[Python-Dev] Re: Python's SSL: Would you like to help?

Ng Pheng Siong ngps@post1.com
Tue, 30 Oct 2001 01:52:01 +0800


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