To what end though? Why do you even need to support the insecure protocol? I'm not aware of any widely used browsers that can't do HTTPS. If that's what you're worried about, then you should HSTS preload all of your domains, so that browsers that do support HTTPS will only ever get the HTTPS version, and aren't susceptible to an SSLstrip attack.
It's not an insecure protocol. What is insecure, in every single example I've seen in this thread and in the article, is the bad defaults of browsers executing javascript automatically. Without that terrible design choice, prioritized because of commerce and the desire to change the web of documents into a surveillance operating system, HTTP would be, and is, just fine.
Anyway, to directly answer your question there are browsers that can't do all of HTTPS because of false "security" enhancements being pushed for sites that don't need it like restricting the set of TLS versions that are accepted. ref: https://scotthelme.co.uk/legacy-tls-is-on-the-way-out/
It absolutely is. In what sense is HTTP anything but an insecure protocol?
HTTP does not prevent man-in-the-middle attacks or content-injection. It does not ensure you are connecting to the domain you think you're connecting to. It does not prevent snooping on transmitted data. If it did, there would have been no reason to invent HTTPS.
> Without that terrible design choice, prioritized because of commerce and the desire to change the web of documents into a surveillance operating system, HTTP would be, and is, just fine
Absolutely not. You do not get privacy without HTTPS. You do not block MITM without HTTPS.
It's obvious that HTTPS should be used for online banking and for software updates, but HTTPS should also be used for ordinary websites, to protect your privacy and to prevent content-tampering (by an unscrupulous ISP, or when using insecure Wi-Fi).
People sometimes give Wikipedia as an example of something that doesn't need HTTPS, but these people clearly haven't spent much time thinking about it. A snooping ISP should not be able to tell whether a customer has been looking up an embarrassing medical condition.
I'm reminded of a lengthy HackerNews discussion on this same topic, a month ago [0].
The only compelling arguments against HTTPS are that old smartphones used in developing countries don't support it, and that it prevents HTTP caches like Squid. Browser defaults regarding JavaScript, certainly have nothing to do with it.
>Absolutely not. You do not get privacy without HTTPS.
My sites do because I put all of them up as tor hidden services too.
>Browser defaults regarding JavaScript, certainly have nothing to do with it.
They do. Because everything 'insecure' you just described comes from users running code that might be injected. There's no danger from some entity tricking some person into viewing a simple html page.
> everything 'insecure' you just described comes from users running code that might be injected.
No, I gave 3 different examples where JavaScript is irrelevant but HTTPS is still important.
* Online banking (HTTPS prevents snooping)
* Software updates (HTTPS ensures you get untouched data)
* Browsing a Wikipedia page about a medical condition (HTTPS prevents snooping)
> There's no danger from some entity tricking some person into viewing a simple html page.
That's not true. Not all browser security flaws involve JavaScript.
Browser flaws aside, it's still important to prevent an attacker from modifying the page to perform a phishing attack (tricking a non-technical person into visiting faceb00k.com, and then capturing their password). Less seriously, HTTPS blocks injection of spam into your page by an ISP.
HTTPS is also important to prevent profiling by unscrupulous ISPs.
You do realize your isp knows you visited a domain like wikipedia. The only thing private is the page content which can be gotten by visiting your request.
That isn't news to me, and it does not undermine my point. Again: A snooping ISP should not be able to tell whether a customer has been looking up an embarrassing medical condition.
Someone going on Wikipedia tells you relatively little. Knowing which specific pages they've been reading, tells you a great deal more.
HTTPS goes a long way to preventing a snooping ISP from telling which page you visited. A truly committed ISP might still be able to infer it from the traffic patterns, but they'll have a much harder time than with plaintext HTTP.
With a very large property like Wikipedia it's probably unavoidable that it'll be possible to determine that you contacted Wikimedia, even just from IP addresses. If that's too much you'll need TOR.
But far from "the only thing" being page content, almost everything is "kept private" with HTTPS, the request itself including any body provided, and the response to that request.
So while "visiting your request" might well get them their own copy of the content of a particular encyclopedia page you looked at, they're stuck with not knowing what that request was.
And eSNI plus DPRIVE is the final dash to a finish where the ISP doesn't even know which Wikimedia host you visited, assuming they all share the same IP ranges. Italian Wikipedia? Simple English? Wiktionary? Wikivoyage? That's suddenly an ocean of possibilities.
> It's not an insecure protocol. What is insecure, in every single example I've seen in this thread and in the article, is the bad defaults of browsers executing javascript automatically. Without that terrible design choice, prioritized because of commerce and the desire to change the web of documents into a surveillance operating system, HTTP would be, and is, just fine.
OK, so what you're saying here is that HTTP is insecure as long as the browser distributors continue to do something that (you say) is insecure.
Well, I've got news for you. The browser distributors are going to continue to do this.
Also, do you really think it's within reason to expect users to examine all the Javascript that is loaded on a page looking for malicious code before clicking some sort of button to run it?
I mean, it absolutely is an insecure protocol. It has no security whatsoever built into it, and anyone can inspect or modify the contents of the connection with impunity. The only way it's not "insecure" is if that word has no meaning whatsoever.
Other insecure protocols besides HTTP would include Telnet, basic DNS, port 110 POP3, FTP, basic IRC, etc. None of this is controversial or really even arguable.
For the few use cases where the dangers of HTTP can be reasonably consented to by the user, it would make sense to serve the content on a specific subdomain such as:
You can't securely disable http on websites, even if you are not offering it, because it still can be faked by a MITM attacker via proxying it to https. So removing http is pointless for security and only hurts legitimate uses. I guess this is also one of the reasons why "HSTS preload" exists.
That's a good point and a dirty trick, but like you said, it's why we have HSTS and preload lists. I only serve HTTPS (as best I can) because I've never had a case where something truly justified the possibility my system would betray my user. I'm sure I could contrive one, and probably there's someone somewhere who'd agree, but I would rather treat that case existing as a bug to be fixed and not a use case to support. Otherwise you get stuff like the other recent thread [0] with people proudly serving unauthenticated binaries with HTTP for no defensible reason.
Someone in a cousin comment made another, maybe better point: URLs get linked and crawled and cached and having them HTTP just normalizes something that was fine in 1995 but isn't fine in 2020.
It's always possible for someone to get proxied like you said, but it's still safer overall if ever seeing "http://" raises eyebrows. There's another front page thread [1] right now about the normalization of deviance.
I meant the second paragraph about security in general, not TLS [0] encryption, but I can see how that's not clear. HTTPS improves security in part through encryption.
FWIW, one issue with having the plain HTTP site available is that browsers (without the HTTPS Everywhere extension installed) will default to loading the unencrypted site when someone types your domain into their browser. Google is also giving plain HTTP links to your site when it turns up in results it seems.
That makes sense. I wonder if any web servers have smarter decision making for that. Like give a hard 301 to modern browsers, but let older or nonstandard clients get a standard http response.
There are so few browsers that don't support HTTPS that it's not worth worrying about it.
Besides, if the security negotiation is to be done in plaintext, then it's trivial for an attacker to MITM a connection, replace the User-Agent headers, and then trick a server into thinking it should serve content insecurely. This is a huge gaping attack vector. It's better to just always serve securely.