> c) Get .onion IANA reserved It doesn't look like that's going to happen.
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/ is expired & I haven't been able to find anything indicating it's still being considered. See the "existing requests/RFC 6761 process:" section here https://tools.ietf.org/wg/dnsop/minutes?item=minutes-89-dnsop.html Regards, Lee On 11/14/14, Tom Ritter <[email protected]> wrote: > There's been a spirited debate on irc, so I thought I would try and > capture my thoughts in long form. I think it's important to look at > the long-term goals rather than how to get there, so that's where I'm > going to start, and then at each item maybe talk a little bit about > how to get there. So I think the Tor Project and Tor Browser should: > > a) Eliminate self-signed certificate errors when browsing https:// on > an onion site > b) Consider how Mixed Content should interact with .onion browsing > c) Get .onion IANA reserved > d) Address the problems that Facebook is/was concerned about when > deploying a .onion > e) Consider how EV treatment could be used to improve poor .onion > readability > > (If you're not familiar with DV [Domain Validated] and EV [Extended > Validation] certificates and their UI differences, you should take a > peek. For example [0]. There are other subtleties and requirements on > EV certs like OCSP checking that removes the indicator, and the > forthcoming CT effort in Chrome, but that's mostly orthogonal.) > > -------------------- > a) Self Signed Errors on .onion > > A .onion specifies the key needed. As far as little-t tor is > concerned, it got you to the correct endpoint safely, so whatever SSL > certificate is presented could be considered valid. > > However, if the Hidden Service is on box A and the webserver on box B > - you'd need to do some out-of-application tricks (like stunnel) to > prevent a MITM from attacking that connection. So as Roger suggested, > perhaps requiring the SSL certificate to be signed by the .onion key > would be a reasonable choice. But if you make that requirement, it > also implies that HTTP .onions are less secure than HTTPS .onions. > Which may or not be the case - you don't know. > > I'm not religious about anything other than getting rid of the error: > I don't like that users are trained to click through security errors. > > This is a weakly held opinion right now - but I think it's fair to > give DV treatment to http://.onion because it is, from little-t tor's > point of view, secure. Following that conclusion, it is therefore > fair to accept self-signed certificates and _not_ require a > certificate for a https://.onion be signed by the .onion key. > (Because otherwise, we're saying that SSL on .onion requires more > hoops to achieve security than HTTP on .onion, which isn't the case.) > > -------------------- > b) Mixed Content on .onion > > This is a can of worms I'm not going to open in this mail. But it's > there, and I think it's worth thinking about whether a .onion > requesting resources from http://.com or https://.com is acceptable. > > -------------------- > c) Get .onion IANA reserved > > I think this is fairly apparent in itself, and is in the works [1]. > Not sure its status but I would be happy to lend time in whatever IETF > group/work is needed if it will help. > > -------------------- > d) Address the problems that Facebook is/was concerned about when > deploying a .onion > > There are reasons, technical and political, why Facebook went and got > a HTTPS cert for their .onion. I've copied Alec so hopefully he'll > agree, refute, or add. But from my perspective, if I were Facebook or > another large company like that: > > i) I don't want to train my users to click through HTTPS warnings. > (Conversely, I like training my users to type https://mysite.com) > ii) I don't want to have to do the development and QA work to cut my > site over to be sometimes-HTTP if it's normally always HTTPS > iii) It would be convenient if I didn't have to do stunnel tricks to > encrypt the connection between my Hidden Service server and (e.g.) > load balancer, which is on another box > iv) I'd really like to get a green box showing my org name, and it's > even better that it'd be very difficult a phisher to get that > > (iii) can contradict with (A) above of course. Because I came to the > conclusion of allowing invalid certificates, a MITM could attack > Facebook between the HS server and load balancer. I'm not sure there > is an elegant solution there. One would probably have to tunnel the > connection over a mutually authenticated stunnel connection to prevent > a MITM. But frankly, if we assume users are used to clicking through > self-signed certs and we want to start the process of training them > _not_ to, Facebook would have to do this now _anyway_. So... =/ I > guess documenting the crap out of this concern and providing examples > may be the best solution based off my mindset right now. > > It's awesome that Facebook set up a Hidden Service. I'd love to get a > lot more large orgs doing that. We should reach out and figure out > what the blockers are, what's painful about it, and what we can do to > help. I would love doing that, it would be awesome. (And I'm not > afraid to NDA myself up if necessary, seeing as I'm under NDA with > half of the Bay Area anyway.) > > -------------------- > e) Consider how EV treatment could be used to improve poor .onion > readability > > This is the trickiest one, and it overlaps the most with the question > of "Should we encourage CAs to issue certificates?" > > EV treatment in Tor Browser is a tool in the toolbox. I think it would > be wasteful of written code and users who are accustomed to seeing it > to not make use of it. I also think it dovetails nicely with how > unreadable HS addresses are and how much more unreadable they're going > to get soon when they get longer. > > I don't want a system that _requires_ participating in the DNS or CA > model. Free or Paid, you still have to provide identifying information > - and for an anonymity project I think we can all agree that's > unacceptable. But as we hopefully expand hidden services to more and > more corporate services - these organizations are legitimately > concerned about (e.g.) phishing, and it's unreasonable to expect users > to meticulously validate a .onion address. (Let alone how you find > what the address should be validated against.) > > But a problem is that if we allow a .onion to certify anything it > wants, it can certify any fraudulent information it wants. > Bootstrapping off the other axis of Zooko's Triangle (Secure and Human > Meaningful, but Centralized) is a way to combat that fraudulent > information. (Not the only way, but a way.) > > Syrup-tan had an idea on irc: Have a DV certificate sign a certificate > that is valid for the .onion URL, and display the URL of the DV > certificate. This doesn't eliminate phishing - I can register > facebok.com and then get that displayed. But doing bootstapping off > DNS and DV certificates is a fairly low bar in terms of the cost to a > .onion operator. (There are other concerns here, I'm not completely > comfortable with repurposing the EV indicator in this way. Asa on irc > had the good point that if we did this, maybe we'd want to change the > EV green to another color just to be a little bit different. Not that > I really expect users to notice that though...) > > Allowing an organization to purchase an EV certificate from a CA, and > display the organization's name in the address bar, is another way - > albeit a very high bar in terms of cost to an onion operator. > > A petname system based off who-knows-what (for example the > namecoin/sovereign-keys like system of a land-grab, first-to-the-name > approach) is a third, and would meet the goal of not requiring > participating in the DNS and CA systems. but a high bar in terms of > engineering effort for Tor. > > I think Tor Browser should do several of them. I think the EV > certificates + partnering with CAs is dead simple and requires no > engineering effort on behalf of Tor Browser. So that's a win, and I > think worth doing. But there should be at least one more solution in > the short to long term (e.g. a petname approach). Unfortunately, if > the time between now and the 'long term' solution is too long, it > locks out everyone who can't get an EV cert - which is a legitimate > concern. Perhaps after there's a spec Tor likes, some large > organization concerned about preventing phishing could throw some > engineering time at the problem. > > Anyway, if it's not clear, I am volunteering to work on these things > as I'm able. > > -tom > > [0] https://ftt-uploads.s3.amazonaws.com/browser-ssl-ui-comparison.png > [1] > https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/ > _______________________________________________ > tor-dev mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
