When doing a retry after a version negotiation, we actually need to drop
packet 1 rather than 0 to get a retransmit of the initial packet
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26000)
@t8m pointed out that versino negotiation packets weren't guaranteeing
network byte ordering in the array of supported versions.
Convert the client to use network byte order on send and receipt.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25968)
On the client side, when we get a version negotiation packet, we need to
interrogate the supported version list from the server, and either:
1) drop the connection if we don't see a version we can work with
2) select a supported version and try the negotiation again
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25968)
In preparation for doing version negotiation, expose the ability to have
the packetiser for QUIC set a configured protocol version. We only set
it to QUIC_VERSION_1 for now, but it allows for us to set different
protocols in the future.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25968)
After sending a retry frame from a server, the subsequent server hello
record must include the RETRY_SCID transport parameter, as per RFC 9000:
https://datatracker.ietf.org/doc/html/rfc9000#section-7.3
Implement the encoding of said retry_source_connection_id transport
param, and fix up tests to address the impact of that change. Test
changes amount to:
1) quicapitest needs to have its tparam test augmented such that it
doesn't inject the retry_scid on its own, as the quic stack does it
for the test now
2) quicapitest needs to have the ssl_trace test adjusted so the expected
record values are reflected.
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25890)
When establishing a connection over quic, if the channel is established
in response to a retry request from the server, the ORIG_DCID transport
parameter must reflect the original dcid sent from the client in the
first inital packet that the server sent the retry request in response
to.
As opposed to establishing a connection without the retry request, when
address validation isn't in use, where the ORIG_DCID parameter just
represents the the dcid that the client sent.
Augment the channel creation code to select the 'right' DCID when
encoding server side transport parameters
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25890)
When using retry packets in QUIC to implement address validation, the
2nd inital packet that arrives after the server sends the retry frame
will have its CRYPTO packet encrypted using keys derived from the new
dcid, rather than the dcid in the 1st initial packet. Update the
channel creation code to update those keys on the server so that the
CRYPTO packet is decrypted successfully
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25890)
RFC 9000 describes a method for preforming server address validation on
QUIC using retry packets. Based on:
https://datatracker.ietf.org/doc/html/rfc9000#section-17.2.5.2
We do the following:
1) Client sends an Initial packet without a retry token
2) Server abandons the initial packet and responds with a retry frame
which includes a retry token and integrity tag and new SCID
3) Client send the initial packet again, updating the encryption keys
for the connection based on the SCID sent in (2), using it as the new
DCID, including the retry token/tag provided in (2).
4) Server validates the token in (3) and creates a new connection using
the updated DCID from the client to generate its encryption keys
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25890)
Just because one connection has not started yet, it does not mean that
we should not tick the QUIC_ENGINE. There may be other connections that do
need ticking.
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25452)
We provide some callbacks for third party QUIC stacks to use in order
to be able to reuse the OpenSSL TLS implementation in that stack. This is
essentially a thin wrapper around the same API that OpenSSL's own QUIC
stack uses in order to integrate TLS.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26683)
Reviewed-by: Neil Horman <nhorman@openssl.org>
Release: yes
(cherry picked from commit 0ce7d1f355)
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24034)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23535)
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23360)
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23360)
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23360)