66 lines
3.4 KiB
Markdown
66 lines
3.4 KiB
Markdown
|
+++
|
||
|
title = "DNSSEC + DANE: Part 1"
|
||
|
date = "2013-09-14"
|
||
|
tags = ["security", "technical", "DANE"]
|
||
|
+++
|
||
|
|
||
|
#### 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 - haver started introducing
|
||
|
[certificate pinning](https://www.imperialviolet.org/2011/05/04/pinning.html)
|
||
|
to restrict the range of CAs that are valid for a particular domain. 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.
|
||
|
|