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.
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
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 `SideData` trait. The types
implementing it are updated to derive `Debug` or implement it by hand as
appropriate.
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.
Instead of the type `rustls::crypto:💍:Ring`, the value
`rustls::crypto:💍:RING` implements this, and is more
entertaining to write.
`ServerConfig::builder()` references this by default, and
is equivalent to `ServerConfig::builder_with_provider(crypto:💍:RING)`.
This turns `SupportedKxGroup` into a trait, which can tell you
which `NamedGroup` it is, and `start()` an `ActiveKeyExchange`.
An `ActiveKeyExchange` represents the need for the peer's public key
which can be passed to `ActiveKeyExchange::complete`.
Unfortunately we can't be generic at compile-time over the various uses
of the resulting shared secret, so define a further type
which encapsulates the resulting shared secret.
Predefined key exchange algorithms (eg `rustls::kx_group::X25519`)
are now `&'static dyn rustls::SupportedKxGroup`.
The remainder of this commit is noise as much code ceased needing
to be generic of CryptoProvider (for its `KeyExchange` associated type).
Using the crate without this feature means something external
needs to provide all the cryptography, and (eg) convenient integrated
key loading APIs disappear.
The actually expensive part is mostly the gathering of certificates
from the platform trust root store, and it would be better to document
that in the relevant API (that is, in rustls-native-certs). Apart
from that, I believe that the use of `Arc`-wrapped types is also an
effective signal that the wrapped types should be reused where possible.
The docs formerly said the default maximum was 2**16 (64 kB) but according to
spec (and implementation) it's actually 2**14 (16 kb).
The docs recommended setting to TCP MSS but by my understanding there is a
little record overhead so it's better to set this to a little under the MSS.
Clarified that there is in fact a limit when the default value of None is used.
Use the slightly more precise "TLS record" instead of "TLS message".
This removes duplicated manual feature gates for documentation
and leaves it to `cargo doc` to derive the same information from
the actual feature gates.
I didn't find any gaps in the auto-generated features and what we had
before, but now things like `rustls::cipher_suite::TLS_ECDHE_*`
are correctly marked tls12-only.
This commit adds a `KeyExchange` associated type to the `CryptoProvider`
trait. The `KeyExchange` type is constrained with its own `KeyExchange`
trait that has an associated type for the `SupportedGroup`.
In the `crypto::ring` package we adapt the existing *ring* specific
`KeyExchange` and `SupportedKxGroup` types to these new traits.
Throughout the codebase we tighten generic bounds where required to
ensure we have a `CryptoProvider` bound that allows accessing the
associated `KeyExchange` and `SupportedGroup`. We also make the
`CryptoProvider` an associated type on the `Side` config.
This commit moves the existing Ring-based key exchange mechanisms from
`rustls/src/kx.rs` to `rustls/src/crypto/ring.rs` in anticipation of
adapting the codebase to a more general keyex trait that these types
will implement.
No changes are made to the implementation except to update import paths
to reference the new location.
For better code organization this commit moves the generic crypto
interface code from `src/crypto.rs` to `src/crypto/lib.rs`.
The *ring* specific code implementing the generic interfaces is moved to
`src/crypto/ring.rs` as a sub-module of `crypto. All imports are
adjusted accordingly.
This has the advantage of leaving `src/crypto/lib.rs` small, and without
any *ring* specific imports. In the future we may choose to feature-gate
the ring sub-module to allow building the crate without a dependency on
ring.
After splitting up the quic server connection types consumers lost the
ability to dig out the server name from the SNI extension the server
received. This commit adds the `server_name` function to
`quic::ServerConnection` to restore that ability.
The documentation retains mention of "server name indication" (SNI) for
folks that search the documentation with that more specific technical
term. For users not steeped in the deeper lore of TLS the new name
will be easier to find/understand.
These enums (AlertDescription, ContentType, and HandshakeType) were
previously only available as part of the private API. Eight months ago
we added a public reexport of their names, but did not remove the
private version to avoid semver breakage.
Now that we have a semver-incompatible version coming up we can move
these fully to the public API.
I think these uses of `doc(hidden)` are trying to implement `pub(crate)`
semantics. Perhaps it was done this way a long time ago when `pub(crate)`
wasn't a think.
This change causes an `unreachable_pub` warning for `PlaintextSink`, so
make that `pub(crate)` too.
Some external users might be using these even though they probably shouldn't
be, so this is technically a breaking change.
When we encounter an error processing the client hello, don't try again.
Trying again generally won't do any good. This matches `Future::poll`
semantics (Futures shouldn't be polled after yielding `Ready`).
Joseph Birr-Pixton
Jacob Hoffman-Andrews
Daniel McCarney
Dirkjan Ochtman
Jorge Aparicio
Smaug123
Brian Smith
Jacob Rothstein
amos
Xuanwo
Josh Aas