The Geneva team has reported on a new protocol whitelister that has been deployed in Iran: https://geneva.cs.umd.edu/posts/iran-whitelister/
Here are my observations:
- They observe traffic to ports 53, 80 and 443 and block connections that are not DNS, HTTP or HTTPS.
- They monitor the first two packets only
- They are not able to reassemble the TCP connection. Sending “G”, “ET”, “/” for HTTP fails when “GET /” succeeds.
- Blocking happens by blocking the second and subsequent packets from the client.
- This aligns with pcaps I’ve seen for blocked Outline servers in Iran. The client is able to send some data, but the rest is blackholed and it looks like a client timeout from the server perspective.
- Server packets are not affected
- DNS-over-TCP is blocked, but usually there’s no second packet, so there’s not much disruption there.
- The whitelister is not bidirectional. You need to be in Iran to trigger it
- Not all destination IPs are subject to the whitelister. It’s unclear what IP ranges are affected.
- Their Geneva system learned some circumvention strategies:
- Send two empty FIN packets before the TCP handshake. You can’t implement this on mobile and it’s very fingerprintable.
- Send 9 ACKs during the TCP handshake. Also fingerprintable and not mobile-friendly.
- Send a HTTP GET fingerprint with corrupted checksum before each packet. Mobile apps could prepend traffic with a GET, but not tamper with the checksum.