Comment by dragonwriter
11 years ago
> This case should be eliminated. We need to stop publishing stuff over HTTP. Period.
HTTP is perfectly fine for information originating on and never leaving controlled, trusted, internal networks, and there is no reason to pay the overhead for HTTPS for those cases.
There's other use cases where its probably not worth the (small) overhead for HTTPS.
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.
1 reply →
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
There's also significant overhead to the community at large in having both HTTP and HTTPS be reasonable systems to use, and requiring that HTTP not show loud warnings. There's also a risk to your organization that you're teaching users that some HTTP sites are reasonable, which is a hard judgment for them to make. I can put up an external website which claims to be internal, and probably get some passwords or confidential information that way.
If you use HTTPS everywhere, there is a tiny bit (but usually negligible) runtime overhead, a bit of process overhead (which this announcement is pushing much closer to zero), and significant simplicity in many other axes. I think the tradeoff leans towards publishing internal sites with globally-valid HTTPS certificates.