Opened 9 months ago

Last modified 4 months ago

#28174 new 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:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor27

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 (5)

comment:1 Changed 9 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 9 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 9 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 9 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 it's 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 is makes analysis of which features 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.

comment:5 Changed 4 months ago by gk

Sponsor: Sponsor27
Note: See TracTickets for help on using tickets.