FIGHTING BACK AGAINST SSL INSPECTION, OR HOW SSL SHOULD WORK

Jacob Thompson, Independent Security Evaluators

Enterprise networks increasingly intercept and inspect SSL-protected employee web traffic—often without adequate understanding on the employee's behalf—and almost certainly without the consent of the entity operating the server. The cases of Trustwave, TURKTRUST, and ANSSI illustrate how the confidentiality of client-server communications is further threatened by the mounting abuse, misuse, incompetence, and compromise of trusted certificate authorities. Prior notice and the need to install custom root certificates are no longer technical hurdles impeding SSL interception, and security professionals should fear the possibility that SSL interception could expand beyond enterprises in the near future. Much previous work has focused on detecting this interception at the client; we discuss how to leverage built-in browser and server capabilities, well understood in academia but rarely used in practice, to achieve mutual authentication, moving the decision of whether to allow SSL interception and inspection from the client to the server.

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.

Mutual Authentication and SSL Interception

A solution for resisting SSL interception without breaking compatibility or requiring cooperation with third parties is needed. The SSL/TLS protocol allows not only servers to authenticate themselves using certificates, but clients as well. Client certificates are widely popular in some government agencies and countries, such as Estonia [27], but are not used by websites catering to the general (US) public. Interestingly, client certificates allow us to sidestep the interception problem.

First, enterprises have absolutely no control over the list of trusted client certificate authorities present on third-party web servers. Second, web servers can be set up to issue their own certificates, rather than rely on a third party CA. Since an interception device has no way to produce an acceptable client certificate on its own, it can only obtain one by extracting the certificate and key from an end user's device, or by subverting the process used by a legitimate client to obtain a certificate in order to frauduluently obtain one.

In fact, all web browsers include support for generating RSA key pairs in order to facilitate the issuing of client certificates, and have for many years. The HTML keygen tag causes the browser to generate a key pair, retain the private key, and transfer the public key to a server as part of a form submission. This tag is supported by Chrome, Firefox, and Safari; Internet Explorer offers similar functionality through the certificate enrollment control. After receiving the public key, the server can generate a signed certificate and return it to the browser. Then, the browser immediately adds the certificate to its store of client certificates and allows it to be used for authentication to the server.

How should the server verify a user's identity before issuing a certificate? As in any PKI system, this is a difficult problem. Since we are leveraging client certificate authentication only to frustrate man-in-the-middle attacks, and not to truly verify a client's identity, we could ignore this issue, and allow the server to blindly sign any certificate requests that it receives. In fact, this would be similar to the level of security provided by SSH: as long as the very first connection to a server is not intercepted, a user would receive and retain a valid certificate. The user would never again need to go through the enrollment process unless the certificate were deleted, the user moved to a different device, or the certificate expired.

Instead, we have built a limited amount of identity verification into our proposed solution. We simply have the server generate a 128-bit enrollment key, and send it to the user through an out-of-band channel. Then, as long as either the public key is encrypted with this key before it is sent to the server, or the signed certificate is encrypted with this key before it is returned to the client, a man-in-the-middle cannot complete the enrollment process without possessing the key. Thus, the man-in-the-middle must obtain the key from the user, e.g. through phishing.

For Firefox and Safari, the solution works as follows:

  1. The user access the website in its original form, e.g., mutual.www.ise.io, which does not require client authentication.
  2. The resulting page tests for the presence of a client certificate by attempting to load an iframe from a mutually-authenticated server, in this case, www.mutual.www.ise.io.
  3. If the iframe load succeeds, then the user must already have a client certificate, and JavaScript code within the iframe redirects the user to the mutually-authenticated website.
  4. If the redirection has not occurred within a few seconds, then the iframe load must have failed. Therefore, the user must not have a certificate, and we begin the enrollment process.
    1. The user enters an e-mail address and CAPTCHA in order to receive the out-of-band key.
    2. The keygen tag is used to generate a certificate request and send it to the server.
    3. The server signs a certificate, encrypts it using the out-of-band key, and returns the encrypted certificate back to the client.
    4. JavaScript code prompts the user for the out-of-band key, and then uses it to decrypt and install the received certificate (entirely at the client side).
    5. The user can then access the mutually-authenticated server.

The process for Chrome is similar, but as limitations in Chrome prevent a certificate from being decrypted and then installed using JavaScript, the certificate request is encrypted, instead. We acknowledge that a MAC is a more correct solution for this purpose.

Example

An example server implementing this solution is available at mutual.www.ise.io.

Attribution and Acknowledgements

This research was conducted by Jacob Thompson and directed by Stephen Bono.

References

[1] Jarmoc, Jeff. SSL Interception Proxies and Transitive Trust. Black Hat Europe 2012, Amsterdam, Netherlands.

[2] Trustwave to escape 'death penalty' for SSL skeleton key

[3] Trusted Root Signing Certificates

[4] Enhancing digital certificate security

[5] Further improving digital certificate security

[6] DNS Hijacking - Manipulation by ISPS

[7] UK government to activate adult content filters by default

[8] Comcast Wi-Fi serving self-promotional ads via JavaScript injection

[9] Managing Encrypted Traffic With Blue Coat Solutions

[10] Mobile Workers: 'I Want My BlackBerry Back'

[11] GeoRoot

[12] EFF SSL Observatory Map of CAs

[13] Adventures in X.509: The Utterly Ignored nameConstraints

[14] Analysis of the HTTPS Certificate Ecosystem

[15] French gov used fake Google certificate to read its workers' traffic

[16] The "Certificate Authority" Trust Model for SSL: A Defective Foundation for Encrypted Web Traffic and a Legal Quagmire

[17] DigiNotar Removal Follow Up

[18] Revoking Trust in one ANSSI Certificate

[19] Netcraft blog, violations of CABF Baseline Requirements, any consequences?

[20] Is This MITM Attack to Gmail's SSL? [sic]

[21] Certificate Blacklisting in Jelly Bean

[22] Convergence

[23] New Chromium security features, June 2011

[24] Public Key Pinning

[25] An update on attempted man-in-the-middle attacks

[26] Certificate Transparency

[27] Practical Issues with TLS Client Certificate Authentication