To make life easier for the recipients of your capture file with secrets file, you can also merge both files together: embedding the secrets into the pcapng file. They can then use it like explained in part 2. This file can now be shared (together with the capture file) with third parties, without revealing the web server’s private key. The content of the file that was created (tls.keys) looks very similar to the SSLKEYLOGFILE we generated in part 2:Ī small difference here, is that the RSA secret includes the master key in stead of the pre-master key. Such a file with secrets can be generated by Wireshark, when you have the capture file open together with the server’s private key file. Because those keys only apply to that particular TLS stream, they are useless for other TLS streams. If you would have the necessary secrets in a SSLKEYLOGFILE, you would be able to share that.

I’m sure you don’t want to share the web server’s private key with a vendor (remember, in part 1, we used a web server’s private key to decrypt a TLS stream, while in part 2 we used a client’s SSLKEYLOGFILE). Or you are troubleshooting an issue, and need need to share the decrypted TLS stream with a vendor. You did a forensic investigation, and you need to included the decrypted TLS stream in your findings. Say that you have to share a decrypted TLS stream, like the stream we decrypted in part 1.

Wireshark pcapng