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

Fri Dec 8 16:27:41 UTC 2017

On 8 December 2017 at 09:06, George Kadianakis <desnacked at riseup.net> wrote:
> As discussed in this mailing list and in IRC, I'm posting a subsequent
> version of this proposal. Basic improvements:
> - Uses a new custom HTTP header, instead of Alt-Svc or Location.
> - Does not do auto-redirect; it instead suggests the onion based on
>   antonella's mockup: https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png
>
>
>
> ========================================================================
> UX improvement proposal: Onion redirects using Onion-Location HTTP header
> ========================================================================
>
> 1. Motivation:
>
>    Lots of high-profile websites have onion addresses these days (e.g. Tor ,
>    NYT, blockchain, ProPublica).  All those websites seem confused on what's
>    the right way to inform their users about their onion addresses. Here are
>    some confusion examples:
>      a) torproject.org does not even advertise their onion address to Tor users (!!!)
>      b) blockchain.info throws an ugly ASCII page to Tor users mentioning their onion
>         address and completely wrecking the UX (loses URL params, etc.)
>      c) ProPublica has a "Browse via Tor" section which redirects to the onion site.
>
>    Ideally there would be a consistent way for websites to inform their users
>    about their onion counterpart. This would provide the following positives:
>      + Tor users would use onions more often. That's important for user
>        education and user perception, and also to partially dispell the darkweb myth.
>      + Website operators wouldn't have to come up with ad-hoc ways to advertise
>        their onion services, which sometimes results in complete breakage of
>        the user experience (particularly with blockchain)
>
>    This proposal specifies a simple way forward here that's far from perfect,
>    but can still provide benefits and also improve user-education around onions
>    so that in the future we could employ more advanced techniques.
>
>    Also see Tor ticket #21952 for more discussion on this:
>       https://trac.torproject.org/projects/tor/ticket/21952
>
> 2. Proposal
>
>    We introduce a new HTTP header called "Onion-Location" with the exact same
>    restrictions and semantics as the Location HTTP header.

For reference, this is https://tools.ietf.org/html/rfc7231#section-7.1.2

> Websites can use the
>    Onion-Location HTTP header to specify their onion counterpart, in the same
>    way that they would use the Location header.
>
>    The Tor Browser intercepts the Onion-Location header (if any) and informs
>    the user of the existense of the onion site, giving them the option to visit
>    it. Tor Browser only does so if the header is served over HTTPS.
>
>    Browsers that don't support Tor SHOULD ignore the Onion-Location header.
>
> 3. Improvements
>
> 4. Drawbacks
>
> 4.1. No security/performance benefits
>
>    While we could come up with onion redirection proposals that provide
>    security and performance benefits, this proposal does not actually provide
>    any of those.
>
>    As a matter of fact, the security remains the same as connecting to normal
>    websites (since we trust its HTTP headers), and the performance gets worse
>    since we first need to connect to the website, get its headers, and then
>    also connect to the onion.

I would specifically call out that the user has provided any
identifying information (cookies) that may be present, as well as
opened themselves to any possible browser-based attack vector served
by the target domain.

>    Still _all_ the website approaches mentioned in the "Motivation" section
>    suffer from the above drawbacks, and sysadmins still come up with ad-hoc
>    ways to inform users abou their onions. So this simple proposal will still
>    help those websites and also pave the way forward for future auto-redirect
>    techniques.
>
> 4.2. Defining new HTTP headers is not the best idea
>
>    This proposal defines a new non-standard HTTP header. This is not great
>    because it makes Tor into a "special" thing that needs to be supported with
>    special headers. However, the fact that it's a new HTTP header that only
>    works for Tor is a positive thing since it means that non-Tor browsers will
>    just ignore it.
>
>    Furthermore, another drawback is that this HTTP header will increase the
>    bandwidth needlessly if it's also served to non-Tor clients. Hence websites
>    with lots of client traffic are encouraged to use tools that detect Tor
>    users and only serve the header to them (e.g. tordnsel).

I would talk about how users could experience false positives and
false negatives if this mechanism is used.

I think it is also worth addressing that this does not stop sysadmins
from (trying to) detect tor users, and send the onion address in the
Location header, thus triggering a non-prompting redirect. But that
they should consider the potential user confusion of being redirected
to an odd looking domain in such a scenario. And state that this
mechanism is designed to provide a browser-supported option to
consistently offer an onion service in a hopefully less-confusing way.

-tom

> 5. The future
>
>    As previously discussed, this is just a simple proposal to introduce the
>    redirection concept to people, and also to help some sysadmins who are
>    currently coming up with weird ways to inform people about their
>    onions. It's not the best way to do this, but it's definitely one of the
>    simplest ways.
>
>    In the future we could implement with more advanced auto-redirect proposals like:
>
>    a) Have a "domains to onions" map into HTTPS-everywhere and have it do the
>       autoredirects for us (performance benefits, and security benefits under many
>       threat models).
>
>    b) Bake onion addresses into SSL certificates and Let's Encrypt as suggested
>       by comment:42 in #21952.
>
>    But both of the designs above require non-trivial engineering/policy work
>    and would still confuse people. So I think starting with a simple approach
>    that will educate users and then moving to more advanced designs is a more
>    normative way to go.
>
> ======================================================================
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev