Re: [tor-dev] Potential projects for SponsorR (Hidden Services)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 George Kadianakis wrote: == Opt-in HS indexing service == This seems like a fun project that can be used in various ways in the future. Of course, the feature must remain opt-in so that only services that want to be public will surface. For this project, we could make some sort of 'HS authority' which collects HS information (the HS descriptor?) from volunteering HSes. It's unclear who will run an HS authority; maybe we can work with ahmia so that they integrate it in their infrastructure? If we are more experimental, we can even build a basic petname system using the HS authority [2]. Maybe just a simple NAME - PUBKEY database where HSes can register themselves in a FIFO fashion. This might cause tons of domain camping and attempts for dirty sybil attacks, but it might develop into something useful. Worst case we can shut it down and call the experiment done? AFAIK, I2P has been doing something similar at https://geti2p.net/en/docs/naming We have been running our petname system for at least five years (probably longer), mostly without incident. The above linked page covers details of the current system; see [0] for a (slightly dated) more general discussion of the reasons behind the I2P naming system, common arguments and possible alternatives. We have also started looking at GNS as an option[1,2]. I like the concept, and the ability for users to easily control their own domain name zones, which replaces the problem of a user losing their Destination keys (.onion equivalent) down to only needing to securely maintain their zone key. But the UI/UX needs vast improvement if everyday users are to understand it, and we need to research the trade-offs carefully. I am happy to discuss this further if anyone is interested, because a combined / general approach would benefit multiple networks. str4d [0] https://geti2p.net/en/docs/discussions/naming [1] http://zzz.i2p/topics/1545 (in I2P) [2] http://trac.i2p2.de/wiki/GNS -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJURgOtAAoJEIA97kkaNHPnfUQP/RQIBUCjCQcRvDyXL5l+D0Cv yoE7JT2vr7mqQx+/4nT9w/EhuQvakS5lK8gsod3yHDErtbNa8Ot/NylDbPYvdSo0 mXYOWRtaozv/8VIrRZuFc1NLne/08RYAIrnC3A9NCbpCcvwVLMxWXdl3DzEuZ+R5 rVijvHXW2nhVKjEYFez4dtErA+qTC/nKtdlG5hG1gq4mTTbWyYPEVmUonZe7t8l6 +iVc5jG9bKS6ng1Mcvmj5XwDN2rRRk3igo+64gyk7GsHSi3IXxq2S8H+hVD16hk+ gPmS0+oX5Vy6Ww04xM+x55X3NBHbLzkb+dEMYC/gYVLZrmxeG76iAQ/vBDCJncGC 8JI+KhoCx/hQGzvIby1T2VEf8t/fyREKwDq/jmAQdraxqoA5/z5xHwgpetNRRJOM 6LuOtc3jkxe0fOrsJcvHXLQybOKE8bLrLf0jLlmOpKR60EqmFAZaXC8qbzfItvaA KBHKO9t4e1F0t96PH0qhTJjlqqJVunfHyaulC6i9/HBRIZAnjrDtxvN9oQgtyYzI TRw/uxqR0o4c3iDet472YOjLR0JDwz23OHGT66VG/xiNYN2siNpSeBoVXmpc7YuC PGqjgZJkl3EZ/AIU+2mS+lAvmouT9UmW58fIF0BD+bmsr1//zfCIxXH8/EeOZBCw sXUQa30VVMdDYCmQc8dX =HUK1 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Pluggable transports meeting tomorrow (16:00UTC Wednesday 22nd of October 2014)
Hello! just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Thanks for your attention! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] 5-hop hidden service circuits (was: Potential projects for SponsorR (Hidden Services))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/10/14 14:37, George Kadianakis wrote: On an even more researchy tone, Qingping Hou et al wrote a proposal to reduce the length of HS circuits to 5 hops (down from 6). You can find their proposal here: https://lists.torproject.org/pipermail/tor-dev/2014-February/006198.html The project is crazy and dangerous and needs lots of analysis, but it's something worth considering. Maybe this is a good time to do this analysis? One aspect of this proposal that might be problematic: the client and hidden service negotiate a random number and use it to pick a rendezvous point from a list of candidates. They must have matching lists of candidates. With a similar idea in mind, I recently looked into how long it takes for two clients to obtain copies of the same consensus. I found out that this is never guaranteed to happen, because each client may skip a consensus each time it downloads a fresh one. That would need to be addressed before implementing the 5-hop proposal. https://lists.torproject.org/pipermail/tor-dev/2014-September/007571.html Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJURlAkAAoJEBEET9GfxSfM8u0H/26wRDiVzzYZopgIb1Vlb99q FuPAF5D0quETvAoYxcxpN72+pJjIWOdmccw4NURpJQ7FYYQgbTEirNPqmaeZjDt7 T9IG4goL8CIyxlFA25Kbb6bCf1xLtIOJHksdtCNeLnf8wsLyOYlW7kZEhQQpojzM 1TScWp9rfSfJc/P6juGad6H0BKaLDhsmUb1gtBGYS7JHQNNovruqVugI+Q2iqzOK UhvBW2Lfhnf42HuTfal/oQaq3z00wPPxmqA25GmTmrzhUU0xqqHKHrReV7YqppOw GZH2SSxpcnV1EQ/M/fh8jMtsaGZiQe1bCZQqjwOudkuinpoir7RiCU9QS3PytiM= =2oJx -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] 5-hop hidden service circuits (was: Potential projects for SponsorR (Hidden Services))
On Tue, Oct 21, 2014 at 8:23 AM, Michael Rogers mich...@briarproject.org wrote: On 20/10/14 14:37, George Kadianakis wrote: On an even more researchy tone, Qingping Hou et al wrote a proposal to reduce the length of HS circuits to 5 hops (down from 6). You can find their proposal here: https://lists.torproject.org/pipermail/tor-dev/2014-February/006198.html The project is crazy and dangerous and needs lots of analysis, but it's something worth considering. Maybe this is a good time to do this analysis? One aspect of this proposal that might be problematic: the client and hidden service negotiate a random number and use it to pick a rendezvous point from a list of candidates. They must have matching lists of candidates. With a similar idea in mind, I recently looked into how long it takes for two clients to obtain copies of the same consensus. I found out that this is never guaranteed to happen, because each client may skip a consensus each time it downloads a fresh one. That would need to be addressed before implementing the 5-hop proposal. Yeah, Qingping assumed that clients did converge on the same consensus, and handwaved over the and they prove to each other they are using the same consensus part. I agree that needs to get fixed first. Qingping graduated and my group has a lot of other projects to juggle right now, but we are in principle still interested in pursuing that to some sort of definite conclusion. Funding of course helps free up student time :) zw ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Potential projects for SponsorR (Hidden Services)
On Mon, Oct 20, 2014 at 02:37:49PM +0100, George Kadianakis wrote: this is an attempt to collect tasks that should be done for SponsorR. You can find the SponsorR page here: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR Thanks for getting this going! == Safe statistics collection == We've discussed this quite a bit over the past year and I think we all pretty much agree on which stats are safe to collect and which not. I think we know some safe first-round things to collect. But I bet there's a lot more that's grey-area. I think we all agree that collecting the number of HS circuits and traffic volume from RPs (#13192) is harmless [0] and useful information to have. We need to clean up Roger's patch to add that information in extra-info descriptors, and then do some visualisations. That would give us a good idea of how much HSes are used. Sounds good. OTOH, other statistics like # of HS descriptors are not that harmless and the upcoming HS redesign will block us from getting this information anyway. How will the upcoming design block hsdirs from knowing how many descriptors they got? I agree that it'll be harder to know how many underlying hidden services they represent; but given a predictable publishing schedule and a number of descriptors you got, you should be able to derive an estimate for how many hidden services published to you. The main goal of (that part of) the hsdesc redesign was to prevent hsdirs from learning how to visit the hidden service. Unless we have a plan for the security property you describe? For now, I think we should focus on #13192 for this project. I'd like to branch out into a bunch of other stats too -- for example, how many intro points were established at my relay over the past 24 hours? How many rendezvous points? How many of those rendezvous points got used? What were the various usage stats of the intro points? Basically, anything where we're pretty sure it can't be used for harm, but we can imagine finding numbers that surprise us, we should consider looking at, to see if we're surprised -- and we should collect the numbers over time, in case later they turn into something surprising. The trickier examples, which we shouldn't deploy without more thought, would be things like what is the median, 90th percentile, etc of bytes used on circuits where I'm the rendezvous point? At the extreme, which is clearly in don't do it territory, we can imagine doing a website fingerprinting attack at the rendezvous point, to discover which hidden service it is and thus track popularity. See item #4 at the end of this mail for more next steps. == Tor controller API improvements == To better refine this project, we should think about what we want to get out of it. Here are some outcomes: a) A better control API allows us to perform better performance measurements for HSes. All in all, this seems like a project worth doing right because it will be useful in the future. It can even act as an automated regression test. I agree. I'd like us to get a really good answer in place here and then see what it tells us over time. b) This might also be a good time to start working on automated integration tests for HSes. It should be possible to spin up private Chutney networks and test that particular HSes are reachable. Or perform regression tests; for example, Roger recently suggested writing a regression test to make sure that clocks don't need to be synchronized to build HS circuits (#13494). Yep. In general, I think there are many questions where we look at the code and wonder if it's behaving correctly. With a tool like Chutney, we should be able to instrument the whole network to *verify* that the code is behaving correctly. And with a bit more effort, we should be able to make that verification easier to do the second time. Part of what I'm hoping we'll uncover with the Chutney tests is edge cases where most of the time it behaves as we expect, but every so often it goes really wrong. So we should think about what we want to capture from each relay in order to be able to track down the details of these anomalies. And then we should figure out how to induce defects, like half of the hsdirs for the hidden service go down or drop the descriptor, and see if our algorithms still behave the way we expect. Bonus points if it's pretty easy to reuse these steps on both Chutney and Shadow. This work ties into https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorS/IntegrationTesting/Proposal so hopefully it will be a great area where SponsorR devs can collaborate with SponsorS devs, and where SponsorR devs can get up-to-speed on all our hidden service code. c) Tor should better expose error messages of failed operations. For example, this could allow TBB to inform users whether they mistyped the onion address or the HS is actually down, and it would also let us do
Re: [tor-dev] Potential projects for SponsorR (Hidden Services)
Roger Dingledine wrote: h) Back to the community again. There have recently appeared a few messaging protocols that are inherently using HSes to provide link layer confidentiality and anonymity [1]. Examples include Pond, Ricochet and TorChat. There are also a fair few IRC and XMPP servers floating around onionland (and soon to be many more via Stormy). I'm also really curious what the impact that Pond would have on the HS landscape if it become popular. Right now, there are probably only a handful of people who run their own independent Pond HS, but that could change. There's also onionshare, which creates hidden services as-needed -- which are typically discarded after sharing a single file one time. It might be worth researching these use cases to see how well Tor supports them and how they can be supported better (or whether they are a bad idea entirely). Yes. My guess is that it's lightweight to establish a circuit with each of your friends, and then when it goes away you try to reestablish it and if you fail then your friend is probably gone. And my guess is that it's heavyweight to try rendezvousing with each of your friends every 5 minutes to see if they're still there. We should put up some guidelines for eco-friendly use of hidden services in this situation. Scott Ainslie and I came to the conclusion that two one-way video conversations over hidden services is a pretty decent replacement for Skype etc[2]. At a really crude level, this can be achieved using gstreamer (maybe with FreeNote[1]) and then sharing the hidden service addresses with each other. Some assembly required, obviously. It's my undying wish that someone create a proof-of-concept app for this using gtk or kivy or something. == Opt-in HS indexing service == The question of whether this has to be built-in is a fine one to explore. I bet we'd get more people doing it if it were just a torrc option that you can uncomment. But it also seems inherently less safe, since it might mean more publishings by your Tor than the human would do. It would definitely get more opt-ins than if there were additional steps. There's a measure of informed consent there, because if you are opting in intentionally, then you are saying that you want your hidden service publicized. Any given person running a library or art project might think Oh nobody cares about my hidden service and not bother going through additional steps, but would be perfectly happy to have more people look at their work. The question, to me, is how to frame the torrc option so as to make sure people know it's optional. - #8902 Rumors that hidden services have trouble scaling to 100 concurrent connections I've been curious about this ticket for a while, and happy to structurerun a follow-up test on a controlled server. Since the original problem was with an IRC server, it makes sense to set one up for the purposes of a test, and then set up a secondary machine for 'user' connections and an extra monitoring point. I suspect that there are other factors that might have influenced that report. Could it be an issue with one of the intermediary points? There certainly *seem* to be tons of people using the OFTC hidden service, but that could be perception (ie, still 100 concurrent users). What useful projects/tickets did I forget here? 1) We should identify and describe the great use cases of hidden services, especially the ones that are not of the form I want to run a website that the man wants to shut down. One thing that is interesting: in practice, onionshare (RetroShare et al) winds up being easier than trying to share a file with a friend using third-party services. Particularly for large-ish files or something where you want some measure of privacy (ohai dropbox), sending it to a third-party and then making it available to your friend and then deleting/hiding it again is a little annoying. (And there are of course privacy and cost tradeoffs with this as well). People like to set up private IRC Jabber chats to chat without attracting trolls and spambots, and get an extra layer of encryption from Tor. What sorts of hidden service examples are we missing from the world that we'd really like to see, and that would help everybody understand the value and flexibility of hidden services? Along these lines would be fleshing out the hidden service challenge idea I've been kicking around, where as a follow-up to the EFF relay challenge, we challenge everybody to set up a novel hidden service. We would somehow need to make it so people didn't just stick their current website behind a hidden service -- or maybe that would be an excellent outcome? This could be fun. =) We could put out a blog post when Stormy reaches 1.0 about this too. there is a lot of, shall we call it, dark matter in hidden service space. What are some safe ways we can improve our
