Following up on this email:

On Tue, Feb 11, 2014 at 4:59 PM, Jim Baker <jbaker@zyasoft.com> wrote:
...
Incidentally since I wrote the last email, I have also implemented nonblocking server support in socket-reboot, although I haven't yet done the last pieces for SSL. Most of this is around properly managing certificates and validating them, such that the Python API for this can be done in Java. My plan is to avoid writing the most dangerous code in the world (see this blog post, http://tersesystems.com/2014/01/13/fixing-the-most-dangerous-code-in-the-world/) - Java gives us good tools, it just can be too easy to turn security off.

The spike now fully supports server sockets: blocking/nonblocking, plaintext/SSL, including Start TLS protocols which start as plaintext and switch to SSL. I have tested with a grab bag of functional tests, mostly trying to mix CPython and Jython. Remaining pieces include mapping Java/Netty exceptions to Python exceptions; and UDP.

Supporting Start TLS required a bit of thought. Start TLS is a natural pattern with C API sockets, because a child socket may be immediately wrapped as SSL with wrap_socket or instead used send/recv with plaintext, then possibly later a wrap_socket call. However, Netty wants to immediately initialize the handlers on a child socket. Such support required latching Netty's child socket initialization handler so that it waited until seeing user's intent on the child socket, then completing initialization as desired.

The other piece that was completed is supporting OpenSSL-formatted certs and keys so that we can build corresponding trust managers and key managers; this seen in the parameters keyfile, certfile, and ca_certs to wrap_socket, then building an appropriate SSLContext. It might be worthwhile exposing this SSLContext construction as a Jython-specific API in the ssl module so that it can be used directly by Java APIs as well.

Reading OpenSSL-formatted keys currently requires the use of BouncyCastle; it's not clear to me the minimum jar required for this (maybe 500K?), or if it would be straightforward to implement this one piece ourselves. BC also apparently provides a solution to buggy support for certain ciphers, as seen when testing SSL servers under high load, from what looks like OpenSSL-based clients; see https://github.com/netty/netty/issues/1062 and https://community.oracle.com/message/10877177?tstart=0

- Jim