#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:4 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.

 Someone on IRC commented on the TCP options, saying they are weird but not
 related to the blocks. They said that the options did not depend on the
 ISP, rather something in the middle. Testing outside of kz was "all ok".

 IRC user, what did you mean by that? Did you mean that outside of kz, you
 saw the same weird server TCP options MSS=1351,NOP,NOP,NOP,EOL?

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

Reply via email to