3

I am trying to fill in gaps of my understanding of HTTPS.

I understand that the server sends the client a public key to encrypt information and that only the server has the private key which prevents interception of request packets.

What happens in the response side of things? E.g. web application server responds with a session token, or is responding with sensitive information. Could a MITM attacker catch the initial public key response from the server and pretend to be the intended client? Or does the client also have a private/public key that it uses to handle the responses, and passes the public key inside the request?

Basically wondering if you can pretend to be the client, instead of most MITM where the attacker pretends to be the server.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
Cyassin
  • 503
  • 2
  • 6
  • 12

3 Answers3

2

There are two separate problems mentioned in this question: authentication and session encryption.

As for eavesdropping on the initial response, it is a problem of encrypting the session. Each session between the client and the server is protected using a different key. The key exchange algorithm (whichever is used) ensures only one party receives the keys used to secure the transmission.

The technical details were already explained in answers to How does SSL/TLS work?, but in brief an ephemeral key-pairs are used. They are separate from the public key sent by the server in the certificate.

The server's public key (included in the certificate) is on the other hand used for authentication (in public-key cryptography when you encrypt the data with a private key you are effectively signing it not encrypting, anyone can decrypt it with the publicly-known public key).

For the client authentication you can also use a key-based authentication, but this scenario is much less common. Usually you authenticate using password or some other method over an already-established secure channel. In this scenario there is no need or way to "pretend you are the intended client" because at the moment of initiating the connection there is no notion of the intended client yet.

Community
  • 1
techraf
  • 9,141
  • 11
  • 44
  • 62
  • Im still a little confused, so if you could point me towards to section of the How SSL/TLS works link that explains it. Basically my case scenario, is what prevents user 1 using site a over HTTPS from going to the sites login page, authenticating but having the response packet that contains say the application sessionId captured by user 2 in the middle and decrypting that response packet. – Cyassin Aug 03 '16 at 05:29
  • "Key Exchange" in Thomas Pornin's answer. User1 does not have the key to decrypt User2 packets and vice-versa. – techraf Aug 03 '16 at 05:45
  • I did read that section, in which it still appears unclear to my question. I can't take away from it how responses are encrypted. If the client (and MITM) has the public key from the cert, and the server has the private key how does the key exchange understand who is user1 to send packets to if MITM reads all handshake information and knows exactly what user1 knows? – Cyassin Aug 03 '16 at 06:16
  • Forget the key from the certificate for a moment. Each connection between A and B (no matter who they are) uses different, random, ephemeral keys. The key exchange protocol assures no eavesdropping-attacker can deduce the key that the server and the client agreed on. That's what it is designed for. It ensures the communication is encrypted between A and B, and no C can decrypt it. – techraf Aug 03 '16 at 06:26
2

As @techraf wrote, there are two things provided by TLS: authentication and encryption.

Basically wondering if you can pretend to be the client, instead of most MITM where the attacker pretends to be the server.

Bearing it in mind, let's focus on authentication.

The typical HTTPS communication over Internet is used to assure clients that the server is what it claims to be, e.g. e-bank. However, in typical Internet scenario, a server does not authenticate clients via HTTPS. In this e-bank example, you need to provide credentials so the bank knows who you are (not your own certificate).

On the encryption level: after the initial TLS handshake, a session specific symmetric key is negotiated between the client and the server, and it's the symmetric key that is then used to encrypt all traffic on the HTTP connection in both directions.

EDIT: when you are in the middle of the communication channel and you crack the TLS connection then you can impersonate both sides of the communication: a client and a server. Which is a typical MItM scenario, but just like you wrote: usually we want to trick clients, not servers.

boleslaw.smialy
  • 1,627
  • 2
  • 15
  • 25
2

A useful resource on this is The First Few Milliseconds of an HTTPS Connection.

Public key cryptography is used in order to authenticate the server to the client. That is, the client then cannot be tricked into connecting to a MITM pretending to be bank.example.com because only the real bank.example.com will have the private key.

Once this is established, a pair of symmetric keys are established. One for client to server traffic, and another for server to client traffic.

A MITM cannot decrypt the server to client traffic because it has no knowledge of the private key agreed.

A very simplistic overview is:

  • Client generates a ClientHello.random and sends it to the server during initial handshake.
  • Server generates a ServerHello.random and sends it to the client during initial handshake.
  • Client generates a 48 byte "pre-master secret" and sends it to the server encrypted by the server's public key.
  • A master secret is calculated using the formula master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)
  • PRF is a mixture of MD5 and SHA-1.
  • A key block is calculated using key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random);
  • The keyblock is sliced up to give separate asymmetric keys for traffic in each direction (along with some IVs and MACs which you can ignore for the purposes of answering your question).
SilverlightFox
  • 33,408
  • 6
  • 67
  • 178