On Mon, Oct 29, 2001 at 01:53:07PM +0100, Gerhard Häring wrote:
I've meanwhile started a discussion about the future of SSL support in Python itself on the python-dev mailinglist.
The talk is about several issues, like redesign a whole new API (yes/no), integrate an existing module (which one?), support much crypto at all.
As you seem to have a lot of experience in this field, perhaps you'd like to share some of your opinions there?
[ Not subscribed, hopefully this gets thru. ] Hello, Thanks for asking. I've just read the discussion in the archives. My own archives contain a similar (but much shorter) discussion that took place on the old python-crypto@egroups list in Apr 2000. I've also just downloaded 2.2b1, POW (Python OpenSSL wrappers) 0.5, and pyOpenSSL 0.4 to have a quick look-see. (Haven't been keeping track of the competition. ;-) I noticed there are several SSL patches on SF, mostly from Gerhard. I didn't read the patches, though. Here are some random thoughts based on my experience with M2Crypto: - To do simple multi-threading, you need to bracket calls to SSL_read(), SSL_write(), etc. with Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. You also (apparently) need to implement the locking required by OpenSSL; see M2Crypto's _thread.i. IIRC, OpenSSL's docu warns of Bad Things should one fail to do so. (None of the others seem to do this.) If you want to do callbacks for certificate verification, it's a little more complicated. First, you need to muck around with Python's thread states in OpenSSL's structures. M2Crypto and pyOpenSSL do these mostly the same way. POW doesn't do this. Next, consider the Python "SSL Context" object that mirrors SSL_CTX: In M2Crypto, the "SSL Context" is implemented in Python; conveniently, I use it to keep additional Python-level policy stuff. Thus, when OpenSSL calls back into M2Crypto, I need a means to get at the Python SSL Context object, before calling back into Python. Implementing the SSL Context object in C may make this simpler. (I see 2.2b1 does only SSL_VERIFY_NONE. Ditto POW and pyOpenSSL, it seems.) - Even if you only want to do certificates within SSL, you need to wrap quite a bit of the X.509 API. See M2Crypto's _x509.i and X509.py. POW seems to have done so, as well. If you also want to do X.509 independent of SSL (say for implementing a CA), you'll need to do more housekeeping, like whether to free a given structure at the Python side or the C side. Grep for "_pyfree" in M2Crypto's Python code. - Asynchronous SSL: I think M2Crypto has this mostly right, since ZServerSSL works (2nd birthday came and went it seems ;-), and I've recently implemented Medusa-based FTP-over-TLS which interoperates with other people's clients. Based on my light reading of the code, none of 2.2b1, POW and pyOpenSSL do async-SSL properly at all. - FakeSocket, SSLFakeSocket and SSLFakeFile are ugly! M2Crypto wraps OpenSSL's "stackable BIOs". makefile() on an SSL connection pushes a buffering BIO on top of the SSL BIO and returns that, which then behaves like a Python file-like object. Even does readline()! See M2Crypto's BIO.py. 2.2b1 has a BIO member in PySSLObject but doesn't seem to use it. Nor do POW and pyOpenSSL, it appears. Well, that's only the SSL-related stuff that came to my mind readily. The Python development team has to decide how much of the above you want within Python, e.g., how much of the BIO and X.509 APIs to wrap. Not to mention PRNGs, secure memory handling and crypto-in-general. (Lastly, I'm pleased to note that M2Crypto is still ahead of the competition. Gotta keep moving, though! ;-) Cheers. -- Ng Pheng Siong <ngps@post1.com> * http://www.post1.com/home/ngps