[Nadya]

You're thinking too narrow. Attackers cast wide nets then narrow down the attack to what they've caught in the net. They don't blindly bait individual traps targeting individual users and hope they get a catch.

I'm a hacker at a local Starbucks. I go there every Thursday and use a WiFi Pineapple in my backpack. By naming my WiFi access point similar to the Starbucks' free WiFi I trick a few dozen people a day to connect through my Pineapple instead of the Starbucks provided WiFi. Over a period of a few weeks I log all traffic and devices. I see a number of regulars - many with their own unique browsing habits. I create a few phishing sites to target these unfortunate users who routinely browse at the coffeeshop. Over the course of the next few days I MITM all traffic in the shop and successfully phish a small number of the users. Now imagine a wider net. A collection of compromised networks that don't require my physical presence in a coffee shop and a small team of individuals selecting vulnerable targets based on their browsing patterns.

Neither you nor your users need to be individually targeted by some 3 letter government agency for this attack to work. They only need to be an unfortunate victim and you only need to be too lazy to spend 10-15 minutes setting up a TLS certificate.

This attack is heavily thwarted by sites using TLS certificates. I'd need to get my hands on a number of invalid certificates and even that can be thwarted by HSTS. Now instead of my attack being completely transparent I need to worry about raising suspicion of users browsing https:// sites not getting errors about invalid certificates.

[dvfjsdhgfv]

It all makes good sense in a scenario when the user is sending some data. But for static websites, when they are only visiting a website?

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

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