We currently expose this method on `SslContextBuilder`, which is fine
for bootstrapping an `SSL_CTX`, but subsequent attempts to set ECH keys
(like during key rotation) can only happen via `SslContextRef`. Also
update the method on the builder to take an immutable reference to self
because the API is thread safe.
X25519MLKEM768 is the standardised successor of the preliminary
X25519Kyber768Draft00. Latest browsers have switched to X25519MLKEM768.
Cloudflare supports both on the edge.
We've had support for X25519MLKEM768 in this crate for a while, but
didn't enable by default. We're now enabling serverside support by
default. We also let clients advertise support when set
to kx-client-pq-supported.
We don't enable support by default yet for clients set to
kx-client-pq-preferred, as that would cause an extra round-trip due to
HelloRetryRequest if the server doesn't support X25519MLKEM768 yet.
BoringSSL against which we build must support X25519MLKEM768, otherwise
this will fail.
Mid-handshake errors that occur before certificate verification
currently look like this:
```
TLS handshake failed: cert verification failed - Invalid certificate verification context [WRONG_VERSION_NUMBER]
```
Despite no certificate even being received yet, the error complains
about a failed verification. The cause here is that `cert verification
failed` is only omitted if the verification result is `OK`. The default
in BoringSSL before verification runs is `INVALID_CALL`, however.
`INVALID_CALL` is set/returned in these places:
- 44b3df6f03/src/ssl/internal.h (L3904)
- 44b3df6f03/src/ssl/ssl_session.cc (L396)
- 44b3df6f03/src/ssl/ssl_x509.cc (L713)
It is not used anywhere else as a verification result code. To improve
the error message, this commit adds `INVALID_CALL` as a verification
result for which no additional error is dislayed.
As of https://boringssl-review.googlesource.com/c/boringssl/+/64141,
X509_STORE_CTX_cleanup will zero the memory allocated to the
X509_STORE_CTX. Because X509StoreContextRef::init invokes
X509_STORE_CTX_cleanup once the with_context closure has finished,
calling X509StoreContextRef::verify_result (or any API really) is going
to be invalid because memory has been zerod out. This is a pretty big
footgun, so maybe we should consider screaming a bit louder for this
case.
This adds a feature to build against a BoringSSL version compatible with
the current boringssl-fips, but _without_ actually enabling the `fips`
feature.
This can be useful to use with `fips-link-precompiled` while using a
custom BoringSSL version based on the older FIPS branch.
set_surves_list is similar to set_curves, but the curves are specified
by a string. This makes it convenient when the supported curves of
the underlying BoringSSL is not known at compile time.
Also fix a bug in checking return value of SSL_set1_curves_list.
Our rustdocs are miserably broken. We manually link to openssl docs in
most binding definitions, and openssl keeps changing their documentation
URL, so in order to fix everything I'd have to touch every single
binding definition in every single file. Instead, we should use the
`corresponds` macro from the openssl-macros crate which nicely adds a
link to the openssl documentation on our behalf. If the openssl
documentation url ever changes again in the future, a simple dependency
bump should solve the issue.
`ForeignTypeExt` and `ForeignTypeRefExt` are inspired by
https://github.com/sfackler/rust-openssl/pull/1345, which make dealing
with FFI safer and more ergonomic. The new APIs (e.g.
from_const_ptr_opt`) also allow for gracefully handling instances where
the initial API call results in `NULL`. Instead of crashing the program,
`None` will be returned.
We previously added an `SslCurveId` struct to house SSL_CURVE variants of
the internal NID constants, to allow `SslRef::curve()` to properly
instantiate `SslCurve` structures. This was done to ensure
`SslRef::set_curves()` did not break, as it expects the internal NID
constants instead of the public SSL_CURVE ones. In future versions of
boringssl, this problem is solved by virtue of the
SSL_CTX_set1_group_ids API. Since we don't have this yet, this commit
adds `SslCurve::nid()` so `SslRef::set_curves()` can convert the
SSL_CURVE constants to the NID representation internally
without breaking the public API.
The [x509_check_host docs](https://www.openssl.org/docs/man1.1.1/man3/X509_check_host.html)
state:
> The functions return 1 for a successful match, 0 for a failed match
and -1 for an internal error: typically a memory allocation failure or
an ASN.1 decoding error.
All functions can also return -2 if the input is malformed. For example,
X509_check_host() returns -2 if the provided name contains embedded
NULs.
The current implementation will return `true` for 1, -1, and -2,
therefore returning an incorrect value if any of the above error cases
are hit.
Some functions use the NID_* constants, and some use the SSL_CURVE_* ones.
Extract from the documentation:
> Where NIDs are unstable constants specific to OpenSSL and BoringSSL, group IDs are defined by the TLS protocol. Prefer the group ID representation if storing persistently, or exporting to another process or library.
Fix three potential timing sidechannels. These don't affect ephemeral
usage of Kyber as in TLS, but it's good practice to get rid of them anyway.
Also adds IPDWing, a preliminary version of X-Wing using the initial public
draft (IPD) of ML-KEM. Don't use it.
The client sent ciphers in the ClientHello are unparsed and thus require
the user to convert u16s into SslCipher instances. It could be worth
doing this parsing in the library itself to make things consistent and
always return a StackRef<SslCipher>.
This feature expects a recent boringssl checkout (such as the one
found in boring-sys/deps/boringssl), so it should not be using
the same bindings as the fips feature, which are based on
boring-sys/deps/boringssl-fips, which is older and with a different
API.
This helps drive async callbacks from outside tokio-boring, such as in quiche.
Not a breaking change because every public item in tokio-boring is preserved as is.
Setting callbacks multiple times on a SslContextBuilder causes the previous callback
installed to leak, using replace_ex_data internally prevents that.
We also start using it in tokio-boring in with_ex_data_future, my understanding
is that the futures currently in use are never installed twice by that function
but that could change in the future with the addition of more async callbacks.
We introduce new methods replace_ex_data for both SslContextBuilder
and Ssl in case anyone is relying on the leaking behaviour of their
set_ex_data methods, but we do document that they leak now.
Feature no-patches is ever only useful when setting other env variables
BORING_BSSL{,_FIPS}{,_SOURCE}_PATH, and it has no impact on the APIs
provided by any of the boring crates, so we may as well make it an env
variable itself so downstream users have less features to propagate
across their own crate graph.
Builds using feature fips or fips-link-precompiled now
read variables prefixed by BORING_BSSL_FIPS_ instead of
BORING_BSSL_. This helps complex builds where build dependencies
also use boring, where we may not want to use fips there.
Without those separate variables, the boring build for the
build dependencies end up relying on e.g. BORING_BSSL_PATH,
causing errors if this path is a boring checkout intended for
fips builds, while the fips feature isn't enabled for
the build dependency.
This means BORING_SSL_PRECOMPILED_BCM_O is now
BORING_BSSL_PRECOMPILED_BCM_O.
Prefix BORING_BSSL_ has been chosen because that's the
one that is used the most among all the variables
the build script uses.
In boringssl, FIPS_mode_set is more or less useless, and
it doesn't even set an error stack at all on failure,
so there is no point using it instead of FIPS_mode.
To handle lifetimes better and allow returning a &mut SslRef from
the client hello struct passed to the closure from
SslContextBuilder::set_select_certificate_callback, we make
the ClientHello struct itself own a reference to the FFI
client hello struct.
These two new kinds of methods immediately return a MidHandshakeSslStream
instead of actually initiating a handshake. This greatly simplifies
loops around MidHandshakeSslStream::WouldBlock.
Overwrite boringSSL's default key exchange preferences with safe
defaults using feature flags:
* "kx-pq-supported" enables support for PQ key exchange algorithms.
Classical key exchange is still preferred, but will be upgraded to PQ
if requested.
* "kx-pq-preferred" enables preference for PQ key exchange,
with fallback to classical key exchange if requested.
* "kx-nist-required" disables non-NIST key exchange.
Each feature implies "kx-safe-default". When this feature is enabled,
don't compile bindings for `SSL_CTX_set1_curves()` and `SslCurve`. This
is to prevent the feature flags from silently overriding curve
preferences chosen by the user.
Ideally we'd allow both: that is, use "kx-*" to set defaults, but still
allow the user to manually override them. However, this doesn't work
because by the time the `SSL_CTX` is constructed, we don't yet know
whether we're the client or server. (The "kx-*" features set different
preferences for each.) If "kx-sfe-default" is set, then the curve
preferences are set just before initiating a TLS handshake
(`SslStreamBuilder::connect()`) or waiting for a TLS handshake
(`SslStreamBuilder::accept()`).
Rushil Mehra