A vulnerability in OpenSSH <= 8.4 allows a man in the middle attack to determine, if a client already has prior knowledge of the remote hosts fingerprint.
Using this information leak it is possible to ignore clients, which will show an error message during an man in the middle attack, while new clients can be intercepted without alerting them of the man in the middle attack.
SSH Host Keys¶
According to RFC-4251,
SSH clients keep track of trusted servers by verifying a fingerprint with the user, storing
identity and public key material in the
known_hosts file (or any other decentralized local database)
when connecting for the first time.
The ssh trust on first use concept is an artifact dating back to a more simpler time. Then it was considered a definite step up to its counterparts in terms of security. Now it is frowned upon by many people who value their security dearly. With the now readily available Public Key Infrastructure (PKI) of the internet, there is no need to verify the identity of the server against fingerprints.
This way of handling trust can have multiple implications for an operating mitm server which is trying to audit ssh connections:
the mitm server wants the user to associate his public key with the identity of the actual remote host
OR if the remote host is already known
it wants to pass through the connection to the remote host and not alert the user of the mitm operation
CVE-2020-14145: OpenSSH Client Information Leak¶
Using this vulnerability a ssh server can figure out if a connecting client has prior knowledge of the remote hosts public key fingerprint during algorithm negotiations.
The reasoning behind this ability to extract information about client to server association lies in the
algorithm negotiation itself. Particularly in the way the
server_host_key_algorithms are sent.
The official SSH Transport RFC 4253 requires
each named list in the algorithm negotiation to make the first item a guessed preference.
This is understandable for Key Exchange, Crypto or MAC algorithms but leads
to exactly this information leak when also applied to the
server_host_key_algorithms. This named list is used
to negotiate which public key associated with the corresponding key generation algorithm should be used
to authenticate the identity of the server.
Following comparison will make the described anomaly in question more clear:
New Fingerprint server key: ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 ssh-ed25519 rsa-sha2-512 rsa-sha2-256 ssh-rsa Known Fingerprint server key: rsa-sha2-512 rsa-sha2-256 ssh-rsa ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 ssh-ed25519
This is a shortened list of the actual output when using the default host key algorithms list.
With no prior knowledge of the remote host the OpenSSH Client will send a pre-defined default list of server host key algorithms to choose from. If the remote host is known i.e. an entry in the local database matches the remote, the key information of the entry will be used to change the order of the list being sent.
Knowing this a mitm server can simply compare the list of server host key algorithms to a default list and determine if the client is connecting for the first time or not, then process them accordingly.
OpenSSH 8.4 has implemented a patch that will not alter the named list of server host key algorithms if the default algorithm (ecdsa-sha2) is locally stored for the remote host, this can partially be worked around by not actively choosing that algorithm as option on the ssh server.
HostKeyAlgorithms as an ssh option manually this described anomaly will not occur
because the given list of algorithms will always be used as-is. This can be used to mitigate the
Another way of mitigating this information leak is to only accept certificate based host key algorithms. According to research done by the FZI this will not alter the order of the server host key algorithms and therefore no information will be leaked.