4 ms·
That requires the client to only emit ECH, even if the ISP-provided (and therefore government controlled) DNS blocks HTTPS/SVCB records. China can easily make t
by johncolanduoni 9mo ago
That requires the client to only emit ECH, even if the ISP-provided (and therefore government controlled) DNS blocks HTTPS/SVCB records. China can easily make the default for a browser in China be to never even try to use ECH as well. Then they'll only annoy people trying to actively circumvent their system. They already do TCP sessionization to extract the SNI domain. Detecting ECH and then just dropping the connection at L3 is functionally equivalent.
In theory, sites could eventually require ECH to serve anything at all. But we're very far from that.
- fc417fc802 9mo ago> In theory, sites could eventually require ECH to serve anything at all. But we're very far from that. I doubt the Chinese government would care about that. They don't depend on the west for their online services any more than we depend on them. All that would happen is that the internet would bifurcate to an even greater degree than it already has. It's extremely helpful at home in the west as a countermeasure against data monetization and dragnet surveillance. It certainly isn't perfect but at least it reduces the ability of ISPs to collect data on end users as well as forcing the government to formally move against the cloud providers if they want the data. Not that I want the cloud providers having my data to begin with but that's a different rant.
- tialaramex 9mo ago> That requires the client to only emit ECH So for example, Firefox since version 119. Or Chrome since 117 Now, for most services ECH doesn't have an encrypted target server. But the important choice in ECH was in this case it just fills that space with noise. An encrypted message also looks like noise. So you can block all the noise, in case it's secrets, or you can let through all the noise (some of which might be secrets) or I suppose you can choose randomly, but you can't do what such regimes want, which is to only forbid secrets, that's not a thing. We've been here before. When sites starting going to TLS 1.3 lots of HN people said oh, China will just block that, easy. But the choice wasn't "Use TLS 1.3 or keep doing whatever China is happy with instead" the choice was "Use TLS 1.3 or don't connect" and turns out for a lot of the Web China wasn't OK with "don't connect" as their choice, so TLS 1.3 is deployed anyway.
- johncolanduoni 9mo agoThe great firewall was updated to support inspection of TLS 1.3. They didn’t just decide it was whatever and let everything through. It was easier to just update their parsing than to force everyone to turn it off, so they did that instead. Perfect forward secrecy was a thing before TLS 1.3, and they’ve found other methodology to accomplish what they want. For ECH, China can just require you turn it off. Or distribute their own blessed distribution. It’s the more marginal censorship regimes that will be in an interesting spot. Especially ones where the ISPs are mostly responsible for developing the technical measures.
- tialaramex 9mo ago> The great firewall was updated to support inspection of TLS 1.3. To actually "inspect" TLS 1.3 you need the keys which are chosen randomly for each session by the parties - so either (1) you have a mathematical breakthrough, (2) you have secured co-operation from one or both parties (in which case they could equally tell you what they said) or (3) in fact you don't have inspection. As you observe forward secrecy was already possible in TLS 1.2 and China's "Great firewall" didn't magically stop that either. In fact what we see is that China blocks IP outright when it doesn't want you to talk to an address, the protocol doesn't come into that. What we changed wasn't whether China can block connections, but how easy it is to snoop those connections. > For ECH, China can just require you turn it off So did they? Remember, I'm not talking about some hypothetical future, this technology is actively in use today and has been for some time.
- johncolanduoni 9mo agoI don’t understand what your point about TLS 1.3 is. It’s only relevant if you’re doing a downgrade attack (or equivalently, using an active middleware box). TLS 1.3 itself is not vulnerable to this because it (a) doesn’t have non-PFS suites to downgrade to and (b) protects the cipher suites by including them in the key exchange material. But if the server supports TLS 1.2, an active MITM can still downgrade to it if the client doesn’t demand TLS 1.3 specifically (which browsers do not by default). It won’t matter to China until there are lots of TLS 1.3-only websites (which hasn’t happened yet). China was already leaning on passive DPI and L3 blocking before TLS 1.3 complicated (but as I said, did not preclude) downgrading to PFS ciphers. The reason being that for about the last 10 years, many sites (including default CDN settings) used SSL profiles that only allowed PFS ciphers. For such a server, downgrade attacks are already not useful to the Great Firewall, so adding TLS 1.3 to the mix didn’t change anything. > So did they? Remember, I'm not talking about some hypothetical future, this technology is actively in use today and has been for some time. Google Chrome (for example) will now use ECH if the website has the relevant DNS record - but it doesn’t use the anti-censorship mechanism in the spec to make requests to servers that haven’t enabled it look like they may be using ECH. This, combined with the fact that China can just not serve the relevant DNS record by default, means it doesn’t really impact the great firewall. This is actually a good example of the non-technical side of this: Chrome could send a fake ECH on every request, like the spec suggests. This would perhaps make China block all Chrome traffic to prevent widespread ECH. But then Chrome would lose out on the market share, so Google doesn’t do it. Technical solutions are relevant here, but even the most genius anti-censorship mechanism needs to content with political/corporate realities.