70 lines
3.4 KiB
Plaintext
70 lines
3.4 KiB
Plaintext
---
|
|
title: "DNSSEC + DANE: Part 1"
|
|
---
|
|
|
|
## Problem
|
|
|
|
Communications on the Internet overwhelmingly rely on SSL/TLS for protection.
|
|
There are two forms of protection this is meant to provide - from snooping of
|
|
traffic, and from impersonation. The first of those gets a lot of attention
|
|
but, unless we have the latter as well, an attacker can snoop on your traffic
|
|
by performing a man-in-the-middle attack on you with a dodgy certificate:
|
|
|
|
=> http://falkvinge.net/2013/09/12/the-nsa-and-u-s-congress-has-destroyed-ssl-we-must-rebuild-web-security-from-the-ground-up/
|
|
|
|
Unfortunately, the current method of providing protection-from-impersonation
|
|
is terrible. Traditionally, OS and browser vendors pick a range of root
|
|
certificates to bundle with their software - a list that's generally hundreds
|
|
of entries long - and everyone trusts that the list is good. Anyone who can
|
|
get a certificate into the lists can then sell certificates signed by it to
|
|
people who can't (like me, for a start).
|
|
|
|
They can sell certificates for any domain, for any reason, with any degree of
|
|
publicity, transparency or validation; the only recourse vendors have is to
|
|
threaten to stop trusting them if the're shown to be issuing certificates that
|
|
don't meet some standard or another. If they're compromised and the key for the
|
|
root certificate is stolen - as happened in 2011:
|
|
|
|
=> https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-https
|
|
|
|
Then it's a mad scramble to revoke or blacklist new certificates based on that
|
|
stolen information before too much harm is done.
|
|
|
|
Recently, some vendors - Chrome, for instance - have started introducing
|
|
certificate pinning
|
|
to restrict the range of CAs that are valid for a particular domain:
|
|
|
|
=> https://www.imperialviolet.org/2011/05/04/pinning.html
|
|
|
|
This helps a bit against some attacks on large sites, but isn't much use as a
|
|
general solution.
|
|
|
|
As for the first part - the encryption itself - there's a lot of discussion
|
|
right now over which parameters are safe, and which aren't. There's probably
|
|
*some* setups that're safe from cryptanalysis - or if not, then we can probably
|
|
come up with some. In this area, one more problem we have with the current CA
|
|
model is that deploying new types of certificates is a slow process - you have
|
|
to wait for a trusted CA to start offering them, before you can use them.
|
|
|
|
## Solutions
|
|
|
|
The current system, then, can be summarised as trust silos. The main contender
|
|
to replace it is an RFC known as DANE:
|
|
|
|
=> https://datatracker.ietf.org/doc/rfc6698/
|
|
|
|
This leverages DNSSEC-signed DNS to publish records that say which certificates
|
|
(rather than certificate authorities) are valid for a particular service running
|
|
on a domain. As it utilises the DNS, we move from trust silos to hierarchical
|
|
trust.
|
|
|
|
Hierarchical trust is narrower, and so better, but still vulnerable to
|
|
compromises of keys not under your control. However, the only other schemes
|
|
I'm really aware of at the moment are based on web-of-trust relationships with
|
|
offline identity verification. This boils down to everyone manually curating
|
|
bookmarks that tell them how much to trust things, and there are still keys
|
|
out of your control that, if compromised, break you - you just get to choose
|
|
between trust anchors more flexibly than with a hierarchical system. I'm not
|
|
convinced the extra effort is worth it, so I've deployed DNSSEC + DANE instead,
|
|
and in the next article, I'll go over how I did it.
|