Yes, I'm aware of MITM attacks and I'm also aware that fake certificates can be used to MITM even HTTPS sessions.
So I'm not convinced that HTTPS is the solution for that hypothetical attack. Not while untrustworthy certificate authorities are default-enabled on most clients anyway. At best, HTTPS complicates the attack but it doesn't make you immune to it.
A hypothetical MITM attacker can just get a fake certificate from a low-security vendor (ex: Comodo), and serve that to get a nice "trusted" version of the fake webpage. If you control the network, you control the certs that are eventually served to the users.
> At best, HTTPS complicates the attack but it doesn't make you immune to it.
That's literally all security. It isn't binary. It never is. At best, ASLR complicates ROP. At best, salts complicate breaking password hashes. At best, memory safe languages complicate buffer overflow attacks.
One could use your argument to dismiss basically all security. You've chosen zero mitm protection rather than a lot of mitm protection.
If you aren't using https then a network attacker with no preplanning can cause problems. If you are using https then a network attacker needs to get a bogus cert ahead of time. This costs money and time and does not scale well. Security is an economics issue. Making it more expensive to attack people is good.
