To solve this problem in the context of HTTP proxying you'd need more than just a way to refer to arbitrary content (which, honestly, doesn't need to be a crypto hash, it just needs to be an arbitrary identifier unique to the user and session). First, consider why we use HTTPS (in an overly-simplistic view):
1. Integrity
You want to make sure the data you're getting is from the source you expect, and that it hasn't been compromised. HTTPS does this with PKI by enabling you to verify the destination host is really who they say they are (Certificates) and to only trade data with them. Anybody who doesn't pass the signed-certificate-verifying test, doesn't get to give us data.
2. Secrecy
We don't want anyone else knowing what our data is because it may contain sensitive information. Once we verify the identity of the sender, each session is independently encrypted to prevent later decoding.
So what would we need to cache our content and retain its integrity and secrecy? The simplest thing would be encrypted blobs of data signed by our destination host's certificate. A proxy could keep data for a set amount of time, perhaps each piece of data encapsulated in a different session. All our client would need to do was connect once and initiate a session, and the server could deliver a copy of the encrypted/signed payload to the proxy.
With some magic flags in the new protocol our client could be instructed that the server allows the client to make a 'proxy request' to the destination for content. This request could be made in such a way that it allows a proxy to intercept this request from the client (which could be plaintext actually), get the encrypted chunk from the destination (which could also be done plaintext), and the proxy could deliver the chunk to the client, similar to what it does now with HTTP. Since the chunk was signed and encrypted by the destination, the proxy can't do anything but deliver the exact copy the destination gave it. Our client receives the data it wants from the proxy and verifies it's from the destination, unpacks it and loads it.
1. Client requests content from server (HTTPS)
2. Server replies back that server allows proxy requests (HTTPS)
3. Client sends request again with proxy-request flags and arbitrary content identifier & session identifier (HTTP)
4. Proxy receives request, gets content from server (HTTP)
5. Proxy replies to client delivering content from server (HTTP)
6. Client verifies content was signed by server
Of course this would be limited in its usefulness compared to plaintext caching; it would be user and session specific, so only lots of requests by the same client in a session would benefit from this. But it would theoretically save on bulk requests of encrypted content while preserving integrity and secrecy.