[SOLVED] Issues with Kubernetes IngressRoutes and TLSOption

Traefik Traefik v2
1

I am trying to remove some 112 bit ciphers from use for a particular IngressRoute. To that end I have created a TLSOption:

apiVersion: traefik.containo.us/v1alpha1
kind: TLSOption
metadata:
  name: tls-options
  namespace: default
spec:
  minVersion: VersionTLS12
  cipherSuites:
    - TLS_AES_128_GCM_SHA256
    - TLS_CHACHA20_POLY1305_SHA256
    - TLS_AES_256_GCM_SHA384
    - ECDHE-RSA-AES128-GCM-SHA256
    - ECDHE-RSA-AES256-GCM-SHA384
    - ECDHE-RSA-CHACHA20-POLY1305
    - ECDHE-RSA-AES128-SHA
    - ECDHE-RSA-AES256-SHA
    - AES128-GCM-SHA256
    - AES256-GCM-SHA384
    - AES128-SHA
    - AES256-SHA

I have applied this TLSOption to my IngressRoute:

---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: ig-name
  namespace: namespace-name
spec:
  entryPoints:
    - websecure
  routes:
  - match: Host(`sub.host.com`)
    kind: Rule
    services:
    - name: frontend
      port: 80
  tls:
    options:
      name: tls-options
      namespace: default

After I set this up I run sslscan on the url. What I'm seeing with this config is:

SSL/TLS Protocols:
SSLv2 disabled
SSLv3 disabled
TLSv1.0 enabled
TLSv1.1 enabled
TLSv1.2 enabled
TLSv1.3 enabled

TLS Fallback SCSV:
Server supports TLS Fallback SCSV

TLS renegotiation:
Secure session renegotiation supported

TLS Compression:
OpenSSL version does not support compression
Rebuild with zlib1g-dev package for zlib support

Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed
TLSv1.1 not vulnerable to heartbleed
TLSv1.0 not vulnerable to heartbleed

Supported Server Cipher(s):
Preferred TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519 DHE 253
Accepted TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519 DHE 253
Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve 25519 DHE 253
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253
Accepted TLSv1.2 256 bits AES256-GCM-SHA384
Accepted TLSv1.2 128 bits AES128-GCM-SHA256
Accepted TLSv1.2 256 bits AES256-SHA
Accepted TLSv1.2 128 bits AES128-SHA
Accepted TLSv1.2 112 bits TLS_RSA_WITH_3DES_EDE_CBC_SHA
Accepted TLSv1.2 112 bits TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
Preferred TLSv1.1 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253
Accepted TLSv1.1 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253
Accepted TLSv1.1 256 bits AES256-SHA
Accepted TLSv1.1 128 bits AES128-SHA
Accepted TLSv1.1 112 bits TLS_RSA_WITH_3DES_EDE_CBC_SHA
Accepted TLSv1.1 112 bits TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
Preferred TLSv1.0 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253
Accepted TLSv1.0 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253
Accepted TLSv1.0 256 bits AES256-SHA
Accepted TLSv1.0 128 bits AES128-SHA
Accepted TLSv1.0 112 bits TLS_RSA_WITH_3DES_EDE_CBC_SHA
Accepted TLSv1.0 112 bits TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

As you can see TLSV1.0 and TLSV1.1 are enabled even though I've specified a minimum version of TLSv1.2. If I remove the cipherSuites section from the TLSOption and re-create it. The minimum version of TLSV1.2 is respected:

SSL/TLS Protocols:
SSLv2 disabled
SSLv3 disabled
TLSv1.0 disabled
TLSv1.1 disabled
TLSv1.2 enabled
TLSv1.3 enabled

TLS Fallback SCSV:
Server supports TLS Fallback SCSV

TLS renegotiation:
Session renegotiation not supported

TLS Compression:
OpenSSL version does not support compression
Rebuild with zlib1g-dev package for zlib support

Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed

Supported Server Cipher(s):
Preferred TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519 DHE 253
Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve 25519 DHE 253
Accepted TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519 DHE 253
Preferred TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253
Accepted TLSv1.2 128 bits AES128-GCM-SHA256
Accepted TLSv1.2 256 bits AES256-GCM-SHA384
Accepted TLSv1.2 128 bits AES128-SHA
Accepted TLSv1.2 256 bits AES256-SHA
Accepted TLSv1.2 112 bits TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
Accepted TLSv1.2 112 bits TLS_RSA_WITH_3DES_EDE_CBC_SHA

Anyone have any ideas why trying to set the cipherSuites seems to break the TLSOption?
I'm running Traefik 2.1.6

2

The object TLSOptions that have been created contains invalid cipher suites and because of that it has not been applied to the IngressRoute you created.

Please verify the log file or have a look on the dashboard to see the information concerning invalid cipher suites.

Here is the list of supported cipher suits.

I suggest updating the TLSOptions object and update the list of cipher suites accordingly than your configuration will be respected by Traefik.

You can also set the argument preferServerCipherSuites: true as it is described here and let the server to choose the most preferred cipher suite instead of the client.

I hope that helps, let me know :wink:
Thank you,

3

Thanks for your reply.

I changed the listing of cipher suites based on the list of supported suites in the link you posted:

apiVersion: traefik.containo.us/v1alpha1
kind: TLSOption
metadata:
  name: tls-options
  namespace: default
spec:
  minVersion: VersionTLS12
  cipherSuites:
    - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
    - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
    - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Unfortunately, this still doesn't seem to be working as even with this config I'm still showing that TLSv1.0 and TLSv1.1 are enabled. I'm pretty confused here. I feel like my config is somehow invalid, but I can't see why.

4

I tried adding the cipher suites one at a time and it seems like the issue is with the CHACHA20 ciphers. Without those it seems to work. Not sure why.

5

Hey @tristan43

Your configuration seems to be correct. I've just applied that to one of my test environments and run SSLtest using sslabs.com against that. The results are the following:

TLS 1.3	Yes
TLS 1.2	Yes*
TLS 1.1	No
TLS 1.0	No*
SSL 3	No
SSL 2	No

I also used curl for testing the website. I forced the specific TLS version by adding the parameter to curl:

curl --tlsv1.1 --tls-max 1.1 ...

and I received the error message as it was expected.

curl: (35) error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol version

Can you please try to use curl with the specific TLS version?

I am not familiar with the tool (sslscan) you are using. However, your configuration seems to be correct.

Thank you,

6

Thanks for your help. For whatever reason leaving out the CHACHA20 ciphers results in a valid, working configuration.

7

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.