This commit adds an example *server* that is roughly contemporary with
the existing "simpleclient".
It is the absolute bare minimum needed to run a server using Rustls
(e.g. it only accepts a single connection before terminating).
You can run the server with:
```
CERTFILE=test-ca/rsa/end.fullchain PRIV_KEY_FILE=test-ca/rsa/end.key cargo run --package rustls-examples --bin simpleserver
```
And connect to it with a client:
```
cargo run --package rustls-examples --bin tlsclient-mio -- --port 4443 --cafile test-ca/rsa/ca.cert localhost --http
```
This sticks the error from `process_tls_records()` inside
`UnbufferedStatus`. That means the `discard` field is still
available, but continues to require handling the error to learn
the `state` field's underlying value.
TODO: the example code is made to unwrap errors in this PR.
They need reorganising so the discard processing happens before
error handling.
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
These helpers assumed the *ring* crypto provider. Consumers can now use
the exported `verify_tls12_signature` and `verify_tls13_signature`
helpers with the crypto provider of their choice to implement these fns.
Similarly since `WebPkiSupportedAlgorithms` now exposes the
`supported_schemes` fn there's no need for the
`default_supported_verify_schemes` helper.
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.
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.
The `rcgen` crate has cut a 0.11.2 release that includes the CRL
functionality we were using a Cargo patch to depend on previously. This
commit removes the patch, fixes one breakage in the server acceptor
example, and updates the `Cargo.toml` and `Cargo.lock` files.
In an effort to reduce our feature list, this commit replaces the
`dangerous_configuration` feature flag with separate `danger` modules.
Cargo features are additive, which means transitive dependencies could
enable them for you without explicit opt-in. Using obviously named
modules will maintain the property that it's easy to grep for imports,
but avoids feature flag bloat and the additive downsides.
After discussion we've chosen to not include the webpki verifier and
helper functions as part of the dangerous API surface. Functionality for
setting a custom verifier, or implementing one to make assertions about
verification status, remain marked as dangerous via their module name.
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).
Benjamin Jurk
Daniel McCarney
Niklas Fiekas
Joseph Birr-Pixton
Jorge Aparicio
dependabot[bot]
Jacob Hoffman-Andrews
girlbuzz
Dirkjan Ochtman