Bug 1233122

Summary:	elinks sends SSLv2 style Hello
Product:	Red Hat Enterprise Linux 6	Reporter:	Filip Krska <fkrska>
Component:	nss_compat_ossl	Assignee:	Matthew Harmsen <mharmsen>
Status:	CLOSED CURRENTRELEASE	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	6.7	CC:	ekeck, fkrska, jherrman, jkurik, kdudka, ksrot, mhaicman, mharmsen, msaxena, nkinder, rcritten
Target Milestone:	rc	Keywords:	Patch, ZStream
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
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.	Story Points:	---
Clone Of:
Clones:	1252649 (view as bug list)		Environment:
Last Closed:	2016-09-14 13:13:49 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1002711, 1252649

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.