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

[dvfjsdhgfv]

> The benefit is very small but still existent.

Well, it's almost nonexistent. To reiterate: if the attacker can only sniff your traffic, they will see what static websites you visit and that's it - whether you use HTTPS or not. On the other hand, if the attacker can modify your network traffic, they will attack you in million ways but using any dynamic website (i.e. requiring some interaction on your part - sending a login etc.). Such an attack on a static website doesn't make any sense when you can do so much damage everywhere else. Can we agree on that? If so, I find the past Google's policy of marking as insecure websites with forms etc. as pretty responsible and I applaud it. Whereas now it looks like blackmail on their part. And I still don't have a feeling I'm protecting any of the users who visit my static websites, I'm just forced to do that because Google rules the Internet now.

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