5 Lessons from the SHA-1 deprecation

When Microsoft announced that they will no longer accept SHA1 certificates from 1 January 2017, and Google said that they will start showing warnings as early as 2015, a cold sweat ran down the backs of IT operators across the world. This was a ticking time bomb, one that would require many wires to be carefully cut before services dropped dead come 2017. For those working in environments which may be infested with hundreds of these SHA1 instances (possibly hidden in legacy servers, clients and applications), this was going to be one messy clean-up exercise.

Even as you are busily working away all your SHA-1 dramas, know that you are not alone! We can get through this together. In fact, the greatest thing is that there are tons of support out there. So let us grab a drink (non-alcoholic if you are on-call) and recap over what we have learnt over the past couple of months.

  1. Cuz Microsoft hurts too…

The fact that the active deprecation of SHA1 is Microsoft led and that even the Certification Authorities were ill-prepared for this change, bought a lot of questions to mind. Was this a joke just to show us how powerful they are? Will Microsoft take it back in time? Unfortunately, this isn’t a joke and Microsoft are deadly serious.

What may have contributed to this is the Flame virus, discovered by Russian antivirus firm Kaspersky in 2012. Attackers performed a hash-collision on a weak md5 certificate to create a fake certificate. In doing so, they were able to impersonate Microsoft and distribute malware through their Update Service. This was used for spying and espionage on infected targeted systems in Iran, Lebanon, Syria, Sudan and the Israeli Occupied Territories for an unknown period (2-5 years potentially). Although this was a rare and highly sophisticated attack requiring massive amounts of computing power and one that is difficult for the standard attacker to replicate, it is fair to say that this is probably something Microsoft doesn’t want a repeat of.

  1. Microsoft and Google ARE almighty.

When Google announced that they were going to begin showing warnings as early as 2015, from the “Secure, but with minor errors” to the flat-out “Insecure” warnings, many of us wanted to boycott Google Chrome and tell our users to use another browser. However, after additional thought (30 seconds), this was replaced by a sigh of resignation. After all, Google Chrome do own a huge slice of the pie when it comes to market share. In Australia, they own the majority of market-share and they ARE trying to do the right thing.

Their view is that, as long as SHA-1 continues to be supported, there will be little work to deprecate SHA1. Even though the CA/Browser Forum’s Baseline Requirements recommended an upgrade to SHA-2 in 2011, CA’s were reluctant to stop issuing SHA-1 certificates due to market pressure. The transition from MD5 to SHA-1 took ages and caused many headaches for Google when they finally removed support for the algorithm. Therefore, the only way to give this the push it requires is for a browser-led initiative.

  1. When it rains, it storms

As if SHA-1 deprecation wasn’t enough for IT operators to deal with, some versions of OpenSSL were bleeding with Heartbleed while POODLE killed SSLv3. Then after some reprieve, FREAK came along to remind us that the rain never really stops. It was like being in the middle of a heart transplant, when fluid starts leaking into the lungs and then the liver fails. I will explore some of these attacks in more detail in my next post.

  1. Migrating to SHA-2 is painful

In complex environments, it may be difficult to discover all the SHA1 certificates out there. Especially if there are certificates issued by multiple External and Internal Certification Authorities. It can also take a long time to identify the support teams and businesses that own the domains. There are some certificate discovery tools that can be purchased from your CA (e.g. Symantec or Digicert both issue them). These scan the network for any SSL certificates (issued by any CA). A good discovery tool should be fast to implement and easy to set-up (they may also be able to detect misconfigured certificates or other vulnerabilities (e.g. BEAST).

While most modern and commonly used clients, devices and servers support SHA-2, there are legacy clients, devices, applications and servers that do not support SHA-2 and may require additional patching before the migration can occur. For example, Windows Server 2003 will require further patching. Windows XP running on anything less that Service Pack 3 will require an upgrade (even though XP should no longer be used). Some applications running on supported systems may not be able to validate SHA2 certificates (e.g. Outlook 2003). The true impact will not be known until you begin testing.

  1. Getting support and prioritization from the business is hard

Let’s be honest here, nobody really cares about the insecurities of SHA-1, not really. Especially since the attacks are still practically infeasible and will take huge amounts of computing power to achieve. The CA browser community didn’t care enough to do anything about it until Microsoft and Google posed their challenge, so why would businesses care? In a large organization, where change is slow and budgets are spliced, coordinating an effort as big as this one, in a short timeline, is suffice to say, difficult. Success will require a coordinated effort by IT Support, customer support, business application owners, managers and security to collaborate effectively. To get all these teams on board and motivated to take action, there needs to be strong buy-in. It is all in or nothing. Therefore, Microsoft setting a review of this, sometime in July this year to “assess” whether to go ahead or not sets us in limbo and makes it hard to gather appropriate prioritization and support. There can be no “yes this may happen but maybe it won’t” scenarios to play out. Teams are busy enough. What helps is to have a clear deadline. What doesn’t help is any ambiguity. Meanwhile, time is ticking…