TLS Ciphers are breaking in FIPS Mode

Summary

When Pages is running in FIPS mode, some ciphers do not work.

Steps to reproduce

Follow steps in #718 (comment 904531139)

It also has the list of which ciphers do not work in FIPS mode.

What is the current bug behavior?

All the ciphers mentioned below work when Pages is running as part of GDK but do not work when Pages is hosted on a FIPS enabled RHEL server

`TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305` and `TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305`

These are TLS 1.2 ciphers. By default the curl connection goes for TLS1.3 connection unless explicitly specified using --tlsv1.2 --tls-max 1.2

Logs when Pages is running in GDK and explicit TLS versions not specified in curl

$ curl https://127.0.0.1:3012 -H 'Host: t1.vishaltak.com' --verbose --insecure --cipher ECDHE-RSA-CHACHA20-POLY1305
*   Trying 127.0.0.1:3012...
* Connected to 127.0.0.1 (127.0.0.1) port 3012 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ECDHE-RSA-CHACHA20-POLY1305
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=IN; ST=MH; L=Mumbai; O=GitLab; OU=Create; CN=pages.gdk.test; emailAddress=vtak@gitlab.com
*  start date: Apr  7 10:38:07 2022 GMT
*  expire date: Apr  7 10:38:07 2023 GMT
*  issuer: C=IN; ST=MH; L=Mumbai; O=GitLab; OU=Create; CN=pages.gdk.test; emailAddress=vtak@gitlab.com
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x12100e600)
> GET / HTTP/2
> Host: t1.vishaltak.com
> user-agent: curl/7.79.1
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
< HTTP/2 200
< cache-control: max-age=600
< content-type: text/html; charset=utf-8
< etag: "7918027bec724fb2a62bcc049eef34f25848f0d4e0aaa5955107e3fb87859dba"
< expires: Fri, 08 Apr 2022 09:03:39 UTC
< last-modified: Tue, 22 Mar 2022 14:11:29 GMT
< vary: Origin
< content-length: 632
< date: Fri, 08 Apr 2022 08:53:39 GMT
...

Logs when Pages is running in FIPS RHEL

Curl logs

$ curl https://127.0.0.1:3012 -H 'Host: t1.vishaltak.com' --verbose --insecure --cipher ECDHE-ECDSA-CHACHA20-POLY1305 --tlsv1.2 --tls-max 1.2
*   Trying 127.0.0.1:3012...
* Connected to 127.0.0.1 (127.0.0.1) port 3012 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ECDHE-ECDSA-CHACHA20-POLY1305
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* error:1404B410:SSL routines:ST_CONNECT:sslv3 alert handshake failure
* Closing connection 0
curl: (35) error:1404B410:SSL routines:ST_CONNECT:sslv3 alert handshake failure

Pages Server logs

{"level":"info","msg":"http: TLS handshake error from 127.0.0.1:34048: tls: no cipher suite supported by both client and server","time":"2022-04-08T09:10:37Z"}

`TLS_AES_128_GCM_SHA256` , `TLS_AES_256_GCM_SHA384` and `TLS_CHACHA20_POLY1305_SHA256`

These are TLS v1.3 ciphers.

Curl logs

$ curl https://127.0.0.1:3012 -H 'Host: t1.vishaltak.com' --verbose --insecure  --tls13-ciphers TLS_AES_128_GCM_SHA256 --tlsv1.3
*   Trying 127.0.0.1:3012...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 3012 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLS 1.3 cipher selection: TLS_AES_128_GCM_SHA256
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, protocol version (582):
* error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version
* Closing connection 0
curl: (35) error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version

Pages server logs

{"level":"info","msg":"http: TLS handshake error from 127.0.0.1:34066: tls: client offered only unsupported versions: [304]","time":"2022-04-08T09:15:42Z"}

What is the expected correct behavior?

The HTML should be served while respecting the TLS version and the cipher

Comments

I think, for TLS 1.2, ciphers ECDHE-RSA-CHACHA20-POLY1305 and ECDHE-ECDSA-CHACHA20-POLY1305 are not supported in FIPS mode

Reason

$ openssl ciphers -v -stdname  | grep TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305    # when run of RHEL FIPS machine, gives empty result
$ openssl ciphers -v -stdname  | grep TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305  # when run of RHEL FIPS machine, gives empty result

I think TLS v1.3 is not supported in FIPS mode and that is why the Pages server logs tls: client offered only unsupported versions: [304] . 304 refers to TLS v1.3 as can be seen here .

However, out of the 3 TLSv.13 ciphers mentioned above, the first two can be seen as available in FIPS RHEL OpenSSL.

$ openssl ciphers -v -stdname -s -tls1_3         # when run of RHEL FIPS machine
TLS_AES_256_GCM_SHA384 - TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_AES_128_GCM_SHA256 - TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
TLS_AES_128_CCM_SHA256 - TLS_AES_128_CCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESCCM(128) Mac=AEAD

TLS_CHACHA20_POLY1305_SHA256 is not available in the list

OpenSSL Version Details

Local Mac - LibreSSL 2.8.3
GDK (Ubuntu) - OpenSSL 1.1.1f 31 Mar 2020
FIPS Pages(RHEL) - OpenSSL 1.1.1k FIPS 25 Mar 2021

If you are using Mac, you would want to spin up some server(Ubuntu) which has openssl installed or install a separate openssl on Mac. The default openssl installed in Mac does have TLS v1.3 ciphers available for some reason.

Note

While testing this, I've generated certificates for the pages domain (pages.gdk.test) and not for the custom domain (t1.vishaltak.com) .

Edited Apr 08, 2022 by Vishal Tak