This means a `ClientConfig` and `ServerConfig` can be asked whether it
is in fips mode, and it answers by asking the same of all its
constituent cryptography.
Google Chrome project proposes Client Hello extensions should be
randomized in order to prevent fingerprinting [1]
This commit sorts all the extensions that have been sent in the same
order as before by using a seed that is saved at the start of the
connection. And keeps the PSK extension in the end.
[1] https://chromestatus.com/feature/5124606246518784resolves#1313
Co-authored-by: Joseph Birr-Pixton <jpixton@gmail.com>
For client ECH support we'll need to be able to fork (e.g. clone) the
`HandshakeHashBuffer` and `HandshakeHash` types used to maintain the
client transcript.
For ECH confirmation we'll fork the existing hash(buffer), add some specially
encoded messages, and then use the hash state to derive a shared secret.
If the secret matches an expected value we'll use the original
`HandshakeHash`/`HandshakeHashBuffer`'s state from before our twiddling
to continue the handshake.
To support implementing client-side ECH we'll need to clone a few
message types to make modifications. This commit adds derived `Clone`
implementations for `ClientHelloPayload`, `HelloRetryExtension` and
`ServerHelloPayload`.
As part of implementing client-side ECH support we will want to be able
to return a `PeerIncompatible` error variant that includes ECH configs
to use for potential retry.
Since `PeerIncompatible` derives `PartialEq` we need to thread
derivations of this trait down through the `EchConfig` and associated
types.
In practice we need `'static` here to be able to easily hold `Box<dyn
HpkeSender>` and friends. Our existing provider implementation already
matches this lifetime bound.
Encrypted Client Hello support requires that clients maintain the HPKE
sealer context between sending an initial client hello, and processing
a hello retry request, such that the subsequent client hello can re-use
the HPKE state.
This commit updates the HPKE trait to add `setup_sealer` and
`setup_opener` fns in addition to the "one-shot" APIs. New
`HpkeSealer` and `HpkeOpener` traits are used to represent the
stateful sender/receiver contexts in a backend neutral way.
The existing hpke-rs provider example is updated to implement the new
required traits and fns.
* Move the public key/secret key arguments to be last, since they are
"long lived".
* Rename `pk_r` -> `pub_key` and `sk_r` to `secret_key`. Reference RFC
9180's terse names.
The `ClientConfig` parts should appear before the types it references.
The `Tls12Resumption` enum should appear after the `Resumption` type
that uses it.
This acts as a regression test for the previous commit. This also enables:
- TLS12-Server-CertReq-CA-List
- TLS13-Server-CertReq-CA-List
- Null-Client-CA-List
The `KeyProvider` trait associted with the `CryptoProvider` struct is
specific to private key material that can be loaded from a DER
representation. For users that want to use private keys used through
a handle, or PKCS11 style interface an alternative integration approach
is needed.
This commit adds a doc string update to the `KeyProvider` to guide such
users to look at the Rustls manual's section on customizing private key
usage.
Sean McGrail
Joseph Birr-Pixton
Daniel McCarney
Nick Kirby
Goncalo Gomes
Christian Poveda
Benjamin Jurk