HTTPS everywhere would solve this, and the Comcast Javascript injection - I wonder how many more people will deploy things like this before that happens?
Injecting a script into insecure HTTP is just one of many abuses possible by ISP's. Replacing images on the fly is another. Recompressing (degrading) images/video is another. Messing with DNS responses is another, and so on...
A far better working solution is to use a VPN service since when it's configured correctly, it will encrypt all traffic passing through your ISP. Of course, this is really just moving the trust problem, rather than solving it, but at least using a VPN service makes it your decision who to trust. I use Tunnelr.com [2] since by reputation, similar interests, and years of traded emails, I know the people who run it.
What is the FCC good for?
I agree you shouldn't have to do it, but you need to worry about more than just your ISP.
Just assume any unsecured internet connection is actively hostile, and you'll be better off.
1) They can't get away with it 2) That'd slow everything to a crawl, inspecting traffic is expensive at the scales most large providers operate at.
The correct solution is signing the webpage (but not necessarily encrypting it). More technically, that means the server/website would hash the source of the webpage, and then send the webpage, the signed hash, and if needed, the cert it used to sign the hash. Upon receiving both the webpage and the signed hash, the browser would then check to make sure that the signature can be trusted (using a chain of trust the same way we do with certs for https pages already), hash the webpage source it received, and then verify that that hash matches the signed hash it received from the website.
It doesn't matter if any of that is sent in plaintext, because there is no sensitive information, and as long as the hashing algorithm used is strong (ie sha2 family, not md5), then the isp can do fuck all to inject javascript.
(Spoiler: HTTPSEC is not a real thing, it's what we'd had if people who invented DNSSEC, or people like the parent commenter, designed something like TLS).
is the delay/cost of signing versus encrypting data really so huge that it's infeasible to sign dynamic pages?
also, why does each non-existent http page need it's own 404? Wouldn't a static 404 response be just fine?
Now you need a separate IP (expensive) or port (annoying) for each virtual host configured with a different SSL cert. This has to stop, but it will not be easy to fix.
--
1. http://en.wikipedia.org/wiki/Server_Name_Indication#No_suppo...
How would they do this without triggering certificate warnings? Or are you simply saying that everyone ignores certificate warnings?
At ShitISP we care about your cyber safety. In order to prevent viruses and other Bad Things from infecting your computer and the other computers on our network, you will be unable to do some things on the internet until you install our certificate.
Thank you for helping us keep your computer and our network safe!"
Baloney. :-) Or rather, please cite something in the last 5 years showing that the overhead of the symmetric encryption is a significant cost in HTTPS.
sure, the extra rtt is preferable to javascript injection, but signing the webpage is sufficient to prevent javascript injection and it wouldn't add extra rtt delay (aside from fetching a cert in the trust chain, which https can also suffer from in the exact same way).
depending on the algorithms used, on-the-fly signing of dynamic pages might be (read: almost certainly is) more painful than ssl/tls in terms of computation time, but to the user would still be quicker for most cases than the rtt delay added by ssl/tls.
This is inherently error-prone. It gives the developers a big, convenient, and reassuring assumption which the attacker is able to violate. For a complex and evolving endpoint like a web browser, I don't think you'd ever see the end of security bugs. More: https://www.ietf.org/mail-archive/web/tls/current/msg04017.h...
Furthermore, retroactive authentication still doesn't preclude the encryption: https://www.ietf.org/mail-archive/web/tls/current/msg08722.h...
But some low-hanging fruit remains. Improvements to clients and servers that increase TLS session resumption rates would help too.
Google has already provided statistics showing that HTTPS adds a negligible amount of CPU load to servers (and most websites aren't CPU bound anyway).