Not to mention many non-https sites have zero reason to be. A plain HTML portfolio site, for example, should not be flagged with a scary "insecure" logo because its content is not encrypted.
We need to protect the integrity of the information so that kit's not abused to serve malware or pages that exploit zero-day vulnerabilities to the end-user when they browse on an insecure network (which, if Snowden's publications are anything to go by, is every network).
HTTPS is not just confidentiality - security is confidentiality, integrity and availability.
HTTPS ensures the data isn't tampered during transport, but it doesn't ensure the integrity of the data itself. That's why there's things like Subresource Integrity (which doesn't apply to top-level resources like HTML).
However, there's no way to ensure the files we download are created by who they say they are. A domain for example can change hands and existing links say on HN can be loaded with unexpected, potentially malicious, content. Same for hacked servers.
IMO we need some form standard page signing to enforce actual integrity of information, not just transport. I made a proof-of-concept Web Extension to show how that might be possible using PGP [1]. Of course PGP has its own issues but it's just an experiment.
Okay, I'll bite. Let's say I'm loading a page over https, and you control the network but not the server (mitm). How exactly are you adding content to the page?
Attack the client's (or some sub-population of clients at some ISP) DNS resolver and point it towards other IPs that serve up a clone of the web interface with their own LE signed HTTPS but now with some new content too.
This is the same argument technique being used when people say, "Oh, but you can MITM HTTP!" Yes, a target attack of something beyond your webserver is bad. But it applies to HTTP and HTTPS.
Yeah, no; there's a world of difference between subverting the uplink for a single client (all that you need for altering unencrypted traffic) and subverting the network for your target/victim and multiple LE servers that are designed to resist this attack [0]. If your proposed attack worked, it would be font-page news because it'd undermine the security of ex. gmail/banks. HTTPS moves the bar from "bored script kiddies can do this"[1] to "would need a nation-state-level attack to subvert that many networks at once and we'd know about it because that scale of network redirection would not fly under the radar".
1. You 're the one that told me I had control of the client network as per MITM; don't move the goalposts.
2. You're overthinking this. I'm not talking about hijacking established sessions. I'm talking about never letting the authentic session start in the first place.
As soon as the attacker controls the DNS resolver it doesn't matter what security you have in place. The bank and the LE servers and all that can be perfectly secure. But if the client is going to the wrong IPs they never will interact with them. They'll only interact with the perfectly valid HTTPS hosts the attacker sets up.
My initial statement was that HTTPS would prevent a third party from adding malware to a site (implicitly, "as it was loaded"), to which pbalau responded "No it doesn't." Are you suggesting that our attacker can "just" compromise the victim's machine or the hosting server? Because that's true, but HTTPS is effective against network attacks. Deploying HTTPS also won't prevent someone from mugging you IRL, but that doesn't mean that it's not an effective security measure for what it does.
If we're talking about SSL Stripping, then 1. we're back to you needing to control the network, so apparently my goalposts are exactly in the right place, 2. that is at best partially effective (AFAIK, requires the victim to start from a non-HTTPS page, so again, we really want 100% of sites on HTTPS), and 3. that works specifically by getting the victim back onto insecure HTTP, so if you need that then it's proof of the effectiveness of HTTPS.
You're missing your very own point again. You guys are up in arms about potential attacks against the client or the network. Attacks that having nothing to do with the web server.
I am giving examples of how that class of attacks is not mitigated by HTTPS.
I am not talking about SSL stripping. I am talking about not even letting the client talk to the remote host because in the scenario where you MITM you have control of the network.
Assuming you own the DNS server and redirect traffic to a different IP address, how will your fake host provide the CA-verified certificate to the client?
How would you get a LE cert for a domain you don't control? Your proposed attack is thwarted by ACME challenges.
You could redirect the user to a HTTP site, but 1. that can be defeated by adding the domain to hsts preload list 2. This isn't replacing content of HTTPS site, but replacing HTTPS site with a HTTP one.
To actually pull your attack off, you'd need to add your own root certificate to the client device (which means you either tricked the super into doing it and could've as well tricked them into letting you take control of their device anyway, or actually had control of their device - in both cases MITM is pointless at that point), or trick a CA into issuing you a certificate for a domain you don't own/steal a CA's private keys - both of which are things that can easily kill a CA (see DigiNotar, which stopped existing same month the security breach was reported), and therefore obviously aren't easy to pull off.
Certs can be purchased for the price of a coffee or two and are generally trivia to implement — there’s really no reason NOT to upgrade these days, no matter how benign the content. And I say that as someone who still has a non-HTTPS portfolio site :)
