Add header to redirect websites visitors using tor-browser to the .onion address

added component::internal services/tor sysadmin team owner::hiro priority::medium resolution::fixed severity::normal status::closed type::defect labels

Trac:
Description: We have received a number of tickets by Tor Browser users that we should keep people visiting the .onion version of a website in the .onion space.

I am willing to implement a header that signal the .onion address for all of our onions and I am currently considering two options.

Implement alt-svc. This is what facebook does. Specifically the browser receive a alt-sv header like:

alt-svc: h2="facebook2futmrduts5uqn3ahwg4qyqoks6h3alxf5drhsgyhzujyqad.onion:443"; ma=86400

Use onion-location:

Onion-Location: http://sbe5fi5cka5l3fqe.onion/~acat/test/onionlocation/header/

Use a onion-location meta-tag:

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="onion-location" content="http://sbe5fi5cka5l3fqe.onion/~acat/test/onionlocation/meta/"/>
  </head>
  <body>
    Onion-Location meta tag test.
  </body>
</html>

I would personally prefer to use one of the two headers options. Either the alt-sv or the onion-location one. Both have advantages. I like that with alt-sv the connection is upgraded to an onion location without the address bar changing. At the same time we should also showcase our onions! And if we launch the onion-location header support we should show it on our websites.

Something I would avoid is following the model that Privacy International use, and issue a "Location:" redirect when the client comes from an exit node. We currently do not check in our infrastructure where a user is coming from and I wouldn't like to start doing that.

to

We have received a number of tickets by Tor Browser users that we should keep people visiting the .onion version of a torproject.org website in the .onion space. Instead because we have different subdomains for different websites a user surfing the onion version of torproject.org will be taken to support.torproject.org instead of its onion address.

I am willing to implement a header that signal the .onion address for all of our onions and I am currently considering two options.

Implement alt-svc. This is what facebook does. Specifically the browser receive a alt-sv header like:

alt-svc: h2="facebook2futmrduts5uqn3ahwg4qyqoks6h3alxf5drhsgyhzujyqad.onion:443"; ma=86400

Use onion-location:

Onion-Location: http://sbe5fi5cka5l3fqe.onion/~acat/test/onionlocation/header/

Use a onion-location meta-tag:

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="onion-location" content="http://sbe5fi5cka5l3fqe.onion/~acat/test/onionlocation/meta/"/>
  </head>
  <body>
    Onion-Location meta tag test.
  </body>
</html>

I would personally prefer to use one of the two headers options. Either the alt-sv or the onion-location one. Both have advantages. I like that with alt-sv the connection is upgraded to an onion location without the address bar changing. At the same time we should also showcase our onions! And if we launch the onion-location header support we should show it on our websites.

Something I would avoid is following the model that Privacy International use, and issue a "Location:" redirect when the client comes from an exit node. We currently do not check in our infrastructure where a user is coming from and I wouldn't like to start doing that.

Technically you could have both, since they are independent. But I'm assuming we want to advertise the .onion address, let people bookmark it, etc., and that's not something you can do with Alt-Svc, so I think Onion-Location would be preferable.

Yes I was at the beginning inclined to implement both. But there was a quick chat on #tor-dev and the idea was to pick either one of the two. I'd like to know what we prefer. I think we should showcase the .onion so onion-location would be ideal. Not sure others have other opinions.

Trac:
Cc: N/A to isabela

Trac:
Cc: isabela to isabela, stephw

Trac:
Cc: isabela, stephw to isabela, stephw, steph

Trac:
Cc: isabela, stephw, steph to isabela, stephw, sysrqb

Trac:
Cc: isabela, stephw, sysrqb to isabela, stephw, sysrqb, mcs

Trac:
Description: We have received a number of tickets by Tor Browser users that we should keep people visiting the .onion version of a torproject.org website in the .onion space. Instead because we have different subdomains for different websites a user surfing the onion version of torproject.org will be taken to support.torproject.org instead of its onion address.

I am willing to implement a header that signal the .onion address for all of our onions and I am currently considering two options.

Implement alt-svc. This is what facebook does. Specifically the browser receive a alt-sv header like:

alt-svc: h2="facebook2futmrduts5uqn3ahwg4qyqoks6h3alxf5drhsgyhzujyqad.onion:443"; ma=86400

Use onion-location:

Onion-Location: http://sbe5fi5cka5l3fqe.onion/~acat/test/onionlocation/header/

Use a onion-location meta-tag:

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="onion-location" content="http://sbe5fi5cka5l3fqe.onion/~acat/test/onionlocation/meta/"/>
  </head>
  <body>
    Onion-Location meta tag test.
  </body>
</html>

I would personally prefer to use one of the two headers options. Either the alt-sv or the onion-location one. Both have advantages. I like that with alt-sv the connection is upgraded to an onion location without the address bar changing. At the same time we should also showcase our onions! And if we launch the onion-location header support we should show it on our websites.

Something I would avoid is following the model that Privacy International use, and issue a "Location:" redirect when the client comes from an exit node. We currently do not check in our infrastructure where a user is coming from and I wouldn't like to start doing that.

to

We have received a number of tickets by Tor Browser users that we should keep people visiting the .onion version of a torproject.org website in the .onion space. Instead because we have different subdomains for different websites a user surfing the onion version of torproject.org will be, for example, taken to support.torproject.org instead of its onion address.

I am willing to implement a header that signal the .onion address for all of our onions and I am currently considering the following options.

Implement alt-svc. This is what facebook does. Specifically the browser receive a alt-sv header like:

alt-svc: h2="facebook2futmrduts5uqn3ahwg4qyqoks6h3alxf5drhsgyhzujyqad.onion:443"; ma=86400

Use onion-location:

Onion-Location: http://sbe5fi5cka5l3fqe.onion/~acat/test/onionlocation/header/

Use a onion-location meta-tag:

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="onion-location" content="http://sbe5fi5cka5l3fqe.onion/~acat/test/onionlocation/meta/"/>
  </head>
  <body>
    Onion-Location meta tag test.
  </body>
</html>

I would personally prefer to use one of the two headers options. Either the alt-sv or the onion-location one. Both have advantages. I like that with alt-sv the connection is upgraded to an onion location without the address bar changing. At the same time we should also showcase our onions! And if we launch the onion-location header support we should show it on our websites.

Something I would avoid is following the model that Privacy International use, and issue a "Location:" redirect when the client comes from an exit node. We currently do not check in our infrastructure where a user is coming from and I wouldn't like to start doing that.

Thanks for opening this ticket, hiro!

At the moment there is no standard to redirect users to onions. Thanks to our work with S27, we deployed some features in the Tor Browser, which improves the experience of users reaching onions. Given that it is the first time we are prioritizing onions in Tor Browser, we decided to prompt users the first time of use and allow them to opt-in to prioritize onions globally.

I hope that at some point, we can reach a moment where we can contemplate all stakeholder's needs and develop a standard for this TLS upgrade without messing around the domain naming business.

For now, onion-location seems a to go for Tor Browser users, and (if I'm not wrong), alt-svc will work in clients like Brave. The end-user experience will be a little different, but both options will serve onions.

I'm happy to learn about your pain-points implementing this. It will serve as material for our next iteration in this space.

So should we implement both? Or only onion-location?

Hello! Here i've acutally the same question of @hiro.

In GlobaLeaks we are considering to implement one or both the headers alt-svc and onion-location and we have documented here the use case: https://github.com/globaleaks/GlobaLeaks/issues/2847

My doubt is:

do you advise to implement just one and what is your vision on long term support; i consider that you considered adding the onion-location before the definition of the standard alt-svc; will you continue to keep onion-location and which is it's value over alt-svc?
Does they both work in relation to http and https?
which is the prioritization run inside the Tor browser over the two implementations
which are the versions of Tor that supports one or the other?

Thank you so much for clarifying. :)

I just noticed that a ticket has been already opened in order to document this topic: https://trac.torproject.org/projects/tor/ticket/33516

I am deploying this change today. Detail of the change here: https://share.riseup.net/#9u7BJQ_S_GQEdmqFAaUpTQ

To make sure I am temporarily disabling puppet from running on:

web-cymru-01.torproject.org
web-fsn-01.torproject.org
web-fsn-02.torproject.org
cdn-backend-sunet-01.torproject.org

We are now serving the onion-location header.

Trac:
Status: assigned to closed
Resolution: N/A to fixed

closed

Add header to redirect websites visitors using tor-browser to the .onion address

Child items 0

Activity