Ask Your Question
0

TLS decryption with NSS key log but without handshake frames

asked 2025-02-13 14:01:25 +0000

Hi,

I'm in the use case where a client and a server established a TLS1.2 tunnel using ECDHE. I'm able to extract from client (or server) the premaster secret and the client random to give it to wireshark following TLS1.2 NSS key log format. When i read my .pcap (containing the handshake frames), wireshark is able to decrypt the data.

In my use case, i start to record the network only when something wrong happen. => So i only have, in my record, encrypted data (handshake frame are not available). I'm able to have the NSS key log. => Wireshark is not able to decrypt data, and this is normal since TLS master key is computed with KDF[premaster secret, client random, server random] and only "client random" and "premaster secret" are available in my NSS key log file.

==> Is it possible with wireshark to decrypt such TLS1.2 record (without having access to the handshake frame) ? -> For example, giving to wireshark also the "server random" ? (but server random is not mentionned in the standardized NSS key log format).

==> I know TLS1.3 is quite different in the way of computing TLS keys. Do you know, if using TLS 1.3 and "TLS1 1.3 NSS Key log) I will have the same issue ?

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
0

answered 2025-02-24 21:45:15 +0000

André gravatar image

The decryption of a TLS stream will fail, regardless of version, if there is a gap in the TLS stream. So, if the initial handshake is missing no data will be decrypted.
If the gap is later in the stream then it will fail at that point. This may happen when the TCP preferences "Allow subdissector to reassemble TCP streams" or "Reassemble out-of-order segments" are not enabled.

If the detection trigger comes after the initial handshake then the only option is to capture continuously, using a ring buffer, and use the trigger to either stop the capture or extract the needed data. For example:

dumpcap -b filesize:102400 -b files:10 -w demo.pcapng -i <interface>

See dumpcap(1) Manual Page for all options for a ring buffer.

edit flag offensive delete link more

Comments

I did the following test with my TLS stream which start with a TLS handshake and then a lot of encrypted data. I create a "gap" in the middle of this TLS stream removing some encrypted data. (the handshake is still available in the stream). Wireshark is able to decrypt everything even the encrypted data following the "gap"..

Wireshark_C gravatar imageWireshark_C ( 2025-02-26 13:18:43 +0000 )edit

The application data can be considered two independent streams. For example when removing data from server to client, then the stream from client to server will indeed be decrypted completely but the server to client data should be truncated.

That is exactly what I get when creating a gap by filtering out some frames C>S and exporting that to a new file with the option “Include depended upon packets” disabled.

Can you share a sample pcap so we can take a look in more detail?

André gravatar imageAndré ( 2025-02-26 15:27:24 +0000 )edit

Ok, my use case is on DTLS (UDP), it's a client which sent periodically data to a server (without any response from server).

Anyway, your first response answer to my initial question:
-> If we have a DTLS1.2 pcap without the handshake stream but only with the stream of some encrypted applicative data, there is no way to decrypt it. (To fullfil this need (= decrypt without having access to handshake stream) theoretically Whireshark would need master secret, client random (=NSS key log) and also "server random", but there is no way to give the server random to wireshark.

The second question was : if we switch on DTLS1.3, does Wireshark will be able to decrypt application data without having access to handshake stream (and using TLS1.3 NSS key log (CLIENT_EARLY_TRAFFIC_SECRET, CLIENT_HANDSHAKE_TRAFFIC_SECRET, SERVER_HANDSHAKE_TRAFFIC_SECRET, CLIENT_TRAFFIC_SECRET_0, SERVER_TRAFFIC_SECRET_0, EXportER_SECRET) )

Wireshark_C gravatar imageWireshark_C ( 2025-02-26 16:14:41 +0000 )edit

Right, so DTLS instead of TLS. Then failure in TCP reassembly is not an issue and using a block cipher should work.

You could try to craft the needed handshake with the keys using text2pcap and prepend that to the capture.

André gravatar imageAndré ( 2025-02-26 18:01:46 +0000 )edit

And is it plan that wireshark will one day allow user to also import server_random ?

Having access to both: - NSS key log (CLIENT_RANDOM & SECRET) - SERVER_RANDOM will allow wireshak to decryp "application data" without needing the handshake stream in the pcap.

Wireshark_C gravatar imageWireshark_C ( 2025-02-28 08:10:10 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2025-02-13 14:01:25 +0000

Seen: 104 times

Last updated: Feb 24