[PATCH] SSL: SSL_CTX_set_tlsext_ticket_key_cb() deprecated in OpenSSL 3.0

Sergey Kandaurov pluknet at nginx.com
Thu Dec 15 12:47:36 UTC 2022


> On 15 Dec 2022, at 08:25, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> Hello!
> 
> On Thu, Dec 15, 2022 at 06:13:41AM +0400, Sergey Kandaurov wrote:
> 
>> # HG changeset patch
>> # User Sergey Kandaurov <pluknet at nginx.com>
>> # Date 1671069897 -14400
>> #      Thu Dec 15 06:04:57 2022 +0400
>> # Node ID 8fbae86083f2efda8b4e079b3bda148dec220323
>> # Parent  c38588d8376b77fc2f56f90ca16533031b235491
>> SSL: SSL_CTX_set_tlsext_ticket_key_cb() deprecated in OpenSSL 3.0.
>> 
>> It becomes hidden when OpenSSL is built with OPENSSL_NO_DEPRECATED.
>> While this is manageable for the ssl_session_ticket_key directive,
>> rotation of ticket keys stored in shared memory is silently disabled.
>> 
>> Switch to SSL_CTX_set_tlsext_ticket_key_evp_cb() whenever available.
>> A macro similar to SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB isn't provided,
>> so the feature test uses OSSL_PARAM_octet_string as a close relative.
>> Using the documented macro OSSL_MAC_PARAM_KEY is considered worthless
>> as this requires to conditionally include an additional OpenSSL header.
> 
> Do we really need this?
> 
> Given the amount of various API changes and deprecations in 
> OpenSSL, especially in OpenSSL 3.0, and the quality of new APIs 
> being introduced (see 61011bfcdb49 for an example, and the whole 
> early data stuff for another one), I would rather refrain from 
> supporting this at least till SSL_CTX_set_tlsext_ticket_key_cb(), 
> which is also the only API supported by LibreSSL and BoringSSL, is 
> actually removed.

The main motivation is to support such experimental builds,
such that they won't affect passing our own nginx tests.
This can wait for sure till existing API is removed (if at all).

> 
> Note well that building nginx with OpenSSL 3.0 and 
> OPENSSL_NO_DEPRECATED defined will simply fail.
> 
> If for some reason OpenSSL was built with "no-deprecated", I 
> believe it's completely expected that some advanced features using 
> APIs not present in the build will not be available, and it's sole 
> responsibility of whoever created such a build.
> 
> [...]

-- 
Sergey Kandaurov


More information about the nginx-devel mailing list