Re: [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:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202002  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:  Sponsor27-can
--+---
Changes (by sysrqb):

 * keywords:  TorBrowserTeam202001 => TorBrowserTeam202002
 * sponsor:  Sponsor27 => Sponsor27-can


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202001  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:  Sponsor27
--+---
Changes (by sysrqb):

 * status:  new => needs_information


Comment:

 Replying to [ticket:28174 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  TorBrowserTeam202001  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:  Sponsor27
--+---
Changes (by pili):

 * points:   => 2


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  TorBrowserTeam202001  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor27
--+---
Changes (by sysrqb):

 * keywords:  TorBrowser202001 => TorBrowserTeam202001


Comment:

 Correct keyword.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  TorBrowser202001  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor27
--+---
Changes (by sysrqb):

 * keywords:   => TorBrowser202001


Comment:

 Putting this on the roadmap for early next year.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  Sponsor27
--+---
Changes (by pili):

 * cc: simonfrey (added)


Comment:

 #32464 is a duplicate

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  Sponsor27
--+---
Changes (by gk):

 * sponsor:   => Sponsor27


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 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.

 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?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:1 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 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.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[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|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 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 [https://docs.google.com/document/d
 /1bPrNLIl7Qy-sA7aTfElu80Xk2eXzTfH_5BGTOUDK8XU/edit 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs