Let SSL_new_session_ticket() enter init immediately
authorBenjamin Kaduk <bkaduk@akamai.com>
Fri, 2 Apr 2021 17:04:24 +0000 (10:04 -0700)
committerBenjamin Kaduk <bkaduk@akamai.com>
Wed, 19 May 2021 21:56:08 +0000 (14:56 -0700)
commit7c73fefe38f4fce9437b1d24d90dd5aa411c7e28
tree8d8c7b23f8eae3456b81ba5e2198515d556bae22
parente34e91d7e575a2f69119601f2d34655cb6816148
Let SSL_new_session_ticket() enter init immediately

The initial implementation always deferred the generation of the
requested ticket(s) until the next application write, but this
is not a great fit for what it actually does, architecturally wise.
A request to send a session ticket means entering back into the
handshake state machine (or "in init", as it's known in the
implementation).  The state machine transition is not something that
only occurs at an application-data write, and in general could occur at
any time.  The only constraint is that we can't enter "init" while in
the middle of writing application data.  In such cases we will need to
wait until the next TLS record boundary to enter the state machine,
as is currently done.

However, there is no reason why we cannot enter the handshake state
machine immediately in SSL_new_session_ticket() if there are no
application writes pending.  Doing so provides a cleaner API surface to
the application, as then calling SSL_do_handshake() suffices to drive
the actual ticket generation.  In the previous state of affairs a dummy
zero-length SSL_write() would be needed to trigger the ticket
generation, which is a logical mismatch in the type of operation being
performed.

This commit should only change whether SSL_do_handshake() vs zero-length
SSL_write() is needed to immediately generate a ticket after the
SSL_new_session_ticket() call -- the default behavior is still to defer
the actual write until there is other application data to write, unless
the application requests otherwise.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14817)
ssl/ssl_lib.c