Hi, > I was unaware that BoringSSL removed the callback, but in that case, could > we limit this feature to only OpenSSL? I¹m also not seeing how using this > callback prevents rfc5077, could you please elaborate.
Yes, sorry, I didn't realize it earlier but that's not true for all
OpenSSL versions. Starting with OpenSSL 1.0.0, tls1_process_ticket()
will decline decrypting session tickets sent by the client if the
session_secret_cb is in use:
if (s->tls_session_secret_cb)
{
/* Indicate cache miss here and instead
of
* generating the session from ticket
now,
* trigger abbreviated handshake based
on
* external mechanism to calculate the
master
* secret later. */
return 0;
}
There is even a nice comment about it, starting from 1.0.1 I believe:
* If s->tls_session_secret_cb is set then we are expecting a pre-shared
key
* ciphersuite, in which case we have no use for session tickets and one
will
* never be decrypted, nor will s->tlsext_ticket_expected be set to 1.
> I see that now. But in the current implementation, doesn¹t it always just
> use the default CTX if the client doesn¹t specify SNI? In that case, you¹d
> still be limited to the signature algorithm of the default CTX. It¹s
> possible to take the server preferences in mind. However, wouldn¹t that
> lead to a situation where the server wants to use Signature Algorithm A,
> but the client only supports B, and then the client can¹t connect?
Yes, of course, but remember that the client sends not one choice but an
ordered list of ciphersuites he is willing to use. If none of these is
accepted by the server, the connection will fail, true, but in practice
it seldom happens.
> In my mind, choosing the signature algorithm based on what the client
> supports is a good idea as it guarantees that the client can use that
> algorithm. Then, the server can use w/e cipher suite it wants in terms of
> Key-Exchange and symmetric-encryption.
Yes, choosing a common suite supported by both side is a necessity. But
when there is more than one common suite, which happens most of the
time, you can either follow the client's preference or the server one.
Right now, it seems that we have a consensus to follow the server's
choice (see ssl_prefer_server_ciphers on for nginx, SSLHonorCipherOrder
on for Apache HTTPd, ..) and I believe we should continue to do that in
HAproxy because legacy clients have a long history of choosing crappy
ciphersuite (look at the recent export fiascos, for example).
> Tying this feature into 1.0.2 would definitely make it easier, I agree. It
> just will hinder adoption.
That's true, but I am afraid doing otherwise would require adding a
complex logic in the TLS stack of HAproxy, so sadly I am more enclined
to require 1.0.2 for people willing to use this feature.
signature.asc
Description: OpenPGP digital signature
