homepage

While running test_ssl in verbose mode, I noticed the following exception:
 [...]
 test_protocol_sslv3 (test.test_ssl.ThreadedTests)
 Connecting to an SSLv3 server with various client options ... 
 SSLv3->SSLv3 CERT_NONE
 SSLv3->SSLv3 CERT_OPTIONAL
 SSLv3->SSLv3 CERT_REQUIRED
 {SSLv23->SSLv3} CERT_NONE
 Exception in thread Thread-54:
 Traceback (most recent call last):
 File "/home/nadeem/src/cpython/def/Lib/threading.py", line 730, in _bootstrap_inner
 self.run()
 File "/home/nadeem/src/cpython/def/Lib/test/test_ssl.py", line 926, in run
 if not self.wrap_conn():
 File "/home/nadeem/src/cpython/def/Lib/test/test_ssl.py", line 880, in wrap_conn
 self.sock, server_side=True)
 File "/home/nadeem/src/cpython/def/Lib/ssl.py", line 206, in wrap_socket
 _context=self)
 File "/home/nadeem/src/cpython/def/Lib/ssl.py", line 293, in __init__
 raise x
 File "/home/nadeem/src/cpython/def/Lib/ssl.py", line 289, in __init__
 self.do_handshake()
 File "/home/nadeem/src/cpython/def/Lib/ssl.py", line 489, in do_handshake
 self._sslobj.do_handshake()
 ConnectionResetError: [Errno 104] Connection reset by peer
 {TLSv1->SSLv3} CERT_NONE
 SSLv23->SSLv3 CERT_NONE
 ok
 [...]
Note that the exception is ignored and the test still passes.

What is the OpenSSL version? (printed at the beginning of test_ssl)
Having an exception here is quite normal: the test checks that a certain (client protocol, server protocol) combination fails. However, a SSLError is expected rather than an OSError.

> What is the OpenSSL version?
 test_ssl: testing with 'OpenSSL 1.0.0e 6 Sep 2011' (1, 0, 0, 5, 15)
 under Linux ('debian', 'wheezy/sid', '')
 HAS_SNI = True

> > What is the OpenSSL version?
> 
> test_ssl: testing with 'OpenSSL 1.0.0e 6 Sep 2011' (1, 0, 0, 5, 15)
> under Linux ('debian', 'wheezy/sid', '')
> HAS_SNI = True
For the record, it works here under 'OpenSSL 1.0.0d 8 Feb 2011'.

The changelog between 1.0.0d and 1.0.0e doesn't seem to list anything which could affect this test:
 *) Fix bug where CRLs with nextUpdate in the past are sometimes accepted
 by initialising X509_STORE_CTX properly. (CVE-2011-3207)
 [Kaspar Brand <ossl@velox.ch>]
 *) Fix SSL memory handling for (EC)DH ciphersuites, in particular
 for multi-threaded use of ECDH. (CVE-2011-3210)
 [Adam Langley (Google)]
 *) Fix x509_name_ex_d2i memory leak on bad inputs.
 [Bodo Moeller]
 *) Remove hard coded ecdsaWithSHA1 signature tests in ssl code and check
 signature public key algorithm by using OID xref utilities instead.
 Before this you could only use some ECC ciphersuites with SHA1 only.
 [Steve Henson]
 *) Add protection against ECDSA timing attacks as mentioned in the paper
 by Billy Bob Brumley and Nicola Tuveri, see:
	http://eprint.iacr.org/2011/232.pdf
(from http://www.openssl.org/news/changelog.html)

Might it be a distribution-specific issue, then? I'm running Ubuntu and
IIRC you're using Mageia?

> Might it be a distribution-specific issue, then? I'm running Ubuntu and
> IIRC you're using Mageia?
Yes, I'm using Mageia. It would be nice if you could take a look at
Ubuntu's or Debian's OpenSSL patches (if any).

I can't see anything in the Ubuntu patches (available from
<https://launchpad.net/ubuntu/+source/openssl/1.0.0e-2ubuntu4>)
that relate to networking or handshakes, so maybe it's not that.
I could be wrong, though - I've never used OpenSSL myself.

I see these failures too on Ubuntu, both in verbose and non-verbose mode:
$ ./python -m test -v test_ssl
== CPython 3.4.0a0 (default:1c71882938eb+, Mar 3 2013, 14:21:46) [GCC 4.6.3]
== Linux-3.2.0-38-generic-i686-with-debian-wheezy-sid little-endian
== /home/wolf/dev/py/py3k/build/test_python_21756
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1)
[1/1] test_ssl
test_ssl: testing with 'OpenSSL 1.0.1 14 Mar 2012' (1, 0, 1, 0, 15)
 under Linux ('debian', 'wheezy/sid', '')
 HAS_SNI = True
test_ciphers (test.test_ssl.ContextTests) ... ok
[...]
test_protocol_sslv3 (test.test_ssl.ThreadedTests)
Connecting to an SSLv3 server with various client options ... 
 SSLv3->SSLv3 CERT_NONE
 SSLv3->SSLv3 CERT_OPTIONAL
 SSLv3->SSLv3 CERT_REQUIRED
 {SSLv23->SSLv3} CERT_NONE
Exception in thread Thread-62:
Traceback (most recent call last):
 File "/home/wolf/dev/py/py3k/Lib/threading.py", line 639, in _bootstrap_inner
 self.run()
 File "/home/wolf/dev/py/py3k/Lib/test/test_ssl.py", line 1029, in run
 if not self.wrap_conn():
 File "/home/wolf/dev/py/py3k/Lib/test/test_ssl.py", line 980, in wrap_conn
 self.sock, server_side=True)
 File "/home/wolf/dev/py/py3k/Lib/ssl.py", line 232, in wrap_socket
 _context=self)
 File "/home/wolf/dev/py/py3k/Lib/ssl.py", line 332, in __init__
 raise x
 File "/home/wolf/dev/py/py3k/Lib/ssl.py", line 328, in __init__
 self.do_handshake()
 File "/home/wolf/dev/py/py3k/Lib/ssl.py", line 543, in do_handshake
 self._sslobj.do_handshake()
ConnectionResetError: [Errno 104] Connection reset by peer
 {TLSv1->SSLv3} CERT_NONE
 SSLv23->SSLv3 CERT_NONE
ok
test_protocol_tlsv1 (test.test_ssl.ThreadedTests)
Connecting to a TLSv1 server with various client options ... 
 TLSv1->TLSv1 CERT_NONE
 TLSv1->TLSv1 CERT_OPTIONAL
 TLSv1->TLSv1 CERT_REQUIRED
 {SSLv3->TLSv1} CERT_NONE
 {SSLv23->TLSv1} CERT_NONE
Exception in thread Thread-76:
Traceback (most recent call last):
 File "/home/wolf/dev/py/py3k/Lib/threading.py", line 639, in _bootstrap_inner
 self.run()
 File "/home/wolf/dev/py/py3k/Lib/test/test_ssl.py", line 1029, in run
 if not self.wrap_conn():
 File "/home/wolf/dev/py/py3k/Lib/test/test_ssl.py", line 980, in wrap_conn
 self.sock, server_side=True)
 File "/home/wolf/dev/py/py3k/Lib/ssl.py", line 232, in wrap_socket
 _context=self)
 File "/home/wolf/dev/py/py3k/Lib/ssl.py", line 332, in __init__
 raise x
 File "/home/wolf/dev/py/py3k/Lib/ssl.py", line 328, in __init__
 self.do_handshake()
 File "/home/wolf/dev/py/py3k/Lib/ssl.py", line 543, in do_handshake
 self._sslobj.do_handshake()
ConnectionResetError: [Errno 104] Connection reset by peer
ok
test_recv_send (test.test_ssl.ThreadedTests)
[...]
----------------------------------------------------------------------
Ran 58 tests in 2.080s
OK (skipped=1)
1 test OK.

Ok, I guess we could handle the ConnectionResetError as a SSLError for the purpose of those tests. What probably happens is that OpenSSL versions, instead of answering "sorry, I can't talk to you", brutally reset the connections.

Ezio, Nadeem, do you want to provide a patch?

The first traceback comes from 
try_protocol_combo(ssl.PROTOCOL_SSLv3, ssl.PROTOCOL_SSLv23, False,
 client_options=ssl.OP_NO_SSLv3)
in test_protocol_sslv3. The test is marked with the @skip_if_broken_ubuntu_ssl decorator, but this seems to be some different kind of brokenness.

This change fixes the problem (and doesn't break anything else that I can see):
--- a/Lib/test/test_ssl.py
+++ b/Lib/test/test_ssl.py
@@ -979,7 +979,7 @@
 self.sslconn = self.server.context.wrap_socket(
 self.sock, server_side=True)
 self.server.selected_protocols.append(self.sslconn.selected_npn_protocol())
- except ssl.SSLError as e:
+ except (ssl.SSLError, ConnectionResetError) as e:
 # XXX Various errors can have happened here, for example
 # a mismatching protocol version, an invalid certificate,
 # or a low-level bug. This should be made more discriminating.
Does that look reasonable?

Yes, it's certainly reasonable. You could add a comment explaining the issue.

New changeset fa24c1382bd3 by Nadeem Vawda in branch '3.2':
Issue #13898: test_ssl no longer prints a spurious stack trace on Ubuntu.
http://hg.python.org/cpython/rev/fa24c1382bd3 

New changeset 77cbb3ba5d40 by Nadeem Vawda in branch '3.3':
Issue #13898: test_ssl no longer prints a spurious stack trace on Ubuntu.
http://hg.python.org/cpython/rev/77cbb3ba5d40 

New changeset 69f737f410f0 by Nadeem Vawda in branch 'default':
Issue #13898: test_ssl no longer prints a spurious stack trace on Ubuntu.
http://hg.python.org/cpython/rev/69f737f410f0 

> You could add a comment explaining the issue.
Done.
This doesn't seem to affect 2.7. Marking as fixed in 3.2/3.3/3.4.

Thanks for the fix -- that solved the problem here too.