tls 1.3: sending multiple tickets - Mailing list pgsql-hackers

Hi,

To investigate an unrelated issue, I set up key logging in the backend (we
probably should build that in) and looked at the decrypted data.  And noticed
that just after TLS setup finished the server sends three packets in a row:

C->S: TLSv1.3: finished
C->S: TLSv1.3: application data (startup message)
S->C: TLSv1.3: new session ticket
S->C: TLSv1.3: new session ticket
S->C: TLSv1.3: application data (authentication ok, parameter status+)


We try to turn off session resumption, but not completely enough for 1.3:
       SSL_OP_NO_TICKET
           SSL/TLS supports two mechanisms for resuming sessions: session ids and stateless session tickets.

           When using session ids a copy of the session information is cached on the server and a unique id is sent to
theclient. When the client  wishes  to
 
           resume it provides the unique id so that the server can retrieve the session information from its cache.

           When  using  stateless  session  tickets the server uses a session ticket encryption key to encrypt the
sessioninformation. This encrypted data is
 
           sent to the client as a "ticket". When the client wishes to resume it sends the encrypted data back to the
server. The  server  uses  its  key  to
 
           decrypt the data and resume the session. In this way the server can operate statelessly - no session
informationneeds to be cached locally.
 

           The  TLSv1.3  protocol  only  supports  tickets and does not directly support session ids. However, OpenSSL
allowstwo modes of ticket operation in
 
           TLSv1.3: stateful and stateless. Stateless tickets work the same way as in TLSv1.2 and below.  Stateful
tickets mimic  the  session  id  behaviour
 
           available  in TLSv1.2 and below.  The session information is cached on the server and the session id is
wrappedup in a ticket and sent back to the
 
           client. When the client wishes to resume, it presents a ticket in the same way as for stateless tickets. The
servercan then extract the session id
 
           from the ticket and retrieve the session information from its cache.

           By default OpenSSL will use stateless tickets. The SSL_OP_NO_TICKET option will cause stateless tickets to
notbe issued. In TLSv1.2 and below this
 
           means no ticket gets sent to the client at all. In TLSv1.3 a stateful ticket will be sent. This is a
server-sideoption only.
 

           In TLSv1.3 it  is  possible  to  suppress  all  tickets  (stateful  and  stateless)  from  being  sent  by
calling SSL_CTX_set_num_tickets(3)  or
 
           SSL_set_num_tickets(3).


Note the second to last paragraph: Because we use SSL_OP_NO_TICKET we trigger
use of stateful tickets. Which afaict are never going to be useful, because we
don't share the necessary state.

I guess openssl really could have inferred this from the fact that we *do*
call SSL_CTX_set_session_cache_mode(SSL_SESS_CACHE_OFF), b


Seems we ought to use SSL_CTX_set_num_tickets() to prevent issuing the useless
tickets?



It seems like a buglet in openssl that it forces each session tickets to be
sent in its own packet (it does an explicit BIO_flush(), so even if we
buffered between openssl and OS, as I think we should, we'd still send it
separately), but I don't really understand most of this stuff.

Greetings,

Andres Freund