If you have been following the IT security news, you might have come across these headlines: Earlier this year, Russia creates its own TLS certificate authority to bypass sanctions, entering production in September. On July 6th, digital security giant and root CA operator Entrust informed its customers about having been breached by a ransomware gang. Both news have seen a decent amount of attention, but one thing they tell us in common has received considerable less coverage: That the global PKI ecosystem, which virtually all internet users (have to) trust, is actually not trustworthy at all.

A crash course on today's global PKI

Standing for public-key infrastructure, PKI is a hierarchic, but not necessarily centralized system of delegating trust, in a way that it can be processed by machines, which are then able to derive actions from an entity being assessed as trustworthy or distrusting.

The most common PKI use case you all have encountered is for HTTPS: If you visit this web site, for example, your browser will try to establish a TLS connection to the IP address it has received from its DNS resolver for blog.ipfire.org. During this TLS connection establishment (a process called "handshaking"), the server will present a certificate, comprising of a public key and a signature. However, your browser will not trust this certificate blindly.

Instead, it will try to trace its signature back to the public-key material of an entity that has been marked as ultimately trustworthy, either in the operating system or the browser itself. Such entities are called "root certificate authorities", or "root CAs" for short, and browser/OS vendors have assessed them to do their job properly. Most importantly, this includes vetting any certificate signing request, to ensure that the requesting entity is authorized to have such a certificate.

In practice, this often means assuring that the system requesting a certificate for an FQDN, say blog.ipfire.org, has control over this FQDN, and can put certain data online on the CA's request. Often, this includes placing a unique string into a predefined location of the site, or into the respective DNS zone. The respective certificates are thus called "domain-validated" (DV), and can be issued fully automated, as we see for the ACME standard and CAs such as Let's Encrypt.

But what if a root CA goes rogue?

If you check the list of root CAs your browser trusts ("trust store"), you may well see more than 100 entries, including some organizations that are obviously tied to governments. Basically, your browser trusts all these root CAs to "do the right thing", as detailed above. Depending on your threat model, you probably may beg to differ for some of them by instinct.

However, since your browser cannot know if an HTTPS site has obtained their certificate from root CA X or Y, it has to accept any certificate it somehow can trace back to any root CA in its trust store.

In order words, you have to trust more than 100 organizations across the globe not to issue fraudulent certificates, neither due to poor vetting, due to being compromised, or being forced to cooperate with domestic government agencies. It takes only one of them failing to withstand such technical, organizational and legal threats to obtain arbitrary certificates virtually every internet user trusts. An adversary possessing such a certificate and capable of conducting man-in-the-middle (MITM) attacks can intercept and modify TLS connections transparently, without the user or application even realizing. This is by no means an academic threat, as historical incidents tell.

The swamp of intermediate CAs

Should you manage to be reassured in the face of things like the CA/browser forum, where root CA operators having to undergo extensive audits and being scrutinized by application vendors before making it into their trust stores, the author has bad news: Such procedures apply for root CAs, but not for so-called "intermediate CAs", which are entrusted by root CAs to any certificate on behalf of the root CA (or entrust further intermediate CAs).

The raison d'être of intermediate CAs is rooted in the fact that it would be way too dangerous for a root CA to operate with their primary private key all the time. Commonly, this one is kept offline in a safe, and is only rarely used to sign other CAs, which have a shorter lifetime, and are used to do the actual certificate signing work for customers. Most root CA operators also offer schemes to delegate their trust to other organizations that may wish to run private CAs for internal purposes, or cannot undergo the effort to make it into trust stores directly.

To the best of the author's knowledge, there is no comprehensive list of intermediate CAs, and root CAs are not obliged to make it public which entities they have provided with such services. In 2010, EFF assessed to be more than 1,000 out there.

This means virtually every internet user has to trust more than 100 root CAs plus an unknown four-digit amount of organizations running intermediate CAs, for which there is not even a list, let alone some audit results. Again, one of them falling is sufficient to carry out attacks.

Trusting this ecosystem is not brave, it is naive.

DANE comes to the rescue - if we would be using it

Specified in 2012 as DNS-based Authentication of Named Entities, DANE takes a more sane approach to ensure TLS clients are communicating with the peer they intended to: The administrator can put a hash of the certificate, or a signature of the used CA into DNS which can be validated by a client. No other certificate or no other CA except those listed will be trusted any more. In the light of the day, the remote site itself is best placed to assess what a trustworthy certificate for it looks like. Its staff have to know, since they set up HTTPS deliberately.

Thanks to DNSSEC, we can verify that DNS responses have not been tampered with. If a DNSSEC-signed zone contains a list of acceptable hash values for certificates used by its TLS services, and this list can be queried and processed, we can ensure that the certificate the TLS server presented to us actually matches one of these hashes. If it does, no MITM is trying to intercept the TLS connection. If it doesn't, we are under attack, and refuse to process further.

DANE is doing precisely that. It also allows TLS clients to skip PKI validation for a certain FQDN, and to come up with self-signed certificates only. Thanks to the DNSSEC-signed DANE data, such certificates can be verified as well, ruling CAs completely optional. For services serving a mixed audience of DANE capable and incapable clients, the optional PKI validation won't break the latter, while still improving security somewhat: Now, an attacker has to compromise one distinct CA, having access to a random intermediary or root CA is no longer sufficient.

This obviously greatly raises the bar.

The good news is: DANE has already been rolled out in the SMTP ecosystem, and works perfectly fine there. Using an online testing tool or CLI tools such as posttls-finger, you can for example verify that IPFire's mail server certificate can be validated using DANE.

The bad news: Despite no technical roadblocks left, DANE support never made it into any common web browser. DNSSEC chain extension, a necessary prerequisite to bring DNSSEC validation to the end-user devices, remains an experimental RFC for the time being and is now developed further outside the IETF. So far, no browser vendor showed any interest in implementing it whatsoever. It is a frustrating situation: Even though the internet community is in need of a trustworthy alternative to PKI, browser vendors are not making any incentive to come up with a solution. Without them doing anything, it does not make sense for web site operators to care about DANE - a vicious circle.

A problem beyond IPFire's scope

At IPFire, we fight to protect your network - sometimes quite literally, with developers working through long nights to keep up with all the security threats, fixing bugs, and bringing new features to our userbase.

Since 2016, IPFire brings DNSSEC to the edge of your network, protecting you from DNS spoofing. However, DANE and the underlying issue of the global PKI ecosystem being not trustworthy at all is an issue IPFire cannot address: For DANE, it is necessary to conduct both the DNSSEC signature and TLS certificate validation on the device that has established the TLS connection - otherwise, local (network) attackers are still able to modify DNS responses.

Since IPFire does not have any influence on the software running on devices behind it, we did as much as we could: Bringing DNSSEC to the masses, at least to the edges of their network.

Use DANE for SMTP - and lobby for it to be implemented by browsers

Over the past decade, the internet has made great progress with regards to encryption: Transport encryption became the de-facto standard, and HTTPS adoption is nowadays so great that the first browsers have made it mandatory for their entire userbase by default. TLS 1.3 has been standardized in 2018, encrypts everything it can as soon as possible, and threw out a bunch of outdated techniques and algorithms, making it virtually fool-proof to implement and use. However, the best transport encryption is of little help if it still permits to talk encrypted to an attacker without noticing.

Even the issue of verifying the peer's identity in a trustworthy, decentralized manner has been resolved in theory, and the growing adoption of DANE among the SMTP ecosystem shows that this works in practice as well.

For all of this, IPFire encourages its users to DNSSEC-sign their domains, if not already done so, and deploy DANE for their SMTP infrastructure. But most importantly, please lobby for DANE to be implemented at common web browsers, so we can finally shift away from trusting a completely untrustworthy global PKI, making the internet a safer (or shall we say less unsafe?) place.