[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #6414 [Ooni]: Automating Bridge Reachability Testing
#6414: Automating Bridge Reachability Testing
--------------------------------------------------------------------------------+
Reporter: isis | Owner: isis
Type: project | Status: accepted
Priority: normal | Milestone:
Component: Ooni | Version:
Keywords: bridge-reachability metrics-db automation testing SponsorF20121101 | Parent:
Points: | Actualpoints:
--------------------------------------------------------------------------------+
Comment(by phw):
Replying to [comment:10 isis]:
> Replying to [comment:7 phw]:
> > * UAE and Ethiopia do not actually block bridges but rather network
packets. We need to distinguish between blocking Tor by protocol and by
end points (bridges/relays). Also, Lebanon and Qatar are new to me. It
would be helpful to add them to the
[https://trac.torproject.org/projects/tor/wiki/doc/OONI/censorshipwiki
censorship wiki] in case anybody knows more about that. Apart from China,
is there any country actually blocking bridges by IP and port at the
moment?
> UAE and Ethiopia block all SSL, correct?
>
> If so, there seems to be not much that Tor or any bridge tests can do
about that, at least not until more pluggable transports are deployed.
It does not look like UAE is blocking Tor at the moment but Ethiopia is
dropping the Tor TLS client hello and server hello. All the details are in
the one and only
[https://trac.torproject.org/projects/tor/wiki/doc/OONI/censorshipwiki
censorship wiki]! SSL in general is not blocked, though.
> > 2. I haven't seen any evidence for service enumeration. Is this still
supposed to happen?
>
> This is what I read, and if it is the case, i.e., that China blocks by
IP:port if there are other services, and elif by IP blackholing, then it
would make testing easier because, as I mentioned earlier, it would be
pretty trivial to fake services on a bridge that we set up (that way we
could just change the port to continue bridge reachability testing). If
you're not seeing it though, I suppose you've probably got more info on
this than anyone else, so it might not be happening anymore. Does this
mean they always dumb block on IP:port? Or are they always blackholing?
Yes, it looks like bridges (and even relays) are blocked by IP:Port. I
only saw IP blackholing for the directory authorities. I think that from
the GFC's point of view that's quite good: It has no collateral damage and
is still highly effective.
> > 2. It looks like the old concept of "scanning queues" in 15 minute
intervals changed a couple of weeks ago. What I am seeing now is real-time
scans which happen immediately after the GFC detected a potential Tor
connection. Then, you won't see any scanners for ~20 minutes even though
you continue initiating Tor connections. After ~20 minutes, there are
real-time scans again. I have yet to take a closer look at the data. If
anybody wants to help, drop me an e-mail.
>
> I'd take a look at it. Do you think the "twelve hours without a
successful connection from the probe" still applies to unblocking?
I reproduced this a couple of weeks ago and was able to unblock bridges
after just 2-3 hours. The time seems to vary but it should still work,
yes.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6414#comment:11>
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