[Bug 2516] New: ssh client shouldn't trust the DNS AD bit blindly

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2516

            Bug ID: 2516
           Summary: ssh client shouldn't trust the DNS AD bit blindly
           Product: Portable OpenSSH
           Version: 7.1p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: security
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: scott-mindrot at shambarger.net

I've been working on getting DNSSEC local validation working on OSX
with ldns (see bug 2119), and I see that the code for libresolv and
libldns both trust the AD bit in DNS responses for the SSHFP by
default.

>From RFC 4035 section 4.6,
   A resolver MUST disregard the meaning of the CD and AD bits in a
   response unless the response was obtained by using a secure channel
   or the resolver was specifically configured to regard the message
   header bits without using a secure channel.

My coffee house here happily sets the AD bit on DNSSEC answers, but I
wouldn't trust that they did the correct validation... which means I
could easily be auto-accepting server fingerprints for MITM hosts into
which I may type my password (ie "Bad(tm)")

AD bit might be useful, but not in an untrusted environment, and
currently openssh doesn't have any way to know if it can trust the AD
bit it gets, so per the RFC, it should probably ignore it unless it's
explicitly configured to do otherwise.

I suggest only treating the SSHFP as secure if the DNS response is
locally validated (eg with ldns and a locally stored root anchor), and
perhaps supporting the AD bit only if a (new) host config indicates
that it's ok.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.