Opened 20 months ago

Last modified 4 months ago

#28174 needs_information defect

Block non-.onion subresources on .onion websites?

Reported by: arthuredelstein Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: TorBrowserTeam202006
Cc: simonfrey Actual Points:
Parent ID: Points: 2
Reviewer: Sponsor: Sponsor27-can

Description

Right now, .onion sites can load HTTP or HTTPS subresources (scripts, images, etc.).

But is this safe? Loading non-.onion subresources means we are potentially leaking information including:

  • the .onion domain
  • the full top-level .onion URL
  • other information about the content of the page
  • the list of subresources requested by a .onion page

Leaks might happen by referer, fetch request, query string, etc. (I haven't tested these yet and I'm not sure what leaks happen in practice.) Such leaks would be particularly bad for "stealth" onion sites.

Even worse, some of the non-.onion subresources may leak the onion site's IP address. For example, a .onion website improperly configured may accidentally include URLs pointing to their own server's non-.onion IP address. Loading those subresources leaks the IP address not just to the user but to anyone watching connections outside the Tor network.

While it's true that warnings in Tor Browser's URL bar .onion icons from #23247 help a little (especially with HTTP subresources), they don't show any warning when onion sites from load non-.onion HTTPS subresources. And a warning icon is actually too late -- the subresource has already been requested by the time a user sees the warning.

So, my question is: should we apply a more strict blocking rule? Possible alternative rules could be:

  1. No non-.onion subresources can be loaded from a .onion site.
  2. No "active" non-.onion subresources can be loaded from a .onion site.

I guess it depends on how many existing onion sites we break. But my feeling is that allowing mixed content was a mistake for HTTPS sites and we should avoid making the analogous mistake.

Child Tickets

Change History (12)

comment:1 Changed 19 months ago by tom

I think there are two constituents here: The onion server, and the Browser user.

Our primary goal should be to serve the browser user.

Where it's easy and simple, we can serve the onion server. But these suggestions are not comprehensive, and Tor Browser will never be a comprehensive onion audit tool. I would instead advocate for improving the tool onionscan https://onionscan.org/ where it is possible (although that also, cannot be comprehensive...)

Focusing on the browser user, I think it's fair to treat any non-onion resource as Mixed Content on an onion, regardless of HTTP/HTTPS status. There are three levels of Mixed Content Blocking:

  • None
  • Active (blocks scripts, allows images)
  • Full (blocks scripts and images)

There's also the security slider. I would suggest that when the security slider is at High, we perform Full blocking. It provides a smaller attack surface for the browser user.

When the slider is not at High; I would advocate for either Active or Full Blocking. Probably Active.

  • I personally would ignore the situation of a HTTPS onion including from a HTTP onion and give this no special treatment (that is to say it's fine, and it loads fine.)

comment:2 in reply to:  1 ; Changed 19 months ago by gk

Replying to tom:

I think there are two constituents here: The onion server, and the Browser user.

Our primary goal should be to serve the browser user.

Where it's easy and simple, we can serve the onion server. But these suggestions are not comprehensive, and Tor Browser will never be a comprehensive onion audit tool. I would instead advocate for improving the tool onionscan https://onionscan.org/ where it is possible (although that also, cannot be comprehensive...)

Focusing on the browser user, I think it's fair to treat any non-onion resource as Mixed Content on an onion, regardless of HTTP/HTTPS status. There are three levels of Mixed Content Blocking:

  • None
  • Active (blocks scripts, allows images)
  • Full (blocks scripts and images)

There's also the security slider. I would suggest that when the security slider is at High, we perform Full blocking. It provides a smaller attack surface for the browser user.

I'd like to understand that point more. What attacks are you talking about here? We block *features* based on code execution vulnerabilities in the past, not based on transport, as a general rule of thumb. So, this means that on the highest slider scripts are already blocked irrespective of transport or mixed content situation or whatever. Now, images are not so far, because the ratio of security benefit/usability penalty is not that good. That, again, is not dependent on the underlying transport or the mixed content situation.

If I understand it right then what you want is to defend against the *privacy* risks Arthur outlined by using the *security* slider. If that's the case then I am not convinced by that idea yet as we don't want to mix security and privacy related settings in the slider.

comment:3 in reply to:  2 ; Changed 19 months ago by tom

Replying to gk:

If I understand it right then what you want is to defend against the *privacy* risks Arthur outlined by using the *security* slider. If that's the case then I am not convinced by that idea yet as we don't want to mix security and privacy related settings in the slider.

Nooo, I keep the delineation in mind. I said "when the security slider is at High, perform Full blocking" specifically for security reasons.

An attacker wants to compromise a user who visits foo.onion. foo.onion includes an image from example.com. (HTTP or HTTPS, doesn't matter.) Instead of compromising foo.onion, the attacker compromises either example.com or the connection from the exit node to example.com and serves an exploit on a passive piece of content (like an image.)

Performing full blocking removes this attack surface.

Now you said

We block *features* based on code execution vulnerabilities in the past, not based on transport

I hadn't heard the bit about transport before. Perhaps you disagree with me based on that. But I'm confused then: At Medium, why is JS disabled on HTTP sites? Isn't that blocking a feature based on transport?

comment:4 in reply to:  3 Changed 19 months ago by gk

Replying to tom:

Replying to gk:

If I understand it right then what you want is to defend against the *privacy* risks Arthur outlined by using the *security* slider. If that's the case then I am not convinced by that idea yet as we don't want to mix security and privacy related settings in the slider.

Nooo, I keep the delineation in mind. I said "when the security slider is at High, perform Full blocking" specifically for security reasons.

An attacker wants to compromise a user who visits foo.onion. foo.onion includes an image from example.com. (HTTP or HTTPS, doesn't matter.) Instead of compromising foo.onion, the attacker compromises either example.com or the connection from the exit node to example.com and serves an exploit on a passive piece of content (like an image.)

Performing full blocking removes this attack surface.

Okay, sounds good.

Now you said

We block *features* based on code execution vulnerabilities in the past, not based on transport

I hadn't heard the bit about transport before. Perhaps you disagree with me based on that. But I'm confused then: At Medium, why is JS disabled on HTTP sites? Isn't that blocking a feature based on transport?

Well, back then we wanted to block JavaScript due to its high amount of vulnerabilities found in the past everywhere. But we settled at *enabling* it for HTTPS on the more or less medium level to strike some balance between usability and security as otherwise that level would have been too unattractive to use.

So, it's not exactly like blocking something based on transport (the difference might sound subtle here but I still think it is worth mentioning). That said, in general we could think about taking the transport into account for putting something onto the slider. My worry is, though, that it makes analysis of which features to block where much more complicated and we end up picking less security where we should not.

But *that said* I think we should definitely do the mixed content blocking (we might even already get some due to treating .onion as secure context) and we have #13747 for that which I just put on our work radar. And we should go with (full) mixed content blocking regardless of the slider level. Ideally, we would align it with the mixed content policy we see wrt non-onion mixed content but I guess that could be up for debate.

I think I'd like to see #13747 fixed first and see what fallout we have from that change and some better understanding whether the remaining parts should be tackled on the browser side or not.

Arthur: if you feel that this ticket is essentially about implementing full mixed content blocking, then feel free to dupe it over to #13747. If not, let's revisit it after #13747 got done.

Last edited 5 months ago by gk (previous) (diff)

comment:5 Changed 14 months ago by gk

Sponsor: Sponsor27

comment:6 Changed 6 months ago by pili

Cc: simonfrey added

#32464 is a duplicate

comment:7 Changed 6 months ago by sysrqb

Keywords: TorBrowser202001 added

Putting this on the roadmap for early next year.

comment:8 Changed 6 months ago by sysrqb

Keywords: TorBrowserTeam202001 added; TorBrowser202001 removed

Correct keyword.

comment:9 Changed 6 months ago by pili

Points: 2

comment:10 in reply to:  description Changed 5 months ago by sysrqb

Status: newneeds_information

Replying to arthuredelstein:

Right now, .onion sites can load HTTP or HTTPS subresources (scripts, images, etc.).

But is this safe? Loading non-.onion subresources means we are potentially leaking information including:

  • the .onion domain
  • the full top-level .onion URL
  • other information about the content of the page
  • the list of subresources requested by a .onion page

Leaks might happen by referer, fetch request, query string, etc. (I haven't tested these yet and I'm not sure what leaks happen in practice.) Such leaks would be particularly bad for "stealth" onion sites.

Even worse, some of the non-.onion subresources may leak the onion site's IP address. For example, a .onion website improperly configured may accidentally include URLs pointing to their own server's non-.onion IP address. Loading those subresources leaks the IP address not just to the user but to anyone watching connections outside the Tor network.

I'm not sure I understand the goal of this. In the simple case, a web developer has complete control over which subresources are used on the web site. As such, they accept any risks associated with using non-onion subresources. Maybe we should provide more training/support for explaining these risks, but I do not see the browser as a place where these restrictions should be imposed.

I begin seeing the benefit of blocking resources from clearnet addresses on more complicated websites, such as those sites where user-generated content is published. However, in this case, it seems like the website/server should implement sanitization or filtering in their software, instead of expecting this functionality in the browser.

As a user, it is possible I may only want to load resources from .onion addresses. This wouldn't be related to leaking onion addresses. There is a torrc option (OnionTrafficOnly) which accomplishes this, and we could expose a UI preference for this - but as gk mentioned, this sound like #13747.

comment:11 Changed 5 months ago by sysrqb

Keywords: TorBrowserTeam202002 added; TorBrowserTeam202001 removed
Sponsor: Sponsor27Sponsor27-can

comment:12 Changed 4 months ago by pili

Keywords: TorBrowserTeam202006 added; TorBrowserTeam202002 removed

Deferring until June 2020

Note: See TracTickets for help on using tickets.