We all like to think that web security is perfect, but we all know better. You know about spam, phishing, and all manner of malware. You probably run a virus scanner on your computer. But what you don’t expect and shouldn’t expect is that the core of our security system would have a flaw. It does, and has, from the beginning. What’s more, it’s a known flaw.
How is it your browser decides to trust a site, or to show that lovely lock icon and perhaps a green URL bar when your communication is both encrypted and verified to be to a specific end point? The simple answer is that your browser provider, Microsoft, Mozilla, Apple, or Google, has made a decision on your behalf that – at least as initially configured – your browser will trust a certain set of authorities– certificate authorities (CAs)– who will validate others.
One such certificate authority got hacked. Badly. And because they were trusted by your browser, so might you have been. Here’s how it works.
- When you access a URL that begins with “https”, a certificate is sent by that site that is signed by one of the trusted CAs, saying “yes, I agree that this is google.com,” (for example). If someone gets in between you and Google, they won’t have the private key associated with that certificate, and they won’t be able to validate to your browser.
- If someone breaks into a CA and gets a certificate for “google.com” (again, for example), and then gets between you and the real Google, they will be able to masquerade. It doesn’t matter which CA it is, as long as your browser trusts it. Google needn’t have any relationship with that CA.
This is what happened with DigiNotar. Not only did they get hacked, but they didn’t notice. They didn’t have sufficient controls in place to even spot the attack. That they should have had.
But now there’s something else we can do. In the Internet Engineering Task Force (IETF), a few folks led by a gentleman by the name of Paul Hoffman have developed an approach where sites like Google can effectively register which certificates are valid for them in an separate alternative authority that we largely trust, the Domain Name System (DNS). You use DNS to convert site names like ofcourseimright.com to IP addresses like 10.1.1.1.
The group working on it is called “dane“. Had the dane mechanism been in place in the browser, the attack on Diginotar and Google would have failed, even if Google was a customer of Diginotar (which they weren’t).
When we speak of security we always discuss defense in depth. That is– never rely on exactly one mechanism to protect you, because at some point it will surely break. In this case, the attacker needed to (a) compromise the CA and (b) get in between the service and the end user to succeed. Had dane been in place, atop (a) and (b), the attacker would also have to have compromised Google’s DNS for the attack to succeed. That’s likely even harder than compromising a CA.
Dane has another potential benefit: in the long run, it may get browsers completely out of the business of telling you who to trust, or it will extremely limit that trust.
This attack also demonstrates that as threats evolve our response to those threats evolves. Here we understood the threat, but just didn’t get the work done fast enough before a CA was compromised. I still call this a win, as I think we can expect to see dane even faster than we expected before the attack.