-2

I'd like to explain my understanding first then ask a question.

This question is meant as a simpler overview of other question..and talks about implication and not process as much.

My understanding is this:

  • client connects to server
  • server sends its public key
  • client checks with third party to see if it indeed belongs to server
  • if it checks out client sends its public key encrypted to server
  • server decrypts clients public key and then encrypt using it to respond back

My Question is how does server knows that there isn't a spy who is sending a fake encrypted public key. We were able to verify public of server but how does server verifies that key belongs to client.

I'm pretty sure I'm missing some steps in my understanding of SSL..

This is a scenario that fails my understanding:

  1. my browser makes a request to server
  2. server sends its public key
  3. browser verifies it
  4. send its own key encrypted using server's public key
  5. hacker intercepts the request
  6. use server's public key to encrypt his own key and send it instead
  7. server uses that key to respond back
  8. hacker gets the message, and then reencrypt it and pass it onto me
Muhammad Umer
  • 715
  • 7
  • 10

2 Answers2

2

Your understanding is pretty much correct, except for the fact that a client normally doesn't send a public key, but generates one on the spot (slightly simplified).

The reason this is fine is that the server is normally like a web server, and thus "everyone" can connect to it.

If you need to authenticate clients (i.e., you want to exclude spies) then you can use a feature called Client Authentication. There, the server will also check with a third party to verify that the key indeed belongs to the client.

The scenario you describe does not work for the attacker: at step 8, you will get a message that you cannot read. This is because at step 6, the attacker has modified a message, and now the server is communicating with the attacker, and not with you. The attacker cannot re-encrypt (step 8), because he does not know the private key of the server. Thus, the message you receive from the attacker will not match the key in step 3.

Note: in practice, things are a little bit more complicated -- for one, the protocol includes some extra data in the messages to protect against replay attacks, where the attacker repeats previously sent messages. Also, the public and private keys are only used to establish a communication link, after which TLS switches to symmetric cryptography (using, for example, AES). However, your question concerns the phase where keys are exchanged, so in this answer I avoided discussing these parts.

Rens van der Heijden
  • 615
  • 4
  • 8
  • I see that was what i was thinking, hacker became like a new person and won't have session cookie to get client data. – Muhammad Umer Aug 02 '15 at 14:49
  • actually, there is still a problem. What happens when hacker in the middle just gets information from server and then pass it to me. i'd think it's from server. – Muhammad Umer Aug 02 '15 at 15:09
  • 2
    Well, yes. That's how routing works. The trick is that the attacker can't read the information in this case, because the data is encrypted. Doing a classic man in the middle attack does not work, because the client verifies the certificate of the server, and will thus detect it if the attacker tries to falsify the certificate to one that he has the private key for. – Rens van der Heijden Aug 02 '15 at 15:11
  • oh ok so hacker can't get my public key because i encrypted using server's public key. So even if he gets server to believe that my public key is B instead of A. Then it can't just continue to pass messages to me, as it doesn't know my key. is that it. What happens if browser gets a garbage back from server, is it 5xx error. – Muhammad Umer Aug 02 '15 at 15:17
  • No, that's not it. The attacker can see your public key on the network, and he can change messages you send to the server, but he cannot change the responses the server sends, because those are encrypted and integrity-protected. This means that you can always verify that messages you get are actually from the server. If the attacker changes the messages you send, then the server will talk with the attacker. That means that you cannot read the responses from the server. – Rens van der Heijden Aug 02 '15 at 15:43
1

You are close, when the client connects, the server sends over the certificate which incorporates its public key. With this certificate the browser checks if it for the right URL, if the date is valid and check if it trusts whoever signed it (the root CA).

If all this checks out, the client will generate a (symmetric) session key used to encrypt and decrypt the rest of the communication. The client encrypts this session key with the public key it got from the certificate and send it over to the server. Now only the server with the private key that was used for generating the certificate (or the CSR for the certificate rather) can decrypt this session key. Now both the server and the client will use the same key for both encrypting and decrypting.

This way you can be sure that you are connecting to the server that is being shown in the address bar (as long as you pay attention to the padlock and make sure its there).

BadSkillz
  • 4,444
  • 25
  • 29
  • The session key is not generated by the client; is not encrypted; is not transmitted; and is not decrypted. It is calculated independently by both peers via a key agreement protocol. – user207421 Mar 21 '17 at 04:13