#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):

 Replying to [comment:3 dcf]:
 >  * MSS=1351 is unusual...
 > dcf connected to the server with ncat from Linux 4.7. The server's
 SYN/ACK had
 >   MSS=1350,SAckOK,Timestamp,NOP,WScale=6 (20 bytes)

 This might be the key. When reached over an uncensored link, the bridge
 reports its MSS as 1350. I.e., the largest TCP segment it can handle on
 its inbound link is 1350 bytes. But when contacted over the censored kz
 link, the "bridge" reports an MSS of 1351, one byte too big to fit through
 the link.

 A middlebox might have injected the SYN/ACK with MSS=1351. That then
 causes the client to send segments with 1351 bytes of payload, which then
 get dropped somewhere between the middlebox and the server.

 That would explain why the blocking is intermittent—the middlebox might
 have limited injection capability. It would seem the middlebox can also
 drop packets, as well as ACKing the client's data (and sending keep-alive
 ACKs). It doesn't seem like this trick would work when the server has an
 MSS greater than or equal to the client's, though, hmm.

 kzblocked, if you're reading this, please try reducing your OS's MTU; that
 should make a spoofed MSS ineffective. It looks like you can change it by
 setting the registry key

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

Reply via email to