Throttling of Twitter domains in Russia #65
Comments
|
Roskomnadzor made a press release (archive) with the ostensible reason for the throttling.
The Associated Press noted (archive) that at the onset of the Twitter block, some Russian government web sites also experienced slowdowns and outages.
More discussion on Habr: РКН замедляет Twitter (archive). Other links:
|
|
Updates from the past day in the NTC thread:
Throttling of unrelated domains endsIt appears that the unintentional throttling of non-Twitter domains ended at about 2021-03-11 08:00 UTC. Twitter-related domains are still throttled as before. https://ntc.party/t/twitter/907/84 2021-03-11 09:46
https://ntc.party/t/twitter/907/85 2021-03-11 09:58
Test pagesResearchers have set up test pages for people to test their own connections. Test for non-Twitter throttling, by @darkk with help from @bassosimone and @m-lab: Test for Twitter throttling, by @4ndv: https://ntc.party/t/twitter/907/68
https://ntc.party/t/twitter/907/94
|
|
There is something that I have been seeing in Iran for a long time. Because of the bandwidth-throttling, the upload speed was much faster than the download speed. Or that UDP speeds were sometimes 30 times faster than TCP. I use a method to test this type of internet disruption that I don't know if there is a better way or how it can be improved. Is this method correct or will it cause abuse? Probably this method can be tested in Russia, in a situation where only the download from Twitter has slowed down. Create a header file with the following content: That Test upload: # curl -X POST -d @fakeheader.txt -Lo /dev/null -skw "\ntime_connect: %{time_connect}s\ntime_namelookup: %{time_namelookup}s\ntime_pretransfer: %{time_pretransfer}\ntime_starttransfer: %{time_starttransfer}s\ntime_redirect: %{time_redirect}s\ntime_total: %{time_total}s\n\n" https://video.twimg.com/robots.txt
time_connect: 0.063130s
time_namelookup: 0.048475s
time_pretransfer: 0.124583
time_starttransfer: 0.124592s
time_redirect: 0.000000s
time_total: 5.449413s
Test download (as they did in ntc.party) # curl -Lo /dev/null -skw "\ntime_connect: %{time_connect}s\ntime_namelookup: %{time_namelookup}s\ntime_pretransfer: %{time_pretransfer}\ntime_starttransfer: %{time_starttransfer}s\ntime_redirect: %{time_redirect}s\ntime_total: %{time_total}s\n\n" https://video.twimg.com/ext_tw_video/1201955484183531521/pu/vid/720x1280/6VWb4aD7I6HrBQqD.mp4?tag=10
time_connect: 0.049789s
time_namelookup: 0.035611s
time_pretransfer: 0.124363
time_starttransfer: 1.924300s
time_redirect: 0.000000s
time_total: 2.804413s
(This sample test was performed in Netherlands.) The point is that the server first receives the HTTP data completely and then processes it. (And we download almost nothing.) |
|
Some users on the NTC thread reported an occasional lack of throttling. @darkk 2021-03-17 16:08 https://ntc.party/t/twitter/907/125
@ValdikSS 2021-03-19 20:20 https://ntc.party/t/twitter/907/128
|
|
Censored Planet published a report on the ongoing Twitter throttling, with detailed technical measurements. Throttling of Twitter in Russia 2021-04-06 One of the main observations is that throttling is being managed in a different way from how site blocking in Russia is done. In site blocking, though the list of sites to block is managed and dictated centrally by Roskomnadzor, it is individual ISPs that are responsible for enforcing the blocks, a situation that Censored Planet has previously called "decentralized control". In contrast, this research shows that not only are the devices that perform throttling separate from ISPs' usual blocking filters, they are highly uniform across ISPs and probably centrally operated by Roskomnadzor. This centralized mode of operation more resembles the way censorship is done in other countries, like China and Iran. The current belief is that the throttling devices are TSPU (ТСПУ, технические средства противодействия угрозам) DPI boxes, and that this is the first major application of them. The research team conducted measurements from 7 landline and mobile vantages in Russia. After verifying that all 7 vantages experienced throttling, they began experiments using a "record and replay" technique. They recorded a traffic capture of an unthrottled host in Russia requesting an image from a Twitter server, then replayed that traffic towards a controlled server in the US from the throttled vantages, testing the effects of various modifications to the traffic. The essential feature that triggers throttling is the TLS ClientHello record—specifically the critical data fields are ContentType=handshake and HandshakeType=client_hello. The detection devices actually parse ClientHello records: it is not enough for the Twitter domain simply to be present as a substring, it must actually be contained in the server_name extension (SNI). The ClientHello does not have to be in the first TCP segment past the handshake, but it does have to appear at the beginning of a segment, and cannot span multiple segments. The detection boxes can detect a ClientHello with an actionable SNI even if it is preceded by up to about 20 other TLS records, or up to 101 non-TLS bytes (which means that throttling even affects Twitter connections through plaintext proxies, like SOCKS or HTTP proxies). Detection is not symmetric, in the sense that only connections that originate in Russia are throttled. But once the connection is established, directionality does not matter: a matching ClientHello results in throttling even if sent by the TCP server. Throttling is implemented by packet dropping, which is observable as gaps in received IP ID sequences. (One mobile vantage showed evidence of delay-based, rather than drop-based, throttling on uploads, but that may have been caused by other traffic controls implemented by the ISP, unrelated to Twitter throttling.) Both upstream and downstream are throttled independently, to about 128 kbps. If you leave a throttled connection idle for about 10 minutes, throttling will expire and the connection will be usable at full speed again—but sending packets before those 10 minutes expire will renew the timeout. Sending a FIN or RST packet, which has proven useful in confusing some middlebox state machines, does not work in this case to expire the throttling. Using limited-TTL experiments, the authors found that the throttling devices are located closer to end users (≤5 hops) than are the usual network filter devices (5–8 hops). This is consistent with TSPU installation guidelines sent to ISPs by Roskomnadzor. The high degree of uniformity in detection and throttling behavior across ISPs points to such a unified implementation. The report observes ways to circumvent throttling:
|
Starting at about 2021-03-10 07:00, access to Twitter-related domains, like twimg.com and t.co, was throttled in Russia. As a side effect, not only those domains, but also all domains containing "t.co" as a substring were throttled, including, for example, rt.com, reddit.com, and microsoft.com.
NTC has a thread all about it, in Russian. I will try to summarize the main points.
If you make an account at NTC and log in, there will be an automatic translation button under each post. That is the source of the translations into English here.
Classification is by TLS SNI only
The decision of what gets throttled depends only on the TLS SNI, not destination IP address or anything else. SNI-less TLS sessions to Twitter servers are not throttled. TLS sessions with a spoofed Twitter SNI, to non-Twitter servers, are throttled.
https://ntc.party/t/twitter/907/11
https://ntc.party/t/twitter/907/24
Throttled speed is reported to be 128 kbps
https://ntc.party/t/twitter/907/5
https://ntc.party/t/twitter/907/6
Domains with "t.co" anywhere are affected
The evident intent was to throttle traffic to t.co, which is Twitter's link-shortener domain. But throttling affects any domain with "t.co" anywhere as a substring. This includes, for example:
https://ntc.party/t/twitter/907/27
The unanchored substring matching is very obvious with "t.co", but it also appears to happen with "twimg.com":
https://ntc.party/t/twitter/907/11
https://ntc.party/t/twitter/907/73
The throttling devices are separate from ISPs' normal filtering devices
By using different circumvention techniques, it is possible to construct traffic that is detected and blocked by the usual censorship of Russian ISPs, but which bypasses the throttler. This indicates that the throttling is being done by a separate device, perhaps upstream from ISPs.
https://ntc.party/t/twitter/907/22
https://ntc.party/t/twitter/907/35
The throttling was temporarily disabled and then reenabled
2021-03-10 09:33
https://ntc.party/t/twitter/907/14
2021-03-10 10:03
https://ntc.party/t/twitter/907/18
Doug Madory posted a graph that shows fluctuations in traffic to Rostelecom, with timing that matches up with these reports.
https://twitter.com/DougMadory/status/1369648537634545673 (archive)
The text was updated successfully, but these errors were encountered: