5 ms·

So there would be ClientHello with greased ECH and SNI and ClientHello with real ECH and without SNI? Regarding blocking, what prevents Chinese firewall from s

So there would be ClientHello with greased ECH and SNI and ClientHello with real ECH and without SNI? Regarding blocking, what prevents Chinese firewall from simply removing ECH extension from all ClientHello packets? Servers that don’t expect ECH would continue to work, those that expect wouldn’t accept connection, mission accomplished.

deleted 6y ago
[deleted]
tialaramex 6y ago
No. There's always SNI in the outer unencrypted ClientHello. ECH DNS entries explain which name you should use in this position, which will be constant across some number of inner names which will be encrypted. Remember the IP address you connect to already tells a hypothetical eavesdropper roughly what you connected to. If it's a Wikimedia server or Microsoft is not concealed by lacking SNI. What ECH does is hide exactly which service you wanted from that IP address. Wikimedia run not only their famous encyclopedia, but a dictionary and numerous other useful references - from the same IP address with different hostnames. So maybe a future ECH-enabled German Wiktionary will use the same outer name as the English Wikipedia. Today an adversary can see which I am using, with ECH they cannot. > Regarding blocking, what prevents Chinese firewall from simply removing ECH extension from all ClientHello packets? Servers that don’t expect ECH would continue to work, those that expect wouldn’t accept connection, mission accomplished. The entire handshake is integrity protected. In TLS 1.3 (ECH is not proposed for any earlier versions) the transcript recorded by the server and client would deviate (one sent ECH the other did not receive it) and so the transcript signature check step fails and the connection doesn't work. The Chinese don't bother messing about with this stuff, if you connect somewhere the Great Firewall thinks you shouldn't, it just closes the TCP connection and blocks traffic altogether. Simple, effective, and in a sense, standards compliant.
- ameshkov 6y ago
  Thank you for the very detailed explanation!
shawnz 6y ago
The handshake messages are validated with an HMAC to prevent tampering

deleted 6y ago

[deleted]

tialaramex 6y ago

No. There's always SNI in the outer unencrypted ClientHello. ECH DNS entries explain which name you should use in this position, which will be constant across some number of inner names which will be encrypted. Remember the IP address you connect to already tells a hypothetical eavesdropper roughly what you connected to. If it's a Wikimedia server or Microsoft is not concealed by lacking SNI. What ECH does is hide exactly which service you wanted from that IP address. Wikimedia run not only their famous encyclopedia, but a dictionary and numerous other useful references - from the same IP address with different hostnames. So maybe a future ECH-enabled German Wiktionary will use the same outer name as the English Wikipedia. Today an adversary can see which I am using, with ECH they cannot. > Regarding blocking, what prevents Chinese firewall from simply removing ECH extension from all ClientHello packets? Servers that don’t expect ECH would continue to work, those that expect wouldn’t accept connection, mission accomplished. The entire handshake is integrity protected. In TLS 1.3 (ECH is not proposed for any earlier versions) the transcript recorded by the server and client would deviate (one sent ECH the other did not receive it) and so the transcript signature check step fails and the connection doesn't work. The Chinese don't bother messing about with this stuff, if you connect somewhere the Great Firewall thinks you shouldn't, it just closes the TCP connection and blocks traffic altogether. Simple, effective, and in a sense, standards compliant.

ameshkov 6y ago
Thank you for the very detailed explanation!

shawnz 6y ago

The handshake messages are validated with an HMAC to prevent tampering