Bug 1778856

https://docs.openshift.com/container-platform/3.11/architecture/networking/routes.html#env-variables the way to configure TLS settings is via router environment variables: https://docs.openshift.com/container-platform/3.11/architecture/networking/routes.html#env-variables

For TLS, I believe the salient one is this:

ROUTER_CIPHERS  intermediate  Specify the set of ciphers supported by bind

Where "intermediate" means https://wiki.mozilla.org/Security/Server_Side_TLS

"Intermediate compatibility (recommended)For services that don't need compatibility with legacy clients, such as Windows XP or old versions of OpenSSL. This is the recommended configuration for the vast majority of services, as it is highly secure and compatible with nearly every client released in the last five (or more) years.

    Cipher suites (TLS 1.3): TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
    Cipher suites (TLS 1.2): ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
    Protocols: TLS 1.2, TLS 1.3
    TLS curves: X25519, prime256v1, secp384r1
    Certificate type: ECDSA (P-256) (recommended), or RSA (2048 bits)
    DH parameter size: 2048 (ffdhe2048, RFC 7919)
    HSTS: max-age=63072000 (two years)
    Maximum certificate lifespan: 90 days (recommended) to 2 years
    Cipher preference: client chooses

So, according to this, port 443 should only respond to TLS 1.2 or later.


However, I am still able to use tls 1.1:

> openssl s_client -connect kibana.origin311.logging.test:443 -tls1_1

CONNECTED(00000003)
depth=1 CN = openshift-signer@1561772088
...
New, TLSv1.0, Cipher is ECDHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : ECDHE-RSA-AES128-SHA

Workaround is to use a custom router template.

(In reply to Dan Mace from comment #2)
> Workaround is to use a custom router template.

By this do you mean provide an explicit list of supported and/or unsupported cipher suites in the ROUTER_CIPHERS env. var.?

(In reply to Rich Megginson from comment #3)
> (In reply to Dan Mace from comment #2)
> > Workaround is to use a custom router template.
> 
> By this do you mean provide an explicit list of supported and/or unsupported
> cipher suites in the ROUTER_CIPHERS env. var.?

Unfortunately, there is no such environment variable configuration for TLS in 3.11. Support was introduced in https://github.com/openshift/router/pull/35 to enable the v4 TLS API. What I mean is that in 3.11, the user can specify a custom haproxy config template and configure the min/max version manually, e.g.

    ssl-default-bind-options ssl-min-ver TLSv1.2

Can you please provide documentation on how to achieve this for 3.11?

Verified with atomic-openshift-3.11.187-1.git.0.be0cfd4.el7 and the issue has been fixed.

# oc set env dc/router SSL_MIN_VERSION=TLSv1.2 SSL_MAX_VERSION=TLSv1.3
# oc exec router-7-kb5vz -- grep ssl-min-ver haproxy.config
  ssl-default-bind-options ssl-min-ver TLSv1.2 ssl-max-ver TLSv1.3

# curl https://console.apps.0312-icn.qe.rhcloud.com -k -I --tlsv1.1
curl: (35) Peer reports incompatible or unsupported protocol version.
# curl https://console.apps.0312-icn.qe.rhcloud.com -k -I --tlsv1.2
HTTP/1.1 200 OK

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-2020:0793