KEDA should use TLS12 or above as minimum TLS version

[JorTurFer]

Report

Current, KEDA allows all TLS versions

Expected Behavior

Not allowed broken TLS versions

Actual Behavior

allowed broken TLS versions

[rmrfroot]

And limit TLS 1.2 cipher suites plz:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305

[JorTurFer]

And limit TLS 1.2 cipher suites plz:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305

Why is this required? Is anyone broken? (I have no idea)

[rmrfroot]

Why is this required? Is anyone broken? (I have no idea)

64-bit block cipher 3DES vulnerable to SWEET32 attack
To support only secure cipher suites.
https://ssl-config.mozilla.org/#server=traefik&version=2.1.2&config=intermediate&guideline=5.6

[JorTurFer]

Can this be solved using TLS 1.3 as default? Supporting cipher suites could be more complex as it isn't a single value

[rmrfroot]

If use only TLS 1.3 - of course. But all clients should also support it.

[JorTurFer]

If use only TLS 1.3 - of course. But all clients should also support it.

I guess we can do it as we don't receive request due to we don't have clients. The only requests we receive are from k8s api-server (which AFAIK supports it) and our own requests between components (which already use TLS1.3).
We are the clients of the upstreams, and I guess (better, I hope) that they support TLS1.3

Also taking this into account, maybe TLS1.2 could also be enough as we will use it only as clients, couldn't?
WDYT @zroubalik ?

[rmrfroot]

The only requests we receive are from k8s api-server (which AFAIK supports it) and our own requests between components (which already use TLS1.3).

Looks great!

[zroubalik]

I am not sure if this not gonna affect scalers (in case they are using TLS for the connection). Might be safer to default on 1.2 here. Though I'd love to see 1.3 as default here. I don't have much knowledge in this area so I wonder what is the standard in opensource projects are k8s these days? 1.2 or 1.3? @rmrfroot by chance, do you know any details?

[JorTurFer]

BTW @rmrfroot , are you willing to contribute with the cipher suite improvements? We can create another issue to track those changes once the default version is merged.

[rmrfroot]

@zroubalik @JorTurFer Found this issue after one of my prod infrastructures with keda installed didn't pass security scans as a preparation to PCI DSS audit. So had to remove it. I'd really want to contribute if I had more experience in Go and more free time. But I can try to help.

[JorTurFer]

Found this issue after one of my prod infrastructures with keda installed didn't pass security scans as a preparation to PCI DSS audit. So had to remove it

With this PR, TLS1.2 will be the default minTLSVersion, but you could set to 1.3 just adding the environment variable if you need it to pass you audit. Could this be enough for your use case?

[rmrfroot]

@JorTurFer yes, this is a nice solution. So that we can test before breaking anything. Thanks!

[davidlanouette]

And limit TLS 1.2 cipher suites plz:
...

By default, Go only supports a limited set of "safe" cipher suites for TLSv1.2

Here is the list of CipherSuites that are supported by default (if you don't specify which CipherSuites to support) for TLSv1.2) It changes regularly as vulnerabilities are found.

I would suggest you don't specify a list of suites because then you are in the business of knowing which ones have been exploited, and maintaining that list. Let Google do that work for you - they are more likely to "get it right", and keep it up to date.

Setting the min version of TLS should be all you need to do.

[JorTurFer]

Wow,
Thanks a ton @davidlanouette for the awesome clarification 🙇