Before moving on from Alt-Svc, one idea that I thought would be great is adding a new ALPN protocol ID [1] for HTTP/2 over onions, similar to "h2" for HTTP/2 over TLS. Alec's post [2] reminded me of this and I'm sure someone has considered this before, but if not now's a good time.First, let's all agree that all non-onion websites have to use https, otherwise none of this matters.Here's the gist of it:Let's consider the case of "h2" ALPN for HTTP/2 over TLS:
1. browser requests "https://foo.com", receives 'alt-svc: h2="bar.onion:443"'
3. browser connects to bar.onion:443 port (this fails if tor socks isn't set up)
4. the host must pass authentication [3], which for "h2" means giving a valid certificate for "foo.com"
5. if authentication succeeds, browser displays "foo.com" but connects using "bar.onion" and shows "bar.onion" in the circuit display.
This scenario is great for common websites because the cookie space is always "foo.com", so the onion address can be transitory. In particular, even if the website doesn't own the private key to the onion service, authentication depends on TLS certificate for "foo.com", which the website owns.
Now, the idea is to add "h2o" ALPN for HTTP/2 over TCP via an onion service:
1. browser requests"https://foo.com", receives 'alt-svc: h2o="bar.onion:80'
3. normal browsers would ignore this, but Tor Browser connects to bar.onion:80
4. the host must still pass an authentication step for "h2o" that Tor Browser can invent
5. if authentication succeeds, Tor Browser redirects to "bar.onion", optionally noting "foo.com" in the circuit display.
For the "h2o" authentication step, TBB could:1. Use a HTTPS Everywhere type extension
2. Require UI announcement + confirmation
This scenario is great for websites that want to separate cookie spaces "foo.com" and "bar.onion" (you probably don't want a whistle-blower logged in to your onion service suddenly send cookies over an exit node) or don't want https+onion. Also, this is pretty much compatible with the Alt-Svc specifications, so it doesn't require adding a new header.
Note that in this case the onion address is no longer transitory, so it's important that the website should own the private key. This is critical because unlike IP addresses, domain names, or even HTTPS certificates, the private key to onion addresses doesn't expire (until offline/delegate keys are implemented).Thoughts?On Sat, Sep 22, 2018 at 2:55 PM nusenu <nusenu-lists@xxxxxxxxxx> wrote:(changed the subject to make clear that this is NOT about Alt-Svc anymore)
I assume this is limited to onions for sites that do not aim for server side location anonymity.
> FYI: the proposal is now the first Tor Browser proposal:
> https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-location-header.txt
in the light of the fact that this proposal has been started before
Tor Browser 8 with Alt-Svc support for .onions was a thing (and CF jumping on it [0])
I'm wondering how you think about it compared to what benefits Alt-Svc provides
over what Onion-Location provides?
Are you unsatisfied with what RFC 7838 - HTTP Alternative Services
provides or is "onion address is displayed in URL bar" one of your goals/requirements of this proposal?
Although Alt-Svc does not work reliably _yet_ and the UI part is missing [3]
I find it addresses some rather important issues that 'Onion-Location' does not:
- users get the transport security benefits of .onions without Tor Browser displaying
hard/impossible to remember/recognize randomly looking strings.
Long randomly looking strings in the domain part of the URL that would probably
confuse many users and make it harder to answer the question "Am I still on the page I want to be?"
(I consider it a major UX improvement that you can display the non
.onion domain name while the traffic actually goes to the .onion)
- users will use onions transparently
without asking them questions they probably don't understand or don't want
to be bothered with everytime they visit a website [1]
I believe asking fewer questions, safe defaults and configuration options for advanced users
are some reasonable goals.
- it solves the ".onions can't get DV certs (yet)" issue
[0] https://blog.cloudflare.com/cloudflare-onion-service/
[1] https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png
[2] https://trac.torproject.org/projects/tor/ticket/27590
[3] https://trac.torproject.org/projects/tor/ticket/27590#comment:2
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
--
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev