This article is the first part of a two articles series on the DNS, the public web PKI and dappy. It is the result of more than two years of research and exchange with engineers and researchers in cybersecurity and web technologies.

We will first describe the typology and properties of the web’s public key infrastructure, its relations with the Domain Name System and the associated issues, limitation or vulnerabilities, then in part two come up with a design proposition that aims at solving many issues.

Certificates and TLS identities : a struggle for visibility and efficient management

Today, managing certificates is a pain for many companies. When exposing a B2B portal, online SaaS or APIs are exposed to security risks or service interruption caused by corrupted or expired certificates (some companies have hundreds of web services). Service interruptions, hacks or simply exposure to risks have noxious effects on a company’s or web service’s operations, it can imply high costs of maintenance (budget for security may go from 10% to 25% for critical applications), reduced trust from the partners and clients, and also limitation of the scope of an application.

What are certificates and stores ?

Certificates X509 v3 certificates are the angular stone of identity in the TLS protocol. Certificates are based on digital signatures, they allow authentication with the concept of chain of trust (or certification path ). There are two types of certificates :

– server certificate are delivered by companies and institutional servers, they contain the server’s identity. Server certificates are signed by a second type of certificate.

– root certificates (root are in reality often intermediate certificates, but let’s keep that aside for now). Root certificates are installed on client devices (computers and mobile phones) or programs (an operating system has many root certificates installed). A server certificate is trusted if signed by a root certificates known by the client.

In a public web context, root certificates are distributed over Web PKI root stores, authored by browser companies like Mozilla, Microsoft, Google, Apple. Root stores contain hundreds of root certificates owned by public certificate authorities. The root certificates have to be installed on their local stores in order to be trusted, this is usually done during software updates.

What’s wrong with certificate stores ?

Firstly, the local list of root certificates is the point of reference, and each client has one. It does not matter that a web server has a certificate signed by a well known authority like “Let’s Encrypt” if the clients don’t have the corresponding root certificate installed, there will be a certificate error in the browser. In addition to many different root certificate stores being distributed in operating systems and web browsers, the lists evolve over time, it means that a client will often have a list that differs from the a Web PKI root store. Quite obviously, the larger this gap, the higher the security risk. Browsing the public web with an outdated local certificate store can be extremely insecure.

Secondly, certificates can’t be easily repudiated. The cryptographic proof (signature) is valid forever because a certificate has been signed by a root certificates (to be exact, it has been signed by its corresponding private key). OCSP and CRL protocols permit repudiation, the burden of checking the validity of certificates is on the softwares that interpret the metadata. These protocols are overlays, they can be implemented or interpreted differently by softwares, ultimately, OCSP and CRL do not and cannot invalidate CA signatures. There are dozens of windows distributions, hundreds of releases of Chrome, Chromium or Firefox browser, and they may each have a different, or non-existent OCSP policy. Sadly, these protocols do not guarantee that clients or partners are browsing your website with only valid and non revoked certificates.

Many vendors advocate now for short validity periods to minimize the attack surface, this is only half of a solution. Moreover, how would you install the new certificate before the expiry date in the local root store ? And even if OCSP is perfectly set up, how do you ensure that none of the other 500 certificates authority (yes, Microsoft Windows has 500) issue counterfeit certificates ?

As this paper written by researchers Tariq Fadai, Peter Kieseberg, Martin Mulazzani and Sebastian Schrittwieser states ”the trust model of SSL is fundamentally broken”.

Teaser : Static stores of root certificates are the problem.

Ultimately, your server identity can be impersonated or revoked by any certificate authority. For example, on apple devices, 164 root certificates are valid. Who can guarantee today that countries like United States, China or some private corporations are not conducting shady interceptions in relation with the root certificates stores ? War in Ukraine recently illustrated that the chain of trust is easily corruptible. It takes only one root certificates authority to be compromised for your (or your client’s) TLS communications to be exposed to Man-In-The-Middle attacks. MITM attacks are partly mitigated by CT Logs, but still possible. TLS interception is not always bad, it is widely used in company intranets or private networks to prevent data leaks and monitor traffic. Few people realize that anyone is also exposed to these attacks on the public web.

The relation with DNS and the public names

DNS is the authority for the management of public names. The typology of this network is pyramidal / top-down, it starts at the root and goes down the domains (root, top level, second level etc.). DNS is a unique tree, it is an ever changing but unique tree of public names. DNS stores many informations, the most important being the IP addresses of the servers. On the other hand the certificate authorities system is a horizontal network with hundreds of authorities at the root, not at all a tree-like network. The two typologies can only oddly coexist, for example you will very hardly know all the certificates that are linked to a public name at a given time, CAs are opaque.

One may say that a public PKI system must offer visibility, that is not the case today, the certificate authority system does not offer global visibility. No one should be able to impersonate a domain name, but as argued earlier the PKI and root stores of the public web make it hard to obtain this guarantee. What happens when a domain name has a new owner ? You guessed it … certificates are still valid. And conversely, why does a certificate become invalid despite the fact that name ownership hasn’t changed.

Many attempts were made to patch DNS and allow DNS zones to store TLS certificates, RFC 4398, or to save certificate fingerprints with DANE. But DNS failed to be secured using DNSSEC in an end to end way.

A public web identity is in reality borrowed from certificate authorities. If just one authority is compromised in any way, all secured public communications are compromised, a root authority can create a certificate for any domain without the owner’s permission. We implicitly accept this single point of failure because it’s the only effective way to secure communications and transactions on the internet. At the beginning we also explained that no unified policy exists to avoid the use of revoked certificates.

The web deserves better

One of the central ideas of our research and products at FABCO, and also a point on which we agree with some researchers is that too much trust is delegated to local stores and their root certificates. Security flaws, lack of visibility and control will be a gigantic issue as companies continue to digitize their operations, and deploy critical web applications on the web. More and more value will be managed through APIs and web interfaces in the coming years, web cryptocurrency exchanges already handle daily volumes that are in the Billions, home ownership can be digitalized using NFTs. Not surprisingly, the number of cyber attacks has never been so high.

As a solution to avoid issues with the local root certificate stores, we propose the following : not using local root certificate stores. In part two we will expand on this idea and explain how the dappy name system is highly related to this topic, and well positionned to solve issues that have already cost too much time and money.