I wonder what they intend to do (other than just blocking entire IP ranges of non-Indian hosting providers, which I would not be surprised by) when things increasingly move to TLS1.3 with ESNI.
The Great Firewall does not block TLS 1.3. You may have seen headlines which claim it does, but they're based on a report that actually says it doesn't. Remember journalists probably know even less than you do about most things they write about!
In this case the report says the Great Firewall was determined to block the following specific combination:
* A ClientHello for TLS 1.3 that
* Includes the 0xffce extension value (used for experimenting with an earlier SNI draft)
If you add a 0xffce extension full of random noise, the Great Firewall blocks it. If you use the same random noise but pick a different extension value (do not do this in production code - those aren't for your meddling!) the Great Firewall doesn't interfere at all.
We have yet to discover what happens if a big bang release of Encrypted Client Hello (the current iteration of the encrypted SNI work) just deluges the Great Firewall with ECH connections. But we do know TLS 1.3 has been used successfully for years from China.
You also mention this idea that it would "force hosts to drop down to 1.2 for connections".
It is hard to tell what you intended here, it would of course be possible to force the humans using a computer to downgrade, or to disable encryption, or to cease using a computer altogether, perhaps you could put a gun to their heads for example.
But TLS 1.3 has an anti-downgrade design. A [edited to add] modern TLS 1.3 capable web browser which connects to a TLS 1.3 capable web site but finds that the connection has been negotiated as TLS 1.2 instead will reject the connection as clearly under attack, you cannot reach that site until the problem is remedied. I think you would notice if all TLS 1.3 capable sites (about a third of popular sites) suddenly did not work from China, even the Chinese government might struggle to silence such confusion and dismay from their people.
While all of the above is correct, it doesn't stop the GFW from implementing per flow based DPI that drops traffic, or throttles it to a throughput that is so slow as to be unusable, based on detection of consistent encrypted flows between an IP that is outside of China, and domestically within China.
The one thing TLS1.3 with ESNI is not is hard to detect. It's a consistent traffic pattern if you throw a sufficient amount of CPU and RAM resources at doing DPI on each and every user's flows.
In an ordinary non censored ISP environment the ratio at which you export netflow data to a collector adjacent to the router is quite low. And not a great deal of CPU and RAM resources are put into doing detailed analysis of it, other than for basic things like figuring out who you should be peering with that you aren't peering already, and identifying percentages of traffic patterns (eg: at 10pm every night we see this much traffic from our on-net locally hosted netflix cache boxes going towards the residential GPON customers).
If you are a Chinese entity with access to the router-design people at Huawei and ZTE, and sufficient motivation to do so, there's no reason why you couldn't crank up the ratio greatly and (on a middle mile and per POP basis) export netflow by a dedicated 100Gbps link to a set of directly-adjacent high performance x86-64 servers, running custom flow analysis and DPI inspection software.
They're already doing massive flow sampling at the GFW complexes today. They can police down to individual flows if they want to. They scale wide by distributing out traffic based upon src or dst IP.
