search

caddyserver / caddy

Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS
https://caddyserver.com
Apache License 2.0
58.4k stars 4.04k forks source link

Support Encrypted Client Hello (formerly known as ESNI) #4221

Open Gunni opened 3 years ago

Gunni commented 3 years ago

Please add support for TLS Encrypted Client Hello

Previous ticket for ESNI was not recreated after being closed, so here it is.

List taken from the openssl issue.

francislavoie commented 3 years ago

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.

mholt commented 3 years ago

ECH is its successor though. If Go implements it we should try to support it.

francislavoie commented 3 years ago

Oh sorry, I totally misread the issue title. My bad! :man_facepalming:

joshxyzhimself commented 2 years ago

Related

diyism commented 2 years ago

Any updates? all of nginx,apache,lighttpd have support ECH, how about caddy?

francislavoie commented 2 years ago

@diyism I can't find any evidence that they do support it. Where did you see that? Please share links.

diyism commented 2 years ago

@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 ?

francislavoie commented 2 years ago

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.

mholt commented 2 years ago

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/

ViViDboarder commented 1 year ago

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/

mholt commented 1 year ago

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.

ViViDboarder commented 1 year ago

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!

dennisjackson commented 1 year ago

@mholt - Just to clarify, ECH is the last part of the solution. There were four places where website names were leaking in plaintext:

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!

mholt commented 1 year ago

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.

dennisjackson commented 1 year ago

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 :-).

mholt commented 1 year ago

(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.)

Harusakii commented 1 year ago

(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 ^^

networkException commented 1 year ago

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

Harusakii commented 1 year ago

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

mohammed90 commented 1 year ago

We're dependent on Go standard library to support this function. Watch golang/go#63369. It seems to be going in a positive direction.

rugk commented 1 year ago

Firefox now supports ECH, would be great if you could support it, too: https://blog.mozilla.org/en/products/firefox/encrypted-hello/

francislavoie commented 1 year ago

@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.

PrivacyOsint2 commented 5 months ago

@francislavoie @mholt @mohammed90 @Gunni

They added support for ECH.

crypto/tls: add ech client support

https://github.com/golang/go/commit/9eeb627f606e713854e117dd4e52af5bcad28b66

PrivacyOsint2 commented 5 months ago

crypto/tls: support Encrypted Client Hello in clients #63369 Closed / Added

https://github.com/golang/go/issues/63369

Gunni commented 5 months ago

@francislavoie @mholt @mohammed90 @Gunni

They added support for ECH.

crypto/tls: add ech client support

https://github.com/golang/go/commit/9eeb627f606e713854e117dd4e52af5bcad28b66

Only client side logic https://github.com/golang/go/issues/63369#issuecomment-2126161985

coolaj86 commented 1 month ago

Status has been updated to Accepted: https://github.com/golang/go/issues/68500

Release targeted for Go 1.24: https://github.com/golang/go/issues/63369#issuecomment-2083070008 \ (for reference, the current version is 1.23.1 and 1.24 is expected to land around February 2025 )