> I'm very tempted to add an optional parameter to socket.ssl(), which > will be a callback function which will be passed the remote side's IP > address and credentials, and which may raise an exception if it > doesn't like the credentials. The exception would then be re-raised > from socket.ssl() (on the client side) or SSLServerPort.accept() (on > the server side). The callback function would of course default to > None which would give the current behavior. This is different from > the built-in SSL verify function, which just checks the certificate > chain. This could do things like only allowing particular clients to > reach the server; it would also work on the client side, allowing a > client to check the credentials of the server. The problem with doing > this is that we'd also need to devise a Python object wrapper for the > cert itself, with an appropriate API. More work.
A simpler way of doing this would be to just have the "peer" call on SSLObject return a read-only mapping giving the entities in the peer certificate (or None, or host and port, if there is no peer certificate). Then the application can look at this before working with it, and decide whether to communicate with the remote end. It would still be nice to add a flag argument to socket.ssl() to allow the application to control the level of verification for the remote certificate. CERT_NONE would mean that no cert is required, or if provided not verified (SSL_VERIFY_NONE). CERT_OPTIONAL would mean that no cert is required, but if one is provided, it's verified (SSL_VERIFY_PEER). CERT_REQUIRED would require a cert to be provided, and would verify it (SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT). The default SSL verify procedure would be used for verification. The default would be CERT_NONE, which is what is currently used. Now, does this mean that we'd need to create a database of trusted certs, similar to Java's trustStore and various OS X keychains? I'm not sure how useful verification will be without such a facility? I see that there was some discussion about this in December, which I missed earlier. http://mail.python.org/pipermail/python-list/2006-December/418511.html And of course there has been discussion about SSL in general: http://mail.python.org/pipermail/python-dev/2005-June/054083.html http://mail.python.org/pipermail/python-dev/2001-October/018161.html There's a list of failings of the current SSL support by Gerhard Hring: - no support for specifying the SSL protocol (SSL v2/SSL v3/SSL v2|3) (I wasn't planning to touch that. The current code uses v2|3. However, this might be a good time to fix this, too. It would be simple to provide an optional keyword protocol argument to socket.ssl().) - no proper certicate checking (See above discussion of verification.) - SSL objects are neither compatible with sockets nor are they file-like objects (Don't currently intend to change this.) - no advanced features like SSL callbacks (to allow the user to accept a cerficicate, for example) (Providing more information about the peer cert would halfway address this.) And there is the pyOpenSSL library, from http://mail.python.org/pipermail/python-dev/2001-July/015855.html, now at http://pyopenssl.sourceforge.net/. It would be nice if we could just use that X509 object type to allow the app to get its hands on the peer cert, but it's GPL'd code. Bill
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com