2 ms·
Yes, That is exactly the reported issue here. PuTTY 0.68 through 0.73 allows the remote attacker to accurately determine whether or not the client has cached t
by Randor 6y ago
Yes,
That is exactly the reported issue here. PuTTY 0.68 through 0.73 allows the remote attacker to accurately determine whether or not the client has cached the host key. It looks like this works because PuTTY sends a different algorithm list depending on whether or not the key has been cached.
If the MiTM attacker sees the 'default algorithm list' it can be assumed that this is the first connection attempt and the attacker can substitute the server key with a compromised key.
- 8organicbits 6y agoAh, that's cool. I pushed AWS to give better ways of getting the host key for new EC2 instances a few years back. The whole start an EC2 instance, SSH in and blinkly trust the host key on first use thing seemed terrible! EC2 docs now include that detail, although its labeled as optional. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connection-prereqs.html#connection-prereqs-fingerprint https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecti...