certificate selection based on supported groups/curves in TLS 1.2

[jmayclin]

Problem:

S2N doesn't seem to consider a client's supported_groups when choosing a certificate.

Given an openssl client that only supports the P-384 group and an s2n_server that has an RSA and an ECDSA:P-256 cert configured, the s2n-server should prefer to send the RSA cert since the client has indicated that they don't support P-256.

Reproduction Steps First, run the generate_certs.sh command from the bench directory.

Then the handshake failure can be observer by running s2nd with an RSA and ECDSA:P-256 cert.

./build/bin/s2nd localhost 9000 --ciphers default_tls13 --cert bindings/rust/bench/certs/rsa2048/server-cert.pem --key bindings/rust/bench/certs/rsa2048/server-key.pem --cert bindings/rust/bench/certs/ecdsa256/server-cert.pem --key bindings/rust/bench/certs/ecdsa256/server-key.pem

openssl s_client -connect localhost:9000 -tls1_2 -groups P-384

If only an RSA cert is configured, then the handshake succeeds.

./build/bin/s2nd localhost 9000 --ciphers default_tls13 --cert bindings/rust/bench/certs/rsa2048/server-cert.pem --key bindings/rust/bench/certs/rsa2048/server-key.pem

openssl s_client -connect localhost:9000 -tls1_2 -groups P-384

Solution:

My understanding is that the supported_groups extension is sent as part of the client hello, so the server should be able to choose a certificate based on the supported_groups extension.

[jmayclin]

I was trying to see if we had any integration tests for this case, but it looks like we had previously run into a potentially related problem and documented it here: #2130

[jmayclin]

As far as I can tell we don't have integration tests for this case. As a general rule our integration tests do not load multiple certificates, with the exception of test_sni_match.py, but that test uses very permissive clients and as such did not catch this issue.

[csosto-pk]

Could this be because the second argument in s2nd overrides the RSA passed first?