Onion sites may be sending referer header

https://bugzilla.mozilla.org/show_bug.cgi?id=1744290 is a report by a Mozilla developer that he sees .onion addresses in his referrer logs, corresponding to 60 and 78 major versions and tor exit IPs.

I used https://iz3xdp3z2vuewtpbxityih5tdri3ee4zeqbcx3oq6pkezipgtwtn3pyd.onion/misc/ff/headers-include.html to try and reproduce it with 91 and 78 and I could not. This onionsite is a mirror of ritter.vg and it includes an image (and has a link) to ritter.vg (non-onion) on it.

But it might be an edge case.

If I grep through all my logs looking specifically for this issue, I do have a lot of weird hits in the past year and a half.

zgrep "\.onion" all_log.* | grep -v iz3xdp3z2vuewtpbxityih5tdri3ee4zeqbcx3oq6pkezipgtwtn3pyd | grep -v "tomritterbassljd" | egrep "Firefox/([0-9]+)" -o | sort | uniq -c
      1 Firefox/10
      1 Firefox/24
      1 Firefox/28
      1 Firefox/31
    178 Firefox/60
  10429 Firefox/68
  10146 Firefox/78

added Icebox + 1 deleted label

@tom can you grant me access to https://bugzilla.mozilla.org/show_bug.cgi?id=1744290

added Roadmap::Future label

removed Icebox label

added Bug label

@tom ping

added All Platforms label

You're on the cc list; you can't see it?

Hm so I can. I must not have been logged in previously. Sorry!

added Q2 label

/cc @gk

assigned to @ma1

We've got network.http.referer.hideOnionSource set to true, hence by default we do not send any Referer header and use null as Origin when leaving onion sites (verified empirically too).

We don't lock the preference, though, maybe we should?

@ma1 Could you check out Brave handles onion referer's in their Tor tab?

@ma1 Could you check out Brave handles onion referer's in their Tor tab?

Done: Brave (1.48.158) does remove the Referer header when going from onion to non-onion. Furthermore, its User-Agent header is Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36 (no "Firefox" there).

Ok good to know.

Perhaps these are non-Tor Browser browsers (Brave, custom configs?)

Perhaps these are non-Tor Browser browsers (Brave, custom configs?)

Yeah, or just plain Firefox users. @tom: you really believe this is a Tor Browser issue?

FWIW: the relevant patch got uplifted in https://bugzilla.mozilla.org/show_bug.cgi?id=1305144 and was written ages ago in #17334 (closed) and #9623 (closed).

Are those logged requests actually cross-site (we do send the Referer when navigating internally to the onion site)?

If a user of Tor Browser is visiting a website over the onion address, and then somewhere on that site, there is a link to the site that is not an onion site, and they click that link, then their traffic will go out an Exit node, and I think the browser would consider this cross-site as they are different domains, would the Referrer appear in that situation?

I think the browser would consider this cross-site as they are different domains

Exactly.

would the Referrer appear in that situation?

No it would not, that's the point of network.http.referer.hideOnionSource.

It looks like this is an issue on old Tor Browsers, but not current ones; no? If I look at my logs for 2022 and 2023 I see lots of onion referers, but only for old versions:

     14 Firefox/60
      3 Firefox/68
     54 Firefox/78
      1 Firefox/98

1 Firefox/98

This cannot be Tor Browser.

While the others are ESRs, 98 is RR. And it cannot be Android because we've skipped 97 and 98 (we've rebased 96, 99 and 102, plus possibly an unreleased 100).

Unless I'm reading the calendar wrong, only 68 and 78 were ESR versions. 78 was active from 2020-09 through 2021-10 whereas the network.http.referer.hideOnionSource feature seems to have been comitted around 2018ish (maybe earlier). The pref does default to false in vanilla firefox, so yeah, probably just Firefox users.

Here's the original(ish) issue about this feature: #22320 (closed)

@tom this referrer stripping preference was uplifted to Firefox, but it is disabled by default there. It seems like it would be a good idea to try and get this enabled by default in Firefox - do you know how this could happen?

Crazy idea: if we're concerned about users of other browsers on Tor leaking onion services info through Referer or Origin (and it seems we are, since these users are putting in jeopardy others by not using the Tor Browser), could we provide a default option (or at least initially guidance here) to automatically inject a Referrer-Policy: noreferrer header in every and each HTTP requestresponse proxied through the HiddenService machinery?

I don't think so, the request would be encrypted (assuming its going over HTTPS) and outside of teh tor daemon's control.

the request would be encrypted (assuming its going over HTTPS) and outside of the tor daemon's control.

I mean injecting the Referrer-Policy header in each response (sorry, I miswrote "request" earlier) from the local web server (which according to the instructions is serving unencrypted traffic from localhost) before it's passed as an hidden service downhill Tor.

Or, until the Tor daemon is patched to do this, or if it can't be done for other reasons, at least warning administrators to do so by themselves, e.g. using Apache's mod_headers.

Oh you mean the onion service side? IIRC we do say hosting a 'plain-text' onion service webserver is fine since all onion service traffic is encrypted by virtue of the onion routing, but this approach wouldn't work for HTTPS onions. We should warn system administrators to set up the right referrer policy though if we haven't already.

We should warn system administrators to set up the right referrer policy though if we haven't already.

Beside adding this to the documentation, I suppose the daemon could still do it automatically for HTTP, and check + warn via logs/console messages for HTTPS on restart.

For defense-in-depth for users with strange configs I've backported the pref to be enabled by default in base-browser here: #41627 (closed)

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1816916 to enable it in FF

IANAE but if you're trying to make tor specific prefs friendly (and not used in Firefox by default because hidden services are not supported by default) .. then

would you not also want to set dom.securecontext.allowlist_onions = true - 1382359,1744006

The difference here is that allowlist_onions changes the behavior of the browser to improve the behavior for users. Users have the agency to flip this pref themselves if they want to do the not-recommended thing.

Whereas hideOnionRefer changes the behavior of the browser to protect the confidentiality of onion sites; and the onionsites have no agency because they can't make users flip the pref.

Thanks thanks!

removed Q2 label

added Apps::Type::Bug label

added Apps::Impact::Unknown label

@tjr @ma1 looks like the upstream pref has been flipped and we'll inherit it in esr140. Is there anything else we need to do here?

I think we're good.

@ma1 #25482 (closed) is the same/dupe of this?

closed

mentioned in issue #25484 (closed)

marked #25484 (closed) as a duplicate of this issue

marked this issue as related to #25484 (closed)

made the issue visible to everyone