Why Google is Hurrying the Web to Kill SHA-1

published by Eric Mill on
Hilbert map of hashing algorithms, by Ian Boyd

Most of the secure web is using an insecure algorithm, and Google's just declared it to be a slow-motion emergency.

Something like 90% of websites that use SSL encryption — — use an algorithm called SHA-1 to protect themselves from being impersonated. This guarantees that when you go to , you're visiting the real Facebook and not giving your password to an attacker.

Unfortunately, SHA-1 is dangerously weak, and has been for a long time. It gets weaker every year, but remains widely used on the internet. Its replacement, SHA-2, is strong and supported just about everywhere.

Google recently announced that if you use Chrome, then you're about to start seeing a progression of warnings for many secure websites:

What's about to befall websites with SHA-1 certificates that expire in 2017, in Chrome.

The first set of warnings will hit before Christmas, and will keep getting more stern over the next 6 months. Eventually, even sites with SHA-1 certificates expiring in 2016 will be given yellow warnings.

By rolling out a staged set of warnings, Google is declaring a slow-motion emergency, and hurrying people to update their websites before things get worse. That's a good thing, because SHA-1 has got to go, and no one else is taking it as seriously as it deserves.

If you run a website that uses SSL, you can test your website using a small SHA-1 testing tool I built that will tell you what you need to do.

Even if you don't, I encourage you to read on. In the rest of this post, I'll cover how SSL and SHA-1 work together on the web, why it's as urgent as Google says it is, and what web browsers are doing.

As importantly, the security community needs to make changing certificates a lot less painful, because security upgrades to the web shouldn't have to feel like an emergency.

SHA-what?

To understand why replacing SHA-1 is so important, you have to put yourself in a browser's shoes.

When you show up to a website using , the website presents a file — an SSL "certificate" — to your browser. This certificate is used to do two things: encrypt your connection to the website, and verify that you've connected to the real website.

Any certificate can be used to encrypt your connection. But to verify that you're at the real Facebook, your browser has to have a way to decide whether to trust that certificate, and show you a green lock.

Your browser does this by figuring out whether the website's certificate file has been issued by a "Certificate Authority" (CA). CAs generally charge money to give website owners this file. Your browser trusts over 50 Certificate Authorities to create and vouch for certificates, ranging from Verisign to GoDaddy to various governments — and the many subordinate CAs to whom those 50+ have delegated trust. As you might guess, this is a very flawed system, but it's the system that we have right now.

This website's Certificate Authority, for the time being, is Comodo, purchased through Namecheap.

What you see in Chrome if you click the green lock for this site.

So another crucial test your browser demands, when a website's SSL certificate claims to be issued for that website by a particular Certificate Authority, is: can the certificate prove it?

Wherever practical, the internet proves things through math. When a certificate is issued, the Certificate Authority includes this proof by cryptographically "signing" the certificate using a private key, in a way only the real CA could do and that browsers can verify.

But the CA doesn't actually sign the raw certificate: it first condenses the certificate into a unique slug by running it through a "one-way hash" algorithm, like MD5, SHA-1, or SHA-256.

An excerpt of what you see in Chrome if you ask for more certificate information.

Using a one-way hash keeps things small: for example, running this exact 3.2MB version of War And Peace through SHA-1 gives you baeb2c3a70c85d44947c1b92b448655273ce22bb.

Calculated using MD5file.com, a pleasant online hash calculator.

One-way hash algorithms like SHA-1 are designed to produce unique, irreversible slugs. You should not be able to take baeb2c3a70c85d44947c1b92b448655273ce22bb and work backwards and produce War And Peace. As importantly, no other file should produce that same slug — even changing one little period should cause the SHA-1 result to change so drastically as to be unrelated.

If two files are discovered to produce the same slug when run through a one-way hash like SHA-1, that's called a "collision". Collisions are always theoretically possible, but they're supposed to be so rare as to be practically impossible.

When your browser sees a certificate, it can calculate the SHA-1 for that certificate's information itself, and then compare it to the signed SHA-1 that the certificate offered as proof. Because SHA-1 promises unique slugs, the browser trusts that if they match, the certificate on offer is the same one the Certificate Authority signed.

If you could engineer a certificate that "collides" with a target certificate, and coax a Certificate Authority to issue you that certificate, then you would successfully forge a certificate that a browser would find indistinguishable from the target.

Gritty details: If you'd like to get into the details of signature algorithms and SSL certificates, Joshua Davies has an extremely detailed technical explainer.

An attack on SHA-1 feels plenty viable to me

In 2005, cryptographers proved that SHA-1 could be cracked 2,000 times faster than predicted. It would still be hard and expensive — but since computers always get faster and cheaper, it was time for the internet to stop using SHA-1.

Then the internet just kept using SHA-1. In 2012, Jesse Walker wrote an estimate, reprinted by Bruce Schneier, of the cost to forge a SHA-1 certificate. The estimate uses Amazon Web Services pricing and Moore's Law as a baseline.

Walker's estimate suggested then that a SHA-1 collision would cost $2M in 2012, $700K in 2015, $173K in 2018, and $43K in 2021. Based on these numbers, Schneier suggested that an "organized crime syndicate" would be able to forge a certificate in 2018, and that a university could do it in 2021.

Walker's estimates and Schneier's characterization have become widely cited in the planning and debate over transitioning from SHA-1. A group of leading Certificate Authorities, the CA Security Council, cited them recently to complain about Google's schedule. In that complaint, the CAs use those estimates to suggest "the lack of a practical attack until 2018".

I find this to be an absolutely cartoonish stance for the CA Security Council to take in 2014. They are clearly rationalizing the issue, based on how inconvenient they think a more rapid transition would be.

Walker and Schneier's estimates were pre-Snowden, before the public properly understood that governments are adversaries too. By their estimates, a forged certificate in 2014 would cost less than $2 million, a sum that many determined actors in this world would pay.

How do we know that they would? Because they have.

Computers infected with Flame, as measured by Kaspersky Labs

In 2012, researchers uncovered a malware known as Flame. The Washington Post reported that this was a US-Israel collaboration to obtain intelligence from Iran to stall their nuclear weapons program, and a leaked NSA document seems to confirm this.

Flame relied on an SSL certificate forged by engineering a collision with SHA-1's predecessor, MD5. Disturbingly, it used a method that was not publicly known at the time, despite years of concerted research on MD5. This was a reminder that we should assume that the worst vulnerabilities go undisclosed.

And it's a funny story about MD5, because, like SHA-1, it was discovered to be breakably weak a very long time ago, and then, like SHA-1, it took a horrifying number of years to rid the internet of it.

MD5 was first shown to be theoretically weak in 1995, and over time was shown to be even weaker. But MD5 was still used by some Certificate Authorities until 2008, when researchers successfully engineered a collision and got a forged certificate issued. That certificate, issued to "MD5 Collisions, Inc." has been immortalized inside your browser so that it can be specifically blacklisted.

In Chrome, you can see these by visiting chrome://settings/certificates.

That was an emergency, and yet Chrome wasn't able to remove support for MD5 until 201116 years after MD5 was first shown to be untrustworthy.

That's because there's a particular challenge with updating signature algorithms on the internet today: as long as browsers need to support SHA-1 for someone, anyone's certificate can be forged with it. You can impersonate a SHA-2-signed cert with a SHA-1-signed forgery, because the browser will only be looking at the forgery and not know that there's a "real" cert or that that cert is "supposed" to be signed with SHA-2.

In other words, the only way to prevent certificate forgeries using SHA-1 is to remove SHA-1 support from browsers. Like a tumor, you have to get rid of it all.

What browsers are doing

Microsoft was the first to announce a deprecation plan for SHA-1, where Windows and Internet Explorer will distrust SHA-1 certificates after 2016. Mozilla has decided on the same thing. Neither Microsoft nor Mozilla have indicated they plan to change their user interface in the interim to suggest to the user that there's a problem.

Google, on the other hand, recently dropped a truth bomb by announcing that Chrome would show warnings to the user right away, because SHA-1 is just too weak:

We plan to surface, in the HTTPS security indicator in Chrome, the fact that SHA-1 does not meet its design guarantee. We are taking a measured approach, gradually ratcheting down the security indicator and gradually moving the timetable up.

Google's Ryan Sleevi had first announced Chrome's intended policy a couple weeks before, and I strongly recommend reading the full discussion — you will get to see many Certificate Authorities and large site operators show up and nervously attempt to reason with this wild-eyed man who appears to be telling them that they should stop issuing weak certificates not late next year, but right now.

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.

What you can do

To help with the transition, I've built a small website at shaaaaaaaaaaaaa.com that checks whether your site is using SHA-1 and needs to be updated:

I chose a large, unguessable prime number of A's.

You'll need to generate a new certificate request, and get your CA to issue you a new certificate using SHA-2.

Using your existing private key:

openssl req -new -sha256 -key your-private.key -out your-domain.csr

The -sha256 flag will sign your CSR itself with SHA-2, but whether your CA issues you a certificate signed with SHA-2 is up to them. Look for controls on their website during the certificate process.

I'm keeping track of issues and workarounds for getting SHA-2 certificates from various CAs. If you run into a problem not mentioned there, please ring in here and I'll update the site.

You may also need to update any SHA-1 intermediate certificate(s), as they're also verified using a digital signature. This means tracking down whether and where your CA has published their SHA-2 intermediates. I'm keeping track of SHA-2 intermediate locations for various CAs. If you find some not mentioned, or your CA doesn't have them yet, please ring in.

If you have a site but some other company controls the certs, email their customer support and tweet at them. Link to Google's announcement, and ask for their timeline.

I could also use some help on shaaaaaaaaaaaaa.com — if you feel like chipping in, check out the open issues and lend a hand.

SHA-1 roots: You don't need to worry about SHA-1 root certificates that ship with browsers, because their integrity is verified without using a digital signature.

Changing certificates shouldn't be this hard

There is a larger issue here: there's no reason that fixing security issues should be so aggravating. A big reason why websites and Certificate Authorities are dragging their feet on updating to SHA-2 is because it means reissuing certificates, and everyone hates replacing SSL certificates.

For individuals, the certificate process can be strange, filled with arcane terminology and confusing user interfaces.

For companies, certificates are generally obtained for as long as possible, stuck wherever, and forgotten about until it's time to panic. Certificate management is often outsourced or out of reach.

In discussing Chrome's new policy, Google's Ryan Sleevi makes this exact point — that security today means that changing your certificate can't be such a tremendous operational hassle:

The age of having a secure UI remain static for five years is no longer tenable. It is expected that sites be able to respond to and adapting to security threats. This applies whether you're talking about TLS protocol level attacks like BEAST, cryptographic attacks like those involved in certificate issuance, or application-level attacks such as mixed content.

For the vast majority of our users, security is a one-or-two bit state, not the gradiations that CAs may see. In this model, we need to accurately reflect to the user whether or not we believe they're secure.

...If a site is not capable of changing its cert within 12 weeks, then I think we have a far more serious security problem - as Heartbleed [has] taught us.

If you poke around Google's SSL configuration, you'll see that (!) they use certificates signed with SHA-1. But each certificate expires in 3 months, a short-lived window that reduces the chances that a certificate could be forged, while they migrate to SHA-2 in 2015.

As importantly, a 3-month window forces Google to make cert rotation operationally simple across its own services. This is the equivalent of Netflix's Chaos Monkey — forcing yourself to take entropy and change seriously by turning it from an emergency into the routine.

Google has made it somewhat easier for themselves to do this, by setting up a private intermediate certificate authority for themselves, signed by GeoTrust, that can reissue certificates on demand. But you don't need to own an intermediate CA to make frequent certificate rotation a part of your business processes — you need to prioritize it. That's what Google's doing, and that's what they're arguing we should all do.

Further reading: Another related idea, under active discussion by Mozilla, Google, and others, is to allow for extremely short-lived certs, on the order of a few days. This would improve performance, as browsers wouldn't need to bother with revocation checking for those certs. It would also bring along the general security and operational benefits of frequent cert rotation, as described above.

In conclusion

A SHA-1 push like this should have started years ago. Any annoyance at Google for amping up the pressure should be channeled towards the Certificate Authorities instead, for allowing nothing to happen for so long.

For individuals, obtaining a certificate needs to be as easy as buying a domain name, installing it needs to be easy as turning on a website, and replacing it needs to be automatic. There are some pretty clear business opportunities and open source tooling gaps here.

For organizations, frequent certificate rotation needs to be prioritized in their infrastructure design and update processes. Organizations that have already done a good job of this should talk about it, and open source their work.

In the meantime, site operators should update their certificates and use the lack of Heartbleed-level urgency as an opportunity to revisit their SSL configuration and turn on things like forward secrecy.


  1. Pemkihq

    Payday installment loans Payday loans las vegas Payday loans Houston Payday loan Online payday loans

    http://payday-loans-fast-easy.loan

  2. Pemjraz

    Payday loans in MD Payday loans Online payday loan lenders Internet Payday Loans Faxless Payday Loans Fast payday loans Payday loans in AZ Payday loans no credit check Online payday loans no credit check

    http://payday-loans-fast-easy.loan

  3. Pemhsnn

    Payday installment loans Online payday loans no credit check Payday loans online Debit card payday loans Payday loans no credit check Payday loans las vegas Payday loans in GA Payday loan

    http://payday-loans-fast-easy.loan

  4. Pempzuk

    Payday advance loans USA payday loans Payday loans online no credit check Payday loan Instant payday loans Payday loans in MD Payday loans denver

    http://payday-loans-fast-easy.loan

  5. Pemxmct

    Payday loan online Payday loans Houston Quick payday loans Payday loans in PA Faxless Payday Loans Payday installment loans Fast payday loans

    http://payday-loans-fast-easy.loan

  6. AviollaCap

    [url=http://proflist.ferumtile.ru/moll/1368-list-otsinkovyvat-profnastil.html]Лист оцинковывать профнастил[/url]

    [url=http://kolpak-gib.ru/store/717-i-kolpakami-kolonnami-s-foto-zabora.html]И колпаками колоннами с фото забора[/url]

  7. Rob Brown

    Would you even need to "coax a Certificate Authority to issue you that certificate"?

    If you're an attacker and you find a collision, by definition you have already got a certificate "signed" by a CA because the hash they signed is the same as yours. You just add the matching signature to your cert file, upload it to your server, and then you just have the DNS to spoof (or connection to MITM or whatever). No CA needed.

  8. vsn

    This is all well and good, but the refusal of modern browsers to accept certificates with sha-1 signatures creates difficulties managing legacy devices with web interfaces. These devices live in internal networks so there is no threat, yet we are forced to maintain deprecated browsers like IE9 so that we can manage them.

  9. Meir Bank

    Thanks for the tool! My certificate says 256, so does your tool, but firebug was giving me console warnings. strange.

  10. RB

    Got to https://youtube.com, open the browser's console (using Firefox, I presume same is with Chrome) and you will see the following:

    "This site makes use of a SHA-1 Certificate blah blah blah" Google bitchin about something like this and at the same time actively using it (for Heaven's sake YouTube has Alexa ranking 3, which makes it the 3rd most visited website WORLDWIDE!) is pure hypocrisy.

  11. BlackOPS

    Well, after reading the comments I feel that a vast majority of you have caught on here. As for what Google's actual intention is long term, you guess is a good a mine.

    Interestingly, certificate authorities such as Comodo are issuing two intermediate certificates with the SHA-2 certs. One is a SHA-2 intermediate and the other is a chaining cert to SHA-1 so you can handle older browsers, EOL OS, that don't support SHA-2, etc.

    Google is not switching over for the very same reason that a number of commercial sites aren't. There are still a great many people using older OS, such as Windows 98, Mac OS <10.5, which do not support SHA-2 certs. Additionally, there are a number of devices that are running OS that will not support SHA-2 certs i.e. Apple iOS <3.0.

    It's all about the numbers gentlemen, and if you cut off "n" percentage of the online revenue stream it costs you money. Google is all about the money; therefore, they are continuing to issue SHA-1 certs, and as some of the more astute people here have gathered; they are getting around their own Chrome browsers because they know how to beat them.

    Google is not your friend people! They are all about Google, period!

  12. Charles

    Ideally, most commercial sites should support SHA-1 and SHA-2 simultaneously to aid in the transition. However, most websites use of load balancers (reverse-proxies) to handle the SSL offload of traffic to their production virtual ip addresses (VIPS) and unfortunately, most ( if not all) do not support the ability to apply two certificates (SHA-1 and SHA-2) to one VIP.

  13. Doug

    If it's so easy to change over to SHA-2, why is Google still issuing certificates signed with SHA-1 from their SHA-1 CA? They are even issuing ECC certificates signed with SHA-1. Google is mandating the change over but not changing anything themselves! I agree with Bob Dole's comment earlier that they are being hypocritical.

    Their loop hole is that they issue themselves 3-month certificates and set their policy to take advantage of that. They don't need to make any changes until 2016 while the rest of the industry needs to move over right away.

  14. Eric Mill

    @Dennis - SHA-3 would be great, but it's not finalized. Even when it's finalized, the next challenge will be getting it shipped into web browsers so that client support is acceptably broad to enable its use.

  15. Dennis

    I always ponder when SHA-2 is recommended. Any thoughts about SHA-3 instead?

  16. Mike

    Has anyone tried https://www.digicert.com/sha1-sunset/? Digicert offers to replace SHA-1 cert for free.

  17. David

    As an e-sign tech provider, the use of SHA-1 for digitally signed documents sounds like a bigger potential problem. After all, certs expire, but signed documents last "forever." The current PKI-based focus (especially with the EU's "advanced" and "qualified" e-signatures) has no solution for upgrading hashes, keys or the like. But a "service" type of technology like Open eSignForms, the server could (if desired) re-digitally sign all existing documents (of course, ensuring the current digital signatures are valid) using stronger encryption and hashing.

  18. David

    Are there any examples of two certs that have the same SHA-1 hash for the same domain name? Collisions are hard enough, but making a useful alternative is even harder. If not for certs, how about any examples of two documents (Word, HTML, XML, PDF, etc.) that both have the same SHA-1 hash? That is, has anybody made an actual "useful" collision that can be shared?

  19. Martin Wilson

    I’ve just found paypal.com is still using SHA-1, didn’t migrate to SHA-2 - https://shachecker.com/check/paypal.com. Now I am afraid to use PayPal for transaction. I think it will be good not to use PayPal for transaction until it migrates to SHA-2.

  20. Bert

    Just don't use a Google Chrome

  21. Bob Dole

    https://www.sslshopper.com/ssl-checker.html#hostname=google.com

    A large portion of Google's Domains utilize sha-1:

    Common name: *.google.com SANs: *.google.com, *.android.com, *.appengine.google.com, *.cloud.google.com, *.google-analytics.com, *.google.ca, *.google.cl, *.google.co.in, *.google.co.jp, *.google.co.uk, *.google.com.ar, *.google.com.au, *.google.com.br, *.google.com.co, *.google.com.mx, *.google.com.tr, *.google.com.vn, *.google.de, *.google.es, *.google.fr, *.google.hu, *.google.it, *.google.nl, *.google.pl, *.google.pt, *.googleadapis.com, *.googleapis.cn, *.googlecommerce.com, *.googlevideo.com, *.gstatic.cn, *.gstatic.com, *.gvt1.com, *.gvt2.com, *.urchin.com, *.url.google.com, *.youtube-nocookie.com, *.youtube.com, *.youtubeeducation.com, *.ytimg.com, android.com, g.co, goo.gl, google-analytics.com, google.com, googlecommerce.com, urchin.com, youtu.be, youtube.com, youtubeeducation.com

    Seems a little hypocritical.

  22. Brian

    If SHA1 really is weak why are Google themselves still using SHA1 certificates for all their certificates? And why have they neatly sidestepped the warnings in Chrome 39 by continually re-issuing their own SHA1 certificates in a way that's impractical for most certificate users? No there must be something else going on here. Do no evil my foot.

  23. Toby Goodwin

    Great article, thanks!

    You'll need to generate a new certificate request that asks your CA to use SHA-2, using the -sha256 flag.

    Sadly, this doesn't do what you imply that it does. Using -sha256 to the openssl req command gets you a SHA256 signed CSR. Hand that to a CA, and you get back... a SHA1 signed certificate. (I have seen exactly this with a GeoTrust RapidSSL certificate purchased through NameCheap in the last week.)

  24. Eric Mill

    @G: Believe me, I'm on it.

  25. G

    18f.gsa.gov uses SHA-1.

  26. Matt

    Strange that google are pushing this but not worried about crl checking. see https://revoked.grc.com/

  27. Randall

    There's one countermeasure that reduces the threat of collision attacks surprisingly well: random serial numbers.

    To pull off a collision attack you need to get the CA to sign one cert when secretly you have another cert in mind that hashes to the same thing. Random serial number messes with that because the cert authority inserts a random number (that you, the attacker, don't know) early in the content it hashes and signs. As long as the SN precedes the important content like the keys and identity, a collision f/one serial won't necessarily work with another.

    My recollection is that the MD5 Collisions Inc folks actually had to make a few attempts in order to get a cert with the serial number they wanted because their CA used an incrementing integer and they could only approximately predict the rate at which certs would be issued.

    Still, weak functions are weak, and there could eventually be preimage attacks, which are effective even in spite of serials. I'm guessing Google's including state-sponsored attackers (given they've dealt with attacks from more than one state actor) in their threat model. Also sort of glad they're using some muscle with CAs, who seem mostly interested in sitting on their valuable real estate in browsers' cert stores, more than improving Internet security.

    The large number of trusted CAs, the resulting risk that some of them might have bad practices or be legally compelled to do something bad, and the lack of great ways around the problem if they misbehave (HSTS is good but there could be more), seem like some of the big remaining problems for HTTPS.

  28. Kurt Andersen

    M3AAWG published a key rotation BCP last year recommending a similar tempo to be applied to the crypto employed for signing email: http://m3aawg.org/sites/maawg/files/news/M3AAWG_DKIM_Key_Rotation_BP-2013-12.pdf

  29. Dor

    Very good summarizing.

  30. Andreas G.

    Will Google replace the over 300 SHA-1 signed certificates on the webservers of our customers ? I think not.

  31. Eric Mill

    @Calvert - CAs disabling SHA-1 certificates would help a lot. That wouldn't protect against any existing forgeries which have already been made, and are waiting to be wielded (or are being actively wielded right now).

    The surest win comes when browsers can distrust SHA-1 certificates entirely.

  32. Eric Mill

    @Pierre - My statement that anyone's certificate can be forged as long as SHA-1 is alive is not based on the idea of forging an intermediate CA.

    You can impersonate a SHA-2-signed cert with a SHA-1-signed forgery, because the browser will only be looking at the forgery and not know that there's a "real" cert or that that cert is "supposed" to be signed with SHA-2.

    The only way to prevent forgeries of SSL certs on the web using SHA-1 is to remove SHA-1 support from browsers. Thus, all efforts to remove SHA-1 certificates help in achieving that goal.

    This point wasn't obvious to me either, until Seth Schoen wrote me to explain it. I've copied his email here, I found it very helpful:

    https://github.com/konklone/shaaaaaaaaaaaaa/issues/25

  33. Pierre Carbonnelle

    After reading the rogue CA attack, I believe it is incorrect to say : "as long as browsers need to support SHA-1 for someone, anyone's certificate can be forged with it."

    Instead, say "as long as browsers need to support SHA-1 intermediate CA, anyone's certificate can be forged with an SHA-1 attack."

  34. Marcos

    So why is https://www.google.com still using SHA1 as hash on their cert??

  35. Calvert

    "A big reason why websites and Certificate Authorities are dragging their feet on updating to SHA-2 is because it means reissuing certificates, and everyone hates replacing SSL certificates."

    Would you kindly explain why the main problem for CAs here is the replacement of existing SHA-1 SSL certificates? Why do they need to do that? 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? Is there any security gain whatsoever in upgrading any individual site from SHA-1 to SHA-2, as long as there remains at least one CA that still issues SHA-1 certs?

  36. Eric

    @Ted - Yep, they are using SHA-1 until 2015. I've updated the site to add a special message for google.com, since that's a common point of confusion.

  37. Ted

    As a sanity check, I ran the SHA-1 checker against google.com. It claims google.com is also (still) using SHA-1. Are you sure the SHA-1 checker works correctly?

  38. Eric

    @Bill - This is definitely a time to invest in SHA-3, for the reasons you described. But SHA-3 is very new, and I don't think client support is anywhere near what it would need to be to deploy SHA-3 anywhere right now. SHA-2 has been around long enough that it's supported in every browser except for WinXP SP2, and Android 2.3 and below.

    Never been a better time to push for SHA-3 support in more OSes and browsers!

  39. Bill

    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 and considered quite secure at the moment. But 1) SHA-2 was handed down from the NSA and 2) is in the same family as MD5 and SHA-1 (Merkle–Damgård).

    Considering 1) the recent NSA scandals, 2) that SHA-3 was independently developed and won a public-ish competition, and 3) that SHA-3 uses a newer family of algorithm (sponge construction) and comes with security proofs lacking for SHA-2, it would seem prudent to use momentum to move to SHA-3 sooner rather than later.

  40. v

    Collisions are always theoretically possible, but they're supposed to be so rare as to be practically impossible.

    No. No. NO. NO! Collisions are not theoretically possible they are a mathematical certainty. What is theoretically possible, but ideally rare is collisions of well structured, meaningful data.

  41. Larry

    your site has an issue testing mine :(

    Argh. There was an error checking webmail.lerctr.org.

  42. ecc

    @ogr

    See the article:

    If you poke around Google's SSL configuration, you'll see that (!) they use certificates signed with SHA-1. But each certificate expires in 3 months, a short-lived window that reduces the chances that a certificate could be forged, while they migrate to SHA-2 in 2015.

  43. ogr

    Funny that https://shaaaaaaaaaaaaa.com/check/www.google.com shows google.com has a SHA-1 certificate.

  44. Drew

    A shaaaaaaaaaaaaa.com report for one of my domains states, "Nice. [mydomain] has a full certificate chain signed with SHA-2", yet then it goes on to state, "Your SSL certificate was signed using a hashing function — probably SHA-1. Which is too bad, because SHA-1 is becoming dangerously weak. It's time to upgrade to SHA-2."