TrustBase: an architecture to repair and strengthen certificate-based authentication O’Neill et al., USENIX Security 2017
We recently saw that the sorry state of DNSSEC makes it comparatively easy to be sent to the wrong address when looking up a hostname. If certificate-based authentication is messed up as well, then it’s double trouble as you can also be fooled into establishing a secure connection with the imposter. And guess what?
Server authentication on the Internet currently relies on the certificate authority (CA) system to provide assurance that the client is connected to a legitimate server and not one controlled by an attacker. Unfortunately, certification validation is challenged by significant problems.
What kind of problems?
- Client applications frequently do not properly validate the server’s certificate
- TLS interception (used by many middleboxes) compromises the integrity of end-to-end encryption, “with many firewalls having significant implementation bugs that break authentication.”
- The CA system itself is vulnerable to being hijacked even when applications and proxies are implemented correctly.
There are a number of proposals to improve things, but most applications have not (yet?) adopted them. Even things like certificate revocation remain problematic.
TrustBase aims to fix these problems by moving authentication from an application responsibility to an operating system responsibility, where an administrator can define policies. It makes a ton of sense to me, is compatible a range of operating systems (e.g., Linux, Windows, Android), and can enhance the security of existing applications without requiring any changes to them at all.
TrustBase provides universal coverage of existing applications, supports both direct and opportunistic TLS, is hardened against unprivileged local adversaries, is supported on both mobile and desktop operating systems, and has negligible overhead.
What’s not to like? The main chink in the armour that I can see is TLS 1.3. In TLS 1.3 the exchanged certificates are encrypted, which means that TrustBase’s normal mode of passive traffic interception won’t work. Applications can be directly modified to use the TrustBase API (the best solution in theory, but subject to the slow roll-out problems TrustBase is hoping to fix), or TrustBase can be deployed in conjunction with a local TLS proxy. Future work is looking at how to remove this constraint, including the option of providing TLS itself as an operating system service.
How TrustBase works
There are two primary ways of interacting with TrustBase: newly developed applications can code directly to the TrustBase validation API; existing applications benefit from TrustBase due to its traffic interceptor. In the Linux implementation, interception happens via a loadable kernel module (LKM), which can be loaded and unloaded at runtime. No modifications of native kernel code are required.
TrustBase provides generic traffic interception by capturing traffic between sockets and the TCP protocol. This is done by hooking several kernel functions and wrapping them to add traffic interception as needed.
The interceptor works with a collection of handlers that each lay claim to different kinds of traffic. Out of the box, TrustBase ships with a TLS handler, and an opportunistic TLS handler (E.g., for STARTTLS connections). Adding additional handlers is designed to be easy to do.
The TLS handler extracts certificates from TLS network flows and forwards them to a policy engine for validation.
The opportunistic TLS handler performs passive monitoring of plaintext protocols such as SMTP. If the application requests initiation of a TLS connection then control is passed to the normal TLS handler. Why the opportunistic TLS handler then? Because you can specify policies that always require TLS, defending against stripping attacks whereby an attacker tries to fool the client into believing that the server does not support TLS upgrades.
The policy engine is where you can configure system-wide rules for how connections should be validated. Different strategies (authentication services) are made available to the policy engine via a plug-in API.
When the policy engine receives a validation request from a handler, it will query each of the registered authentication services to validate the server’s certificate chain and host data.
Plugins (services) can be defined as either necessary, or voting. All necessary services must indicate that a certificate is valid, and a majority of voting services.
The initial set of implemented services are as follows:
The prototype implementations of TrustBase (Linux, Windows, Android) can be found at owntrust.org.
Protections provided by TrustBase
The coverage of TrustBase enables it to enforce both proper and additional certificate validation procedures on TLS-using applications. There are a variety of ways that attackers may try to perform at TLS MiTM against these applications.
TrustBase is able to detect and prevent all of the following:
- Hacked or coerced certificate authorities: attackers who have received a valid certificate through coercion, deception, or compromise of CAs. Pinning and/or notary plugins in TrustBase can detect the mismatch between the original and the forged certificate.
- Local malicious root: certificates installed into a local trusted store will be trusted by many application (e.g., Google Chrome ignores certificate pins in the presence of a certificate linking back to a locally-installed root certificate). Once more, TrustBase’s pinning and/or notary plugins can protect against this.
- Absence of status checking: many applications do not check OCSP or Certificate Revocation Lists (CRL), meaning that attackers using stolen certificates can can continue to exploit them even after they’ve been reported and revoked. TrustBase has OCSP and CRLSet plugins that will perform these checks. “For example, the OCSP plugin can be used to check certificates received by the Chrome browser, which does not do this natively.”
- Failure to validate hostnames: some applications validate signatures from a hostname back to a trusted root, but don’t verify that the hostname matches the one in the leaf certificate! Thus an attacker can simply use any valid certificate!! TrustBase strictly validates the common name and all alternate names in a valid certificate.
- Lack of any validation: some applications simply accept all certificates, without performing any validation at all. These can be fooled using a self-signed certificate! TrustBase always ensure that a certificate has a proper chain of signatures back to a trust anchor.
- STARTTLS downgrade attack: a downgrade attack happens when an active attacker suppresses STARTTLS-related messages, tricking endpoints into thinking the other does not support TLS. TrustBase includes an option to enforce STARTTLS use.
Evaluation
The performance overhead of TrustBase is negligible, with the average different between intercepted and non-intercepted connections less than 10 microseconds. The memory footprint is also negligible – less than 300 bytes of data per connection.
We tested TrustBase with 34 popular applications and libraries and tools, shown in Table I (below). TrustBase successfully intercepted and validated certificates for all of them. For each library tested, and where applicable, we created sample applications that performed no validation and improper validation (bad checking of signatures, hostnames, and validity dates). We then verified that TrustBase correctly forced these applications to reject false certificates despite those vulnerabilities in each case.
In addition to the Linux prototype, the authors also demonstrate feasibility on Android, where TrustBase appears as a VPN service. On Android, TrustBase was successfully tested with, and strengthened certificate validation for: Chrome, YouTube, Pandora, Gmail, Pinterest, Instagram, Facebook, GooglePlayStore, Twitter, Snapchat, Amazon Shopping, Kik, Netflix, Google Photos, Opera, and Dolphin.
There’s a protoype implementation available for Windows 10 too, implemented using the native Windows Filtering Platform.
I’m looking forward to seeing TrustBase advance from a research prototype to a hardened service available to all!