Very cool news out of the FreeBSD team yesterday… the upcoming FreeBSD 10 will include support in OpenSSH for DNSSEC. The key point is this:
This means that OpenSSH will silently trust DNSSEC-signed SSHFP records.
What this means is this: when you go to ssh into an unknown system (i.e. one that is not in your “known_hosts” file), OpenSSH will do a query for a SSHFP record and use DNSSEC validation to ensure that the SSHFP record is indeed the one that the domain operator wants you to use.
This process of using a SSHFP record was defined in RFC 4255 back in 2006. If you are familiar with how ssh (a.k.a. “secure shell“) works, when you connect to an unknown system for the first time you are presented with the “fingerprint” of the public key of the server to which you are connecting. In theory you could verify this fingerprint through some out-of-band mechanism (perhaps seeing it on a web page or having received it separately in an email). In practice, the vast majority of people just hit enter/return or type “yes” or something like that.
In the RFC 4255 mechanism, the operator of the server would publish a SSHFP record in DNS that would have the fingerprint of the SSH public key. This is the same key fingerprint that would normally be presented to a user. By using DNSSEC to sign the DNS zone that includes the SSHFP record, the server operator can provide a method for a DNSSEC-validating SSH client to verify that the SSH fingerprint is in fact the one that should be used to connect to the server.
This creates a higher level of trust and security in SSH connections.
It’s great to see this added to FreeBSD 10, which, according to the FreeBSD Release Engineering page, should be available sometime in November 2013.
For those curious, the SSHFP record is similar to what was defined six years later in RFC 6698 for the DANE protocol, which is really no surprise as they share a common author, Jakob Schlyter. DANE’s TLSA record is a bit more complex and, for instance, allows for the inclusion of a complete SSL/TLS certificate rather than just a fingerprint. In both cases, though, the idea is the same – use a DNS record to provide a means to verify a public key, and use DNSSEC to provide integrity protection so you know that you can trust the DNS record.
Great to see this being rolled out in an enabled state. Kudos to the FreeBSD team for doing this!