Hacker News Reader

Comment by captncraig | Hacker News Reader

It is interesting that the main argument against staying http is one of social responsibility. Your static site isn't any more susceptible to attacks with http only, but your users are. A bunch of MITM techniques are thwarted by only visiting https sites. Is that your problem as a webmaster? Since LE, I have taken up the position that it is easy, and I prefer https sites as a user, so I really don't have a good reason not to enable https.

Also, an attack on my end users is an attack on my site. Anytime someone wants to see my content and gets something else, that is bad. If I can significantly raise the difficulty of doing that, why wouldn't I?

View on HN

Exactly. As a user I've installed the browser add-on Let's Encript and have the "Encrypt All Sites Eligible" option enabled to block all unencrypted pages. On the odd occassion that I encounter a page that isn't available over HTTPS I'm prompted to choose whether I want to make an exception and allow the site to load for that session. I rarely do though.

Did you not read my comment? I love HTTPs. I make sure all my websites have it available. But I also make sure there's an HTTP site too.

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

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

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

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.

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:

http://insecure.example.com

alongside:

https://www.example.com

Offering HTTP allows MITM attackers to strip HTTPS from visitors who want it. HSTS can help, but the vector still exists.

Optional security is not just an upgrade; it opens up a downgrade path from more secure to less.

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.

Also encryption is neither security nor privacy.

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.

[0] https://news.ycombinator.com/item?id=22136710 [1] https://news.ycombinator.com/item?id=22144330

Pray tell, how did you come to the conclusion that encryption is not security or privacy, and are you an Australian politician?

There is no need for trolling. He's talking about encryption, but calls it security, that's something I have a problem with.

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.

[0] What do you think of that S?

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.

Reply on news.ycombinator.com