Microsoft Retiring SHA-1 in 2016

I think this is a good move on Microsoft’s part:

Microsoft is recommending that customers and CA’s stop using SHA-1 for cryptographic applications, including use in SSL/TLS and code signing. Microsoft Security Advisory 2880823 has been released along with the policy announcement that Microsoft will stop recognizing the validity of SHA-1 based certificates after 2016.

More news.

SHA-1 isn’t broken yet in a practical sense, but the algorithm is barely hanging on and attacks will only get worse. Migrating away from SHA-1 is the smart thing to do.

Tags: , , ,

Posted on November 13, 2013 at 2:17 PM • 20 Comments

Comments

David Magda • November 13, 2013 5:11 PM

Are any major CAs currently making use of anything but SHA-1?

Not really, but they will soon if Windows is ending support. I don’t think it’s a coincidence about the timing of this announcement as 2016 is just over two years away, and a lot of certs are issued annually.

This allows roughly two SSL/TLS cert renewal cycles before possible breakage occurs. I think most browsers support SHA-2 already, but don’t have a citation for that.

Anura • November 13, 2013 5:49 PM

@David

Many are issued on two or three years; I have a feeling they are going to delay this change near the last minute, but it really is a good kick in the butt for the CAs either way.

I know from experience that OpenSSL supports SHA-2 certificates. Chrome and Firefox both use NSS, which I am pretty sure supports it since NSS added Suite B compliance, which requires SHA-256 and SHA-384 for signing.

Jakub Narebski • November 13, 2013 6:27 PM

What about using SHA-1 not for cryptography, but as hash function, for example in modern distributed version control systems (content-based addressing)?

Anura • November 13, 2013 6:37 PM

@Jakub

If you are only concerned about a unique identifier for file contents, and not with someone deliberately trying to mess with you, MD5 is perfectly fine. As far as I know, no one has ever publicly demonstrated SHA-1 collisions at all (unlike MD5) so you are probbaly safe from malice for the immediate future. That said, there is little reason to choose SHA-1 over SHA-256 for any application, except compatibility with systems that only support SHA-1, and maybe performance (which is probably not significant for your purposes).

Viktor Dukhovni • November 13, 2013 7:24 PM

Clients using OpenSSL 0.9.8 do not in fact support SHA-2 by default (OpenSSL_add_ssl_agorithms() does not enable SHA-2 until OpenSSL 1.0.0). TLSv1 does not advertise the client’s supported digests, and server certificates have to be compatible with the vast majority of clients.

Microsoft cannot in practice retire support for SHA-1 until after most sites have deployed SHA-2 certificates, which cannot begin to happen until most clients are TLSv1.2 capable. Their timeline is unrealistic.

There is more to TLS than just the various flagship browsers. HTTP APIs in various languages (C, Java, Python, …) using various underlying TLS libraries, and non-HTTP applications using TLS (SMTP, IMAP, XMPP), …

We are some time away from universal adoption of SSL toolkits in which SHA-2 is on by default, and deprecation of SHA-1 is unrealistic until that happens.

Dirk Praet • November 13, 2013 8:07 PM

@ Viktor Dukhovni

We are some time away from universal adoption of SSL toolkits in which SHA-2 is on by default, and deprecation of SHA-1 is unrealistic until that happens.

You’re probably right, and especially as long as DoD applications or other equipment are impacted. But it is a good thing that big boys like M/S are (finally) starting to pay proactive attention to this kind of stuff. It hasn’t always been like that.

Mike the goat • November 14, 2013 4:43 AM

I understand code signing but will they also kill it from IE’s SSL implementation. We still have sites forcing RC4-MD5 and both the RC4 cipher and MD5 hashing algo both have known issues. It doesn’t appear that anyone has found SHA1 collisions just yet, so perhaps this is jumping the gun just a tad. No doubt SHA1 will be as broken as MD5 in a few year’s time but even MD5 is still widely used (even for evidentiary purposes, ie some forensic software still uses this to verify that files have been not modified) and it is past its useby date well and truly.

Pete S. • November 14, 2013 5:16 AM

@Anura: “Are any major CAs currently making use of anything but SHA-1?”

StartSSL gives you the option of having certs signed with SHA256 by their intermediate cert (SHA1 is the default).

They also provide two intermediate certs for each certification level (e.g. two each for Class 1 certs, two each for Class 2, etc.): one signed by the root using SHA1 and the other with SHA256. Each of the intermediate certs share the same private/public key, but the signature algorithm differs between the two certs.

They employ the same one-key/two-certs mechanism with their root: the root included in most browsers uses SHA1 for its self-signature, but several browsers (e.g. Firefox) have both the SHA1 and SHA256 roots added. Thus, if your server sends the SHA256 intermediate then Firefox will use the all-SHA256 chain back to the root. Chrome on Windows will use the SHA256 link between the server and intermediate cert, but uses SHA1 for the link between the intermediate and the root.

StartSSL also recently released their “G2” root (which is SHA256-only) to browsers but it’s not yet being used for production.

I’m not sure about any other major CAs. It seems strange to me that so many CAs are touting their 2048-bit roots but still use SHA1.

Bryan • November 14, 2013 6:38 AM

Anybody else getting the impression we are on the verge of a revelation on the permeability of encryption in general?

Wm • November 14, 2013 6:54 AM

@ Viktor Dukhovni
“Their timeline is unrealistic.”

Come on now. If the Obamacare website can be build, up, and running in 2 years, then web sites should be able to deploy SHA-2 certificates and make their clients TLSv1.2 capable in 2 years.

Eldoran • November 14, 2013 5:25 PM

As for more or less realistic current hash strength:
effectively a single sha1 / sha256 is the measure:
according to http://golubev.com/gpuest.htm the optimum (price/performance) is right now: a Radeon HD 5830 with 896M in single sha1. A radeon 6990 goes up to 2656M.

Or a more general comparrison: http://openwall.info/wiki/john/development/GPU

The main trouble IMHO is less the hash in the end user certificate, more for the root/intermediate CA certificate. If one manages to break that hash, or more to the point creates a hash collision with a fake intermediate CA certificate, then this would be worth quite a bit of money.

Unfortunately there are still some systems that won’t even accept sha256 – windows XP before SP3 is such a case.

Anura • November 14, 2013 5:52 PM

@Eldoran

The root certificate is self-signed, so finding collisions for that certificate doesn’t really mean much (it’s trivial to forge a root certificate). The primary (only?) reason for forging an SSL certificate is to perform a man in the middle attack; even if the intermediate certificates are all sha256, if the browser accepts sha1 for certificate signatures then (assuming you can readily find collisions) the attacker can still perform a MITM.

Andre DeMarre • November 14, 2013 6:28 PM

Attacks only get better insofar as they only get more effective, never less so. Harmoniously, attacks only get worse insofar as they become more damaging.

Dirk Praet • November 14, 2013 6:32 PM

On a related sidenote, M/S this week published Security Advisory 2868725 strongly “encouraging customers to evaluate, test and implement the options for disabling RC4 to increase the security of clients, servers and applications”.

Cisco as of this month downgraded RC4 from “legacy” to “avoid” in its recommendations for cryptographic algorithms.

David Filiatrault • November 14, 2013 8:33 PM

A great way to push site owners to spend the time to disable RC4 is to to convince the PCI Security Standards Council to classify RC4 as a “weak” cipher so that it get assessed and documented, which then gets management attention. They should also make a similar statement like that SHA1 will start to be considered weak starting with assessments starting in 2015.

anonymous coward • November 15, 2013 6:11 AM

This looks more like a marketing stunt and an attempt to discriminate against an installed base of enterprise linux systems and against an installed base of smart phones and other Internet&SSL-enabled gear that does not support SHA1.

Microsoft has been distributing digital signatures on code (e.g. Hotfixes from Windows Update) for Windows 7/2008R2 with sha1WithRsaEncryption signatures created with code signing certificates signed by sha1WithRsaSignature — although these platform have included sha2 support from the start.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.