- Don't list dependencies in the headline
- Remove relativistic language like "mature" and "widely"
- Remove possible future features as it is incomplete and thus misleading, should eventually replace with a roadmap
- Make it clear that Rustls provides no unsafe features *by default*
- remove self-signed certs and compression from non-features list because it's nuanced and we don't want to turn people away
- Add a list of project leadership
The existing text has fallen out of sync with `SECURITY.md` and
recommends sending security issues through regular GitHub issue, or
email to Ctz.
This commit updates the text to match what's in the up-to-date
`SECURITY.md`: use the GitHub security advisory tooling. That's what
it's made for.
This is an example that builds a mostly-unchanged rustls example
(simpleclient), but only using crypto from the rust-crypto project
and elsewhere.
This is intended to be minimalistic, and not a complete replacement
for *ring*.
It implements:
- TLS1.3 TLS13_CHACHA20_POLY1305_SHA256 cipher suite.
- TLS1.2 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 cipher suite.
- X25519 key exchange.
- RSA-PSS-SHA256 and RSA-PKCS1-SHA256 signature verification for
verifying the server, integrated into the webpki crate.
- random generation using `rand_core`.
This means it can fetch www.rust-lang.org.
TLS1.2 is not strictly necessary for this server, but serves to
demonstrate that part of the API.
This removes a further need for `Payload` to be understood outside
this crate. `payload()` allows immutable access as a slice,
`payload_mut()` allows mutable access to the underlying vec (such
as needed to decrypt the message without a copy).
The prior arrangements are still available (and the default), if the
crate is built with the *ring* feature.
`WebPkiSupportedAlgorithms` is a new structure (designed for static
construction, and direct use in webpki calls) that links
`pki_types::SignatureVerificationAlgorithm`s to their corresponding TLS `SignatureScheme`.
This replaces the hardcoded mappings in `fn convert_scheme` etc.
Using the crate without this feature means something external
needs to provide all the cryptography, and (eg) convenient integrated
key loading APIs disappear.
This is just for extreme paranoia and isn't fixing an extant issue.
It is safer to have a length prefix that is too large, so that an
accidental read of the buffer prior to the length being fixed cannot
be interpreted as an empty structure followed by something else.
eg, a `ClientExtension` (type 0x12 0x23) in this situation with body [0xff, 0x01, 0x00, 0x00]
with a zero dummy length would end up encoded as:
0x12 0x23 0x00 0x00 0xff 0x01 0x00 0x00
Which decodes as two extensions (one empty, one RenegotiationInfo). That would be bad.
Using maximal lengths:
0x12 0x23 0xff 0xff 0xff 0x01 0x00 0x00
This cannot be decoded, and prevents the body from being interpreted as
something else.
The diffs produced tend to be noisy here because two separate
compilations have different per-type and per-compilation uniqueness. eg:
```
29,792 (124.8%) ???:_ZN5alloc7raw_vec11finish_grow17h463b2c6f0ba30854E.llvm.2614985587368234107
-29,792 (-124.8%) ???:_ZN5alloc7raw_vec11finish_grow17h463b2c6f0ba30854E.llvm.3375118279659775674
```
This diff line is here because some per-compilation unique value (after the '.llvm.') changed, not
because the instruction count changed.
We can chop these out by giving a regular expression to cg_diff.
Josh Aas
Daniel McCarney
Dirkjan Ochtman
Joseph Birr-Pixton
tottoto
dependabot[bot]
Jacob Hoffman-Andrews
Adolfo Ochagavía