Smart proxy cipher setting for TLS 1.3 on machines with Ruby < 3.2

Development
1

There is currently a PR open https://github.com/theforeman/smart-proxy/pull/947 that has the following security flaw:

A user can set :ciphers in proxy settings.yml, specifying an allowlist of ciphers that the proxy can use.

Setting ciphers can be done using SSL_CTX_set_cipher_list() method. This limits ciphers to only those specified.

However, that method only limits ciphers for TLS 1.2. For TLS 1.3, there is another method SSL_CTX_set_ciphersuites() that, in turn, only works for TLS 1.3.

Ruby’s openssl only knows this method in versions 3.2+, or on RHEL builds in RHEL 3.0+. The only version of Debian that we currently support, 12, has Ruby < 3.2.

That means any ciphers that user specifies can only be applied to TLS 1.2 and TLS 1.3 will use all available ciphers, even those not on the allowlist.

I think this is a serious security flaw. If a user lists a set of ciphers we are allowed to use, we can’t just take that list and append all existing TLS 1.3 ciphers to it and use that.

We may merge that PR but before release, we really should decide what to do with it. We’ve discussed three options:

  1. fail proxy start with an explanation that we are not able to fulfill this - setting ciphers in settings on a machine without the method available is just illegal

  2. disable TLS 1.3 entirely on machines without the method because we are not able to limit its ciphers in any way. Because when a user explicitly or implicitly (no setting tls_min present) allows TLS 1.3, and at the same time specifies ciphers, we need to only allow those ciphers; not those ciphers + any TLS 1.3 cipher (example: if a user doesn’t specify TLS version but only allows cipher_that_is_only_in_tls12, it means that we should only allow cipher_that_is_only_in_tls12 and not also cipher_that_is_only_in_tls13_a and cipher_that_is_only_in_tls13_b, thus we need to disable TLS 1.3 entirely) => note that this means Debian 12 can’t ever have TLS 1.3 if the user specified ciphers with any value

  3. the way it is now which doesn’t set any ciphersuites for TLS 1.3, effectively allowing any TLS 1.3 cipher even though user specified just some or not any at all => I think this would be a very bad security choice worth filing a CVE the minute we release it

2

And I see I forgot the question, but it’s straightforward: does anyone have any opinions on this? Which option? Or an entirely new option?

3

I’ll admit up front I got lost in the details. However, I think from what I could glean my opinion would be:

If a user configures a combination of cipher suites and TLS versions that are incompatible, the application should fail to start with an obvious error message, and ideally a pointer to help them resolve things.

As I believe you are calling out, thinking you are running in a particular mode when you are not actually is a potential major security issue for a user.

1 Like