With a particularly atrocious network connection, I often get the following exception:

File "/usr/lib/python3/dist-packages/dugong/init.py", line 503, in connect
self._sock = self.ssl_context.wrap_socket(self._sock, server_hostname=server_hostname)
File "/usr/lib/python3.5/ssl.py", line 385, in wrap_socket
_context=self)
File "/usr/lib/python3.5/ssl.py", line 760, in __init__
self.do_handshake()
File "/usr/lib/python3.5/ssl.py", line 996, in do_handshake
self._sslobj.do_handshake()
File "/usr/lib/python3.5/ssl.py", line 641, in do_handshake
self._sslobj.do_handshake()
OSError: [Errno 0] Error

I don't think an error with errno == 0 should ever be raised by Python.

It might help if you explained what “atrocities” are happening on your network. Is there a proxy or man-in-the-middle (or the remote peer) that shuts down TCP connections?

If so, perhaps this is similar to bpo-10808. From my memory, in that case an OS “recv” or “read” call returns zero to indicate a connection was shut down. Python and/or Open SSL correctly treats this as an error, but then assumes “errno” is valid. Perhaps Python should be raising SSLEOFError in this situation.

Maybe also check the “suppress_ragged_eofs” setting, but I think that only affects later stages, after the handshake succeeds.

Regarding "atrocious connection": I wish I knew, but I have no control of the connection. All I can tell is that there are frequent disconnects, occasional latency spikes, my remote ip address seems to change frequently (while the apparent local one stays as-is, so presumably some NAT in between), temporary bandwidth drops, etc.

We have an easy reproduction of this "[Errno 0] Error" on the server side in tornadoweb/tornado#2504 (comment)

It is triggered by a connection from nc -z (which I think is doing a TCP handshake and shutting down the connection cleanly, but I'm not sure. It might just send an RST instead of the clean shutdown). On macos, I get SSL_ERROR_EOF (as expected), but on linux it raises an OSError with errno 0. (Note that the script as posted has a small mistake in that it is using a client-side SSLContext on the server side. The same error is seen when that mistake is fixed)

I'm going to add "errno 0" to the list of errors that Tornado should swallow silently here, so if you're trying to reproduce this in the future use Tornado 5.1.1.

This flakiness just caused a PR merge to be blocked by AppVeyor for me:

======================================================================
ERROR: test_with_statement (test.test_nntplib.NetworkedNNTP_SSLTests)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "C:\projects\cpython\lib\test\test_nntplib.py", line 242, in wrapped
    meth(self)
  File "C:\projects\cpython\lib\test\test_nntplib.py", line 264, in test_with_statement
    with self.NNTP_CLASS(self.NNTP_HOST, timeout=TIMEOUT, usenetrc=False) as server:
  File "C:\projects\cpython\lib\nntplib.py", line 1077, in __init__
    self.sock = _encrypt_on(self.sock, ssl_context, host)
  File "C:\projects\cpython\lib\nntplib.py", line 292, in _encrypt_on
    return context.wrap_socket(sock, server_hostname=hostname)
  File "C:\projects\cpython\lib\ssl.py", line 405, in wrap_socket
    return self.sslsocket_class._create(
  File "C:\projects\cpython\lib\ssl.py", line 853, in _create
    self.do_handshake()
  File "C:\projects\cpython\lib\ssl.py", line 1117, in do_handshake
    self._sslobj.do_handshake()
OSError: [Errno 0] Error

https://ci.appveyor.com/project/python/cpython/builds/21299396

I lucked out by kicking it with a no-op change to re-trigger an appveyor run where it passed.

In the CherryPy project it is also observed on Windows with Python 3,7.2.
In CherryPy it's triggered by Checker plugin, which connects to the app listening to the socket port in TLS mode via plain HTTP during startup (from the same process).
It has been around for a while: cherrypy/cherrypy#1618 (comment)

I volunteer to test the theory that the connection is closed mid-flight.

Rejoice: https://github.com/dimaqq/bpo-31122
Short, easy to reproduce :)
(I've tested on Mac: 3.7, 3.8, 3.9a from python.org, linked against OpenSSL 1.1.1c/d)
Funnily enough, Python 2.7 raises an ssl.SSLEOFError instead 🤷‍♂️

I've traced it down to here:

err.c (errno) == 0, no error, and err.ssl == 5, SSL_ERROR_SYSCALL, helpfully commented "look at error stack/return value/errno" in openssl/ssl.h 😅

I'm a bit suspicious about s->errorhandler() which is some old convention (git blame: 8 years ago), commented "checks errno, returns NULL, set a Python exception", but at this point, we know that errno is 0, so why call it?

I'm thinking to just change that to SSLEOFError, but I wonder if something else might break?

#18772 posted

If someone can review #18772 then pretty-please review 🙏

I know Christian is very busy, so what can I do to have this patch reviewed?

• it's concise
• there's a reproducer

Would anyone be able to review this? People keep reporting this bug in my project.
Months are just passing while the PR is just a few lines of code:
https://github.com/python/cpython/pull/18772/files

New changeset 495bd03 by Dima Tisnek in branch 'master':
bpo-31122: ssl.wrap_socket() now raises ssl.SSLEOFError rather than OSError when peer closes connection during TLS negotiation (GH-18772)
495bd03

Thanks!

fyi for confirmation incase anyone doubted:

>>> issubclass(ssl.SSLEOFError, OSError)
True

So from a code point of view, anything already catching the error still catches the error. 100% bugfix.

While this is present in 3.7 (and earlier?), 3.7 is EOL - security fix only stage. the 3.8 and 3.9 PRs should automerge after CI finishes.

please reopen the issue or ping me on those PRs if they somehow fail to do so.

New changeset 2434581 by Miss Islington (bot) in branch '3.8':
bpo-31122: ssl.wrap_socket() now raises ssl.SSLEOFError rather than OSError when peer closes connection during TLS negotiation (GH-18772)
2434581

New changeset fc8ffe2 by Miss Islington (bot) in branch '3.9':
bpo-31122: ssl.wrap_socket() now raises ssl.SSLEOFError rather than OSError when peer closes connection during TLS negotiation (GH-18772)
fc8ffe2