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?