When resuming a TLS session using Dial (and not DialEarly), 0-RTT should
be disabled at the TLS layer, even if the session ticket allows for
0-RTT resumption.
This bug is not critical, since Dial doesn't return an EarlyConnection,
so the client wouldn't be able to actually send 0-RTT data in practice.
* also send session ticket when 0-RTT is disabled for go1.21
* allow session ticket without transport parameters
* do not include transport parameters for non-0RTT session ticket
* remove the test assertion because it is not supported for go1.20
* Update internal/handshake/session_ticket.go
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
* add a 0-RTT argument to unmarshaling session tickets
* bump sessionTicketRevision to 4
* check if non-0-RTT session ticket has expected length
* change parameter order
* add test checks
---------
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
When receiving a handshake message after another handshake messages that
doesn't cause any action from the TLS stack (i.e. Certificate and
CertificateVerify), the handshake would run into a deadlock if the first
of these handshake messages caused an error in the TLS stack.
We need to make sure that we wait until a message has been fully
processed before proceeding with the handshake.
The RTTStats are used by the logging package. In order to instrument the
congestion package, the RTTStats can't be part of that package any more
(to avoid an import loop).
Application data is now retrieved and restored via two callbacks on the
qtls.Config. This allows us the get rid of the rather complex wrapping
of the qtls.ClientSessionCache. Furthermore, it makes sure that we only
restore the application data when qtls decides to actually use the
ticket.
Previously, RunHandshake() would send the session tickets. Now, the
session initiates the sending of the session ticket. This simplifies the
setup a bit, and it will make it possible to include the RTT estimate in
the session ticket without accessing the RTTStats concurrently.
