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 the client. 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 session information. 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 information needs to be cached locally.
The TLSv1.3 protocol only supports tickets and does not
directly support session ids. However, OpenSSL allows two 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 wrapped up 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 server can 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 not be 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-side option 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
