Any of the 100+ Certificate Authorities can issue valid TLS certificates for any domain name on the public web, in short this is what’s wrong 🫣🫣.

Hello there we’re the dappy team, developping a new name system under an unofficial .d TLD. We have strong opinions on many things, one of them is that the Certificate Authority system used for HTTPS website has strong flaws, and will witness more and more hacks and inconsistencies as web services carry increasing value and critical data. Let’s dive into today’s article !

Why are Certificate Authorities needed for HTTPS ?

The Certificate Authorities system is used to authenticate web servers on the internet, those web servers are often tied to a domain name and a company, foundation or government institution. When you login to X or facebook, you authenticate as a client, facebook must be sure that you are John Doe the owner of account john@doe.com in Facebook’s database.

It is also true that when you go on https://facebook.com with a browser, or even to a call to api.facebook.com in a nodeJS program, the server you reach must give you a proof that it is facebook.com. This is because the internet is a packet switching network, data may flow through dozens of countries and Internet Service Providers, you shouldn’t really trust anyone.

How are HTTPS certificates obtained

Web servers in relation with a domain name are authenticated using intermediary companies called Certificate Authorities (CA). As someone controlling a domain name in the DNS, and a web server, you may reach a certificate authority. For free or after a payment, and after having verified that you are in control of the web server linked to yourdomain.com, the CA will give you a signed TLS certificate. This certificate is signed by the root certificate of the authority, which is hardcoded in most web browsers.

You can check Mozilla’s root certificates list here, this list is used in Firefox and NodeJS.

How are HTTPS connections established

Now whenever clients need to reach https://yourdomain.com, your web server (nginx or apache properly configured) will first present the signed certificate to the program (likely a web browser) will check. This is the most important part, your browser or operating system carries a hardcoded list of root CA certificates, it will try to match the certificate presented from web servers with any of them.

The security and trust issue with Certificate Authorities

Yes, any Certificate Authority can attest HTTPS connection of any domain, we refer to this system as an unscoped system, whereas in DNS that is tree like, Verisign (owning an authoritative name server) is the ultimate source of truth for .com domains. In the CA system any authority can really attest anything, they all have internet-wide scope.

This is the main flaw of the CA system 😑, let’s say you’re a company selling jets online, 1M dollars worth of payments are processed directly on the website every day. You first have to trust ICANN and Verisign for securing your .com domain, which are two external third party companies.

You also have to trust hundreds of government agencies, and private companies from dozens of countries, because they cryptographically own one root certificate in everyone’s browser 🥶🥶. If millions are at stake, some may issue forged certificates in some regions and be able to spy on TLS connections in a typical Man-In-The-Middle scenario. Worst thing is that you may not ever know about it.

One must also consider that your clients may have a different operating system, web browser and therefore another trusted root certificates list. DNS resolvers, DNS registries, Certificate Authorities occasionally fail and/or are hacked through social engineering. Defi service Balancer is a recent example.

The solutions to the trust issue in HTTPS and DNS

The web PKI needs to be more transparent, predictable, and have less attack vectors or point of unilateral decision. We argue that permissioned blockchain network operated by established companies, is the way to go. In addition domain owners should simply distribute root certiciates, and not signed one. Permissioned leaderless blockchain, direct control over TLS identities together with co-resolution are features at the core of the dappy protocol that we develop.

We hope you liked this article, feel free to join us on Discord.