InformAction Forums

A while ago I was reading some blog comments discussing restrictions on mixed secure/insecure content, and someone made an interesting suggestion: resources such as images don't usually need confidentiality, just integrity. It would be useful to have some kind of intermediate protocol between HTTP and HTTPS, where resources are signed (to prevent tampering), but not encrypted, and can therefore be cached just like HTTP.

Does anyone see any obvious pitfalls with that idea?

Um, that it's easily MITM-able? An attacker could strip the signature, modify the content, sign it with their own or a hacked key, and serve it to you. Or just serve you their own content entirely, with some valid signature.
The browser would have to know in advance who is "supposed" to sign a resource, how can it?

And for those of us with data usage limits, what would be the bandwidth usage of that vs just encrypting the connection?

I think the idea is that the PKI infrastructure would be the same as regular TLS. You contact a server and get its certificate, verify that, then make a plaintext connection and expect the response to be signed with the key that matches the certificate. So there shouldn't be any more MITM issues than normal.

I don't think bandwidth would be drastically different, although you might save some roundtrips on the TLS handshake. The biggest difference would be that the response would be cacheable - which is good in general, and excellent for content delivery networks (which would be able to deliver pre-signed content without needing to possess the key). You'd also be able to compress without running into attacks like CRIME and BREACH.

Cookie handling would have to be considered, of course; I think the connection should be treated as insecure for that purpose (so cookies marked Secure would not be sent). If a resource is actually tied to the user session and not exposed to the public, then it should be served over full TLS.

Thrawn wrote:I think the idea is that the PKI infrastructure would be the same as regular TLS. You contact a server and get its certificate, verify that, then make a plaintext connection and expect the response to be signed with the key that matches the certificate.

OK, makes sense.

Thrawn wrote:The biggest difference would be that the response would be cacheable - which is good in general, and excellent for content delivery networks (which would be able to deliver pre-signed content without needing to possess the key).

How so? Someone would need the key for the CDN's SSL/TLS certificate in order to validly sign the resources on that CDN...

Thrawn wrote:Cookie handling would have to be considered, of course; I think the connection should be treated as insecure for that purpose (so cookies marked Secure would not be sent). If a resource is actually tied to the user session and not exposed to the public, then it should be served over full TLS.

Cookie handling should treat this protocol like the plain HTTP that it is. True that a MITM won't be able to interfere with the traffic, but they can still eavesdrop on everything that's going on, so secure cookies could get just as stolen if sent over this protocol as over regular plain HTTP.

barbaz wrote: How so? Someone would need the key for the CDN's SSL/TLS certificate in order to validly sign the resources on that CDN...

If a CDN is sitting in front of example.com (the way Cloudflare does) and serving its content (with extra caching and worldwide distribution), then the webmaster of example.com can provide the CDN with signed copies of his assets, and never has to hand over his private key.

Ah, I thought you meant like youtube's ytimg.com or something like cloudfront.net.

It's more of a Web Application Firewall scenario, I guess...Cloudflare actually developed their own solution for serving a site without holding the private key (by establishing a secure channel to a client-controlled server that would perform key operations for them), but it would be much simpler with signing.

You will love http://www.w3.org/TR/SRI/, what you propose is precisely the goal of the Subresource Integrity spec.

Yes, that does sound on-target. Thanks for sharing it.

I like the idea of putting the hash in a HTML attribute; that means minimal server-side involvement. The resource load could be a perfectly ordinary HTTP request; the origin could be a CDN that doesn't even know about the spec.

There have been people asking before if NoScript could do something like this, but I think the answer was, it's not as fine-grained as that. Too many resources to be feasible.

And, it's coming in Firefox 43