Ecrypted client hello (ECH) enabled Regions/IPs

Hello,

I’ve been trying the ECH extension and so far It’s working perfectly. However there are limited set of IPs on Cloudflare that support ECH as mentioned in the article from Handshake Encryption: Endgame (an ECH update)

ECH is rolling out for some FREE zones on our network in select geographic regions. We will continue to expand the set of zones and regions that support ECH slowly, monitoring for failures in the process.

My question is : Is there a list of all the Cloudflare Zones/IP that currently support ECH ?

We don’t typically publish such a list but I’ve asked internally if there’s more we can share.

3 Likes

Thank you ! ECH is a game changer for TLS. I’m looking forward to any updates linked to it on Cloudflare.

An issue that was related to the previous spec “ESNI” was stale DNS records. Since ECH keys are published through DNS, if new keys are generated, it will take time for DNS records to propagate. This might make some TLS requests with ECH enabled with old keys to fail. Are there ways to get the ECH keys other than DNS ?

Hi x3m3x, the ECH spec provides a mechanism for “correcting” the client’s ECH configuration in the TLS handshake. If your client offers an ECH config we don’t recognize, then we will reply with the correct ECH config in the EncryptedExtensions. You can use these safely in a subsequent handshake attempt.

See TLS Encrypted Client Hello for details.

1 Like

Thank you, I can see now how this is an improvement over the previous DNS method. If I’m not mistaken, you are currently a maintainer for this repository GitHub - cloudflare/go: Stable Go with Cloudflare (experimental) patches and backports from tip .
Reading through ech_test.go go/ech_test.go at cf · cloudflare/go · GitHub I can see that when the client sends greased or invalid ECH keys the expected behavior for the client is to receive a serverHello with retry_configs and then signal rejection. Tried with stale ECH keys I got the same behavior with a connection error.
Is there any way/example in the repository linked to how to retrieve the updated keys once the client signals a rejection ?

How are you attempting to retrieve the retry configs? The retry configs are sent in the EncryptedExtensions, so you wouldn’t see them on the wire (i.e., in wireshark).

By the way, we haven’t yet added ECH support for any traffic behind Cloudflare, but we do have a test server you can try at crypto.cloudflare.com.

1 Like

I was able to get the keys with a small patch to the code in handshake_client_tls13.go :

type ECHReject struct {
	message string
	keys    []byte
}

func (e *ECHReject) GetKeys() []byte {
	return e.keys
}

func (e *ECHReject) Error() string {
	return e.message
}

func (hs *clientHandshakeStateTLS13) abortIfRequired() error {
	c := hs.c
	if c.ech.offered && !c.ech.accepted {
		// If ECH was rejected, then abort the handshake.
		c.sendAlert(alertECHRequired)
		return &ECHReject{message: "tls: ech: rejected", keys: c.ech.retryConfigs}
	}
	return nil
}

I’m not using cloudflare.com since it doesn’t offer ECH yet (hopefully in the near future). I was using the test server at crypto.cloudflare.com and ECH keys from the HTTPS DNS records but now with Grease and retryConfigs that’s not needed anymore. Thanks you.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.