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.
Bug 1233122 - elinks sends SSLv2 style Hello
Summary: elinks sends SSLv2 style Hello
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nss_compat_ossl
Version: 6.7
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Matthew Harmsen
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 1002711 1252649
TreeView+ depends on / blocked
 
Reported: 2015-06-18 09:26 UTC by Filip Krska
Modified: 2019-08-15 04:44 UTC (History)
11 users (show)

Fixed In Version: nss_compat_ossl-0.9.6-2.el6
Doc Type: Bug Fix
Doc Text:
When establishing a secure connection, the nss_compat_ossl service previously requested the Network Security Services (NSS) library to initiate an SSL 2.0 handshake with the remote server. However, because NSS no longer supports the SSL 2.0 protocol, the handshake failed. With this update, nss_compat_ossl no longer uses SSL 2.0, and secure connections can be properly established using SSL 3.0, TLS 1.0, or their later versions.
Clone Of:
: 1252649 (view as bug list)
Environment:
Last Closed: 2016-09-14 13:13:49 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Filip Krska 2015-06-18 09:26:48 UTC 
Description of problem:

In case of https connection elinks sends packet

SSLv2 Record Layer: Client Hello

This drives elinks unusable with services secured to refuse vulnerable SSLv[23] protocols which is current recommended setup.

Version-Release number of selected component (if applicable):

elinks-0.12-0.21.pre5.el6_3.x86_64

How reproducible:

Always

Steps to Reproduce:
1. setup a service refusing SSLv[23] protocols, e.g. tomcat according to our recommendation https://access.redhat.com/solutions/1232233

2. links https://server:port


Actual results:

links sends

SSLv2	Client Hello

service refuses to handshake e.g. with

TLSv1	Alert (Level: Fatal, Description: Handshake Failure)


Expected results:

links sends (like e.g. wget does)

TLSv1.2	Client Hello

service continues with handshake

TLSv1.2	Server Hello, Certificate, Server Key Exchange, Server Hello Done

...

Additional info:
Comment 2 Kamil Dudka 2015-06-18 12:47:24 UTC 
TLS in RHEL-6 elinks is provided by nss_compat_ossl, which has no API to fine configure this.  I see basically 2 options to fix this in the elinks package:

1. Use TLSv1_client_method() instead of SSLv23_client_method() to initialize the TLS context.  This would enable TLS 1.0 only with the current version of RHEL-6 nss.

2. Bypass nss_compat_ossl and enabled/disable the requested TLS versions directly in elinks.  This would be a dirty hack, which can interfere with future updates of nss_compat_ossl.

In any case, elinks currently provides no option to configure the TLS version.  Unconditionally changing the TLS version could break existing scenarios that rely on the support of SSLv3.  We should probably introduce a new option to restore the old behavior after the update to cover these cases.

Do we actually need to disable SSLv3?

If this request is only about SSLv2 Hello, we can just switch the component to nss_compat_ossl, where the following patch needs to be applied:

    attachment #897966 [details]
Comment 6 Kamil Dudka 2015-06-22 14:25:30 UTC 
Thank you for giving it a try, Filip!

I am switching the component to nss_compat_ossl...
Comment 25 Marcel Kolaja 2016-09-14 13:13:49 UTC 
The fix for this bug has been delivered in RHEL 6.7.z and this component has not been updated in RHEL 6.8. RHEL 6.8 contains the fix from RHEL 6.7.z. Therefore, this bug has been closed as CURRENTRELEASE.
Note You need to log in before you can comment on or make changes to this bug.