Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Expose client-side ECH #282

Closed
jrose-signal opened this issue Sep 27, 2024 · 1 comment · Fixed by #309
Closed

Expose client-side ECH #282

jrose-signal opened this issue Sep 27, 2024 · 1 comment · Fixed by #309
Assignees
@rushilmehra

Comments

@jrose-signal
Copy link
Contributor

Now that Cloudflare is rolling out ECH again, it'd be great to see the ECH client APIs exposed in boring:

  • SSL_set1_ech_config_list for basic support
  • SSL_get0_ech_retry_configs for recovery from key mismatches
  • SSL_get0_ech_name_override for custom verifiers to support fallback to non-ECH
  • SSL_ech_accepted for completeness

The server APIs would also be good to add, and might be the best way to write a test, but they're a little more involved (EVP_HPKE_KEY has to be exposed in order to provide SSL_ECH_KEYS_add).
@rushilmehra
Copy link
Collaborator

Hi, yes, I'll be getting to this shortly as we want to implement ECH for some internal rust projects. I'll add the client APIs as well. Will use this issue to track

@rushilmehra rushilmehra self-assigned this Sep 27, 2024
rushilmehra added a commit to rushilmehra/boring that referenced this issue Feb 10, 2025
@rushilmehra
Expose client/server-side ECH
cca9bd2 
Resolves cloudflare#282
@rushilmehra rushilmehra mentioned this issue Feb 10, 2025
Merged
rushilmehra added a commit to rushilmehra/boring that referenced this issue Feb 10, 2025
@rushilmehra
Expose client/server-side ECH
b00a47d 
Resolves cloudflare#282
rushilmehra added a commit to rushilmehra/boring that referenced this issue Feb 10, 2025
@rushilmehra
Expose client/server-side ECH
e1bbaab 
Resolves cloudflare#282
rushilmehra added a commit to rushilmehra/boring that referenced this issue Feb 11, 2025
@rushilmehra
Expose client/server-side ECH
4100155 
Resolves cloudflare#282
rushilmehra added a commit to rushilmehra/boring that referenced this issue Feb 11, 2025
@rushilmehra
Expose client/server-side ECH
9ac89ea 
Resolves cloudflare#282
rushilmehra added a commit to rushilmehra/boring that referenced this issue Feb 12, 2025
@rushilmehra
Expose client/server-side ECH
5ced63c 
Resolves cloudflare#282
kornelski pushed a commit that referenced this issue Feb 12, 2025
@rushilmehra @kornelski
Expose client/server-side ECH
5af8291 
Resolves #282
0x676e67 added a commit to 0x676e67/boring2 that referenced this issue Feb 12, 2025
@0x676e67 @bwesterb
@ghedo @evanrittenhouse @kornelski @rushilmehra
Expose client/server-side ECH (#48)
d1f73a9 
* 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 cloudflare/boring#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>
0x676e67 added a commit to 0x676e67/boring2 that referenced this issue Feb 13, 2025
@0x676e67 @bwesterb
@ghedo @evanrittenhouse @kornelski @rushilmehra
Expose SSL_set_enable_ech_grease (#49)
e82939f 
* 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 cloudflare/boring#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>
0x676e67 added a commit to 0x676e67/boring2 that referenced this issue Feb 13, 2025
@0x676e67 @bwesterb
@ghedo @evanrittenhouse @kornelski @rushilmehra
Use corresponds macro (#50)
0d30ebf 
* 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 cloudflare/boring#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>
0x676e67 added a commit to 0x676e67/boring2 that referenced this issue Feb 23, 2025
@0x676e67 @bwesterb
@ghedo @evanrittenhouse @kornelski @rushilmehra
sync upstream (#54)
7ee98f6 
* 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 cloudflare/boring#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:
rust-lang/cmake-rs#229

This means we don't need e6833b0

* 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 49d5a61.

* Revert "Refactor!: Remove strict `TokioIo` response requirement from `hyper_boring::v1::HttpsConnector`"

This reverts commit e518c24.

* 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>
0x676e67 added a commit to 0x676e67/boring2 that referenced this issue Feb 24, 2025
@0x676e67 @bwesterb
@ghedo @evanrittenhouse @kornelski @rushilmehra
Fix lifetimes in ssl::select_next_proto (#55)
657dcc2 
* 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 cloudflare/boring#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:
rust-lang/cmake-rs#229

This means we don't need e6833b0

* 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 49d5a61.

* Revert "Refactor!: Remove strict `TokioIo` response requirement from `hyper_boring::v1::HttpsConnector`"

This reverts commit e518c24.

* 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 sfackler/rust-openssl#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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rushilmehra rushilmehra

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Expose client/server-side ECH rushilmehra/boring
2 participants
@jrose-signal @rushilmehra