[tor-dev] Of CA-signed certs and .onion URIs

[Lee]

> 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 <tom at ritter.vg> 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
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>