Opened 14 months ago

Last modified 4 weeks ago

#21952 reopened project

.Onion everywhere?: increasing the use of onion services through automatic redirects and aliasing

Reported by: linda Owned by: linda
Priority: Medium Milestone:
Component: Webpages Version:
Severity: Normal Keywords: ux-team, tor-hs
Cc: dgoulet, asn, ilf, gk, isabela, arma, fdsfgs@…, hacim, guido@…, alec.muffett@…, mrphs, brade, mcs, catalyst, arthuredelstein, a.krey@…, phw, dmr Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by linda)

Background

People can't remember, or type in onion sites very easily. We should try to fix this somehow.

ilf is experimenting with automatically redirecting Tor users to .onion versions of websites that they visit (because they want more people to visit onion sites and they will do so if it is painless to them). But when users were redirected automatically to an onion site, they freaked out about it because they didn't know what happened, didn't know what onion sites were, and the "https" was dropped.

asn and dgoulet also were trying to find a solution to make onion sites more accessible to use. Specifically, onion addresses are quite long and random-ish, making them hard to remember and hard to type. There were many solutions discussed casually to try and resolve this, but none stood out as a clear winner.

Discussion

I like the idea of redirecting users to .onion sites automatically when they type in the websites non-onion address. This way, users don't need to remember anything else, need to type in anything long, or really even know what onion sites are.

My suggestion is to follow the https design pattern, and create a similar indicator for .onion sites.


The proposed solution would be this: when a user types in a website (pad.riseup.net), they would automatically be redirected to the onion site. When this happens, there would be an onion icon next to the address bar (replacing the https lock icon if there is one, or just being there an https lock icon would be if redirection from an http website), similar to that of the https lock icon. The address in the address bar can turned a different color or indicated in some way that this is an alias for the onion site.

From my observation, people don't mind automatically being redirected to https sites from http sites, but freak out when redirected from an http/https site to an onion site. I don't think that this is because people know what https is and find the idea comforting (although this can help). I speculate that they don't mind because they don't notice, and the reason why users freaked out at the redirect to onion sites is that they saw the website address visibly change in the address bar.

Also--

If we want to show users the address of the onion site, we can additionally have a feature to reveal the onion site when the user clicks in the address bar.


I don't know how I feel about this, since it may just be confusing, and just shock the user later. Users don't know that pad.riseup.net resolves to some numerical IP address, and that isn't displayed to users. So there could be an argument made for just indicating that the address is an alisas and not ever showing the .onion address, either. This will confuse way less of the general population.

Considerations

  • how should the redirect behavior work?
  • how can we implement this without tracking?
  • should we allow users to turn off this redirecting behavior?
  • should we hide the .onion address from the users more so than the proposal above?

Child Tickets

Attachments (5)

onion-address-idea.png (24.8 KB) - added by linda 14 months ago.
onion-address-secondary-idea.png (39.2 KB) - added by linda 14 months ago.
rules.zip (118.9 KB) - added by cypherpunks 14 months ago.
290 onion redirection rules
21952.png (2.5 MB) - added by antonela 6 months ago.
21952 - 1.png (2.2 MB) - added by antonela 6 weeks ago.

Change History (58)

Changed 14 months ago by linda

Attachment: onion-address-idea.png added

Changed 14 months ago by linda

comment:1 Changed 14 months ago by linda

Description: modified (diff)

comment:2 Changed 14 months ago by linda

Hey asn and dgoulet: I'd love to hear your thoughts.

comment:3 Changed 14 months ago by cypherpunks

From my observation, people don't mind automatically being redirected to https sites from http sites, but freak out when redirected from an http/https site to an onion site. I don't think that this is because people know what https is and find the idea comforting (although this can help).

Have you tested the opposite, whether users notice anything different about a downgrade attack when they're being redirected from https to http?

comment:4 Changed 14 months ago by arma

Three thoughts:

A) If I'm using onion *and* https, I want some visual way to learn that. That's because an https cert for an onion site, especially if it's an EV cert, probably means that I can be more assured that I'm really on the site I meant to be on. In particular, if you replace the https lock icon with the onion one, then it could be harder for me to know whether I have the https layer too.

B) I think the UX part might need to depend on how exactly we're choosing to do the redirects. Do we have a local database, a la httpseverywhere, that has a mapping for us? And when we type in foo.com, it auto rewrites it to foo.onion? In that case, I think it is a really compelling idea to have the browser tab display "foo.com" for us when we're at the site that it "knows" is foo.onion. We could even do that swap if the user went directly to foo.onion, since we can look it up to see that we should display foo.com. But in this case, we should also have a good plan for how to handle the case where the user is on an onion address that isn't in our rewrite table. I guess we put the cool blue onion label in the url tab, but leave the address alone (as xyz.onion)? Does that create a world where we have first tier onions and second tier onions, and users learn to mistrust second tier onions? Is that a feature or a bug?

Shipping such a table with Tor Browser means more centralization of the naming system. Especially if users trust sites in the table more than sites not in the table, we're going to see pressure from various folks to get their onion address added to the list. Do we add the particular sketchy sites, or do we opt not to, effectively censoring them? How about when some government agency comes to us asking us to remove one of the entries?

Maybe there are other approaches to helping users do the rewrite that don't suffer from the centralization / central point of intervention issues above. See e.g. the proposals for having CAs include both foo.com and an altname of foo.onion in the same https cert, to effectively bind the names together.

C) The browser has a bunch of built-in defenses, under the broad term "cross site something", which aim to provide isolation of cookies, javascript, etc between domains. These defenses are often keyed off of what's written in the url bar. So we should have some smart browser people think through whether we would be undermining these defenses with this change. (Alternatively, maybe we can get away with not changing what the browser thinks is in the url bar, but just changing how it's displayed to the user.)

comment:5 Changed 14 months ago by arma

Cc: arma added

comment:6 in reply to:  4 Changed 14 months ago by arma

Replying to arma:

C) The browser has a bunch of built-in defenses, under the broad term "cross site something"

Yawning helpfully supplies the phrase "same-origin policy".

Changed 14 months ago by cypherpunks

Attachment: rules.zip added

290 onion redirection rules

comment:7 Changed 14 months ago by cypherpunks

If it will be useful here is my collection of 290 clearnet to onion rules. It is the personal continuation of "darkweb-everywhere" but does not include the proofs. Most of them are official mirrors, some addresses may be unofficial but harmless mirrors, obvious or potential scam websites were not added. To use them, just copy the rules to the HTTPSEverywhereUserRules folder inside your Tor Browser profile. Since the goal was just to collect all such addresses, I didn't bother with cleaning obsolete rules. Nevertheless it is up to date and contains most of the websites that has onion addresses.

But Facebook is turned off by default since that would make the user fingerprintable, is there a way to use the redirection only if the person visits facebook.com?

Last edited 14 months ago by cypherpunks (previous) (diff)

comment:8 Changed 14 months ago by gk

#19812 is at least related.

comment:9 Changed 14 months ago by gk

#8686 has already had some discussion about the UX in the URL bar.

comment:10 Changed 14 months ago by cypherpunks

My suggestion as a long time user of these rules:

It should be easy to disable/revert the redirection for times when the onion address is down or doesn't provide the same functionality as the clearnet one, for example trac.torproject.org onion mirror doesn't allow logging in

comment:11 Changed 14 months ago by tokotoko

Cc: fdsfgs@… added

comment:12 Changed 13 months ago by blockflare

My modest suggestion: If such a redirect proposal is implemented, instead of scaring the user with such unexpected behavior, make it optional, and ask the user with a dialog when he first installs the Tor Browser to choose whether he wants to be automatically redirected to some onion services or not (additionally with some non-technical information on what they are and their security benefits).

comment:13 Changed 13 months ago by asn

Hey Linda. Thanks for thinking about this problem.

FWIW, I definitely find this idea quite compelling and I think it's well motivated. That said, I feel that Roger raised some very good points in comment:4. e.g. what happens when a user uses onion+HTTPS which seems like it's not currently handled by the mockups above.

And then of course there is the question of how are those automatic redirects caused?

  • Does this proposal apply only to clearnet sites that actually do an HTTPS 302 redirect to an onion site? This rarely happens right now.
  • Or does this proposal assume that there is some out-of-scope mechanism that does automatic redirects from clearnet to onion sites (like Roger's (b), or the various ideas from our recent blog post? WRT Roger's (b) idea, I definitely echo that the Tor Project should not be responsible for mapping names to onions: I think that's a huge rabbithole of sadness that should probably be handled by a third-party organization (e.g. EFF) or as a community project (e.g. we include darkweb-everywhere in TBB, like we do for https-everywhere).

Anyhow I will not complicate this thread further with more doubts and edge-cases, as there are various open questions here already.

comment:14 Changed 13 months ago by micah

Cc: hacim added

comment:15 Changed 13 months ago by guido

Cc: guido@… added

comment:16 Changed 13 months ago by micah

Right now, the current way that Riseup is doing this is the first one that asn enumerates:

  1. 1/hr cronjob that downloads the current exit list
  2. leaning on apache/nginx geoip modules to webserver redirect any user that comes from an IP in the above list to the onion address

This works fairly well, I have reasonable ways to do it in apache and nginx. This was the mechanism that ilf and I were developing and were wanting to document and promote more to get onion operators to do, rather than trying to do this tor mapping thing.

There are a couple cases where it doesn't work perfectly that I've run into:

  1. One user who runs an exit node on their home network router, NATing all their connections through that same IP, but does not run TBB, was unhappy that they were redirected to .onion sites because they didn't want to use TBB all the time. This was a bit of a rare case. The user agreed to try to use TBB instead in the future, but also was willing to provide me his relay FP so I could remove it from the redirect rules.
  1. One user who was concerned about the redirection, thought they had been hacked and were being redirected to a nefarious site.

comment:17 in reply to:  16 ; Changed 13 months ago by arma

Replying to micah:

redirect any user that comes from an IP in the above list to the onion address

I've been recommending to websites that they *not* do this.

First, it breaks your website for people in the case of false positives (e.g. where an apartment building has one IP address and one exit relay, or where somebody briefly setup an exit relay in the coffeeshop).

But more importantly, it should be up to the users what sort of security properties they get while connecting to your website, and you're taking away their choice. Privacy is about control and choice -- putting up a little dynamic section of the page that says "Hey, did you know we have an onion address?" is great, but sending them somewhere else based on their IP address seems like a slippery slope.

Last edited 13 months ago by arma (previous) (diff)

comment:18 in reply to:  17 Changed 13 months ago by ilf

Thanks Linda for opening this ticket and everyone for jumping in. Unfortunately, I feel we are both a little too quick and merging too many things into one.

So first things first:

Let's auto-redirect Tor-Users to Hidden Services!

Some websites already redirect Tor users to their Hidden Services:

(We planned to publically document how to do this. And then discuss this on tor-users. This ticket surpassed our timeline.)

This is awesome

  1. Other websites punish Tor users. Let's embrace (and "reward") them.
  2. Discovering onions is hard. Let's make it easier.
  3. Client-side redirects (like https://github.com/chris-barry/darkweb-everywhere and #19812) are nice. But server-side redirects are better:
    1. The server knows its onion, the client would have to verify it out-of-band or trust someone else.
    2. The server admin already controls, "what sort of security properties they get while connecting to your website", arma. We are doing the same thing with redirects to HTTPS, TLS properties, logging policies, etc. It's the admins server, afterall.

User response

Most users didn't freak out. We now have hundreds of users and most don't provide feedback. (Like always.)

Some users do provide feedback, and most say they like it. (Like me.)

As micah said, there was only one user that ran an exit at his home but didn't use TBB himself. He now does.

This works the other way around, too. When I shared a .onion address via chat, the other user knew what it was, but never bothered to get TBB before. To view the URL, they got TBB - and still use it today. I would not have shared the onion URL if I hadn't been auto-redirected.

And there was one user, who "freaked out" about the redirect. And only because that user used TBB, but didn't know what hidden services are. This is exactly the kind of person, i want to get using TBB.

Moving foward

The original issue we gave to Linda was the one user "freaking out" about the server-side redirect.

A rough first idea was: "Maybe TBB should inform users about .onion the first time they visit one?"

From there it evolved into this bigger debate about UX, URL bars, tabs, HTTPS, same-origin policy, darkweb everywhere, and more.

I'm not exactly sure where we move from here.

  1. Maybe a first step would be to discuss, if TBB should do something the very first time it visits a .onion.
  2. When we finally got around to documenting the server-side-onion-redirect, I propose to discuss that on tor-users.

Opinions?

comment:19 Changed 13 months ago by cypherpunks

I dislike the automatic redirection for tor users (at least if you implement it like it is implemented on lists.riseup.net) because it breaks links.

I want to be able to give out a _single_ URL without knowing if this is clicked by a Tor user or non-tor user and they should end up all on the _same_ content.

To give you an example with an URL. If you give this URL:

to a tor user, he will be redirected to

while non-tor users will see the actual intended content
for tor users the content would be here:

So now everytime I send someone a link I have to send two urls one for tor users and one for non-tor users since I don't know if the user uses tor or not.

comment:20 Changed 13 months ago by ilf

We are aware of the issue. I think the advantages outweigh the occasional inconvenience:

  1. We get more users to use onions, because they will use them even when they would not know about them.
  2. We get more users to use TBB, because they will use TBB to handle onion links. See the real-world example I encountered above.
  3. We circumvent the delegation of trust that is X.509 as much as possible in favor of the more direct system of trust that are onions.

The different content in your example is of course a bug in riseups configuration. That should not happen.

Last edited 13 months ago by ilf (previous) (diff)

comment:21 Changed 13 months ago by cypherpunks

How safe are server-side redirects? How can I be sure some capable adversary or a malicious exit node didn't redirect me?

comment:22 Changed 13 months ago by ilf

cypherpunks: What "safety" properties are you looking for?

If you visit https://pad.riseup.net, you put some level of trust in DNS, TLS (with X.509), and the server itself. But once you connect to it, you trust the server to give you the content that you requested and that it is autorized to give you.

We propose to allow that server in that connection to tell you his hidden service and redirect you to it. If this can successfully be MITM'd, so can the original content. So the attack vector is no different there.

OTOH, this makes it a lot easier to discover the .onion of a server, because clients get it directly from the server itself, not from any third entity like plugins or other websites. This minimizes a human attack vector like error or wrong information.

And once the .onion is used, we drop the reliance on DNS and X.509, which is a big win.

What I would recommend against is a redirect already on cleartext HTTP without HTTPS, like http://ev0ke.net/ is currently doing. That's why we want to test and discuss this to find and write down best practices.

Last edited 13 months ago by ilf (previous) (diff)

comment:23 Changed 13 months ago by cypherpunks

Can I disable server-side redirects when something is wrong with the onion address? This happens often and is a major problem

Client-side redirects gives the control to the user which is a good argument

comment:24 Changed 13 months ago by cypherpunks

Why do I need to trust the DNS and TLS systems so that I can avoid it later with the onion address it provides? And hoping each time that I am redirected to the genuine onion address

With client-side rules, you only trust the community once which should provide the proofs that the onion addresses are genuine anyway

comment:25 Changed 13 months ago by cypherpunks

Another example for what can go wrong with onion addresses is that I found many websites which have problems with replacing internal links with the onion address, this can have anonymity consequences, I would rather trust client-side rules to never allow any clearnet connection to happen

I can give examples where website owners recommend using darkweb-everywhere to fix such issues, this is an additional benefit of client-side (HTTPS-Everywhere) redirects

Example from torproject: Tor Browser onion download link:
http://expyuzz4wqqyqhjn.onion/dist/torbrowser/6.5.2/torbrowser-install-6.5.2_en-US.exe
redirects to
https://dist.torproject.org/torbrowser/6.5.2/torbrowser-install-6.5.2_en-US.exe

with automatic redirection rules this can be avoided
http://rqef5a5mebgq46y5.onion/torbrowser/6.5.2/torbrowser-install-6.5.2_en-US.exe

Last edited 13 months ago by cypherpunks (previous) (diff)

comment:26 Changed 13 months ago by alecmuffett

Cc: alec.muffett@… added

comment:27 Changed 13 months ago by mrphs

Cc: mrphs added

comment:28 Changed 13 months ago by mcs

Cc: brade mcs added

comment:29 Changed 11 months ago by catalyst

Cc: catalyst added
Keywords: ux-team added

comment:30 Changed 9 months ago by linda

Resolution: wontfix
Status: newclosed

I am the one who suggested it, but I feel weird about this suggestion.

I think that I am convinced that automatic redirects are not really safe and freak some people out. Yet I think that without redirecting automatically, it's really really really not going to be used by the masses.

BUT this is be okay. We want people to use Tor browser and browse things, and using onion services should be a decision that they actively make.The security implications are unclear, and it can easily politically be construed to us pushing an agenda, the security benefits are much less clear than with http vs https. I personally wouldn't mind an average Tor user browsing on regular sites and using .onion sites rarely for special cases.

I am also convinced that there are other projects all taking stabs at the whole naming-onion-sites, and that may provide a better solution.

comment:31 Changed 9 months ago by tom

Resolution: wontfix
Status: closedreopened

So something similar I have been advocating is using the Alt-Svc header to advertise .onions. Alt-Svc is an implemented Internet Standard, and once Tor Browser flips the prefs for it (and HTTP2) using it with .onions may just work right out of the box.

https://tools.ietf.org/html/rfc7838
https://www.mnot.net/blog/2016/03/09/alt-svc

The idea of Alt-Svc is for a website to be able to tell a client "For technical reasons you don't need to care about, please talk to me using [this other web address]. Oh, and do it over HTTP2 if you can."

The client optionally does so. (They don't have to.) If they do so, they *do not* change the address bar or give any sort of visual indication to the user.

I think websites (like facebook) should advertise .onion Alt-Svc's. Non-Tor Browsers should ignore them (although we'd have to validate that); but for users of Tor Browser, they will stop connecting to facebook.com and start connecting to facebookcorewwwi.onion. (The user won't even know the difference, but their connection will be silently and transparently upgraded.


Something interesting about this (that, again, we would need to verify) is that it should allow users to deploy HTTPS for their onion domains without getting an EV cert. This is because the HTTPS cert advertised on the .onion has to match the ORIGINAL domain name (in our example 'facebook.com') and NOT the alternate service domain (in our example facebookcorewwwi.onion). This is to prevent an attacker from redirecting people via Alt-Svc - the thought is that obtaining a CA cert for facebook.com is sufficient validation that it is the correct destination. So the onion operator never needs to get a cert with their .onion address included (which requires a company due to EV guidelines).


Now there is one wrinkle in my idea. Alt-Svc is delivered once, and then the client remembers it and uses it the next time. (Optionally it uses it the first time too, but that gains us no security.) Remembering means state. State means tracking.

So we have to figure out how to do this without state. My thought on this would be to develop something like HTTPS Everywhere. (Call it Onion Everywhere.) We would preload Alt-Svc bindings from the sites that have deployed this. We could explicitly ask them if they want to be included (the first few adopters will no doubt coordinate with us). Or we could just scan and opt in anyone we find.

comment:32 Changed 9 months ago by linda

Description: modified (diff)
Type: enhancementproject

I marked this as a project and formatted the ticket so that it is easier to read.

comment:33 Changed 9 months ago by linda

After reading Tom's comment, I'm back for advocating this idea. I didn't realize that this happens everywhere anyway, so it wouldn't be out of norm if Tor Browser did some automatic redirecting.

My previous reason for not considering this was:

The security implications are unclear, and it can easily politically be construed to us pushing an agenda, the security benefits are much less clear than with http vs https.

But if we feel this way, we can just redirect websites to their .onion counterpart if it's https + .onion.

I didn't realize that this proposal/Alt-srv would involve state/tracking, so that's something to think about.

comment:34 Changed 9 months ago by linda

Description: modified (diff)
Summary: Increasing the use of onion services through automatic redirects and aliasing.Onion everywhere?: increasing the use of onion services through automatic redirects and aliasing

comment:35 Changed 9 months ago by alecmuffett

Great. I posted a long and friendly explanation, and Trac swallowed it because it wanted email verification.

So, here are the highlights of what you missed:

1) https://github.com/chris-barry/darkweb-everywhere already exists. it needs engineers.

2) issuing AltSvc headers makes no sense unless the client is coming from an exit node, so if you want people to adopt that solution then you need to make it really cheap for sites to check if a client is an exit node

3) nobody will issue AltSvc on every request because it's a bandwidth-waste for 99.99% of requests.

4) facebook did not adopt the auto-upgrade idea because (1) worries about onion bandwidth (2) worries about user paranoia; both of these are now solvable. source: me.

comment:36 Changed 9 months ago by alecmuffett

p.s.: when I say "it needs engineers.", I actually mean "it needs a 'forever home'."

Renaming and refactoring (or even, reimplementing) "Darkweb Everywhere" and putting it officially under the aegis of the Tor Project is certainly the right way to go for the near, even medium term.

AltSvc headers are a cool idea, but nothing that cannot be achieved by a chunk of code that says:

if (client_ip_is_an_exit_node) { issue_http_308_redirect($rewritten_uri) }

...where HTTP-308 is "Permanent Redirect with Method and body not changed"; 307 is its temporary equivalent.

This, or something very similar, is how https://www.privacyinternational.org/ implements Onion-redirection. I know the sysadmin, if you want to talk to him.

Last edited 9 months ago by alecmuffett (previous) (diff)

comment:37 Changed 9 months ago by arthuredelstein

Cc: arthuredelstein added

comment:38 in reply to:  35 ; Changed 9 months ago by arthuredelstein

Replying to tom:

Now there is one wrinkle in my idea. Alt-Svc is delivered once, and then the client remembers it and uses it the next time. (Optionally it uses it the first time too, but that gains us no security.) Remembering means state. State means tracking.

Generally speaking, Tor Browser wipes all state after every session. (We should check that that is true for Alt-Svc.) And as Mozilla has already kindly implemented first-party isolation for Alt-Svc, I think it won't be usable for tracking.

Replying to alecmuffett:

Great. I posted a long and friendly explanation, and Trac swallowed it because it wanted email verification.

2) issuing AltSvc headers makes no sense unless the client is coming from an exit node, so if you want people to adopt that solution then you need to make it really cheap for sites to check if a client is an exit node

The client could also somehow indicate in the HTTP request that it supports onions.

comment:39 in reply to:  38 ; Changed 9 months ago by alecmuffett

Replying to arthuredelstein:

The client could also somehow indicate in the HTTP request that it supports onions.

Cute idea, although I can entirely imagine that suggestion would cause the Tor Users Should Look Nondescript anti-fingerprinting-community, to have kittens.

comment:40 in reply to:  39 Changed 9 months ago by arthuredelstein

Replying to alecmuffett:

Replying to arthuredelstein:

The client could also somehow indicate in the HTTP request that it supports onions.

Cute idea, although I can entirely imagine that suggestion would cause the Tor Users Should Look Nondescript anti-fingerprinting-community, to have kittens.

Good, I love kittens. :) But making it difficult to distinguish Tor Browser from other browsers is an unrealistic goal anyhow.

comment:41 Changed 8 months ago by akrey

Cc: a.krey@… added

comment:42 Changed 8 months ago by cypherpunks

Syverson here. (Gotta get myself a trac ID. Just noticed this ticket recently for the first time.)
This proposal fits under some of the things that I spelled out at a high level in "The Once and Future Onion" https://www.nrl.navy.mil/itd/chacs/syverson-once-and-future-onion
and that coincidentally has a section entitled "Onions Everywhere".
Also Griffin and I discussed even earlier in "Bake in .onion for Tear-Free and Stronger Website Authentication"
https://www.nrl.navy.mil/itd/chacs/syverson-bake-onion-tear-free-and-stronger-website-authentication
(though I think the subdomain onions and integration of onion and TLS keys as discussed in the later paper is generally more promising in the long run than the PGP approach).
Short term (before getting fullblown subdomain onions going), I would like to get a few things going.

  1. For sites with registered domain names, e.g., foo.com, look at usability, etc. of having a subdomain onion.foo.com that redirects to foo.com's onion address. This will be more compatible in the long run with sites providing self-authenticated access for their users who are not coming in via the Tor network (cf. Once and Future Onion), but redirecting from foo.com.onion should also be considered. I expect this is best accomplished via HTTPS everywhere rulesets, but am open.
  2. For onionsites with or without associated RDN, look at integration of TLS with onionsite keys. This won't prevent unknown authority warnings for non EV-certified sites (that fix is planned but further down the road) but will at least allow familiar HTTPS lock icon interface with any onion address and avoid those sorts of warnings. Many pieces here, but will stop now to avoid even more of a data dump on people.

comment:43 Changed 7 months ago by phw

Cc: phw added

comment:44 Changed 7 months ago by asn

FWIW, after multiple sessions during the montreal dev meeting, and also based on phw's survey, it seems that users are very open to the auto-redirect idea if it's done properly.

People liked Tor Browser using the Alt-Svc header to learn about onion addresses for websites and the browser redirecting users. People also suggested that Tor Browser inserts a "pop-up"-ish thing (maybe like an informative strip below the address bar) informing that auto-redirect is taking place as a form of user education.

Not sure how to best move forward here, but I'm mentioning my takeaways from the tor meeting.

comment:45 Changed 6 months ago by asn

Posted an initial proposal about Alt-Svc here so that we have something concrete to talk about: https://lists.torproject.org/pipermail/tor-dev/2017-November/012595.html

Changed 6 months ago by antonela

Attachment: 21952.png added

comment:46 Changed 6 months ago by phw

Responding to 21952.png​: doesn't the phrasing "a secure version of this site" imply that the currently-open site is not secure? That may be confusing given that the example uses HTTPS. I wonder if something along the lines of "a more anonymous and secure version of this site" may be helpful?

Also, I suppose a web site could display a very similar banner on its own, pretending that it's from Tor Browser. Should we worry about this?

Last edited 6 months ago by phw (previous) (diff)

comment:47 in reply to:  46 Changed 6 months ago by arthuredelstein

Replying to phw:

Also, I suppose a web site could display a very similar banner on its own, pretending that it's from Tor Browser. Should we worry about this?

Yes, I imagine it could potentially be a problem, especially on an http site. One possible alternative we discussed on IRC is the idea of using a popup notification (aka doorhanger). The popup partially overlaps with browser chrome so it can't be spoofed by the content page.

comment:51 in reply to:  49 Changed 5 months ago by cypherpunks

Replying to cypherpunks:

v1.0.7.1718 added this experimental project.

  1. Install the add-on and go to "Options" > "Advanced".
  2. Enable "#21952" and click Save.

Method 1: Configure server to send header.

1. Configure your server to send "Onion-Location" header with appropriate value.
e.g.
add_header Onion-Location "http://grrmailb3fxpjbwm.onion";

a. You can write "Onion-Location" to "onION-LoCAtion". Case doesn't matter.
b. The value must start with "http:" or "https:", and must ends with ".onion".
c. If the value is incorrect, the add-on will yield a warning to "Browser console".

2. Open a new tab and try to open your clearnet website.

3. Example result:

if "website.owner.test"'s server sent
"Onion-Location: http://xyz.xxxxx.onion" header

https://website.owner.test/about.html
--redir--> http://xyz.xxxxx.onion/about.html

Method 2: Add 1 line to php file.

<?php
header("Onion-Location: http://grrmailb3fxpjbwm.onion");// send Onion-Loc header
echo('Hmm?');
?>

If #21952 is not activated, you'll see "Hmm?".


Pros:
1. Easy to use. (just add 1 header)
2. Less need to maintain the onion-clearnet list.

Cons:
1. Evil webmaster can use this header to track Tor users individually.
For example, user A login -> send aaa.onion; user B login -> send bbb.onion.
2. If clearnet response is not https:// but http://, or the response is MITMed
by Cloudflare or something, attacker could ask the victim to redirect to evil.onion.

TLDR:
While this header might be useful, it's better to use o-c verified-by-human list
rather than trust server response header.
Last edited 5 months ago by cypherpunks (previous) (diff)

Changed 6 weeks ago by antonela

Attachment: 21952 - 1.png added

comment:52 Changed 5 weeks ago by dmr

Cc: dmr added

comment:53 Changed 4 weeks ago by dmr

Keywords: tor-hs added
Note: See TracTickets for help on using tickets.