4 ms·

There is an enormous campaign, both by companies and security enthusiasts, which promotes the view that serving static content over HTTP should, as the article

There is an enormous campaign, both by companies and security enthusiasts, which promotes the view that serving static content over HTTP should, as the article says, "die".

albinowax_ 1y ago
This research is not about HTTP vs HTTPS - it’s about HTTP/1.1 vs HTTP/2+, specifically for upstream connections. Anyway this will be clear once it’s published.
altairprime 1y ago
It took them twenty years to remove ftp support, and the chances of squid proxy removing http/1.1 support are virtually nil. The rhetoric is unsurprising, though still disappointingly short-sighted, given the unwillingness of for-profit enterprises to invest in architectural advances such as HTTP/2 or QUIC/3. Much more likely is that https:// https:// URLs served by http/1.1 will be marked as Insecure in browsers, leading to autofill and form submission warnings, and eventually trigger security interstitials as badcerts do today; that is an immediately plausible case that can be argued and defended and scheduled for the future now by browsers (and by e.g. PCI compliance specs!), especially as attacks on http/1.1 improve. The vast majority of sites would then, once pressured, either upgrade to h1+ https:// https:// with Alt-Svc to maintain basic compatibility, rather than downgrade to h1-only http:// http://, resolving the majority of threats offered by downgrade attacks without having to cut it off altogether. Perhaps someday it will be more difficult to access http/1.1 resources in a browser, but ftp (and gopher!) resources still exist to this day and remain accessible using tools for that purpose. Regardless, I encourage donating to Archive.org, and also ensuring that any static content you visit over http:// http:// is mirrored by them. ps. Let’s Encrypt would have to update http-01 to work with h2+ over 443/tcp,udp by specifying that it performs no validation whatsoever of the server’s existing TLS certificate properties, in order to continue functioning as intended in a post-h1 environment. They would likely specify that as http-02 and require h2+, bind https:// https:// verification URLs to it, and eventually deprecate http-01. They could do this at any time - perhaps they will!

There is an enormous campaign, both by companies and security enthusiasts, which promotes the view that serving static content over HTTP should, as the article says, "die".

albinowax_ 1y ago

This research is not about HTTP vs HTTPS - it’s about HTTP/1.1 vs HTTP/2+, specifically for upstream connections. Anyway this will be clear once it’s published.

altairprime 1y ago

It took them twenty years to remove ftp support, and the chances of squid proxy removing http/1.1 support are virtually nil. The rhetoric is unsurprising, though still disappointingly short-sighted, given the unwillingness of for-profit enterprises to invest in architectural advances such as HTTP/2 or QUIC/3. Much more likely is that https:// https:// URLs served by http/1.1 will be marked as Insecure in browsers, leading to autofill and form submission warnings, and eventually trigger security interstitials as badcerts do today; that is an immediately plausible case that can be argued and defended and scheduled for the future now by browsers (and by e.g. PCI compliance specs!), especially as attacks on http/1.1 improve. The vast majority of sites would then, once pressured, either upgrade to h1+ https:// https:// with Alt-Svc to maintain basic compatibility, rather than downgrade to h1-only http:// http://, resolving the majority of threats offered by downgrade attacks without having to cut it off altogether. Perhaps someday it will be more difficult to access http/1.1 resources in a browser, but ftp (and gopher!) resources still exist to this day and remain accessible using tools for that purpose. Regardless, I encourage donating to Archive.org, and also ensuring that any static content you visit over http:// http:// is mirrored by them. ps. Let’s Encrypt would have to update http-01 to work with h2+ over 443/tcp,udp by specifying that it performs no validation whatsoever of the server’s existing TLS certificate properties, in order to continue functioning as intended in a post-h1 environment. They would likely specify that as http-02 and require h2+, bind https:// https:// verification URLs to it, and eventually deprecate http-01. They could do this at any time - perhaps they will!