[tor-dev] HTTPS Everywhere harmful

[yan]

To be clear, Tim is talking about "HTTPS Everywhere" in general, not the 
browser extension!

On 4/24/15 8:05 PM, Mike Perry wrote:
> Maciej Soltysiak:
>> http://www.w3.org/DesignIssues/Security-NotTheS.html
>
> 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 
the spec:

1. If a subresource is successfully upgraded on foo.com, remember this 
and automatically upgrade subresources with the same host on bar.com in 
the future.
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.
>

Forgiven. :)

>
>
> ** 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
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>