We've addressed this lint's findings in `main`. For the 0.21.x release
stream, allow the finding and leave the code unchanged for minimal
semver impact.
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.
The `Tls12CipherSuite::hash_algorithm` and
`Tls13CipherSuite::hash_algorithm` functions were meant to be crate
internal, since their return type leaks the `ring::digest::Algorithm`
type. As written today these fns make updates to `*ring*` a breaking
change for the Rustls API.
This commit switches the visibility of both functions to be
crate-internal. Strictly speaking this is a breaking change, but we
don't expect there to be consumers of these functions and it unblocks
a *ring* update that would otherwise be breaking on its own.
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 `RootCertStore` type is used for both client and server trust
anchors. This commit deprecates the inappropriately named
`add_server_trust_anchors` fn and adds a new `add_trust_anchors` fn to
use in its place.
This commit updates the `build.yml` GitHub actions workflow to
additionally include a step that checks semver compatibility w/
cargo-semver-checks[0].
Notably this check passing is necessary but not sufficient for knowing
that we're maintaining semver: if this tool produces a finding we know
we aren't matching semver, but if it doesn't, we may still be breaking
semver in a way the tool can't detect.
[0]: https://github.com/obi1kenobi/cargo-semver-checks
This commit renames the `ClientConfig` builder's `with_single_cert`
function to be called `with_client_auth_cert`. The old
`with_single_cert` function is left as an alias for
`with_client_auth_cert` and marked as deprecated to encourage users to
switch to the new name.
I believe this offers better symmetry with the `with_no_client_auth`
function that's used to disable client authentication, and more clearly
conveys the purpose of this function is for providing a client
authentication certificate.
Fixes:
```
warning: this URL is not a hyperlink
--> rustls/src/error.rs:427:15
|
427 | /// [^1]: https://www.rfc-editor.org/rfc/rfc5280#section-5.3.1
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: use an automatic link instead: `<https://www.rfc-editor.org/rfc/rfc5280#section-5.3.1>`
|
= note: bare URLs are not automatically turned into clickable links
= note: `#[warn(rustdoc::bare_urls)]` on by default
```
The top level `Error::InvalidCertRevocationList` was
exported, but not its inner `CertRevocationListError` enum. This should
be done to match other enums (e.g. the `Error::InvalidCertificate`'s
exported `CertificateError` enum).
This commit introduces `api.rs` integration tests that verify
a server configured with client authentication (mandatory or optional),
and a CRL that specifies a client cert as revoked, will correctly return
a revoked error for that client cert.
In addition to the test CRL data generated in a previous commit this
work requires `rustls-pemfile` >= 1.0.3 to use unreleased CRL support in
the `rustls-pemfile` crate. The rustls dev-dependency and the rustls
example dependency on this crate are adjusted accordingly.
This commit updates the `build-a-pki.sh` script to generate example
certificate revocation lists (CRLs) that mark each of the client
certificates as revoked. These can be used by server tests to ensure CRL
validation works as expected.
The process of generating CRLs using `openssl` is... well... not
great...
It can't be done without using `openssl ca`, which in turn requires
using an `openssl.cnf` with all the associated warts. I've done my best
to create the absolute minimum configuration that can be used for our
purposes.
Using `openssl ca` also requires writing some intermediate state. The
script is updated to create/delete this state through the process of
generating the CRLs. This should be sufficient for our needs. Blech.
This commit introduces a `crls: Vec<webpki::OwnedCertRevocationList>>`
field to the `AllowAnyAuthenticatedClient` implementation of
`ClientCertVerifier` in preparation of supporting revocation checking of
client certs with CRLs.
Each impl gets a builder-style `with_crls` method that can be used to
augment the verifier with CRLs to use for client cert revocation status
checking.
The constructed cert revocation lists are provided to webpki at cert
verification time to use for revocation lookup.
The `tlsserver-mio` example is updated with a `--crl` flag to the
that can be used to optionally provide a series of DER encoded CRLs to
use for client certificate revocation checking.
Daniel McCarney
Geoffroy Couprie
Joseph Birr-Pixton
Robsdedude
Dirkjan Ochtman
dAxpeDDa