[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #21952 [Webpages]: Increasing the use of onion services through automatic redirects and aliasing
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs