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
-- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
