TrustBase: An Architecture to Repair and Strengthen Certificate-based Authentication Mark O’Neill, Scott Heidbrink, Scott Ruoti, Jordan Whitehead, Dan Bunker, Luke Dickinson, Travis Hendershot, Joshua Reynolds, Kent Seamons, and Daniel Zappala, Brigham Young University https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/oneill This paper is included in the Proceedings of the 26th USENIX Security Symposium August 16–18, 2017 • Vancouver, BC, Canada ISBN 978-1-931971-40-9 Open access to the Proceedings of the 26th USENIX Security Symposium is sponsored by USENIX TrustBase: An Architecture to Repair and Strengthen Certificate-based Authentication Mark O’Neill Scott Heidbrink Scott Ruoti Jordan Whitehead Dan Bunker Luke Dickinson Travis Hendershot Joshua Reynolds Kent Seamons Daniel Zappala Brigham Young University [email protected], [email protected], [email protected], [email protected], [email protected] [email protected], [email protected], [email protected] [email protected], [email protected] Abstract of end-to-end encryption [24, 34], with many firewalls having significant implementation bugs that break authen- The current state of certificate-based authentication is tication [7, 11]. Third, the CA system itself is vulnerable messy, with broken authentication in applications and to being hijacked even when applications and proxies are proxies, along with serious flaws in the CA system. To implemented correctly. This is largely due to the fact solve these problems, we design TrustBase, an architec- that most CAs are able to sign certificates for any host, ture that provides certificate-based authentication as an reducing the strength of the CA system to that of the weak- operating system service, with system administrator con- est CA [12]. This weakness was exploited in the 2011 trol over authentication policy. TrustBase transparently DigiNotar hack [25], and is exacerbated by CAs that do enforces best practices for certificate validation on all not follow best practices [31, 10] and by governmental applications, while also providing a variety of authentica- ownership and access to CAs [13, 40]. tion services to strengthen the CA system. We describe a research prototype of TrustBase for Linux, which uses a Due to these problems, there are a number of recent loadable kernel module to intercept traffic in the socket proposals to improve or replace the current CA trust layer, then consults a userspace policy engine to evaluate model. These include multi-path probing [31, 41, 1, 23] certificate validity using a variety of plugins. We evaluate or other systems that vouch for the authenticity of a certifi- the security of TrustBase, including a threat analysis, ap- cate [15, 2, 3], DNS-based authentication [21], certificate plication coverage, and hardening of the Linux prototype. pinning [16, 32], and audit logs [27, 39, 14, 26]. Unfortu- We also describe prototypes of TrustBase for Android nately, the majority of applications have not yet integrated and Windows, illustrating the generality of our approach. these improvements. Even relatively simple fixes, such We show that TrustBase has negligible overhead and uni- as certificate revocation, are beset with problems [29]. versal compatibility with applications. We demonstrate The result is that there is no de facto standard regarding its utility by describing eight authentication services that where and how certificate validation should occur, and it extend CA hardening to all applications. is currently spread between applications, TLS libraries, and interception proxies [11]. Several projects have tried to address these issues, fix- 1 Introduction ing broken authentication in existing applications, while providing a means to deploy improved authentication ser- Server authentication on the Internet currently relies on vices. Primary among these is CertShim, which uses the the certificate authority (CA) system to provide assurance LD PRELOAD environment variable to replace functions in that the client is connected to a legitimate server and not dynamically-loaded security libraries [4]. However, this one controlled by an attacker. Unfortunately, certificate approach does not provide universal coverage of all exist- validation is challenged by significant problems. First, ap- ing applications, does not provide administrators singular plications frequently do not properly validate the server’s control over certificate authentication practices, does not certificate [20, 17, 5, 35]. This is caused by failure to protect against several important attacks, and has signifi- use validation functions, incorrect usage of libraries, and cant maintenance issues. Fahl takes a different approach also developers who disable validation during develop- that rewrites the library used for authentication by An- ment and forget to enable it upon release. Second, TLS droid applications [18], while also including pluggable interception, used by numerous firewall appliances and authentication modules. This approach is well-suited for software (as well as malware), compromises the integrity Android because all applications are written in Java, but USENIX Association 26th USENIX Security Symposium 609 it is difficult to extend this approach to operating sys- TrustBase enables system administrators and OS ven- tems that provide more general programming language dors to enforce a number of policies regarding TLS. For support. example, an administrator could require revocation status In this paper, we explore a different avenue for fixing checking, disallow weak cipher suites, or mandate that these problems by centralizing authentication as an operat- Certificate Transparency be used to protect against active ing system (OS) service and giving system administrators man-in-the-middle (MITM) attacks. An OS vendor could and OS vendors control over authentication policy. These ship TrustBase with strong default protections against two motivating principles result in TrustBase, an archi- broken applications, such as enforcing best practices for tecture for certificate authentication that secures existing validating a certificate chain, requiring hostname valida- applications, provides simple deployment of improved tion, and pinning certificates for the most popular web authentication services, and overcomes shortcomings of sites and applications. As TLS becomes more widespread, previous approaches. TrustBase provides universal cov- TrustBase could easily be extended to provide the capa- erage of existing applications, supports both direct and bility to report on the use of all applications that do not opportunistic TLS1, is hardened against unprivileged lo- use TLS, so that an organization could better manage or cal adversaries, is supported on both mobile and desktop even block insecure applications. All of these improve- operating systems, and has negligible overhead. ments can be made without requiring user interaction or To centralize authentication as an operating system ser- configuration. vice, TrustBase uses a combination of traffic interception Our contributions include: to harden certificate validation for existing applications and a validation API to simplify authentication for new • An architecture for certificate validation that pri- or modified applications. TrustBase intercepts network oritizes operating system centralization and sys- traffic between the socket layer and the transport layer, tem administrator control: TrustBase offers stan- where it detects the initiation of TLS connections, extracts dard certificate validation procedures and option- handshake information, validates the server’s certificate ally adds additional authentication services, both using a variety of configurable authentication services, of which are enforced by the operating system and and then allows or blocks the connection based on the re- controlled by the administrator or OS vendor. This sults of this additional validation. This allows TrustBase repairs broken validation for poorly-written appli- to harden certificate validation in an application-agnostic cations and can strengthen the validation done by fashion, irrespective of what TLS library is employed. all applications. TrustBase provides a policy engine TrustBase also includes a simple certificate validation that enables an administrator to use policies that de- API that applications call directly, which extends authen- fine how multiple authentication services cooperate, tication services to new or modified applications, while for example using unanimous consent or threshold also providing compatibility with TLS 1.3. voting. To provide system administrator control, TrustBase • A research prototype of TrustBase: We develop a provides a policy engine that enables an administrator to loadable kernel module that provides general traf- choose how certificate authentication is performed on the fic interception and TLS handling for Linux. This host, with a variety of authentication services that can be module communicates via the Netlink API to the used to harden the CA system. The checks performed by policy engine residing in user space for parsing and authentication services are complementary to any exist- validation of certificates. We describe how this same ing certificate validation performed by applications. This architecture can be implemented on other operat- approach both protects against insecure applications and ing systems and give details of our current Android transparently enables existing applications to be strength- and Windows versions. We provide source code