* 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
* Detailed error codes
* Clean up boring_sys::init()
We don't need the workaround that was initially introduced for a bug in
openssl, and OPENSSL_init_ssl always calls into CRYPTO_library_init on
boringssl, so just call it explicitly.
* Expose EVP_HPKE_KEY
* Expose client/server-side ECH
Resolves https://github.com/cloudflare/boring/issues/282
* Clean up ECH tests
* Expose SSL_set_enable_ech_grease
* Use corresponds macro
* build: Fix the build for 32-bit Linux platform (#312)
build: Fix the build for 32-bit Linux platform
* Set CMAKE_BUILD_PARALLEL_LEVEL to available_parallelism
cmake-rs' jobserver doesn't work reliably, if at all. One workaround is
to set CMAKE_BUILD_PARALLEL_LEVEL to available_parallelism(). On my
machine it shaves ~35 seconds off of boring-sys builds.
* Expose SSL_CTX_set1_ech_keys from SslContextRef
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.
* Bump cmake-rs to improve Mac OS build parallelism
There's a bug on OSX that prevents the CMake jobserver from working
properly, and so CMake defaults to a single-threaded build. It's not
clear when this is actually going to get fixed, so recent versions of
cmake-rs just disable the jobserver and have CMake fall back to the
number of available cores:
https://github.com/rust-lang/cmake-rs/pull/229
This means we don't need e6833b0074
* Release 4.14.0 (#317)
* Actually expose SslEchKeys
* Address clippy lints
* Revert "Refactor!: Introduce a Cargo feature for optional Hyper 0 support"
This reverts commit 49d5a61163.
* Revert "Refactor!: Remove strict `TokioIo` response requirement from `hyper_boring::v1::HttpsConnector`"
This reverts commit e518c2444a.
* Introduce a builder pattern for SslEchKeys + make set_ech_keys take a reference (#320)
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.
* Revert cmake bump (for now) as it is overly restrictive (#321)
Some users of boring have issues with newer versions of cmake. Because
we have an alternative solution, we can hold off on the bump for now.
* Fix lifetimes in ssl::select_next_proto
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.
---------
Co-authored-by: Bas Westerbaan <bas@cloudflare.com>
Co-authored-by: Alessandro Ghedini <alessandro@cloudflare.com>
Co-authored-by: Evan Rittenhouse <erittenhouse@cloudflare.com>
Co-authored-by: Kornel <kornel@cloudflare.com>
Co-authored-by: Rushil Mehra <rmehra@cloudflare.com>
Co-authored-by: Rushil Mehra <84047965+rushilmehra@users.noreply.github.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
* chore: Fix docs on SslRef::replace_ex_data
* Detailed error codes
* Clean up boring_sys::init()
We don't need the workaround that was initially introduced for a bug in
openssl, and OPENSSL_init_ssl always calls into CRYPTO_library_init on
boringssl, so just call it explicitly.
* Expose EVP_HPKE_KEY
* Expose client/server-side ECH
Resolves https://github.com/cloudflare/boring/issues/282
* Clean up ECH tests
* Expose SSL_set_enable_ech_grease
* Use corresponds macro
* build: Fix the build for 32-bit Linux platform (#312)
build: Fix the build for 32-bit Linux platform
* Set CMAKE_BUILD_PARALLEL_LEVEL to available_parallelism
cmake-rs' jobserver doesn't work reliably, if at all. One workaround is
to set CMAKE_BUILD_PARALLEL_LEVEL to available_parallelism(). On my
machine it shaves ~35 seconds off of boring-sys builds.
* Expose SSL_CTX_set1_ech_keys from SslContextRef
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.
* Bump cmake-rs to improve Mac OS build parallelism
There's a bug on OSX that prevents the CMake jobserver from working
properly, and so CMake defaults to a single-threaded build. It's not
clear when this is actually going to get fixed, so recent versions of
cmake-rs just disable the jobserver and have CMake fall back to the
number of available cores:
https://github.com/rust-lang/cmake-rs/pull/229
This means we don't need e6833b0074
* Release 4.14.0 (#317)
* Actually expose SslEchKeys
* Address clippy lints
* Revert "Refactor!: Introduce a Cargo feature for optional Hyper 0 support"
This reverts commit 49d5a61163.
* Revert "Refactor!: Remove strict `TokioIo` response requirement from `hyper_boring::v1::HttpsConnector`"
This reverts commit e518c2444a.
* Introduce a builder pattern for SslEchKeys + make set_ech_keys take a reference (#320)
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.
* Revert cmake bump (for now) as it is overly restrictive (#321)
Some users of boring have issues with newer versions of cmake. Because
we have an alternative solution, we can hold off on the bump for now.
---------
Co-authored-by: Bas Westerbaan <bas@cloudflare.com>
Co-authored-by: Alessandro Ghedini <alessandro@cloudflare.com>
Co-authored-by: Evan Rittenhouse <erittenhouse@cloudflare.com>
Co-authored-by: Kornel <kornel@cloudflare.com>
Co-authored-by: Rushil Mehra <rmehra@cloudflare.com>
Co-authored-by: Rushil Mehra <84047965+rushilmehra@users.noreply.github.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
* chore: Fix docs on SslRef::replace_ex_data
* Detailed error codes
* Clean up boring_sys::init()
We don't need the workaround that was initially introduced for a bug in
openssl, and OPENSSL_init_ssl always calls into CRYPTO_library_init on
boringssl, so just call it explicitly.
* Expose EVP_HPKE_KEY
* Expose client/server-side ECH
Resolves https://github.com/cloudflare/boring/issues/282
* Clean up ECH tests
* Expose SSL_set_enable_ech_grease
* update
* Use corresponds macro
---------
Co-authored-by: Bas Westerbaan <bas@cloudflare.com>
Co-authored-by: Alessandro Ghedini <alessandro@cloudflare.com>
Co-authored-by: Evan Rittenhouse <erittenhouse@cloudflare.com>
Co-authored-by: Kornel <kornel@cloudflare.com>
Co-authored-by: Rushil Mehra <rmehra@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
* chore: Fix docs on SslRef::replace_ex_data
* Detailed error codes
* Clean up boring_sys::init()
We don't need the workaround that was initially introduced for a bug in
openssl, and OPENSSL_init_ssl always calls into CRYPTO_library_init on
boringssl, so just call it explicitly.
* Expose EVP_HPKE_KEY
* Expose client/server-side ECH
Resolves https://github.com/cloudflare/boring/issues/282
* Clean up ECH tests
* Expose SSL_set_enable_ech_grease
* update
---------
Co-authored-by: Bas Westerbaan <bas@cloudflare.com>
Co-authored-by: Alessandro Ghedini <alessandro@cloudflare.com>
Co-authored-by: Evan Rittenhouse <erittenhouse@cloudflare.com>
Co-authored-by: Kornel <kornel@cloudflare.com>
Co-authored-by: Rushil Mehra <rmehra@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
* chore: Fix docs on SslRef::replace_ex_data
* Detailed error codes
* Clean up boring_sys::init()
We don't need the workaround that was initially introduced for a bug in
openssl, and OPENSSL_init_ssl always calls into CRYPTO_library_init on
boringssl, so just call it explicitly.
* Expose EVP_HPKE_KEY
* Expose client/server-side ECH
Resolves https://github.com/cloudflare/boring/issues/282
---------
Co-authored-by: Bas Westerbaan <bas@cloudflare.com>
Co-authored-by: Alessandro Ghedini <alessandro@cloudflare.com>
Co-authored-by: Evan Rittenhouse <erittenhouse@cloudflare.com>
Co-authored-by: Kornel <kornel@cloudflare.com>
Co-authored-by: Rushil Mehra <rmehra@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
* 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>
* 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.
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.
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.
0x676e67