[Python-Dev] More on server-side SSL support

[Bill Janssen]

> 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 HŠring:

- 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