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.
Without the context of RFC 8446 in your mind the use of the
`ProtocolVersion::TLSv1_2` constant in the TLS 1.3 `MessageEncrypter`
implementations appears like an oversight or copy/paste error. This
commit adds a brief explanatory comment.
We're starting to land semver incompatible changes into `main`. This
commit bumps the crate version so that the semver detection job won't
cause spurious failures.
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.
This puts ring, aws-lc-rs, and the tls12 features up front. They're
likely more interesting than the logging and read_buf features that are
increasingly niche.
The per-provider key loading functions returned this singleton error,
but it was usually then wrapped into Error::General("invalid private key").
That means the singleton error is unnecessary API surface, but also
it means potentially valuable information is lost.
Move the wrapping into `Error::General` to a lower level, add detail
about which specific parsing operation failed, and pass along error
details from the lower-level library.
`CertificateError` and `CertRevocationListError` both had an `Other` variant
containing `Arc<dyn StdError + Send + Sync>`, while `rustls::Error` used
the newtype `OtherError`. Use `OtherError` in all three cases.
Also, implement `StdError` and `Display` for `OtherError`, and
specifically implement `source()` to return the underlying error.
Also document at the call site for `for_key_exchange` why those guarantees
are upheld.
I didn't get far enough to document where those guarantees are upheld at
the call sites for `for_secret`, but they are relied upon by one of the
implementations:
303b3ff97d/rustls/src/crypto/aws_lc_rs/tls12.rs (L407-L412)
Many projects use CHANGELOG.md to convey their list of changes. Add a
link there. In README.md, instead of describing "release history",
use the "Changelog" terminology.
The top level of the crate is meant for "paved path" exports.
In 0.21.x, this type was in `cipher_suites`, along with a few other
types that got moved to specific crypto providers. Moving this to
`crypto` instead of re-exporting under its old name in `cipher_suites`
seems acceptable, because it will mainly be used in implementing crypto
providers. Also, its internals have changed significantly so there is
already churn for this type.
* Leadership -> membership.
* Clarify roles per member.
* List full-time members and funding source.
* Add Josh Aas, project management.
* Link to GitHub profiles.
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.
Joseph Birr-Pixton
Dirkjan Ochtman
Christian Poveda
Daniel McCarney
Jorge Aparicio
Geoffroy Couprie
aashish
girlbuzz
Jacob Hoffman-Andrews