Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
(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 3Bohuslav "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 4Bohuslav "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.
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.