In a message written on Mon, May 28, 2018 at 09:23:09AM -0500, Mike Hammett wrote:
However, this could be wildly improved with caching ala squid or something similar. The problem is that encrypted content is difficult to impossible for your average Joe to cache. The rewards for implementing caching are greatly mitigated and people like this must suffer a worse Internet experience because of some ideological high horse in a far-off land.
Some things certainly do need to be encrypted, but encrypting everything means people with limited Internet access get worse performance OR mechanisms have to be out in place to break ALL encryption, this compromising security and privacy when it's really needed.
I'm going to take this question head on, as opposed to the many tangents in this thread. The Internet lived in the world you described, and a lot of people learned a lot of things along the way. Perhaps the most important lessons: - Users cannot be trusted to check if there is a "secure" indicator before sending sensitive information. - Users cannot tell the difference between two "secure" sites, one of which is a phishing site that just happens to have a certificate. - There is no algorithmic way to determine if mixed mode content is "safe". - Web site operators seem incapable of maintaining white lists of safe mixed mode content. - Mixed mode content is not safe due to browser bugs. - Once users have been trained that it's ok to send content via some insecure channels, it's nearly impossible to untrain them of it later. Basically, while you presented the "pro" side of unencrypted content (being able to cache), you didn't present any of the negative side. I have to wonder if the villagers were given a choice of faster internet, where 5% of them had their bank account cleaned out, and 5% had their identity stolen, or slower, secure internet which they would choose? Want a technological solution? It exists! Signed content. I've always been baffled why there isn't a way to serve up HTTP signed (but not encrypted) content. I'd imagine the way it would work is: 1) Initial connection had to be HTTPS encrypted to create a full encrypted channel. 2) Additional assets could then be downloaded as HTTPS, or as HTTP + Signature. Signature must be from the same certificate as the HTTPS data. The http+signature data could then be cashed just fine, and stored in the clear. The web site could determine what to serve up that way to maintain security. All POST commands would have to be HTTPS (data from client to server), and of course sensitive information would be returned HTTPS only. Why doesn't that exist? -- Leo Bicknell - bicknell@ufp.org PGP keys at http://www.ufp.org/~bicknell/