[openssl-users] RFC5077 ticket construction help

[Viktor Dukhovni]

> On Mar 28, 2018, at 1:37 PM, Henderson, Karl via openssl-users <openssl-users at openssl.org> wrote:
> 
> Ok, but I’d like to use TLS rather than Kerberos. I’m wondering if I could do something like this:
>  
> 	• C sends a Client Hello with 0 length Session Ticket to B.
> 	• B sends back a NewSessionTicket to C in Server Hello.
> 	• C sets SSL_CTX_sess_set_new_cb(ctx, new_session_cb) and saves the session blob/ticket in the new_session_cb function indexed by the URL of B.
> 	• A contacts C with the URL of B
> 	• C looks up session ticket indexed by URL of B
> 	• C sends A the session ticket.
> 	• A contact B and sets the ticket using SSL_set_session_ticket_ext(ssl, ticket, ticket size)
>  
> Feasible? I’m trying something like this now but I can’t get it working.

This is essentially what happens in Postfix much of the time between the tlsmgr(8)
process which manages the TLS session cache and the smtp(8) delivery agent which
talks TLS to remote servers, except the initial acquisition of the session is
by a delivery agent that did not find a session to re-use or tried to re-use a
session, but the server did a full handshake anyway...

Which brings us to an important point.  The server might not resume
a session for any number of reasons, and will do a full handshake.
Then what?  Session resumption is an optimization, and the server
can choose to ignore the presented ticket, or might decide it is
too stale, or that the phase of the moon is wrong, and not use it.

Secondly, you need a very secure channel between C and A, as the
serialized session, may allow off-line decryption of subsequent
traffic between A and C, or at least a man-in-the-middle attack.
The master secret for the cached connection is part of that data.

What's wrong with issuing client certs trusted by B?

-- 
-- 
	Viktor.