Why Google Is Pushing For a Web Free of SHA-1 108
An anonymous reader writes: Google recently announced Chrome will be gradually phasing out support for certificates using SHA-1 encryption. They said, "We need to ensure that by the time an attack against SHA-1 is demonstrated publicly, the web has already moved away from it." Developer Eric Mill has written up a post explaining why SHA-1 is dangerously weak, and why moving browsers away from acceptance of SHA-1 is a lengthy, but important process. Both Microsoft and Mozilla have deprecation plans in place, but Google's taking the additional step of showing the user that it's not secure. "This is a gutsy move by Google, and represents substantial risk. One major reason why it's been so hard for browsers to move away from signature algorithms is that when browsers tell a user an important site is broken, the user believes the browser is broken and switches browsers. Google seems to be betting that Chrome is trusted enough for its security and liked enough by its users that they can withstand the first mover disadvantage. Opera has also backed Google's plan. The Safari team is watching developments and hasn't announced anything."
SHA-1 (Score:5, Funny)
Deprecation shouldn't start at the browser (Score:4, Insightful)
It should start at the certificate authorities. They should've been planning for sha-1 to be unsupported by x date, and not issuing certificates valid past that date.
Re:Deprecation shouldn't start at the browser (Score:4, Informative)
It should start at the certificate authorities. They should've been planning for sha-1 to be unsupported by x date, and not issuing certificates valid past that date.
Certificate authorities roots also use SHA1 and typically carry validity periods of decades.
Re: (Score:1)
Root cert sigs are meaningless, they're self-signatures. They could be zeroed out and most trustdbs probably wouldn't care.
Re: (Score:2)
Root cert sigs are meaningless, they're self-signatures. They could be zeroed out and most trustdbs probably wouldn't care.
Yes this is true but it doesn't matter.
Cross signing / alternate certification paths can lead to one mans root becoming another's intermediary.
Intermediaries have the same problem with 10+ year validity periods.
Re:Deprecation shouldn't start at the browser (Score:4, Insightful)
Re: (Score:2)
They do have a large interest in the matter. If SHA-1 is broken and they keep selling it they lower the belief in the system. Thus it would lower the monetary value of ALL certificates.
Re: (Score:2)
They do have a large interest in the matter. If SHA-1 is broken and they keep selling it they lower the belief in the system. Thus it would lower the monetary value of ALL certificates.
How to lower the belief in something that no one's knows it there? :-)
Common people don't know about cryptography and security. All that common people knows is about WHO tells that something is secure or not - if they trust the guy that says that something is secure, then they acts as it is secure.
Google is betting that people thrust Chrome.
Re: (Score:1)
It didn't stop VeriSign from selling lower priced MD5 certificates when the algorithm had known vulnerabilities. They finally stopped when somebody publicly announced the ability to forge a verifiable certificate for any website in 1-2 days using a cluster of 200 PS3's.
Re:Deprecation shouldn't start at the browser (Score:4, Informative)
Re: (Score:2)
That's actually up to the browser providers. Your browser (assuming you're using something halfway normal) has a list of certificates that are from certificate authorities, and a certificate authority is a company that has it's certificate listed in browsers as certificate authorities. It isn't (AFAIK) recognized by any government (although governments can have certificates in there).
For certificates not in that list, there's ways to connect certificates to the authorities, directly or indirectly, so y
Re: (Score:3)
One obvious solution is to run your own mail server and create <certificates@example.com>, a forward to <bobfromaccounting@example.com> and finally a bit of logic such that a big scary warning is sent to the administrator account for the mail server if the forw
Re: (Score:3)
No, it should start, and stop, at the user's local cert store.
I don't actually trust any of the root CAs, and would much rather the world ran on self-signed certs.
I'd love to walk into my bank and say "Hey fuckers, I need to add your cert. He's my cert so you can do that same. I can clearly see that you are in fact, my bank, and you can see that I am, in fact, your customer, so let's share our certs so we can communicate over public lines securely.".
But no, that requires effort. So fuck it, we'll use unt
Re: (Score:2)
My bank is not a place I can easily walk into. I'd need to figure out where their office is, make an appointment, travel there, etc. And they'd have to do that with every single customer.
On the other hand, when I originally got my account there, I sent them a bunch of paperwork, and they sent me all sorts of sensitive stuff in return. Through snailmail. So I guess adding their cert (on a USB stick?) to that wouldn't compromise anything.
Re: (Score:3)
Print your cert with a QR code on a single sheet of correspondance. Its not hard, and it would be easy to disseminate.
Re: (Score:1)
How do you deal with entities that aren't physically located where you live?
There's no amazon place of business in australia, but I buy stuff from them all the time. I'm pretty sure that ebay australia doesn't have a local presence in my home city, and there's definitely no valve place of business here. How do I exchange certs physically with these entities without flying to sydney or to america?
Re: (Score:2)
How do you deal with entities that aren't physically located where you live?
There's no amazon place of business in australia, but I buy stuff from them all the time. I'm pretty sure that ebay australia doesn't have a local presence in my home city, and there's definitely no valve place of business here. How do I exchange certs physically with these entities without flying to sydney or to america?
Site posts thumbrint of cert on site.com/security .
I can call the customer service phone number and ask a human to tell me the thumbprint so I can verify.
A QR code can be posted on my monthly bill.
I can ask someone else who I trust and who deals with that entity to tell me the thumbprint.
Or I can take the risk and trust the cert.
It's about giving the USER control over who they trust, making trust an explicit action with a default of NOT trusting shit, and getting rid of the possibility for CAs/governments t
Re: (Score:2)
I'd love to walk into my bank
Good for you. Mine is all e-bank and I tend to like it that way. Same with most the e-tailers I shop at, the intersection with physical retailers is slim. How do you visit Gmail or Facebook? Speaking of which, people often have a different third party between them and whoever they're communicating with. You could always pretend it's not signed you know, what would you do? Send an email, asking them if that's their real certificate? Try to verify it through your "web of trust", which includes a bunch of dimw
Re: (Score:2)
Call your bank, talk to a person, compare the cert thumbprint with what the employee tells you.
Or check against the one included on your monthly bill, possibly via a QR code.
Or check against any other trustworthy source.
You being lazy isn't an excuse, be it physically going somewhere or spending 5 minutes to look shit up.
I don't care. (Score:4, Funny)
My website will be fine since it uses ROT-13.
Re:I don't care. (Score:4, Funny)
That's why I always use ROT-13 twice. It completely eliminates the risk of that form of decryption.
Re: (Score:2)
Yep, good old SHA-15
Can't beat that.
Re: (Score:2)
That's why I always use ROT-13 twice. It completely eliminates the risk of that form of decryption.
Because I had to worry about clients using XP SP2, I'm stuck using ROT-1. But I found that if I use it 26 times, it gives just as good protection and also avoids the inverse directional issues ROT-1 has with some implementations.
Re: (Score:3)
Because I had to worry about clients using XP SP2, I'm stuck using ROT-1.
You joke about that, but we just had to switch a major client's SSL certificate back to SHA-1 because their users in China couldn't use the new certificate since they were all on XP pre-SP3. We charged them something like a $500 stupidity tax for making us go through the process to install a less secure certificate.
Re: (Score:2)
Yeah it's a real issue. And in many environments even installing another browser isn't an option for various reasons. Going to be a pain for those websites that want to reach pre-XP SP3 machines once root CAs stop issuing SHA-1 certs.
Re: (Score:2)
HSOOHW
Re: (Score:2)
But does it handle 2ROT-13 or any other more advanced version? 3ROT-13 has nearly double the key width of ROT-13, after all.
First movers nothing. (Score:5, Interesting)
First movers nothing. Firefox 32 just released, and it deprecated a bunch of certs without any real warning at all, causing some users to get mad (http://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/). Google waited for Mozilla to take the risk while planning to safely tell the user that the site is running outdated SHA-1 certs. Stop trying to paint them as heroes, they're just one of the players, and not even at the forefront of the effort.
Re: (Score:2)
Wrong. That time you added an exception back in 2013 was the warning. Now deal with it.
Re:First movers nothing. (Score:4, Funny)
There's no point in acting all surprised about it. All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri for fifty of your Earth years so you've had plenty of time to lodge any formal complaints and its far too late to start making a fuss about it now.
What MS and Mozilla might be thinking (Score:2)
Re: (Score:2)
That's why you should never hire people, just small furry creatures from Alpha Centauri.
Re: (Score:2)
They're not banning anything. They're progressively changing the lock icon, from gold padlock now, to one with a red cross on in it some time next year.
SHA1 is not encryption (Score:1)
The summary writers really need to stop adding terminology willy-nilly. SHA1 is a hashing function, not an encryption.
Re:SHA1 is not encryption (Score:4, Informative)
The summary writers really need to stop adding terminology willy-nilly. SHA1 is a hashing function, not an encryption.
Yes, SHA-1 is a hashing algorithm, and anyone even remotely confused about the distinction should avert their eyes and NOT click on this link [slashdot.org] to an elucidating comment from a few years ago that indicated something... rather surprising... about the nature of hashing and encryption.
Strange, eh?
Re: (Score:1)
You still need a way to mix a key into the result if you want a symmetric cipher.
In any case, certificate validation doesn't use SHA-1 as a cipher.
Re: (Score:2)
Its a cryptographic hash function that uses encryption algorithms to generate (what used to be) secure hashes.
There are some pretty terrible hash functions that are not crypto (like parity bits) but SHA is crypto.
Re: People who just bought a multiyear certificate (Score:4, Insightful)
Not sure if serious...
Most CA's offer free re-issues these days. Allowing you to change your key, and hashing algorithm, and possibly other stuff.
SHA-3 (Score:5, Insightful)
Wouldn't now be the time to push toward a transition to SHA-3, rather than SHA-2? I realize SHA-2 implementations are much more common. But 1) SHA-2 was handed down from the NSA and 2) is in the same family as MD5 and SHA-1.
Considering 1) the recent NSA scandals, 2) that SHA-3 was independently developed and won a public competition, and 2) that SHA-3 uses a newer family of one-hash algorithms which is provably more secure than SHA-2, it would seem prudent to use momentum to move to SHA-3 sooner rather than later.
Re: (Score:3)
Interesting, didn't know that XP doesn't support SHA-2. As certs will have to move to SHA-2 or above, that means the XP users won't be able to connect any more - not an issue as far as I am concerned (would rather loose XP based people that those who use the latest Chrome builds etc and won't connect because of security alerts).
Given this, does this mean we are getting close to a point where we can start using SNI - if people with systems that don't support SNI can't connect anyway because they also don't s
Re: (Score:2, Informative)
Interesting, didn't know that XP doesn't support SHA-2.
Read the post again: XP sp2 doesn't support SHA-2.
XP with sp3 does - I just tried it with a sha256 certificate.
As certs will have to move to SHA-2 or above, that means the XP users won't be able to connect any more - not an issue as far as I am concerned
Some of us want to have a website to serve all paying customers, even if they use an old operating system.
Amazon is probably the best example - any browser can shop on Amazon, since long ago Amazon real
Re: (Score:2)
As certs will have to move to SHA-2 or above, that means the XP users won't be able to connect any more - not an issue as far as I am concerned
Some of us want to have a website to serve all paying customers, even if they use an old operating system.
Amazon is probably the best example - any browser can shop on Amazon, since long ago Amazon realized that annoying their customers with the latest buzzword ajax "responsive" junk doesn't sell their product.
Never mentioned anything about ajax or responsive etc, only about support for SNI. Also, but of selective quoting on the part about loosing XP customers, you forgot to include the bit where I said "would rather loose XP based people that those who use the latest Chrome builds etc and won't connect because of security alerts". - in other words if one of those two sets has to be lost for some reason, I would select to loose the older XP set. Obviously it would be best to loose neither, but given a enforced ch
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
I thought chrome moved away from using the windows SSL support some time ago to allow it to support SNI on XP.
Re: (Score:2)
It would be nice if certificate authorities gave the option of getting a SHA-3 certificate. Sell it as an extra high security cert that will remain secure for a lot longer, but make clear that it's not supported by older browsers. People who really want the extra security would have the option to get it, and they'd have to insist that their users upgrade to a more secure browser. Win all around.
Re: (Score:1)
SHA-3 is provably resistant to the types attacks that have been used to break MD5 and SHA-1. SHA-2 uses similar constructions to MD5 and SHA-1, Merkle-Damgaard, and some of these attacks are generic across the family. While SHA-2 looks to still be quite strong in practice, as attacks against SHA-1 improve they'll also likely improve against SHA-2. And while SHA-2 is stronger and is more conservative (the NSA may have foreseen the breakthroughs made by researchers in the 2000s), that's not a good position to
Re: (Score:1)
You said, "There is no evidence that SHA-3 is any better than SHA-2."
That is false. We know that SHA-3 is resistant to attacks that SHA-2 isn't. SHA-2 has known attacks, they're just not better than brute force. That's how MD5 and SHA-1 started out. In fact, most algorithms
"In fact, SHA-2 is older, and has had more time for evaluation, and so far has stood up."
This is false. It hasn't stood up. If cryptographers thought it was standing up and was going to stay secure, there wouldn't have been a push for SHA
Re: (Score:3)
Well, if x509 has simply allowed for multiple signatures, we could just put both SHA2 and SHA3 signatures on the certs, and consumers of the certs could move towards supporting SHA3 as their security requirements dictate, ignoring the SHA2 signatures when they have a SHA3 signature available to them.
But as with everything PKI related, the people making the calls have some blind spots when it comes to making things forward compatible or even particularly maintainable. It's as if they've never had to a day
Re: (Score:2)
Why? That sounds incredibly stupid. Isn't the obvious method to validate both?
You could do that too, but if the SHA3 is not deemed sufficient protection, then we are
screwed anyway. Embedded devices might choose to ignore the SHA2 to save on
compute resources.
What about Symantec Class 3 EV SSL CA - G2 (Score:3)
Issuer: CN = VeriSign Class 3 Public Primary Certification Authority - G5, OU = (c) 2006 VeriSign, Inc. - For authorized use only, OU = VeriSign Trust Network, O = VeriSign, Inc., C = US
Subject: CN = Symantec Class 3 EV SSL CA - G2, OU = Symantec Trust Network, O = Symantec Corporation, C = US
Valid from: Thursday, 31 October 2013 12:00:00 p.m.
Valid to: Tuesday, 31 October 2023 11:59:59 a.m.
Signature algorithm: sha1RSA
Signature hash algorithm: sha1
Thumbprint algorithm: sha1
Thumbprint: e4 99 59 a4 b3 36 ac bd 2d ac 75 9b b5 21 b9 46 03 3e 82 3a
They're still issuing certificates. It appears they use sha1?
Thumbprint (Score:2)
Re: (Score:3)
That's not a root CA, it's an intermediate CA signed by the VeriSign root CA.
Uhh yeah (Score:4, Informative)
Re: (Score:2)
Microsoft will probably implement SHA0. There's no value in SHA2 (and variants) now that SHA3 has been ratified, since SHA2 is just SHA1 with some lengthening. If SHA1 is brutally compromised, SHA2 will fall shortly after. Best to switch to NESSIE (Whirlpool) and SHA3 (something that sounds vulgar).
Having said that, SHA3 involved dubious mid-contest rule changes and spurrious rejection criteria that might well have been NSA-inspired. I'd take a very close look at the Hashing Lounge for any second or third r
Re: (Score:2)
The problem with hunting down the best hash algorithm is that both your certificate authority and the user's browser have to support it. SHA-3 has at least the benefit of standardization, which puts it far ahead of a third round reject.
Re: (Score:2)
Agreed, which is why it should be there.
Nonetheless, there needs to be a backup plan in case it does turn out that the NSA or GCHQ have a backdoor to it. If it's been deliberately compromised (and I'm not keen on changes made AFTER it had been approved as SHA3 for that very reason), then the more paranoid amongst us need to have a backup plan. I certainly wouldn't suggest HTTPS over TOR use algorithms that are considered three-letter-agency-unsafe for any part of the security protocol, for example, since th
https://www.google.com using SHA-1 (Score:5, Interesting)
Amazing www.google.com and every single link in its trust chain is using SHA-1 signature algorithm.
Re: (Score:3, Informative)
True. As mentioned in the article and a linked tweet, Google plans to migrate to SHA-256 by the end of 2015. Why it will take them so long is not stated.
In the meantime, their certificates only last three months. Probably only NSA and GCHQ could forge a cert in that short a time — and they don't need to. (Though I'm sure they would prefer a nice quiet forgery to issuing an order that someone might blow the whistle about.)
Re: (Score:2)
True. As mentioned in the article and a linked tweet, Google plans to migrate to SHA-256 by the end of 2015. Why it will take them so long is not stated.
I only read Google's announcement and did not follow every link from others before posting.
Hearing this only makes things worse... If Google themselves is not getting their act together until 2016 and concurrently the following is true:
"Chrome 39 (Branch point 26 September 2014)
Sites with end-entity (âoeleafâ) certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as âoesecure, but with minor errorsâ.
It is hard to imagine a situation whereby you can avoid everything appearing broken in much the same way everything is known to the state of California to cause cancer.
In the meantime, their certificates only last three months. Probably only NSA and GCHQ could forge a cert in that short a time â" and they don't need to.
What is the point of this?I don't understand the logic here.. how/who does this help?
Google's cert would be
Oh be serious, Google (Score:1)
Why is the only form of encrypted password you accept via your Google Apps Directory Synchronization GADS tool SHA1? Not even salted. Just flat out SHA1. Let us sync salted strongly hashed passwords, and then we'll take your concern for security seriously.
Re: (Score:3)
Except that it's honestly a shitty idea given the history of witness unreliability. The human mind is pretty shit at remembering a real human's face you've only seen once. Worse, an uncanny valley fake face is going to look like every other uncanny valley fake face, especially without additional visible features like hair or glasses (and even then the memory is likely to recall "wears glasses" not a specific style or color).
Also, the guy never explained what the hell the problem was that he wants the engin
Re: The Real Reason? (Score:2)
AC is very clearly trying to promote his own useless face-generation technique.
US Gov migration from SHA1 (Score:1)
A migration from SHA1 for US federal agencies was mandated at the end of 2013.
Re: (Score:1)
A quick check of https://www.irs.gov/ [irs.gov] and https://whitehouse.gov/ [whitehouse.gov] failed SSL Certificate validation (for different reasons.)
And https://www.healthcare.gov/ [healthcare.gov] is using SHA1
More information = less security (Score:1)
When you add decision points about issues the average user has no practical basis for making an informed determination you just make matters worse by adding confusion and uncertainty able to be leveraged by adversaries.
Now instead of secure and not secure.. ideally working and not working... we are hurling FUD and technobabble at users whose day job is NOT technology.
Who am I trying to kid.. .f@#uck...it...ya'll just need more reassuring padlock .gifs to adorn your secure sites.
Thats rich comming from Google, they sure love RC4 (Score:4, Informative)
Google still REQUIRES RC4 for Youtube.
https://news.ycombinator.com/i... [ycombinator.com]
Re: (Score:2)
Re: (Score:3)
the only meaningless information is coming from you. Its not the YT portal that requires RC4, its servers serving actual video files
r6---sn-2apm-f5fs.googlevideo.com
accepted ciphers:
TLSv1 128 bit RC4-SHA
SSLv3 128 bit RC4-SHA
and hundreds of other content farm servers
Re: (Score:1)
Not encryption! (Score:2)
Google recently announced Chrome will be gradually phasing out support for certificates using SHA-1 encryption.
SHA-1 is a hashing Algorithm, not an Encryption Algorithm. Really people. How do you expect anyone to become educated if everything they see is inaccurate to begin with?
http://en.wikipedia.org/wiki/H... [wikipedia.org]
http://en.wikipedia.org/wiki/E... [wikipedia.org]
The short story is that hashing is to prove information has not been altered. Encryption is to keep information secret. Both technologies are used to ensure a secure information exchange experience.
Re: (Score:2)
Is it not enough for CA's to _stop_ issuing new certificates under SHA-1, as only new certificates would be the potential source of collision attacks?
Unfortunately SSL certificates have become a lowest bidder shithole market. In this environment ensuring that no CA continues to issue SHA-1 certs is impractical.
Rejecting certs based on issue date doesn't directly solve the problem either because the "legit" and "fake" certs in the collision attack can have different issue and expiry dates. What it does do is strongly discourage CAs from issuing SHA-1 certs which has two positive affects
1: it reduces (but does not eliminate) the risk that the attacker will
Re: (Score:2)
Didn't know you could encrypt things with SHA-1 (Score:1)
Hash in counter mode == stream cipher (Score:2)
Re: (Score:2)
While that may be true, web browsers aren't using SHA-1 for encryption, especially for validating certificates. It's a cryptographically strong hashing function, but not, on its own, encryption.
Re: Dip Shit Alert! It's a hash not crypto! (Score:4, Informative)
Dip Shit Alert! It's a hash not crypto! (Score:1)
if you had studied computational complexity theory, you would understand that they are the same thing
Re: (Score:1)
-
hash < huge > 160 bits (no way back)
crytp < huge > huge (get it back exactly as before)