5 ms·

No, the way to solve this is to use client public key authentication. Then a successful MITM will require the client's private key too.

nothrabannosir 8y ago
No, it will only require the public key (which is public) to impersonate the server. It won’t be a MITM but it’s still bad; see e.g. the bug in this very article, or if (god forbid) you’ve set up agent forwarding. Or if you do e.g. a git pull from github on a fresh comp, it can serve you bad code. Asymmetric key is not a solution to the problem of users blindly trusting hosts without checking the fingerprint. It’s a UI problem. Every time I bring this up it gets shot down (e.g. now -3 votes), and every time I wait for someone to put forward an actual counter argument. Unfortunately, no luck. SSH is broken and it needs fixing.
- fwip 8y ago
  I'm not sure you know how public/private keys work.
  - nothrabannosir 8y ago
    This reply is tragicomically ironic :( See it like this: The bug is in the verification of the host, not the user. Eve can intercept a connection from Alice to Bob. It can "pretend" to be Bob, but it can't MITM (aka "proxy") because it won't be able to auth with Bob. However, auth depends on the server encrypting a message with Alice's public key, which everyone has ( https://github.com/torvalds.keys https://github.com/torvalds.keys !), including Eve, so Alice will connect to Eve. Really this is nothing different from just connecting to a fresh host: you upload your public key to the remote ~/.ssh/authorized_keys somehow, and voila, right? How does your ssh client know that was the same server? The fingerprint. Did you check it? No. Check out this article: > The more well-discussed use of asymmetrical encryption with SSH comes from SSH key-based authentication. SSH key pairs can be used to authenticate a client to a server. The client creates a key pair and then uploads the public key to any remote server it wishes to access. This is placed in a file called authorized_keys within the ~/.ssh directory in the user account's home directory on the remote server. > After the symmetrical encryption is established to secure communications between the server and client, the client must authenticate to be allowed access. The server can use the public key in this file to encrypt a challenge message to the client. If the client can prove that it was able to decrypt this message, it has demonstrated that it owns the associated private key. The server then can set up the environment for the client. - https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process https://www.digitalocean.com/community/tutorials/understandi... As you can see, ssh public key auth authenticates the user, not the host. anyone could be that host. Now: you as a human will quickly notice "where is my homedir? wait a second... this is not Bob—This is Eve!" the question is: quickly enough? If you were using scp: no, look at TFA. If you were connecting to github for the first time using git, perhaps using homebrew on a fresh machine: now you'll definitely never know. If you had set up your ssh key agent to forward keys to your "trusted" Bob host: serious trouble. There are loads of reasons why intercepting an SSH connection is a dramatic bug, even without being able to MITM it. Or just try and turn it around: why do you think SSH prompts you to confirm the host key fingerprint, if it doesn't matter? For fun? They didn't add that as a joke. Alas, few people understand this, as you so elegantly demonstrated :/
    - fwip 8y ago
      Your condescension is noted. The host key fingerprint does matter. That's the host's public key. The host also has a private key. Without that private key, Bob can't pretend to be Eve. You are correct that when connecting to Bob, if his public key doesn't match Eve's expected key, it will prompt the user to cancel the connection. You argue: "It will only require the public key (which is public) to impersonate the server." The key piece here you are missing is that if Bob steals Eve's public key, he won't have a matching private key, and authentication will fail. If you don't think the private keys are important, go edit them on your server, and see how SSH'ing in goes for you.
      - nothrabannosir 8y ago
        Eve is the bad guy, Bob is the intended party. Bob is not stealing keys, Eve is. Well, not "stealing", just obtaining public keys. The attack is on Alice, who thinks she's connecting to Bob, but is actually connecting to Eve. This is on initial connect, and assuming Alice doesn't check the host fingerprint (which nobody does; that's the crux of my point). This nomenclature is the convention when discussing cryptographic attacks: https://en.wikipedia.org/wiki/Alice_and_Bob https://en.wikipedia.org/wiki/Alice_and_Bob I'm going to stop discussing this in this thread, but feel free to contact me (info in profile). I promise to engage, in good faith, and if you do end up convincing me, I'll post an update here. Best wishes.
        fwip 8y ago
        Okay, swap Bob and Eve then.
        Dylan16807 8y ago
        Okay. "The attack is on Alice, who thinks she's connecting to Eve, but is actually connecting to Bob. Assuming Alice doesn't check the host fingerprint (which nobody does), the attack succeeds." You're fundamentally misunderstanding the argument about which key is being copied. It's Alice's public key that's copied. The fake server generates its own public and private keys and nobody notices that it doesn't match the real server. The user won't be "prompted to cancel" when this is their first time connecting. authorized_hosts, as typically used, prevents an imposter from showing up later. It does absolutely nothing to prevent an imposter that's there from the start.

nothrabannosir 8y ago

No, it will only require the public key (which is public) to impersonate the server. It won’t be a MITM but it’s still bad; see e.g. the bug in this very article, or if (god forbid) you’ve set up agent forwarding. Or if you do e.g. a git pull from github on a fresh comp, it can serve you bad code. Asymmetric key is not a solution to the problem of users blindly trusting hosts without checking the fingerprint. It’s a UI problem. Every time I bring this up it gets shot down (e.g. now -3 votes), and every time I wait for someone to put forward an actual counter argument. Unfortunately, no luck. SSH is broken and it needs fixing.

fwip 8y ago
I'm not sure you know how public/private keys work.
- nothrabannosir 8y ago
  This reply is tragicomically ironic :( See it like this: The bug is in the verification of the host, not the user. Eve can intercept a connection from Alice to Bob. It can "pretend" to be Bob, but it can't MITM (aka "proxy") because it won't be able to auth with Bob. However, auth depends on the server encrypting a message with Alice's public key, which everyone has ( https://github.com/torvalds.keys https://github.com/torvalds.keys !), including Eve, so Alice will connect to Eve. Really this is nothing different from just connecting to a fresh host: you upload your public key to the remote ~/.ssh/authorized_keys somehow, and voila, right? How does your ssh client know that was the same server? The fingerprint. Did you check it? No. Check out this article: > The more well-discussed use of asymmetrical encryption with SSH comes from SSH key-based authentication. SSH key pairs can be used to authenticate a client to a server. The client creates a key pair and then uploads the public key to any remote server it wishes to access. This is placed in a file called authorized_keys within the ~/.ssh directory in the user account's home directory on the remote server. > After the symmetrical encryption is established to secure communications between the server and client, the client must authenticate to be allowed access. The server can use the public key in this file to encrypt a challenge message to the client. If the client can prove that it was able to decrypt this message, it has demonstrated that it owns the associated private key. The server then can set up the environment for the client. - https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process https://www.digitalocean.com/community/tutorials/understandi... As you can see, ssh public key auth authenticates the user, not the host. anyone could be that host. Now: you as a human will quickly notice "where is my homedir? wait a second... this is not Bob—This is Eve!" the question is: quickly enough? If you were using scp: no, look at TFA. If you were connecting to github for the first time using git, perhaps using homebrew on a fresh machine: now you'll definitely never know. If you had set up your ssh key agent to forward keys to your "trusted" Bob host: serious trouble. There are loads of reasons why intercepting an SSH connection is a dramatic bug, even without being able to MITM it. Or just try and turn it around: why do you think SSH prompts you to confirm the host key fingerprint, if it doesn't matter? For fun? They didn't add that as a joke. Alas, few people understand this, as you so elegantly demonstrated :/
  - fwip 8y ago
    Your condescension is noted. The host key fingerprint does matter. That's the host's public key. The host also has a private key. Without that private key, Bob can't pretend to be Eve. You are correct that when connecting to Bob, if his public key doesn't match Eve's expected key, it will prompt the user to cancel the connection. You argue: "It will only require the public key (which is public) to impersonate the server." The key piece here you are missing is that if Bob steals Eve's public key, he won't have a matching private key, and authentication will fail. If you don't think the private keys are important, go edit them on your server, and see how SSH'ing in goes for you.
    - nothrabannosir 8y ago
      Eve is the bad guy, Bob is the intended party. Bob is not stealing keys, Eve is. Well, not "stealing", just obtaining public keys. The attack is on Alice, who thinks she's connecting to Bob, but is actually connecting to Eve. This is on initial connect, and assuming Alice doesn't check the host fingerprint (which nobody does; that's the crux of my point). This nomenclature is the convention when discussing cryptographic attacks: https://en.wikipedia.org/wiki/Alice_and_Bob https://en.wikipedia.org/wiki/Alice_and_Bob I'm going to stop discussing this in this thread, but feel free to contact me (info in profile). I promise to engage, in good faith, and if you do end up convincing me, I'll post an update here. Best wishes.
      - fwip 8y ago
        Okay, swap Bob and Eve then.
        Dylan16807 8y ago
        Okay. "The attack is on Alice, who thinks she's connecting to Eve, but is actually connecting to Bob. Assuming Alice doesn't check the host fingerprint (which nobody does), the attack succeeds." You're fundamentally misunderstanding the argument about which key is being copied. It's Alice's public key that's copied. The fake server generates its own public and private keys and nobody notices that it doesn't match the real server. The user won't be "prompted to cancel" when this is their first time connecting. authorized_hosts, as typically used, prevents an imposter from showing up later. It does absolutely nothing to prevent an imposter that's there from the start.