How to decrypt HTTPS (ECDHE) data?

Question

I am trying to understand how exactly HTTPS works and doing a little practical tests.

I have a data captured from HTTPS communication encrypted by TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA.

If I understood it right, client during the TLS handshake creates a master key, which is then encrypted using server's public key and sent to server. This master key (as a plain text) is then used as a symmetric key for encrypting ongoing communication. Is this correct?

If yes, how to decrypt the data, if I know the master key?

It sounded pretty easy to me at first, so I just wrote this script

$masterKey = '8ef36f0eb2c10ea6142693374f6c5c7ae65eee5f6bd45bd1990b08e6c144227382726496b795d62284bd8c6c0cadbbdb';

$someRandomEncryptedData = '170303001D314A69C7DF95E07AAF51FBDA01C178D45330BC902308DF8C418FA5B02B';

$sDecrypted = mcrypt_decrypt(MCRYPT_RIJNDAEL_256, pack('H*', $masterKey), pack('H*', $someRandomEncryptedData), MCRYPT_MODE_CBC);

echo $sDecrypted;

Then I notice that master key is 96 byte long (48 as binary string), which results to PHP warning as the key should be 256 bit (32 byte) long. Am I missing something?

Answer 1

client during the request creates a master key, which is then encrypted using server's public key and sent to server. This master key (as a plain text) is then used as a symmetric key for encrypting ongoing communication. Is this correct?

Well, all-in-all, No.

Because you are asking about DH and ECDH, which are Key Agreement protocols: the client does not generate a random key, encrypt it under the server's public key and then send it to the server. That's Key Transport (like RSA Key Transport), and not DH or ECDH. Key transport is going away in TLS 1.3.

There are two phases to TLS: key agreement and bulk transfer. The phases are not as well defined as in IPSec. When the client and server use DH or ECDH, they arrive at a premaster_secret. That's the shared secret drops out of Diffie-Hellman or Elliptic Curve Diffie-Hellman.

They take the premaster_secret, they add a client random, a server random, and arrive at a master_secret. Then they take the master_secret and derive 6 symmetric keys from it:

• Client initial IV
• Client encryption key
• Client mac key
• Server initial IV
• Server encryption key
• Server mac key

Those keys are used to key a block or stream cipher.

If you notice, each side contributes to the premaster_secret - the client contributes g^a and the server contributes g^b. Then each side contributes to the master_secret through nonces - the client random and the server random.

The reason there's two contributions from both sides is transport schemes, like RSA Key Transport, don't allow the server to contribute to the premaster_secret. The server has to wait until the derivation of the master_secret to contribute to the key material via a nonce.

So the progression is premaster_secret to master_secret to 6 session keys. I'm not sure where the master key is...

---

If yes, how to decrypt the data, if I know the master key?

I think its usually easier to just plug it into Wireshark if you have the master key. The Wireshark wiki talks about a master key (though I don't know what it is - there's a premaster_secret and master_secret). See the Wireshark wiki for Secure Socket Layer (SSL).

---

It sounded pretty easy to me at first, so I just wrote this script

Yeah... :) Check out RFC 5246. That's Transport Layer Security (TLS) Protocol Version 1.2. Then let's talk about easy :)

---

Then I notice that master key is 96 byte long (48 as binary string)

96 bytes is the output of the PseudoRandom Function (PRF). Check out RFC 5246, page 13.