[Nadya]

Even on a completely static site one could introduce links if they can manipulate content. Create a fake blog post linking to Reddit asking for support, make up a story that a family member fell ill and please donate to your Go Fund Me. Add a cryptocoin miner Javascript. The possibilities are quite endless when you have full control to manipulate a website and an easy way to make a profit off of someone elses' reputation, audience, and laziness.

[dvfjsdhgfv]

The point is, if you're able to manipulate someone else's network traffic, you will be able to modify their DNS traffic as well, and HTTPS won't help with that - you can do all these things you listed and worse.

That's why I cringe whenever I hear the mass propaganda that "HTTPS is secure". It encrypts traffic between the two endpoints, that's it.

[Nadya]

To which browsers will warn the user that the certificate is invalid. Something that, if it was an HTTP site, the user would never be made aware of. The user would then need to ignore the certificate warnings at which point you've done your job by having HTTPS - the rest is up to the user to not ignore security warnings, you can't control that part. Having to generate false certificates at scale for an attack on a number of websites is unlikely - even with the Comodo/DigiNotar blunders of the past. Especially when arguments against these attacks are "nobody would attack me anyway" (you're only making it easier for them to target your visitors by not requiring them to jump through a hoop to get a fake cert).

If they send your user to https://dvfjsdhgfv.com (malicious server) instead of https://dvfjsdhgfv.com (your server) the browser will yell at them about the site being insecure. If they try to use http://dvfjsdhgfv.com your user can see that it isn't secure. They would need a fake certificate for dvfjsdhgfv.com to serve with their malicious version of the site. Arguing against the increased security theoretical attacks exist is a bit misguided - especially when certificates have been revoked or CA's been blacklisted/go out of business for this behavior. It's extremely uncommon - there have only been a handful of instances of it occurring/being caught (an important distinction I'm sure you'd bring up). Because of the difficulty in getting an invalid cert signed by a CA they tend to only go after the big fish (Google/Alibaba/Facebook) and hope they don't get caught quickly.

If fake certificates were as common as having an unlocked bike left in central L.A stolen, the argument would be a lot stronger.

>It encrypts traffic between the two endpoints, that's it.

Which is why it is important. The attack is called "man in the middle" and not "man at the ends". Also "mass propaganda"? Propaganda from who exactly?

I don't understand the refusal to implement https, even on static sites. It takes literally minutes and provides additional security to your readers/users. Refusal to do so is laziness at best and maliciousness at worst. I have a personal file host that receives <5 unique views/day, mostly only by friends, and 99% of all traffic only comes from me - I still took the time to set up TLS [1]. It took me under 10 minutes to implement and it was my first time ever doing so. If you expect to have 0 visitors ever why not just use localhost?

[0] http://techgenix.com/understanding-man-in-the-middle-attacks...

[1] https://kimiwo.aishitei.ru

[dvfjsdhgfv]

> To which browsers will warn the user that the certificate is invalid.

Only if the attacker is very, very stupid. They will happily redirect the request to paypal.com to https://www.xn--paypl-7ve.com (which resolves to https://www.xn--paypl-7ve.com that Let's Encrypt will happily give you a certificate for). The latter looks exactly like paypal.com and has a green padlock - so for an unsuspecting user it's "secure". Only having implemented DoH correctly you could talk about benefits you mentioned, without it it only gives the user a false sense of security. Seriously, people need to be aware of that.

EDIT: HN formats the IRIs so that the above makes little sense, see https://people.csail.mit.edu/ayf/IRI/index.htm for more examples.

[Nadya]

I'm aware of that attack. I'm not sure if you're aware; but the only modern browser it still works against is Firefox.

Chrome patched in in Version 58, Opera patched it not long after. Safari and Edge quickly followed suite (or always displayed the punycode) and I believe IE has always shown punycode. Leaving the only browser with significant user share that's susceptible to this attack being Firefox. At least for users who haven't enabled `network.IDN_show_punycode` in about:config, which is probably most (if not all) users who haven't heard of this attack. Firefox is 6%~ market share - so this attack would fail on 94%~ of your viewers as long as they were paying any attention to the domain. Probably the only way Mozilla will stop dragging their feet in joining everyone else is if someone creates a malicious punycode version of Mozilla with a cert and brings the battle to their doorstep.

This isn't an argument against TLS/HTTPS - this is an argument against Firefox as far as I'm concerned.

[dvfjsdhgfv]

To be clear, I'm not against HTTPS at all. I'm against exaggerating by marketing it as "secure", and on insisting on its benefits in the case of static websites, where the case is very weak.

Even if you don't use punycodes, many users are still vulnerable to another type of attack that Let's Encrypt allows:

https://www.bleepingcomputer.com/news/security/14-766-lets-e...

Even without altering the network traffic many people fall victims to these vicious tricks. The big question here is how much attention do you pay to the address bar.

Nevertheless, the benefits of HTTPS are obvious - there definitely is some protection when the user is sending some data. But for reading a static website, I'm sorry, but I hardly see any benefit. I installed Let's Encrypt on all my websites, but each time I see someone calling it "secure" I really get frustrated.

[Nadya]

Users being ignorant (not dumb, just ignorant) doesn't make it less secure. The user ignoring the security benefits or not knowing where/how to check things or being complacent and simply not checking things doesn't make it less secure. I don't have any good metaphors for it - but the problem is 99.98% on the users and 0.02% on "this could probably be better". But even with giant red warnings saying a site is insecure, an absurd amount of users just ignore the warnings and click past them (these users are also not necessarily dumb... too many legitimate programs and websites have conditioned users to just click past warnings and errors to get things to work).

Every single one of those paypal.com phishing URL's issued could be prevented if users understood how domains work. That's asking an awful lot, I know.

Security, much like any other form of personal safety, is equal parts of following protocol and being educated about the dangers. You can't reasonably protect yourself from something you don't know exists and you won't protect yourself from danger if you don't follow protocol (see also: OSHA, lab safety). If the user's understanding is that "https/green padlock = correct site!" then that's terrible, I agree. If the understanding is "https=secure!" that's better but a bit misguided. A secure connection with a malicious server probably isn't what the user has in mind when thinking "secure". But even this misguided approach is a vast improvement over the alternative of "nothing at all" which is why there has been such a strong push towards it. It's quite literally "something is better than nothing" being applied to the general population of users who will probably never be educated enough to protect themselves properly.

By your last reply I had kinda pieced together that your issue is more with the "https=secure!" generalization and not necessarily an "https isn't any more secure than http" argument.

>The big question here is how much attention do you pay to the address bar.

I check the cert for every site I visit - although if I were to become the victim of a MITM attack using DNS spoofing while in the middle of browsing a site and it was targeted directly at me... I don't check the cert on every page load so would probably be fooled for that small window. I also don't lock my front door when I go get the mail, it's a risk I'm willing to take. I understand this makes me in the 0.001% of "maybe a bit too paranoid" users - if there are even that many of us.

>But for reading a static website, I'm sorry, but I hardly see any benefit.

The benefit is very small but still existent. Simply because the time to implement is in the order of minutes instead of days/weeks - I can't see a good argument against taking the time to implement it. Even if it only ever protects a single user.

[Whitestrake]

> They will happily redirect the request

Doesn't HSTS thwart this? Unless paypal.com were omitted from the preload list, AND you had never browsed to paypal.com before with that browser, it should refuse to connect over HTTP and the attacker won't be able to issue their redirect. It will try HTTPS instead and immediately fail out of certificate validation.

[Nadya]

That wasn't quite what they were talking about. They were talking about IDN Phishing [0] and not http-->https redirection (which is what HSTS is directed towards). But since we're talking about DNS redirection the http:// handshake against the legitimate server never happens, you're only ever visiting a malicious website (which the certificate checks would all fail - except visually in the case of IDN phishing which only works against Firefox users).

[0] https://www.xudongz.com/blog/2017/idn-phishing/

[1] https://www.xn--80ak6aa92e.com/ (this will show the punycode domain on HN, visit it in Firefox it will look just like https://apple.com )

[2] The cert still shows punycode though most users wouldn't check the cert: https://kimiwo.aishitei.ru/i/MMFWtvE5ZgYdHWki.png

[dvfjsdhgfv]

No, HSTS relies on the server sending the relevant header to the web browser. In this scenario you have total control over all servers the user connects to.