> 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 _______________________________________________ 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
