[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #20348 [Metrics/Censorship analysis]: kz no need tor, tor no need kz, if anybody want they can to use ultrasurf. cyberoam assists bloody dictatorships.



#20348: kz no need tor, tor no need kz, if anybody want they can to use ultrasurf.
cyberoam assists bloody dictatorships.
-----------------------------------------+-------------------------
 Reporter:  dcf                          |          Owner:
     Type:  project                      |         Status:  closed
 Priority:  Medium                       |      Milestone:
Component:  Metrics/Censorship analysis  |        Version:
 Severity:  Normal                       |     Resolution:  invalid
 Keywords:  censorship block kz          |  Actual Points:
Parent ID:                               |         Points:
 Reviewer:                               |        Sponsor:
-----------------------------------------+-------------------------

Comment (by dcf):

 kzblocked, I saw you on IRC asking about the ExtORPort and rate limiting.
 I seem to understand that the firewall might be detecting bridges because
 they detect the bridge reaching its capacity? Can you explain more about
 that?

 The ExtORPort is on localhost, but the first thing that the PT server
 sends to tor over the ExtORPort is the external client IP address. See:
 https://gitweb.torproject.org/torspec.git/tree/proposals/196-transport-
 control-ports.txt (it's the `USERADDR` command that informs of the client
 IP address). The client IP address is basically how all the country-
 specific graphs work on https://metrics.torproject.org/.

 The `USERADDR` stuff from that proposal is implemented, but the
 `RATE_LIMITED` stuff is not implemented—so if there's any rate limiting,
 it's being done by tor, not by the PT.

 Your experiments and https://lists.torproject.org/pipermail/tor-
 talk/2016-November/042586.html show that default bridges are getting
 blocked, but non-default bridges are less likely to get blocked. There
 must be something different about the default bridge. One possibility is
 that their timing characteristics are altered, because they are under a
 lot of load. Another possibility is that (maybe) firewalls around the
 world are colluding and counting connections, in order to identify popular
 destinations that also receive high-entropy traffic—this would probably be
 good against VPNs too.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20348#comment:65>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs