9 ms·

Finally encrypted client hello support \o/

by capitol_ 5mo ago

bombcar 5mo ago
Is this something that we can enable "today" or is it going to take 12 years for browsers and servers to support?
- arcfour 5mo ago
  CloudFlare has supported it since 2023: https://blog.cloudflare.com/announcing-encrypted-client-hello/and https://blog.cloudflare.com/announcing-encrypted-client-hell... Firefox has had it enabled by default since version 119: https://support.mozilla.org/en-US/kb/faq-encrypted-client-hello#w_how-do-i-enable-ech-in-firefox https://support.mozilla.org/en-US/kb/faq-encrypted-client-he... so you can use it today.
  - bombcar 5mo ago
    https://tls-ech.dev https://tls-ech.dev indicates that Safari doesn't support it, but Chrome does.
    - altairprime 5mo ago
      That’s likely due to iOS/macOS not supporting it in production-default-enabled yet; there’s an experimental opt-in flag at the OS level, but Safari apparently hasn’t (yet) added a dev feature switch for it. https://developer.apple.com/documentation/security/sec_protocol_options_set_enable_encrypted_client_hello https://developer.apple.com/documentation/security/sec_proto... Presumably anyone besides Safari can opt-in to that testing today, but I wouldn’t ship it worldwide and expect nice outcomes until (I suspect) after this fall’s 27 releases. Maybe someone could PR the WebKit team to add that feature flag in the meantime?
  - 1vuio0pswjnm7 5mo ago
    "... so you can use it today." What if he wanted to use it for requesting blog.cloudflare.com ;; ANSWER SECTION: blog.cloudflare.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.18.28.7,104.18.29.7 ipv6hint=2606:4700::6812:1c07,2606:4700::6812:1d07 Where are the ECH keys For example, ;; ANSWER SECTION: test.defo.ie. 300 IN HTTPS 1 . ech="AEb+DQBCqQAgACBlm7cfDx/gKuUAwRTe+Y9MExbIyuLpLcgTORIdi69uewAEAAEAAQATcHVibGljLnRlc3QuZGVmby5pZQAA" or ;; ANSWER SECTION: cloudflare-ech.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.18.10.118,104.18.11.118 ech="AEX+DQBBpQAgACB/RU5hAC5mXe3uOZtNY58Bc8UU1cd4QBxQzqirMlWZeQAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA=" ipv6hint=2606:4700::6812:a76,2606:4700::6812:b76 It's true one can "use it today". One could use it for the past several years as well. The software has been around for a while But ECH has never been consistently enabled for the general public beyond a small number of test sites that are only for testing ECH
- kro 5mo ago
  Nginx mainline 1.29.x supports it. So once you get that and also the openssl version on your system, good to go. Likely too late for ubuntu 26.04, maybe in debian 14 next year, or of course rolling release distros / containers. But, in a personal/single website server, ech does not really add privacy, adversaries can still observe the IP metadata and compare what's hosted there. The real benefits are on huge cloud hosting platforms.
  - Bender 5mo ago
    FWIW Nginx 1.30 [1] just released and supports it so most distributions will have support as soon as those responsible for builds and testing builds push it forward. "Nginx 1.30 incorporates all of the changes from the Nginx 1.29.x mainline branch to provide a lot of new functionality like Multipath TCP (MPTCP)." "Nginx 1.30 also adds HTTP/2 to backend and Encrypted Client Hello (ECH), sticky sessions support for upstreams, and the default proxy HTTP version being set to HTTP/1.1 with Keep-Alive enabled." But, in a personal/single website server, ech does not really add privacy, adversaries can still observe the IP metadata and compare what's hosted there I don't quite follow. I have dozens of throw-away silly hobby domains. I can use any of them as the outer-SNI. How is someone observing the traffic going to know the inner-SNI domain unless someone builds a massive database of all known inner+outer combinations which can be changed on a whim? ECH requires DOH so unless the ISP has tricked the user into using their DOH end-point they can't see the HTTPS resource record. [1] - https://news.ycombinator.com/item?id=47770007 https://news.ycombinator.com/item?id=47770007
    - ameliaquining 5mo ago
      It's not that adversaries can directly see the domain name; this doesn't have anything to do with domain fronting. The issue is that ECH doesn't hide the server's IP address, so it's mostly useless for privacy if that IP address uniquely identifies that server. The situation where it helps is if the server shares that IP address with lots of other people, i.e., if it's behind a big cloud CDN that supports ECH (AFAIK that's currently just Cloudflare). But if that's the case, it doesn't matter whether Nginx or whatever other web server you run supports ECH, because your users' TLS negotiations aren't with that server, they're with Cloudflare.
- tialaramex 5mo ago
  TLS (the IETF Working Group not the protocol family named for them) have long experience with the fact that if you specify how B is compatible with A based on how you specified A and ship B what you did won't work because the middleboxes are all cost optimized and don't implement what you specified but instead whatever got the sale for the least investment. So e.g. they'd work for exactly the way you use say TLS 1.0 in the Netscape 4 web browser which was popular when the middlebox was first marketed, or maybe they cope with exactly the features used in Safari but since Safari never sets this bit flag here they reject all connections with that flag. What TLS learned is summarized as "have one joint and keep it well oiled" and they invented a technique to provide that oiling for one working joint in TLS, GREASE, Generate Random Extensions And Sustain Extensibility. The idea of GREASE is, if a popular client (say, the Chrome web browser) just insists on uttering random nonsense extensions then to survive in the world where that happens you must not freak out when there are extensions you do not understand. If your middlebox firmware freaks out when seeing this happen, your customers say "This middlebox I bought last week is broken, I want my money back" so you have to spend a few cents more to never do that. But, since random nonsense is now OK, we can ship a new feature and the middleboxes won't freak out, so long as our feature looks similar enough to GREASE. ECH achieves the same idea, when a participating client connects to a server which does not support ECH as far as it knows, it acts exactly the same as it would for ECH except, since it has neither a "real" name to hide nor a key to encrypt that name it fills the space where those would fit with random gibberish. As a server, you get this ECH extension you don't understand, and it is filled with random gibberish you also don't understand, this seems fine because you didn't understand any of it (or maybe you've switched it off, either way it's not relevant to you). But for a middlebox this ensures they can't tell whether you're doing ECH. So, either they reject every client which could do ECH, which again that's how you get a bunch of angry customers, or, they accept such clients and so ECH works.
- ekr____ 5mo ago
  Even if the browsers and servers don't support it, you could still enable it because the system is designed to be backward compatible.
ocdtrekkie 5mo ago
Just be aware any reasonable network will block this.
- quantummagic 5mo ago
  Why is it "reasonable" to block it?
  - vman81 5mo ago
    Well, I may want to have a say in what websites the employees at work access in their browsers. For example.
    - altairprime 5mo ago
      That’s not a meaningful issue here. Either snoop competently or snoop wire traffic, pick one. In the snooping-mandatory scenario, either you have a mandatory outbound PAC with SSL-terminating proxy that either refuses CONNECT traffic or only allows that which it can root CA mitm, or you have a self-signed root CA mitm’ing all encrypted connections it recognizes. The former will continue functioning just fine with no issues at providing that; the latter will likely already be having issues with certificate-pinned apps and operating system components, not to mention likely being completely unaware of 80/udp, and should be scheduled for replacement by a solution that’s actually effective during your next capital budgeting interval.
    - kccqzy 5mo ago
      That’s usually done not on the network side but through the device itself. Think MDM and endpoint management.
      - ocdtrekkie 5mo ago
        A good solution is tackling it on both. At work we have network level firewalls with separate policies for internal and guest networks, and our managed PCs sync a filter policy as well (through primarily for when those devices are not on our network). The network level is more efficient, easier to manage and troubleshoot, and works on appliances, rogue hardware, and other things that happen not to have client management.
deleted 5mo ago
[deleted]
philipnee 5mo ago
And QUIC.
- kybishop 5mo ago
  Wasn't QUIC all done in the 3.x versions? Is there something in this release related to QUIC support?
  - jlericson 5mo ago
    Correct. 3.5 (the current LTS) included QUIC support: https://openssl.foundation/news/the-features-of-3-5-external-quic-library-interface https://openssl.foundation/news/the-features-of-3-5-external...

Finally encrypted client hello support \o/

bombcar 5mo ago

Is this something that we can enable "today" or is it going to take 12 years for browsers and servers to support?

arcfour 5mo ago
CloudFlare has supported it since 2023: https://blog.cloudflare.com/announcing-encrypted-client-hello/and https://blog.cloudflare.com/announcing-encrypted-client-hell... Firefox has had it enabled by default since version 119: https://support.mozilla.org/en-US/kb/faq-encrypted-client-hello#w_how-do-i-enable-ech-in-firefox https://support.mozilla.org/en-US/kb/faq-encrypted-client-he... so you can use it today.
- bombcar 5mo ago
  https://tls-ech.dev https://tls-ech.dev indicates that Safari doesn't support it, but Chrome does.
  - altairprime 5mo ago
    That’s likely due to iOS/macOS not supporting it in production-default-enabled yet; there’s an experimental opt-in flag at the OS level, but Safari apparently hasn’t (yet) added a dev feature switch for it. https://developer.apple.com/documentation/security/sec_protocol_options_set_enable_encrypted_client_hello https://developer.apple.com/documentation/security/sec_proto... Presumably anyone besides Safari can opt-in to that testing today, but I wouldn’t ship it worldwide and expect nice outcomes until (I suspect) after this fall’s 27 releases. Maybe someone could PR the WebKit team to add that feature flag in the meantime?
- 1vuio0pswjnm7 5mo ago
  "... so you can use it today." What if he wanted to use it for requesting blog.cloudflare.com ;; ANSWER SECTION: blog.cloudflare.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.18.28.7,104.18.29.7 ipv6hint=2606:4700::6812:1c07,2606:4700::6812:1d07 Where are the ECH keys For example, ;; ANSWER SECTION: test.defo.ie. 300 IN HTTPS 1 . ech="AEb+DQBCqQAgACBlm7cfDx/gKuUAwRTe+Y9MExbIyuLpLcgTORIdi69uewAEAAEAAQATcHVibGljLnRlc3QuZGVmby5pZQAA" or ;; ANSWER SECTION: cloudflare-ech.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.18.10.118,104.18.11.118 ech="AEX+DQBBpQAgACB/RU5hAC5mXe3uOZtNY58Bc8UU1cd4QBxQzqirMlWZeQAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA=" ipv6hint=2606:4700::6812:a76,2606:4700::6812:b76 It's true one can "use it today". One could use it for the past several years as well. The software has been around for a while But ECH has never been consistently enabled for the general public beyond a small number of test sites that are only for testing ECH
kro 5mo ago
Nginx mainline 1.29.x supports it. So once you get that and also the openssl version on your system, good to go. Likely too late for ubuntu 26.04, maybe in debian 14 next year, or of course rolling release distros / containers. But, in a personal/single website server, ech does not really add privacy, adversaries can still observe the IP metadata and compare what's hosted there. The real benefits are on huge cloud hosting platforms.
- Bender 5mo ago
  FWIW Nginx 1.30 [1] just released and supports it so most distributions will have support as soon as those responsible for builds and testing builds push it forward. "Nginx 1.30 incorporates all of the changes from the Nginx 1.29.x mainline branch to provide a lot of new functionality like Multipath TCP (MPTCP)." "Nginx 1.30 also adds HTTP/2 to backend and Encrypted Client Hello (ECH), sticky sessions support for upstreams, and the default proxy HTTP version being set to HTTP/1.1 with Keep-Alive enabled." But, in a personal/single website server, ech does not really add privacy, adversaries can still observe the IP metadata and compare what's hosted there I don't quite follow. I have dozens of throw-away silly hobby domains. I can use any of them as the outer-SNI. How is someone observing the traffic going to know the inner-SNI domain unless someone builds a massive database of all known inner+outer combinations which can be changed on a whim? ECH requires DOH so unless the ISP has tricked the user into using their DOH end-point they can't see the HTTPS resource record. [1] - https://news.ycombinator.com/item?id=47770007 https://news.ycombinator.com/item?id=47770007
  - ameliaquining 5mo ago
    It's not that adversaries can directly see the domain name; this doesn't have anything to do with domain fronting. The issue is that ECH doesn't hide the server's IP address, so it's mostly useless for privacy if that IP address uniquely identifies that server. The situation where it helps is if the server shares that IP address with lots of other people, i.e., if it's behind a big cloud CDN that supports ECH (AFAIK that's currently just Cloudflare). But if that's the case, it doesn't matter whether Nginx or whatever other web server you run supports ECH, because your users' TLS negotiations aren't with that server, they're with Cloudflare.
tialaramex 5mo ago
TLS (the IETF Working Group not the protocol family named for them) have long experience with the fact that if you specify how B is compatible with A based on how you specified A and ship B what you did won't work because the middleboxes are all cost optimized and don't implement what you specified but instead whatever got the sale for the least investment. So e.g. they'd work for exactly the way you use say TLS 1.0 in the Netscape 4 web browser which was popular when the middlebox was first marketed, or maybe they cope with exactly the features used in Safari but since Safari never sets this bit flag here they reject all connections with that flag. What TLS learned is summarized as "have one joint and keep it well oiled" and they invented a technique to provide that oiling for one working joint in TLS, GREASE, Generate Random Extensions And Sustain Extensibility. The idea of GREASE is, if a popular client (say, the Chrome web browser) just insists on uttering random nonsense extensions then to survive in the world where that happens you must not freak out when there are extensions you do not understand. If your middlebox firmware freaks out when seeing this happen, your customers say "This middlebox I bought last week is broken, I want my money back" so you have to spend a few cents more to never do that. But, since random nonsense is now OK, we can ship a new feature and the middleboxes won't freak out, so long as our feature looks similar enough to GREASE. ECH achieves the same idea, when a participating client connects to a server which does not support ECH as far as it knows, it acts exactly the same as it would for ECH except, since it has neither a "real" name to hide nor a key to encrypt that name it fills the space where those would fit with random gibberish. As a server, you get this ECH extension you don't understand, and it is filled with random gibberish you also don't understand, this seems fine because you didn't understand any of it (or maybe you've switched it off, either way it's not relevant to you). But for a middlebox this ensures they can't tell whether you're doing ECH. So, either they reject every client which could do ECH, which again that's how you get a bunch of angry customers, or, they accept such clients and so ECH works.
ekr____ 5mo ago
Even if the browsers and servers don't support it, you could still enable it because the system is designed to be backward compatible.

ocdtrekkie 5mo ago

Just be aware any reasonable network will block this.

quantummagic 5mo ago
Why is it "reasonable" to block it?
- vman81 5mo ago
  Well, I may want to have a say in what websites the employees at work access in their browsers. For example.
  - altairprime 5mo ago
    That’s not a meaningful issue here. Either snoop competently or snoop wire traffic, pick one. In the snooping-mandatory scenario, either you have a mandatory outbound PAC with SSL-terminating proxy that either refuses CONNECT traffic or only allows that which it can root CA mitm, or you have a self-signed root CA mitm’ing all encrypted connections it recognizes. The former will continue functioning just fine with no issues at providing that; the latter will likely already be having issues with certificate-pinned apps and operating system components, not to mention likely being completely unaware of 80/udp, and should be scheduled for replacement by a solution that’s actually effective during your next capital budgeting interval.
  - kccqzy 5mo ago
    That’s usually done not on the network side but through the device itself. Think MDM and endpoint management.
    - ocdtrekkie 5mo ago
      A good solution is tackling it on both. At work we have network level firewalls with separate policies for internal and guest networks, and our managed PCs sync a filter policy as well (through primarily for when those devices are not on our network). The network level is more efficient, easier to manage and troubleshoot, and works on appliances, rogue hardware, and other things that happen not to have client management.

deleted 5mo ago

[deleted]

philipnee 5mo ago

And QUIC.

kybishop 5mo ago
Wasn't QUIC all done in the 3.x versions? Is there something in this release related to QUIC support?
- jlericson 5mo ago
  Correct. 3.5 (the current LTS) included QUIC support: https://openssl.foundation/news/the-features-of-3-5-external-quic-library-interface https://openssl.foundation/news/the-features-of-3-5-external...