Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: cloudflare/quiche
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: master
Choose a base ref
...
head repository: cloudflare/quiche
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: evanrittenhouse/handshake-confirmed
Choose a head ref
Checking mergeability… Don’t worry, you can still create the pull request.
  • 2 commits
  • 2 files changed
  • 1 contributor

Commits on Aug 1, 2025

  1. quiche: add is_handshake_confirmed API 

    `is_established()` will return `true` as soon as the handshake is
considered complete, but that will miss [post-handshake auth]. This is a
potential footgun as it could lead to applications mistakenly assuming
that post-handshake authorizations like mTLS are complete, when they're
not.

`is_handshake_confirmed` is a more explicit signal that the
QUIC connection considers the full handshake to be complete.
    @evanrittenhouse
    evanrittenhouse committed Aug 1, 2025
    Configuration menu
    Copy the full SHA
    9ae8d03 View commit details
    Browse the repository at this point in the history

  2. tokio-quiche: exit Handshake stage when handshake is confirmed 

    This makes exiting the handshake stage more aligned with the design of
the AOQ trait.

Take, for example, an mTLS client/server. The server could send a
CertificateRequest, but then drop through and send a Finished in the
same flight ([1]) since mTLS is considered [post-handshake
authentication]. This would cause a tokio-quiche-based mTLS client to
exit the handshake as soon as it sees the Finished, before it ever sends
its certificate. This could lead to cases where the AOQ sends data into
the void despite a pending handshake failure.

By instead exiting the handshake stage when the handshake is confirmed,
we can ensure that the AOQ only begins running when the handshake is
truly complete. This more closely matches the intended design of the AOQ
trait, which should only ever start handling packets when the entire
handshake is complete.

For servers, this is essentially a no-op change since
flipping `handshake_confirmed` to true is gated on
`handshake_completed`, which is the same as `is_established()`. For
clients, we now consider the handshake complete upon receiving a
`HANDSHAKE_DONE` frame rather than a TLS `Finished` message.

[post-handshake authentication]: https://datatracker.ietf.org/doc/html/rfc8446#section-4.6.2
    @evanrittenhouse
    evanrittenhouse committed Aug 1, 2025
    Configuration menu
    Copy the full SHA
    b56d834 View commit details
    Browse the repository at this point in the history
Loading