For the past couple of years, browser makers have raced to migrate from SHA-1 to SHA-2 as researchers have intensified warnings about collision attacks moving from theoretical to practical. In just weeks, a transition deadline set by Google, Mozilla and Microsoft for the deprecation of SHA-1 is up.
Starting on Jan. 24, Mozilla’s Firefox browser will be the first major browser to display a warning to its users who run into a site that doesn’t support TLS certificates signed by the SHA-2 hashing algorithm. The move protects users from collision attacks, where two or more inputs generate the same hash value.
In 2012, Bruce Schneier projected a collision attack SHA-1 would cost $700,000 to perform by 2015 and $143,000 by 2018. In 2015, researchers said tweaks to existing attacks and new understanding of the algorithm could accelerate attacks and make a full-on collision attack feasible for somewhere between $75,000 to $125,000.
Experts warn the move SHA-2 comes with a wide range of side effects; from unsupported applications, new hardware headaches tied to misconfigured equipment and cases of crippled credit card processing gear unable to communicate with backend servers. They say the entire process has been confusing and unwieldy to businesses dependent on a growing number of digital certificates used for not only their websites, but data centers, cloud services, and mobile apps.
“SHA-1 deprecation in the context of the browser has been an unmitigated success. But it’s just the tip of the SHA-2 migration iceberg. Most people are not seeing the whole problem,” said Kevin Bocek, VP of security strategy and threat intelligence for Venafi, “SHA-1 isn’t just a problem to solve by February, there are thousands more private certificates that will also need migrating.”
Nevertheless, it’s browsers that have been at the front lines of the SHA-1 to SHA-2 migration. And starting next month, public websites not supporting SHA-2 will generate various versions of ominous warnings cautioning users the site they are visiting is insecure.
According to Venafi’s research team, 35 percent of the IPv4 websites it analyzed in November are still using insecure SHA-1 certificates. However, when researchers scanned Alexa’s top 1 million most popular websites for SHA-2 compliance it found only 536 sites were not compliant.
Exceptions to Every Rule
But still there are companies concerned about disruption to their business after the deadline asking for exceptions and exploring alternatives to full SHA-2 support.
“What you are seeing is various companies, for one reason or another, unable to complete the migration” said Patrick Donahue, security engineering product lead at Cloudflare. “The browser makers have created an exception process that allows companies to make appeals for exceptions that allow CAs (certificate authorities) to issue them.”
For example, last year Mozilla allowed a security firm to issue nine new SHA-1 certificates to payment processor Worldpay to use in 10,000 of its payment terminals worldwide. Worldpay argued because it missed a Dec. 31, 2015 cutoff for obtaining SHA-1 certificates, it needed SHA-1 certificates to buy more time to make the transition to SHA-2, or risk having thousands of its terminals go dark. After considerable debate, Mozilla granted the exception and issued SHA-1 certificates after the cutoff date.
According to Cloudflare, as many as 10 percent of credit card payment systems may also face problems as browsers reject SHA-1 certificates used in terminals similar to Worldpay’s.
“For credit card processing, it’s not as simple as a software update. It will require sending out new credit card processing machines that support SHA-2,” Donahue said.
For social networking behemoth Facebook, it wasn’t so much about the company looking for an exception, rather a solution that could allow it to keep users stuck on older computers and aging handhelds connected to its service. In late 2015, Facebook estimated up to 7 percent of browsers used by its customers, particularly in developing countries, would not able to use the newer SHA-2 standard.
At the time, Facebook chief security officer Alex Stamos said, “We don’t think it’s right to cut tens of millions of people off from the benefits of the encrypted Internet, particularly because of the continued usage of devices that are known to be incompatible with SHA-256.”
The solution for Facebook is similar to what a number of companies have sought, a stopgap fix until SHA-2 adoption is ubiquitous.
Facebook said it has found success running a large TLS termination edge with certificate switching, where it intelligently chooses which certificates a person sees based upon Facebook’s guess as to the capabilities of user’s browser. “This allows us to provide HTTPS to older browsers using SHA-1 while giving newer browsers the security benefits of SHA-256,” Stamos explained.
Cloudflare and Mozilla have both developed a similar techniques for customers concerned that line-of-business websites will stop working after the deprecation deadline.
“The biggest excuse among web server operators was the need to support Internet Explorer on Windows XP (pre-SP3), which does not support SHA-2. However, websites with this requirement (including www.mozilla.org) have developed techniques that allow them to serve SHA-2 certificate to modern browsers while still providing a SHA-1 certificate to IE/XP clients,” said J.C. Jones, cryptographic engineering manager at Mozilla.
Workarounds work for browsers, but different SHA-2 transition challenges persist within the mobile app space.
Apps Must Catch Up on SHA-2 Support
When a browser rejects a SHA-1 certificate, the warning message is easy to spot. That’s not the case with apps. While Google’s Android and Apple’s iOS operating systems have supported SHA-2 for more than a year, most apps still do not.
“With apps, you don’t get to see what the actual trusted connections are. It requires blind faith,” Venafi’s Bocek said. Alternatively, it should be a matter of trust and verify, he said. He reminds how bad things got in 2014 when Fandango and Credit Karma assured users that their data was secure and being sent over encrypted SSL connections when in fact they disabled their apps’ SSL certificate validation.
SHA-1 used by apps is a far cry from no protection. But still, the absence of SHA-2 introduces risk that someone could mint a forged SHA-1 certificate to connect with an app using a SHA-1 certificate. An attacker spoofing the DNS of a public Wi-Fi connection could launch a man-in-the-middle attack, and unlike with a browser, the use of untrusted TLS certificates would go unnoticed, Bocek said.
App developers don’t have to worry about pressure from browser makers. More often, it’s about what individual platforms and app makers decide to enforce.
In December, Apple backtracked on its plan to enforce a year-end deadline that would have required developers to adopt App Transport Security, which included SHA-2 support. It did not set a new deadline. As with Apple, it’s unclear when Google might force app developers to use SHA-2 or if it will reject SHA-1 certificates used to sign apps.
Salesforce warned its developer community and users if they wanted to continue to have error-free access to Salesforce, they needed to ensure their operating systems, browsers, and middleware were capable of accepting HTTPS certificates with the SHA-2 hashing algorithm or risk being blocked.
For Facebook, unlike its stance on SHA-1 deprecation for its website, it set a firm sunset date of Jan. 1, 2016 for SHA-1 for developers using its SDKs. After that date, Facebook required apps that connect to it to support SHA-2 connections.
“If your app relies on SHA-1 based certificate verification, then people may encounter broken experiences in your app if you fail to update it,” said Adam Gross, a production engineer at Facebook.
Internal PKIs Aren’t Immune
Enterprises are also not under the same immediate pressure to update their internal PKI used for internal hardware, software and cloud applications. But security experts warn that doesn’t make them immune to major certificate headaches. One of those hassles is the fact the number of certificates has ballooned to an average of more than 10,000 per company, which makes the switch from SHA-1 to SHA-2 a logistical nightmare, according to Venafi.
The growth of SSL and TLS traffic has been a mixed blessing, Bocek said. “More security is always better, but one blind spot in a sea of thousands of certificates used within the enterprise could be disastrous for the security of a business.”
That’s prompted Microsoft to take a hardline approach to SHA-1 deprecation. It announced an ultimate kill date for SHA-1 for its operating system in 2014:
“CAs must stop issuing new SHA-1 SSL and Code Signing end-entity certificates by 1 January 2016 … For SSL certificates, Windows will stop accepting SHA-1 end-entity certificates by 1 January 2017. This means any time valid SHA-1 SSL certificates must be replaced with a SHA-2 equivalent by 1 January 2017 … For code signing certificates, Windows will stop accepting SHA-1 code signing certificates without time stamps after 1 January 2016. SHA-1 code signing certificates that are time stamped before 1 January 2016 will be accepted until such time when Microsoft decides SHA1 is vulnerable to pre-image attack.”
“This is an operational issue. It isn’t as simple as patching or upgrading systems,” Bocek said. The migration requires a certificate inventory assessment, a review of policies, application and system testing and automation, he said. But he warns of the perils of procrastination.
“This is a non-trivial migration,” Bocek said. Think of 2017 not as the end of the race, rather when SHA-2 migrations begin to hit their stride, he said.
