Hi all,

Dave, thank you for proposing this feature, I truly think that being
able to serve RSA or ECDSA certificates depending on what the client
supports would be an awesome addition to HAproxy.

However, I have some concerns about the use of
SSL_set_session_secret_cb() for this feature, because it was clearly not
designed for this kind of manipulation. It has been removed from
BoringSSL [1] and simply enabling this callback in OpenSSL, regardless
of what is done in the callback itself, disables TLS session ticket
(rfc5077) [2], which I believe is an issue.
It also means that you have to use flags that are internals to OpenSSL,
and may change in the future. Note that this could probably be avoided
in 1.0.2+ with the use of ssl_cipher_get_cert_index().
Lastly, switching the SSL_CTX based only on the suites sent by the
client in ClientHello means that you effectively bypass the suites
preference set on HAproxy, if any. If the first suite sent by the client
requires an ECDSA certificate, you will switch to a SSL_CTX supporting
only ECDSA suites, even if the server preferences prefer some suites
using RSA better than ECDSA ones. This is quite a change from the
HAproxy default, which is to take into account the server preferences
first [3].

IMHO, I would tend to prefer letting OpenSSL handle both the RSA and
ECDSA pairs in the same SSL_CTX. It could probably be done when a new
certificate is loaded by looking up in the existing certificates list if
there is already is one with the same subject name / SAN and a different
key type, and merging it to the existing SSL_CTX if it does.
I do realize that it would only work with 1.0.2+ because of the
inability of previous OpenSSL version of supporting more than one chain
in a given SSL_CTX, though.

Just my two cents :)

[1]
https://boringssl.googlesource.com/boringssl/+/d1681e614f8c3b4105efc42fb1fd35bd3ec09547%5E!/
[2] see tls1_process_ticket(), in ssl/t1_lib.c
[3] the default ssloptions contains SSL_OP_CIPHER_SERVER_PREFERENCE, in
ssl_sock_prepare_ctx(), src/ssl_sock.c


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to