Add HTTP Onion-Location header to inform browsers about the onion service

[evilaliv3]

The Tor browser supports a non standard HTTP header that enables a server to advise browsers about the existence an an onion service corresponding to a regular HTTPS resource.

This could be used in order to inform browsers about the existence of the onion service and implement automatic redirection with the best support offered by the Tor Browser.

https://trac.torproject.org/projects/tor/ticket/27502
https://trac.torproject.org/projects/tor/ticket/32256

[evilaliv3]

@alecmuffett @jonaharagon: Within @globaleaks we are considering using alt-svc and onion-location headers (#2846, #2847).

I just read your previous articles on the topic and i would like to know your advice: https://write.privacytools.io/jonah/securing-services-with-tor-and-alt-svc
https://medium.com/@alecmuffett/different-ways-to-add-tor-onion-addresses-to-your-website-39106e2506f9

Currently GlobaLeaks can run both a Tor Onion Service V3 and a HTTPS on a regular website and we are implementing a serverside detection about users reaching the site via an exit-node to redirect users to the onion service.

I would like to get your opinion on:

• I consider alt-svc better in our context because of the fact that it would offer the possibility to preserve HTTPS in addition to the protection offered by Tor. Do you agree?
• I'm in doubt if enabling as well Onion-Location header as i'm in doubt of the possible issues that could happen given the different prioritization that the tor browser may implement over the years.
• I consider worth it to maintain also the serverside detection in order eventually to actively redirect users if the servers identify the ip of the user as coming from Tor.

Do you have any feedback? What are your advises to implement it all properly and which are the side effects that you identify? Thank you!

[jonaharagon]

1. That’s the reason I set it up, until Let’s Encrypt starts offering certs. alt-svc also requires 0 configuration on the webserver side besides adding the header, no need to mess with virtual hosts. This method does not redirect people or show people the onion address in the address bar, so it seems kind of pointless for your setup if you would rather redirect people entirely to the onion domain.
2. It’s very new so I haven’t given this too much of a look yet, but it seems like it will be the best solution for replacing redirects. I feel like you wouldn’t need both this and alt-svc however.
3. If you have that setup and it works well... you might as well keep it. But I would be concerned about redirecting clearnet users on accident. For example someone running an exit node from an apartment with a single IP, if you’re doing IP-based detection everyone in the building might show up as Tor users when that is not the case.

[evilaliv3]

Thank you @jonaharagon !
You write That’s the reason I set it up, until Let’s Encrypt starts offering certs.. Does this mean that finally letsencrypt is offering certificates for .onion domains? Can you point me to the documentation where i could read about this?

[evilaliv3]

For the moment we have opted for keeping the serverside redirect based on the ip of the client and we have implemented as the Onion-Location header.

We have considered instead to not implement the Alt-Svc header due to undefined policies of choice expecially for onion services. In fact in our use case the onion service would have to be preferred and the user forcefully redirected to it, while in the Tor browser it seems that the browser is randomly picking one of the alternatives with the effect that sometimes the browser continues to use the HTTPS alternative instead of the ionion services.

[jonaharagon]

Does this mean that finally letsencrypt is offering certificates for .onion domains?

No, but the CAB Forum finally decided to allow DV .onion certificates, so they technically are allowed to for the first time. Who knows when they actually will offer them, but I’m sure they will eventually now that they have the option.

[asn-d6]

(Hello GL team, let me know if you need any help or internal info about onions here).

[evilaliv3]

Thank you @asn-d6 ! welcome here!

Actually your imput would be definitely helpful you advice on which is the preference that TBB is going to give to the different headers (Onion-Location/Alt-svc) and which are your recommendations of use in the context of globaleaks.

[asn-d6]

Hello Giovanni,
by preference you mean which of them is gonna be prioritized if they are both present? I'm actually not sure about this, but if you are interested in doing so I can ask the right people (@acatarineu).

WRT what you should use for globaleaks, I think it's up to whether you prefer. If you want the onion address destination to be visible and the user to be informed of this redirection, then you should use onion-location, otherwise you should use alt-svc.

Also, Let's Encrypt certificates for onions will be kinda late because of limited bandwidth from the LE team wrt this problem.

(Also, feel free to CC me in any other tickets that need atttention from Tor people)

[evilaliv3]

Thank you. Yes we are interested in knowing the priority and mix behaviours in relation to HTTPS / HTTP.

I found that alt-svc is badly defined and works well only for aspects of load balancing like analyzed by @alecmuffett but actually in relation to security priority is not well defined (by order of alternatives? by security of the alternatives, etc)

For this reason at the current moment we implemented only onion-location preferring explicit redirect as you say and we use it exaclty like a Location header by redirecting to the home page of the app.

p.s. thank you for your support it is really really appreciated and i will for sure take the chance to tag you on other relevant tickets.

[acatarineu]

which is the preference that TBB is going to give to the different headers

So in principle Onion-Location and Alt-Svc are independent of each other. If both are present, then it will depend on whether user has enabled "automatic onion-location redirects" or not. If not, the .onion available badge will be displayed and Alt-Svc will continue to work as if Onion-Location did not exist. If user has enabled "automatic onion-location redirects", then they will be redirected to .onion and most likely there will not be time for Alt-Svc to be used in practice (but not sure if that's relevant anymore, because of the quick redirect). Also note, Onion-Location only works when served over https.

Did that answer your question? If you meant the priority of different alt-svc headers, we currently inherit that from the Firefox implementation, and do not change it. I don't think they treat a .onion alt-svc different than others, though. I would have to take a look at the implementation, but I also have the feeling that as you said, you get no guarantees that the alt-svc will be used, either in the actual implementation or in the spec.