On Thu, Aug 10, 2017 at 2:53 AM, Roger Dingledine <a...@mit.edu> 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@lists.torproject.org > 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@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
