4 ms·

I've been loosely following ESNI/ECH drafts, and I am not sure this approach (double handshake) was ever seriously considered despite that it sounds perfectly f

I've been loosely following ESNI/ECH drafts, and I am not sure this approach (double handshake) was ever seriously considered despite that it sounds perfectly fine to me. It'd make the handshake heavier, but on the other hand, it'd also make it much harder to distinguish from the regular TLS traffic. On the contrary, ESNI/ECH seems to be easy to detect and block, and some countries (China, for instance) have already announced that they're going to do that.

parliament32 6y ago
There was nothing stopping a MITM with a fake/self-signed pre-handshake.
tialaramex 6y ago
ECH is intended to be GREASEd which means there isn't an easy way to say "Block ECH only when it is used" because the obvious markers are present in every single connection. That is, an ECH implementing browser talking to some web site that doesn't do ECH will present it an ECH blob which is random gibberish. The web site doesn't do ECH, so it ignores the ECH, but a middlebox doesn't know that and if it wants to "block ECH" it must tear down this connection. If the same browser connects to a site which does have ECH the ECH blob isn't gibberish it's encrypted, the site decrypts it and treats the result as the real ClientHello. Historically China's Great Firewall is willing to put work in to detect and sabotage things it doesn't like. But the point of GREASing extensions is to ensure that the extension itself isn't poisoned. As a result most likely ECH will work fine in China, they'll just block IPs they don't like, punish citizens (or indeed visitors) they don't like, and that's an internal matter that the Chinese can take up with their government in the usual (and costly) way. This is not a magic anti-censorship tool, and isn't designed to be one. Even Tor isn't that, although its developers can point you at services that help if that's what you need.
- ameshkov 6y ago
  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
- saurik 6y ago
  I don't see how this would work: China would effectively just be banning that browser, which is no skin off their back as other companies--even better: ones local to China--can make browsers that don't do this.
  - tialaramex 6y ago
    Sure, if China wants to ban say, Safari, they can do that. Seems like a very bad idea to me, but it's their country and they can choose policy. I think Winnie the Pooh is smarter than Trump and won't just throw a tantrum because he didn't get his way, but it's certainly possible he'd decide to turn every iPhone in China into a brick rather than accept that we don't want to keep telling eavesdroppers which server name you wrote in the URL. The GREASE isn't there primarily because of China, as I said they don't build crazy fragile technology, they don't have anybody to sell this too, the Great Firewall is an in-house project, so it's mostly simple and robust. Bad destination IP, connection blocked. Rarely a big problem in a technical sense. GREASE is because of stupid corporate middleboxes. Middleboxes are a technical problem, because even when they have an apparently mundane and legitimate purpose they tend to go about it in stupid over-complicated ways that destroy forward compatibility. All of the weird spelling of TLS 1.3 is because of middleboxes. Why is HelloRetryRequest spelled ServerHello? Because if you don't say ServerHello at that point some famous middleboxes explode. Why is TLS 1.3 ClientHello written exactly like a TLS 1.2 ClientHello (including the version number) except with crazy extension values? Because otherwise middleboxes explode. Why is there a bunch of completely random data labelled "Session ID"? Is it a session ID? Nope. If that was missing, you guessed it, middleboxes explode.
KMag 6y ago
RFC 7924[0] (cached certificate extension) is intended only to avoid lots of wasted bandwidth re-sending certificates, but with a modification of where the cached_info goes in the handshake, it would make any middle-box meddling (including censorship) orders of magnitude more expensive. Honestly, the next version of TLS should have a mandatory variant of certificate caching [0], except instead of putting the cached_info in the ClientHello message, the final handshake message (which is encrypted) would include the hash of the cached certificate. If the hash doesn't match, then the server would send the certificate (the connection is now in an encrypted but unauthenticated state). If nothing is cached, the client sends randomly generated bits in place of a cached certificate hash, which eliminates one case to be handled in the protocol. (Handle an empty cache and a stale cache in the same code branch.) This provides more privacy than sending an "I have nothing cached" and it's more likely to be struck by lightning and a meteorite simultaneously than get a 256-bit collision. The consequences of a hash collision are only that the connection needs to be reset. In the case of nothing being cached, again to reduce the number of special cases to handle, the client would need to make a guess as to the ECDH/RLWE/etc. parameters in its initial handshake message. The mechanism for handling stale cached ECDH/RLWE/etc. parameters would then apply to the non-cached case. (In this case, the server just sends back a message saying "Those are stale. Here are my parameters for a method in your provided list of supported methods, and here, also have my first side of the handshake."). Again, eliminating special cases by faking it/guessing if nothing is cached slightly increases privacy by requiring information outside of the handshake to detect if this is a repeat visit. This change would force any meddling middle box to go through MITM'ing most of a TLS handshake before getting much information at all, and then having to break the MITM'd connection and allowlist/denylist* the involved IP for some period of time. For scalability, most present-day censoring hardware keeps the censorship out of the main path, passively observing traffic from a router's cloned port, and submitting forged RST packets to both sides of a TCP connection when the plain text contains something it doesn't like. Forcing MITM'ing makes such meddling orders of magnitude more expensive to implement, and much less accurate in cases of shared IP addresses. On a side note, I heavily use the trick of initializing a cache to expired values in order to avoid special-casing empty caches. There's a cute trick for caching conversion of ISO-formatted date strings to date objects if your hot path includes a lot of parsing of dates from JSON and only dealing with consecutive days (in my case, yesterday and today) the least significant bit of the rightmost day digit code point and the least significant bit of the rightmost month digit code point form a very cheap 2-bit hash that never collides for consecutive dates, so you can use a 4-element array as your cache. These digits are at constant offsets in the ISO date string from the year 1000 to the year 9999. (There are no consecutive even days, and consecutive odd days only occur when the month rolls over. Months always alternate even and odd, even at the rollover from 12-31 to 01-01. Every character set I'm aware of puts the digits consecutively, so this trick works for unicode, ASCII, and every character set I'm aware of.) [0] https://tools.ietf.org/html/rfc7924 https://tools.ietf.org/html/rfc7924 * formerly known as whitelist/blacklist

parliament32 6y ago

There was nothing stopping a MITM with a fake/self-signed pre-handshake.

tialaramex 6y ago

ECH is intended to be GREASEd which means there isn't an easy way to say "Block ECH only when it is used" because the obvious markers are present in every single connection. That is, an ECH implementing browser talking to some web site that doesn't do ECH will present it an ECH blob which is random gibberish. The web site doesn't do ECH, so it ignores the ECH, but a middlebox doesn't know that and if it wants to "block ECH" it must tear down this connection. If the same browser connects to a site which does have ECH the ECH blob isn't gibberish it's encrypted, the site decrypts it and treats the result as the real ClientHello. Historically China's Great Firewall is willing to put work in to detect and sabotage things it doesn't like. But the point of GREASing extensions is to ensure that the extension itself isn't poisoned. As a result most likely ECH will work fine in China, they'll just block IPs they don't like, punish citizens (or indeed visitors) they don't like, and that's an internal matter that the Chinese can take up with their government in the usual (and costly) way. This is not a magic anti-censorship tool, and isn't designed to be one. Even Tor isn't that, although its developers can point you at services that help if that's what you need.

ameshkov 6y ago
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
saurik 6y ago
I don't see how this would work: China would effectively just be banning that browser, which is no skin off their back as other companies--even better: ones local to China--can make browsers that don't do this.
- tialaramex 6y ago
  Sure, if China wants to ban say, Safari, they can do that. Seems like a very bad idea to me, but it's their country and they can choose policy. I think Winnie the Pooh is smarter than Trump and won't just throw a tantrum because he didn't get his way, but it's certainly possible he'd decide to turn every iPhone in China into a brick rather than accept that we don't want to keep telling eavesdroppers which server name you wrote in the URL. The GREASE isn't there primarily because of China, as I said they don't build crazy fragile technology, they don't have anybody to sell this too, the Great Firewall is an in-house project, so it's mostly simple and robust. Bad destination IP, connection blocked. Rarely a big problem in a technical sense. GREASE is because of stupid corporate middleboxes. Middleboxes are a technical problem, because even when they have an apparently mundane and legitimate purpose they tend to go about it in stupid over-complicated ways that destroy forward compatibility. All of the weird spelling of TLS 1.3 is because of middleboxes. Why is HelloRetryRequest spelled ServerHello? Because if you don't say ServerHello at that point some famous middleboxes explode. Why is TLS 1.3 ClientHello written exactly like a TLS 1.2 ClientHello (including the version number) except with crazy extension values? Because otherwise middleboxes explode. Why is there a bunch of completely random data labelled "Session ID"? Is it a session ID? Nope. If that was missing, you guessed it, middleboxes explode.

KMag 6y ago

RFC 7924[0] (cached certificate extension) is intended only to avoid lots of wasted bandwidth re-sending certificates, but with a modification of where the cached_info goes in the handshake, it would make any middle-box meddling (including censorship) orders of magnitude more expensive. Honestly, the next version of TLS should have a mandatory variant of certificate caching [0], except instead of putting the cached_info in the ClientHello message, the final handshake message (which is encrypted) would include the hash of the cached certificate. If the hash doesn't match, then the server would send the certificate (the connection is now in an encrypted but unauthenticated state). If nothing is cached, the client sends randomly generated bits in place of a cached certificate hash, which eliminates one case to be handled in the protocol. (Handle an empty cache and a stale cache in the same code branch.) This provides more privacy than sending an "I have nothing cached" and it's more likely to be struck by lightning and a meteorite simultaneously than get a 256-bit collision. The consequences of a hash collision are only that the connection needs to be reset. In the case of nothing being cached, again to reduce the number of special cases to handle, the client would need to make a guess as to the ECDH/RLWE/etc. parameters in its initial handshake message. The mechanism for handling stale cached ECDH/RLWE/etc. parameters would then apply to the non-cached case. (In this case, the server just sends back a message saying "Those are stale. Here are my parameters for a method in your provided list of supported methods, and here, also have my first side of the handshake."). Again, eliminating special cases by faking it/guessing if nothing is cached slightly increases privacy by requiring information outside of the handshake to detect if this is a repeat visit. This change would force any meddling middle box to go through MITM'ing most of a TLS handshake before getting much information at all, and then having to break the MITM'd connection and allowlist/denylist* the involved IP for some period of time. For scalability, most present-day censoring hardware keeps the censorship out of the main path, passively observing traffic from a router's cloned port, and submitting forged RST packets to both sides of a TCP connection when the plain text contains something it doesn't like. Forcing MITM'ing makes such meddling orders of magnitude more expensive to implement, and much less accurate in cases of shared IP addresses. On a side note, I heavily use the trick of initializing a cache to expired values in order to avoid special-casing empty caches. There's a cute trick for caching conversion of ISO-formatted date strings to date objects if your hot path includes a lot of parsing of dates from JSON and only dealing with consecutive days (in my case, yesterday and today) the least significant bit of the rightmost day digit code point and the least significant bit of the rightmost month digit code point form a very cheap 2-bit hash that never collides for consecutive dates, so you can use a 4-element array as your cache. These digits are at constant offsets in the ISO date string from the year 1000 to the year 9999. (There are no consecutive even days, and consecutive odd days only occur when the month rolls over. Months always alternate even and odd, even at the rollover from 12-31 to 01-01. Every character set I'm aware of puts the digits consecutively, so this trick works for unicode, ASCII, and every character set I'm aware of.) [0] https://tools.ietf.org/html/rfc7924 https://tools.ietf.org/html/rfc7924 * formerly known as whitelist/blacklist