5 ms·
Having a valid ssl cert does not stop a website from serving malware.
by pbalau 6y ago
Having a valid ssl cert does not stop a website from serving malware.
- yjftsjthsd-h 6y agoNo, but it stops third parties from adding it
- pbalau 6y agoNo it doesn't.
- netizen-9748 6y agoWould the third part not need to serve a valid cert to do this? I'd like to hear if it is easier or harder to do with http vs https
- yjftsjthsd-h 6y agoYes, you'd need either a valid cert, or for the user to click through the big scary warning to accept the invalid (or self-signed) cert, either of which raises the bar way above unencrypted HTTP, where this attack is trivial (ex. https://en.wikipedia.org/wiki/Firesheep https://en.wikipedia.org/wiki/Firesheep and https://stopthecap.com/2013/04/03/isp-crams-its-own-ads-all-over-your-capped-internet-connection-banners-block-your-view/ https://stopthecap.com/2013/04/03/isp-crams-its-own-ads-all-... )
- yjftsjthsd-h 6y agoOkay, 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?
- superkuh 6y agoAttack 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.
- yjftsjthsd-h 6y agoYeah, 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". [0] https://letsencrypt.org/2020/02/19/multi-perspective-validation.html https://letsencrypt.org/2020/02/19/multi-perspective-validat... [1] http://codebutler.github.io/firesheep/ http://codebutler.github.io/firesheep/
- superkuh 6y ago1. 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.
- yjftsjthsd-h 6y agoMy 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.