#20348: Kazakhstan blocking of vanilla Tor, 2016-06
 Reporter:  dcf                          |          Owner:
     Type:  project                      |         Status:  new
 Priority:  Medium                       |      Milestone:
Component:  Metrics/Censorship analysis  |        Version:
 Severity:  Normal                       |     Resolution:
 Keywords:  censorship block kz          |  Actual Points:
Parent ID:                               |         Points:
 Reviewer:                               |        Sponsor:

Comment (by dcf):

 kzblocked shared a pcap of trying to connect over obfs4 to the bridge
 Mosaddegh:80. I don't want to upload it without permission but I can
 summarize the interesting features.

  * The client sends a SYN with 12 bytes of TCP options:
  * The server replies with a SYN/ACK and 8 bytes of TCP options:
  * The client sends an empty ACK.
  * The client sends 5211 bytes of payload across 4 packets:
  * The server ACKs the client's payload but sends no payload of its own.
  * 5.2 seconds later, the server sends an ACK with an acknowledgement one
 less than the one it most recently sent (a TCP keep-alive).
  * The server sends 5 more keep-alives separated by 5 seconds.

 The server's TCP options are weird. MSS=1351,NOP,NOP,NOP,EOL.
  * MSS=1351 is unusual; there's only once case of it (M547) in nmap-os-db,
 "HP MSM410 WAP V. (Looks like Linux 2.6.32 --ed.)". MSS=1350
 is more common.
  * The NOP,NOP,NOP,EOL padding at the end isn't needed and it's out of
 character for a Linux server. TCP options need to be padded to a multiple
 of 4 bytes but the MSS=1351 option is already 4 bytes.
  * There's no WScale option, which is unusual for Linux.

 dcf connected to the server with ncat from Linux 4.7. His SYN had the
   MSS=1460,SAckOK,Timestamp,NOP,WScale=7 (20 bytes)
 The server's SYN/ACK had
   MSS=1350,SAckOK,Timestamp,NOP,WScale=6 (20 bytes)

Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20348#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
tor-bugs mailing list

Reply via email to