Opened 3 weeks ago

Last modified 2 weeks ago

#32865 new defect

Setting Origin: null header still breaks CORS in Tor Browser 9.5

Reported by: micahlee Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: acat, gk, alecmuffett Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I'm working on creating an onion service version of theintercept.com using Alec Muffet's EOTK (https://github.com/alecmuffett/eotk) and running into an issue with CORS that lead me to #32255. The patch that fixed that issue doesn't totally solve the Tor Browser CORS problems.

Specifically, embedding documents from DocumentCloud works in Tor Browser 9.5 on the clearnet site, but breaks when viewing my test onion site. Here is an example document: https://theintercept.com/document/2019/05/08/ron-wydens-letter-to-private-intelligence-firm-lookingglass-on-immigration-protest-surveillance/

This page makes a XHR request to https://www.documentcloud.org/api/documents/5993383-Ron-Wyden-s-Letter-to-Private-Intelligence-Firm.json with the following relevant request headers:

Origin: https://theintercept.com
Referer: https://theintercept.com/

And the response has these relevant headers:

access-control-allow-credentials: true
access-control-allow-headers: Accept,Authorization,Content-Length,Content-Type,Cookie
access-control-allow-methods: OPTIONS, GET, POST, PUT, DELETE
access-control-allow-origin: https://theintercept.com

The response body is JSON object that describes the document. This page ends up working fine. After loading that XHR request, it makes a series of other requests to assets.documentcloud.org, loading images for individual pages of the document to display.

I've configured EOTK to basically run two onion services, one that proxies requests to theintercept.com (ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion) and one that proxies requests to documentcloud.org (5h2y2fecwejfrizmzdt2bmwxvykv32xddx4k4f2lhocgvxqiwsabm2qd.onion). (Note that both of these domains force HTTPS and use a self-signed certificate, so if you want to test them you'll need to accept the untrusted certificates.)

Here is the onion service version of that page: https://ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion/document/2019/05/08/ron-wydens-letter-to-private-intelligence-firm-lookingglass-on-immigration-protest-surveillance/

This page makes an XHR request to https://www.5h2y2fecwejfrizmzdt2bmwxvykv32xddx4k4f2lhocgvxqiwsabm2qd.onion/api/documents/5993383-Ron-Wyden-s-Letter-to-Private-Intelligence-Firm.json with the following relevant headers:

Origin: null

(Tor Browser is stripping the Referer header.)

And the response includes these relevant headers:

Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Accept,Authorization,Content-Length,Content-Type,Cookie
Access-Control-Allow-Methods: OPTIONS, GET, POST, PUT, DELETE
Access-Control-Allow-Origin: null

The response body is blank, and this warning is in the Tor Browser console:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.5h2y2fecwejfrizmzdt2bmwxvykv32xddx4k4f2lhocgvxqi…5993383-Ron-Wyden-s-Letter-to-Private-Intelligence-Firm.json. (Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘null’).

Note that if I configure EOTK to only create an onion proxy for theintercept.com, and not for documentcloud.org, I get the same behavior.

One possible solution would be to treat onion sites that load resources from other onion sites different than onion sites loading resources from clearnet sites. When it's onion -> onion, it could send the actual Referer and Origin headers, but when it's onion -> clearnet, it could strip the Referer header and send Origin: null, which is the current behavior.

For example, if https://ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion/document/2019/05/08/ron-wydens-letter-to-private-intelligence-firm-lookingglass-on-immigration-protest-surveillance/ makes a request to https://www.5h2y2fecwejfrizmzdt2bmwxvykv32xddx4k4f2lhocgvxqiwsabm2qd.onion/api/documents/5993383-Ron-Wyden-s-Letter-to-Private-Intelligence-Firm.json, it would send these headers:

Origin: https://ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion
Referer: https://ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion/

However if https://ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion/document/2019/05/08/ron-wydens-letter-to-private-intelligence-firm-lookingglass-on-immigration-protest-surveillance/ makes a request to https://www.documentcloud.org/api/documents/5993383-Ron-Wyden-s-Letter-to-Private-Intelligence-Firm.json, it would send these headers:

Origin: null

But also, in the case of The Intercept's website, I don't think it's a problem to leak the domain name in the Origin header when making requests to DocumentCloud, and in fact it would be nicer to not have to use a separate documentcloud.com onion proxy at all. I believe it would "just work" if the Origin header were passed as expected. So, another possible solution would be if an onion site could somehow tell Tor Browser that it doesn't want the Referer or Origin headers to be modified, maybe using an http header or something?

Child Tickets

Change History (6)

comment:1 Changed 3 weeks ago by micahlee

Component: - Select a componentApplications/Tor Browser
Owner: set to tbb-team

comment:2 Changed 3 weeks ago by alecmuffett

Cc: alecmuffett added

comment:3 Changed 3 weeks ago by alecmuffett

This strikes me as a farily fundamental question: Tor Browser in this instance is intentionally not following web standards behaviour in order to protect the "privacy of existence" / secrecy of given onion sites or pages. Questions for the TBB team include whether this non-standard behaviour will be plausibly copied (mandated?) in other browsers that implement onion networking, and how practical it is to assume that any/every onion site's threat model includes by-default privacy/secrecy, thereby breaking onions for (e.g.) TheIntercept and who knows whom else in future?

Making broad assumptions of "intent" at layer 7, on the basis of layer 3, will continue to have unexpected consequences as Onion networking is more generally adopted.

comment:4 in reply to:  3 ; Changed 2 weeks ago by gk

Replying to alecmuffett:

This strikes me as a farily fundamental question: Tor Browser in this instance is intentionally not following web standards behaviour in order to protect the "privacy of existence" / secrecy of given onion sites or pages.

Huh! We _are_ following web standards here. You might enjoy reading: https://tools.ietf.org/html/rfc6454#section-7.3. I'll quote the relevant part for you:

Whenever a user agent issues an HTTP request from a "privacy-
sensitive" context, the user agent MUST send the value "null" in the
Origin header field.

Note the MUST here. I think assuming that .onion sites are privacy-sensitive is a good default, as well.

Then there is https://fetch.spec.whatwg.org/#origin-header you might enjoy as well. (No referer boils actually down to Origin: null as well)

Actually, the discussion in #32255 might be useful, too, where we fixed Mozilla's bogus behavior.

comment:5 in reply to:  description Changed 2 weeks ago by gk

Replying to micahlee:

[snip]

One possible solution would be to treat onion sites that load resources from other onion sites different than onion sites loading resources from clearnet sites. When it's onion -> onion, it could send the actual Referer and Origin headers, but when it's onion -> clearnet, it could strip the Referer header and send Origin: null, which is the current behavior.

On the positive side, I think this seems to be worth exploring to me (bonus points if we have a convincing argument as to why this is (still) spec-compliant).

comment:6 in reply to:  4 Changed 2 weeks ago by alecmuffett

Replying to gk:

Huh! We _are_ following web standards here. You might enjoy reading: https://tools.ietf.org/html/rfc6454#section-7.3. I'll quote the relevant part for you:

Whenever a user agent issues an HTTP request from a "privacy-
sensitive" context, the user agent MUST send the value "null" in the
Origin header field.

Note the MUST here. I think assuming that .onion sites are privacy-sensitive is a good default, as well.

I stand corrected re: the text, but I differ on the presumption that all ".onion" sites are privacy-sensitive by default; because (apart from anything else) that you describe this as a "default" suggests there is a way to override the behaviour.

I am not aware of a way for a website to declare to Tor Browser, that it should override this behaviour? Am I again wrong?

Note: See TracTickets for help on using tickets.