Bug 1385158

Summary:	SSL/TLS requires its own separate method to limit the version
Product:	OpenShift Container Platform	Reporter:	Eric Jones <erjones>
Component:	Networking	Assignee:	Miciah Dashiel Butler Masters <mmasters>
Networking sub component:	router	QA Contact:	zhaozhanqi <zzhao>
Status:	CLOSED EOL	Docs Contact:
Severity:	urgent
Priority:	urgent	CC:	abhgupta, aos-bugs, erjones, rthrashe
Version:	2.2.0
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-01-13 21:53:46 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:

Description Eric Jones 2016-10-14 20:29:31 UTC

Description of problem:
Looking at the code for SSL options, we have found that the only place that would make sense is in the cipher section of the code [0] for the web-proxy. But looking at the nodejs site [1] we see that SSL and TLS have their own method to limit the version used (secureProtocol) which would look something like "SSLv3_method" to force SSL version 3.

Looking at the commit [2] that added the cipher list, we can also see that it removed this SSLv#_method from the code.

This limits the version that can be limited and forces the cipher list to be the only variation possible.

[0] https://github.com/openshift/origin-server/blob/master/node-proxy/lib/utils/http-utils.js#L30-L42
[1] https://nodejs.org/api/tls.html#tls_tls_createserver_options_secureconnectionlistener
[2] https://github.com/openshift/origin-server/commit/7dec6165f2e8d3ac3c7bf3b8b5dfaf7adfc7aa6e#commitcomment-19434073

Comment 3 Miciah Dashiel Butler Masters 2016-11-01 16:49:48 UTC

Are you saying that the sysadmin wants to change the list of ciphers accepted for WebSocket connections (which are handled by node-proxy)? The commit you reference changed node-proxy to set a default list of ciphers that excludes some weak ciphers.  This list can be overridden by specifying it in web-proxy-config.json.  The commit also marked web-proxy-config.json as a configuration file so that sysadmins can modify the file, and RPM will leave those modifications in place.

Comment 4 Eric Jones 2016-11-01 17:32:47 UTC

Miciah, we found that commit because the sysadmin needs to limit the version of TLS they are using within OpenShift (specifically using TLSv1.1 or 1.2) and after looking around, the only way we found to do that was to set the SSLv#_method that was explained in the second link. But we could not figure out how to use that with the cipher list. 

Are we going about this incorrectly? Do we need to use a different method? Is there a way to use the cipher list and we simply missed it?

Comment 5 Rory Thrasher 2016-11-04 23:18:48 UTC

Eric,

We disable SSLv3 (and backwards) here: https://github.com/openshift/origin-server/blob/master/node-proxy/lib/utils/http-utils.js#L32

The SSLv23_method that was removed is the default (which is why it was removed, just cleaning up code when we had a change in that area).  So it still starts at TLSv1.2 and then works its way backwards if the client doesn't support that.  It stops at SSLv3 since we have disabled it.

We DO allow TLSv1.0.  We can disable it by changing the secureOptions to  constants.SSL_OP_NO_TLSv1|constants.SSL_OP_NO_SSLv3 - however that isn't a configuration option to my knowledge.

What is the customer's use case?  Do they simply want to disable TLSv1.0?

Comment 6 Eric Jones 2016-11-11 14:29:48 UTC

My apologies for the delay.

A quote from the customer when they started the case:
RC4 should not be used where possible. One reason that RC4 was still being used was BEAST and Lucky13 attacks against CBC mode ciphers in SSL and TLS. However, TLSv 1.2 or later address these issues.

They mention RC4 because they started off the case looking to disable that and then realized it was using TLSv1.0. So it is for security reasons that they look for TLSv1.1+

Comment 7 Rory Thrasher 2016-11-11 20:54:05 UTC

RC4 is disabled with our default cipher list.

BEAST is mostly irrelevant now.  It is client-side and most (if not all) major browsers have implemented fixes.  See articles like https://blog.qualys.com/ssllabs/2013/09/10/is-beast-still-a-threat for more information.

Lucky13 was patched in openSSL.


If there are concerns about specific vulnerabilities from the customer, we can look into them and come back with more information about what we've done to mitigate those issues.  We can look into adding an option to disable TSLv1.0 if its really a priority for the customer - however we would prefer to put resources elsewhere if the specific security concerns have already been addressed.  Disabling TLSv1.0 will also remove compatibility with a large number of web clients who don't support TLSv1.2 - which was rather disruptive when we tried it.

Comment 8 Rory Thrasher 2017-01-13 21:53:46 UTC

OpenShift Enterprise v2 has officially reached EoL.  This product is no longer supported and bugs will be closed.

Please look into the replacement enterprise-grade container option, OpenShift Container Platform v3.  https://www.openshift.com/container-platform/

More information can be found here: https://access.redhat.com/support/policy/updates/openshift/