Hoping to avert “collision” with disaster, Microsoft retires SHA1

After 2016, Microsoft will stop accepting the collision-prone crypto algorithm.

Microsoft is retiring two widely used cryptographic technologies that are growing increasingly vulnerable to attacks that seemed unlikely just a decade ago.

The company's software will stop recognizing the validity of digital certificates that use the SHA1 cryptographic algorithm after 2016, officials said on Tuesday. SHA1 is widely used to underpin secure socket layer (SSL) and transport layer security (TLS) certificates that authenticate websites and encrypt traffic passing between their servers and end users. SHA1-based certificates are also used to digitally verify that specific software applications are legitimate and not imposter programs or programs that have been tampered with to include hidden backdoors.

The move comes as hardware improvements and research breakthroughs have made SHA1 and several other cryptographic hashing algorithms more susceptible to so-called collision attacks. Collisions occur when two distinct plaintext "messages" produce an identical hash or "digest." The security of an algorithm rests on it producing unique hashes for each plaintext string or file. The growing ease of producing collisions makes it possible for attackers to create digital forgeries that completely undermine the security of systems that rely on the weak algorithms.

The state-sponsored Flame malware that targeted Iran pulled off the only known in-the-wild collision attack earlier this decade. Using a never-before seen technique to subvert the MD5 algorithm, Flame-infected computers were able to pose as official servers belonging to Microsoft. By forging Microsoft's digital signatures, the infected machines were able to trick uninfected computers into installing highly malicious software they otherwise would have refused. Microsoft has since decommissioned MD5 in its update system. Tuesday's advisory indicates that the company is aiming to learn from that past incident by retiring SHA1 before it falls to the same type of attack.

"Since 2005 there have been known collision attacks (where multiple inputs can produce the same output), meaning that SHA-1 no longer meets the security standards for a producing a cryptographically secure message digest," Tuesday's advisory explained. "For attacks against hashing algorithms, we have seen a pattern of attacks leading up to major real-world impacts."

(Almost) unimaginable consequences

Back-of-the-envelope math published last year showed that SHA1 could fall to viable collision attacks by 2018. Those calculations didn't take into account the use of video cards or newer mathematical-based techniques to carry out the attacks. Depending on how well these and other alternative methods work, it's possible that the attacks could be viable sooner. Given the ubiquity of SHA1 now, its demise would spell almost unimaginable consequences in today's landscape. While collision attacks wouldn't allow attackers to decode encrypted traffic that's intercepted, it would make it much easier for them to create fraudulent certificates that could be used to validate malicious websites and software.

Microsoft officials went on to recommend that customers stop using SHA1 now and begin using certificates based on SHA2, which is much more resistant to collision attacks.

Decommissioning RC4

Also on Tuesday, Microsoft recommended that customers dump the RC4 cryptographic cipher on their websites and in their apps and replace it with something compatible with TLS version 1.2.

"Microsoft strongly encourages customers to evaluate, test, and implement the options for disabling RC4 below to increase the security of clients, servers, and applications," company representatives wrote in a separate advisory. "Microsoft recommends enabling TLS 1.2 and AES-GCM. Clients and servers running on Windows with custom SSL/TLS implementations, such as Mozilla Firefox and Google Chrome, will not be affected by changes to SChannel."

Promoted Comments

A few years back I was updating a medical system which ran using libraries compiled before I was born, and we didn't have the code for them. We advised our client to do fully replace the software and some of the hardware, but they weren't willing to pay. Many companies just aren't willing to spend more than 6 figures on something which (seemingly) works.Since the software isn't critical for patient care, and I was switching companies, I didn't continue pushing it, but I can imagine this behavior happening where it can't be allowed to.

The security of an algorithm rests on it producing unique hashes for each plaintext string or file. The growing ease of producing collisions makes it possible for attackers to create digital forgeries that completely undermine the security of systems that rely on the weak algorithms.

You leave an incomplete/poor definition of hash functions. By definition, a hash takes an infinite number of different inputs and produces a finite number of results (128 bit hash, there's only 2^128 different results). ALL hash functions produce collisions. Its inevitable. What makes a strong hash is the randomness of these collisions, not its ability to avoid them (assuming you've chosen a large enough hash of course, an 8 bit hash is obviously too small).

The strength of a hash isn't really about randomness of collisions. It's about the difficulty in finding a collision on purpose. First, the collisions aren't truly random, as they are entirely deterministic. A better term would be that they are pseudo-random. Second, one could imagine a hash function that results in a similarly-random-appearing distribution of hashes, but where some weakness in the function makes it relatively easy to collide on purpose. This was, in fact, what happened with MD5. "Someone" found a weakness that allowed a purposeful collision using much less processing power than if they simply brute-forced a collision.

I just killed RC4 ciphers and support for SSL 2 & 3 on my personal server plus got perfect forward secrecy enabled, but since I'm the only user right now from IE 9 at work to Safari on Mac/iOS for home/mobile it was pretty easy. I'm debating killing TLS 1.0 and only leaving TLS 1.1 and 1.2 but haven't yet. Also debating removing all the 128-bit ciphers and only allowing 256.

Now at work I have to move much slower. Our users are gov't agencies, not exactly swimming in upgrade money at the moment, so I'll have to proceed with caution and be ready to back out.

If you want to test a server's SSL implementation try running it through SSL Labs checker. Nice tool:https://www.ssllabs.com