[three14]

This is exactly the issue. Once some content on the page is not SSL, you can't trust what you're seeing.

Of course, it's easy to fix with an extension to HTML, something like hrefhash="DSKJsdfjsdfs234" so the browser can verify that the referenced resource hasn't been tampered with. Then you can have your non-private data served over HTTP, and cached by the browser and by proxies, and you don't need the extra server side computation of SSL.

[jrockway]

I think browsers should respect HTTP's caching headers, even if the content is served over SSL. If the server says "hey, it's OK to cache this", I don't think the browser should second-guess that.

If you want to be ultra-secure, get an extension for your browser that doesn't cache anything.

[three14]

I agree. But extending HTML to use a hash for verification has additional benefits. One - proxies can see plain HTTP, but they can't cache HTTPS (I think). Two - you can share the same images for the HTTP and HTTPS pages on your site. And three - you can point to a resource (e.g. a Javascript library, a download link, whatever) that you don't control, but you can now trust that the other site won't change it to something malicious.

[three14]

Just thought of another benefit - if the referenced resource is cached, the browser can save an extra HTTP request that it would have sent to check if the referenced data has been modified. Now it knows, given the hash, that it must be unchanged.

[jrockway]

All good points. I like your idea.

I assume most people have frameworks that generate their <script src=...> tags for them, so this shouldn't even require developers to think about it.

[m_eiman]

I had a similar idea a while ago, and put the results of my brainstorming here: http://eiman.tv/misc/http-content-signature.html

The idea is to add a signed hash of the content in the HTTP headers, along with a way of verifying the signature. The point of it all is to make it possible to verify the source and integrity of content served from non-HTTPS servers.

Feedback welcome!

[jbert]

You could specify that you expect the referenced resource to be served with a given ETag. Would that be good enough?

[litewulf]

ETags can be arbitrary, the server can put whatever it wants.

[jbert]

Ah, yes. An attacker could fetch the resource themselves, discover the ETag and serve their malicious resource with the real ETag. Sorry.