[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 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. And we don't know if the TCP test will fail for normal bridges
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?
I don't know.
> 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.
> > 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.
> > 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.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5028#comment:43>
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