Opened 4 years ago

Closed 2 years ago

Last modified 2 years ago

#9623 closed defect (fixed)

Referers being sent from hidden service websites

Reported by: cypherpunks Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: tbb-torbutton, tbb-security, TorBrowserTeam201510R
Cc: gk, gordon@…, arthuredelstein Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (36)

comment:1 Changed 4 years ago by cypherpunks

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.

comment:2 Changed 4 years ago by arma

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

comment:3 Changed 4 years ago by gk

Cc: g.koppen@… added

comment:4 Changed 4 years ago by gmorehouse

Cc: gordon@… added

comment:5 Changed 4 years ago by cypherpunks

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. 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.

comment:6 Changed 3 years ago by erinn

Component: TorBrowserButtonTor Browser
Keywords: tbb-torbutton added
Owner: changed from mikeperry to tbb-team

comment:7 Changed 3 years ago by zyan

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.

comment:8 Changed 3 years ago by gk

Cc: gk added; g.koppen@… removed

comment:9 Changed 3 years ago by zyan

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

comment:10 Changed 3 years ago by gk

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.

comment:11 in reply to:  10 Changed 3 years ago by gk

Replying to gk:

Where is the .onion specific part?

Ah, I see it, nevermind then.

comment:12 Changed 2 years ago by vynX

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!

comment:13 Changed 2 years ago by 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.

comment:14 Changed 2 years ago by cypherpunks

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).

comment:15 Changed 2 years ago by arma

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.

comment:16 Changed 2 years ago by arthuredelstein

Cc: arthuredelstein added

comment:17 Changed 2 years ago by zyan

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.

comment:18 Changed 2 years ago by zyan

Status: newneeds_revision

comment:19 in reply to:  13 ; Changed 2 years ago by zyan

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.

comment:20 in reply to:  19 ; Changed 2 years ago by cypherpunks

Replying to zyan:

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.

Is occasionally breaking things not worth the security tradeoff?

comment:21 Changed 2 years ago by teor

Can we add the following behaviour to the security slider:

  • High-ish: Never send referrers to any cross-origin sites
  • Low-ish, or maybe default: don't send referrers containing .onion addresses to cross-origin sites

I can't imagine any use case for cross-origin .onion referrers that outweighs the security risks. But some users might want their clearnet sites that depend on cross-origin referrers to keep working.

comment:22 Changed 2 years ago by mikeperry

Keywords: tbb-security TorBrowserTeam201510 added

I agree that .onion domains should not send cross-origin referrers by default. I could also see the High setting disabling them entirely, or applying the same origin restriction from the refSpoof component.

It looks like Yan's patch works for the .onion case only. We can take that, if it still works. We can also alter it to have a separate pref to apply to everything for the High setting easily enough. I am fine with both.

In both cases, we will need to file another tbb-torbotton-conversion ticket to convert this to a direct Firefox patch, but this need not block deploying this now.

Sorry for missing Yan's initial review request.

comment:23 in reply to:  20 ; Changed 2 years ago by zyan

Replying to cypherpunks:

Replying to zyan:

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.

Is occasionally breaking things not worth the security tradeoff?

It might be, but this ticket is about .onion behavior, not general referrer behavior in TBB. Worth a separate ticket.

comment:24 in reply to:  23 Changed 2 years ago by cypherpunks

Replying to zyan:

Replying to cypherpunks:

Replying to zyan:

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.

Is occasionally breaking things not worth the security tradeoff?

It might be, but this ticket is about .onion behavior, not general referrer behavior in TBB. Worth a separate ticket.

Good point, I have created a ticket here: https://trac.torproject.org/projects/tor/ticket/17228

comment:25 in reply to:  22 Changed 2 years ago by zyan

Status: needs_revisionneeds_review

Replying to mikeperry:

I agree that .onion domains should not send cross-origin referrers by default. I could also see the High setting disabling them entirely, or applying the same origin restriction from the refSpoof component.

It looks like Yan's patch works for the .onion case only. We can take that, if it still works. We can also alter it to have a separate pref to apply to everything for the High setting easily enough. I am fine with both.

In both cases, we will need to file another tbb-torbotton-conversion ticket to convert this to a direct Firefox patch, but this need not block deploying this now.

i have now rebased https://github.com/diracdeltas/torbutton/pull/1 and it seems to be working on the few .onions i've tested.
mikeperry/gk please review. thanks.

comment:26 Changed 2 years ago by mikeperry

Keywords: TorBrowserTeam201510R added; TorBrowserTeam201510 removed

comment:27 Changed 2 years ago by gk

Status: needs_reviewneeds_revision

Here are a couple of thoughts:

1) I think all the general referrer related logic should not be included in this patch. Just the .onion related one (as this ticket is only about this and all the bikeshedding should go into #17228) and a pref, say extensions.torbutton.disable_onion_referrer, which governs enabling/disabling this feature

2) This code is called quite often and thus we should try to make it a bit more efficient IMO. E.g. there is no need to do

var prefs = Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefBranch);

every time http-on-modify-request gets triggered

3) I wonder why we need the tor_enabled check. What is its purpose in this patch?

comment:28 Changed 2 years ago by zyan

Will fix. On further thought, maybe just get rid of the pref entirely until #17228? I can't think of an immediate use case where one would want to enable cross-origin onion referrers.

comment:29 Changed 2 years ago by zyan

The tor_enabled check was boilerplate from the original referer patch; I'm not sure either why it's there.

comment:30 Changed 2 years ago by zyan

Addressed comments in https://github.com/diracdeltas/torbutton/pull/1 and updated to using mozIThirdPartyUtil instead of rolling our own same-origin check.

comment:31 in reply to:  28 ; Changed 2 years ago by teor

Replying to zyan:

Will fix. On further thought, maybe just get rid of the pref entirely until #17228? I can't think of an immediate use case where one would want to enable cross-origin onion referrers.

Onion-sites using sub-onions to host (static) content.
Or the onion-per-role design that Facebook (and perhaps other sites) use (I think it's upload, static, and dynamic).

Perhaps we could send an email to tor-dev before we decide whether we need a preference?

comment:33 in reply to:  31 Changed 2 years ago by zyan

Replying to teor:

Replying to zyan:

Will fix. On further thought, maybe just get rid of the pref entirely until #17228? I can't think of an immediate use case where one would want to enable cross-origin onion referrers.

Onion-sites using sub-onions to host (static) content.
Or the onion-per-role design that Facebook (and perhaps other sites) use (I think it's upload, static, and dynamic).

I am working with Alec Muffett at Facebook to see if this patch affects their use case, since they use a different onion domain as a CDN.

Note that the patch does NOT affect referrer passage between onions and sub-onions. Those are considered the same origin, so the referrer is sent as usual.

comment:34 in reply to:  30 ; Changed 2 years ago by gk

Replying to zyan:

Addressed comments in https://github.com/diracdeltas/torbutton/pull/1 and updated to using mozIThirdPartyUtil instead of rolling our own same-origin check.

This looks better, thanks. Some smaller things:

1) Could you avoid doing

   var ios = Components.classes["@mozilla.org/network/io-service;1"].
     getService(Components.interfaces.nsIIOService);

everytime calling onModifyRequest()? Assigning it once in the constructor (as done with thirdPartyUtil) should be enough.

2) Could you remove the boilerplate for Firefox 3.6 at the end of torRefSpoofer.js?

3) Could you squash your commits?

One thing I am wondering is whether it would be better to set the Referrer to a URL containing the domain the user is requesting instead of setting it to http://example.com. There might be cases where this makes the Referer spoofing non-obvious which seems superior to just using a semi-random URL.

comment:35 in reply to:  34 Changed 2 years ago by zyan

Replying to gk:

Replying to zyan:

Addressed comments in https://github.com/diracdeltas/torbutton/pull/1 and updated to using mozIThirdPartyUtil instead of rolling our own same-origin check.

This looks better, thanks. Some smaller things:

1) Could you avoid doing

   var ios = Components.classes["@mozilla.org/network/io-service;1"].
     getService(Components.interfaces.nsIIOService);

everytime calling onModifyRequest()? Assigning it once in the constructor (as done with thirdPartyUtil) should be enough.

2) Could you remove the boilerplate for Firefox 3.6 at the end of torRefSpoofer.js?

good catches, fixed.

3) Could you squash your commits?

One thing I am wondering is whether it would be better to set the Referrer to a URL containing the domain the user is requesting instead of setting it to http://example.com. There might be cases where this makes the Referer spoofing non-obvious which seems superior to just using a semi-random URL.

I think this makes sense, so I did it.

comment:36 Changed 2 years ago by gk

Resolution: fixed
Status: needs_revisionclosed

Thanks, I applied this to master (commits 9fe9cdfe816ed030e615643e35b9e0dcaa5a8635 and f98243cfed952d1a1375fb1f486d728e6ca1bd44). It should show up in the next nightlies.

The patch made it into the stable branch (maint-1.9.3) as well as I think the benefits outweigh the risks in this case (please complain if you think otherwise).

The C++ conversion ticket is #17334.

Last edited 2 years ago by gk (previous) (diff)
Note: See TracTickets for help on using tickets.