[tor-bugs] #21952 [Webpages]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-------------------------+--------------------------
 Reporter:  linda        |          Owner:  linda
     Type:  enhancement  |         Status:  reopened
 Priority:  Medium       |      Milestone:
Component:  Webpages     |        Version:
 Severity:  Normal       |     Resolution:
 Keywords:  ux-team      |  Actual Points:
Parent ID:               |         Points:
 Reviewer:               |        Sponsor:
-------------------------+--------------------------
Changes (by tom):

 * status:  closed => reopened
 * resolution:  wontfix =>


Comment:

 So something similar I have been advocating is using the Alt-Svc header to
 advertise .onions. Alt-Svc is an implemented Internet Standard, and once
 Tor Browser flips the prefs for it (and HTTP2) using it with .onions may
 just work right out of the box.

 https://tools.ietf.org/html/rfc7838
 https://www.mnot.net/blog/2016/03/09/alt-svc

 The idea of Alt-Svc is for a website to be able to tell a client "For
 technical reasons you don't need to care about, please talk to me using
 [this other web address]. Oh, and do it over HTTP2 if you can."

 The client optionally does so. (They don't have to.) If they do so, they
 *do not* change the address bar or give any sort of visual indication to
 the user.


 I think websites (like facebook) should advertise .onion Alt-Svc's. Non-
 Tor Browsers should ignore them (although we'd have to validate that); but
 for users of Tor Browser, they will stop connecting to facebook.com and
 start connecting to facebookcorewwwi.onion. (The user won't even know the
 difference, but their connection will be silently and transparently
 upgraded.

 -----

 Something interesting about this (that, again, we would need to verify) is
 that it should allow users to deploy HTTPS for their onion domains without
 getting an EV cert. This is because the HTTPS cert advertised on the
 .onion has to match the ORIGINAL domain name (in our example
 'facebook.com') and NOT the alternate service domain (in our example
 facebookcorewwwi.onion). This is to prevent an attacker from redirecting
 people via Alt-Svc - the thought is that obtaining a CA cert for
 facebook.com is sufficient validation that it is the correct destination.
 So the onion operator never needs to get a cert with their .onion address
 included (which requires a company due to EV guidelines).

 -----

 Now there is one wrinkle in my idea. Alt-Svc is delivered once, and then
 the client remembers it and uses it the next time. (Optionally it uses it
 the first time too, but that gains us no security.)  Remembering means
 state. State means tracking.

 So we have to figure out how to do this without state. My thought on this
 would be to develop something like HTTPS Everywhere. (Call it Onion
 Everywhere.) We would preload Alt-Svc bindings from the sites that have
 deployed this. We could explicitly ask them if they want to be included
 (the first few adopters will no doubt coordinate with us). Or we could
 just scan and opt in anyone we find.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21952#comment:31>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online