Impacts of Encryption Everywhere (any solution?)

Leo Bicknell bicknell at ufp.org
Tue May 29 14:44:13 UTC 2018


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 at ufp.org
PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 793 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20180529/f818897c/attachment.sig>


More information about the NANOG mailing list