I work as a researcher at the The Centre for Internet and Society (CIS), where we've been actively studying internet censorship in India over the last year.
We've built CensorWatch, an android app which crowdsources measurements of internet censorship. This allows us to study censorship from different vantage points, which would otherwise be impossible to do at our scale.
If you live in India, please consider running it! It's completely anonymous, does not store any personal information, does not require any app permissions, and can be deleted after running (takes roughly 30 minutes). More information here -- https://cis-india.github.io/censorwatch/
I'm one of the authors of the paper in the post, we're trying to extend this work by crowdsourcing censorship measurements from different vantage points in India.
Do you have any plans of releasing an iOS app anytime soon? I’m going to recommend the Android app to people I know, but it would be good to have something for the iOS users too.
Thanks! This is interesting/useful/worrying. I note that there's an emphasis on web censorship, but do you have a feel for how other protocols are affected? I know that if the "plug" is pulled, everything would be affected, but what about file transfers using SFTP or FTP?
You never know. Could be a mistake where they were trying to block a certain path due to some search result of copyright infringement, but ended up banning the domain itself. One can only guess.
Reddit and Github have previously been temporarily banned in India due to similar "mistakes"
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.
Agreed, it's flimsy. Certainly a bit more effort for them spoof it correctly though. Would need to watch traffic on the path back per flow to isolate the number of prior decrements to the TTL leading up to MitM, and then store that value until such time that it sees an SNI it cares about / it's time to generate a reset.
This is not about the block a month ago. This is a new block.
When it was blocked a month ago, there was no notice. Now, there is a notice that it is a TRAI order. usually seen on sites that the govt themselves ask to block (piratebay, torrentz.eu, etc)
I guess its only limited to some regions. I'm using Airtel for my home connection as well mobile and get redirected to https everytime I visit the http version of ddg on both connections.
This is wrong. The ClientHello message is not encrypted in TLS 1.3, so, the client has to announce any extensions in plaintext. Thus the Great Firewall blocks connections which say they want to do encrypted SNI.
TLS 1.3 works fine in China, but if you use TLS 1.3 with the earlier proposed encrypted SNI draft it is blocked. The Great Firewall can't tell which name you actually wanted, but it can tell you're encrypting the SNI and block that.
With the currently proposed Encrypted Client Hello with a GREASE-style dummy ECH on all connections (so the "real" Hello is sometimes in an encrypted block and sometimes that encrypted block was just noise), China would still be able to choose to block all ECH-enabled connections since their presence is detectable. This would break everything, but China can choose to do that. What happens next is a policy question.
If you want to sneak past nation state snooping you need something else, that's not what TLS is for. The TOR project does not directly offer this either, but they can help you find out how to connect to TOR in a sneaky way if that's necessary for you.
If they block ESNI, it's likely all ESNI requests would be blocked, because they can't tell if its a blocked site or not. (it'd be possible they only apply ESNI-blocking against IPs associated with blocked sites, but that seems unlikely)
Agreed and since TLS 1.3 is still work in progress the chances are slim that you will find a blocked website that meets your criteria. Great article, very accessible. Thanks!
That RFC is marked as "PROPOSED STANDARD" which is why I saw it as work in progress but you're right, that seems to be the end of the road for RFC's (for example RFC 6455 December 2011 (websockets) is also marked as proposed standard but this is what everyone has implemented)
The IETF deliberately has no power whatsoever. Whether an IETF standards track proposal in fact becomes a standard everybody implements is entirely up to the implementers. This is in contrast to many standards development organisations (and indeed whether the IETF is even an organisation is open to doubt) which are government functions and can produce de jure standards you're obliged to implement or in the worst case force may be exercised against you by those with a monopoly on its use.
As a result IETF standards are only proposed and that is as you say "the end of the road".
> As a result IETF standards are only proposed and that is as you say "the end of the road".
Not really, after PROPOSED STANDARD there's INTERNET STANDARD, the STD series. For instance, IPv4/ICMPv4 (RFC 791/792) is STD 5, UDP (RFC 768) is STD 6, TCP (RFC 793) is STD 7, DNS is STD 13, and so on (STD 1 has the full list).
However, an IETF standard only reaches that level after it's been in use for a while; according to RFC 2026 (BCP 9), "A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level. An Internet Standard (which may simply be referred to as a Standard) is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community."
Using the TTL, we figured out that the censor kicks in at the kth hop. This kth box belonged to Airtel.
If a box was censoring after Airtel, we would have received a clean response (ICMP timeout) at hop k as well. Of course, the TTL itself can change during the run, but that wouldn't happen for so many cases :)
Thanks to everyone in this subthread. I'm on BSNL which I find is one of the Indian ISPs that seems to implement easy to circumvent blocks (DNS based), so far. Reliance no doubt is a different beast with its financial and technical clout and increasing market share. Rather concerning that we're quickly catching up to China in terms of implementing an increasingly sophisticated firewall.
Seriously can't expect the average Joe to know about stuff like greentunnel. And that's concerning...
We've built CensorWatch, an android app which crowdsources measurements of internet censorship. This allows us to study censorship from different vantage points, which would otherwise be impossible to do at our scale.
If you live in India, please consider running it! It's completely anonymous, does not store any personal information, does not require any app permissions, and can be deleted after running (takes roughly 30 minutes). More information here -- https://cis-india.github.io/censorwatch/