[tor-dev] UX improvement proposal: Onion auto-redirects using Onion-Location HTTP header

[dinovirus at gmail.com]

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?

[1]
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1
[2]
https://medium.com/@alecmuffett/onion-synopsis-for-susan-hennesey-b28a92f0e974
[3] https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-2.1

On Sat, Sep 22, 2018 at 2:55 PM nusenu <nusenu-lists at riseup.net> 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>


-- 
mahrud <algorithms.jux-foundation.org/~mahrud/blog>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180926/65abb1f2/attachment.html>