[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#81668: the "fix" that caused this symptom is solving the wrong problem



On 4/16/07, Florian Weimer <fw@deneb.enyo.de> wrote:
* Kacper Wysocki:

> 1. If the attacker has the ability to spoof my DNS, I have been
> compromized. It doesn't need to resolve to a FQDN, a spoofed DNS can
> resolve my "shortname" to the IP of their choice. They can do this for
> all my services, not only ssh.

SSH is supposed t work (IOW, fail reliably) even when the attacker
controls DNS (or the routing, for that matter).

The only way to achieve that is not to rely on DNS, which means that
the specified host name must be processed unaltered.

... which is where the IP comes in. Since the hostkey exchange relies
on the security of that first time connection, the specified hostname
doesn't need to be "processed" at all - it functions merely as a
menemonic for the user. However, at some point it'll have to be looked
up in DNS - and if it's done that critical first time as a point of
reference (user gets notified of the resolution along with the key
fingerprint), later lookups can be DNS-spoofing-proof where your
approach isn't.

To put simply: the hostkey lookup in known_hosts is most securely done
when matched only on IP, then the hostkey signature comparison can run
its course.




Reply to: