Methods on QUICConn are synchronous:
The connection state is expected to change only in reaction
to a user calling a QUICConn method, and the state change
should finish completely before the method returns.
The connection context provided to QUICConn.Start violates
this model, because canceling the context causes an
asynchronous state change.
Prior to CL 719040, this caused no problems because canceling
the context did not cause any user-visible state changes.
In particular, canceling the context did not cause any new
events to be immediately returned by QUICConn.NextEvent.
CL 719040 introduced a new error event. Now, canceling a
QUICConn's context causes a new connection event to be
generated.
Receiving this event causes a data race visible to the
race detector, but the core problem is not the data race
itself: It's that an asynchronous event (canceling the
connection context) causes an change to the connection
events.
Fix this race by reworking the handling of QUICConn
context cancellation a bit. We no longer react to
cancellation while control of the connection lies
with the user. We only process cancellation as
part of a user call, such as QUICConn.Close
or QUICConn.HandleData.
Fixes#77274
Change-Id: If2e0f73618c4852114e0931b6bd0cb0b6a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/742561
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
For TLS 1.3, after procesesing the server/client hello, if there isn't a
CCS message, reject the trailing messages which were appended to the
hello messages. This prevents an on-path attacker from injecting
plaintext messages into the handshake.
Additionally, check that we don't have any buffered messages before we
switch the read traffic secret regardless, since any buffered messages
would have been under an old key which is no longer appropriate.
We also invert the ordering of setting the read/write secrets so that if
we fail when changing the read secret we send the alert using the
correct write secret.
Fixes#76443
Fixes CVE-2025-61730
Change-Id: If6ba8ad16f48d5cd5db5574824062ad4244a5b52
Reviewed-on: https://go-review.googlesource.com/c/go/+/724120
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Coia Prant <coiaprant@gmail.com>
Go 1.23 adds two new events to QUICConns: QUICStoreSessionEvent and
QUICResumeSessionEvent. We added a QUICConfig.EnableStoreSessionEvent
flag to control whether the store-session event is provided or not,
because receiving this event requires additional action from the caller:
the session must be explicitly stored with QUICConn.StoreSession.
We did not add a control for whether the resume-session event is
provided, because this event requires no action and the caller is
expected to ignore unknown events.
However, we never documented the expectation that callers ignore
unknown events, and quic-go produces an error when receiving an
unexpected event. So change the EnableStoreSessionEvent flag to
apply to both new events.
Fixes#68124
For #63691
Change-Id: I84af487e52b3815f7b648e09884608f8915cd645
Reviewed-on: https://go-review.googlesource.com/c/go/+/594475
Reviewed-by: Marten Seemann <martenseemann@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
The check for fragmentary post-handshake messages in QUICConn.HandleData
was reversed, resulting in a potential panic when HandleData receives
a partial message.
In addition, HandleData wasn't checking the size of buffered
post-handshake messages. Produce an error when a post-handshake
message is larger than maxHandshake.
TestQUICConnectionState was using an onHandleCryptoData hook
in runTestQUICConnection that was never being called.
(I think it was inadvertently removed at some point while
the CL was in review.) Fix this test while making the hook
more general.
Fixes#62266
Change-Id: I210b70634e50beb456ab3977eb11272b8724c241
Reviewed-on: https://go-review.googlesource.com/c/go/+/522595
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Marten Seemann <martenseemann@gmail.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
yuhan6665