0

This is my understanding of Digital Certificate Signing mechanism so far. Correct me if I am wrong.

  1. www.abc.com(SSL enabled) is typed in the browser for the first time
  2. The server of abc.com sends it's public key and a Digital Signature to the browser. Along with other content, the Digital Signature contains abc.com's public key in an encrypted form. That encryption is performed with Digital Signature's private key
  3. The Digital Signature is decrypted with the corresponding public key already stored in the Browser(already stored because it is from a Certified Authority). This decryption gives Server's public key
  4. The decrypted public key and plainly sent public key are compared for equality to verify the Trust
  5. If successful, then the symmetric key is generated, encrypted with the server's public key and sent for further communication.

Now, consider a possibility for MITM attack:

  1. The hacker gets a copy of data packets that are transmitted from server to browser after step 2
  2. Since every browser has CA's public key, he can decrypt the digital signature and verify the equality with server's public keys
  3. Now, he can further generate his own version of the symmetric key, encrypt with server's public key, send to the server and pretend like an actual user

So, can a hacker's symmetric key possibly confuse the server with the original symmetric key sent by the actual user?

Will the server reply back to a hacker or only to the actual user?

Is this vulnerable or is that not possible?

Do correct me what I am missing.

Sathyamoorthy R
  • 101
  • 2
  • Your understanding of TLS is unfortunately wrong. Therefore marked as duplicate of a question where the details of TLS get explained. – Steffen Ullrich Apr 06 '18 at 12:22
  • @SteffenUllrich That doesn't answer my question – Sathyamoorthy R Apr 06 '18 at 12:42
  • Your question is based on a wrong understanding of how TLS works. It makes no sense to answer a question where the basic assumptions are already wrong. – Steffen Ullrich Apr 06 '18 at 12:54
  • it's better to point out what is wrong rather repeating the same comment. not offended. – Sathyamoorthy R Apr 06 '18 at 12:59
  • About everything is wrong: The public key of the certificate is not encrypted. Signature is not encryption. The public key gets not extracted by decrypting the signature. Trust is not verified by comparing the public key. ... – Steffen Ullrich Apr 06 '18 at 13:03
  • https://security.stackexchange.com/questions/101619/specific-clarification-on-how-https-server-public-key-is-trusted – Sathyamoorthy R Apr 06 '18 at 13:11
  • TLS handshake is not the same as digital signatures so referring to a question about digital signatures makes no sense. TLS uses digital signatures to authenticate the server but not in the way you describe. It is all explained in the question I've linked to so please read it. – Steffen Ullrich Apr 06 '18 at 13:32
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/75641/discussion-between-sathyamoorthy-r-and-steffen-ullrich). – Sathyamoorthy R Apr 07 '18 at 01:21

1 Answers1

0

This would not be possible at step 3 (emphasis added by me).

  1. Now, he can further generate his own version of the symmetric key, encrypt with server's public key, send to the server and pretend like an actual user

The public key cannot be used to encrypt, only to decrypt. The encryption is performed on the server using a corresponding private key that is kept secret and never leaves the server.

JustAnotherCoder
  • 111
  • 5
  • public key can be used to encrypt. see that answer marked by @SteffenUllrich – Sathyamoorthy R Apr 06 '18 at 12:43
  • This is incorrect, the public keys are used to encrypt, private keys are used to decrypt. A private key cannot be (correctly) used to encrypt. – AndrolGenhald Apr 06 '18 at 15:39
  • Guys, of course you can encrypt with a public key. But Then you must decrypt with private key. that’s where the original question went off the rails. – manduca Apr 07 '18 at 07:03