VerifyHostKeyDNS, was Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30

Paul Wouters paul at xelerance.com
Thu Oct 13 14:46:01 UTC 2011


On Thu, 13 Oct 2011, Tomas Mraz wrote:

> Nope, you do not understand what the dependency is. Of course you depend
> on the DNS to not be compromised to get the IP address of the host but
> you still can verify the fingerprint on the first connection if you got
> it by other means.

That scales as well as all those firefox plugins that warn you when a cert
changes.... but yes, a very few individuals with pick up the phone, and good
for them!

> and you'll connect to a different host. With 'VerifyHostKeyDNS yes' if
> there is a malicious DNS administrator, you will not have a chance to
> verify the fingerprint, you will be directly connected to a false server
> immediately compromising your password if password auth is used.

That's a very good argument - but against password ssh authentication, not
against fingerprints in dnssec.

1) the infrastructure is already compromised by an inside DNS admin
2) the user apparently typing in a password into a machine they never
    contacted before.

You should use "ssh-keyscan remotehost" to a machine you never connected to
before where you depend on password authentication to avoid this.

The only scenario where I can see trusting machines I never logged into before
is one where the cluster is trusted by the same admin, using the same usernames
and shared homedirs, in which case I would alwas have my authorized_keys,
and would immediately hit ctrl-c when a password prompt would happen.

> And if
> this malicious DNS administrator controls the caching nameserver you're
> using for DNS queries, he can present you ANY data even 'valid' fake
> DNSSEC data.

I have no idea what " 'valid' fake DNSSEC data" is supposed to mean. I
am assuming you mean something silly as "trust random dhcp obtained dns
server's AD bit". If you do that, you already lost before even getting
an ssh login on a new server. Any security aware fedora user is running
a local DNSSEC caching server. If not, then ssh will prompt them with
the host key!

Also, trusted the AD bit without trusting the last mile violates the RFC 3655
Section 3

    3.  Interpretation of the AD bit

    A response containing data marked Insecure in the answer or authority
    section MUST never have the AD bit set.  In this case, the resolver
    SHOULD treat the data as Insecure whether or not SIG records are
    present.

    A resolver MUST NOT blindly trust the AD bit unless it communicates
    with a recursive nameserver over a secure transport mechanism or
    using a message authentication such as TSIG [RFC2845] or SIG(0)
    [RFC2931] and is explicitly configured to trust this recursive name
    server.

If the ssh client grabs non-localhost resolver entries and trusts the AD
bit, then that is a bug and should be reported upstream.

Paul


More information about the devel mailing list