Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1064942 - ssl.py or httplib use wrong version string PROTOCOL_SSLV23 for wrap_socket() [NEEDINFO]
Summary: ssl.py or httplib use wrong version string PROTOCOL_SSLV23 for wrap_socket()
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: python
Version: 6.6
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Python Maintainers
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-13 15:30 UTC by Juha Tuomala
Modified: 2015-01-07 14:25 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-07 14:25:49 UTC
bkabrda: needinfo? (tuju)


Attachments (Terms of Use)

Description Juha Tuomala 2014-02-13 15:30:57 UTC
Description of problem:
A wrong version string is sent during SSL-handshake and it then fails.


Version-Release number of selected component (if applicable):
python, python-libs-2.6.6-52.el6.x86_64 preceisely


How reproducible:
Always.


Steps to Reproduce:
1. Write a python implemention that uses SSL, like https with httplib
2. Take a SSL-connection to a server
3. It fails.

Actual results:
  File "/usr/lib64/python2.6/httplib.py", line 914, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib64/python2.6/httplib.py", line 951, in _send_request
    self.endheaders()
  File "/usr/lib64/python2.6/httplib.py", line 908, in endheaders
    self._send_output()
  File "/usr/lib64/python2.6/httplib.py", line 780, in _send_output
    self.send(msg)
  File "/usr/lib64/python2.6/httplib.py", line 739, in send
    self.connect()
  File "/usr/lib64/python2.6/httplib.py", line 1116, in connect
    self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file)
  File "/usr/lib64/python2.6/ssl.py", line 342, in wrap_socket
    suppress_ragged_eofs=suppress_ragged_eofs)
  File "/usr/lib64/python2.6/ssl.py", line 120, in __init__
    self.do_handshake()
  File "/usr/lib64/python2.6/ssl.py", line 279, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [Errno 1] _ssl.c:492: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure


Expected results:
An established SSL-connection.


Additional info:
File /usr/lib64/python2.6/ssl.py has wrap_socket that uses ssl_version argument that is hardcoded.

def wrap_socket(sock, keyfile=None, certfile=None,
                server_side=False, cert_reqs=CERT_NONE,
                ssl_version=PROTOCOL_SSLv23, ca_certs=None,
                do_handshake_on_connect=True,
                suppress_ragged_eofs=True):


By changing it from PROTOCOL_SSLv23 to PROTOCOL_SSLv3 things work again.

It appears, that httplib uses ssl.py from line 1116 and there the ssl_version is not passed at all.

  self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file)

so maybe this could be fixed in httplib. Both files reside in python-libs so the component is correct.

Version strings are documented in SSL page
  http://docs.python.org/2/library/ssl.html

This bug was introduced into CentOS at the end of last year, I installed it in November 05 and since then nothing worked. No idea when working and breaking package versions were released.

This problem is widely talked in different net forums and appears to exist in different languages that use SSL-libraries.

Comment 2 Tomas Hoger 2014-12-15 10:08:44 UTC
(In reply to Juha Tuomala from comment #0)
> def wrap_socket(sock, keyfile=None, certfile=None,
>                 server_side=False, cert_reqs=CERT_NONE,
>                 ssl_version=PROTOCOL_SSLv23, ca_certs=None,
>                 do_handshake_on_connect=True,
>                 suppress_ragged_eofs=True):
> 
> By changing it from PROTOCOL_SSLv23 to PROTOCOL_SSLv3 things work again.

This is bad idea and it won't happen.  SSLv23 enables all protocols supported by the underlying OpenSSL, including TLS 1.x.  SSLv3 only enables SSL 3.0, which is know to have security issues and should be avoided in the future.  It's even disabled by default in the newest upstream Python versions.

> This bug was introduced into CentOS at the end of last year, I installed it
> in November 05 and since then nothing worked. No idea when working and
> breaking package versions were released.

OpenSSL packages were updated form 1.0.0 to 1.0.1 via RHBA-2013:1585:

https://rhn.redhat.com/errata/RHBA-2013-1585.html

That update introduced support for TLS 1.1 and TLS 1.2, and it is automatically enabled when SSLv23 is used.  Prior to the update TLS 1.0 was the highest supported version.  This change may cause connection issues when talking to broken server unable to cope with client hellos that indicate TLS 1.1 or higher as supported version.

However, RHBA-2013:1585 was only released on Nov20, and hence does not match your timeline mentioning Nov05.

You've not indicated which server you're trying to connect to for others to try to reproduce the issue.  There are few things you can test:
- check if it works with PROTOCOL_TLSv1
- test what openssl s_client can connect with.  use it as: openssl s_client -connect yousrserver:443 and add these options one by one: -no_tls1_2 -no_tls1_1 -no_tls1

Comment 3 Bohuslav "Slavek" Kabrda 2014-12-16 09:42:24 UTC
Juha, can you please confirm that everything works with OpenSSL build mentioned in Tomas's comment? If so, I'd like to close this bug. Thanks!

Comment 4 Bohuslav "Slavek" Kabrda 2015-01-07 14:25:49 UTC
Closing this. Feel free to reopen if things don't work with the new OpenSSL build as mentioned in comment 3. Thanks.


Note You need to log in before you can comment on or make changes to this bug.