wkrp
commented
2 hours ago Thanks for this information!
OONI has been working on a methodology for measuring throttling. They may be interested in hearing about your results.
The pcap files are hosted on a personal repository because github doesn't allow attaching pcap files in issues.
BTW, a workaround for that is to gzip the pcap files before attaching them. It's possible to attach .gz files to issues.
Whenever a natural disaster or other major event happens in Turkey, the Turkish government dials their DPI clusters up to 11 to prevent people from talking about it online on social media. But instead of using RST injection like they do with most blocked domains, they throttle connections. This has been covered multiple times before by OONI, #155 and probably many others. But I haven't seen a post that looks at exactly how it works under the hood and figured I might document it in case it's useful for someone else.
I took some packet captures of the social media throttling that happened after yesterday's attacks in Ankara. The DPI here is pretty standard, it looks at the Host header in HTTP requests and SNI field in TLS Client Hello to start interfering. Unlike some other countries, the censor doesn't look at the TLSv1.2 Server Hello certificate domains and also doesn't look at HTTP/3 or QUIC, but that's a post for another day.
I've recorded both sides of a basic TLSv1.2 handshake + TCP termination handshake from a Turkish ISP (Superonline) going out to a VPS I own to compare timings, both with a censored SNI and an uncensored SNI for control. The handshake fails with an Internal Error here, probably because the backend wasn't expecting the SNIs I used, it's not related to middlebox interference and doesn't change any of the observations.
Note: as of Oct 25, Tiktok and other social media aren't throttled anymore, though this same behavior has been permanently on for VPN providers for many years. Possibly to get connections to time out slowly and not allow clients to detect blocks as easily. Certain VPN protocols like Wireguard on well-known ports are also dropped on some mobile networks, though only on UDP.
The IP and MAC addresses on the pcaps were anonymized with tcprewrite. The pcap files are hosted on a personal repository because github doesn't allow attaching pcap files in issues.
Client
The mismatch of IPs is because
235.86.126.254represents a NAT'd IP like 192.168.X.X. Same deal with mismatching ports and MAC addresses.Server
Based on the timings, it looks like the censor starts slowing things down for both sides as soon as it sees an offending Client Hello packet. I'm suspecting the natural congestion control of TCP is making things even worse as retransmissions eat into the maximum bandwidth, slowing down both the client and the server. I've yet to test this out though. There are a few other things to test like IP packet fragmentation and different MSS values. Though I feel like they would only make things worse without jumbo frames, which isn't applicable on the open internet.
The packet captures attached here are very small because a full page load of something like protonvpn.com can take up to 2 minutes with the amount of packet loss. Though I'm happy to share a large pcap file like that if anyone needs it.
There's a tool I'm working on for fingerprinting the behavior of censors. I'm wondering how to fingerprint throttling to compare behaviors between different ISP/country censors. Probably needs involvement on both client and server to compare against control timings. Just something to think about.