My observations on how local authorities censor the World Wide Web are very limited. From time to time I have to start a network sniffer to investigate some seemingly absurd network problems. Later these appear to be our new Internet restrictions according to an ‘Uzbekistan’ page of the annual ‘Freedom on the Net’ report by Freedom House. I can summarize what I stumble upon as follows.
1. Shaping the traffic for Internet censorship First noted around 2018 as a Facebook problem, traffic shaping is trending as a filtering technology here. Some connections, which where interrupted or routed to nowhere previously, are now rate limited to turn useless.
Bandwidth limiting is aggressive. It starts from the very first packets. It’s purely SNI-based. TLS 1.0, 1.2 SNI-less connections to banned resources are not interrupted and do work as needed Server certificates don’t trigger the shaping.
Curl’ing a blocked resource with an -m option often ends just immediately, as no TLS connection could be established at all. Segments are being lost in both directions. A TCP flow diagram looks really horrible. Twitter, Viber, Skype, and mobile devices’ power sources are among the affected.
2. Blocking TLS connections by injection of TCP segments with the FIN flag set in reply to the ‘Client Hello’ messages It’s still a popular filtering technique, entirely SNI-based again. SNI-less connections to banned resources are not interrupted and do work as needed.
FIN segments inserted have right syn and ask values, but are still distinguishable by their weird timing (they come too fast to originate from a server abroad), ‘random’ IP IDs, and non-empty data (proudly reporting some ‘Middlebox v 1.0’ usage as a plain text string).
Dropping these SYNs with nftables causes them to be reinserted several times with one second delay, followed by the final RST segment. The later comes with right syn and ask values and no data, albeit again it has a ‘random’ IP ID and follows the same single second temporal pattern.
No data from the remote server appear in between these injected segments. That points to the next level of filtering equipment installed in-path.
Some times ago I also noticed forceful setting of FIN flags in what looked like genuine remote server replies to the ‘Client Hello’ messages. No in-path blocking equipment was seen in such cases. I don’t know, whether such blocking method is being employed now.
3. RSTing TCP connections It’s used, probably, for non-TLS TCP connections our state censors want to interrupt. Injected segments again have proper syn and ask values and no data. They come too fast to originate from a remote server and possess ‘random’ IP IDs. RSTs arrive after several seconds since the 3-way handshake, therefore services blocked in such a way look ‘half-working’ for their users.
As of what is being blocked in Uzbekistan one could look at OONI measurements (OONI forever!).
To put things into the context I’d recommend the already mentioned collection of ‘Freedom on the Net’ reports on Uzbekistan (a great work by The Freedom House).
A couple of RIPE probes seems to be active in the country. Kudos to those, who maintain them!
OONI just published a report on Signal blocking that has a section on Uzbekistan. There were not many Signal measurements from Uzbekistan, but all measurements showed blocking.
When attempting to perform a TLS handshake to all Signal backend services, the connection constantly times out after writing the first data packet to the network, as illustrated through OONI data below.
{ "operation": "connect", "address": "173.194.220.121:443", "proto": "tcp", "t": 0.474921823, "failure": null }, { "operation": "tls_handshake_start", "t": 0.47523901, "failure": null }, { "operation": "write", "num_bytes": 288, "t": 0.478659219, "failure": null }, { "operation": "read", "t": 10.477152913, "failure": "generic_timeout_error" }, { "operation": "tls_handshake_done", "t": 10.47733385, "failure": "generic_timeout_error" },
What do you think? Are these timeouts an instance of your 1. Shaping the traffic for Internet censorship? I found another measurement that has some successful "read" events before it starts timing out. (Expand the test_keys.network_events array in the JSON.) The fact that some reads were possible seems to match your observation about rate limiting, rather than complete blocking.
{ "operation": "connect", "address": "76.223.92.165:443", "proto": "tcp", "t": 0.259690886, "failure": null }, { "operation": "tls_handshake_start", "t": 0.259772552, "failure": null }, { "operation": "write", "num_bytes": 307, "t": 0.262190208, "failure": null }, { "operation": "read", "num_bytes": 517, "t": 3.775013176, "failure": null }, { "operation": "read", "num_bytes": 831, "t": 3.77526703, "failure": null }, { "operation": "read", "t": 10.28804083, "failure": "generic_timeout_error" }, { "operation": "tls_handshake_done", "t": 10.288115725, "failure": "generic_timeout_error" },
It looks like that ugly shaping. False FINs’ I/O pattern is replicating itself just exactly among measurements. Moreover, false FINs are 1-RTT fast. Only triple handshake’s SYN,ACK segment actually arrives from the remote server.
But let me remind you again, my observations are very limited.
For the first time I’ve observed a Server Certificate-based blocking. Even SNI-less TLS 1.2 connections turn dead after a ‘wrong’ (from our state censors’ point of view) Server Certificate message. As Server Certificate messages span over several TCP segments, I still can see their beginning.