[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #5028 [Ooni]: Tor bridge scanning
#5028: Tor bridge scanning
---------------------+------------------------------------------------------
Reporter: hellais | Owner: runa
Type: project | Status: assigned
Priority: normal | Milestone: Sponsor F: March 15, 2012
Component: Ooni | Version:
Keywords: | Parent:
Points: | Actualpoints:
---------------------+------------------------------------------------------
Comment(by ioerror):
Replying to [comment:41 karsten]:
> Replying to [comment:40 ioerror]:
> > It seems like such an automated scan should contain special cases for
countries with network censorship systems that are as advanced as China.
>
> Sure. In the long run we could do full Tor handshakes for most
countries and just the TCP scan for China. But we'll have to start
somewhere, and the TCP scan seems to be the safest approach.
Hrm. I think that full Tor handshakes are best all around - the question
is more about how we transport the handshake - that is to say that a full
obfu bridge test is the useful test for China today, not TCP or TLS - we
already know the latter two fail almost all of the time.
I do agree that a TCP scan is safer for China than a full handshake but
I'm not convinced it is terribly useful for China for that very same
reason. I do think one useful outcome of the TCP scan is that we might
learn where other people have triggered an active probe that resulted in
an IP block. I wonder though, do we know for sure that active scans put
those IP addresses into a firewall forever? Or have active scans replaced
that static block list?
>
> > > > Obfu bridges are generally reachable, tls bridges are generally
blocked either before we test or by confirmation with a follow up probe.
Has that changed?
> > >
> > > I wouldn't know.
> >
> > This is a test that seems extremely relevant and if we're going to do
scans from China, I bet it's one of the safest and most useful.
>
> If we only scan obfsproxy bridges, we'll only learn if those are
reachable. But we want to have a mechanism for telling if normal bridges
are reachable as well. Excluding obfsproxy bridges for the moment.
>
Ok. I think that if we exclude those, we'll have a set of bridges that
have likely been harvested and blocked or just blocked by active probing.
It's not clear how we'll know the difference with a TCP connection scan.
> > > > Are we doing a scan of the obfu bridges? Or just the normal
HTTPS/TLS bridges?
> > >
> > > We're scanning normal HTTPS/TLS bridges, no obfsproxy bridges.
> >
> > Ok. Are we scanning from all buckets or just a single bucket?
>
> The plan was to scan all HTTPS bridges, but I guess we can reduce that
to 2 out of 5 rings. 125 bridges in total.
>
I think the lower the number, the better a chance we'll get at refining
these tests over a few hours - if we lose them all in on shot, we're sorta
out of luck until they churn.
> > The ground truth for China is different from other countries these
days. Any automated tool to do this kind of scanning should not have an
assumption that IP or TCP connect scans and a full handshake with data
will produce the same results.
>
> Right, that's an assumption that needs to be made explicit. Want to
help write the report, so that these things come over correctly?
I'm happy to look at the data but I don't know what such a report entails,
I assume that's a different deliverable?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5028#comment:42>
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