7

Firstly, let me start by saying that I am not attempting to hack anyone or anything (not that I would know how or where to begin, if I were).

For illustration purposes, let's call the primary key owner A, the "good" public key holder GOOD, and the "evil", MITM public key holder BAD.

Also, assume this MITM is in your ISP and you are attempting to connect via hostname vs IP (i.e., the MITM can tell you that you mean to connect to its IP).

It seems to me that there is zero difference between A connecting to GOOD and A connecting to BAD, assuming that BAD can behave like GOOD enough to convince A that he is in fact connected to GOOD (e.g., maintaining an SSH connection with A, etc.). This would give BAD the incoming half of the conversation (which, depending on the context, may be of great value to BAD).

Is the above assumption true?

orokusaki
  • 1,362
  • 2
  • 10
  • 13
  • When A connects to GOOD, he uses GOOD's public key to encrypt his messages to GOOD. If BAD intercepts encrypted message intended for GOOD, BAD can't read them, because of the encryption. Assuming A already knows GOOD's public key, he will not use BAD's public key by mistake when trying to talk to GOOD (or if he does, the system will give him a stern warning that it's a bad idea). Thus, A's outgoing messages will be encrypted with GOOD's public key, and messages from GOOD to A are encrypted with A's public key. – apsillers Jul 26 '13 at 16:46
  • 1
    If GOOD doesn't have a keypair, then A can't send encrypted messages to GOOD. In an asymmetric key system, the recipient of encrypted messages must have a private key (and then senders use the associated public key to send messages). A's public key is used for encrypting messages intended for A (i.e., to be decrypted by A's private key). To have two-way communication and authentication, you need a keypair for each party. – apsillers Jul 26 '13 at 16:50
  • @apsillers - ah, so I just had it completely backwards in my head when I started writing this question. Does this mean that, without distributing my private key, there is no possible way that any value whatsoever can be gleaned from having my public key and being a MITM, which can't already be gleaned by simply being a MITM? If so, could you please word this out into an answer so that I can accept it. Also, if so, I now feel a lot more comfortable about all the recent scares pertaining to PKI being rendered obsolete by the NSA, etc. (except that they're asking for the actual private keys). – orokusaki Jul 26 '13 at 16:54
  • 1
    Yes, correct -- that is the entire point of encryption. You can freely distribute your public key (that's why it's called a public key). The public key only allows someone to send messages to you (not as you, nor as anyone else). – apsillers Jul 26 '13 at 16:55
  • @apsillers - ugh... I just realized, I wasn't thinking backwards. I keep my private key on my notebook and put my public key on my server (in ~/.ssh/authorized_keys to allow me to SSH from my notebook to my server. This is precisely the scenario I was concerned with, connecting to a server out there that is actually a MITM pretending to be my server (also having the public key of course). – orokusaki Jul 26 '13 at 17:37
  • Yes, but your server also has its own public key that you use to send it messages. The server stores your public key in authorized_keys to verify your identity, and you store a fingerprint of the server's public (in your laptop's ~/.ssh/known_hosts) key to verify the server. See also What is the difference between authorized_key and known_host file for SSH? – apsillers Jul 26 '13 at 17:59

4 Answers4

7

With SSH, the server key pair is actually used for signatures: the server sends to the client a piece of data and signs it. By verifying the signature, the client makes sure that the piece of data is really from the intended server. That "piece of data" contains a Diffie-Hellman public key that the server just generated, and the client uses it to do the cryptographic key exchange.

To succeed at doing a Man-in-the-Middle attack, the attacker must either obtain the DH private key (but tough luck on that; the server keeps it, and rebuilding it from the public counterpart is way too expensive to be actually done with actual technology), or feed the client with a fake DH public key for which the attacker knows the private part. But the client won't accept a fake DH public key from the attacker, because that fake will not be signed with a signature corresponding to the server public key (the "permanent" public key, not the DH one).

To be brief, everybody knows the public key; it is public. It is not a problem if the attacker knows the public key. What would be a problem is if the client did not know the server's public key, because in that case the client would not be able to verify the signature from the server. Without this verification, the client can be embezzled by the attacker with a fake DH packet, and the MitM attack succeeds.

The client "knows" the server public key by remembering it. This is the reason why the first connection to a server is critical: at that point, the client does not know the true server public key yet. The client is supposed to verify the key fingerprint by (for instance) phoning the server sysadmin.

All of this relies on the magic of asymmetric cryptography:

  • You can verify a signature with the public key, but producing new signatures requires knowledge of the private key, and the private key cannot be (practically) deduced from the public key.

  • The DH key exchange consists in publicly exchanged messages, sender and receiver finally agree on a "shared secret" obtained by processing these messages, and yet someone observing only these messages cannot recompute the same secret.

Mathematics are involved.

Thomas Pornin
  • 326,555
  • 60
  • 792
  • 962
  • Ah, thanks man. This is the light bulb moment I was looking for. Despite my having originally flip-flopped the public/private situation in my head, I was still left with some confusion, especially after having conflated the issue of CAs and then plain ol' PKI via something like SSH. – orokusaki Jul 26 '13 at 17:11
  • Could you look at my last comment to @apsillers on the original question. I don't think this answers my question or resolves the concern, still. – orokusaki Jul 26 '13 at 17:38
  • 1
    What I described is the authentication of the server key by the client. When you want to authenticate the client with a key of his own, the same process happens in the other direction as well: client signs some message (which includes some connection-specific elements) and the server verifies the signature, using the public key in the authorized_keys (on the server). There again, everybody can know your client public key (it is public) but nobody can forge such signatures (because this requires your private key, which does not leave your notebook). – Thomas Pornin Jul 26 '13 at 17:43
5

If they only have your public key there is not a lot they can do if encryption is used, as they won't be able to communicate as if they are you.

This is why it is called public. . . Everyone can have a copy of your public key. Anything they encrypt with your public key can only be decrypted by your private key, and vice versa.

Rory Alsop
  • 61,507
  • 12
  • 118
  • 322
  • What I mean isn't to suggest they can pretend they're me because they have my public key, but rather that they can pretend they're the server I'm trying to connect to, if they're between me and that server, and they have my public key. – orokusaki Jul 26 '13 at 16:23
  • @orokusaki Do you not have your server's public key? – Brendan Long Jul 26 '13 at 16:25
  • @BrendanLong - I'm not sure I follow. I (A) am the owner of the public/private pair, and have distributed my public key so that anyone can have it. There is a MITM (BAD) who controls my WAN access (including DNS lookups, naturally), who also has my public key (since it's distributed). I am trying to connect to GOOD (which also has my public key). – orokusaki Jul 26 '13 at 16:29
  • @orokusaki What I mean is that you're only looking at it from one side. The server should also have a public and private key, and you can tell if there's a MITM if their messages aren't signed by the server's private key. – Brendan Long Jul 26 '13 at 16:38
  • @BrendanLong - I have a private key, whose public counterpart is on a server that I intend to SSH to. – orokusaki Jul 26 '13 at 16:41
  • 1
    The public key alone doesn't prove identity, you establish your identity using the private key, and the public key is used to verify that (as well as prove you are who someone else says you are). It works in both directions, a MITM cannot pretend to be a webserver without the webserver's private key. A critical part of this trust is pre-knowledge of CA root certs. – mr.spuratic Jul 26 '13 at 16:42
2

In asymmetric cryptography, everyone has the public keys and only the entity being verified by the public key has the private key. The public key and private key are related in a way that having the public key doesn't reveal anything about the private key, but that the holder of the private key can prove their identity by having someone verify a challenge using the public key.

Basically, something that is encrypted with a public key can only be decrypted by the private key and something that is encrypted with the private key can only be decrypted with the public key.

To prove the server is who they claim to be, they encrypt a challenge with their private key (which only they have) and the public key is used to verify that the challenge can be decrypted, thus the other party has the private key.

To talk to the server securely, the public key is used to encrypt a symmetric session key. That session key is encrypted with the public key and sent to the server. Only the valid server (that has the private key) can decrypt the session key, so only the client (who created the session key) and the server with the private key can communicate.

The public key is trusted by the client because it is similarly signed by a root certificate authority which is included with the browser.

Update: I misread the question as SSL, not SSH. The basic idea is still roughly the same, but the server certificate often won't be signed by a CA, in which case the certificate needs to be manually verified the first time after which your client should keep track of who you connected to last time. The key exchange also differs in terms of how a key is agreed upon, but I don't know the SSH handshakes as well as I know SSL's, so see Thomas Pornin's answer for that.

AJ Henderson
  • 42,081
  • 5
  • 65
  • 112
0

Since it is current, there is something else you must consider. MITM without end point control is one thing, and is pretty secure (minus certain state terrorists' weakenings), still does not account for the most effective MITM which is if they have access to your unencrypted server, game over. They can copy the private key, and perform a MAN-AT-THE-END rather tham MITM attack, which is 100% effective, as in check MATE.

Njomsky
  • 59
  • 1
  • 2