Referers being sent from hidden service websites

Currently, when browsing on a hidden service website, when you click on a clearnet/hidden service link it sends the current address as referer.

I think Tor Browser should behave for websites on .onion addresses the same as https:// websites on clearnet in certain cases.

Normally, when you click on a http link from a https website, it doesn't send any referer.

Tor Browser should at least use this same behavior of https for http hidden services (both are encrypted right?). No referers should be sent to clearnet or to other hidden services, this is unacceptable. I believe it shouldn't send referers for https links as well, so send nothing at all.

Other than a partial solution, I still believe using the smart referer is a better solution overall.

added TorBrowserTeam201510R component::applications/tor browser owner::tbb-team priority::high resolution::fixed status::closed tbb-security tbb-torbutton type::defect labels

This is not only an issue about users being tracked.

It's also bad for owners of hidden services as the addresses are getting discovered. Maybe the user was on a private website which nobody should learn, or at least on a private webpage on a public website.

Or maybe the referer could include login credentials, or other dangerous information.

The current behavior doesn't really fit well with the "hidden service" idea.

Sounds plausible to me. I wonder how hard it is to do technically.

Trac:
Cc: N/A to g.koppen@jondos.de

Trac:
Username: gmorehouse
Cc: g.koppen@jondos.de to g.koppen@jondos.de, gordon@morehouse.me

It looks like removing the referer spoofing feature was due to usability issues.

https://www.torproject.org/projects/torbrowser/design/#deprecate

Here is my idea. By default, if it's a hidden service website in the referer, don't send it to any other domain.

But what about a preference to enable smart referer feature for all websites. It would make sense to integrate/combine this feature into #9387 (moved). In short, it would be a good idea to simplify this slider to choose between "usability" or "security" by adding any other missing preferences like this referer spoofing.

Please share your opinions about this idea.

Trac:
Owner: mikeperry to tbb-team
Keywords: N/A deleted, tbb-torbutton added
Component: TorBrowserButton to Tor Browser

Mike, would you accept a torbutton patch that clears referer when going from a THS domain to any other domain? This is causing major headaches for us in SecureDrop.

Trac:
Cc: g.koppen@jondos.de, gordon@morehouse.me to gk, gordon@morehouse.me

Ok here is a quick patch for review, based on the formerly-obsolete torRefSpoofer component: https://github.com/diracdeltas/torbutton/pull/1/files

Where is the .onion specific part? There are no plans to implement a general Referer spoofing solution, see: https://www.torproject.org/projects/torbrowser/design/#deprecate section 1.

Replying to gk:

Where is the .onion specific part?

Ah, I see it, nevermind then.

Consider that the reasoning not to deprecate Referer behavior only makes sense when interacting with legacy clearnet websites. Providers of onion services should learn not to rely on cross-domain referrer trickery. Every day some onion addresses are being leaked to my web servers just because they link me… that is a serious issue!

Trac:
Username: vynX

I found this comment to be interesting https://addons.mozilla.org/en-us/firefox/addon/smart-referer/reviews/570470/

Looks like setting about:config's network.http.referer.XOriginPolicy;1 may solve this problem without any further action needed, maybe the torbrowser dev team can look into that.

This is being actively exploited in the wild to discover Tor Hidden Services by sniffers on or around bad exits. Please ensure that TBB at least refuses to send referrers over plaintext communications channels (eg: port 80).

Trac:
Sponsor: N/A to N/A

I can also imagine that even in the absence of malicious exits, somebody doing xkeyscore style rules on internet backbone traffic would scoop up all onion addresses whose web content links to pages on the insecure web. Sounds worth fixing.

Trac:
Cc: gk, gordon@morehouse.me to gk, gordon@morehouse.me, arthuredelstein

I have some spare time in the next week or so; let me know if you want me to rebase my 14-month old patch for this issue. https://github.com/diracdeltas/torbutton/pull/1/files

Note that Firefox 36 implemented meta-referrer, so in the meantime, .onion site owners can simply add a HTML meta tag to clear all referrers on the document. https://bugzilla.mozilla.org/show_bug.cgi?id=704320

Actually, Firefox 37 added CSP referrer policy, so that is another option. https://bugzilla.mozilla.org/show_bug.cgi?id=965727

I guess that also means the patch above could be simplified by injecting the CSP no-referrer header on HTTP responses for .onion documents.

Trac:
Status: new to needs_revision

Replying to cypherpunks:

I found this comment to be interesting https://addons.mozilla.org/en-us/firefox/addon/smart-referer/reviews/570470/

Looks like setting about:config's network.http.referer.XOriginPolicy;1 may solve this problem without any further action needed, maybe the torbrowser dev team can look into that.

I think that would affect all origins, not just .onion origins, which is probably not what we want. I usually browse with referrer disabled and I find that it occasionally breaks things.