[openssl-users] renegotiation expected to fail when trust configuration has changed.
Matt Caswell
matt at openssl.org
Thu Nov 22 17:45:16 UTC 2018
On 22/11/2018 15:58, Pfluegl, Andreas wrote:
>
> I expect server_parse_cb() returning 0 to cause the interruption of the connection.
>
> Can you confirm this?
Yes. According to the docs:
"If the B<parse_cb> considers the extension data acceptable it must return 1. If
it returns 0 or a negative value a fatal handshake error occurs using the TLS
alert value specified in B<*al>."
https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_add_server_custom_ext.html
>
> Here I am missing server_parse_cb() (see Server trace scenario 1)
When a client receives a HelloRequest message it will send a new ClientHello and
attempt to resume the connection. The attempt at resumption does not occur when
a reneg is initiated from the client side unless you call
SSL_renegotiate_abbreviated() instead of SSL_renegotiate().
If the attempt at resumption is successful then custom extension parsing does
not get invoked on the server side. This is by design:
https://github.com/openssl/openssl/blob/0fbe8491fc05d280a1f00bfc26dd3c3a6c63f04a/ssl/t1_lib.c#L2314-L2325
Unfortunately the docs in 1.1.0 are a bit lacking on this point. They have been
significantly revised and updated in 1.1.1 and hopefully this is a little more
obvious. In particular note that the 1.1.1 flag SSL_EXT_IGNORE_ON_RESUMPTION is
automatically set when calling SSL_CTX_add_server_custom_ext(). This is so that
the behaviour is backwards compatible with 1.1.0:
https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_add_custom_ext.html
In 1.1.1 we have the new function SSL_CTX_add_custom_ext() which (among other
things) allows you to control whether the callback is called during resumption
or not. See the doc link above.
So, in order to solve your problem, I see 2 possible solutions:
1) Upgrade to 1.1.1 and use the new SSL_CTX_add_custom_ext() API.
or
2) Invalidate any sessions in the session cache for old connections that were
established using the old certificate. You'll need to some additional custom
code to track that I imagine. You'll also need to avoid session tickets for that
to work.
Probably the upgrade to 1.1.1 is your best bet since 1.1.0 is only supported
until September 2019 anyway.
Matt
More information about the openssl-users
mailing list