1742405 - Sending null Origin Header for .onion domain name only to no-CORS request

Status: NEW

(Core :: Networking, task, P3)

Description

[Tim Huang[:timhuang] [PTO 10/19 ~ 11/3]]

We have set Origin Header to null for .onion requests in bug 1503736. Now, people are discussing in https://github.com/whatwg/fetch/issues/1350 about standardizing this behavior and, also, only applying this restriction to no-cors requests. It's because this could disable meaningful access controls for resources in .onion page. However, this change could bring accidental leakage which is mentioned in here.

Dragana, Valentin, what's our standpoint on this? Thanks.

Comment 1

[Anne (:annevk)]

Note that currently network.http.referer.hideOnionSource is false. I'd like to know whether we plan on changing that.

Comment 2

[Valentin Gosu [:valentin] (he/him) {{ PTO until Nov 5 }}]

(In reply to Anne (:annevk) from comment #1)

Note that currently network.http.referer.hideOnionSource is false. I'd like to know whether we plan on changing that.

They override this pref in the tor browser
I don't think we are intending to ship that, unless it becomes part of the standard 🙂

I am not entirely sure what the expectations of an .onion page are.
I think we should reach out in the TOR issue tracker. They seem to be aware of the CORS issues

Comment 3

[Valentin Gosu [:valentin] (he/him) {{ PTO until Nov 5 }}]

This comment seems relevant:

I support @micah's proposal of allowing the Origin header between .onion domains. This gives a workable solution to security-conscious admins (simply get all services a .onion domain) while protecting users from leaking info to clearnet sites.
Apparently '"privacy-sensitive" context' is not clearly defined. The argument to make this proposal spec-compliant could be that the context only becomes privacy-sensitive when the request goes from .onion into the clearnet.
Yep. As I stated in #32865 (comment 2670298) this seems to me like a good way forward. Patches are welcome as we are swamped right now. I can try putting it on our 10.5 radar allowing us to backport this to 10.0...

Comment 4

[Anne (:annevk)]

I chatted a bit with Tom Ritter about this. It seems we could flip network.http.referer.hideOnionSource as .onion domains typically do not resolve. We should do that I think. Given that .onion domains can be secret and CORS is rather easily used on today's web, my inclination would be to keep the current strict behavior and only support revealing .onion domains through some kind of explicit opt-in at a later point.

I've asked for further feedback on the Fetch issue from some of the folks directly involved with .onion. If anyone here has a Gitlab account it might also be worthwhile highlighting the Fetch issue on the Tor Project issue.

Comment 5

[Valentin Gosu [:valentin] (he/him) {{ PTO until Nov 5 }}]

I left a note on the tor issue encouraging them to participate in the fetch discussion.

Comment 6

[Tom Ritter [:tjr]]

I heard back from an engineer on the Facebook onionsite, posted with permission:

this is actually breaking photo and video uploads within the Facebook product at the moment, since they involve separate "upload" and "vupload" subdomains of our onion (and clearnet site too). An engineer who is onboarding onto our Tor infra is investigating and we're undecided whether we should fix this (safely & securely) on our end or not - we need to make sure we get a grasp of all the CSRF edge-cases!

Perhaps there's some intermediate solution in which Tor Browser still allows CORS between subdomains of an onion service but disallows it between different onions / between clearnet and onion-space. Maybe that's catering too specifically to our use-case (I'd guess that CORS is generally used for cross-domain requests rather than cross-subdomain requests).

Comment 7

[Anne (:annevk)]

Could they post that on the relevant standards issue? Per the public suffix list it seems doable, but it would be the first time that CORS makes a distinction between same-site and cross-site, rather than same-origin and cross-origin. It ends up being quite the special case, though it does seem somewhat reasonable given how .onion domains work (as I understand it anyway).