This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mpb
Recipients christian.heimes, mpb
Date 2013-06-25.03:13:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1372129999.64.0.733403324372.issue18293@psf.upfronthosting.co.za>
In-reply-to
Content
Hi Christian, thanks for the prompt response.

Sorry about choosing the wrong versions - I wasn't thinking that enhancements should target future versions, but of course that makes sense.

After submitting the enhancement request, I did dig into the OpenSSL docs, and, as Christian points out, I discovered that OpenSSL is not designed in a way that makes it easy to implement the enhancement.

Aside: Interestingly, it looks easier to implement the enhancement in PolarSSL, and probably also in MatrixSSL and CyaSSL.  Of course, that's not really an option.  I did not look at GnuTLS.

Thanks for the pointer about being able to get the server's DER certificate.  That will be useful.  Is there some reason to return DER but not PEM?  Or is this perhaps a bug that could be fixed in a future version of Python's ssl module?

Christian wrote: "Optional and required verification makes only a differen[ce] for client side certs."

I believe there is one small exception:  With SSL_VERIFY_NONE, a client will continue talking with a server with an invalid certificate.  With SSL_VERIFY_PEER, when a client fails to verify the server's certificate, the client will terminate the connection.

Ideally, I would like a client to be able to get both of  the following from the API: (a) the server's certificate (and chain?), and (b) whether or not the certificate (and chain?) is valid (against a given sets of root certs).

Similarly, I would like a Python server to be able to get both of: (a) the client's certificate, and (b) whether the certificate is valid (against a given set of root certs).

In the latter case, it seems that OpenSSL is even more restrictive!  With SSL_VERIFY_NONE, the server will not request (and presumably therefore not even receive) a certificate.  With SSL_VERIFY_PEER, the server will terminate the connection if the client's certificate does not validate!  Very inconvenient!

Interestingly, I believe I have worked around this limitation in OpenSSL using M2Crypto (which is built on top of OpenSSL), by installing my own verifier that overrides the built-in verifier.  This is done as follows:

    import M2Crypto.SSL
    ctx  = M2Crypto.SSL.Context ()
    ctx.load_cert ('var/cert.pem')
    def verify (*args):  return True
    ctx.set_verify (M2Crypto.SSL.verify_peer, 10, verify)

After doing this, both the client and the server can see each other's certificates, even if those certificates are invalid.  (Of course I'll have to write my own verifier.  "return True" is only useful for testing purposes.)

I'm not sure how much of this functionality the Python developers might be interested in putting into Python 3.4?  Given that M2Crypto does not work with Python 3.x at all (at least not yet?), I am interested in finding something that will work with Python 3.x and give me the functionality I want.

I can probably help with the C OpenSSL code, if needed.  However, I have no experience writing Python bindings.

Your thoughts?  Thanks!
History
Date User Action Args
2013-06-25 03:13:19mpbsetrecipients: + mpb, christian.heimes
2013-06-25 03:13:19mpbsetmessageid: <1372129999.64.0.733403324372.issue18293@psf.upfronthosting.co.za>
2013-06-25 03:13:19mpblinkissue18293 messages
2013-06-25 03:13:18mpbcreate