[tor-dev] HTTPS Everywhere harmful

[Mike Perry]

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

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/).

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.


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150424/80c192c8/attachment.sig>