The "kx-*" features control default key exchange preferences. Its
implementation requires disabling APIs for manually setting curve
preferences via `set_curves()` or `set_curves_list()`.
In practice, most teams need to be able to override default preferences
at runtime anyway, which means these features were never really used.
This commit gets rid of them, thereby reducing some complexity in the
API.
SslStream::new() is fallible, but `SslStream::from_raw_parts()` and
`SslStreamBuilder::new()` now unwrap. Upstream has also deprecated the
`SslStreamBuilder`, maybe we should do the same.
Per BoringSSL's FIPS policy, its `main` branch is the "update branch"
for FedRAMP compliance's purposes.
This means that we can stop using a specific BoringSSL branch when
enabling FIPS, as well as a number of hacks that allowed us to build
more recent BoringSSL versions with an older pre-compiled FIPS modules.
This also required slightly updating the main BoringSSL submodule, as
the previous version had an issue when building with the FIPS option
enabled. This is turn required some changes to the PQ patch as well as
some APIs that don't seem to be exposed publicly, as well as changing
some paths in the other patches.
In order to allow a smooth upgrade of internal projects, the `fips-compat`
feature is reduced in scope and renamed to `legacy-compat-deprecated` so
that we can incrementally upgrade internal BoringSSL forks. In practice
this shouldn't really be something anyone else would need, since in
order to work it requires a specific mix of BoringSSL version and
backported patches.
This method reliably retrieves the certificate the `X509_STORE_CTX` is
verifying, unlike `X509_STORE_CTX_get_current_cert`, which may return
the "problematic" cert when verification fails.
Newer versions of FIPS don't need any special casing in our bindings,
unlike the submoduled boringssl-fips. In addition, many users currently
use FIPS by precompiling BoringSSL with the proper build tools and
passing that in to the bindings.
Until we adopt the Update Stream pattern for FIPS, there are two main
use cases:
1. Passing an unmodified, precompiled FIPS validated version of
boringssl (fips-precompiled)
2. Passing a custom source directory of boringssl meant to be linked
with a FIPS validated bcm.o. This is mainly useful if you carry
custom patches but still want to use a FIPS validated BoringCrypto.
(fips-link-precompiled)
This commit introduces the `fips-precompiled` feature and removes the
`fips-no-compat` feature.
The "fips" feature implies use of a prebuilt boringSSL. The boringSSL
API consumed by `SslCurve` in incompatible with older versions of
boringSSL.
In the `ffi` bindings, the following symbols don't exist in older
builds:
* NID_X25519MLKEM768
* SSL_CURVE_X25519_MLKEM768
* NID_X25519Kyber768Draft00Old
The following symbols have been renamed:
* SSL_CURVE_P256KYBER768DRAFT00 => SSL_CURVE_P256_KYBER768_DRAFT00
* SSL_CURVE_X25519KYBER512DRAFT00 => SSL_CURVE_X25519_KYBER512_DRAFT00
* SSL_CURVE_X25519KYBER768DRAFT00OLD => SSL_CURVE_X25519_KYBER768_DRAFT00_OLD
* SSL_CURVE_P256KYBER768DRAFT00 => SSL_CURVE_P256_KYBER768_DRAFT00
Meanwhile, the `ssl_set_curves_list()` API is stable across these
versions of boringSSL.
These codepoints are added to the `SslCurve` API whenever
"pq-experimental" is enabled. Since this feature is no longer mutually
exclusive with prebuilt boringSSL (`boring-sys` just ignores patches),
we also need to disable this API whenever "fips" is enabled.
Modify the "fips" feature so that it no longer implies "fips-compat".
The latter is no longer needed for recent builds of boringSSL; users who
need older builds will need to enable "fips-compat" explicitly.
Also, remove the "fipps-no-compat" feature, as it's now equivalent to
"fips".
As of boringSSL commit a430310d6563c0734ddafca7731570dfb683dc19, we no
longer need to make exceptions for the types of BufLen, ProtosLen, and
ValueLen, which means the "fips-compat" feature is no longer needed for
"fips" users.
Currently "fips" implies "fips-compat". To allow users to upgrade
without breaking API compatibility with boring version 4, add a new
feature, "fips-no-compat", that does not imply "fips-compat".
In boring 5, we should remove "fips-no-compat" and decouple
"fips-compat" from "fips".
This algorithm is advertised with "kx-client-pq-supported" but not with
"preferred". However the algorithm is wide spread enough that preferring
it is not a significant risk.
See https://github.com/sfackler/rust-openssl/pull/2360 and
https://nvd.nist.gov/vuln/detail/CVE-2025-24898. From the rust-openssl
PR:
`SSL_select_next_proto` can return a pointer into either the client or
server buffers, but the type signature of the function previously only
bound the output buffer to the client buffer. This can result in a UAF
in situations where the server slice does not point to a long-lived
allocation.
Thanks to Matt Mastracci for reporting this issue.
Previously, set_ech_keys would consume the SslEchKeys struct to enforce
the requirement that the struct is immutable after initializing it on a
SSL_CTX. The problem with this is that it requires applications to
needlessly reallocate the SslEchKeys struct if they want to initialize
keys on multiple SSL_CTXs, which is a pretty common pattern. To work
around this, we introduce a builder (SslEchKeysBuilder) that requires
mutable access to add keys to the underlying struct. set_ech_keys takes
in a reference to SslEchKeys, which can only be made via consuming the
builder.
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.
Apoorv Kothari