Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Onion-Location HTTP header
Hi, On 23/10/18 18:15, Alec Muffett wrote: > But any website that takes an interest (e.g. tracks Cloudflare's > "xx-tor" country geolocation, or whatever it is called) - regarding the > reputation of the source IP address will KNOW that the user is coming > from Tor. > > We live in a weird world where the Tor community still believes that > systems administrators don't have trivial access to IP reputation databases. IP reputation databases do not reflect the current state of the Tor network exactly. They may be pretty close, even 99%, but they're not exact. You will get false positives, and a lot of false negatives too. Improving exit detection is on the list of tasks for Tor Metrics but it is not our top priority. > 3) if sites wish to follow Privacy International's example and redirect from a DNS TLD to ".onion" then that is something they should implement at layer 7, by dint of identifying whether the user has arrived over Tor. Given that false positives are possible, doing this conditionally is going to give some people a terrible user experience by redirecting them to an onion they cannot possibly reach in their browser. This is why I like the Onion-Location header. You don't have to have this conditional. You don't need to have any infrastructure to provide lookups from databases (which ideally would need to be refreshed constantly). You just always serve the header. This also gives you the opportunity to advertise that a service is available via Onion service to all users, some of which might have a browser add-on that lets them know about these things. Thanks, Iain. signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Onion-Location HTTP header
(just pasting the references from twitter threads, I'm not sure if there is a nice way to view the entire thread and all subthreads without missing any) Alec Muffett: > perhaps it's time that > we stopped trying to hide the fact that we are using Tor? https://twitter.com/sjmurdoch/status/1054797781343330307 https://twitter.com/arthuredelstein/status/1054835301028253696 > the fact that/when traffic > arrives from Tor is virtually unhideable. related https://lists.torproject.org/pipermail/metrics-team/2018-September/000914.html -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Onion-Location HTTP header
On Tue, Oct 23, 2018, 12:15 PM Alec Muffett wrote: > > The world has changed since Tor was first invented; perhaps it's time that > we stopped trying to hide the fact that we are using Tor? Certainly we > should attempt to retain the uniformity across all tor users - everybody > using Firefox on Windows and so forth - but the fact that/when traffic > arrives from Tor is virtually unhideable. > > Consciously sacrificing that myth would make uplift to onion networking so > much simpler. > I agree. In particular because I want to avoid false positives and false negatives in the reputation system. But by what mechanism do we expose this information? I can't think of one that doesn't have significant drawbacks. And what do we say/what do we mean? (I am onion capable?) > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Onion-Location HTTP header
1) the best and proper way to redirect from site A to site B is to use "Location:" and/or an appropriate 3xx code. It already works. 2) having an "h2o" ALPN for Alt-Svc would literally make things worse, retard adoption, confuse implementations, break almost all of my future plans for onionification of corporations, and generally make life a pain. It's hard enough getting people to implement functionality in early stages when there are merely bugs, let alone forcing them to jump through hoops to implement special, redundant magical headers that literally do not serve any additional functional value above the extant, open, standard, supported ones. 3) if sites wish to follow Privacy International's example and redirect from a DNS TLD to ".onion" then that is something they should implement at layer 7, by dint of identifying whether the user has arrived over Tor. (See below) 4) if sites want to advertise the existence of an alternate onion site by leveraging some form of tor-specific browser pop down, then sure, knock yourself out with a magical header but nobody in their right mind is going to deploy it in the Enterprise. It would be a massive waste of human / tech bandwidth and hassle. It would be far easier and cheaper instead to react having first identified whether the user has arrived over Tor. 5) onion networking already works for h2 ALPN under alt-svc; please do not mess this up by fragmenting it / imagining that it needs to take-on a special syntax to reflect it's "onion nature". I get what you are saying, it's very clever, but please: no. There is a vast amount of potential for organisations to "turbocharge" their Tor user-experience by simply offering an "h2" onion address amongst Alt-Svc when a user connects to them via an exit node. Everything is already sufficiently disambiguated by the ".onion" suffix. We're good. 6) a moment's consideration will illuminate that the underlying problem here is the increasing fallacy which Tor continues to suffer, that sites should/do not know that a user is arriving over Tor. That half of the websites in the world should be kept in ignorance that a user is arriving via Tor, while the other half - the popular sites by volume - actively want to know that the user is arriving over Tor in order to optimise the user's experience. In short we have conflicting desires: some tor users want to pretend that they are just some schmoe (sp?) running Firefox on Windows on a "random machine somewhere on the internet" - e.g. a fat exit node run by Mozilla… But any website that takes an interest (e.g. tracks Cloudflare's "xx-tor" country geolocation, or whatever it is called) - regarding the reputation of the source IP address will KNOW that the user is coming from Tor. We live in a weird world where the Tor community still believes that systems administrators don't have trivial access to IP reputation databases. The world has changed since Tor was first invented; perhaps it's time that we stopped trying to hide the fact that we are using Tor? Certainly we should attempt to retain the uniformity across all tor users - everybody using Firefox on Windows and so forth - but the fact that/when traffic arrives from Tor is virtually unhideable. Consciously sacrificing that myth would make uplift to onion networking so much simpler. - a ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Onion-Location HTTP header
On Wed, 26 Sep 2018 at 06:51, 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Onion-Location HTTP header
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 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 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/cloudfl
Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Onion-Location HTTP header
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 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
Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Onion-Location HTTP header
(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 signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
