[tor-dev] HTTPS Everywhere harmful
yan at torproject.org
Sat Apr 25 06:10:11 UTC 2015
To be clear, Tim is talking about "HTTPS Everywhere" in general, not the
On 4/24/15 8:05 PM, Mike Perry wrote:
> Maciej Soltysiak:
> The problem with his argument is that the web (and any protocol, really)
> needs a way to demand a hard guarantee that a request must proceed over
> a secure transport layer. If that layer is not available, the request
> must fail. Anything short of that is opportunistic security, and by
> definition not effective against an active attacker**.
We (the W3C technical architecture group) talked to TBL in person about
this yesterday. To be clear, in TBL's proposal, the HTTPS scheme still
exists and works as-is; it's just HTTP that changes.
> I suspect what Tim Berners-Lee is actually annoyed with is Mixed Content
> Blocking and its tendency to impede upgrade to HTTPS rather than
> encourage it (due to blocking HSTS-upgraded URLs and addon redirect
> HTTPS upgrades as if they were HTTP URLs, rather than allowing them to
> be treated as first-class HTTPS urls). With that, I sympathize. Mixed
> Content Blocking seems to be doing more harm than good in terms of
> encouraging HTTPS transition, and has forced HTTPS-Everywhere to have to
> disable thousands of HTTPS upgrade rules due to site breakage from
> improperly blocked "Mixed Content".
> Unfortunately, it seems that conflating the Mixed Content Blocking issue
> with the HTTPS namespace issue will likely distract the standards
> community long enough to delay development of proper solutions to HTTPS
> migration (like an improved form of HSTS that addresses known issues
> with Mixed Content Blocking: https://w3c.github.io/webappsec/specs/upgrade/).
I think you're right that a *lot* of TBL's frustration is from mixed
content blocking, a sentiment which many of us share. The "Upgrade
Insecure Requests" doc is a good start, but perhaps it could be more
aggressive with upgrades. Two ideas I left for Mike West on my review of
1. If a subresource is successfully upgraded on foo.com, remember this
and automatically upgrade subresources with the same host on bar.com in
2. Make a header that lets a host indicate that it should be upgraded
whenever it's a subresource, regardless of whether the embedding page
has set the CSP upgrade header. Sort of like HSTS if HSTS actually
happened *before* mixed content blocking.
Both of these can obviously be abused to fingerprint users,
unfortunately (in the same way that HSTS can).
> Forgive me if I do my best to avoid this distraction myself.
> ** Sure, there could be a pile of new attribute flags that could be set
> on every HTML resource tag that says the resource must use a "secure
> http:" channel if the parent document happened to load over a secure
> channel, but the net engineering effort of deploying that correctly far
> exceeds the effort needed to mitigate the namespace fragmentation
> issues that Tim Berners-Lee is seemingly so concerned about.
> tor-dev mailing list
> tor-dev at lists.torproject.org
More information about the tor-dev