#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 tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs