Support ECH/ESNI

[HLFH]

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

[lanodan]

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.

[Motophan]

@lanodan no, it should not be avoided. This enables GFW circumvention and needs to be rolled out immediately.

[hacker-h]

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

[botovq]

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.

[theoparis]

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.

[vszakats]

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.