SSL_SESSION_set1_ticket ?

[Viktor Dukhovni]

> On Apr 3, 2019, at 4:16 PM, Jeremy Harris <jgh at wizmail.org> 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.