Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] [SPAM:###] Re: Google Unveils Tools to Access Web From Repressive Countries | TIME.com

Adam Fisk afisk at bravenewsoftware.org
Thu Oct 24 14:39:32 PDT 2013


Now that's what I call a productive, collaborative email. Awesome. Thanks
Roger. Responses inline.

Yep. I think using trust networks to solve the "how do I learn about a
> proxy to use" question could work well for some (many) users. I haven't
> looked at all the Lantern details lately, but if I had to guess it
> would be Lantern's transport that falls first (to use the phrase from
> one of the pluggable transport researchers who was looking at it today,
> "udt encapsulated tls handshake is really easy to regex").
>

Yup completely agreed. The UDT piece of Lantern is definitely the weak
link, although I will say it's also an interesting weak link in that
there's unlikely to be a censor out there now that can quickly DPI some
pretty weird UDP packets going across the wire at least using currently
available software. Then again, maybe you know something I don't, and maybe
it is possible to apply a global regex rule to all UDP traffic from some of
these boxes (clearly it's possible generally, but is it possible
country-wide *now*?). Lantern does also use TCP when NAT-PMP or UPnP are
working on one of the endpoints, so it's a combination of the two.


> Now the point isn't to guess which part will be the weakest link. Or
> to say "well ok if they write a DPI rule for it we'll fix it then". The
> right goal imo would be to make it so it's easy to switch to the webrtc
> transport, or obfs3, or something else that turns out to not be broken
> at that time, while still using the same discovery mechanism.
>
> In that sense uproxy as I understand it might be described as "the
> lantern discovery mechanism, but with a webrtc transport rather than a
> udt transport".
>

Precisely, albeit with the TCP caveat above.


> > I think we're seeing this now with private Tor
> > networks where bridges are distributed through trusted contacts, and
> that's
> > exactly what we're after with both Lantern and UProxy.
>
> Just to clarify, it isn't private Tor networks. It's one big public
> Tor network (everybody needs to use the same one for anonymity),
> but private bridges. (Bridges are basically unlisted relays
> that let you use as your first hop to reach the public relays:
> https://www.torproject.org/docs/bridges )
>

Excellent point.


>
> >  The above quote I think
> > is an unfortunate combination of a limited understanding of the
> technology
> > and conversation with a reporter who will pick the juiciest sound bites,
> > but it's clearly incorrect and just dangerous.
>
> Right -- I think we're all getting more experience than we'd like this
> year talking to journalists whose deadline is "in four hours" and who
> have no interest in actually learning about the issues. :/
>

Umm, yeah. I need to learn to STFU =).


>
>
> Preventing or slowing the 'social network mapping' attack is an important
> goal.
>
> But this discussion also reminds me a lot of the "Zig-zag between bridges
> and users" attack:
>
> "Start with a set of known bridge addresses. Watch your firewall to
> see who connects to those bridges. Then watch those users, and see what
> other addresses they connect to. Wash, rinse, repeat."
>
> You can read more about it as attack #10 at
>
> https://blog.torproject.org/blog/research-problems-ten-ways-discover-tor-bridges
>
> In the Lantern / uProxy case I could probably speed the attack by feeding
> users a cookie on one of the censored websites (or a component the
> website draws in like an ad network), and then making a list of other
> addresses whose requests include that cookie. (But here I am making a
> point about how ignoring privacy will harm your circumvention tool, and
> you've already declared that you're a circumvention tool not a privacy
> tool, so I'll put that point aside for now. :)
>
> I wonder how much change Kaleidoscope would need to implement the 'cells'
> idea in the blog post. As you say, much research remains.
>

Yup. Kaleidoscope addresses the issue of discoverability through first
choosing which proxy addresses get propagated via a random walk but then
routing along that random walk consistently after that first route
selection, if that makes sense, such that new nodes in the system can't
learn about all of the existing nodes because all existing routing is
consistently using the formerly-chosen routes. So it's similar to the cell
ideas in the sense that it's like a courier who initially didn't know the
shopkeeper she's supposed to drop off a letter too such that a letter gets
passed along, but once the courier knows the shopkeeper she never goes to
any other shopkeeper.

Definitely more work to be done, but we're really interested in
interoperating using pluggable transports for sure. The other part in terms
of discovery is really interesting as well, and I'd be happy to talk more
about it. Interestingly I think that part is extremely easy. Really all
Lantern does is log into Google Talk and then give mode peers/bridges
advertise Lantern support through the -lan- extension in their Jabber ID.
You could argue there's a privacy leak there, but the only peers that see
that -lan- extension by default are peers on your XMPP roster, so peers
you've already approved. So it could be really easy to integrate that into
Tor, but we'd be happy to talk about that more or to help however we can.

Thanks again Roger.

-Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20131024/aa1b09a3/attachment.html>


More information about the liberationtech mailing list