Hypertext Transfer Protocol Secure (HTTPS) has evolved into the de facto standard for secure Web browsing. Through the certificate-based authentication protocol, Web services and Internet users first authenticate one another (“shake hands”) using a TLS/SSL certificate, encrypt Web communications end-to-end, and show a padlock in the browser to indicate a communication is secure. In recent years, HTTPS has become an essential technology to protect social, political, and economic activities online.
At the same time, widely reported security incidents—such as DigiNotar’s breach, Apple’s #gotofail, and OpenSSL’s Heartbleed—have exposed systemic security vulnerabilities of HTTPS to a global audience. The Edward Snowden revelations—notably around operation BULLRUN, MUSCULAR, and the lesser-known FLYING PIG program to query certificate metadata on a dragnet scale—have driven the point home that HTTPS is both a major target of government hacking and eavesdropping, as well as an effective measure against dragnet content surveillance when Internet traffic traverses global networks. HTTPS, in short, is an absolutely critical but fundamentally flawed cybersecurity technology.
While the Heartbleed incident illuminated severe flaws in a widely used crypto-library of HTTPS (OpenSSL), the focus here is on the systemic security vulnerabilities in the HTTPS authentication model that precedes end-to-end encryption. Although some of these vulnerabilities have been known for years, the 2011 security breach at the small Dutch certificate authority (CA) known as DigiNotar was a watershed moment, demonstrating these theoretical man-in-the-middle vulnerabilities in the wild. Meanwhile, large CAs such as Comodo and Verisign have experienced breaches as well but did not suffer similar consequences as DigiNotar. In fact, some large CAs actually benefited from the increased sense of HTTPS insecurity.
Policymakers and technologists are increasingly advocating various solutions to address the security collapse of HTTPS. The European Union is halfway through adopting the first comprehensive legislation on HTTPS in the world. It will acquire immediate binding force in the legal systems of 28 European member states. As most large CAs operate (also) under E.U. jurisdiction, the legislation will impact HTTPS governance globally. In the U.S., on the other hand, attention has focused on technological solutions and industry self-regulation.
To evaluate both legal and technological solutions, an understanding of the economic incentives of the stakeholders in the HTTPS ecosystem, most notably the CAs, is essential.2,3 This article outlines the systemic vulnerabilities of HTTPS, maps the thriving market for certificates, and analyzes the suggested regulatory and technological solutions on both sides of the Atlantic. The findings show existing yet surprising market patterns and perverse incentives: not unlike the financial sector, the HTTPS market is full of information asymmetries and negative externalities, as a handful of CAs dominate the market and have become “too big to fail.” Unfortunately, the proposed E.U. legislation will reinforce systemic vulnerabilities, and the proposed technological solutions are far from being adopted at scale. The systemic vulnerabilities in this crucial technology are likely to persist for years to come.
Systemic Vulnerabilities in the HTTPS Authentication Model
Essentially, HTTPS is a two-step process. First, a trust relationship (a handshake) is established between a website and an end user’s browser. This is done with the help of a Transport Layer Security/Secure Sockets Layer (TLS/SSL) certificate containing basic information for authentication purposes. If the Web browser trusts the certificate and the issuing CA, then this authentication handshake succeeds. Second, successful authentication leads to a TLS/SSL-encrypted channel between the website and browser, called a tunnel.1 Thus, the handshake authentication serves as the stepping stone for the confidentiality and integrity that HTTPS seeks to deliver. If the handshake succeeds, then the browser informs the user by, for example, depicting a padlock or a green address bar. If the TLS/SSL certificate or the issuing CA cannot be trusted, then the browser will show a security warning to the end user. The described data flows are shown in Figure 1.
A website that wants to provide HTTPS communications to users needs to obtain a TLS/SSL certificate from a CA. Basically, these certificates are small computer files that contain information on hostname (website), certificate owner (website owner), certificate issuer (CA), validity period, and public key.1 The method for verification of the identity of a website owner, among others, drives the costs of a certificate and is the key difference between domain validation (DV), organization validation (OV), and extended validation (EV) certificates.2
The stakeholders. HTTPS market involves four central stakeholders, as depicted in Figure 1—Website owners; certificate authorities; Web browsers; and end users.
Website owners decide whether to deploy HTTPS or not, and how securely to implement it on their servers. Deployment is a binary affair from the point of view of the end user. An outdated implementation, as long as the browser accepts it, appears similar to the state-of-the-art implementation. If embedded content from third-party websites (for example, behavioral tracking across websites for advertising) is a part of the revenue model of a website owner, then that operator has a strong incentive not to deploy HTTPS at all. Both deployment and secure implementation vary widely.24
Certificate Authorities. CAs sell TLS/SSL certificates, which come in three categories: root, intermediate/subordinate, and untrusted. Root CAs are trusted by default by browsers, after they have solicited for such a status with the browsers and complied with the varying browser CA trust policies. Intermediate/subordinate CAs are either directly verified by one root CA or they are part of a chain of trust of several intermediate CAs that ultimately ends with one root CA. Certificates of untrusted CAs are not issued by a CA linked to a root CA but are mostly self-signed by the owner of a website. Self-signed certificates evoke the “untrusted connection” security warning when served by a website to browsers. CAs are owned by such varying entities as multinational corporations, nation-states, universities, and hacker communities—anyone can start a CA operation relatively easily.
Web-browser vendors. These vendors play a key role in the HTTPS ecosystem. For example, they decide whether to trust a CA inherently, how to respond to a (suspected) CA compromise, and how to implement related trust revocation protocols such as the OCSP (Online Certificate Status Protocol). Over the years, various browsers have developed different certificate policies, leading to varying numbers of root and intermediate CAs inherently trusted per browser.3,7
End users. Because their communications and valuable information are on the line, end users have an interest in seeking HTTPS communications with websites, but they depend to a large degree on security decisions made by the other stakeholders and can exert very little control over HTTPS.4,9
Known CA breaches. On Friday, September 2, 2011, a nocturnal press conference of the Dutch Minister of Internal Affairs marked the beginning of the DigiNotar affair. It was triggered by unauthorized access, reportedly by a hacker sympathizing with the government of Iran in mid-July 2011, to the root CA capacity of DigiNotar. When the breach became public three months later, it emerged that in this long period of obscurity 531 false certificates had been created for widely used and highly sensitive domain names such as *.google.com, *.facebook.com, update.windows.com, and *.cia.gov.12 A small player in the global market with a strong presence in the niche for Dutch e-government services, DigiNotar had root status with all major browser vendors, leading those browsers to trust, by default, corrupt certificates for months.
According to the forensic report, 30 critical updates had not been performed, logging was insufficient, and no antivirus protection was in place at the time of the intrusion.13 The damage was probably enormous but cannot be determined with certainty because of the unreliability of the log files. ENISA (European Network and Information Security Agency) speaks of breached communications of “millions of citizens,” particularly connected to the *.google.com certificate, and notes that some experts believe the lives of Iranian activists have been put at risk.9 Upon publication of the breach, the trust in the entire range of DigiNotar activities was revoked by all the major browsers.
Comodo. The range of breaches at market-leading CA Comodo also received considerable media attention.14 The best documented breach was the compromise of Comodo’s UTN-USERFirst-Hardware certificate. According to the Electronic Frontier Foundation (EFF) SSL Observatory, 85,440 public HTTPS certificates were signed directly by UTN-USERFirst-Hardware, and indirectly, the certificate had delegated authority to 50 more intermediate CAs.8
Verisign. Another dominant CA, Verisign, was hacked in 2010. The breach was not discovered until February 2012, after new Security and Exchange Commission (SEC) regulations mandated companies to notify investors of intrusions. In reporting its discovery, news agency Reuters quoted a former CTO who said Verisign “probably can’t draw an accurate assessment” of the damage, given the time elapsed since the attack and the vague language in the SEC filing.9
Trustwave used its root CA status to enable third parties to issue SSL server certificates for the purpose of monitoring employees. While providing man-in-the-middle capabilities to private entities via sub-CAs does not technically breach the HTTPS trust model, it undermines it. This is especially true when end users are not informed of the monitoring. Trustwave claims this is common practice among root CAs.6 This illustrates the “compelled-CA attack” in real life: CAs are in a unique position to enable surveillance of end users.23
Steven B. Roosa and Stephen Schultze20 report on several other breaches, including GlobalSign, KPN/Getronics, StartSSL, and TurkTRUST. From the known CA breaches, several patterns emerge.
Systematic vulnerabilities of the HTTPS authentication model. The term systemic vulnerabilities refers to those vulnerabilities inherent in the HTTPS ecosystem, as opposed to incidental vulnerabilities that have occurred at a particular stakeholder during an isolated incident. Many security experts agree that the security of the HTTPS authentication model and thus the HTTPS ecosystem is systemically flawed as a result of these vulnerabilities.1
Weakest link. A crucial technical property of the HTTPS authentication model is that any CA can sign certificates for any domain name. In other words, literally anyone can request a certificate for a Google domain at any CA anywhere in the world, even when Google itself has contracted one particular CA to sign its certificate. CAs have certain institutional limits to issuing certificates (for example, validation procedures) but no technical ones. If this second google.com certificate is obtained from one of the hundreds of intermediate CAs that link to root CAs trusted by browsers, users will get the familiar HTTPS notification (signaling all is OK).
While this ability to sign for any domain name has spurred a flourishing global market for certificates, it has profound implications for the security of the HTTPS ecosystem, commonly referred to as the weakest-link problem: if one CA suffers a breach, the entire ecosystem is under attack.9,20 The scenarios for failure are manifold, from CA compromise, misconfiguration, and malpractice to state compulsion.23
Information asymmetry and ineffective auditing schemes. The recurring information asymmetries are a striking systemic vulnerability, making it very difficult for other stakeholders to know about the security of CAs. The current regulatory regime in the E.U. and auditing obligations worldwide have proven ineffective. The qualified certificate practices of DigiNotar were regulated and passed the periodic audits based upon internationally recognized industry standards. The regulatory and auditing schemes deliver perceived security and enable liability dumping.20
Liability dumping. Websites, browsers, and CAs push damages from security breaches downstream toward end users. CAs, for example, disclaim all liability for losses suffered via inappropriately issued certificates.20,25 Because of the negative externalities at play, liability dumping is a common practice, and it is widely criticized for providing wrong incentives or actual security provision.1,22 End users bear the burden of these security vulnerabilities and breaches, even though most users are probably unaware of this and cannot reasonably be held responsible for evaluating security practices in the HTTPS authentication model.
Mapping the HTTPS Market
To understand these systemic flaws better, a thorough understanding of the market dynamics of HTTPS is essential.1 It is only in light of such data-driven findings that one can start to reflect on the need for legal and technical interventions in the current HTTPS ecosystem.
Several studies have surveyed the SSL certificate market. Two of the largest have been the EFF SSL Observatory in 2010 and the University of Michigan’s HTTPS ecosystem scans in 2012–2014. Both projects systematically scanned all the IPv4 address space, looking for publicly facing HTTPS servers. They retrieved the SSL certificates presented by these servers and later parsed and validated them to determine whether different browsers and operating systems would trust that certificate.
In an earlier study3 we used the EFF dataset, which contains approximately 1.5 million trusted certificates, in empirically establishing the number of CAs, the firms that own them, their market shares, and the pricing strategies. We compared our findings against the HTTPS ecosystem scan dataset, which has approximately three million trusted certificates. Durumeric et al.7 use this dataset to analyze the HTTPS ecosystem. While the latter scan has collected more certificates than the EFF dataset, this difference mostly reflects a linear growth pattern over time in the number of certificates in use on the Web, and to a limited extent improved scanning methodology. There is a difference of 400,000 certificates if the growth trend in the ecosystem scan data is extrapolated back in time to the EFF data-collection period. Despite these differences, the following patterns are consistent across both datasets.
Many CAs. Foremost, the number of organizations that can issue browser-trusted certificates is high. There are between 1,000 and 2,000 trusted CAs, including root and intermediate CAs. Multiple CAs might be owned by the same organization for a variety of operational and business needs, so the number of issuing organizations is lower. Mapping CAs to organizations leads to an estimated 250 to 700 trusted certificate-issuing organizations, located in 57 countries worldwide. Heterogeneity is often good for an ecosystem, especially in terms of resilience. Because of the weakest-link nature of the HTTPS system, however, this also means many more single points of failure in case of CA compromise or misconfiguration. What is particularly troubling is that a number of the trusted CAs are run by authoritarian governments, among other less trustworthy institutions. Their CAs can issue a certificate for any website in the world, which will be accepted as trustworthy by browsers of all Internet users.
HTTPS market concentration. Second, the market for SSL certificates is highly concentrated, despite the large number of issuers. In fact, both data sets find that around 75% of SSL certificates in use on the public Web have been issued by just three companies: Symantec, GoDaddy, and Comodo. Symantec, the largest commercial CA, owns multiple brands, including Verisign, GeoTrust, Thawte, RapidSSL, and TC TrustCenter. The distribution is heavily skewed, with smaller CAs having little or no presence on the public Internet. Power-law distributions, although not surprising in Internet service markets, pose a major risk for the HTTPS ecosystem: if one of the large CAs is compromised, its root status cannot be revoked by browser vendors without massive collateral damage. One particular CA of GoDaddy had signed 26% of all valid HTTPS certificates in use in March 2013. That means if it were compromised, 26% of all websites that rely on HTTPS would need to be immediately issued new certificates.7 Otherwise, browsers ought to present certificate warnings or block access to those sites, posing an impossible trade-off for the user between access and security. In other words, such large CAs are truly “too big to fail.”
Weak price competition. Mapping the prices for different certificate brands provides a sense of the degree to which the market is dominated by price competition. Figure 2 shows the price and market share for DV certificate offerings. Symantec/GeoTrust certificates (for example, QuickSSL Premium) sell for $149 but have a much larger market share than Gandi SSL certificates selling at $16. OV and EV markets show similar dynamics, as presented in the accompanying table.
The situation is extreme in the EV market, as shown in Figure 3. The market leader, Verisign, sells certificates for approximately $1,000 and has a 63% share. GoDaddy, offering certificates at a fraction of that price ($100), captures a mere 5% of the market. (These comparisons have certain limitations, most notably that prices are as advertised by vendors in March 2013, while market shares were from the EFF 2010 dataset.3 The more recent and longitudinal HTTPS ecosystem scan data shows that similar market shares hold over time, with a slight shift of a few percentage points away from Symantec to cheaper providers.) The differences are intriguing, as certificates themselves are perfect substitutes (within each validation category). The differences might be explained by features bundled with the certificates, discussed in the next section. In sum: the SSL market shows few signs of intense price competition.
Analysis of HTTPS Market Incentives
Various researchers and industry observers have claimed that a “race to the bottom” exists in the HTTPS market: a market dominated by fierce competition pushing prices toward marginal cost, with perverse incentives for security.1,22 Some have pointed to this as an explanation for the poor security practices at DigiNotar and other compromised CAs.15,18,20,25
One would indeed expect such a race. Certificates are perfect substitutes, suggesting a completely commoditized market. Also, buyers cannot meaningfully distinguish secure from less secure offerings; and even if they could, buying from a more secure CA cannot protect the site owner against the threat of an attacker fraudulently signing the domain with a certificate from a compromised CA.
The empirical data, however, clearly suggests otherwise, showing market concentration and little price competition. In one sense, it is good news that the market is not driven by a race to the bottom, given the perverse security incentives associated with such a race. Rather than certificates themselves, however, the HTTPS market is driven by:3
- Bundled security services such as scans of the buyer’s s site for malware.
- Enterprise certificate management services such as support for management and billing of large numbers of certificates.
- Brand reputation as a liability shield against shareholders, regulators, or others who may hold the buyer accountable in the face of security issues.
- Trust or security signals aimed at third parties and end users such as site seals, warranty amounts, and the high price of a certificate itself.
- Higher continuity in case of security failures at the CA, because of the too-big-to-fail dynamic of market-leading CAs.
Knowledgeable buyers understand security in this market is a weakest-link problem and thus determined by the weakest CA. They also understand three of the four market leaders got hacked in recent years and some of the “security” features of these services do not really provide actual security. Nonetheless, buying from the market leaders is still rational, given the liability shield and higher continuity. The price differences are not enough to overrule these advantages. They may be large in a relative sense, but they are modest in absolute terms, compared with other cost components in large firms.
Given the market leaders successfully differentiate their products via, among other things, security-related features, buyers appear to be willing to pay for security. Two classic problems, however, as mentioned earlier, affect the proper alignment of incentives:
- Information asymmetry prevents buyers from knowing what CAs are really doing. Buyers are paying for the perception of security, a liability shield, and trust signals to third parties. None of these correlates verifiably with actual security. Given that CA security is largely unobservable, buyers’ demands for security do not necessarily translate into strong security incentives for CAs.
- Negative externalities of the weakest-link security of the system exacerbate these incentive problems. The failure of a single CA impacts the whole ecosystem, not just that CA’s customers. All other things being equal, these interdependencies undermine the incentives of CAs to invest, as the security of their customers depends on the efforts of all other CAs.
The most powerful incentive for security seems to be reputation effects, but this does not necessarily make them more sensitive to the reputation damage caused by breaches. While they have more to lose compared with smaller brands, large CAs are less threatened by the ultimate reputation effect: being removed from the root stores.
Ironically, the security problems that have plagued the HTTPS ecosystem over the past few years, including the breaches at market leaders, may in fact benefit these same market leaders. The breaches have increased the demand for security, and this demand seems to latch onto whatever security signals are available, regardless of their relationship to actual security. All of this may impact the attempts to fix the systemic vulnerabilities of the system. The dominant players might be reluctant—or less eager—to push for adoption of one of the proposed technological solutions. This is not to suggest that market leaders will act against them, but rather that the status quo works quite well for them.
Improving HTTPS Governance
In the aftermath of these CA breaches, policymakers and technologists have suggested regulatory and technical solutions to the systemic vulnerabilities of HTTPS. Let’s evaluate these solutions in light of the market-incentive analysis.
Regulatory solutions. The HTTPS authentication model is by and large unregulated in both the U.S. and the E.U. This is bound to change in the near future. Each entity has opted for a completely different approach: the U.S. gives priority to technological solutions and lets industry self-regulate in the meantime. The European Commission (the executive branch of the E.U.), on the other hand, proposed the Electronic Identification and Trust Services Regulation in June 2012. Unlike the more common E.U. directives that require implementation in national law, regulations acquire direct binding force of law in all E.U. member states upon adoption in Brussels. In April 2014, the European Parliament adopted substantial amendments to the commission proposal, leaving the regulation only for the E.U. Council (national governments of the E.U.) to approve.
Here, we outline the scope, underlying values, security requirements, security breach notification, and liability regime of the E.U. proposal,10 as well as the recent proposals by Mozilla for “chain of trust transparency.”2,3
Scope. The E.U. proposal regulates trust service providers, including CAs.10 All major CAs appear to fall within both U.S. and E.U. jurisdiction.3 While inherently local, regulation may therefore be an effective instrument to address the observed market failures and positively influence HTTPS security globally. Other critical stakeholders in the HTTPS ecosystem, however, such as browser vendors and website operators, remain unregulated in the proposal. This limited scope impacts the proposed security measures considerably.
Underlying values. The E.U. proposal focuses on availability interests to boost trust in e-commerce, neglecting confidentiality and integrity concerns connected to the systemic HTTPS vulnerabilities already outlined. Apart from failing to observe privacy and communications secrecy obligations under the E.U. Charter of Fundamental Rights, the proposal completely ignores the Snowden revelations. The BULLRUN and MUSCULAR disclosures have made clear that HTTPS significantly raises the costs of mass dragnet surveillance and has been a primary target of intelligence agency subversion. Large Internet companies have now started or accelerated efforts to encrypt communication paths both with users and within their own networks using TLS. The April 2014 E.U. Parliament amendments not only ignore these developments, but also make explicit that the HTTPS provision is “entirely voluntary” for Web services (recital 67).
Security requirements. The E.U. proposal introduces new obligations for CAs to adopt security requirements. Their details will be determined by the European Commission in a so-called implementing act. While such delegation to the executive branch provides some flexibility to adapt requirements to new technological developments, the E.U. proposal fails to specify regulatory priorities or underlying values. Moreover, the April 2014 parliament amendments literally state that “industry-led initiatives (for example, CA/Browser Forum)” influence such requirements (recital 67). Naming a CA industry group as influential in a law that seeks to address failing security practices of CAs indicates control by dominant market players.
Security breach notification (SBN). In theory, SBNs help minimize the damage after a breach has occurred and provide incentives for organizations to invest in information security upfront. The E.U. proposal introduces an SBN regime stating that notification needs to occur “within 24 hours” to relevant authorities if the breach “has a significant impact,” a concept that is not defined in the law. The general public is informed when a breach harms the “public interest” (also undefined). Again, the European Commission will determine those details, but the parliament proposal states that CAs should be subject to “light-touch and reactive ex-post supervisory activities” and that there exists “no general obligation to supervise nonqualified service providers” (that is, CAs offering certificates for HTTPS).
Aforementioned information asymmetries and CA breaches render defensible a strict regime for notifications—which types of breaches should be made public by default, for example. Experiences with SBN legislation in the U.S., moreover, suggest SBNs need to be complemented with punitive (for example, sanction and liability regimes) and proactive enforcement (for example, as part of annual reporting) to create real incentive to notify—and avoid noncompliance by less well-intentioned companies.1,22 In addition, reputation losses might not affect major CAs that do not risk being thrown out of root stores for nonreporting. Reporting not only breaches, but also the vulnerabilities that led to them, would be a major step forward, as would a scheme of responsible disclosure. Such lessons are not included in the E.U. proposals or considerations. Moreover, the parliament has further weakened the SBN regime by mandating light-touch and ex-post supervision. Again, these amendments indicate capture of the regulatory process by dominant CAs.
Liability. As already observed, liability for security breaches is disclaimed across the HTTPS ecosystem and transferred through terms and conditions to end users. The 2012 E.U. Commission proposal sought to address such liability dumping by imposing a strict liability regime on CAs for “any direct damage,” with CAs bearing the burden of proving they handled the situation non-negligently. The 2014 parliament amendments reverse this burden of proof; customers and users now have to prove malicious intent or negligence at CAs post-breach. Moreover, CAs are allowed to transfer liability in their terms and conditions to end users. Astonishingly, the parliament explicitly codifies liability dumping. Again, there are traces of regulatory capture at the E.U. parliament.
The weakest-link problem of HTTPS creates more fundamental problems with security through liability: small CAs will be unable to conduct business with large corporations processing vast amounts of sensitive data. Consider DigiNotar with its an annual budget of a few million U.S. dollars; it could never cover damages for the rogue certificates that were issued for Google, Facebook, Skype, cia. gov, among others, in the midst of its security breach. Smart CAs will thus circumvent liability by creating subsidiary special-purpose companies that bear full liability and can easily file for bankruptcy. Indeed, DigiNotar quickly went bankrupt post-breach, while its parent company Vasco has escaped unscathed.
Tackling fundamental issues with liability regimes requires carefully crafted policies or broad mandates for enforcement. Liability should be matched with security requirements and distributed among all stakeholders: domain owners should have incentives to protect their assets through HTTPS offering and implementation,2 while browsers should strengthen their CA policies (as discussed later). The European Commission failed to consider such fundamental drawbacks, and the parliament amendments make matters worse by codifying liability dumping and reversing the burden of proof.
Chain of trust transparency. Unrelated to the E.U. proposals, Mozilla has proposed the so-called “chain of trust transparency.” As discussed earlier, one cannot assure that HTTPS communications are subject to systematic but unnoticed surveillance without transparency,23 but today it is only starting to emerge through various (research) projects such as the browser plug-in CertPatrol for Firefox.
In a recent amendment to its CA policy, Mozilla requires that subordinate CA certificates “either be technically constrained or be publicly disclosed and audited.”19 Subordinate CAs, in other words, must either be constrained to issue certificates for only a (small set of) domain name(s)—on internal networks, for example—or their chain of trust must be publicly disclosed and audited. The aim is to hold subordinate CAs to similar standards as root CAs and make a root CA accountable for all the sub-certificates it signs. Existing subordinate CA certificates were given until May 15, 2014, to comply, so it is too early to observe how Mozilla enforces noncompliance. Nonetheless, chain of trust transparency warrants at least consideration and, from a theoretical perspective, encouragement throughout the HTTPS ecosystem.21 So far, it has not been part of any regulatory proposal.
Technology solutions. A host of technological solutions to the systemic vulnerabilities of the current system are being developed. Among the most prominent are Convergence, Perspectives, DANE, Sovereign Keys, Certificate Transparency, Public Key Pinning, and TACK. From the perspective of governance, we can make several general observations:
- All proposals attempt to solve the weakest-link problem by introducing another authority to check whether the certificate that is validated through the normal HTTPS process is indeed the correct one.
- All proposals reduce the information asymmetry of buyers and users, versus the CAs, by systematically uncovering suspect certificates.
- All proposals can function on top of the current CA system, leaving it in place or depending on it; a subset can also replace it.
- All proposals can follow incremental adoption paths (albeit some are a lot more difficult than others), and all need support from browsers.
None of these solutions is close to large-scale adoption. That said, they do seem promising in terms of addressing the current weaknesses, especially the weakest-link problem, for which regulatory solutions appear ineffective. Therefore, in the long run they are preferable, and it is relevant to assess how they relate to the incentives of the HTTPS stakeholders. Some scholars predict multiple proposals will eventually be adopted.5
Not unlike the financial sector, the HTTPS market is full of information asymmetries and negative externalities, as a handful of CAs dominate the market and have become “too big to fail.”
As argued earlier, the insecure status quo can be beneficial for market leaders. In light of this, one might assume that CAs are not particularly keen on actively helping any of these proposals along, especially the ones that theoretically could make them obsolete. In practice, however, some CAs are involved in developing potential solutions—for example, DigiCert and Comodo are experimenting with Certificate Transparency.16 Other proposals require nontrivial activities on the side of the domain owner, which may be done by their CA as a complementary service to current business models.
Furthermore, each proposal is intensely debated in relation to browser performance. Any form of large-scale adoption requires default support by browser vendors. Google and Mozilla have been particularly active in this area.
While none of these solutions is easy to scale, there are benefits for early adopters, a key requirement for any solution to take off. Whether the costs are worth it depends on the kinds of threats HTTPS stakeholders want to defend themselves against. An average cybercriminal might not be interested in breaching a CA and manipulating network traffic already encrypted through HTTPS, as financially attractive information can be acquired through more cost-effective attacks.11,17 From previous breaches, it appears that state-sponsored attackers and large corporations, rather than profit-driven criminals, are more likely to engage in the complex man-in-the-middle attacks in the realm of HTTPS. For some user groups and domains, such adversaries make early adoption attractive.
Conclusion
Recent breaches at CAs have exposed several systemic vulnerabilities and market failures inherent in the current HTTPS authentication model: the security of the entire ecosystem suffers if any of the several hundreds of CAs is compromised (weakest link); browsers are unable to revoke trust in major CAs (“too big to fail”); CAs manage to conceal security incidents (information asymmetry); and ultimately customers and end users bear the liability and damages of security incidents (negative externalities).
Understanding the market and value chain for HTTPS is essential to address these systemic vulnerabilities. The market is highly concentrated, with very large price differences among suppliers and limited price competition. Paradoxically, the current vulnerabilities benefit rather than hurt the dominant CAs, because among others, they are too big to fail.
In terms of solutions, the E.U. has opted for a regulatory response, while the U.S. prefers industry self-regulation and technological solutions. In general, the technological solutions aim to solve the weakest-link security problem of the HTTPS ecosystem. Several proposals are promising, but none is near large-scale adoption. Industry self-regulation has only augmented market failures, rather than solve them.
The proposed E.U. regulation does not consider the role of all stakeholders in the HTTPS ecosystem, thus reinforcing systemic vulnerabilities by creating new long-term institutional dependencies on market-leading CAs. The April 2014 E.U. Parliament amendments make matters much worse. The E.U. Parliament seems to have been successfully captured by CA lobbying efforts.
Regardless of major cybersecurity incidents such as CA breaches, and even the Snowden revelations, a sense of urgency to secure HTTPS seems nonexistent. As it stands, major CAs continue business as usual. For the foreseeable future, a fundamentally flawed authentication model underlies an absolutely critical technology used every second of every day by every Internet user. On both sides of the Atlantic, one wonders what cybersecurity governance really is about.
Acknowledgments
The authors thank Bernhard Amann, Ian Brv own, Peter Eckersley, Edward Felten, Sharon Goldberg, Joris van Hoboken, Ralph Holz, Chris Hoofnagle, Kees Keuzenkamp, Samad Khatibi, Arman Noroozian, Bruce Schneier, Stephen Schultze, Christopher Soghoian, Sid Stamm, Marcelo Thompson, and participants of TPRC 2012, WEIS 2013, two workshops at the Berkman Center in Spring 2014, 29c3, a UC Berkeley TRUST Seminar January 2013, and an HKU Law & Tech Talk, February 2013. The authors are solely responsible for this article.
Related articles
on queue.acm.org
Securing the Edge
Avi Freedman
http://queue.acm.org/detail.cfm?id=640149
The Seven Deadly Sins of Linux Security
Bob Toxen
http://queue.acm.org/detail.cfm?id=1255423
Security in the Browser
Thomas Wadlow and Vlad Gorelik
http://queue.acm.org/detail.cfm?id=1516164
Figures
Figure 1. HTTPS authentication data flows.
From
Join the Discussion (0)
Become a Member or Sign In to Post a Comment