HTTPS certainly is not cache friendly. Is there an easy way to extend https to handle heavy cache use cases (to improve caching behavior across clients)?
For example:
Assume: file.data exists and is already encrypted with enckey=K, deckey=D, algo=X, etc
<- transfer of file.data (from cache) without further encryption but still in the scope of the outer https. The response would carry appropriate headers to indicate where the "plain" data starts and how long it is. At this point, you can use a packet filter and see the encrypted body of the file but not the https headers or anything else.
- Client recognizes this valid https session response but takes the inner sections without further decryption. The inner section would need to be marked (as in a multi-part section), and https response headers would need to indicate which byte range of the body should be read as-is and decoded with key deckey.
Again, I am hoping for some sort of extension to https to make it cache friendly.
Advantages: File is encrypted once (or as needed if policy requires it) and caching proxies can serve the file without re-encryption per user session response.
Disadvantage: Likely need to change http/s in some way to wrap and mark plain data.
This adds an integrity (checksum) attribute to a resource and I think that is fine. It can also be used via https or http but they indicate http is not safe (3.3.2).
The problem is that the data is going to be encrypted per user https session and this adds a load to the server (say if you are streaming a movie or downloading a large file). With https the data has to be encrypted per user so there really is no caching on the output. Sure, the original data file can be in a cache, but what goes out (payload sans header) is the encrypted-per-user byte set. Unlike http where the payload across all users is the same.
This seems to be the feature we need if browsers would support it.
I can see how this would cause issues in the "presentation", i.e., how could a browser warn a user that for this session your data is not encrypted (given expectations for pages served via https have already been defaulted to 'you are at the right site + data transfers are encrypted').
I thought that only protected against modification in transit though. Often, what you really want is to verify the content is what the original source intended it to be, rather than what the server sent. In that case, you want a mechanism for attaching a GPG-like signature to the content. It doesn't matter then if the content is delivered via mirrors, caches and HTTP. This would be especially useful for things like jQuery mirrors, where a compromise of the server would affect many sites at once.
For example:
Assume: file.data exists and is already encrypted with enckey=K, deckey=D, algo=X, etc
Client -> https://www.example.com/file.data <-> <protocol between server/client to get deckey, algo, etc needed to decrypt>
<- transfer of file.data (from cache) without further encryption but still in the scope of the outer https. The response would carry appropriate headers to indicate where the "plain" data starts and how long it is. At this point, you can use a packet filter and see the encrypted body of the file but not the https headers or anything else.
- Client recognizes this valid https session response but takes the inner sections without further decryption. The inner section would need to be marked (as in a multi-part section), and https response headers would need to indicate which byte range of the body should be read as-is and decoded with key deckey.
Again, I am hoping for some sort of extension to https to make it cache friendly.
Advantages: File is encrypted once (or as needed if policy requires it) and caching proxies can serve the file without re-encryption per user session response.
Disadvantage: Likely need to change http/s in some way to wrap and mark plain data.