Search the Community

Facebook has set the date: on September 30, the ancient and creaking SHA-1 hashing algorithm will make its tumbril trip and get the chop. SHA-1, designed by the NSA in 1995, is a one-way algorithm: a block of data is turned into a message digest. The digest can't be turned back into the original message, but serves as a digital signature confirming the authenticity of (for example) the software you've downloaded. And it's long been on the end-of-life list, because it's vulnerable to collision attacks – different blocks of data can present the same SHA-1 hash, allowing malware to verify as if it were authentic. From October 1, The Social NetworkTM says, third-party apps signed with SHA-1 will no longer be able to connect to Facebook. As Facebook's Adam Gross blogs, the move is in line with the Certificate Authority and Browser Forum's intention to sunset SHA-1 by January 2016. “We'll be updating our servers to stop accepting SHA-1 based connections before this final date, on October 1, 2015. After that date, we'll require apps and sites that connect to Facebook to support the more secure SHA-2 connections”, Gross wrote. Facebook recommends that “applications, SDKs, or devices that connect to Facebook” be checked for SHA-2 support, to avoid user irritation. The migration hasn't been without its detractors. Earlier this year, infosec bods told The Register the shift poses challenges. If users see disruption – for example, too many “insecure site” warnings – they fear that trust in the Internet will be undermined. Source

The road towards phasing out the ageing SHA-1 crypto hash function is likely to be littered with potholes, security experts warn. SHA-1 is a hashing (one-way) function) that converts information into a shortened "message digest", from which it is impossible to recover the original information. This hashing technique is used in digital signatures, verifying that the contents of software downloads have not been tampered with, and many other cryptographic applications. The ageing SHA-1 protocol – published in 1995 – is showing its age and is no longer safe from Collision Attacks, a situation where two different blocks of input data throw up the same output hash. This is terminal for a hashing protocol, because it paves the way for hackers to offer manipulated content that carries the same hash value as pukka packets of data. Certificate bodies and others are beginning to move on from SHA-1 to its replacement, SHA-2. Microsoft announced its intent to deprecate SHA-1 in Nov 2013. More recently, Google joined the push with a decision to make changes in he latest version of its browser, Chrome version 42, so that SHA-1 certificates are flagged up as potentially insecure. Nudge Ken Munro, a director at security consultancy Pen Test Partners, warned that this type of behaviour creates the danger that while SHA-2 is being phased in, trust in certificates will suffer. "The risk of not updating could see users learn not to trust your site (reduced custom) or could encourage them to accept less-than-perfect encryption or even invalid certificates," Munro explained. Just updating to SHA-2 is not as simple as it might seem, because of compatibility issues with Android and Windows XP. More specifically, Android before 2.3 and XP before SP3 are incompatible with the change (a fuller compatibility matrix maintained by digital certificate firm GlobalSign can be found here). Windows XP may have been put out to pasture last year, but it's still widely used. Older versions of Android also present a problem. Around one per cent of devices used for Google Play are still <2.3 (Froyo) or below. Whilst the current Play Store version doesn't work pre 2.2, that still indicates that around 20 million active devices are in use that aren’t compatible with SHA-2, according to Munro. "The fact that SHA-2 can’t be used with older browsers and OS’s means that untrusted certificate warnings are going to become commonplace," Munro explained. "And if that happens, the danger is that many users will simply ride rough-shod over such pop-ups, potentially creating the ideal opportunity for man-in-the-middle (MitM) attacks." Ivan Ristic, a software engineer and founder of SSL Labs, agreed with Munro that there might be some trouble with the phasing out of SHA-1, "as with all older technologies". "Websites with older audiences might consider deploying with dual certificates; older SHA-1 for older clients and newer SHA-2 for modern clients," Ristic told El Reg. "Not all web servers support this, however." "To prevent warnings in Chrome, sites must upgrade to SHA-2 by the end of this year. However, it's possible to continue to use SHA-1 certificates at least until the end of 2016. So this gives sites at least about 1.5 years." Baseline requirements from industry group the CA/Browser Forum (PDF) offer "room for a reasonably safe dual-cert deployment" for even longer, if really necessary, up until the start of 2017. Macro signing Browser compatibility is not the only issue. SHA-2 compatibility for macro signing isn’t great, according to Munro, who said "it simply doesn’t work for Office 2003/2007 macro signing". Office 2010 does support SHA-2 macro signing, but only with a hotfix. Munro added: "There are plenty of other systems out there that are unlikely to ever accept SHA-2: what about the web interfaces for SCADA and other industrial control systems? What about other highly customised environments in the military: fire control systems built on old hardened versions of Windows XP?" Microsoft made some changes/exceptions for code signing, according to Ristic. ® Bootnote Microsoft's IE will allow "CAs to continue to issue SSL and code signing certificates until January 1 2016, and thereafter issue SHA-2 certificates only”. Google's Chrome will handle sites with end-entity (“leaf”) certificates that expire on or after 1 January 2017, and which include an SHA-1-based signature as part of the certificate chain, as “secure, but with minor errors”. Mozilla, makers of Firefox, has developed a policy that SHA-1 certificates should not be issued after January 1 2016, nor trusted after January 1 2017. Source