Bug 1220258

Summary:	[RFE] Want option to force use of TLS version 1.1 _only_ subscription-manager
Product:	Red Hat Enterprise Linux 7	Reporter:	Paul Wayper <pwayper>
Component:	subscription-manager	Assignee:	candlepin-bugs
Status:	CLOSED WONTFIX	QA Contact:	John Sefler <jsefler>
Severity:	high	Docs Contact:
Priority:	high
Version:	7.2	CC:	alikins, cperry, jmolet, pgervase, pwayper
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-05-14 11:15:55 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:	1121117

Description Paul Wayper 2015-05-11 06:25:33 UTC

Description of problem:

Some proxies automatically terminate the connection when a TLSv1.0 connection is attempted.  This is due to the ability in the TLS protocol to downgrade TLS 1.0 connections to SSL 3.0, which is vulnerable to attack.

However, subscription-manager does not support any way of configuring which version of TLS it uses, and it uses only TLS 1.0.  Therefore it is immediately blocked at these proxies.

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

subscription-manager-1.13.22-1.el7.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Configure proxy to deny SSL 3.0 and below, and TLS version 1.0
2. Configure subscription-manager to use proxy.
3. Use subscription-manager to register machine to RHN or list available subscriptions.

Actual results:

# subscription-manager list --available --all
Server URL has an invalid scheme. http:// and https:// are supported

Expected results:

Subscription manager returns list of available subscriptions.

Comment 2 Paul Wayper 2015-05-11 06:50:10 UTC

OK, something's puzzling me here.  From the packet capture:

Secure Sockets Layer
    SSL Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 244
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 240
            Version: TLS 1.2 (0x0303)

So how do we have the SSL record with a version of TLS 1.0, and a handshake of a different protocol?  That's new to me.

To return to the point, the problem is that the proxy isn't allowing TLS 1.2:

curl -x proxy.com:8080 .... https://cdn.redhat.com/ --tlsv1.0  <== works
curl -x proxy.com:8080 .... https://cdn.redhat.com/ --tlsv1.1  <== works
curl -x proxy.com:8080 .... https://cdn.redhat.com/ --tlsv1.2  <== does not work
curl -x proxy.com:8080 .... https://cdn.redhat.com/ --tlsv1    <== does not work (as by default highest available selected)

(excellent work by Evgeny there).

What we'd like is the ability to select what version of TLS is used in subscription-manager, to work around this situation.

Hope this helps,

Paul

Comment 3 Adrian Likins 2015-05-11 15:49:55 UTC

TLS version is actually setup by python-rhsm. 

What version of python-rhsm is installed?

versions 1.13.6-1 and higher should mostly be deferring to openssl
system defaults for choosing TLS versions (and post-poodle versions
should default to TLS 1.2). It is specifying the ssl context of
'sslv23' (ala https://www.openssl.org/docs/ssl/SSL_CTX_new.html) but specifically disabling sslv2 and sslv3. 

iirc, correct behaviour there should be a TLSv1 client hello that indicates it can also support TLSv1.1 and TLSv1.2.

cdn.redhat.com does support TLSv1.2, so that seems correct.



Not sure I understand why the proxy would not allow TLSv1.2?  Afaik, that should be the default behaviour for openssl based clients now.

Comment 4 Adrian Likins 2015-05-11 15:55:21 UTC

This sounds a lot like https://bugzilla.redhat.com/show_bug.cgi?id=1039471

Is there a bluecoat or bluecoat like proxy involved?

Comment 8 Adrian Likins 2015-05-13 14:08:33 UTC

Also, note there are two sets of TLS connections involved in subscription-manager/cdn.


1) The connection used for the REST API at subscriptions.rhn.redhat.com/subscriptions. This is the connections used by
subscription-manager via python-rhsm, m2crypto, and openssl.


2) The connection used by yum to get content from cdn.redhat.com. That is
the connection described via the info in /etc/yum.repos.d/redhat.com, and established by yum (via urlgrabber->python-curl->libcurl->nss). 

It's not clear to me which connection this bug is referring too.

Is it the subman connection to subscriptions.rhn.redhat.com, or the yum connection to cdn.redhat.com ?

Comment 10 Adrian Likins 2015-05-13 20:25:01 UTC

Various workarounds:

1) exclude *.redhat.com from bluecoat inspection filters

2) provide a different proxy that does allow https and tlsv1.2 that subscription-manager and/or yum can be pointed at

3) provide a updated bluecoat proxy for use by subman, etc. 

4) change the client code in place or in custom packages. It's more or less a one line change, just one that is not applicable to everyone.

5) provide custom m2crypto or openssl packages that disable v1.2 connections. There isn't a global config/env option for this however.

6) downgrade to pre poodle rhsm/subman versions that would start negotiation at tlsv1

Comment 12 RHEL Program Management 2015-05-14 11:15:55 UTC

Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.