ECH (Encrypted Client Hello) encrypts SNI, which is the only field in cleartext in a HTTPS connection. It requires use of an encrypted DNS server. Enabling this will further protect user privacy by shadowing what WMF sites they are connecting to.
It could also make WMF sites more censorship-resistant. Note that packets with ECH has a distinct signature, so a censor may choose to block it at all.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | ssingh | T252132 Deploy Wikimedia DNS: DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) public resolver | |||
| Open | Feature | None | T205378 Support ECH on Wikimedia servers |
@Shizhao: Is this a feature request? Currently it looks like a question, and questions can be asked on mailing lists, on IRC, or in forums.
Firefox Nightly now supports ESNI:
https://blog.mozilla.org/security/2018/10/18/encrypted-sni-comes-to-firefox-nightly/
While phrased weirdly, I think we can assume he is asking us to support the experimental ESNI TLS extension (https://tools.ietf.org/html/draft-ietf-tls-esni-01).
The feature may have interesting implications related to state censorship of Wikipedia.
@Krenair @Bawolff @jcrespo Wondering if we can enable QUIC support on our server clusters instead? I've heard that the github Googlehosts is providing the QUIC access to Google HK.
I'm not really familiar with the QUIC protocol/upcoming HTTP/3 stuff, but i think that's a rather separate request. I think that QUIC is still using TLS, so still uses normal SNI (or eventually ESNI)
The swap of Traffic for Traffic-Icebox in this ticket's set of tags was based on a bulk action for all tickets that aren't are neither part of our current planned work nor clearly a recent, higher-priority emergent issue. This is simply one step in a larger task cleanup effort. Further triage of these tickets (and especially, organizing future potential project ideas from them into a new medium) will occur afterwards! For more detail, have a look at the extended explanation on the main page of Traffic-Icebox . Thank you!
unsubing, as I think I was added to this ticket by mistake. This is traffic/traffic security expertise, and they already triaged and aware of the task.
Mozilla have now launched ECH in Firefox. Cloudflare have also launched server side support globally. Chrome will be shipping ECH imminently.
Is it worth re-triaging this feature?
@DennisJJackson Hi and welcome to Phabricator! What in this ticket led you to asking for "retriage" (and what does that mean)?
@Aklapper - It looks like this issue was originally raised several years ago and put in the icebox. I'm flagging that the situation around standardization and deployment of ECH has changed rather dramatically since then. This work would also be closely aligned with Wikimedia's recent work on hosting secure DNS.
I'm just flagging that its worth taking a look at and seeing whether its still icebox priority for Wikimedia or whether its worth actively working on.
Hi @DennisJJackson: Thanks for the question. We do plan to work on ECH and enable it for our sites and have had some discussions internally. There is no timeline yet as such, for a variety of reasons, the limited browser support being one, though that has clearly changed over the past few weeks. There are some other considerations here as well such as the lack of server-side options for turning it on but we are hoping the DEfO project will provide the much needed support there for HAProxy, which is what we use for TLS termination.
Once we have defined some timeline, we will re-triage this task and share updates here. Thanks for checking!