On 2017-03-03 01:02, James Roper wrote:
How about you miss-understanding the fact that a hash can only
ever guarantee that two resources are different. A hash can not
guarantee that two resources are the same. A hash do infer a high
probability they are the same but can never guarantee it, such is
the nature of of a hash. A carefully tailored jquery.js that
matches the hash of the "original jquery.js" could be crafted and
contain a hidden payload. Now the browser suddenly injects this
script into all websites that the user visits that use that
particular version of jquery.js which I'd call a extremely serious
security hole. you can't rely on length either as that could also
be padded to match the length. Not to mention that this is also
crossing the CORS threshold (the first instance is from a
different domain than the current page is for example). Accidental
(natural) collision probabilities for sha256/sha384/sha512 is very
low, but intentional ones are higher than accidental ones.
This is completely wrong. No one has *ever* produced an intentional
collision in sha256 or greater.
Huh? When did I ever state that? I have never said that sha256 or higher
having been broken, do not put words/lies in my mouth please. I find
that highly offensive.
I said "could", just ask any cryptographer. It is highly improbable, but
theoretically possible, but fully impractical to attempt (current stages
of quantum computing has not shown any magic bullet yet).
I'm equally concerned with a natural collision, while the probability is
incredibly small the chance is 50/50 (if we imagine all files containing
random data and file lengths, which they don't).
And as to my statement "a hash can only ever guarantee that two
resources are different. A hash can not guarantee that two resources are
the same" again that is true. You can even test this by using small
enough hashes (CRC-4 or something simple) and editing a file and you'll
see that what I say is true.
You know how a these types of hashes works right? They are NOT UNIQUE,
if if you want something unique then those are called "Perfect Hash"
which is not something you want to use for cryptography.
If a hash like sha256 was unique it would be a compression miracle as
you could then just "uncompress" the hash.
Only if the data you hash is the same size as the hash can you perfectly
re-create the data that is hashed. Which is what I proposed with my UUID
suggestion.
Do note that I'm talking about Version 1 UUIDs and not the random
Version 4 ones which re not unique.
In case you missed the headlines, last week Google announced it
created a sha1 collision. That is the first, and only known sha1
collision ever created. This means sha1 is broken, and must not be used.
Now it's unlikely (as in, it's not likely to happen in the history of
a billion universes), but it is possible that at some point in the
history of sha256 that a collision was accidentally created. This
probability is non zero, which is greater than the impossibility of
intentionally creating a collision, hence it is more likely that we
will get an accidental collision than an intentional collision.
Sha1 still has it's uses. Now I haven't checked but sha1 just as md5 are
still ok to use with HMAC. Also it's odd that you say sha1 should not be
used at all. Nothing wrong with using it as a file hash/checksum. With
the number of files and the increase in-data CRC32 is nit that useful
(unless you divide the file in chunks and provide a CRC32 array instead).
A hash is not the right way to do what you want, a UUID and a (or
multiple) trusted shared cache(s) is.
The issue with using a hash is that at some point sha256 could become
deprecated, do the browser start ignoring i then? Should it behave as if
the javascript file had no hash or that it's potentially dangerous now?
Also take note that a UUID can also be made into a valid URI, but I
suggested adding a attribute as that would make older browsers/version
"forward compatible" as the URI till works normally.
And to try and not entirely run you idea into the ground. It's not
detailed enough. By that I mean you would need a way for the webdesigner
to inform the browser that they do not want the scripts hosted on their
site replaced by these from another site. Now requiring a Opt Out is a
pain in the ass, and when security is concerned one such never have to
"Opt Out to get more secure", one should by default be more secure.
Which means that you would need to add another attribute or modify the
integrity one to allow cache sharing.
Now myself I would never do that, even if the hash matches I'd never
feel comfortable running a script originating from some other site in
the page I'm delivering to my visitor.
I would not actually want the browser to even cache my script and
provide that to other sites pages.
I might however feel comfortable adding a UUID and let the browser fetch
that script from it's local cache or from a trusted cloud cache.
If you are going to use the integrity attribute for authentication then
you also need to add a method of revocation so that if for example the
hashing used is deemed weak/compromised (due to say a so far
undiscovered design flaw), then only the browsers that are up to date
will be able to consider those hashes unsafe. Older browsers will be
clueless and all of a sudden some porn site includes manipulated
banking.js and whenever a older browser with a stale cache encounter
that it replaces that and the next time the user goes to their bank the
browser will happily use a trojan script instead. Te end result is that
bank's etc will not use the integrity attribute or they will server a
different versioned script for each visit/page load which kinda nukes
caching in general.
Remember, you did not specify a optin/optout for the shared integrity
based caching.
You might say that this is all theoretical, but you yourself proclaimed
sha1 is no longer safe. Imagine if the most popular version of jquery
became a trojan, we're talking tens of thousands of very high profile
sites possible victims of cache poisoning.
Now I'm not saying the integrity attribute is useless, for CDNs it's
pretty nice. It ensures that when your site uses say awesomescript12.js
that is awesomescript12.js and not a misnamed awesomescript10.js or
worse notsoawesomescript4.js
But, at this point you already trust the CDN (why else would you use
them right?)
Another thing the integrity hash is great for is to reduce the chance of
a damaged script being loaded (sha512 has way more bits than CRC32 for
example).
And if I was to let a webpage fetch a script from a CDN I would probably
use the integrity attribute, but that is because I trust that CDN.
If a browser just caches the first of whatever it encounter and then use
that for all subsequent requests for that script then I want no part of
that, it's a security boundary I'm not willing to cross, hash or no
hash. So a opt-in would be essential on this.
Now many sites have there own CDN I assume these are your focus. But
many use global ones (sometimes provided directly/indirectly with the
blessing of the developers of a script). I don't see this a a major
caching issue. The main issue is multiple versions of a script. Many
scripts are not always that backward compatible, I have seen cases where
there are 3-4 versions of the same script on the same site. A shared
browser cache may help with that if those are the unedited official
scripts of jquery but usually they may not be. They may also be run
through a minifer or similar or they have been minified but not with the
same settings as the official one.
This is why I stress that a UUID based idea is better in the whole. As
the focus would be on the versions/APIs/interoperability instead. I.e.
v1.1 and v1.2 have the exact same calls just some bug fixes? They can
both be given the same UUID and the CDN or trusted cache will provide
v1.2 all the time.
PS! Not trying to sound like an ass here but could you trim the email
next time? While I do enjoy hearing my own voice/reading my own text as
much as the next person there is no need to quote the whole thing. Also
why did you CC me a full quote of my email but did not write anything
yourself, did you hit reply by accident or is there a bug in the email
system somewhere?
Which brings me to a nitpick of mine, if you reply to the list then
there is no need to also CC me. If' I'm posting to the list then I'm
also reading the list, I'd rather not have multiple email copies in my
inbox. Hit the "Reply to list" button instead of "Reply to all" next
time (these options depends on your email client).
--
Roger Hågensen,
Freelancer, Norway.
