On Wed, 26 Sep 2018 at 06:51, dinovirus@gmail.com 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