[Bug 11402] One problem of todays JavaScript libraries is, that the client has to download the same library over and over again, while visiting multiple sites. One could use services like Google Libraries API for a central location, but that introduces new points of

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11402

Kornel Lesinski <kornel@geekhood.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kornel@geekhood.net

--- Comment #2 from Kornel Lesinski <kornel@geekhood.net> 2010-11-24 23:18:00 UTC ---
(In reply to comment #1)
> This can potentially be mitigated by specifying particular hash algorithms that
> can be used, so the browser can verify that the script actually hashes to the
> provided value before committing it to the cache, but that still leaves us at
> the mercy of hashing algorithms being strong.

Obviously browsers would have to verify the hash and only share verified files.

> but that still leaves us at the mercy of hashing algorithms being strong.

Security of HTTPS is at mercy of hashing algorithms too.

> Had this been specified before we knew that MD5 was broken, for example, the attack described above would now be completely doable even *with* hash verification.

I disagree. Even today attack you've described is not know to be possible.

Replacing library that has already been signed by another website requires
preimage attack, and not merely a collision. It's possible to generate MD5
collisions, but there is no known preimage attack yet.

If you only have a collision, you first need to convince attacked site to use
specially crafted JavaScript file with unescaped, unmodified binary blob that
you know collision for.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 24 November 2010 23:18:03 UTC