Detecting and Evading Censorship-in-Depth: A Case Study of Iran’s Protocol Filter
Kevin Bock, Yair Fax, Kyle Reese, Jasraj Singh, Dave Levin
https://censorbib.nymity.ch/#Bock2020a
https://www.usenix.org/conference/foci20/presentation/bock (video and slides)
https://geneva.cs.umd.edu/posts/iran-whitelister/ (blog post)
The paper is about a new component of the Internet censorship system in Iran: a protocol filter that permits only certain protocols on certain TCP ports. The protocol filter, newly activated in February 2020, is separate from, but operates in concert with, the previously existing “standard” DPI-based censorship in Iran. A connection is blocked if it trips either of the two censorship systems.
The protocol filter operates on TCP ports 53, 80, and 443 only. On these ports, connections are only allowed if they match the protocol fingerprint of DNS, HTTP, or TLS. The protocol fingerprint is not paired with a specific port as you might expect: any of the three protocols may be used on any of the three ports. The filter looks at the first two data-carrying packets after the TCP handshake. If the two packets together do not match one of the permitted protocol fingerprints, then every packet after the first will be dropped for 60 seconds. If another non-protocol-conforming flow is sent to the same destination before the 60 seconds are up, the timer is reset. The protocol filter does not do TCP reassembly, nor verify packet checksums. It is unidirectional, only operating on flows that originate in Iran. Curiously, not all destination IP addresses are affected equally. Of an Alexa top 20K list of destinations, only about 18% were consistently affected by the protocol filter.
Section 4.3 gives precise descriptions of the protocol fingerprints the filter looks for. For example, to qualify as HTTP, the combined payload of the first two packets must be at least 8 bytes long, and begin with GET , POST , HEAD , CONNECT , OPTIONS , DELETE , or PUT . The DNS protocol fingerprint has a bug, which is that it matches the format of DNS over UDP, and doesn’t account for the length prefixes that are a feature of DNS over TCP. DNS over TCP still works in Iran, despite the bug in the protocol filter, because an entire DNS query fits in one TCP packet, and the filter never blocks the first packet in a flow.
The authors use Geneva (see previous summary) to automatically discover ways to evade the protocol filter. They find four evasion strategies, three client-side and one server-side:
- (client-side) At the beginning of the flow, send a packet with a protocol-conforming payload but a bad checksum. The filter, which does not verify checksums, marks the entire flow as protocol-conforming, while the packet with the bad checksum is ignored by the destination.
- (client-side) Send two or more FIN packets before the TCP handshake.
- (client-side) Send nine ACK, RST, or SYN packets at the end of the handshake.
- (server-side) Send nine SYN/ACK packets with incorrect acknowledgement numbers. This causes the client to send nine RSTs, effectively inducing the client to perform Strategy 3.