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

[legind]

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.

[legind]

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

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

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

[legind]

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.

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

[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?

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.

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

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

[gk]

Resolved #21713 as duplicate.

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

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

[gk]

Moving our tickets to November.

[gk]

Moving our tickets to December.

[gk]

Moving tickets to Jan 2019.

[gk]

Moving tickets to February.

[gk]

Moving remaining tickets to March.

[gk]

Closed #26625 as duplicate.

[gk]

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