Opened 5 years ago

Last modified 7 months ago

#13747 new enhancement

Block non .onion content on .onion addresses (mixed content blocking)

Reported by: legind Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-security, TorBrowserTeam201903
Cc: arthuredelstein, brade, mcs, tom, pospeselr Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor27

Description

The .onion URL for a given THS instance is a fingerprint of the public key, thus ensuring authenticity of the service. For this reason, some assume the same security assurances for .onion addresses as they would for https, with the added assurances that hidden services provide. For instance, the major browsers have chosen to not load http resources when accessing an https site, blocking mixed content. However, there is no protection against mixed content being loaded in the TBB for .onion addresses when they include resources from http URLs. For any .onion URL which includes http resources, an attacker controlling an exit node could perform a Man in the Middle attack, providing malicious javascript which modifies the content of the DOM.

One would hope that an http THS would never include remote resources from an http site if they would like to protect their users. In fact, one would hope that a THS would never load any resources at all from a source they do not control. But this is no guarantee that they won't. It seems like a good security measure to disallow http resources from being loaded in TBB.

Child Tickets

Attachments (1)

Screenshot - 11132014 - 11:32:01 AM.png (149.0 KB) - added by legind 5 years ago.

Download all attachments as: .zip

Change History (24)

Changed 5 years ago by legind

comment:1 Changed 5 years ago by legind

s/from being loaded in TBB/from being loaded for .onion addresses in TBB/g

comment:2 Changed 5 years ago by arthuredelstein

Cc: arthuredelstein added

comment:3 Changed 5 years ago by mcs

Cc: brade mcs added

comment:4 Changed 5 years ago by jsha

For extra info, TBB disables mixed content blocking for HTTPS pages because that allows HTTPS Everywhere to enable a larger variety of rules (since it can fix up HTTP subresources before they get blocked). See these messages from Mike Perry:

https://lists.eff.org/pipermail/https-everywhere/2015-February/002398.html
https://lists.eff.org/pipermail/https-everywhere/2015-February/002400.html

However, it would be possible to make a different decision for onion addresses, which have different properties.

comment:5 Changed 4 years ago by elypter

the user should be warned but it should be possible to have mixed content.
besides that i always found it stupid when a browser was warning about mixed content but not when surfing a plain http site. that made the impression as is plain http was safer.

if thats not too much work i would suggest that in front of the url there should be 1-3 symbols showing what content is present on the site. for a site that mixes all 3 ways there would be an open lock, a closed lock and an onion.

comment:6 Changed 3 years ago by legind

Severity: Normal

Since the Next Generation Hidden Services is nearly ready to deploy, it would be good to revisit this ticket.

The urgency of this has only increased with NG Hidden Services - users will assume an even greater degree of security than before, which Hidden Services can reasonably provide if they are loading HTTP resources.

comment:7 Changed 3 years ago by teor

This request has a similar affect to the OnionTrafficOnly SOCKSPort flag from #18693, but it is implemented at the application level, rather than the tor daemon level.

comment:8 Changed 3 years ago by cypherpunks

Keywords: tbb-security added
Summary: Block Mixed Content on .onion AddressesBlock non .onion content on .onion addresses

Previous Summary makes sense too, but is a dupe of #13033.

One would hope that an http THS would never include remote resources from an http site if they would like to protect their users.

and from https?

It seems like a good security measure to disallow http resources from being loaded in TBB.

at all?

Anyways, what should be done asap is a warning system for .onion sites like that for passive and active mixed content, which allows to distinguish altered sites by looking at the address bar.

comment:9 in reply to:  8 Changed 3 years ago by arthuredelstein

Replying to cypherpunks:

Previous Summary makes sense too, but is a dupe of #13033.

This is not a duplicate of #13033 (but related). This ticket concerns onion addresses, and #13033 concerns a patch to improve the mixed content blocker in TBB/Firefox.

comment:10 in reply to:  8 Changed 3 years ago by legind

Replying to cypherpunks:

Previous Summary makes sense too, but is a dupe of #13033.

One would hope that an http THS would never include remote resources from an http site if they would like to protect their users.

and from https?

This is addressed in the next sentence: "In fact, one would hope that a THS would never load any resources at all from a source they do not control."

It seems like a good security measure to disallow http resources from being loaded in TBB.

at all?

No, the specific resources mentioned in this ticket, of course :)

comment:11 Changed 3 years ago by gk

Resolved #21713 as duplicate.

comment:12 Changed 2 years ago by cypherpunks

There was a paper relatively recently which showed that a very large chunk of hidden services (~20%) were referencing external resources on non-onion domains (like Google Analytics and jquery). I believe https://mascherari.press/onionscan-report-august-2016-revisiting-caronte-analytics-bitcoins-and-correlations/ describes it. Although a solution to this ticket won't mitigate the HS deanonymization issues, the onionscan results show conclusively that there are a significant number of hidden services which do, often accidentally, expose non-onion resources.

comment:13 Changed 14 months ago by traumschule

Parent ID: #21952

comment:14 Changed 12 months ago by gk

Cc: tom added
Keywords: TorBrowserTeam201810 added
Priority: MediumHigh
Summary: Block non .onion content on .onion addressesBlock non .onion content on .onion addresses (mixed content blocking)

comment:15 Changed 12 months ago by gk

.onions are treated as secure context now (see: https://bugzilla.mozilla.org/show_bug.cgi?id=1382359), so we might already get the mixed content blocking for http:// content (we should double-check that). But even if that's the case I think we should do full mixed content blocking for all non .onion content.

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

comment:16 Changed 12 months ago by gk

Keywords: TorBrowserTeam201811 added; TorBrowserTeam201810 removed

Moving our tickets to November.

comment:17 Changed 11 months ago by gk

Keywords: TorBrowserTeam201812 added; TorBrowserTeam201811 removed

Moving our tickets to December.

comment:18 Changed 9 months ago by gk

Keywords: TorBrowserTeam201901 added; TorBrowserTeam201812 removed

Moving tickets to Jan 2019.

comment:19 Changed 9 months ago by gk

Keywords: TorBrowserTeam201902 added; TorBrowserTeam201901 removed

Moving tickets to February.

comment:20 Changed 8 months ago by gk

Keywords: TorBrowserTeam201903 added; TorBrowserTeam201902 removed

Moving remaining tickets to March.

comment:21 Changed 7 months ago by gk

Parent ID: #21952
Sponsor: Sponsor27

comment:22 Changed 7 months ago by gk

Cc: pospeselr added

Closed #26625 as duplicate.

comment:23 Changed 7 months ago by gk

#28174 is relevant here as "block" can mean a bunch of things.

Note: See TracTickets for help on using tickets.