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

[Bill Janssen]

For those of you following along at home, there's now a patch at
http://bill.janssen.org/python/ssl-update-diff which applies against
the current trunk.  Working code, though I still need to tweak some
import statements for backwards compatibility.  I've started updating
the test suite, see Lib/test_ssl.py.  I'd appreciate review and
comments.

Note that the suggested use of the newer code is to

     import ssl, socket
     conn = ssl.sslsocket(socket.socket())

Using the older

     import socket
     conn = socket.ssl(socket.socket())

still works for backwards compatibility (same restrictions:
client-side only, no verification of server cert, SSLv23).  However,
the object returned from this call is not the older C-implemented SSL
object, but rather an instance of ssl.sslsocket (which supports the
same read() and write() calls).  Should I return the C SSL object,
instead?

Bill

> > I view TLS as a wrapper around / layer on top of TCP, and so I think the
> > API should look like, as well.
> 
> I think Martin raises a valid point here, which should at least be
> discussed more thoroughly.  Should there be an "SSL socket", which is
> just like a regular socket?  Does that really provide any additional
> functionality to anyone?  Most apps and classes that use TCP sockets
> wrap the socket with socket._fileobject() to get "read" and "write",
> anyway -- can't they just wrap it with socket.ssl instead?
> 
> Perhaps in the sprint, I should just concentrate on widening the
> "socket.ssl" interface a bit, and improving the functionality of the
> SSLObject a bit.
> 
> Suggested improvements:
> 
>   *  Allow server-side operation.
> 
>   *  Allow specification of particular SSL protocol version.
> 
>   *  Allow certificate validation.  This is a bit tricky; typically
>      certs are validated against some database of root certificates, so you
>      need a whole infrastructure to maintain that database.  Currently, we
>      don't have one, so no certs can be validated.  We could add a switch
>      to allow auto-validation of self-signed certs pretty easily.  I could
>      add a parameter to the SSLObject constructor which would be a filepath
>      for a file full of root certs (see SSL_CTX_load_verify_locations(3ssl)).
> 
>   *  Add a method to retrieve the other side's certificate info.  What's
>      a good format for the "notBefore" and "notAfter" dates?  The simplest
>      thing to use is the string formatting OpenSSL provides, which is
>      always like "Sep 29 16:38:04 2006 GMT", which can easily be parsed
>      by the time.strptime() function if the user wants something else.
>      On the other hand, figuring out how to use strptime() is always a
>      pain, so providing a convenience function wouldn't be a terrible idea.
> 
>   *  Add a shutdown() method to stop using SSL on the underlying socket
>      without closing the socket.
> 
>   *  Make SSLObject conform to the Raw I/O API in PEP 3116.  This one is
>      interesting; what should close() do?  Close the underlying socket?  Or
>      just do an SSL shutdown?
> 
> Bill
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/janssen%40parc.com