If we've got more data to send than will fit in a single datagram we should
keep generating those datagrams until we've sent it all.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21798)
This is useful for debugging purposes. The standard SSL_trace msgcallback
can be used with tserver.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21800)
Even in case of later failure we need to flush
the previous packets.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21700)
Raise errors when appropriate.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21700)
This improves tracking where the failure was triggered.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21700)
RFC says that successful decryption of HANDSHAKE el packet
triggers the discard on server side only.
On client we discard INITIAL el when we successfully send
a HANDSHAKE packet.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21713)
In some cases where a FIN has been received but with no data quic_read_actual
was failing to raise SSL_ERROR_ZERO_RETURN. This meant that we could end up
blocking in SSL_read(_ex) for too long.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21780)
The comments in quic_tls.c claimed that the dummybio was never used by
us. In fact that is not entirely correct since we set and cleared the
retry flags on it. This means that we have to manage it properly, and update
it in the event of set1_bio() call on the record layer method.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21686)
This should result in a QUIC PROTOCOL_VIOLATION
We also add tests for a post-handshake KeyUpdate, and a NewSessionTicket
with an invalid max_early_data value.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21686)
The max_early_data value must be 0xffffffff if the extension is present in
a NewSessionTicket message in QUIC. Otherwise it is a PROTOCOL_VIOLATION.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21686)
An OpenSSL QUIC client does not send the post_handshake_auth extension.
Therefore if a server sends a post-handsahke CertificateRequest then this
would be treated as a TLS protocol violation with an "unexpected message"
alert code. However RFC 9001 specifically requires us to treat this as
QUIC PROTOCOL_VIOLATION. So we have to translate the "unexpected message"
alert code in this one instance.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21686)
For some of the items we add FUTURE/SERVER/TESTING/MULTIPATH
designation to indicate these do not need to be resolved
in QUIC MVP release.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21539)
