Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1746467

Summary: The router in OCP4 accepts TLS1.0 and TLS1.1 connections with no way to disable them
Product: OpenShift Container Platform Reporter: Wesley Hearn <whearn>
Component: NetworkingAssignee: Dan Mace <dmace>
Networking sub component: router QA Contact: Hongan Li <hongli>
Status: CLOSED ERRATA Docs Contact:
Severity: high    
Priority: high CC: aos-bugs, bbennett, bmontgom, ccoleman, dmace, knewcome, mcurry
Version: 4.1.zKeywords: NeedsTestCase
Target Milestone: ---   
Target Release: 4.2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1747461 (view as bug list) Environment:
Last Closed: 2019-10-16 06:38:14 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: 1747461    

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