If I use the server code in the attachment I get this error in unwrap:

Traceback (most recent call last):
  File "server.py", line 23, in <module>
    deal_with_client(connstream)
  File "server.py", line 13, in deal_with_client
    s = connstream.unwrap()
  File "/usr/lib/python3.1/ssl.py", line 302, in unwrap
    s = self._sslobj.shutdown()
socket.error: [Errno 0] Error

This error message is imo far from optiomal as it gives no clue whatsoever. My Openssl version is: 'OpenSSL 0.9.8o 01 Jun 2010'. Aside from that connstream.close() doesn't close the underlying socket (as seen in http://bugs.python.org/issue10127 Reproduceable with py2.6 and 2.7). The only way to properly close the connection now is:

connstream.close(); newsocket.close()
or
del newsocket; connstream.close()
Maybe the docs should point that out more prominent.

If you need more info just tell me.

As we discussed on IRC, there are two things here:

• unwrap() can give an error because it tries to shutdown the SSL layer cleanly, and the other side doesn't support it or is already closed; unwrap() is useful mostly if you plan to use the clear-text layer afterwards, otherwise you can just call shutdown(socket.SHUT_RDWR) and then close()

• the error message and errnos are totally bogus, but I'm afraid that's because of OpenSSL giving us this information.

"This information" being no information, is that really all you can get out of OpenSSL?

"This information" being no information, is that really all you can get out of OpenSSL?

Well the situation as the same as a system call which would return
failure but leave errno 0 (except that OpenSSL has its own
kind-of-errnos).
OpenSSL's error reporting is unfortunately poorly if at all documented,
and I don't know what to do here.

Poor old bug.

Just being bitten from it today, while trying to package pyftpdlib on the openSUSE build service, which creates a clean reproducible build environment for all packages, and testing fails.

Part of the game: openssl 1.0.1k, Python 2.7.8

https://build.opensuse.org/package/show/home:frispete:python/python-pyftpdlib

It happens reproducible for i586 only, but not for x86_64, with all the same versions, and not with a local (much faster) build host.

So it is smells like a timing problem.

[ 97s] ERROR: test_nlst (test_functional_ssl.TestFtpListingCmdsTLSMixin)
[ 97s] ----------------------------------------------------------------------

[   97s] Traceback (most recent call last):
[   97s]   File "/home/abuild/rpmbuild/BUILD/pyftpdlib-1.5.1/pyftpdlib/test/test_functional_ssl.py", line 139, in test_nlst
[   97s]     super(TestFtpListingCmdsTLSMixin, self).test_nlst()
[   97s]   File "/home/abuild/.local/lib/python2.7/site-packages/pyftpdlib-1.5.1-py2.7.egg/pyftpdlib/test/test_functional.py", line 1187, in test_nlst
[   97s]     self._test_listing_cmds('nlst')
[   97s]   File "/home/abuild/.local/lib/python2.7/site-packages/pyftpdlib-1.5.1-py2.7.egg/pyftpdlib/test/test_functional.py", line 1180, in _test_listing_cmds
[   97s]     self.client.retrlines('%s %s' % (cmd, tempdir), x.append)
[   97s]   File "/usr/lib/python2.7/ftplib.py", line 735, in retrlines
[   97s]     conn.unwrap()
[   97s]   File "/usr/lib/python2.7/ssl.py", line 289, in unwrap
[   97s]     s = self._sslobj.shutdown()
[   97s] error: [Errno 0] Error

I understand this condition happens when the local end calls unwrap(), but the low-level socket connection has already been shut down from the remote end. If the remote is too slow, I get ConnectionResetError instead.

There is some discussion of this at <http://www.mail-archive.com/search?l=mid&q=4BC200FE.4070508@netbauds.net\>. I tend to agree with Antoine that unfortunately there is not much Python can do without help from Open SSL. I.e. can we rely on SSL_shutdown() always setting errno = 0 to indicate Python should raise SSLEOFError, or should Open SSL add some new way of indicating this condition?