[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:43 karsten]:
> Replying to [comment:42 ioerror]:
> > 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.
>
> Testing a normal bridge and testing an obfsproxy bridge are two
different things.
Sure and they're both bridges.
> And we don't know if the TCP test will fail for normal bridges almost
all of the time.
>
Ah, to clarify, I mean _if_ the IP is known/blocked or an active probe is
confirms it in real time, we know those two issues well enough. The
problem scope is pretty well defined for those and we think currently that
obfu bridges are not yet in the protocol detection bucket but rather only
in the IP harvesting/known/blocked bucket.
> > 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?
>
> I don't know.
>
Me either.
> > 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.
>
> It's a start. It's not supposed to be perfect.
Sure, I think small batches are probably best at first.
>
> > > 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.
>
> I don't expect us to have time for another test after this one, so these
125 bridges will be it.
>
I'd suggest that for such a scan - the first test should be something like
a dozen bridges, the second the same dozen and so on. If you use all 125
at once, I wouldn't be surprised to learn that the next hour results in
all of them being blocked with no more bridges to experiment with or use
for the day.
> > > 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?
>
> Ah, the "report" would simply summarize what we found in this
deliverable, so that the sponsor doesn't have to read lengthy Trac
tickets. I'd simply start a LaTeX article document, but it could also be
a blog post. Something we can finish by tomorrow.
Well, it's 3am PST now on the 15th, so I think we'll need some data before
anyone can commit to writing up an analysis of that data. I'm happy to try
to understand the data and to contribute to whatever write up happens. I'm
going to sleep for a bit and then check back when I wake up.
Good luck with the data collection!
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5028#comment:44>
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