Download: Stable · Snapshot | Docs | Changes | Wishlist
PuTTY 0.68 introduced a dynamic
policy for setting the host key preference order in the
SSH_MSG_KEXINIT message. Host key types for which the
client already has a stored host key are promoted to the top of the
list. This ensures that if the client does have at least one stored
key for the server, then one of those keys will be used in the
Without this option, if you already had a host key stored, and the
server acquired a new key higher up PuTTY's default preference order
sshd upgrade caused an Ed25519 key to be
generated when previously the host only had RSA), the client would ask
you to confirm the new key, even though you already knew a key you
could use to talk to that host safely.
However, this policy has a downside as well as an upside. The list of
host key types is sent in cleartext in the first
SSH_MSG_KEXINIT message of the connection. So a network
snooper eavesdropping on all your SSH connections will notice the
different orders of host key preference used for different hosts, and
can use those to make a guess about which servers you already have
host keys for, and which ones you're connecting to for the first time.
So, if you're the kind of user who clicks "accept" to new host keys without checking them out of band (the TOFU policy – Trust On First Use), and if an active attacker is intending to substitute fake host in your SSH connections, then they might be able to use this clue to substitute fake keys for only the hosts you don't already have keys for, which might reduce their risk of being detected when performing that attack.
PuTTY 0.74 comes with a new configuration option in the SSH > Host keys panel: “Prefer algorithms for which a host key is known”. This option is on by default. If you turn it off, you can revert to the pre-0.68 policy in which the same host key preference order is used regardless of the keys you already have cached for a given server.
Our analysis is that this is a choice with pros and cons on each side. Taking several classes of user in turn:
We think this user benefits from the default dynamic policy. (These are the users for whom we introduced it in the first place.)
Checking host keys out of band is awkward, and sometimes not possible (if you can't contact the admin of the server by other methods at the time you need to make the connection). So it's desirable to avoid it whenever possible.
The information leak is not important to this class of user, because an attacker substituting a phony host key will be detected anyway by the out-of-band check.
For this user, it makes very little difference which option they select!
Suppose they turn off the dynamic host key policy, and the active attacker tries to fake a host key for an already-known server, in a case where they would otherwise have been warned off by a changed preference order.
In most cases this will mean that the server does not provide the host key type at the top of PuTTY's preference list (or else the preference order would have been the same even with the dynamic policy enabled). So the attacker could substitute that topmost host key type in any case, and still not be detected.
This is the class of user who is likely to benefit from turning the dynamic policy off, because in this case, the attacker will be misled into trying to attack a connection to an already-known server; they will substitute a host key of a type the server does not provide; and the semi-oblivious user will notice, and check up on it, and detect the attack.
This potential vulnerability was reported to us by the Competence Center for IT security at the FZI Research Center for Information Technology. They have assigned it the id FZI-2020-5, and Mitre assigned it CVE-2020-14002. Here is their own writeup of the issue.