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

[Bill Janssen]

> The idea is that if you call socket.ssl() on a socket that's bound to
> an address, the socket is assumed to be server-side, the cert passed
> in is assumed to be a server-side cert, and the SSLObject returned has
> a couple of extra methods, listen() and accept().  Calling accept() does
> the SSL dance with the remote side, and returns an SSLObject.

After looking at the code a bit more, I think it's wrong to use
SSLObject for both of these uses.  Instead, it makes more sense to
introduce a different C-implemented object, SSLServerPort, which
supports only the method "accept".

So the Pythonic change will be that calling socket.ssl() will call the
"getpeername" method on the socket, and if it doesn't have one, will
assume it's server-side, and construct and return an SSLServerPort
instance instead of doing the SSL dance and returning SSObject.  Code
using this will then call listen on the SSLServerPort, and when a
connection is requested, will call "accept" to do the server-side SSL
dance, which if successful will return an SSLObject.

I intend to add a method to SSLObject, "peer", which will be
functionally equivalent to the current "server" method, which returns
a string version of the name of the server the socket is connected to.
We'd deprecate the use of "server", and replace it with "peer" over
time.  Similarly, internally in _ssl.c, the "server_cert" slot of
SSLObject will become "peer_cert".

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.

Bill