> 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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
