[chrismorgan]

The trouble is that you can’t support HTTP without completely undermining HTTPS.

If you support HTTP at all, you’re damaging the experience for the almost everyone that could have used HTTPS: almost no one will get the HTTPS version unless you deliberately push them over to it, which you will only be able to do after page load by some JavaScript-based user-agent or feature-based sniffing, so now the page loads and then reloads immediately, every time the user visits your site by URL, and you’re causing trouble with search engines, and it’s a regular maintenance burden because no one treads this path so you’ll have to figure out the cut-off points yourself as certificates change, and on top of that it’ll always be subject to a downgrade attack, so now you can’t ever depend on HTTPS.

Remember also that various new features are gated on using a secure context (which roughly means “HTTPS”), like HTTP/2 and HTTP/3. And as for entering passwords or the likes, you’d be opening quite a can of worms if you allow that over cleartext HTTP.

So… yeah, it sounds nice in theory, but I think that it’s just not practical or advisable to retain plain HTTP support. Even supporting TLS < 1.2 or older cipher suites is steadily becoming inadvisable, only to be used on a few sorts of websites. The unfortunate fact of the matter is that you can’t support ancient devices without harming things materially for everything else.

[ndiddy]

> almost no one will get the HTTPS version unless you deliberately push them over to it, which you will only be able to do after page load by some JavaScript-based user-agent or feature-based sniffing, so now the page loads and then reloads immediately, every time the user visits your site by URL

This is false. All you have to do is configure your webserver to only redirect port 80 requests to port 443 if the request includes the "Upgrade-Insecure-Requests" header. Obviously since headers are sent unencrypted this means attackers could easily bypass it, but it's still suitable for personal webpages with no user data. For example, here's how you do it in Apache:

RewriteEngine on

RewriteCond %{HTTP:Upgrade-Insecure-Requests} =1

RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

[chrismorgan]

Ah yes, I had completely forgotten about upgrade-insecure-requests. This mitigates a lot of what I was complaining of, though, as you say, it’s still subject to downgrade attacks at some points. Thanks for the correction.

[superkuh]

The implicit premise here is that your website requires HTTPS only and that a theoretical downgrade attack is enough to justify not having http at all.

Most websites don't even need HTTPS and the complications and sacrifice of autonomy required isn't worth it. Remember, there are no cert authorities that are human people. They are all corporations or institutions. Having to get an incorporated entity's permission to communicate will have dangerous consequences eventually. HTTPS everywhere is done with the best of intentions but it will be the centralizing push that provides juicy targets for government and corporate censorship.

[SulfurHexaFluri]

I'd flip that and say you should only support http if your website absolutely requires it. Unless you absolutely can not avoid supporting old devices you should just redirect http to https.

The privacy of all users is more important than supporting the outdated browser on an ereader.

[GoblinSlayer]

You can't prevent a downgrade attack on server side, the attacker can simply roll full HTTP on top of your server. And browsers already disallow or warn against submitting passwords over HTTP, is there a problem to fix there? Browsers disabled old versions of TLS, you don't harm anyone by supporting them (except for bit rot of that old code). There are also sites with zealous TLS settings, they support only sha384 cypher suites and nothing else at all.

[chrismorgan]

There are multiple layers of protection against HTTPS-to-HTTP downgrade attacks.

① An HSTS policy will protect people that have visited your site within max-age seconds, typically “within the last year”.

② An HSTS policy with preload will protect everyone.

③ HTTPS-only cookies will prevent them being sent over plain HTTP.

⑤ You could depend on various newer functionality that is only available in secure contexts <https://developer.mozilla.org/en-US/docs/Web/Security/Secure...>. For example, the Web Authentication API. (This also raises a good point about using the Web Authentication API for security: authentication is tied to the origin, so http://example.com, https://example.com and https://example.com.evil.example are all different origins and no one will be able to log in over the wrong origin.)

⑥ Any JavaScript code can check the origin and rebel if it’s not what you expect—in fact, I’d say that it’s very common to do this quite incidentally. This protects against a drive-by downgrade attack, increasing the effort required by the attacker who must now reverse-engineer a bit of your code.

[wizzwizz4]

You can: have an “insecure.” version of your site, like people used to have a “secure.” version.

[chrismorgan]

You can’t:

① If it’s on the same domain, it would necessitate weakening the HSTS policy, removing includeSubDomains and preload.

② If it’s on a separate domain, you’re actively training people to do dangerous things and get phished.

③ Pretty much the only way this will ever be used is if you push people to it and ensure that search engines choose it rather than the secure version. (Implicit in this is a significant SEO hassle.) Thus you’re back exactly where you started.

[outsomnia]

HSTS