[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: new
Priority: normal | Milestone:
Component: Ooni | Version:
Keywords: bridge-reachability metrics-db automation testing SponsorF20121101 | Parent:
Points: | Actualpoints:
--------------------------------------------------------------------------------+
Comment(by phw):
I am probably just stating the obvious here but perhaps I have some useful
remarks:
* 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?
* I have a pcap file containing the connections of several hundred
Chinese probes over a period of several weeks. It could be used for TTL
analysis etc. Drop me an e-mail if you are interested in the data set.
* A censor could also silently block bridges while at the same time
initiating dummy Tor connections to them so we wouldn't see the block in
the usage statistics. However, we will probably still be able to detect
this by users complaining over e-mail.
* The following is probably non-trivial but aside from the country-level
usage statistics, the feedback loop to scan bridges could also consider
passive individual bridge usage statistics. E.g., if a bridge recently saw
a connection from a censoring country, it might be reachable. On the other
hand, if a bridge has not seen connections in ''n'' days, it might be
worth scanning.
* As mentioned above, I think that packet fragmentation could be a good
way to scan bridges in China without triggering follow-up scanning. On a
more general note, we might have to come up with country-specific plans to
scan bridges without leaving dozens of blocked bridges behind us.
Regarding the open questions:
2. [http://www.cs.kau.se/philwint/censorbib/#Xu2011 This paper] contains
some additional information about the Chinese filtering infrastructure;
especially with respect to the filtering ASes.
2. That's hard to answer, given that I could not initiate any
communication with the probes other than the bridge scan. Figure 2a) in my
paper shows when we were able to communicate with what we believed was the
host "behind" the probe. Also, keep in mind that the IP hijacking is just
a hypothesis at this point and the evidence is not strong enough to
consider it as fact.
2. I haven't seen any evidence for service enumeration. Is this still
supposed to happen?
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.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6414#comment:7>
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