Opened 4 years ago
Last modified 2 weeks 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, TorBrowserTeam201902 |
Cc: | arthuredelstein, brade, mcs, tom | Actual Points: | |
Parent ID: | #21952 | Points: | |
Reviewer: | Sponsor: |
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)
Change History (20)
Changed 4 years ago by
Attachment: | Screenshot - 11132014 - 11:32:01 AM.png added |
---|
comment:1 Changed 4 years ago by
comment:2 Changed 4 years ago by
Cc: | arthuredelstein added |
---|
comment:3 Changed 4 years ago by
Cc: | brade mcs added |
---|
comment:4 Changed 4 years ago by
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 3 years ago by
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 2 years ago by
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 2 years ago by
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 follow-ups: 9 10 Changed 2 years ago by
Keywords: | tbb-security added |
---|---|
Summary: | Block Mixed Content on .onion Addresses → Block 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 Changed 2 years ago by
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 Changed 2 years ago by
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:12 Changed 20 months ago by
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 6 months ago by
Parent ID: | → #21952 |
---|
comment:14 Changed 4 months ago by
Cc: | tom added |
---|---|
Keywords: | TorBrowserTeam201810 added |
Priority: | Medium → High |
Summary: | Block non .onion content on .onion addresses → Block non .onion content on .onion addresses (mixed content blocking) |
comment:15 Changed 4 months ago by
.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.
comment:16 Changed 4 months ago by
Keywords: | TorBrowserTeam201811 added; TorBrowserTeam201810 removed |
---|
Moving our tickets to November.
comment:17 Changed 3 months ago by
Keywords: | TorBrowserTeam201812 added; TorBrowserTeam201811 removed |
---|
Moving our tickets to December.
comment:18 Changed 6 weeks ago by
Keywords: | TorBrowserTeam201901 added; TorBrowserTeam201812 removed |
---|
Moving tickets to Jan 2019.
comment:19 Changed 2 weeks ago by
Keywords: | TorBrowserTeam201902 added; TorBrowserTeam201901 removed |
---|
Moving tickets to February.
s/from being loaded in TBB/from being loaded for .onion addresses in TBB/g