When negotiating TLS 1.3, AWS-LC always prefer client ciphers order

[dclaisse]

Problem:

When negotiating TLS <= 1.2, there is an option to prefer server ciphers order (SSL_OP_CIPHER_SERVER_PREFERENCE).

But when negotiating TLS1.3, a separate code path is used, and AWS-LC always prefer client ciphers order. Indeed, in ssl_choose_tls13_cipher (see https://github.com/aws/aws-lc/blob/main/ssl/s3_both.cc#L688), iteration is done on client ciphers, and first one being also present in server ciphers will be selected, regardless of SSL_OP_CIPHER_SERVER_PREFERENCE being set or not. There is also a mechanism to avoid AES ciphers if there is no hardware support for it, but it is not relevant here.

This makes AWS-LC's behavior not consistent, and one could expect that SSL_OP_CIPHER_SERVER_PREFERENCE is respected regardless of protocol version.

As an example, see here a user report here that illustrate the issue when using HAProxy: haproxy/haproxy#3024.
The user there tests their setup using testssl.sh and gets the following result: Has server cipher order? yes (OK) -- only for < TLS 1.3

Solution:

SSL_OP_CIPHER_SERVER_PREFERENCE should be used in ssl_choose_tls13_cipher to decide whether iteration is done on client or server cipher list, in order to prefer server ciphers if set.

Requirements / Acceptance Criteria:

Negotiation should be consistent in both TLS 1.3 and TLS 1.2, and server ciphers should be preferred if SSL_OP_CIPHER_SERVER_PREFERENCE is set, also for TLS 1.3.

• Testing: How will this change be tested? Some test should be added, checking cipher selection preference for TLS 1.3.

[justsmth]

Hello! Thanks for raising this issue.

I'll need to ask around internally about the motivations for our current mechanism for cipher selection in TLS 1.3. We will follow up here.

[torben-hansen]

As you describe, the behaviour depends on the TLS version negotiated. Generally, the method used to compute the negotiated cipher suite is different between TLS 1.3 and older TLS versions. As you surface, the former is implemented in ssl_choose_tls13_cipher() and always uses an equal-preference group algorithm that prefers the server in the sense of an ordering that depends on whether AES CPU instructions are available at run-time or not. This has been the behaviour since the AWS-LC project was created as a fork of BoringSSL.

I agree that it's not very transparent if you want to assert strong controls over the server behaviour and there is some lagging configuration options. I took a first small step to at least correctly document the behaviour: #2814. Also wrote down a bit more thinking in the PR about what's next.