Wandering Thoughts archives

2016-10-29

More on SSH, public key authentication, and 'man in the middle' attacks

Several years ago, I wrote an entry on the (apparent) resistance of SSH public key authentication to man in the middle attacks. In this entry I concluded:

[...] I believe that if you use public key authentication you're probably immune to man in the middle attacks.

I think I was too cautious here, because I've recently come to realize that for public key authentication the SSH protocol must have a very closely related property that I'm going to call 'connection laundering resistance'.

Let's assume that you have some public keys that authenticate you to some valuable service (such as Github, to make this concrete). Suppose, not at all hypothetically, that an attacker can get you to connect to a random SSH server under their control, and that as part of that connection you offer to authenticate to that server with your Github public key.

(If you think this is implausible, it's been demonstrated as a cute toy to show how SSH keys are a potential information leak.)

One of the things the attacker can do as you connect and offer your user name and SSH public keys is to turn around, make their own connection to the valuable service (here, Github), and offer your public key up to authenticate their own connection. When Github challenges them to prove that they possess the private key, they turn around and send your original connection the same challenge, then pass your answer back, and so on. They are not a man in the middle because they never claimed to be Github; instead they're trying to launder your connection to them into an authenticated connection to Github.

Obviously, it is really important that this attempt at connection laundering not work. The attacker should not be able to get their own authenticated-as-you connection to Github, one that's under their control and they can read and send traffic on, and generally you and Github should fail to authenticate and establish an encrypted connection at all.

In order to make SSH public key authentication practical, I believe that the SSH protocol absolutely must block this connection laundering attack. An attacker claiming to be a one server cannot be able to launder your connection to them into an authenticated connection to second server. And once you have connection laundering resistance, I suspect that it's a short step to extend it even to man in the middle resistance, where the attacker can't win even if they claim to be the same server.

(It would be ideal if they can't win even if they have the server's proper keys.)

Coming to this realization has made me much more confident in my 'probably' in the original entry. I don't think I can conclude that it's absolutely guaranteed, because cryptography is a land full of counterintuitive landmines, but I would now be quite surprised if SSH public key authentication had connection laundering resistance but not MITM resistance.

(And I think the SSH protocol absolutely has to have connection laundering resistance for public key authentication.)

PS: I suspect that there is a proper cryptography term for what I'm calling 'connection laundering' here. If I find out what it is, I'll probably update the use of the term in the entry.

tech/SSHAndPublicKeyMitM written at 00:10:00; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.