Non-RSA TLS1.2 Packet decryption

问题:

I am trying to decrypt a pcap file. This pcap file contains a capture of an HLS encrypted video stream. The pcap contains TLSv1.2 packets.

Below are some information from the pcap file

Server Hello message Cipher Suite:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.

EC Diffie-Hellman server Params: pubkey (1)

The Certificate Status message:

Signature Hash Algorithm Hash: SHA256

Signature Hash Algorithm Signature: ECDSA

Client Key Exchange Message

EC Diffie-Hellman server Params: pubkey (2)

I tried to follow this Wireshark SSL decryption tutorial. But it seems that it works only for RSA encryptions. I have been researching for a while and found this discussion. I am quoting an extract from this discussion:

There is an important parameter to mind: decryption of a passively recorded session (with a copy of the server private key) works only if the key exchange was of type RSA or static DH; with "DHE" and "ECDHE" cipher suites, you won't be able to decrypt such a session, even with knowledge of the server private key. In that case, you will need either the negotiated "master secret", or to use the server private key to actively intercept the connection

It's note worthy that I have the client private key. In my case, the client is FFmpeg video streamer (FFplay). I had a look also on the TLS v1.2 RFC.

My question:

Is it possible to do a decryption in this scenario ? If yes, what do I need to have to do so?

Is the decryption done using the client's private key or using the pre_shared_master (i.e. Diffie-Hellman) ?

回答1:

No, it is not possible to decrypt in this scenario. That would involve breaking EC Diffie-Hellman.

Decryption is not directly performed using the pre_master_secret but it is performed by keys directly derived from the pre-master secret. That is: the client and server decryption keys that are derived from it by first deriving the master_secret and then performing the PRF and dividing the output to the session keys and IV's.

回答2:

First, the clients private or public key are not involved in the key exchange in any way but only used to authenticate the client (if requested by the server). What is used in the key exchange are the servers private and public key, but only if RSA key exchange is used. For DHE/ECDHE they are not used so private/public key are not sufficient. See it is possible to decrypt HTTPS with the (private, public) pair if it uses DHE? for the details why this is the case.

What you would need instead of the private key is actually the exchanged key which is unique for each TLS session even if the private key is the same. Some clients can store this key for later use and if your client can do it see Decrypting TLS Browser Traffic With Wireshark – The Easy Way! how to proceed then to decrypt the traffic.