Transport Layer Security (TLS) is what gives you the little padlock in your browser bar. Some people still call it SSL, but TLS has been around for 18 years – it’s time to move on.
TLS provides two things. One is encryption of traffic as it goes across the wire, the other is a cryptographic proof that you’re talking to the domain you think you’re talking to.
The second bit is important, as if you can’t prove you’re talking to, for example, your bank you could really be talking to a malicious third party who has convinced your browser to talk to their server instead of your bank which makes the encryption of the traffic much less useful. They could even act as a man-in-the-middle and pass your traffic through to your bank, so that you wouldn’t notice anything wrong.
When your browser connects to a website over TLS it, as part of setting up the connection, fetches a “TLS certificate” from the server. That certificate includes the hostname of the server, so the browser can be sure that it’s talking to the server it thinks it is.
How does the browser know to trust the certificate, though? There’s not really a great way to do that, yet. There’s a protocol called DANE that stores information in DNS to validate the certificate, much the same as we do with DKIM. It’s a promising approach, but not widely supported.
What we have today are “Certificate Authorities” (CAs). These are companies that will confirm that you own a domain, issue you a certificate for that domain where they vouch for it’s authenticity (and usually charge you for the privilege). Anyone can set themselves up as a CA (really – it’s pretty trivial, and you can download scripts to do the hard stuff), but web browsers keep a list of “trusted” CAs, and only certificates from those authorities count. Checking my mac, I see 169 trusted root certificate authorities in the pre-installed list. Many of those root certificates “cross-sign” with other certificate authorities, so the actual number of companies who are trusted to issue TLS Certificates is much, much higher.
If any of those trusted CAs issue a certificate for your domain name to someone, they can pretend to be you, secure connection padlock and all.
Some of those trusted CAs are trustworthy, honest and competent. Others aren’t. If a CA is persistently, provably dishonest enough then they may, eventually, be removed from the list of trusted Certificate Authorities, as StartCom and WoSign were last year. More often, they don’t: Trustwave, MCS Holdings/CNNIC, ANSSI, National Informatics Center of India (who are currently operating a large spam operation, so …).
In 2011 attackers compromised a Dutch CA, DigiNotar, and issued themselves TLS Certificates for over 500 high-profile domains – Skype, Mozilla, Microsoft, Gmail, … – and used them as part of man-in-the-middle attacks to compromise hundreds of thousands of users in Iran. Coverage at the time blamed it on “DigiNotar’s shocking ineptness“.
In 2015 Symantec/Thawte issued 30,000 certificates without authorization of the domain owners, and even when they issued extended validation (“green bar”) certificates for “google.com” they weren’t removed from the trusted list.
So many CAs are incompetent, many are dishonest, and any of them can issue a certificate for your domain. Even if you choose to use a competent, reputable CA – something that’s not trivial in itself – that doesn’t stop an attacker getting certificates for your domain from somewhere else.
This is where CAA DNS records come in. They’re really simple and easy to explain, with no fancy crypto needed to set them up. If I publish this DNS record …
wordtothewise.com 0 issue "letsencrypt.org"
… that says that no CA other than letsencrypt.org may issue a TLS certificate for wordtothewise.com. There are a few extensions, for wildcard certificates and specifying that only a particular customer of the certificate authority may create certificates, but it’s all pretty simple.
There’s nothing to prevent a malicious certificate authority ignoring the record and issuing a certificate anyway – but that’d be conclusive proof of bad intent. It’s a very simple check for a CA to make, so it should prevent even marginally competent CAs from issuing certificates unless they’ve been listed in the domain’s CAA record. And it’s something it would be impossible to social engineer around at the CA. It’s not a perfect solution, but it’s spectacularly better than what we have now.
Support for CAA records has been added to the baseline requirements for all trusted CAs, so it’s something you’re likely to need to do soon. The first step is that at least some CAs will refuse to issue or renew TLS certificates unless the authoritative nameservers for a domain understand requests for CAA records. You don’t need to publish CAA records yet, though you should, but your DNS servers need to be able to handle requests for them.
This is probably going to be a fairly hurried upgrade for some companies. We use PowerDNS for our authoritative DNS servers, and it apparently doesn’t support CAA properly before version 4.0.4, which was released five weeks ago, and we got notification from our CA today that we needed to fix things. It’s probably a DNSSEC configuration issue …
So it looks like I’m going to spend some time over the next day or two diagnosing CAA and DNSSEC issues. I’ll share anything useful on Monday.
RSS - Posts
Intersting idea. I added CAA records to all of my LE signed domains. I use NSD which supports CAA, and my LE script works by inserting DNS records already, so it was a pretty easy hack.
Now I suppose I should see whether it actually worked, and try getting a cert from someone else.