The asynchronous do_handshakes fails for sockets that were connected asynchronously. Tested on 2.6, 3.1 and 3.2.

Traceback (most recent call last):
  File "handshake.py", line 17, in <module>
    s.do_handshake()
  File "/usr/lib/python2.6/ssl.py", line 279, in do_handshake
    self._sslobj.do_handshake()
AttributeError: 'NoneType' object has no attribute 'do_handshake'

Ok, one issue is that connect_ex() isn't implemented for SSL sockets, so it defers to the normal implementation instead, which is wrong.

But your still is wrong too. connect_ex() returns an error, meaning the socket isn't connected and you must retry. Here is a working snippet using connect():


def connect():
    try:
        s.connect(('people.csail.mit.edu', 443))
    except socket.error as e:
        if e.errno != errno.EINPROGRESS:
            raise
        return False
    else:
        return True

while not connect():
    select.select([s], [s], [])

while True:
    try:
        select.select([s], [s], [])
        s.do_handshake()
        break
    except ssl.SSLError as err:
        if err.args[0] == ssl.SSL_ERROR_WANT_READ:
            select.select([s], [], [])
        elif err.args[0] == ssl.SSL_ERROR_WANT_WRITE:
            select.select([], [s], [])
        else:
            raise

A workaround would be exposing _ssl.wrapssl in ssl so that it can be called once the socket is connected and no non-public API had to be used.

The select call after the connect_ex waits until the connection is done, for the first write event is fired then, so the socket is connected afterwards.

> The select call after the connect_ex waits until the connection is
> done, for the first write event is fired then, so the socket is
> connected afterwards.

You are right. Here is a patch for py3k implementing connect_ex() and solving the issue with the missing "_sslobj" attribute. It makes your script run fine.

(ideally I should add some tests to the patch, at least for connect_ex)

I've committed the patch + some tests in r88664 (3.3), r88665 (3.2) and r88666 (2.7). Thanks for reporting this!

Thanks for the fast response and for fixing this.