If I connect a TCP socket s using regular s.connect(), then wrap it
using ssl.wrap_socket(s) and call do_handshake on the resulting SSL
socket, handshake fails in ssl.py:320 with 

AttributeError: 'NoneType' object has no attribute 'do_handshake'

The problem is that when TCP socket is being wrapped in ssl.py:116, it
is not recognized as connected by a call to getpeername(), the exception
thrown in ssl.py:116 and silenced is this:

[Errno 10057] A request to send or receive data was disallowed because
the socket is not connected and (when sending on a datagram socket using
a sendto call) no address was supplied

This is awkward, because synchronous s.connect() has just returned
successfully. Even more weird, if I insert s.getpeername() between TCP
connect() and SSL do_handshake() the latter works fine.

Here is a working sample:

-------------------------------

from socket import socket, AF_INET, SOCK_STREAM
from ssl import wrap_socket, PROTOCOL_TLSv1, CERT_NONE

def test_handshake(address, WORKAROUND):

    s = socket(AF_INET, SOCK_STREAM)
    s.settimeout(3.0)
    s.connect(address)

    if WORKAROUND:
        s.getpeername()

    ssl = wrap_socket(s, server_side = False,
                      ssl_version = PROTOCOL_TLSv1,
                      cert_reqs = CERT_NONE,
                      do_handshake_on_connect = False)
    ssl.do_handshake()

address = ("www.amazon.com", 443)

test_handshake(address, True) # with workaround
print("worked so far")
test_handshake(address, False)
print("but not here it didn't")

-------------------------------

I'm using Python 3.0rc1 under Windows.

I'm unable to reproduce the bug on Python 3.0 svn trunk. Can you retry
with Python 3.0rc2 please?

(I tried your code on Linux and no exception is raised)

Same thing on Python 3.0rc2:

C:\TEMP>python test.py
worked so far
Traceback (most recent call last):
  File "1.py", line 23, in <module>
    test_handshake(address, False)
  File "1.py", line 17, in test_handshake
    ssl.do_handshake()
  File "C:\Python30\lib\ssl.py", line 327, in do_handshake
    self._sslobj.do_handshake()
AttributeError: 'NoneType' object has no attribute 'do_handshake'

1.py == test.py obviously :)

What happens if you remove the call to settimeout()?
Also, it would be nice if you could try with the latest py3k checkout. There's a couple of fixes for do_handshake there (including timeout issues).

The problem does not reproduce in 3.1.1 nor in 3.1.2
(either x86 or x64).

Antoine Pitrou пишет:
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
> What happens if you remove the call to settimeout()?
> Also, it would be nice if you could try with the latest py3k checkout. There's a couple of fixes for do_handshake there (including timeout issues).
> 
> ----------
> nosy: +pitrou
> priority:  -> normal
> versions: +Python 3.1, Python 3.2 -Python 3.0
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue4171>
> _______________________________________
>

Ok, so I think we can close the issue then. Thank you!

Well, I'm sorry to bring this up again, but the problem persists
with Python 3.1.2 (x86, Windows XP). The difference with the
test script behaviour is that now it doesn't break every time.
Perhaps this is the reason I said the problem was gone.
In fact, now that I run the aforementioned script I may get

worked so far
but not here it didn't

and some other time I may get

worked so far
Traceback (most recent call last):
  File "test.py", line 23, in <module>
    test_handshake(address, False)
  File "test.py", line 17, in test_handshake
    ssl.do_handshake()
  File "C:\Python31\lib\ssl.py", line 327, in do_handshake
    self._sslobj.do_handshake()
AttributeError: 'NoneType' object has no attribute 'do_handshake'

and the outcome is unpredictable. It may work many times in a row
and it may break many times in a row.

If this is of any relevance, I've had pywin32-2.14 installed since.

Are you able to compile a fresh checkout of either the py3k or release3.1-maint branch? A bunch of fixes have been committed recently, some of which may (or even should) address your issue.

Checked out and built revision 80956 of py3k against OpenSSL 0.9.8n. Here is the banner:

Python 3.2a0 (py3k:80956, May  8 2010, 11:31:45) [MSC v.1500 32 bit (Intel)] on win32

Now, the breaking script appears not to be breaking any more, even though I tried it in a loop, a 1000 attempts to execute were all successful. 

It seems to be fine now, thank you for your help.

Thank you!