Looks like there is an issue on Tor Browser 9.0 which affects our CORS allowance setup, at least with the dependency django-cors-headers, because it fails to send the expected header ORIGIN in the OPTIONS preflight. It works fine using the latest 8 version. We've noticed this only happens when the CORS request source is a .onion address, otherwise it works as usual.
It seems this is now controlled by network.http.referer.hideOnionSource (changed in https://bugzilla.mozilla.org/show_bug.cgi?id=1503736). Was this pref supposed to affect all requests or just hiding the referer when navigating from an onion website to a non-onion one?
Hm! The idea behind the pref was avoiding information leakage when coming from an .onion domain while requesting a non-onion one. See: #22320 (moved) for a scenario.
The patch that got uplifted (https://bugzilla.mozilla.org/show_bug.cgi?id=1305144) strips the Referer header if the domain in that header would be a .onion one (it does not matter whether the target domain is a .onion or not)
So, the question here is: should the Origin header follow that model to prevent information leakage or is the usecase a different one (or better: are there use-cases that are different enough from the Referer one that we need a more nuanced approach here)?
If I understand it correctly, if we talk about Referer headers this patch is currently only making it easier to not leak the .onion referrer by default, but it should be possible to achieve the same via the right Referrer-Policy, right?
With Origin I think it's different, because the patch allows something that I think is not possible in regular browsers: to issue xhr (fetch, xmlhttprequest) requests without the Origin header. Well, it's possible to do with fetch + mode: no-cors option, but you only get an "opaque" response.
I'm also not sure about what we should do here. One possibility would be to simply go back to previous esr60 behaviour and not strip the Origin header for xhr requests. This however would make it not possible to do fetch requests without Origin. While that's what happens in regular browsers, I think being able to do fetch requests without Origin can be useful for .onion websites.
If we want to keep the current default behaviour, one possibility for people that need CORS in .onions could be to make Origin/Referer headers opt-in based on the page (or fetch API) Referrer-Policy. While linking the Origin header to the Referrer-Policy might be surprising (and non-standard), I think it would be safe to assume that a website that has an explicit policy like no-referrer-when-downgrade would be fine to have both Referer and Origin header in requests. If this approach would work, I guess we could change the default Referrer-Policy from no-referrer-when-downgrade to something like same-origin.
This is breaking doublemixwcfx4wadeuvuygpxej5jpu7uleesh3yptopnbj5kshnlrid.onion for me.
Do you know of any workarounds?
What does break mean? I just loaded the .onion and it works fine for me.
Try to do a mix and watch the network tab. It will retry OPTIONS over and over. Just enter a Bitcoin address like 1xm4vFerV3pSgvBFkyzLgT1Ew3HQYrS1V and click on mix.
The Bitmix API requires the Origin header to return the correct CORS response. Foxmixer is fine because it returns for *. Bitmix is selective.
BTW, I mentioned this issue in the uplift meeting, and tom did not see any problem with just reverting the https://bugzilla.mozilla.org/show_bug.cgi?id=1503736 patch and go to the previous esr60 behaviour. It's not clear why that change was done.
BTW, I mentioned this issue in the uplift meeting, and tom did not see any problem with just reverting the https://bugzilla.mozilla.org/show_bug.cgi?id=1503736 patch and go to the previous esr60 behaviour. It's not clear why that change was done.
Whenever a user agent issues an HTTP request from a "privacy-sensitive" context, the user agent MUST send the value "null" in theOrigin header field.
and arguably .onion sites could be seen as a privacy-sensitive context. Now, the question is whether we could just avoid stripping the header and set it to "null" instead?
Oh, and that seems to be the same behavior in the fetch spec: https://fetch.spec.whatwg.org/#origin-header: If we omit the Referer, send Origin: null. But it seems to me the patch in 1503736 is outright omitting it which does not seem to be compliant with the spec.
+ if (!origin.EqualsIgnoreCase(currentOrigin.get())) {+ // Origin header is suppressed by .onion+ return;+ }+ } } rv = mRequestHead.SetHeader(nsHttp::Origin, origin, false /* merge */);
does not even seem to be the same behavior depending on whether the code takes the nsHttpChannel or the nsCORSListenerProxy path or am I missing something here?