Support for Encrypted ClientHello (ECH) about quic-go HOT 7 CLOSED

I've made a tested fork of quic-go that supports ECH. ECH support is extracted from crypto/tls in cloudflare/go.

Source: https://github.com/SagerNet/quic-go/commits/dev

Usage: SagerNet/sing-box@638c209

from quic-go.

I'm surprised you're saying that you need it. I'm not aware of any ECH deployments on QUIC at this point. Which server are you trying to connect to?

I agree that this would be valuable to have. This will require a TLS stack that supports ECH. As we're switching to crypto/tls with the Go 1.21 release, ECH would need to be implemented by the standard library. This will most likely (at the very least) require the draft to be published as an RFC, so realistically speaking, we won't be able to support ECH for a year or so.

from quic-go.

Unfortunately, no open-source server currently supports it in their stable versions but there are some ECH implementations here: defo.ie.
I plan on using Cloudflare which currently supports it.

Sounds like I would need to implement it in your fork of crypto/tls, I don't know how but I'm going to try.

from quic-go.

Please don’t. This fork is going to be removed within a couple of weeks. quic-go will only rely on crypto/tls, no more forks necessary.

from quic-go.

Thanks for your warning, assuming go 1.21 realases, can I fork crypto/tls from there and implement ECH on that?

from quic-go.

There seems to be some progress on the standard library side, albeit only on the client side: golang/go#63369 (comment)

from quic-go.

I'm going to close this issue, since this is now purely a crypto/tls issue. With golang/go#63369, crypto/tls would gain client-side ECH support. No changes to quic-go will be needed for that.

Similarly, if / when the standard library decides to add server-side ECH support, it is expected that no changes to quic-go will be needed either. Therefore, this issue is not actionable (in quic-go).

from quic-go.