This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: test_ssl failures with OpenSSL 1.0.0
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, benjamin.peterson, flox, giampaolo.rodola, janssen, pitrou, rpetrov, vstinner
Priority: normal Keywords: patch

Created on 2010-04-05 20:45 by pitrou, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
ciphers.patch pitrou, 2010-04-16 20:40
ciphers2.patch pitrou, 2010-04-16 21:35
Messages (10)
msg102409 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-04-05 20:45
When I compile and link against a local build of OpenSSL 1.0.0 (vanilla), I get the following errors in test_ssl:

======================================================================
ERROR: testProtocolSSL2 (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 869, in testProtocolSSL2
    tryProtocolCombo(ssl.PROTOCOL_SSLv2, ssl.PROTOCOL_SSLv23, True)
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 736, in tryProtocolCombo
    CERTFILE, CERTFILE, client_protocol, chatty=False)
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 688, in serverParamsTest
    raise test_support.TestFailed("Unexpected exception:  " + str(x))
TestFailed: Unexpected exception:  [Errno 104] Connection reset by peer

======================================================================
ERROR: testProtocolSSL3 (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 903, in testProtocolSSL3
    tryProtocolCombo(ssl.PROTOCOL_SSLv3, ssl.PROTOCOL_SSLv23, False)
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 745, in tryProtocolCombo
    ssl.get_protocol_name(server_protocol)))
TestFailed: Client protocol SSLv23 succeeded with server protocol SSLv3!

======================================================================
ERROR: testProtocolTLS1 (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 914, in testProtocolTLS1
    tryProtocolCombo(ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_SSLv23, False)
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 745, in tryProtocolCombo
    ssl.get_protocol_name(server_protocol)))
TestFailed: Client protocol SSLv23 succeeded with server protocol TLSv1!
msg102440 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-04-06 08:57
Extract of SSL_CTX_new manual page:


SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)

  A TLS/SSL connection established with these methods will understand
  the SSLv2, SSLv3, and TLSv1 protocol. A client will send out SSLv2
  client hello messages and will indicate that it also understands
  SSLv3 and TLSv1. A server will understand SSLv2, SSLv3, and TLSv1
  client hello messages. This is the best choice when compatibility
  is a concern.

I don't think that "Client protocol SSLv23 succeeded with server protocol SSLv3" or "Client protocol SSLv23 succeeded with server protocol TLSv1" are errors.
msg102441 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-04-06 09:05
It begs the question of why the tests succeed with previous OpenSSL versions.
The only possibly relevant entry I could find in the OpenSSL changelog (but I'm not an expert) is the following:

  *) If no SSLv2 ciphers are used don't use an SSLv2 compatible client hello:
     this allows the use of compression and extensions. Change default cipher
     string to remove SSLv2 ciphersuites. This effectively avoids ancient SSLv2
     by default unless an application cipher string requests it.
     [Steve Henson]
msg102446 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-04-06 09:56
All errors concern SSLv23 at server side, and another protocol at client side (SSLv23 for client and server works as expected).
msg102757 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-04-09 22:36
After some investigation, the error does occur because of the aforementioned changelog entry (SSLv2 weak ciphers are now disabled by default). To check it I just added the following line to newPySSLObject():

     SSL_CTX_set_cipher_list(self->ctx, "ALL");

Of course this isn't desirable: we shouldn't blindly enable weak ciphers. Instead we could simply add an argument to configure allowed ciphers, and use "ALL" in our tests. Or we could add a separate method to configure ciphers.

(this begs the question of whether this is suitable post-beta1)

What do you think?
msg102782 - (view) Author: Roumen Petrov (rpetrov) * Date: 2010-04-10 14:51
Antoine Pitrou wrote:
>
> Antoine Pitrou<pitrou@free.fr>  added the comment:
>
> After some investigation, the error does occur because of the aforementioned changelog entry (SSLv2 weak ciphers are now disabled by default). To check it I just added the following line to newPySSLObject():
>
>       SSL_CTX_set_cipher_list(self->ctx, "ALL");
>
> Of course this isn't desirable: we shouldn't blindly enable weak ciphers. Instead we could simply add an argument to configure allowed ciphers, and use "ALL" in our tests. Or we could add a separate method to configure ciphers.
>
> (this begs the question of whether this is suitable post-beta1)
>
> What do you think?

List of ciphers is application dependent and configure script can't 
limit users(applications) .

Roumen
msg102783 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-04-10 14:53
> List of ciphers is application dependent and configure script can't 
> limit users(applications) .

I was obviously talking about a runtime argument to ssl.wrap_socket().
msg103357 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-04-16 20:34
A set_ciphers() method turns out to be highly impractical, since the underlying SSL objects are created lazily when we actually connect the socket.
Therefore, I have instead opted for a new "ciphers" argument to the SSL constructor(s). Patch attached.
msg103363 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-04-16 21:35
New patch updating docs.
msg103413 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-04-17 17:41
Committed in r80151 (trunk), r80154 (py3k).
History
Date User Action Args
2022-04-11 14:56:59adminsetgithub: 52569
2010-04-17 17:41:14pitrousetstatus: open -> closed
resolution: fixed
messages: + msg103413

stage: patch review -> resolved
2010-04-16 21:39:44pitrousetstage: needs patch -> patch review
2010-04-16 21:35:24pitrousetfiles: + ciphers2.patch

messages: + msg103363
2010-04-16 20:40:04pitrousetfiles: + ciphers.patch
2010-04-16 20:39:51pitrousetfiles: - ciphers.patch
2010-04-16 20:34:50pitrousetfiles: + ciphers.patch
keywords: + patch
messages: + msg103357
2010-04-10 14:53:54pitrousetmessages: + msg102783
2010-04-10 14:51:55rpetrovsetnosy: + rpetrov
messages: + msg102782
2010-04-09 22:36:59pitrousetnosy: + benjamin.peterson
messages: + msg102757
2010-04-06 14:50:15Arfreversetnosy: + Arfrever
2010-04-06 09:56:15vstinnersetmessages: + msg102446
2010-04-06 09:05:23pitrousetmessages: + msg102441
2010-04-06 08:57:34vstinnersetnosy: + vstinner
messages: + msg102440
2010-04-05 20:45:34pitroucreate