This was only partially ported, but built due to feature unification
from other crates in the workspace.
Unconditionally use a provider, and wrap certificate signature
operations rather than using (ring-only) `default_verify_tls12_signature`
et al.
In QUIC connections, we shouldn't offer or accept cipher suites
that have `Tls13CipherSuite::quic` as `None`. So introduce
`usable_for_protocol` on `SupportedCipherSuite`, and
use it to extend `reduce_given_version` into `reduce_given_version_and_protocol`.
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.
If we put the key derivation on "our" side of the trait, we avoid
publicising low-level key schedule functions like hkdf_expand_label
& hkdf_expand_label_aead_key, and quic::Version.
Instead we just provide the `AeadKey` and `Iv`, which makes these
interfaces very similar to those in `Tls13AeadAlgorithm`.
This commit implements the Rustls HPKE provider traits using hpke-rs[0]
with the rust-crypto backend.
Since HPKE is not yet used in Rustls (but will be for ECH support),
a unit test based on the RFC 9180 test vectors is added.
Likely in the future we will want to move this test somewhere outside of
the provider-example crate and use it to test a *ring* HPKE
implementation using the same test vector data.
[0]: https://github.com/franziskuskiefer/hpke-rs
This commit introduces a trait for a hybrid public key encryption (HPKE)
provider. HPKE is specified in RFC 9180[0], and is a pre-requisite for
implementing encrypted client hello (ECH).
Implementations of this trait can use the cryptographic provider of
their choice to provide HPKE using existing primitives from the crypto
provider.
We've tailored the HPKE trait in Rustls to just what is required for
ECH, e.g. it doesn't support modes other than the unauthenticated 'base'
mode, and it only offers the "single-shot" APIs.
[0]: https://www.rfc-editor.org/rfc/rfc9180
The `error::Error` enum was updated with a `Error::Other` variant that
holds an `error::OtherError` instance. We neglected to export the
`OtherError` type, so this variant ends up opaque. This commit exports
the type so that crate-external users can instantiate an `Error::Other`
variant as needed.
`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 `StoresServerSessions` 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 `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 `ProducesTickets` 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 `ServerCertVerifier` 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 `SideData` trait. The types
implementing it are updated to derive `Debug` or implement it by hand as
appropriate.
This commit adds a `Debug` bound to the `ClientSessionStore` trait,
alongside `Send` and `Sync`. Types implementing the trait are updated
with derived or hand-written `Debug` impls as appropriate, taking care
to avoid leaking any sensitive information.
This commit adds a `Debug` bound to the `Signer` trait alongside the
existing `Send` and `Sync` bounds. Types implementing the trait are
updated with a hand-written `Debug` impl to avoid leaking sensitive
data.
This commit adds a `Debug` bound to the `SigningKey` trait, alongside
`Send` and `Sync`. Types implementing this trait are updated to hand
implement `Debug` to avoid leaking any sensitive data.
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.
It isn't possible to write a cfg expression that says when this
is used, because it would differ over the two instantiations.
Note that HMAC-SHA512 is only actually used to run test vectors posted
to the tlswg mailing list by some random in 2009.
Provide shims for limited number of places where ring 0.17 and
aws-lc-rs (ring 0.16-era) APIs have diverged. This is a
short-term fix, as they are likely to diverge more over time.
Eventually we'll have to stop sharing the code like this.
For unit-like tests, export a `test_provider` alias that resolves
to a provider module, for use in these tests.
This resolves to:
- *ring* if cfg(feature = "ring"), else
- aws-lc-rs if cfg(feature = "aws_lc_rs"), else
- is absent
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.