|
|
|
# Proxy
|
|
|
|
|
|
|
|
The god thing about encryption is that it hides your data from some else's eyes.
|
|
|
|
The bad thing about crypto, is that the eyes of the caching servers are now blind.
|
|
|
|
|
|
|
|
## Content Delivery Networks
|
|
|
|
|
|
|
|
CDN are commercial networks of servers all over the world whose only purpose is to cache and distribute your data as quickly as possible.
|
|
|
|
If that data is encrypted, the CDN will not be able to cache or read anything.
|
|
|
|
|
|
|
|
So the first commercial CDNs asked you your public and private keys, the full X.509 certificate. they basically impersonated you.
|
|
|
|
And you could do nothing but trust them.
|
|
|
|
|
|
|
|
Of course, this is ridiculous, so those same companies modified webservers and TLS libraries so that you could kep everything on _your_ servers, but once the key agreement ended, you had to send them the generated key.
|
|
|
|
And they would effectively Man In The Middle you. You still have your keys, you still have to completely trust them.
|
|
|
|
|
|
|
|
## Secure proxy
|
|
|
|
|
|
|
|
I have a (unfinished) proposal for a secure proxy. The basic idea is:
|
|
|
|
|
|
|
|
* programmers mark each cachable data.
|
|
|
|
* the data is sent and stored (encrypted) in proxies, with a cleartext identifier of the resource stored.
|
|
|
|
* the client gets the data from the proxy, but the key from *your* server.
|
|
|
|
|
|
|
|
The proposal is still unfinished, as I am ironing out the definitions and interactions of explicit and transparent proxies.
|
|
|
|
|
|
|
|
In this CDNs are not strictly considered yet, and I will have to include that, too.
|
|
|
|
|
|
|
|
----
|
|
|
|
|
|
|
|
So a lot more work here, but a protocol-level secure caching proxy/CDN mechanism? Who would not like that?
|
|
|
|
|
|
|
|
----
|
|
|
|
|
