4 ms·

If the DNS query is done with DoT or DoH the server name is not exposed.

LinuxBender 6y ago
That is what I took from their blog as well. For some reason I thought the original intent of ESNI was to do some type of opportunistic or self signed handshake for the (E)SNI portion to hide the requested name, then validate the actual site certificate. They must have run into a problem.
- ameshkov 6y ago
  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!
  - 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

That is what I took from their blog as well. For some reason I thought the original intent of ESNI was to do some type of opportunistic or self signed handshake for the (E)SNI portion to hide the requested name, then validate the actual site certificate. They must have run into a problem.

ameshkov 6y ago
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!
- 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