This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 1 added 56 lines
!!! Overview[1]
The news is that [SHA-1], a very popular [hashing function|Hash Function], is [Deprecated] beyond [2010|Year 2010].
Strictly speaking, this development is not new. The first signs of weaknesses in [SHA-1] appeared (almost) ten years ago.
In [2012|Year 2012], some calculations showed how breaking [SHA-1] is becoming feasible for those who can afford it. In November [2013|Year 2013], [Microsoft] announced that they wouldn't be accepting SHA1 certificates after [2016|Year 2016].
However, we are in a bit of a __panic__ now because Google followed up to say that they will soon start penalising sites that use SHA1 certificates that expire during [2016|Year 2016] and after. This is a major policy change that requires immediate action—according to SSL Pulse, only 15% sites use SHA256 certificates in September 2014.
!! What you should do
Before this most recent development, the advice was very simple: don't use [SHA-1] certificates __past [2016|Year 2016]__. Google's decision implies it no longer safe to use [SHA-1] (with Google Chrome) even __during [2016|Year 2016]__. For some sites there may not be a satisfactory outcome no matter what they do if their desire is to maintain an error-free presence with [Chrome] they might need to cut off some older clients.
Here's what [Qualys|https://Qualys.com/ |target='_blank'] recommends:
! Read the recent announcements
Within months, [certificates] that expire __after [2016|Year 2016] will be affected__. Relatively soon thereafter, further changes will be introduced that will impact the certificates that __expire during [2016|Year 2016]__.
* [SHA1 Deprecation Policy-Microsoft|http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx |target='_blank']
* [Gradually Sunsetting SHA-1 (for Chrome & Google)|http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html|target='_blank']
* [Mozilla - Firefox|https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/|target='_blank']
* [Apple|https://support.apple.com/en-us/HT207459|target='_blank']
! Ensure new certificate and their chains use [SHA256]
Ensure new certificate and their chains use [SHA256]. This is critical—if your new certificates are not guaranteed to be [SHA256] then all your other efforts will be pointless. If you do this, all [SHA-1] certificates that expire by the end of 2015 will be guaranteed to be ready for [2016|Year 2016] without further effort.
Remember, It is also necessary to check that the entire certificate chain is free of [SHA-1]. It is not common, but there are cases where the leaf uses [SHA256] but one of the intermediates uses [SHA-1]. Signatures on roots are not used and Chrome won't warn about them even if they are [SHA-1].
Companies that use centralized [certificate] procurement should find this step straightforward. For those that are not, perhaps this is a good opportunity to consider centralizing further [Certificate] issuance.
! Inventory your existing certificates
This might be difficult, depending on your environment. Automated scanning is not only easy to do once, but can also be repeated regularly to ensure new [SHA-1] certificates are not introduced. There are companies that offer products for this; for example one of the [QualysGuard|https://www.qualys.com/ |target='_blank'] modules do this automatically after scanning the entire company network.
! Replace [SHA-1] certificates that __expire after [2015|Year 2015]__
Start with those used on your most important sites and those that __expire after [2016|Year 2016]__. Those will be the worst affected by the proposed changes and might __stop working in [2017|Year 2017]__.
Then work your way to replace the remaining certificates. These steps are time consuming but shouldn't involve further direct costs because most third-party [Certificate Authority]s will reissue certificates for free. However, there are some special cases you might wish to consider:
* Older server platforms might not be able to support SHA256 certificates. For example, __that's the case with Windows Server 2003__. Thus, upgrading to a [SHA256] certificate might require an upgrade or patching of the underlying platform.
* Some older clients don't support [SHA256]. Most general-purpose sites can upgrade to [SHA256] and expect the users to upgrade, too, but large sites with diverse user bases might want to preserve [SHA-1] compatibility for as long as possible. In some cases that will be possible with __multiple certificate__ deployment.
!! What older clients don't support [SHA256]
Many older clients don't support [SHA256], but the real question is which of those are relevant to your site(s)? For detailed information on client capabilities, head to [GlobalSign|https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility|target='_blank'], which maintains a [detailed summary of SHA256 support|https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility|target='_blank'] for a large number of platforms.
On the desktop, __Windows XP__ introduced [SHA256] in Service Pack 3. Users running SP2 should be able to upgrade to SP3. Depending on a site's profile, a significant chunk of the user base might be running XP. The XP operating system is still very popular in China and there is also strong anecdotal evidence that it remains widely used in some large organizations.
Among the mobile platforms, __Android__ added [SHA256] support in version 2.3. Earlier versions—still used in large numbers—support only[SHA-1].
!! What if you need to support older clients?
Technically, it is possible to have the best of both worlds by providing [SHA256] certificates to modern clients and serve [SHA-1] to those that can not do better. Indeed, there's nothing to say that a site can't use more than one certificate at the same time. This approach is ideal for transitions such as this one. At this time, a site could use two certificates: [ECDSA]+[SHA256] for modern clients and [RSA]+[SHA-1] for older clients.
__Unfortunately__, this feature might not be available for your favorite platform. As far as We are aware, __[Apache]__ is the only major server to support __multiple certificates__. As for __NON-[Apache]__ platforms, [Cloudflare] and [Yahoo] have stated that they will add support to [NGINX] and [Apache] Traffic server, respectively.
!! [Exploit]
In addition to [{$pagename}], there are also other [Exploits] to worry about. [SHAttered] shows an actual [Cryptographic Collision] form the use of [SHA-1]!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [SHA1 Deprecation: What You Need to Know
|https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know|target='_blank'] - based on information obtained 2015-03-14