Besides the newness of the ssl module and the labor of actually getting it to work in CP, I'm just waiting for Windows binaries before making the switch. Assuming those three things happen, I'm all for moving to the ssl module.
I think that we should use the standard library SSL module rather than pyOpenSSL, unless there is a very specific reason *not* to. Depending on a third-party library is a bad idea, especially when a standard library will work, for two reasons: 1) reducing dependencies; 2) not depending on libraries with questionable futures (i.e., we don't know when they're going to be updated). Do I smell a branch?
Integrated the patch in . There are a few things left to do, however:
1. Backport it to trunk. This ''may'' involve supporting both the builtin ssl module and pyOpenSSL for some time in trunk. The `ssl` module has been backported to Python 2.3.5 and is available at http://pypi.python.org/pypi/ssl. Needs tested in Py 2.3, 4, and 5 before we drop pyOpenSSL.
2. Decide what to do about the lost 'http over https' error message and broken test.
3. Restore the lost ssl_certificate_chain functionality.
4. Test and/or restore some of the lost ssl_context functionality; for example, certs which are streams instead of file objects, or need decryption.
5. Restore the lost SSL_* environ entries.
6. Remove the 'print' in tick() once we've debugged enough.
Okay; ssl libs are now pluggable in 3.2 via a new 'server.ssl_module' attribute. This defaults to 'pyopenssl' in trunk and 'builtin' in python3. Implemented in  (trunk) and  (python3) and a couple changesets immediately thereafter.
Fixed the broken 'http over https' error message in .
It would still be good to pursue the ssl_certificate_chain functionality, plus some of the ssl_context functionality (for example, certs which are streams instead of file objects, or need decryption) which pyopenssl provided, in the builtin ssl module. We still are also missing some SSL_* environ entries when using the builtin ssl.