Blind cross-origin requests to .tor.onion domains
PoC:
<!DOCTYPE html>
<html>
<body>
<span></span>
<script>
const target = document.querySelector("span");
const before = Date.now();
const img = new Image();
img.onload = () => {
target.textContent = (Date.now() - before);
};
img.onerror = () => {
target.textContent = (Date.now() - before);
};
img.src = "https://nytimes.securedrop.tor.onion";
</script>
</body>
</html>Pref on: hundreds of ms, even thousands
Pref off: 0 or 16-17 (the request is immediately rejected because the resolution fails, even though at least the browser doesn't say the cause).
We should find a way to allow onion aliases only when the document initializing a request is in the same eTLD.
And if we extend the functionality to support more lists, it will be a nightmare: users could be fingerprinted on the list they have, like uBlock Origin.
Designs
- tor-browser-build #41021
- tor-browser-build #41055
Activity
I understand the list being a FP, and the pref being binary. But I have questions
- is the pref different between distributions - e.g. tails vs TB
- would the list differ between distributions (I get that the list can change per release, but users should be up to date .. I know, I know)
Surely, locking the pref on for all and standardizing the list makes this almost moot?
I understand the list being a FP, and the pref being binary.
Well, it's binary but not uniform. Disabling this pref will disclose a lot of bits.
is the pref different between distributions - e.g. tails vs TB
Tails disables it only for Unsafe browser (captive portals). Otherwise it enables it. Actually, the intended users are encouraged to use Tails.
Having the feature enabled in the Unsafe browser means unveiling users of Tor Browser (TLS request with securedrop.org as a SNI), which isn't great. If you don't use a (secret) bridge you'll leak you're a Tor user anyway, so the number of users protected by this pref is very low, I'd say, but we need to think about them.
would the list differ between distributions (I get that the list can change per release, but users should be up to date .. I know, I know)
Nope. We don't have a dump of the list in our builds. Either you refresh it every 24 hours, or you don't have it. Disabling the pref deletes the list, IIRC.
We locked down the about:rulesets page from the initial version. Initially, I thought we could create an ecosystem of lists you could subscribe to. However, we decided to lock it down and prevent from adding new entries because the onion service aliasing problem is very open and has a lot of possible alternatives. We wanted to agree on a solution at the whole org level. It seems it was a good idea, at this point.
Still, it's possible to edit the only item there, so that FPF people could do tests with it. There's no documentation for anybody else on how to do it. If we really wished, we could just remove the page and tell the folks to use a preference in
about:config.I really didn't have a lot of background on the browser when I did the thing. The solution of replacing the DNS before it hits Tor is elegant enough. But it has yet another disadvantage: it'll leak the .tor.onion alias in the
Hostheader, I believe. It's probably okay until it's Secure Drop, but maybe only rewriting the URL bar was a better alternative, at this point.Anyway, TL; DR: no. There's only one list. Either you have it, or you don't. I believe not too many people disabled it, mainly some cypherpunks that stay around us (to avoid calling home to FPF, but not realizing that their fingerprint could change in this way).
I searched for the name of the pref online. There aren't many results. Mostly the crash that made me think about the problems I didn't think about initially, the MR to fix it, and some commits in the mailing list.
There isn't any public "cypherpunks guide" that tells you to disable this pref.
We should find a way to allow onion aliases only when the document initializing a request is in the same eTLD.
I can do it. @richard, feel free to assign it to me if needed.
To @thorin's point, let's just lock the pref for 13.0 and plan on implementing the 'real' fix in 13.5 (unless this won't work for some reason?)
-
No, this won't work.
Tails needs to have it on
user.js. They use it only for when Tor Browser is configured as unsafe browser for captive portals. I think locking it will not make this possible anymore.I wonder if this is actually used it. I hope it isn't.
Locking it would also bring more attention to it. This problem has existed for a long time now, delaying for a month won't be a big deal.
Maybe patching
nsScriptSecurityManager::CheckLoadURIFlagswould be enough. I don't know if this is what ma1 thought of, or maybe he had another idea that might be even simpler.Sadly, the resolution of the .tor.onion aliases is just too down the road and can't access the channel/origin attributes.
So, I have a strong preference for not locking, then do something when we have time (medium-high priority) and immediately backporting.
-
Maybe patching
nsScriptSecurityManager::CheckLoadURIFlagswould be enough. I don't know if this is what ma1 thought of, or maybe he had another idea that might be even simpler.Not sure if simpler, but probably cleaner, my idea was installing our own
nsIContentPolicyto do this (and maybe other blocking stuff in future) by rejecting any subresource request whose content location host name ends with ".tor.onion" (".bit.onion" too?) and whose loading principal (viansILoadInfo) doesn't match.Edited by ma1 -
Ack, works for me!
securedrop.tor.onion should be considered an eTLD already. At the moment we patch the public suffix file, but in the future I'd like to integrate the rulesets with the eTLD service.
We should make sure securedrop instances cannot load other instances as well, for me. So, nytimes shouldn't be able to load ft, etc, unless they use the real onion address.
added 13.5 stable label
added Bug Fingerprinting Roadmap::Future labels
added Backport label
added Desktop label
assigned to @ma1
mentioned in merge request !876 (merged)
marked this issue as related to tor-browser-build#41021 (closed)
marked this issue as related to tor-browser-build#41055 (closed)
mentioned in issue #42736
added Onion Services label