FIGHTING BACK AGAINST SSL INSPECTION, OR HOW SSL SHOULD WORK

Introduction

Internet users, including many security professionals, often blindly rely on SSL/TLS to provide the confidentiality and integrity of our personal data, at least when using our web browsers. We expect SSL/TLS to do so even in the face of attackers with the ability to hijack and redirect our network connections and DNS traffic (i.e., a man-in-the-middle attack). To resist these attacks, our browsers rely on a list of trusted certificate authorities to authenticate server certificates. Browser vendors audit these certificate authorities, but must presume that neither the trusted root authorities nor any intermediate authorities chaining to a trusted root will sign a certificate for an entity without first verifying that the entity controls the domain name listed in the certificate.

Unfortunately, our faith in SSL/TLS is increasingly misplaced. Accompanying the string of severe security vulnerabilities affecting SSL/TLS libraries in recent years are three specific issues that undermine our browsers' ability to verify a server's certificate:

• The list of trusted certificate authorities on a client device can be customized. This is an issue in any situation where the user of a device is not also the administrator. Corporate enterprises often use this ability to add a custom, internally controlled CA to the list, used solely to sign phony certificates for the purpose of SSL interception [1].
• Some certificate authorities have allowed devices to be constructed, containing an intermediate CA chaining to a trusted root, for the explicit purpose of producing phony certificates on-the-fly to perform SSL interception while avoiding certificate warnings or the need to install a custom CA into each client device [2].
• Large organizations can obtain and internally operate a sub-CA chaining to a trusted root, allowing them to issue certificates to their servers in bulk, rather than submit an individual requests to the CA for each server [3]. Frequently, no technical constraints prevent an organization from using the sub-CA to issue certificates for domains they do not own. Though legal agreements may preclude it, these organizations can and at times do, without the root CA's permission, load their sub-CA into an interception device to perform man-in-the-middle attacks with phony certificates that appear legitimate to browsers [4, 5].

In light of these issues, and the inability of browser vendors to effectively police certificate authorities that fail to fulfill their important responsibilities in the Internet security infrastructure, technical solutions have been proposed to supplement or replace the traditional CA-based model. Of those solutions that augment the existing CA infrastructure, rather than replace it, nearly all are fully client based (e.g., certificate pinning). The server still has no way to detect and block attempted SSL/TLS interception attacks.

For some time, all significant web browsers have had the built-in capability to generate public-private key pairs. Long known in academia but rarely used in practice, this can be leveraged to achieve mutual client-server authentication. The server acts as its own certificate authority for the purpose of authenticating the client. In doing so, we replace an SSL interception device's problem of producing a phony server certificate to suppress warnings on the client with the harder problem of fraudulently obtaining a client certificate from the server. With a sufficiently secure process in place for obtaining the client certificate, we allow the server to resist, if not prevent, automated interception, or at least require an interception device to perform attacks that may cross legal boundaries in order to obtain the client certificate, such as phishing.

SSL/TLS Interception

Routine SSL/TLS interception is rarely performed outside of enterprise networks today. Still, just as hijacking failed DNS queries [6], imposing opt-out content filtering [7], and injecting JavaScript advertisement code [8] have become routine and accepted behavior among ISPs, we fear that interception could reach public networks in the future, in light of certificate authorities' demonstrated willingness to assist in performing it. Just as these three examples are touted by ISPs as "helping" their users, SSL/TLS interception could be cast in a positive light as an anti-malware or content filtering feature.

In this section, we provide enterprises' motivations to perform interception and an overview of how it occurs, explore three recent examples demonstrating public certificate authorities' role in interception, and review the inability of browser vendors to effectively prevent the authorities from doing so.

Corporate Interception

Large enterprises are justifiably concerned with the risk that Internet connectivity presents. Potential unauthorized data egress could lead to financial and reputational harm. In order to monitor for this, many large corporations implement data loss prevention (DLP) systems, which put proxy servers in place to monitor traffic for sensitive data or malware.

In the past, many websites used HTTPS in exceptional cases, such as the transmission of the password from a login page, or receiving credit card information. Thus, the end-to-end security provided by SSL/TLS was not a major issue for the DLP system. More recent web applications use HTTPS to protect the entire site. The pervasive use of HTTPS for webmail, social networking sites, forums, and chat clients introduces a significant attack surface allowing incoming malware or outgoing confidential data to travel through the network without detection. Data loss prevention systems now include SSL/TLS inspection as a feature; some vendors of these applicances claim that an organization cannot be HIPAA or Sarbanes-Oxley (SOX) compliant without SSL inspection [9].

The advent of bring your own device (BYOD) environments is challenging and raises many questions. The use of SSL interception against these devices, and the presence of mobile device management (MDM) in general, mean that from security and privacy perspectives the device is, for all intents and purposes, company owned. Particular issues include:

• How is personal and business use of the device distinguished to ensure that only business traffic is intercepted and monitored?
• Who ensures that the interception stops if a user leaves the company?
• What stops the interception if a user gives a device to a family member as a hand-me-down and buys another?
• Misunderstandings about the role of the device (treated as personal by the employee outside of work hours, but as company by the enterprise) could lead to significant issues, e.g., if confidential employee communications with OHSA, the EEOC, the NLRB, or other regulatory agencies is inadvertently monitored and captured by the employer.

We concede that SSL interception in a business environment may be a case of making the best of a bad situation, under certain conditions: (1) the interception is facilitated using an internal certificate authority that does not chain to a publicly trusted root, to preserve the security model of public certificate authorities, (2) the interception is performed only against company-owned or controlled (BYOD) devices, and (3) users expressly consent to the monitoring (e.g., through a network usage agreement) and truly understand its implications. But corporate employees are just beginning to become aware of the privacy implications of business security controls [10], and thus we believe that an entity operating a web server should be able to protect its users by detecting SSL/TLS interception, if desired.

CA-Assisted Interception

As long as publicly-trusted root certificate authorities (and all intermediate certificate authorities chaining to those roots) fulfill their role in the web's security model by refusing to provide signed certificates to anyone other than a domain's owner, wide-scale, robust SSL/TLS interception is not possible in the absence of unrelated security vulnerabilities. Without the ability to produce trusted yet phony certificates for servers while performing interception, a system must use its own custom certificate authority to produce those certificates, with one of two consequences: (1) the need to install the custom authority as trusted on all machines affected by the interception, or (2) the need to override certificate warnings on all affected devices.

An important concept in the certificate authority industry is the concept of a subordinate certificate authority (sub-CA), also known as an external CA. Sub-CAs allow businesses who are not in the CA business to act as a CA regardless, by obtaining a sub-CA that chains to a trusted root. The purpose of sub-CAs is to allow businesses with the need to issue large numbers of certificates to their own devices to manage this process on their own, rather than interacting with a public CA each time a certificate is needed. GeoTrust is one certificate authority that issues sub-CAs; in order to obtain one, an organization must have a five-million dollar net worth [11]. Many large companies own sub-CAs, including Aetna, EarthLink, Dell, Ford, Fuji Xerox, General Electric, Google, and Wachovia [12].

The problem with sub-CAs is in preventing an entity with a sub-CA from signing certificates for domains that it does not own. The X.509 field used to restrict the scope of domain names that a CA can sign, name constraints, is not widely supported [13]. In fact, a survey of the entire IPv4 address space found 1,832 trusted (intermediate or root) CAs, of which only 7 had name constraints imposed [14].

Consider how three recent examples involving sub-CAs being used to produce phony certificates show that the classical root certificate authority-based trust model is breaking down:

1. Trustwave. In 2012, Trustwave issued a sub-CA to a private organization [2]. This sub-CA was to be loaded into a device performing a man-in-the-middle attack, and its sole purpose was to allow that device to generate trusted certificates for arbitrary domains, allowing interception against all devices on the network. This approach avoided the need to install a custom root certificate across all device, and also prevented certificate warnings, by chaining the phony certificates to Trustwave.
2. TURKTRUST. In 2013, a sub-CA issued by TURKTRUST, a root certificate authority based in Turkey, issued a phony certificate for the google.com domain. The certificate pinning capabilities added to Chrome by Google detected this certificate in the wild [4].
3. ANSSI. Also in 2013, ANSSI, a root certificate authority controlled by the French government, issued a sub-CA to the French treasury department, IGC/A, and IGC/A in turn used the sub-CA to intercept and monitor employee web traffic [15].

Failure to Effectively Police Certificate Authorities

When failures in the certificate authority trust model keep occurring each year, what consequences or penalties apply to the certificate authorities? A legal analysis of certificate authorities found that certificate authorities often use legal language to disclaim any warranty for a party relying on one of their certificates, and the case of an end user relying on a false certificate is untested in court [16]. Thus, the only effective recourse against misbehaving certificate authorities is for browser vendors to remove those authorities from the list of trusted CAs distributed with browsers.

As removing a trusted CA from browsers in response to a handful of invalid certificates causes collateral damage (all sites using valid certificates issued by that CA would begin receiving certificate warnings), the browser vendors have been reluctant to do so. The only prominent example was DigiNotar, whose trust was revoked only after DigiNotar itself was compromised [17].

A review of Mozilla's security policy newsgroup [18, 19] illustrates the frustration that many in the Mozilla security community have with the inability to effectively police certificate authorities. Despite the fact that ANSSI was non-compliant with Mozilla and CA/Browser Forum policies, and the fact that both the TURKTRUST and ANSSI compromises had to be detected by third parties, rather than caught and self-reported by the CAs themselves, Mozilla determined that removing these CAs from the trusted list would be too disruptive. It is clear that there is little incentive for certificate authorities to make the investment in improving their practices as long as even the CAs with the poorest practices remain trusted.

When a compromise or abuse of a certificate authority does occur, blacklisting the affected certificates on client devices may happen only after a lengthy delay, if at all. The DigiNotar CA compromise was detected on August 27, 2011 [20], but the first iOS release to remove DigiNotar from the trusted store occurred on October 13, 2011—nearly three months later. On some older Android devices, the end user could not control the built-in trusted certificate store at all; a certificate blacklist feature was not added until the Jellybean release (4.2) [21].

Prior Work

Since it is evident that the integrity of root certificate authorities as a whole is unlikely to improve in the near future, many have worked on developing solutions. Some propose to replace the CA trust model entirely, such as the Convergence system by Marlinspike [22]. Others, such as Google, seek to build more defense-in-depth security checks into the existing model.

Certificate pinning as implemented by Google Chrome [23] and Mozilla Firefox [24] allows the browser to maintain a pre-loaded list of acceptable public keys for a handful of high-profile websites, such as Google, Twitter, and Facebook. This feature has already detected real-world attacks [25]. The limitation of certificate pinning (as of this writing) is that each protected site must be explicitly built into the browser, and requires cooperation with the browser vendors in order to add a new site, so it is not scalable to any but the highest-profile websites at this time. Other solutions, such as the Certificate Transparency initiative [26], aim to improve certificate authorities by having the authorities make a public log available containing their signing actions.