Bug 1746467 - The router in OCP4 accepts TLS1.0 and TLS1.1 connections with no way to disable them
Summary: The router in OCP4 accepts TLS1.0 and TLS1.1 connections with no way to disab...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.1.z
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.2.0
Assignee: Dan Mace
QA Contact: Hongan Li
URL:
Whiteboard:
Depends On:
Blocks: 1747461
TreeView+ depends on / blocked
 
Reported: 2019-08-28 14:21 UTC by Wesley Hearn
Modified: 2022-08-04 22:24 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1747461 (view as bug list)
Environment:
Last Closed: 2019-10-16 06:38:14 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift router pull 30 0 None closed Bug 1746467: Expose control of the tls settings via router ENV 2020-10-01 19:32:49 UTC
Red Hat Product Errata RHBA-2019:2922 0 None None None 2019-10-16 06:40:23 UTC

Description Wesley Hearn 2019-08-28 14:21:01 UTC
Description of problem:
The ingress application router has support for TLS1.1 and TLS1.0 enable with no way to disable them.

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

How reproducible:
Always

Steps to Reproduce:
1. Install 4.1 cluster
2. Wait for the web console to start up
3. Run the following commands
    openssl s_client -connect <web console route>:443 -tls1
    openssl s_client -connect <web console route>:443 -tls1_1

Actual results:
The connect with openssl s_client is accepted

Expected results:
The connection should not have been accepted

Additional info:
jira COMPLY-67

Comment 1 Bill Montgomery 2019-08-28 14:27:12 UTC
Clayton, Dan, Marc, Kirsten, this is the bug we discussed at NE planning this morning. Router accepts TLS1.0/1.1 and there's no way to turn it off.

Comment 3 Dan Mace 2019-08-28 17:57:59 UTC
Adding a way for the user to change it is an RFE and covered by our security API work.

Changing our current default is possible and sounds more bug-like (and perhaps justified by the fact that 1.0 and 1.1 are now excluded from Intermediate).

However, the fact remains that we shipped 1.0/1.1, and so we have to define the upgrade behavior. What would be the expected outcome of an upgrade, where existing ingress controllers currently accept 1.0 and 1.1?

Comment 4 Dan Mace 2019-08-29 14:20:33 UTC
Decision is that we will remove support for 1.0/1.1 from the default (intermediate) profile. The release note will loudly and clearly advertise the change.

Comment 6 Hongan Li 2019-09-03 02:55:20 UTC
Verified with 4.2.0-0.nightly-2019-09-02-172410 and issue has been fixed.
haproxy router image: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:b10ec8e2828db02fd8bcb1704a071afce7d35e7a9415a4d227cd0c645eeb8cac

$ openssl s_client -connect console-openshift-console.apps.hongli-2410.qe.xxx.com:443 -tls1
CONNECTED(00000003)
139728506337088:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:1535:SSL alert number 70
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 183 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1


$ openssl s_client -connect console-openshift-console.apps.hongli-2410.qe.xxx.com:443 -tls1_1
CONNECTED(00000003)
140450446374720:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:1535:SSL alert number 70
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 183 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.1

Comment 7 errata-xmlrpc 2019-10-16 06:38:14 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2922


Note You need to log in before you can comment on or make changes to this bug.