caddy
caddy copied to clipboard
caddyserver
Support Encrypted Client Hello (formerly known as ESNI)
Please add support for TLS Encrypted Client Hello
- 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
- Work in Progress in picotls: h2o/picotls#155
Previous ticket for ESNI was not recreated after being closed, so here it is.
List taken from the openssl issue.
https://blog.cloudflare.com/encrypted-client-hello/
I don't think ESNI has a future.
And this isn't actionable for the Caddy project until Golang implements it. And there seems to be no plans to unless there's suddenly wider adoption.
ECH is its successor though. If Go implements it we should try to support it.
Oh sorry, I totally misread the issue title. My bad! :man_facepalming:
Related
- https://guardianproject.info/2021/11/30/implementing-tls-encrypted-client-hello/
- https://news.ycombinator.com/item?id=29530811
Any updates? all of nginx,apache,lighttpd have support ECH, how about caddy?
@diyism I can't find any evidence that they do support it. Where did you see that? Please share links.
@diyism I can't find any evidence that they do support it. Where did you see that? Please share links.
I've test it in https://defo.ie/ with msedge dev(https://www.thewindowsclub.com/enable-encrypted-client-hello-in-microsoft-edge):
nginx: https://draft-13.esni.defo.ie:10413 apache2: https://draft-13.esni.defo.ie:11413 both of the upper two pages show "SSL_ECH_STATUS: success" and a green tick mark. Can it prove they hava a ECH-ready nginx and apache2 ?
Those are experiments using a custom build of OpenSSL. That's not really "support".
Either way, Caddy doesn't use OpenSSL, it uses Go's stdlib for TLS. So this work doesn't apply to us.
Yeah, that would be like us building with a custom fork of the Go standard library to support ECH. We could do that (Cloudflare has one), but given the sensitive nature of the crypto/tls package, I would only recommend that for experimental or low-risk environments for now. (CF is surely using it in production, but we don't know how much of the diff is tailored to just their use cases.)
So I guess we can answer "How about Caddy?" with "Sure, go for it" -- just build it with a forked tls package and it is possible. (I'm uncertain if any code changes to Caddy would need to take place, but since you're building from source already, might as well.)
As a side-note, the ECH draft spec seems to have expired: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
I think this doesn’t change anything as Caddy’s stance appears to be “when it’s supported in Go stdlib,” which makes total sense to me, but it looks like ECH has legs and is now supported in mainline Firefox: https://blog.mozilla.org/en/products/firefox/encrypted-hello/
Yeah; to clarify, we like ECH, and will support it someday assuming Go's standard lib implements it. (Because we're wary about switching to a fork of crypto/tls for our standard distribution of Caddy.)
However, I should note that ECH has limited practical use currently as DNS lookups still reveal hostnames in plaintext most of the time, and packets still have IP addresses that aren't encrypted.
It's just really, really hard to solve the problem people are hoping to solve, and ECH is not the whole solution, and without the whole solution, users are still at risk.
But it's cool I guess. A step in the right direction.
Firefox also defaults to DNS over TLS as well, so this is another step to close the gaps.
IP addresses is a big gap. Though it’s one that can be mitigated, depending on trade offs one is willing to make. I like to self host, so I run Caddy on my own server with my IP. So my connection is going to be known that way, but others, who may not care about their own end to end control, can run their server behind a CDN, like Cloudflare. In that case, the IP revealed is one that gives an interloper very little information.
I’m glad to have seen more and more progress over the last few years and excited to see what’s to come!
@mholt - Just to clarify, ECH is the last part of the solution. There were four places where website names were leaking in plaintext:
- In the TLS Server Certificate (fixed by TLS 1.3)
- In the DNS lookup (fixed by DNS-over-HTTPS - which has already shipped in Firefox)
- In the certificate revocation checking (fixed by OCSP Stapling and CRLite)
- In the SNI field (fixed by ECH).
On the topic of IPs, they are far less unique than people realise. Cloudflare have already experimented with serving all of their websites from a single IP address [1]. In their measurement study, over 50% of the entire .com, .net, .info and .org namespace (255 million websites) is available from only ~100 IPs. This is obviously not great from a centralisation perspective, but that seems like more a reason for Caddy to support privacy features like ECH, not less!
Firefox also defaults to DNS over TLS as well, so this is another step to close the gaps.
I'm curious how widespread this is; if it's mostly us tech geeks who actually use this feature -- I know, for example, my parents don't benefit from this. I'd still wager the vast majority of DNS lookups are cleartext.
And yeah, IP addresses in some cases don't reveal much, inasmuch as we centralize to a single hosting provider.
but that seems like more a reason for Caddy to support privacy features like ECH, not less!
To AGAIN clarify, we like ECH. I just want to make sure that people understand that it is only a part of the solution and the solution is still largely incomplete. Your sites and web browsing experience may already have the whole solution, but (without seeing stats I can only guess) I'd wager that most of the Internet still has a long way to go, so I want to make sure we don't hype up something that isn't real for most people yet.
I'm curious how widespread this is; if it's mostly us tech geeks who actually use this feature -- I know, for example, my parents don't benefit from this. I'd still wager the vast majority of DNS lookups are cleartext.
It's the default out of the box in North America, Russia and Ukraine at the moment. ECH is also enabled by default worldwide.
To AGAIN clarify, we like ECH.
That's great to hear!
I just want to make sure that people understand that it is only a part of the solution and the solution is still largely incomplete.
One step at a time :-).
(What I'm saying is that most people don't use Firefox, unfortunately. I know other browsers plan to roll it out too, but we're not there yet.)
(What I'm saying is that most people don't use Firefox, unfortunately. I know other browsers plan to roll it out too, but we're not there yet.)
I think we are there now, Chrome released the update 117.0.5938.150 which now enables ECH on default. Just saying though ^^
Where did you see that? Checking out chromium source at the 117.0.5938.150 tag declares kEncryptedClientHello as FEATURE_DISABLED_BY_DEFAULT in net/base/features.cc
Idk about Chromium but as of https://chromestatus.com/roadmap it is in Origin Trial/Prepare to Ship for 117 so it will come later, but either way Chrome did enable it by default (you may need to reset your chrome://flags) and then you can check by going to https://www.cloudflare.com/ssl/encrypted-sni to see it enabled
We're dependent on Go standard library to support this function. Watch golang/go#63369. It seems to be going in a positive direction.
Firefox now supports ECH, would be great if you could support it, too: https://blog.mozilla.org/en/products/firefox/encrypted-hello/
@rugk as it's been said multiple times in this thread, there's nothing we (the Caddy team) can do until the Go stdlib has support for ECH.