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

[dinovirus at gmail.com]

Sorry, the second reference should have been this:
https://medium.com/@alecmuffett/different-ways-to-add-tor-onion-addresses-to-your-website-39106e2506f9


On Wed, Sep 26, 2018 at 1:50 AM <dinovirus at gmail.com> wrote:

> 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>
>


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