4 ms·
Something that's skimmed over in the article but not addressed is: if the key pair isn't used for encryption, then how are session keys protected? The answer i
by oxplot 6y ago
Something that's skimmed over in the article but not addressed is: if the key pair isn't used for encryption, then how are session keys protected?
The answer is: using the server's public key which is transmitted to client when establishing the connection.
But then it's trivial to perform a person-in-the-middle attack and both observe and manipulate the plain text data by sending the client the attacker's public key.
That's why it's crucial to retrieve host keys via secure channels and explicitly whitelist them on clients.
- tialaramex 6y ago"Protected" is an odd word to choose here because session keys are agreed long before we know who we're talking to. The approach of SSH (like modern TLS) is to create a secure channel between two participants and only then authenticate one or both participants by binding credentials to this secure channel. The article gets that upside down, which is understandable because most people seem to imagine that it'd be essential to figure out who you're talking to first and only then encrypt things, but actually the opposite is better. If you do Trust On First Use as many SSH users do, then you're correct that bad guys can interpose on that first connection if they happen to get lucky - but that's because they can authenticate as the "correct" server by presenting their own public key since you have no idea what the correct one looks like.
- bogomipz 6y ago>"The answer is: using the server's public key which is transmitted to client when establishing the connection." This was true in SSH v1 which is ancient but in modern times v2 uses DH and the the server's pub key is only used to sign the DH parameters.
- emj 6y agoYou can use: "monster in the middle", mitm, if you want to keep it gender neutral.