[tor-dev] UX improvement proposal: Onion auto-redirects using Onion-Location HTTP header
dinovirus at gmail.com
dinovirus at gmail.com
Wed Sep 26 06:54:02 UTC 2018
Sorry, the second reference should have been this:
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  for HTTP/2 over onions, similar to "h2"
> for HTTP/2 over TLS. Alec's post  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:
> 3. browser connects to bar.onion:443 port (this fails if tor socks isn't
> set up)
> 4. the host must pass authentication , 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
> 1. browser requests"https://foo.com", receives 'alt-svc: *h2o*
> 3. normal browsers would ignore this, but Tor Browser connects to
> 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).
>  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:
>> 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 )
>> I'm wondering how you think about it compared to what benefits Alt-Svc
>> 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
>> 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
>> 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 
>> 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
>>  https://blog.cloudflare.com/cloudflare-onion-service/
>>  https://trac.torproject.org/projects/tor/ticket/27590
>>  https://trac.torproject.org/projects/tor/ticket/27590#comment:2
>> tor-dev mailing list
>> tor-dev at lists.torproject.org
> mahrud <algorithms.jux-foundation.org/~mahrud/blog>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tor-dev