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>
This goes from being a single set of keys for ECDSA (with a
purposeful mix of curves) to a set of keys per curve.
That means we can avoid P521 chains in tests when it is not supported.
In those tests, reflect this as additional `KeyType` variants.
if for some reason the recorded session ticket is invalid or decoded
incorrectly by the server, we can get into a case where the resumption
handshake happens, and right after the ChangeCipherSpec message, the
server sends an encrypted handhsake message using the invalid ticket,
and the client rejects it with the BadRecordMAC alert.
Unfortunately, if the calling code retries the connection, if it will
try again with the same ticket and obtain the same result.
This commit makes sure that if we fail to decrypt the first message, we
will remove the session ticket for this server, to start from cratch on
the next connection.
When building a client config or a server config using the default
provider we know that the ciphersuites will be compatible with any
choice of protocol version. By having the default `builder` method
configure itself with safe default versions, and offering
a `builder_with_protocol_versions` for customization we can transition
directly to `WantsVerifier` for these default provider builders,
removing a `Result` that will never be an error and making the API more
ergonomic in the common case.
This commit replaces the existing `CryptoProvider` trait with
a `CryptoProvider` struct. This has several advantages:
* it consolidates all of the cryptography related settings into one API
surface, the `CryptoProvider` struct members. Previously the provider
had methods to suggest default ciphersuites, key exchanges etc, but
the builder API methods could override them in confusing ways.
* it allows removing the `WantsCipherSuites` and `WantsKxGroups` builder
states - the "safe defaults" are automatically supplied by the choice
of a crypto provider. Customization is achieved by overriding the
provider's struct fields. Having fewer builder states makes the API
easier to understand and document.
* it makes customization easier: the end user can rely on "struct update
syntax"[0] to only specify fields values for the required
customization, and defer the rest to an existing `CryptoProvider`.
Achieving this requires a couple of additional changes:
* The cipher suite and key exchange groups are now expressed as `Vec`
elements. This avoids imposing a `&'static` lifetime that would
preclude runtime customization (e.g. the tls*-mio examples that
build the list of ciphersuites at runtime based on command line
flags).
* As a result of the `Vec` members we can no longer offer the concrete
`CryptoProvider`s as `static` members of their respective modules.
Instead we add `pub fn default_provider() -> CryptoProvider` methods
to the `ring` and `aws-lc-rs` module that construct the `CryptoProvider`
with the safe defaults, ready for further customization.
[0]: https://doc.rust-lang.org/book/ch05-01-defining-structs.html#creating-instances-from-other-instances-with-struct-update-syntax
In preparation for moving to a struct based model where
a `CryptoProvider` has a `&'static dyn KeyProvider` field, this commit
splits the `KeyProvider` trait from the `CryptoProvider` trait. In its
place `CryptoProvider` gets a `key_provider(&self)` fn that acts as
a stand-in for what will be a field in the struct based approach.
We're working towards making `CryptoProvider` a struct holding distinct
elements to be used for cryptography. To support this the
`load_private_key` fn needs to be lifted to a new trait, `KeyProvider`.
We can hold a `&dyn KeyProvider` in the to-be-added struct to invoke
as required for `load_private_key`.
This commit adds the new trait, includes `KeyProvider` in the existing
`CryptoProvider` trait bounds, and updates the *ring*, aws-lc-rs, and
provider example crypto providers to implement `KeyProvider`.
In preparation for moving to a struct based model where
a `CryptoProvider` has a `&'static dyn SecureRandom` field, this commit
splits the `SecureRandom` trait from the `CryptoProvider` trait. In its
place `CryptoProvider` gets a `secure_random(&self)` fn that acts as
a stand-in for what will be a field in the struct based approach.
We're working towards making `CryptoProvider` a struct holding distinct
elements to be used for cryptography. To support this the `fill_random`
fn needs to be lifted to a new trait, `SecureRandom`. We can hold
a `&dyn SecureRandom` in the to-be-added struct to invoke as required
for `fill_random`. Since the trait now provides additional context, the
fn is renamed from `fill_random` to `fill`.
This commit adds the new trait, includes `SecureRandom` in the existing
`CryptoProvider` trait bounds, and updates the *ring*, aws-lc-rs, and
provider example crypto providers to implement `SecureRandom`.
The top level of the crate is meant for "paved path" exports.
This newly exported type is used for cryptographic provider
customization, so it properly belongs in the `crypto` module.
Since these are now unconditionally available on the Tls13CipherSuite,
there doesn't seem to be much point in keeping this API (which appears
be unused).
The goal is to make it possible for provider-example to exist
without implementing (eg) QUIC header protection.
This introduces some knock-on requirements for other types/functions
to be the public, so `quic::Algorithm` can be implemented outside
the crate.
`test_client_mtu_reduction` and `test_server_mtu_reduction` already exist
but only check client/server behaviour in (relative) isolation.
This test just checks handshaking and bidirectional data flow over
a matrix of key types, TLS versions, and max_fragment_sizes.
This commit adds a `Debug` bound to the `ResolvesServerCert` trait in
addition to `Send` and `Sync`. Types implementing this trait are updated
to either derive `Debug` or implement it by hand as appropriate.
This commit adds a `Debug` bound to the `ClientCertVerifier` trait in
addition to `Send` and `Sync`. Types implementing this trait are updated
to either derive `Debug` or implement it by hand as appropriate.
This commit adds a `Debug` bound to the `ResolvesClientCert` trait,
alongside `Send` and `Sync`. The types implementing this trait are
updated to either derive `Debug`, or implement it by hand, as
appropriate.
This commit adds a `Debug` bound to the `KeyLog` trait in addition to
`Send` and `Sync`. Each implementation in the codebase is updated to
derive, or hand-implement the `Debug` trait, taking care not to include
any fields that may contain secret key information.
This drastically simplifies `provider-example`. But the
primary goal is ensuring a client configured `with_provider(AWS_LC_RS)`
only uses algorithms from aws-lc-rs, irrespective of crate features.
Naming cipher suites individually seems like a "detail" feature, and
therefore having to name the provider too is not a large imposition.
Naturally this is a breaking change.
Pull out a generic helper from the existing client cert resolver test,
rename the test that uses the helper to emphasize it's testing a default
configuration. This will make it easier to add a test for non-default
configurations.
This commit renames the `ClientCertVerifier::client_auth_root_subjects`
fn to `root_hint_subjects` to emphasize that these subjects
may be distinct from the subjects of the verifier's trust anchors. The
`client_auth` prefix is dropped as obvious from context.
The Rustdoc comment for the trait fn is expanded to give more
information about what these hint subjects are used for, and why there
are instances where the hint subject names aren't 1:1 with the
verifier's root cert store subject names.
Similarly the `ResolvesClientCert::resolve` fn's argument is renamed
from `root_hint_subjects` and the rustdoc gains additional context.
This commit updates the existing client certificate revocation testing
to also exercise the two new verifier options for controlling the depth
of revocation checking, and deciding how to handle unknown revocation
status.
This commit updates `ConnectionTrafficSecrets` to hold `AeadKey` and
`Iv` instances, instead of byte arrays, removing the need for the
`slices_to_arrays` and `slice_to_array` helpers.
In an effort to reduce our feature list, this commit replaces the
`secret_extraction` feature flag with functions that are always present,
but named `dangerous_extract_secrets` to emphasize potential danger.
Cargo features are additive, which means transitive dependencies could
enable them for you without explicit opt-in. Using obviously named
functions will maintain the property that it's easy to grep for imports,
but avoids feature flag bloat and the additive downsides.
Sean McGrail
Joseph Birr-Pixton
Goncalo Gomes
Daniel McCarney
Geoffroy Couprie
Jacob Hoffman-Andrews
Dirkjan Ochtman
Robsdedude