* RTG-3333 Support X25519MLKEM768 by default, but don't sent it as client
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.
* replace once_cell with LazyLock
We can drop the once_cell dependency since the same functionality is
implemented in std now.
Requires bumping MSRV to 1.80.
* fix manual_c_str_literals clippy warning
* chore: Fix docs on SslRef::replace_ex_data
---------
Co-authored-by: Bas Westerbaan <bas@cloudflare.com>
Co-authored-by: Alessandro Ghedini <alessandro@cloudflare.com>
Co-authored-by: Evan Rittenhouse <erittenhouse@cloudflare.com>
* RTG-3333 Support X25519MLKEM768 by default, but don't sent it as client
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.
* replace once_cell with LazyLock
We can drop the once_cell dependency since the same functionality is
implemented in std now.
Requires bumping MSRV to 1.80.
* fix manual_c_str_literals clippy warning
---------
Co-authored-by: Bas Westerbaan <bas@cloudflare.com>
Co-authored-by: Alessandro Ghedini <alessandro@cloudflare.com>
* RTG-3333 Support X25519MLKEM768 by default, but don't sent it as client
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.
* feat: Add kDHE && ffdhe2048/ffdhe3072 curves working implement
* Update
---------
Co-authored-by: Bas Westerbaan <bas@cloudflare.com>
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.
Co-authored-by: Bas Westerbaan <bas@cloudflare.com>
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.
* Release 4.10.3 (#280)
* Create semgrep.yml
Creating Semgrep.yml file - Semgrep is a tool that will be used to scan Cloudflare's public repos for Supply chain, code and secrets. This work is part of Application & Product Security team's initiative to onboard Semgrep onto all of Cloudflare's public repos.
In case of any questions, please reach out to "Hrushikesh Deshpande" on cf internal chat.
* Add "fips-compat" feature (#286)
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.
* boring-sys: include HPKE header file for bindgen
BoringSSL doesn't expose these APIs for FIPs builds, so we gate them
here as well
* Release 4.11.0
* Add `set_cert_verify_callback` (`SSL_CTX_set_cert_verify`)
Add a wrapper for `SSL_CTX_set_cert_verify`, which allows consumers to
override the default certificate verification behavior.
The binding resembles `SSL_CTX_set_verify`'s.
See
https://docs.openssl.org/master/man3/SSL_CTX_set_cert_verify_callback/
for more details.
* Skip bindgen 0.70's layout tests before Rust 1.77
* (ci): brew link x86 toolchain for macos13 runner
It seems we need to manually symlink the x86_64-unknown-linux-gnu
toolchain for the macos13 runner. Also, we don't need to overwrite the
python version anymore
Fixes https://github.com/cloudflare/boring/issues/285
* feat(boring): Add SSL_CURVE_X25519_MLKEM768 curve binding
---------
Co-authored-by: Rushil Mehra <84047965+rushilmehra@users.noreply.github.com>
Co-authored-by: Hrushikesh Deshpande <161167942+hrushikeshdeshpande@users.noreply.github.com>
Co-authored-by: Alessandro Ghedini <alessandro@cloudflare.com>
Co-authored-by: Evan Rittenhouse <erittenhouse@cloudflare.com>
Co-authored-by: James Larisch <jlarisch@cloudflare.com>
Co-authored-by: Jordan Rose <jrose@signal.org>
Co-authored-by: Rushil Mehra <rmehra@cloudflare.com>
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.
0x676e67