[CydeWeys]

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.

[superkuh]

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/

[MaxBarraclough]

> It's not an insecure protocol.

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.

[0] https://news.ycombinator.com/item?id=21912817

[superkuh]

>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.

[MaxBarraclough]

> 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.

[wolco]

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.

[MaxBarraclough]

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.

[tialaramex]

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.

[wlll]

> 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?

[CydeWeys]

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.

[wbl]

Unless you think that someone changing the site to be a picture of a gaping hole is a problem.

[pixl97]

It is an insecure protocol.

For example I was reading Hacker News over HTTP and there is this guy named superkuh saying "Hitler was right".

See, with no execution of code one can completely change a message with no authentication.