[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] HTTPS Everywhere harmful
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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev