TrustBase: An Architecture to Repair and Strengthen Certificate-based Authentication Mark O’Neill Scott Heidbrink Scott Ruoti Jordan Whitehead Dan Bunker Kent Seamons Daniel Zappala Brigham Young University [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Abstract—We describe TrustBase, an architecture that pro- were fabricated by the intruder, including a certificate vides certificate-based authentication as an operating system ser- for Gmail that allowed the intruder to access stored vice. TrustBase enforces best practices for certificate validation for email for 300,000 Iranians [27]. This happened despite all applications and transparently enables existing applications to the fact that Gmail does not use DigiNotar to sign its be strengthened against failures of the CA system. The TrustBase certificates. This problem is exacerbated by CAs that do system allows simple deployment of authentication systems that not follow best practices [34], [11] and governmental harden the CA system. This enables system administrators, for example, to require certificate revocation checks on all TLS ownership and access to CAs [13], [42]. connections, or require STARTTLS for email servers that support • Improvements to the CA system have difficulty it. TrustBase is the first system that is able to secure all TLS being widely deployed. Protocols to enhance the traffic, using an approach compatible with all operating systems. certificate validation process have been developed, but We design and evaluate a prototype implementation of TrustBase on Linux, evaluate its security, and demonstrate that it has the majority of applications have not yet integrated negligible overhead and universal compatibility with applications. these improvements. Even relatively simple fixes, such To demonstrate the utility of TrustBase, we have developed six as certificate revocation, are beset with problems [31]. authentication services that strengthen certificate validation for There is no widely-adopted platform assisting the de- all applications. ployment of improvements to the CA system, meaning researchers and developers have to individually modify I. INTRODUCTION applications to make advances, which severely limits their deployment. Server authentication on the Internet currently relies on the certificate authority (CA) system. While establishing a In this paper, we introduce TrustBase, an architecture for cer- secure SSL/TLS session with a server, clients receive a digital tificate authentication that solves each of these three problems. certificate that vouches for the identity of the server. This TrustBase is designed to (1) secure existing applications, (2) certificate is signed by a certificate authority, and the signature strengthen the CA system, and (3) provide simple deployment is validated against a list of certificate authorities that is shipped of improved authentication systems. with the client or operating system. This provides assurance To address these problems, TrustBase complements the that the client is connected to a legitimate server and not one existing certificate validation performed by applications with controlled by an attacker. additional validation methods that are enforced by the operating Unfortunately, certificate validation is challenged by three system. This approach has several advantages. First, it protects significant problems: against insecure applications—too much evidence shows that developers make mistakes, and this will only get more diffi- arXiv:1610.08570v1 [cs.CR] 26 Oct 2016 • Applications frequently do not properly validate cult as additional authentication methods such as Certificate the server’s certificate [20], [17], [6]. This is caused Transparency [29], [41], pinning [16], [33], and DANE [22] by failure to use validation functions, incorrect usage become more widely available. Second, it transparently enables of libraries, and also developers who disable validation existing applications to be strengthened against failures of the during development and forget to enable it upon CA system. For example, a browser that validates the EV release [18]. These implementation mistakes deceive cert of a bank is doing the best it currently can, but it is the user into believing her session is secure, while still vulnerable to a CA that is hacked, allowing a man-in-the leaving the application vulnerable to man-in-the-middle middle (MITM) to present fake but valid certificates. TrustBase (MITM) attacks. provides complementary authentication services that protect against these situations, such as checking notaries to ensure • The CA system is vulnerable to being hijacked even other hosts across the Internet are seeing the same certificate when applications are implemented correctly. This for the bank.1 Third, it enables a system administrator to ensure is largely due to the fact that most CAs are able to best security practices are properly followed. TrustBase allows sign certificates for any host, reducing the strength of the administrator for an organization to enforce consistent the CA system to that of the weakest CA [12]. This weakness was exploited in 2011 when DigiNotar’s 1Certificates for a notary service can be pinned in advance, so they are not servers were hacked and more than 500 certificates vulnerable to the MITM. certificate validation across all applications, such as requiring We also demonstrate the ability of TrustBase to fix revocation checking or mandating that pinning is used to protect applications that do not validate hostnames or skip against MITM attacks. TrustBase provides administrators with certificate validation altogether. a choice of authentication services that can be used to harden the CA system.2 • An evaluation of TrustBase: We evaluate the Trust- Base prototype for performance, compatibility, and We identify a number of design goals for TrustBase, utility. (1) We show that TrustBase has negligible including full application coverage, universal deployment, and performance overhead, with no measurable impact on negligible overhead. To meet these goals, TrustBase uses latency. (2) We demonstrate that TrustBase enforces traffic interception between the socket layer and the transport correct certificate validation on all popular Linux layer, an approach that is general enough to work on all libraries and tools and on the most popular Android major operating systems, both desktop and mobile. TrustBase applications. (3) We describe six authentication services detects the initiation of TLS connections, finds the handshake that we have developed and report on how simple and information, validates the server’s certificate using a variety of straightforward it was to develop these services in configurable authentication systems, and then allows or blocks TrustBase. the connection based on the results of this additional validation. This allows TrustBase to harden the certificate validation of all II. RELATED WORK applications, regardless of which libraries they use. For new or modified applications, TrustBase provides a simple certificate The typical goal of an attacker who wishes to subvert TLS is validation API that can be called directly. to perform a MITM attack on unsuspecting clients, substituting his own certificate in place of the original. In this section we Our contributions include: discuss flawed implementations, weaknesses of the CA system • An architecture for enforcing best practices for that make these attacks possible, and various alternatives to the certificate validation on all applications: TrustBase CA system that have been developed. We then discuss related requires standard certificate validation procedures and projects that try to address the problems affecting applications optionally adds additional authentication services, both and the CA system. of which are enforced by the operating system and controlled by the administrator. This repairs broken A. Flawed Implementations validation for poorly-written applications and option- ally strengthens the validation done by well-written Several studies demonstrate widespread vulnerabilities in applications. Applications are allowed to be more strict, client-side validation of certificates, in both mobile and desktop but not less strict than TrustBase in their validation environments. Georgiev et al. [20] discovered that many decisions. critical software applications outside the browser rely on completely broken TLS validation libraries, primarily due to • Simplified deployment of authentication systems poorly designed APIs. Brubaker et al. [6] conducted a large- that strengthen the CA system: TrustBase provides scale experiment of TLS implementations using millions of a plugin API and a policy engine that dynamically “frankencerts”, random certificates generated from portions of loads authentication systems based on administrator real certificates. They discovered hundreds of flaws in popular preferences. They can be written in either C or Python, TLS libraries and browsers. Fahl et al. [17] analyzed 13,500 with the ability to add support for additional languages. popular Android apps and determined that 8% were vulnerable The administrator can use policies to define how to TLS MITM attacks. Lucky et al. [37] experimented with multiple authentication systems cooperate, for example 100 popular Android apps and found that several accept all using unanimous consent or threshold voting. certificates and all hostnames, along with other unsafe practices. • A research prototype of TrustBase for Linux: We There