openssh unix dev - Jun 2015 - Small issue with DNSSEC / SSHFP

Hi,

I found a small issue with DNSSEC validation of SSHFP lookups. (For reference
I used OpenSSH 6.8p1 on FreeBSD 10.1).

The issues is that when DNSSEC valiation fails, ssh displays a confusing
message to the user. When DNSSEC validation of a SSHFP record fails, ssh
presents the user with
"Matching host key fingerprint found in DNS.
"Are you sure you want to continue connecting (yes/no)?

(For example 
$ ./ssh -o 'VerifyHostKeyDNS True' fx.dnssec-broken.phicoh.nl
Which has an intentionally broken DNSSEC delegation)

I propose to change that to:
"The DNS lookup was not secure, however a matching host key fingerprint was
found in DNS."

This should make it clear to anyone who relies on DNSSEC that something went
wrong. A patch is at the end of this mail.

At first I also found that DNSSEC validation always fails due to lack of trust
anchor. There is also a ticket for that:
https://bugzilla.mindrot.org/show_bug.cgi?id=2119

However, in the mailing list archive I found:
https://lists.mindrot.org/pipermail/openssh-unix-dev/2012-May/030443.html
(Just adding an 'anchor' line to /etc/resolv.conf solves that issue)

Finally, there is the issue that ldns relies on a DNSSEC aware resolver to
supply the RRSIG records. Note that the resolver doesn't have to be trusted,
it just has to pass the RRSIG records.

However, many CPEs are not DNSSEC aware, so that breaks the validation.


commit da3654f67293daffc913b87eb05eac098e462838
Author: Philip Homburg <philip at f-src.phicoh.com>
Date:   Mon Jun 22 12:52:45 2015 +0200

    Better diagnostic when DNSSEC validation fails.

diff --git a/sshconnect.c b/sshconnect.c
index f41960c..9f1eafa 100644
--- a/sshconnect.c
+++ b/sshconnect.c
@@ -71,6 +71,7 @@ char *server_version_string = NULL;
 Key *previous_host_key = NULL;
 
 static int matching_host_key_dns = 0;
+static int dns_secure = 0;
 
 static pid_t proxy_command_pid = 0;
 
@@ -972,13 +973,18 @@ check_host_key(char *hostname, struct sockaddr *hostaddr,
u_short port,
 				fatal("%s: sshkey_fingerprint fail", __func__);
 			msg2[0] = '\0';
 			if (options.verify_host_key_dns) {
-				if (matching_host_key_dns)
+				if (!matching_host_key_dns)
 					snprintf(msg2, sizeof(msg2),
-					    "Matching host key fingerprint"
+					    "No matching host key fingerprint"
 					    " found in DNS.\n");
+				else if (!dns_secure)
+					snprintf(msg2, sizeof(msg2),
+					    "The DNS lookup was not secure,"
+					    " however a matching host key"
+					    " fingerprint was found in DNS.\n");
 				else
 					snprintf(msg2, sizeof(msg2),
-					    "No matching host key fingerprint"
+					    "Matching host key fingerprint"
 					    " found in DNS.\n");
 			}
 			snprintf(msg, sizeof(msg),
@@ -1295,6 +1301,9 @@ verify_host_key(char *host, struct sockaddr *hostaddr, Key
*host_key)
 					r = 0;
 					goto out;
 				}
+				if (flags & DNS_VERIFY_SECURE) {
+					dns_secure = 1;
+				}
 				if (flags & DNS_VERIFY_MATCH) {
 					matching_host_key_dns = 1;
 				} else {

Quoting Philip Homburg <pch-openssh at u-1.phicoh.com>:
> Hi,
> 
> I found a small issue with DNSSEC validation of SSHFP lookups. (For
> reference
> I used OpenSSH 6.8p1 on FreeBSD 10.1).
> 
> The issues is that when DNSSEC valiation fails, ssh displays a confusing
> message to the user. When DNSSEC validation of a SSHFP record fails, ssh
> presents the user with
> "Matching host key fingerprint found in DNS.
> "Are you sure you want to continue connecting (yes/no)?
That's not the only confusing one.  I ran into another confusing error
message
on some of my 6.6 clients when connecting to hosts which had published a full
set of SSHFPs (types 1 and 4 anyway, with both hash records for each of
those).  It was something vague like "Error calculating host key
fingerprint"
with no mention of an unsupported SSHFP record.

Even though Curve25519 support was in those older versions, I guess the
support for the Ed25519 algorithm in SSHFPs lagged them by quite a while.  I
don't use algorithms 2 or 3 since none of my SSHDs are configured to support
them.

It's probably of minor importance, since DNS fingerprinting is not the best
primary mechanism to verify a server's host key fingerprint.

=R=

In your letter dated Mon, 22 Jun 2015 17:24:01 -0700 you
wrote:
>It's probably of minor importance, since DNS fingerprinting is not the
best
>primary mechanism to verify a server's host key fingerprint.
My experience is that my sites do not have any sensible policy of publishing
ssh fingerprints and quite a few admins would quite like to use DNSSEC
validated fingerprints.