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 1220258 - [RFE] Want option to force use of TLS version 1.1 _only_ subscription-manager
Summary: [RFE] Want option to force use of TLS version 1.1 _only_ subscription-manager
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: subscription-manager
Version: 7.2
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: candlepin-bugs
QA Contact: John Sefler
URL:
Whiteboard:
Depends On:
Blocks: rhsm-rhel72
TreeView+ depends on / blocked
 
Reported: 2015-05-11 06:25 UTC by Paul Wayper
Modified: 2019-07-11 09:07 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-05-14 11:15:55 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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.
Note You need to log in before you can comment on or make changes to this bug.