[tor-bugs] #28174 [Applications/Tor Browser]: Block non-.onion subresources on .onion websites?

[Tor Bug Tracker & Wiki]

#28174: Block non-.onion subresources on .onion websites?
--------------------------------------+--------------------------
 Reporter:  arthuredelstein           |          Owner:  tbb-team
     Type:  defect                    |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:                            |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------

Comment (by gk):

 Replying to [comment:3 tom]:
 > Replying to [comment:2 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28174#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online