Description

HLFH

opened on Aug 17, 2019

Issue body actions

Encrypted SNI is on the standards track and is already being deployed by big players.

Draft RFC: https://tools.ietf.org/html/draft-ietf-tls-esni-04

• Championed by the EFF: https://www.eff.org/deeplinks/2018/09/esni-privacy-protecting-upgrade-https
• Deployed by Cloudflare: https://blog.cloudflare.com/esni/
• Cloudflare's technical details post: https://blog.cloudflare.com/encrypted-sni/
• Supported by Firefox: https://blog.mozilla.org/security/2018/10/18/encrypted-sni-comes-to-firefox-nightly/
• Supported by NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=1495120
• ESNI is specifically being pushed by Sen. Ron Wyden (D-OR): https://gizmodo.com/sen-wyden-urges-dhs-to-adopt-new-encryption-tech-to-pr-1830001179
• Supported in H2O HTTP server: Encrypted SNI h2o/picotls#155

Reacted by Veratyr, J0WI, Theo Paris, Viktor Szakats, codenyte, hex-m, ngn999, cdidier and ud2

Activity

1. kinichiro

   added

   enhancement

   on Aug 19, 2019
2. lanodan commented on Feb 15, 2020

   

   lanodan

   on Feb 15, 2020

   More actions

   This draft should be read before implementing it: https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/

   Also both of them are drafts so should probably be avoided in production.
3. Motophan commented on Sep 20, 2020

   

   Motophan

   on Sep 20, 2020

   More actions

   @lanodan no, it should not be avoided. This enables GFW circumvention and needs to be rolled out immediately.
4. hacker-h commented on Oct 19, 2020

   

   hacker-h

   on Oct 19, 2020

   More actions

   Since #228 was implemented, is there still anything blocking this?
   There is now also the first draft for the standards track: https://tools.ietf.org/html/draft-ietf-tls-esni-08
5. botovq commented on Oct 28, 2020

   

   botovq

   on Oct 28, 2020 via email

   Contributor

   More actions

   On Mon, Oct 19, 2020 at 10:40:52AM -0700, Henning Häcker wrote: Since #228 was implemented, is there still anything blocking this?

   @hacker-h: Thanks for the pointer. We're of course aware of it. The ECH/ESNI and HPKE drafts are still fast moving targets as can be seen on GH and on the ietf-tls mailing lists, e.g.: https://github.com/tlswg/draft-ietf-tls-esni/issues https://github.com/tlswg/draft-ietf-tls-esni/graphs/commit-activity This will have to settle down quite a bit before it makes sense to even think about tackling it. Even if it were top priority, it would be hard to keep up with the constant stream of changes. In any case, it will require a non-trivial amount of work.
6. theoparis commented on Dec 29, 2023

   

   theoparis

   on Dec 29, 2023

   More actions

   BoringSSL supports ECH now as it is able to be used with Nginx in a work in progress fork/patchset. There is already a PR for supporting it in OpenSSL. I am currently stuck with using AWS-LC/BoringSSL for my reverse proxy because LibreSSL does not support ECH.
7. joshuasing

   changed the title [-]Support ESNI[/-] [+]Support ECH/ESNI[/+] on Dec 29, 2023
8. vszakats commented on Apr 16, 2024

   

   vszakats

   on Apr 16, 2024

   Contributor

   More actions

   curl landed ECH support in curl/curl@a362962 via curl/curl#11922.

   It supports both BoringSSL (SSL_set1_ech_config_list) and OpenSSL (SSL_ech_set1_echconfig) (via ECH fork: https://github.com/defo-project/openssl and PR: openssl/openssl#22938) API flavours.

   edit (2026): the OpenSSL marker function ending up in OpenSSL 4.0.0 release is SSL_set1_ech_config_list (replacing: SSL_ech_set1_echconfig).

   Reacted by Theo Paris

Issue actions