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

[Tom Ritter <tom@xxxxxxxxx>]

On Wed, 26 Sep 2018 at 06:51, <dinovirus@xxxxxxxxx> wrote:
> ...

I want to compare your proposal with the simple situation of "If the
server gets a connection from a Tor exit node, return Location:
blah.onion."  (This would also separate the cookie space)

If I understand your proposal correctly, the differences are:

1) Because the client offers h2o in ALPN, the server knows (at initial
TLS connection time) the client supports .onion transport.  (We also
leak this out onto the network in plaintext; but since it comes from
an exit node it's not too concerning?)

2) The server offers h2o as an Alt-Svc protocol, so any client not
supporting onions will ignore it gracefully. There is no concern that
the server could send a Location: blah.onion header to a client not
supporting onions; or omit it from a client supporting onions.

3) Tor Browser can implement additional authentication checks for the
transfer from blah.com -> blah.onion

I'm not clear if the connection to blah.onion involves HTTPS or HTTP;
but I suppose both are possible.

Because the response from the server comes from


So I like to try and keep the intent of headers as close as possible.
Alt-Svc is used to redirect routing without visible changes and
without user prompting. That's why I'm opposed to Alt-Svc:
h2/blah.onion prompting the user, and opposed to the Location: header
prompting the user but am perfectly supportive of a new Onion-Location
header prompting the user.  Creating h2o for Alt-Svc and implementing
it in a way that redirects the user violates the intent of Alt-Svc.

Additionally, ALPN is designed for negotiating an Application Layer
Protocol - what you speak inside TLS. h1 and h2 are different
protocols, so one uses ALPN to negotiate h2 in the TLS connection, and
the first byte of the application layer protocol is HTTP2. In your
proposal; you negotiate a different protocol, but still speak h2.
Actually it's not clear if one should speak HTTP or HTTP2 to the
server! (We could require http2 but that seems like a bad idea.)

The response from the server still comes in the Alt-Svc header; so
there's no connection latency to be avoided.

I like the goal of giving server operators the ability to separate
cookie spaces.  But I think that's accomplished by both a prompted
Onion-Location redirect or a non-prompted Location redirect.

I like the goal of having no ambiguity or confusion about what a
browser that does/doesn't support onion should do with an onion
address or possibility of not serving an onion address to someone who
should get.  Onion-Location solves this for prompted redirects.
Location does not solve this for promptless redirects. (We could add a
'force' parameter to Onion-Location to bypass the prompt. I think this
is a good idea and would suggest we add it to the proposal.)

I think the idea of allowing Tor Browser to require and perform
additional security checks for the transfer from http(s) -> onion. But
I don't see why they couldn't be added/performed as part of the
Onion-Location transfer.

I like the idea of using ALPN for something; but I don't think this is
the right problem to use it for.  Because it's used for Application
Layer Protocol selection, it is the perfect choice to use to negotiate
a Tor connection or a Pluggable Transport connection to a server
supporting both a website and Tor.  (Imagine if that were deployed on
something like Github!) But it's _in plaintext_. So any connection
offering such an ALPN could be blocked. I'm still disappointed the WG
chose ALPN instead of NPN. With this plaintext limitation, I don't
know what we could use ALPN for.  Maybe we could use it inside normal
Tor connections to negotiate a new Tor protocol that didn't nicely fit
into the existing tor protocol version negotiation.

-tom
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev