Google's SHA-1 snuff plan is catching up with Microsoft, Mozilla Google has outlined its approach to deprecating the compromised SHA-1 hash in its Chrome browser. Like the rest of the security world, Google believes the SHA-1 cipher just isn't safe any more. That's a reasonable position, because it's been cracked without enormous effort. Mozilla, Microsoft and Facebook have all therefore …
throw up a warning and allow the user to override if they so desire. How is having a bad encryption scheme any worse than allowing the user to accept a ssl cert manually? (e.g. Man in the middle attack against someone like google or something where they issue a self signed cert for google.com).
This forced breakage of stuff is quite annoying. It should not be forced broken for maybe a decade or more. Give an option to the user, either real time or in the config UI. Last I checked it was seemingly impossible to find an older version of Chrome, and firefox certainly doesn't make it easy to keep multiple versions installed simultaneously(one to access sites that firefox refuses to work with anymore, and one more regular version). Drives me mad to see firefox reject the SSL of some system and really not even give ANY explanation as to why other than
"The page you are trying to view cannot be shown because the authenticity of the received data could not be verified."
Which is the exact same situation as if I was using a self signed cert, except when using a self signed cert firefox(and other browsers) let the user override, of course.
buncha hipsters running the interwebs these days seems like.
Exactly. It's incredibly annoying when you don't know what systems you are dealing with ahead of time or - a real kicker - where it won't let you connect to a management interface in order to fix the problem!
At least make it an option in the advanced configuration screens.
As for an old version of Firefox, I'd recommend using SeaMonkey. Its based on 3.5 with patches added and some of Firefox's new features added in, but still behaves like Firefox from before they started treating version numbers like its an arms race (Which is a rant for a different time).
SHA-1 is not a hash and a cipher, it is only the former.
It is not universally being snuffed out, yet (witness its continued existence in TLS ciphersuites for integrity checking, and as a HMAC).
The issue here is that its use in certificate signatures (sha1WithRSAEncryption) does not offer the required safety margin for something that is effectively a long term credential. Or more precisely it can probably be brute forced for a moderate outlay within its validity period.
It is being used as a signature for a known piece of data (the certificate). The clear-text is known so the risk isn't brute-forcing the value of the hash as in an attack against a credential database.
The risk is that it is seen that there is a greater potential to create a collision - that is two documents with the same hash value. When a CA signs a certificate, basically they are computing a hash of the claims of the certificate and then encrypting that hash with their private key. So if I manager to create two sets of certificate data - one for, say, yourbank.com and another for mysite.com and manage to arrange things so that these two different documents have the same SHA-1 hash. I send off my request to a CA to sign a cert for mysite.com. I can then use that same digital signature to forge a certificate file for yourbank.com and then use that as part of a man in the middle attack.
Yes, unqualified "brute force" is not the proper term here, I mean the (probably) expensive computation involved in attacks similar to that you describe. This will be by definition better than exhaustive brute force, if and when the cat is let out of the bag.
Since the collision attack you describe was used in the 2009 hashclash MD5 attack it is no longer as trivial, CAs must use random serial numbers. My understanding is that further increasing signing-time entropy would have provided continued protection, which is why I'm hoping Santa Claus will bring a second-preimage attack this year.
What bothers me is the dismal options of certificate management that browsers give you. Wouldn't be so bad if they at least gave you columns to sort by algorithm used, signing authority, and country of origin (Or any of the other fields in the certificate such as usage, date of validity, etc.)
As an engineer I already have control issues. I absolutely micromanage my security controls and the certificate systems drive me mad. WTF? It'd be nice if it were easier to manage especially for revocation of current certificates between identification of an issue and addition to the certificate revocation list. [And that ignores the bloated CRL's that exist today let alone the future.]
The article is wildly incorrect:
Like the rest of the security world,
Wrong. SHA-1 is being retired for many purposes, but opinions on its remaining safety are divided. And as with any use of cryptography, its "security" can only meaningfully be discussed in terms of an application and a threat model.
Google believes the SHA-1 cipher just isn't safe any more.
Maybe "Google" as an organization 'believes" that (though it's a tenuous position at best), but "isn't safe any more" isn't a meaningful position to take in this area.
That's a reasonable position,
It's an ignorant position that shows a failure to understand the most basic aspects of information security.
because it's been cracked without enormous effort.
No, it hasn't. The article Sharwood linked to misrepresents the situation, which is clearly spelled out in the paper it refers to. I explained this in a comment to that article and I'm not going to bother going through the details again. Suffice it to say that once again the Reg has gotten this straightforward technical matter completely wrong.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
