#1

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.
#2

One question I have: can you establish a connection, wait some time, then use it freely?
Depending on how long you need to wait, a circumvention tool could leverage a pool of connections that are set up before they are needed.