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**. 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
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:
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Fri, Apr 24, 2015 at 08:05:43PM -0700, Mike Perry wrote:
** 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.
But just as, as you point out, it is useful for the linker to be able to say "hard fail if you don't have an _authenticated_ secure channel" ("https://"), even in a world where plain "http://" means "an encrypted but possibly unauthenticated channel", the linker may also want to say things like "hard fail unless the cert is issued by Foo" or "hard fail unless the cert/pubkey has hash abc123" or "hard fail unless it's an EV cert" (for whatever that's worth). Right now, that "s" means "give an annoying warning if there's not a blessed cert, and hard fail if there's no encryption at all", which is rarely the semantics people actually intend. With HTTP/2 and Let's Encrypt and Chrome suggesting that the annoying warning will start appearing for all unencrypted sites in the medium future, automated DV certs should soon be the minimum "you have to be this tall to play on this Internet" (mumble servers without names mumble), but it may still be useful to distinguish security levels above the minimum in some cases. - Ian
participants (4)
-
Ian Goldberg -
Maciej Soltysiak -
Mike Perry -
yan