0

(shown in step 1): Is the initial process in public key encryption where the public key is transferred across the network done in plaintext? It seems like it must be, which essentially means that no matter if a victim is using HTTPS or a VPN on a public network, if the initial process is done in plain text, than a middleman who has full access to the network traffic can essentially just intercept that initial public key transfer process, steal the key, and effectively intercept the rest of the victims "secure" transmission in their "secure" internet session?

enter image description here

So if I am right, public networks are only secure as long as the device obtaining the public key was there before the attacker was?

twominds
  • 101
  • 3
  • A public key is **public**, the attacker doesn't need to intercept it, we already assume they have it. If the public key is used for messaging, then only the related private key owner can decrypt it. Of course, we want signatures on the sent messages, too. If the public key is used for verifying the signatures, that ok, we already wanted that, too... – kelalaka Oct 16 '21 at 08:31
  • If the attacker introduces their public and private key to the communication, and the clients think that this public key is the servers' key then we have a problem. That is why we have CA as the only solution – kelalaka Oct 16 '21 at 08:34

3 Answers3

1

Yes. This is where PKI comes into play, where a trusted 3rd party (a trusted CA) ensures you: "yes, this is Mr. Smith/example.com, I personally issued a certificate to him, you can verify my signature under his X.509 certificate using my public key which you already know". It's basically how TLS works.

Alexander Fadeev
  • 1,244
  • 4
  • 10
1

Yes, it is.

It's one of the core problems of the Public-Key Cryptography and there are several ways that this could be mitigated.

Web-of-Trust

The idea of the Web of Trust is that you verify - in person - who a key belongs to, and assign trust to it. So you can trust those, whom you verified personally. But you can also trust someone, who was verified by someone you trust. This way, trust propagates, because people each individually verify each other.

At least...in theory. In practice, this design doesn't work all too well, because most people don't ask you for your public key fingerprint and write it down, then manually trust it at home. No, they download your public key from your website and trust (no pun intended) that it will be fine.

Certificates and Certificate Authorities

A more common and arguably more successful approach is that of Certificates and Certificate Authorities (CAs). The basic idea is that a set of public keys of authorities are given to you out-of-band (e.g. when you install your OS). These public keys are then used to sign other public keys, and those again sign other public keys.

If you wish to check whether or not someone or something is "trustworthy", you check if their key has been signed by a Certificate Authority you trust, or by another key, which is signed by a Certificate Authority you trust.

  • 1
    Excellent answer, as usual. But, I believe OP's question is not about an attacker creating a fake public key or certificate for the server. It seems that OP is asking what prevents an attacker who is positioned between the client and the server from intercepting the connection, given that the attacker has knowledge of the public key, because the public key is sent from the server to the client in the clear. – mti2935 Oct 15 '21 at 13:13
1

a middleman who has full access to the network traffic can essentially just intercept that initial public key transfer process, steal the key, and effectively intercept the rest of the victims "secure" transmission

No.

The middleman would not have the private key associated with the public key that he has intercepted. Therefore, he would not be able to intercept the session key sent from the client to the server in step 2 of your diagram.

Related: Could a stolen certificate show as trusted?

mti2935
  • 21,098
  • 2
  • 47
  • 66
  • 1
    Of course he can. If Alice sends her public key to Bob and Mallory intercepts it, then Mallory can exchange it for his public key. Bob would still believe the key he received is from Alice and trust it. –  Oct 15 '21 at 12:54
  • So you are saying that once the session key is encrypted by the public key (1), it cannot be decrypted by the same public key sent by the server and can only be decrypted by the private key (2)? If so, how is this possible? – twominds Oct 15 '21 at 12:55
  • 1
    @MechMK1, OP is describing a scenario where the attacker intercepts the server's public key then attempts to use it, not a scenario where the attacker attempts to create a fake public key / certificate for the server - i.e. `a middleman who has full access to the network traffic can essentially just intercept that initial public key transfer process, steal the key,`. – mti2935 Oct 15 '21 at 12:59
  • 1
    @twominds This is how asymmetric cryptography works. A message is encrypted with the recipient's public key, then the recipient uses his private key to decrypt the message. See https://en.wikipedia.org/wiki/Public-key_cryptography. – mti2935 Oct 15 '21 at 13:02
  • @mti2935 Let me clarify your last statement for my understanding. The public key cannot decrypt the session key in step 2, only the private key can? If so, is it due to the way the asymmetrical encryption algorithm works? – twominds Oct 15 '21 at 13:04
  • 1
    @twominds. Yes, that is correct. The public key is used to encrypt a message. The encrypted message is the 'ciphertext'. The public key cannot be used to decrypt the ciphertext. Only the private key can be used to decrypt the ciphertext. This is the way the algorithm works. – mti2935 Oct 15 '21 at 13:07
  • @mti2935 Very interesting, I hope we can all come to agree on this. I found an interesting source that backs up your last statement: https://ibm.co/3aGJ3p8 – twominds Oct 15 '21 at 13:08
  • 1
    @mti2935 That's not how real life attacks work. An attacker will do whatever they can, not adhere to some arbitrary constraints set by a theoretical scenario. Sure, if they *only* read the key, then there's nothing the attacker can do. However, **interception** means being able to modify the network communication, and in this case, it's game over. –  Oct 15 '21 at 13:21
  • 1
    @MechMK1 Of course there are many ways that the attacker can attempt to intercept the connection. OP is asking specifically about what prevents an attacker who is positioned between the client and the server from intercepting the connection, given that the attacker has knowledge of the public key, because the public key is sent from the server to the client in the clear. This answer attempts to explain the answer to this very narrow question. – mti2935 Oct 15 '21 at 13:28
  • 1
    @mti2935 And as I stated - an attacker *can* intercept the connection this way and gain access to the encrypted data by acting as a MitM proxy. –  Oct 15 '21 at 13:31
  • @MechMK1 Let me clarify your last statement for my understanding. The attacker intercepts the public key (1), creates their own session key (2), and the server uses the attackers fake session key made with the stolen public key(2). Now that the attacker has their own session key, data encrypted with their own session key can be sent to the server. But no matter the scenario, the attacker cannot read the victims data because it can only be decrypted using the private key? If this is true, then you both are right. – twominds Oct 15 '21 at 13:38
  • @mti2935 I found this working online interactive example with RSA asymmetric encryption that essentially proves your statement right: https://bit.ly/3AJEBka But I do believe MechMK1 is also correct, as an MITM attacker could do various other attacks on the victim now that they have access to the victims session on the server, such as requesting already saved data from the server. No matter the case, the attacker will never be able to read the current data transmitted from the victims device, as long as the victim is still using encryption. Please correct me if I am wrong. – twominds Oct 15 '21 at 14:13
  • 1
    @twominds MechMK1 describes a classic Man In The Middle (MITM) attack, where the attacker creates a fake public key for the server, and presents this public key to the client, and fools the client into trusting that this is the correct public key for the server. See https://en.wikipedia.org/wiki/Man-in-the-middle_attack for more info. He is absolutely correct that an attacker who is able to pull this off can intercept the connection. In this case, two sessions are created: one between the client and MITM, and another between MITM and the server. So, MITM can see data sent in both directions. – mti2935 Oct 15 '21 at 14:26
  • 1
    @twominds The servers sends the public key to the user, but the attacker intercepts it. The attacker then creates a session with the server. At the same time, the attacker sends his own public key to the client, and the client generates a session with the user, while *believing* that they are in a session with the server. The server forwards all messages between client and server, while himself being able to read and modify all traffic –  Oct 15 '21 at 14:30
  • @MechMK1 Oh I see, I didn't realize that the attacker can just forward the traffic along as if it were the server. But let me be sure, RKI and certificate authorities fix this entire issue? – twominds Oct 15 '21 at 14:33
  • 1
    @twominds Yes, as long as certificates are validated correctly. The security depends on the fact that an attacker will not be able to get a certificate for a server, for which they cannot prove ownership. –  Oct 15 '21 at 14:35
  • @MechMK1 and mti2935 WOW, you guys are incredible. Thank you. On my behalf, I apologize for not specifying my question in a way where It has a single decisive answer. I am torn on who to give the checkmark to because all three answers are technically right. Maybe you guys can help me? – twominds Oct 15 '21 at 14:39
  • @twominds You don't need to give an accepted answer. It's not a necessity. –  Oct 15 '21 at 14:47
  • @twominds I agree with MechMK1, it's really not about the upvotes. Glad we were able to clarify a few things for you. – mti2935 Oct 15 '21 at 15:13
  • a public key is public what is the point of stealing it? Each connection must be signed with the private key, so the attacker will fail. And usually, we have different keys for public-key encryption and signatures. – kelalaka Oct 15 '21 at 21:47