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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
