_Known_ extensions are already checked by code in the previous commit.
But we also need to check _unknown_ extensions which are otherwise
discarded during decoding.
Instead of `Vec<ClientExtension>`, store the extension data as
a struct. This is possible because past commits have removed
the need for this us to losslessly round-trip extension data.
This involves fewer allocations to construct the extensions for clients.
It eliminates repeated iteration of the vector to find specific extensions
when processing a `ClientHello` for servers. It also reduces
the cost of detecting duplicate extensions.
Verifying a _received_ `ClientHello` binder should be done
against the original received bytes, not our re-encoding of them.
This previously worked, because we required and tested that
we could round-trip `ClientHello` messages (and others). This
is about to become not true.
The vast majority of Cargo features in the crates ecosystem use dashes
to separate words, rather than underscores. The fact that `aws_lc_rs`
uses underscores, and some crates depending on rustls naturally use the
same name for the feature that rustls does, has led some crates to end
up with inconsistent feature naming that throws people off (e.g. using
the wrong feature name and being surprised at the resulting compilation
failures), and has led other crates to use `aws-lc-rs` for consistency
with their other features which causes inconsistency with rustls.
Add an alias, so that it works either way, and people can reference
either one.
This is complaining about the import of the `env` module from
`std::env`, instead of `core::env`.
However, `core::env` is a completely different item -- it is
the `env!` macro.
Unfortunately the alias doesn't allow passing in custom arguments like
`--all` or `--manifest-path`. Doing so in the manner we tried before
results in output like:
```
> Run cargo fmt-unstable --all --manifest-path=connect-tests/Cargo.toml -- --check
Unrecognized option: 'all'
```
This commit switches to the full `cargo fmt` invocation in each case.
55bb27953d inadvertently changed `extract_keys`
to always return `ConnectionTrafficSecrets::Aes128Gcm`, even when AES-256-GCM
was negotiated. This change fixes it by restoring the key length check.
Fixes#1833
These are nightly-only options: so keep them in a separate file.
When it sees unstable features, stable rustfmt gives a diagnostic like:
> Warning: can't set `imports_granularity = Module`, unstable features are only available in nightly channel.
> Warning: can't set `group_imports = StdExternalCrate`, unstable features are only available in nightly channel.
But: _does_ otherwise format the files and exit non-zero. However, this is noisy.
We arrange that `cargo +nightly fmt-unstable` also does the right thing.
The docs.rs environment has golang installed, but doesn't have
the environment variables needed to make it actually work:
https://github.com/rust-lang/docs.rs/issues/1303
So avoid that entirely.
Fixes a missing import error when building without std and with
aws_lc_rs:
```
$ cargo check -p rustls --no-default-features --features aws_lc_rs
Compiling rustls v0.23.0 (/home/daniel/Code/Rust/rustls/rustls)
error[E0432]: unresolved import `ticketer`
--> rustls/src/crypto/aws_lc_rs/mod.rs:228:9
|
228 | pub use ticketer::Ticketer;
| ^^^^^^^^ use of undeclared crate or module `ticketer`
```
Adding a `std` gate on `TICKETER_AEAD` was also required to fix unused
warnings for builds w/o `std` using either ring or aws_lc_rs:
```
$ cargo check -p rustls --no-default-features --features aws_lc_rs
Compiling rustls v0.23.0 (/home/daniel/Code/Rust/rustls/rustls)
warning: static `TICKETER_AEAD` is never used
--> rustls/src/crypto/aws_lc_rs/mod.rs:249:19
|
249 | pub(super) static TICKETER_AEAD: &ring_like::aead::Algorithm = &ring_like::aead::AES_256_GCM;
| ^^^^^^^^^^^^^
|
= note: `#[warn(dead_code)]` on by default
```
Our daily tests CI job runs some additional tests that are too slow or
too flaky to be run for every merge requests. Before doing a release
it's a good idea to run this workflow manually to make sure there aren't
any lurking regressions that `cargo hack` or another test from this
workflow could catch pre-release.
This commit adds that guidance to `RELEASING.md` for future releases.
This commit adds a `quic::Suite` struct for representing the combination
of a `Tls13CipherSuite` and a `quic::Algorithm`. This can optionally be
constructed from a `Tls13CipherSuite` that supports QUIC. Having this
type helps downstream users that otherwise need to juggle the
`Option<quic::Algorithm>` and `Option<Tls13CipherSuite>` from
a `SupportedCipherSuite` separately.
When holding a `ClientConfig` or a `ServerConfig` it may be helpful to
be able to access the `&Arc<CryptoProviver>` that will be used for the
configuration. This commit adds accessor functions for this purpose.
Previously the `CipherSuiteCommon` type had a `confidentiality_limit`
and a `integrity_limit`. Recent refactoring for better downstream
QUIC ergonomics has pulled these limits into the `quic::PacketKey`
trait. To reduce duplication this commit adjusts our handling of these
two limits.
For the `integrity_limit`, it was already documented in
`CipherSuiteCommon` as being specific to QUIC and irrelevant for TLS
over TCP. For this reason we delete the field from `CipherSuiteCommon`,
leaving it only in `quic::PacketKey` where it is actually useful.
For the `confidentiality_limit` it was described imprecisely and erred
on the side of caution, proposing a limit calculated based on QUIC
overhead even for the TCP usecase. Now that we've split this field the
`CipherSuiteCommon` version's documentation is updated to use a tighter
bound for the TCP use-case, and the associated `PacketKey` field can be
documented to use the QUIC bound.
The `append_hs` function of the `MessageDeframer` (used only by QUIC
connections) mishandles the case where we were in the process of
deframing a QUIC HS message that required joining.
When copying a payload of the fragmented HS message into the deframer
buffer the `DeframerBuffer<'a, ExternalPayload<'a>>` trait
implementation for `DeframerVecBuffer` _already_ positioned the write
into the unfilled section of the buffer, `self.unfilled()` (e.g.
`self.buf[self.used..]`).
However, the branch of `append_hs` that continues processing of joining
a fragmented HS message was incorrectly further offsetting the copy
position by `meta.payload.end`, which is equal to `self.used` at this
point. In effect trying to write to `self.buf[self.used+self.used..]`.
As a result, if we have buffered more than half the capacity of
`self.buf` and then attempt to join in more payload bytes, the unfilled
offset is outside the bounds of `buf` and an out-of-bounds indexing
panic occurs.
This commit adds a simple integration test, as well as a fix.
This fixes a wedge of instances of:
```
warning: the item `String` is imported redundantly
--> rustls/src/msgs/handshake.rs:27:5
|
27 | use alloc::string::String;
| ^^^^^^^^^^^^^^^^^^^^^
```
Where `String` is present from the std prelude when built
for testing. Like we just did in webpki, _always_ opt-in
to no_std, and then import the std prelude in tests where
necessary.
Joseph Birr-Pixton
Daniel McCarney
Josh Triplett
dependabot[bot]
Arnav Singh
Yuxiang Cao
Dirkjan Ochtman