[salutonmundo]

The worst web browser I have access to is the "experimental" one on a Kindle 4. Most web pages that one might want to visit will not load in this web browser—because it does not support modern versions of TLS.

For the reasons mentioned in this article—it's probably a good idea to keep plain HTTP access available on your websites.

[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

[kstrauser]

Eh, 98.24% of all users worldwide can use TLS 1.2: https://caniuse.com/?search=tls%201.2

I'm not willing to make security exceptions to support devices from 2011. "HTTPS by default" lifts all boats: people who would MITM your users can't tell if they're reading your nice blog or a critique of their local government, and that's a good thing.

[sundarurfriend]

> Eh, 98.24% of all users worldwide can use TLS 1.2: https://caniuse.com/?search=tls%201.2

That's 98.24% of users captured by CanIUse's sources (which seems to be StatCounter). Like most things on the Internet, that's a bubble - the bubble of users who visit statcounter-infested websites, and are able to run their scripts. And the point of the original post is to think outside the bubble. Not in all cases - if you're a B2B service, or selling T-shirts with slogans on them, CanIUse is likely a good enough source to base your choices on. But if you're a government website, or providing critical Covid-19 data for example, it's irresponsible to ignore these long-tail of users who fall outside expected and easily visible patterns. There's a spectrum between these two kinds of websites, and it's worth thinking about where you fall on that and how many you're comfortable with denying access to your website.

It's a tradeoff between security and accessibility, and we should at least be thoughtful about the implications of our decisions.

[kstrauser]

That's a tough one, because the examples you gave are exactly the ones that I don't want a shady ISP or other interested party to my snooping. I'm not unsympathetic, and genuinely feel bad for the people stuck with truly ancient systems. But at some point, you have to do the analysis of whether it's better to 1) give secure communication to everyone who can have it, or 2) retain insecure communications to support an ever-shrinking pool of people who can't/won't upgrade. I think we're at the point where #1 is more important.

And honestly, I think a lot of people in the second group are there because they bought smartphone in 2007 and won't upgrade because "if it ain't broke, don't fix it". Well, now it's broken. Fix it.

[mtrower]

> That's a tough one, because the examples you gave are exactly the ones that I don't want a shady ISP or other interested party to my snooping.

This sounds like a personal consideration - one you're entitled to, but perhaps shouldn't force on others. Maybe consider Tor?

> ever-shrinking pool of people who can't/won't upgrade.

Are you sure about this? The kind of security you're advocating for here is a moving target. As the pool shrinks on the tail end, surely the head advances...

> Well, now it's broken. Fix it.

Erm, no. The device isn't broken, you are willfully breaking it. I can appreciate your stance, but glib comments like this aren't going to convince anyone in that camp.

[exporectomy]

They can tell what page you're looking at from the host name and request response lengths, though, right? Especially if those are the only two pages on your site.

[SulfurHexaFluri]

With DNS over HTTPS and encrypted SNI, soon the only information you will get is "They accessed a website on amazon/cloudflair"

[_-david-_]

This is not a guarantee. If you have your own public IP it is quite possible to do a reverse ip lookup and get the domain.

[forgotmypw17]

This, a thousand times. No one is going to mitm someone browsing my text blog. On the other hand, https creates many barriers to access, including recent version requirement, time sync, and extra cpu and bandwidth.

[tpxl]

ISPs regularly MITM http websites to inject ads (in the US even).

[forgotmypw17]

It happens. I think I'd rather my site be served with ads, than not at all.

It would be great if we could always automatically choose the right option, but browsers don't do that.

[tpxl]

Ads aren't that much of a problem, but serving cryptominers/phishing websites/viruses is a real issue.

[forgotmypw17]

Do ISPs really do that?

[tpxl]

I haven't heard of it, but other malicious actors surely do.

[cutler]

Not to mention single points of failure like Letsencrypt.