Re: [tor-talk] Motivations for certificate issues for onion services

[Ben Tasker <ben@xxxxxxxxxxxxxxx>]

On Thu, Aug 10, 2017 at 2:53 AM, Roger Dingledine <arma@xxxxxxx> wrote:

>
> * Admins should be able to run their Tor onion service at a different
> location than their webserver. "End to end" in onion encryption means
> "Tor client to Tor client", but "end to end" in web encryption means
> "Browser to Webserver". You should be able to have both. Never forget
> the phrase "SSL added and removed here"!
>
> * People who write complicated web services should be able to have very
> simple "if it's not https, don't allow it" rules, and asking them to
> create an onion-sized hole in their security rules is foolish and harmful.
>
>
For me, this is a primary motivation in wanting a DV cert.

A number of my sites (for example https://www.bentasker.co.uk) are
dual-homed between the WWW and Tor (it's also at
http://6zdgh5a5e6zpchdz.onion/ ). I terminate the client's plain HTTP and
then use HTTPS for the backhaul to the webserver(s), which in principle
feels wrong....

Of greater concern to me, though, is it means there are various things that
I either can't do or are fairly risky to do. Even down to simple things
like adding HSTS headers to the site - if I miss stripping just one on the
torified end then bad things are going to happen. It also means I can't
mark cookies as secure only (not such an issue on the site above, but can
be an issue elsewhere).

For my own site, I don't need the anonymity (it's plastered with my name,
so, yeah), I *could* get an EV, the barrier there is the price - it's just
not (IMO) worth it, especially when you start talking about multiple
different sites. But, the "cost" I'm paying at the moment is increased
complexity in my config and back-end, increasing the risk of me having made
a mistake somewhere in there. And that's for a fairly simple (functionality
wise) site with an off-the-shelf CMS as the backend. It can easily get more
complex (further raising the risk).

As Alec alluded too, there's also a trade-off. Either your tor endpoint
talks to the backend via HTTP, or (as I do) you use HTTPS for that
backhaul, but then have to monkey about in the back-end to have it know
that although the connection appears to be HTTPS there's a whole host of
things that you cannot use.


> - access to secure-locked protocols like WebRTC

This too, and as I understand it (unless things have changed), Firefox's
intention going forward is to increase the number of features that are
HTTPS only. Which isn't necessarily a bad thing, but it does mean that
useful features may increasingly become unavailable to hidden services. For
a multi-homed site, that's something of an issue because you then have to
decide whether to not use those features at all, or to further complicate
things by only using them on the non-Tor connections (and put up with user
complaints that X should be available via Tor too).




> It seems to me that an onion address, where you actually have a private
> key that proves that you "are" the onion address, is a slam dunk for
> a Domain Validated (DV) situation. It's exactly what everybody should
> have wanted for DV certs from the beginning.
>

When you look at the acceptable steps for proving control of a domain, on
the clearnet, yeah. Simply putting a specific file in a specific place is
sufficient for validation nowadays, despite the relative ease of messing
with DNS and BGP for long enough to pass the 'test'. In comparison, having
to have the correct key seems like a much higher burden of proof.




>
> (In fact, technically speaking, there's no particular need to have a
> trusted central third party do the validation, since onion domains are
> *self* validating. If we made a tool to generate a cert chain using the
> onion private key to certify the traditional TLS key, and we taught Tor
> Browser how to verify those cert chains... we wouldn't need the sham
> that is a DV certificate authority. But that is a different discussion. :)
>
> --Roger
>
> --
> tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>



-- 
Ben Tasker
https://www.bentasker.co.uk
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk