The basis of trust for secure website connections—between you and a financial institution, you and Twitter, you and your health-care provider—relies on cryptographic shorthand. An outdated form of this shorthand will finally be mostly ditched starting January 1, 2016, and you may see the impact.
If you run websites, you’ll need to update the digital certificates that are used to form a secure session. But even if you’re just a surfer, you may still encounter problems with sites you frequently visit. Some sites, like Facebook, are trying to provide a smoother migration, though it’s very late in the figurative day to do so.
The problem is that once a standard is put into place, it’s very hard to dislodge, because there’s no centralized authority in most countries and absolutely not globally that requires the use of specific versions of protocols for any kind of Internet interaction.
Trust by verifying
To create an encrypted connection between a browser and a server with no prearrangement, which happens a trillion times a day or more worldwide, clever engineers developed a system that uses public-key cryptography, a method in which one can publish a public key and keep a private complementary key secret without revealing details that allow the private key to be cracked. (I wrote about the details of this problem in May after Google Chrome had pushed out an update, and you can find a full explanation there.)
Every web server that offers a secured connection needs a digital certificate, which is a bunch of formatted text that includes the domain name or range for which the certificate is valid, the server’s public key, and a lot of miscellaneous detail, like issuance and expiration dates. A browser can use the server’s public key to exchange a unique per-session encryption key.
But how can you be sure that this certificate wasn’t tampered with or the traffic isn’t intercepted, and some other party’s certificate and public aren’t in use? Through certificate authorities (CAs). These third parties’ certificates are baked into operating systems (like OS X and iOS) and browsers (like Mozilla’s Firefox).
A CA issues a certificate by taking all that text information (provided in a special format), except for a server owner’s private key. It then creates a kind of mathematical, one-way summary called a hash of the text portion, and encrypts that with its private key.
To prove the certificate was issued by that CA, a browser uses the public key it has on file for the CA to decrypt the hash, which only the CA with that private key could have encrypted in that fashion. It hashes the text in the certificate and compares it with the decrypted CA-signed version. If they match, then the CA’s private key was used. (Some CAs have occasionally been suborned or issued legitimate certificates inappropriately, and there’s continuous work among browser and OS makers and CAs to monitor and prevent recurrences.)
The only trouble with this equation in normal use is that the hashing algorithm that was in broad use until the last couple of years by CAs to create a signature was known to have limits several years ago that would ultimately allow a malicious party (or a researcher) to take a different set of text and produce the same hash. (This is called a “collision.”)
When that can be done effectively, even if it’s expensive, governments and then criminals will be able to fake certificate signatures, and use them to insert themselves into network connections and intercept data seamlessly. This is very bad.
Out with the old, in with the new
Also for years, browser and OS makers have been trying to both upgrade their own products, release patches for old ones, and convince CAs to move faster to a new standard. The earliest hashing algorithm was MD5, which was definitively broken in 2008. SHA-1 was its overlapping replacement, and while it hasn’t been show to be hackable in practice yet, research in the last several months has shown that day to be very very close and cost on the order of tens to hundreds of thousands of dollars—with that price dropping all the time.
The SHA-2 replacement (technically, a set of replacements, including SHA-256, which is the one used widely for web certificates) also overlapped with SHA-1, but both a lot of infrastructure needed to change at CAs and in server security libraries, while older operating systems needed to disappear by attrition, as many couldn’t be upgraded to support SHA-2.
An Internet services firm, CloudFlare, which helps sites deal with high traffic and denial-of-service attacks (among other things), posted a blog entry December 9 sketching out the problems that remain. The main pain points are Windows XP Service Pack 2 and Android 2.2 and earlier, which remain in use by less than 2 percent of the over 2 billion visitors CloudFlare handles each month, or a bit under 40 million users. Facebook sees a somewhat higher percentage. The majority of users of browsers that can’t handle SHA-1 are in developing nations. (Salesforce is the only place I’ve found a definitive list of OS and browser versions, from when the firm transition years ago to SHA-256.)
iOS and Mac users are in good shape. Apple added support in Safari 3/OS X 10.5 (in 2007) and in iOS 3 (2009) for at least the SHA-256. Hardware running versions before that, based on failure rates and “retirement” are likely in the low millions, if that. And some newer–but-not-the-newest browsers with SHA-256 support will run on those versions of OS X, too, reducing the number further.
Certifiably out of date in the wild
You might encounter errors on visiting websites that are still using SHA-1 certificates, however, as the race to swap them out only began in earnest in mid-2014.
CAs will stop routinely issuing SHA-1 certificates on December 31, but certificates using SHA-1 may be acceptable by some browsers through 2016, including Safari in iOS or OS X. Chrome already warns you about SHA-1, and will block a connection if the certificate expires in 2017 or later. Mozilla will only start warning in 2016 about newly issued SHA-1 certificates, and may show Untrusted Connection starting as early as mid-2016.
If you want to stop visiting sites with SHA-1 certificates before the cutoff and use Safari, version 9 (part of El Capitan) offers a way to do so. (There’s no similar option for Safari for iOS.)
- Select Safari > Preferences.
- Under Advanced, check Show Develop Menu in Menu Bar.
- Select Develop > Treat SHA-1 Certificates as Insecure.
The sky hasn’t fallen yet. SHA-1 hasn’t been provably broken, but it will happen soon. When it “breaks,” it’s still a one-by-one affair: A given certificate needs to be duplicated, one at a time, with a lot of computational power behind that task. And then that certificate needs to be installed on a server that’s inserted into a network connection, which requires to major network backbones, because domain name lookups have to also be subverted to make the substitution work without an error.
All of the above has been tried before—and caught—with invalidly obtained CA-signed certificates, which is why there’s so much concern about SHA-1. Keep your browsers up to date, and you’ll start seeing evidence of the sunset on January 1. When SHA-1 bites the dust, you’ll already be prepared.
Author: Glenn Fleishman, Senior Contributor
Glenn Fleishman’s most recent books include Take Control of iOS and iPadOS Privacy and Security, Take Control of Calendar and Reminders, and Take Control of Securing Your Mac. In his spare time, he writes about printing and type history. He’s a senior contributor to Macworld, where he writes Mac 911.