On Tue, Oct 22, 2013 at 11:44:46PM -0700, Adam Fisk wrote: > We do, however, strongly believe in the potential of WebRTC to provide both > interesting cover traffic as well as usability improvements that come as a > result of reusing technology already built into the browser.
I agree! I think the Flash Proxy people have already done some really neat things with Websocket, and I look forward to seeing more use of WebRTC in this area. > Another really vital aspect to both Lantern and UProxy is blocking > resistance, and particularly the idea that trust networks are a promising > path forward in that regard. 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"). 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". On the flip side if webrtc turns out to not have any background traffic to blend with yet, the uproxy people would do well to make it easy for them to pop in some other transport. And if that flip side turns out to be how things unfold, saying phrases like "uproxy's broken, lantern's better" will just confuse the situation further. At this point it makes sense to say phrases like "the uproxy people" and even "the current uproxy design", but thinking that when uproxy-painted-white stops working your best bet is to throw it out and find a new team to build you a red uproxy... that approach leads to a lot of wasted money, and not as much forward progress as we could have. Funders are slowly starting to get it, but as Shava points out, journalists thrive on maintaining and growing this misunderstanding about how good free-software engineering should work. (I think Adam gets most of this, but I'm saying it out loud for everybody else here.) > 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 ) > 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. :/ > > I would be more concerned with adversary externaly > > observing the connections, seeing that a group of people from within > > country X are connecting to the same ip in country Y , thus relating > > those people in that group as sharing a node in a social graph, so to > > each other, while they might not have seen them as related before.. > > This is a concern that was discussed at some length yesterday at the Google > Ideas Summit, and it's a really astute observation others have also made, > most recently at CTS in Berlin. With Lantern it's considerably less of an > issue because Lantern uses > Kaleidoscope<https://github.com/getlantern/kaleidoscope> to > also share connections of contacts who are not direct friends, in Lantern's > case up to four degrees away. While that raises its own concerns in terms > of proxying through essentially total strangers (again with blocking > resistance as the goal), it does mitigate against social network mapping > attacks. In both the UProxy and Lantern cases, however, there is more > thought and research to be done, as it's not immediately obvious how > significant it is that two people know the same person, particularly when > that person is inherently living in another country that is uncensored. > That is by no means an effort to dismiss the critique but rather an > observation that the conclusions to draw aren't obvious at least to me. 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. --Roger -- 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.
