Comment by tialaramex
6 days 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.
I 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.
> if the server supports TLS 1.2, an active MITM can still downgrade to it
Nope. That's specifically guarded against, so double good news. 1) You get to learn something new about an important network protocol and 2) I get to tell you a story I enjoy telling
Here's the clever trick which is specified in RFC 8446 (the TLS 1.3 RFC)
In TLS we always have this "Random" field in both Client Hello and Server Hello, it's 32 bytes of random noise. At least, that's what it usually is. When a server implements TLS 1.3 but it receives a connection (in your scenario this is from a middlebox, but it might equally be somebody's long obsolete phone) which asks for TLS 1.2 then when it fills out the Random for this connection the last eight bytes aren't actually random, they spell "DOWNGRD" in ASCII and then a 01 byte. If the client seems to ask for any older version of TLS which is supported then the server writes DOWNGRD and then a 00 byte instead.
As you hopefully realise this signals to a client that a MITM is attempting to downgrade them and so they reject the failed attack. You very likely have never seen your web browser's diagnostic for this scenario, but it's very much a failure not some sort of "Danger, Chinese government is spying on you" interstitial, because we know that warning users of danger they can't fix is pointless. So we just fail, the Chinese government could choose to annoy its citizens with this message but, why bother? Just drop the packets entirely, it's cheaper.
You might wonder, why Random ? Or, can't the MITM just replace this value and carry on anyway ? Or if you've got a bit more insight you might guess that these questions answer each other.
In TLS the Client and Server both need to be sure that each connection is different from any others, if they didn't assure themselves of this they'd be subject to trivial replay attacks. They can't trust each other, so to achieve this both parties inject Random data into the stream early, which means they don't care if the other party really used random numbers or just (stupidly) didn't bother. Shortly after this, during setup, the parties agree on a transcript of their whole conversation so far.
So, if the Random value you saw is different from the Random number your conversation partner expected, that transcript won't match, connection fails, nothing is achieved. But if the Random value isn't changed but somehow we ended up with TLS 1.2 it says DOWNGRD and a TLS 1.3 capable client knows that means it is under attack and rejects the connection, same outcome.
Now, I said there was an anecdote. It's about terrible middle boxes, because of course it is. TLS 1.3 was developed to get past terrible middle boxes and it was mostly successful, however shortly after TLS 1.3 non-draft launch (when the anti-downgrade mechanism was enabled, it would not be OK to have anti-downgrade in a draft protocol for reasons that ought to be obvious) Google began to see a significant number of downgrade failures, connected to particular brands of middlebox.
It turns out that these particular brands of middlebox were so crap that although they were proxying the HTTP connection, they were too cheap to generate their own Random data. So your TLS 1.3 capable browser calls their proxy, the proxy calls the TLS 1.3 capable server, and the proxy tells both parties it only speaks TLS 1.2, but it passes this bogus anti-downgrade "Random" value back as if it had made this itself, thus triggering the alarm.
Obviously on the "Last to change gets the blame" basis Google had customers blaming them for an issue caused ultimately by using a crap middlebox. So they actually added a Chrome feature to "switch off" this feature. Why do I mention this? Well, Chrome added that feature for 12 months. In 2018. So, unless it is still 2019 where you are, they in fact have long since removed that switch and all browsers enforce this rule. That 12 months grace gave vendors the chance to fix the bug or, if they were able to, persuade customers to buy a newer crap middlebox without this particular bug, and it gave customers 12 months to buy somebody else's middlebox or (if they were thus enlightened) stop using a middlebox.