Comment by IgorPartola
11 years ago
No it is not. I have talked about this on here before, but I don't mind repeating myself:
- Your small blog you publish over HTTP is now opening the door for me, the attacker to mess with any traffic originating from your site. Say you host your resume on your site. I can substitute it with a much less flattering version. Say you host a code snippet. I can add a little obfuscated fork bomb or root kit at the end. Say you have a referral link to Amazon. I send your users to amazom.com, a site that's MitM'ing amazon.com but captures credit card details on the payment form.
- Your internal corporate system is great an all, until you have an unrelated breach and the HTTP site becomes a vector for me to attack your systems. Or worse yet, I learn how to trick your users into believing they are accessing your genuine document store when in fact they are uploading their secret company plans to my very own rogue site. Trust inside the electrified fence is different than on the Internet, but a self-signed cert that your IT sends to every employee is also pretty easy. Conversely, if your organization is so large that it's impractical, just buy a $10 domain and a $8 TLS cert. The "overhead" you speak of does not exist when your server side stops supporting HTTP. FFS, configuring nginx to use TLS/HTTPS takes exactly 3 additional lines of configuration code as compared to an HTTP-only site.
> I can substitute/add/send...
Only if you control any of the infrastructure. If you do, then you can make my life a misery anyway, encrypted or not.
Authenticated and encrypted? That throws a wrench into things.
The authentication provided by the extant PKI system is much weaker than the encryption provided. Any CA can do anything it wants, and browsers trust lots of them.
What's worse is that there has already been at least one case of an ISP rewriting links to Amazon for all of their customers. https://news.ycombinator.com/item?id=6992897