Disclaimer: This post represents personal opinions and thoughts, and does not represent the views or positions of my employer, Google.

This past month, CloudFlare and Facebook grabbed tech press headlines with simultaneous posts about the perceived challenges and risks of the upcoming sunset of SHA-1 certificates. In a post by Alex Stamos, Facebook’s Chief Security Officer reported between 3% to 7% of browsers don’t support SHA-256. Meanwhile, CloudFlare’s Chief Executive Officer, Matthew Prince, offered a more detailed breakdown of the 25 countries with the worst SHA-256 support. The conclusion, from both companies, was that there exists a need to continue issuing SHA-1 certificates for sites. CloudFlare went a step further, suggesting that to sunset SHA-1 was akin to isolating vulnerable populations in the poorest, most repressive, and most war-torn countries of the world from secure communications. Following their posts, Michael Coates, Trust and Information Security Officer of Twitter, joined in support the proposal, painting the conversation as a dichotomy between having either no security or no access, with there being absolutely no middle ground.

The conclusion drawn by Stamos, Prince, and Coates was that there is a need to find a way for sites to continue to obtain new SHA-1 certificates. They proposed that the CA/Browser Forum introduce a new type of certificate, called Legacy Verified (LV), as a way of allowing known-insecure practices to continue while ostensibly mitigating the risks such practices pose. The details of this proposal were later forwarded on their behalf to the Forum.

Background

In order to fully understand and appreciate this proposal, it’s necessary to first understand both the technical details and the historical context surrounding SHA-1 certificates and their sunset. This discussion is not new; rather, it is merely the latest milestone in a discussion that spans a decade. Similarly, the upcoming 31 December 2015 sunset of SHA-1 issuance does not represent the end-state for SHA-1; browsers, CAs, and sites will still be discussing, making changes, and debating trade-offs for at least several more years to come.

In this first post, my hope is to frame the conversation regarding SHA-1 into the proper historical context in which it fits. In many ways, the proposal is simply the continuation of an endless cycle of debate about how to handle deprecating known-insecure practices. And yet even though similarities exist, the rhetoric itself has grown both louder and harsher; to support deprecation is to support the oppression of at-risk populations or to deny them basic rights. Though such appeals are moving in isolation, they must not be taken in isolation, but evaluated within the systems and history in which they are being made. Further, though the numbers being published are both headline-grabbing and alarming, what is published lacks scientific rigor, and even conflicts with the data published by other large sites.

In subsequent posts, I hope to explore both the technical merits of the specific proposal, as well as that of suggested alternatives, as well as explore what possible next steps are available — to browsers, to CAs, and to sites themselves.

A Timeline of Woe

It’s important to realize that the story of SHA-1 is tied closely to that of its predecessor, MD5. Beyond the fact that both MD5 and SHA-1 share similar cryptographic constructions, MD5 was previously the de facto hash algorithm for certificates, due to a lack of widespread SHA-1 support, similar to the story of SHA-1 and SHA-2 today. It was the complete breakage of MD5 that hastened the adoption of SHA-1, much like the near-complete breakage of SHA-1 has hastened about the switch to SHA-2.

This past experience with MD5, and its ultimate removal, has informed and significantly shaped how browsers and software vendors have responded to SHA-1; one cannot discuss SHA-1 without first exploring the history of MD5.

Similarly, to understand the dynamics at play between CAs, browsers, and sites, it’s equally important to consider the discussions related to the ultimate deprecation of both 1024-bit RSA certificates and Server Gated Cryptography, as many of the arguments surrounding those deprecations are similar to — or even identical to — the arguments being put forth today.

This timeline is not meant to be exhaustive as to all the unfortunate events that have happened, but merely serves as a representative sample that can be used to show patterns and trends, as well as referred to in the subsequent posts to demonstrate various flaws in the arguments presented by others.

Conclusions

While this is an admittedly long and detailed timeline, such length is necessary to see that the debate reignited this month is not new, but simply a continuation in the cycle of debates that occurs with each and every deprecation. The concerns raised for compatability are not new — application developers and platform vendors face hard choices each and every step of the way towards securing the Internet, with two notable examples being it be the deprecation of MD5 certificates and the still-ongoing deprecation of certificates with key sizes less than 2048 bits (which all systems continue to trust, with the exception of newly-compiled iOS 9/OS X 10.11 apps that do not disable ATS).

Though this timeline explores the context of MD5, 1024-bit, and SGC, it doesn’t even begin to touch on the challenges of removing support for RC4, removing support for SSLv3, or in removing support for weak Diffie-Hellman keys, all of which have affected the ability of users to get online and accomplish day-to-day tasks, and yet failed to evoke similar hand-wringing concern from those advocating for SHA-1 to continue.

In this timeline of events, it becomes obvious that many examples selected were of a specific CA’s failures. This CA was intentionally chosen to show that these concerns are not isolated one-off incidents from a variety of unrelated CAs, but a long-term pattern of behavior. Unfortunately, a number of CAs have similarly problematic histories, so these issues are by no means limited to this single CA. The most vocal critics of the SHA-1 deprecation in the CA industry, and the most vocal advocates of ways in which to extend the dates, have repeatedly abused the concessions and delays afforded in the past, to the point of causing serious and long-lasting harm to the security of the Internet.

With this timeline, patterns begin to emerge that are both telling and damning for the industry. Leading CAs routinely underestimate the risks to users, overestimate the costs, and delay migrating or mitigating for as long as possible. The timeline for deprecating SHA-1 was first finalized in November 2013, despite having been debated for months before, and continued to be debated for years after. Had CloudFlare, Twitter, or Facebook wished to participate in the debate, the door was long open. PayPal previously participated for years in the CA/Browser Forum. Even if these organizations were unable to agree to the IPR policies necessary to join the Forum, the opportunity for “informal” participation had existed for years as well, and was explicitly reiterated in March, 2015:

The failures of the CA industry are profoundly important when discussing the LV proposal by Facebook, CloudFlare, and Twitter . The ways in which these companies propose to mitigate risk hinges upon a reliance on CA policies and practices which can neither be independently evaluated nor technically enforced by browsers. Each of the proposed solutions have been tried before, have been violated before, and unfortunately, but undoubtedly, will be violated again. To ignore this historic context is not just short-sighted, but puts billions of users at risk.

It is within this framework, both of technical concerns and historical context, that the proposal by Facebook, CloudFlare, and Twitter must be evaluated, and ultimately, rejected. As indicated at the start, this will hopefully be the first in a series of posts that examine the risks that Legacy Verified certificates pose, the challenges in finding solutions, the problems with the data being provided in support of this proposal. Hopefully the conclusion of this series can identify possible paths forward — preferably ones which do not put Internet security as a whole at risk.

This is a post in an ongoing series regarding SHA-1 and the CA ecosystem; the next post is Legacy Verified: Legacy Solutions.

An earlier version of this referred to 1996 as the introduction of SGC certificates; as pointed out on Twitter, this was actually mid-1997, rather than late 1996.

While the opinions, conclusions, and inaccuracies are wholly my own, my thanks to the many people who reviewed draft versions of this post and offered feedback and advice.