CAs Aren’t DANEdy
Recently Brendan Eich has posted in clear terms that Handshake can integrate with the Brave browser if the dev community opens a pull request to their open source repository. This is great, but there is one little hiccup that he mentions:
https://twitter.com/BrendanEich/status/1399163160410558464
But what is DANE and how does it tie into Handshake? DANE creates TLS/SSL connections, but instead of trusting Certificate Authorities (CA), like we do now, the trust is shifted to DNS records. Every time you go to a website and you see that padlock to the left of the URL, that’s TLS in action. It’s showing that your connection with a website is secure and encrypted. This is critical in keeping your information, like logins or credit card numbers, safe from attackers and 3rd party services that route your internet traffic. Your computer establishes this secure connection by asking the website for a TLS session when it first connects. The website will then send over its certificate and your computer will make sure that certificate is “legit”. After it verifies the certificate, it creates two symmetric session keys and one is sent over to the website. As long as both the computer and website have those session keys your connection is encrypted and secure.
This is how the internet has been keeping its connections secure since the 90s, but there’s a problem with this whole system and it’s with your trust anchor lying in the CAs. Your computer’s OS is installed with software that makes it implicitly trust certificates from certain CAs. This is how your computer makes sure the certificate from a website is “legit”.
You can actually see all the certificates that are installed and trusted by your computer by typing in ”manage computer certificates” in the start menu on windows.
This implicit trust leads to many problems that can compromise the security of the TLS connection. The most common being a man in the middle attack (MITM). This happens when an attacker gains access to a certificate from a CA, usually through social engineering tactics where they pose as being from the company associated with the website. Wrong certificate issues have happened to companies as big as Microsoft, so don’t think that only the little guys are vulnerable. After the attacker has access to this certificate they can get in the middle of your TLS session before it’s connected. The attacker will create a TLS session with the website you’re trying to connect to and when your computer thinks it’s setting up a TLS connection with the website it’s actually doing this with the attacker. Your computer sees nothing wrong with this since the attacker has a certificate that your computer trusts. Your URL bar will show a green padlock and you’ll think everything is good to go. With you ignorant to the attack, this man in the middle could be doing anything with that access. Ranging from stealing your login and password, credit/debit card info, collecting information for ad targeting, or maybe it’s just big brother keeping a watchful eye on you looking at your computer’s history.
These attacks aren’t the only problem in the CA industry; the trust that we give them is mishandled even though they’re supposed to operate on reputation and trust. Their purpose is to be as trustworthy with their certificate issue as possible, but there are some flaws with this system. They don’t all have pure incentives to do their job, despite it being their main job to safeguard these certificates. Many of them have been compromised through security breaches, some are run by foreign governments who are at war with the US, or they’re just not trustworthy organizations. There’s always a lot of potential for abuse of power, since our computer trusts all of them equally. When a CA fails to do their job and maintain a pure reputation they should get cancelled and go out of business, since nobody should trust them anymore. This way only the pure CAs are being trusted all the time and they’re forced to compete for trustworthiness to stay around. What ended up happening is most of the major CAs got big enough that there’s no way to just stop trusting them. They’ve signed certs for millions of websites that would effectively be taken offline by making them insecure to connect to. For example, Comodo has had a long series of breaches and mis-issuing of certificates and poor follow up to those incidents. They can’t just stop being trusted to be a CA, because it’d be like unplugging half the internet and expecting all the website owners to just automatically be in the loop and know what to do next. What eventually happens, very slowly, is regulators weigh in and untrustworthy CAs end up getting bought up by bigger, slightly more trustworthy CAs who’ll make them do things right this time. Now there’s a shrinking pool of ultra-massive CAs who control most of the web, none of whom have a perfect track record. We have some mitigations for some of this stuff, but they’re not consistently deployed. There are CAA DNS records on a domain to specify what CA was intended to be used and your computer is supposed to invalidate connections to the site involving certs signed by other CAs. This is a great improvement, but hardly anybody knows about it or uses it and it still doesn’t fix what’s wrong with CAs in general. On top of all of this, suppose one day the government says to all the CAs they have to stop issuing certs to Sci-Hub because they think it’s bad. They all comply except for e.g. Let’s Encrypt because they care about rights and stuff. The government still forces them to comply and maybe a fork of Let’s Encrypt is founded in some other country to allow them to continue operating without the government meddling. The problem is, this new CA can’t get trusted by everybody’s systems when the government can just go to Microsoft and say “don’t ever include this CA in your OS”. The whole system is broken, but “too big to fail” and beholden to government overreach, international conflict, etc. Cybersecurity folks have been groaning about all this stuff the whole time, but they don’t actually have all that much sway on their own, even the ones who use black hat tactics by night. The legacy system of encryption is failing and the people who care are being ignored. We need to flip the switch on all of this to overthrow this monopoly of CAs wielding power they can’t handle and it can happen through DANE.
DNS-based Authentication of Named Entities (DANE), is another way for your computer to establish and trust a TLS connection. It works by your computer requesting an encrypted connection with the website, then the website sending it’s certificate to your computer. This certificate isn’t given out by CAs though, instead this certificate is generated by the host of the website. Your computer doesn’t implicitly trust this certificate, so what it’ll do is it’ll get the hash (a string of numbers unique to that certificate) of the certificate and check the DNS record to make sure the hash from the certificate matches the hash in the DNS record. Once your computer verifies that the hashes are the same. It will create two symmetric keys and send one over to the website. Once they both hold the same key, an encrypted connection is created.
The reason your computer can shift it’s trust anchors from CA’s to the DNS record is because of DNSSEC (Domain Name System Security Extensions). DNSSEC tells your computer that the DNS record has been signed by a certain person and hasn’t been modified by someone who doesn’t have the DNSSEC keys. If for whatever reason the DNS records were changed by someone without the DNSSEC keys or the hashes don’t match up, the computer wouldn’t be able to connect since it assumes that there’s been an attack on the website.
DANE allows us to create secure connections with websites and allows us to dodge the overreach of CAs. The issue is that it doesn’t have any browser support right now. This is mostly for the fact that it adds latency which big Internet aggregators like Google (who also have the most adopted browser) aren’t too fond of and people say that the whole CA system works good enough as it is. DANE also doesn’t tackle the root of the problem with ICANN’s power over domains. If a company like Godaddy holds your DNSSEC keys and they’re beholden to ICANN, then ICANN still holds the power on whether your site stays up or down. Giving up custody of your DNSSEC keys means that the same MITM attacks are still very possible with DANE. Your DNSSEC keys could be easily socially engineered into the wrong hands and the certificates could be modified without your computer knowing an attacker has changed information.
Any Blockchain-based domain system can leverage the power of DANE to avoid the powers of ICANN and CAs. In the case of Handshake, if you’re hosting your own TLD/SLD where only you, the private key holder, can edit the DNS records and your DNSSEC private keys are protected in the same way your Handshake wallet is, an attacker has a close to an impossible chance at changing the certificate information in the DNS record and then being able to sign that with a stolen DNSSEC key. Even though DANE with Handshake provides obvious security and custody benefits, it’s a long road to get things like browser support for DANE and for the whole process of setting up DANE to be easy and seamless for any website host. Nobody said the journey would be short and easy though, but once we get more DANE support the switch from the Cweb to the Dweb will be even more obvious and enticing. People will wonder what they were doing when the new web was being created right under their nose and why they didn’t give it any attention earlier. But that doesn’t have to be you. If this technology excites you as much as it excites me and the whole community of domainiacs, consider joining the discord and get involved and contribute whatever you can with us to build something that we deserve: a free and open internet.
So what do you say fren, you taking the shake pill?
Big shout out to all the domainiacs that helped proof read this paper and Brandon Dees with his great insights in the 6th paragraph.
