For what it's worth, http://w3c.github.io/webappsec/specs/subresourceintegrity/ is actively being worked on, and implementations in Chrome and Firefox are on the way in the near future. The polyfill issue is handled in that proposal as described in <http://w3c.github.io/webappsec/specs/subresourceintegrity/#f...: Your "src" attribute points to a server you control, but your "noncanonical-src" points to the CDN, and a browser that knows about "noncanonical-src" is also supposed to know about the "integrity" attribute and ensure that the content it gets hashes to what you expect.
Just as a further set of links regarding subresource integrity in Chromium, you can try it today on Canary Chrome behind the "Enable experimental Web Platform features" flag. You can follow the feature's development here: https://code.google.com/p/chromium/issues/detail?id=355467
I am not very familiar with hashing algorithms, but why isn't the length of the content specified in the `integrity` attribute? Wouldn't it help avoid length extension attacks?
A good digest alorithm should already handle length extension attacks with just the digest. HMAC algorithms handle that as far as I know, and I think modern hashes don't suffer from the length extension problem in the first place.
In any case, length extension attacks apply to (hashes misused as) keyed message authentication codes - a scenario where you give a message and its authenticator to a server knowing the key, and it checks whether someone knowing the key generated them. The attacks let you, given a message and its authenticator, calculate the authenticator for a different message. However, in this case, the hash cannot be tampered with; breaking integrity would require finding a different message with the same hash, which is a straight-up collision, considered to totally break a hash algorithm. At the moment, the only commonly used hash algorithm with known collisions is MD5; SHA-1 will probably follow in the next several years.
I perhaps used the wrong term. I meant straight-up collision with a modified length.
The known MD5 collision attack needs to modify the length of the message; finding a collision with the same length is extremely difficult. It would be reasonable to assume that attacks on other hashing algorithms would suffer the same constraint.
Wouldn't having the length specified in the integrity attribute help reduce chances of a future attack? The cost of specifying the length is negligible; about 12 bytes for a base-64 encoded 64-bit unsigned int.
You're essentially using the length as a(n extremely weak) secondary hash in that case. That might be sufficient to disable one known MD5 exploit, but if you're worried about vulnerabilities in your primary hash algorithm it would make more sense to use another real hash algorithm for your backup.
Thanks for the answer. I am really not familiar with the mathematics of hash algorithms and I ask just to learn.
Why is length essentially a weak hash? Isn't it an additional constraint that works orthogonal to the hash? It serves to restrict the space of collisions and hence directly reduces the exploit surface. Moreover, the length can be independently verified of the hash function, and its space & time complexity is negligible.
It's utterly trivial to match by itself. Adding length to a real hash is a mild difficulty increase. Adding a second hash is a massive difficulty increase.
> Isn't it an additional constraint that works orthogonal to the hash?
Yes. But so is a second hash.
> It serves to restrict the space of collisions and hence directly reduces the exploit surface.
Very inefficiently.
> Moreover, the length can be independently verified of the hash function, and its space & time complexity is negligible.
A second hash is independent of the first hash too. Hashing a second time compared to downloading and hashing the first time is pretty close to negligible.
