> On Apr 3, 2019, at 4:16 PM, Jeremy Harris <jgh@xxxxxxxxxxx> wrote: > >> Does the server have a temporally stable ticket decryption key? >> Is this Exim? Is the server's SSL_CTX persistent and shared >> across multiple connections? > > Ah, right. Unlike GnuTLS, the STEK is tied to the SSL_CTX and, > as you say, Exim initialises that fresh per connection. > Rearchitecting that is more effort than it's worth spending > on TLS 1.2, I think. Well, the *default* STEK is in the SSL_CTX, but that is not a requirement, and you should use the default STEK, since it is not automatically rolled over. Postfix instantiates the ticket management callbacks, which are registered per-ctx, but the associated key material is then wherever the application (e.g. Postfix) decides to keep them. So you, and should, manage STEKs separately from the SSL_CTX, and as appropriate tie the same keys to any appropriate SSL_CTX by instantiating the appropriate callbacks. The one thing to be mindful of is that if you have different TLS policies across different SSL_CTX objects, they should probably not share keys, otherwise it *may* be possible for sessions to be established against a weak policy and then inappropriately resumed against a service with a stronger policy. The solution is to assign different session id contexts to SSL_CTX's that should not allow cross-resumption. The SSL_CTX_set_session_id_context(3) allows you to specify such a session id context. I just looked at the documentation of SSL_CTX_set_session_id_context(3), and is rather poor. You just need to know that the context is binary data up a maximum length you must not exceed, and the signature of the function. The description is largely wrong. :-( -- Viktor.
