SSL_SESSION_set1_ticket ?

[Viktor Dukhovni]

On Tue, Apr 09, 2019 at 11:52:59PM +0100, Jeremy Harris wrote:

> On 04/04/2019 16:16, Viktor Dukhovni wrote:
> >> 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.
> > 
> > [ Correction: ... should *not* use the default STEK, ... ]
> 
> So I have the server side mostly running, with rollover and
> overlap... but in the client, when a session is succesfully
> resumed but past the overlap period, and the server issues
> a new ticket - the client SSL_SESSION is apparently unchanged
> (at least, the ASN.1 dump of it is identical to that loaded
> for resumption prior to handshake).
> 
> How is an overlapped key update supposed to be handled by
> a client?

With TLS 1.0, 1.1 and 1.2, the the (always new IIRC) session object
associated with the connection object at the completion of each
handshake, will contain any fresh tickets issued by the server.

With TLS 1.3, the session tickets arrive post-handshake, and
so saving the session exactly when the handshake completes,
may not yet result in fresh tickets.

In Postfix, we implement the new session callbacks and then don't
care when the tickets arrive.  Whenever they do arrive the callback
happens, and the client session cache is updated at that point.

    https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L531-L556

The "external" (to OpenSSL) session cache implemented in Postfix,
has its own timeouts, and is periodically GC'd in the tlsmgr(8)
process discarding expired sessions.  There is one session per
lookup key, which captures not only the nexthop destination, endpoint
IP, peer HELO name (for split caches behind load-balancers), ...
but also a cryptographic hash of the TLS policy settings to avoid
accidental misuse.

For an in-memory cache, you could also bound the cache size, and
implement an LRU retired policy.  A priority search queue library
can provide the right abstraction.

-- 
	Viktor.