If someone only has access to a packet capture, and no other key material, then they will obviously be able to see unencrypted data such as the server name (SNI) and the server certificate in TLS 1.2, but not the encrypted data. TLS is designed to prevent third parties from tampering with the session and to prevent replay attacks.
The file generated by the SSLKEYLOGFILE environment variable typically stores per-session secrets and is written by an endpoint (client or server). Its format is documented at https://developer.mozilla.org/NSS_Key_Log_Format
For TLS 1.3, the logged secrets will only be usable for that particular session. These secrets cannot be used to decrypt any other session. That includes previous sessions, future sessions, and sessions with other clients or servers. The reason is that the secrets are derived from the full handshake messages transcript. Any change in the handshake (for example, different Client Random or a different Server Name) will result in a different secret.
For TLS 1.2 and earlier, the situation is almost the same. However, there are two exceptions that break the security of future sessions.
- If the parties agree to use the RSA key exchange, the session won't be forward secret. This means that if the server private RSA key matching the certificate is compromised, then the holder of that private key will be able to decrypt all previous and future sessions based on the same server key. This does not apply if both parties use a forward secret cipher suite based on the Diffie-Hellman key exchange. The latter sessions will still be secure even if the RSA private key is leaked.
- In TLS 1.2, the master secret is linked to a session. Session resumption is a mechanism where a client can attempt to reuse the master key from an earlier session. It does so by sending an identifier (Session ID or Session Ticket) to the server. If the server recognizes this, it will skip the full handshake and complete an abbreviated handshake without performing a new key exchange. The new connection will not be secure as the requirement to keep the master secret private has been violated.
The second issue is subtle, but very important. It has been solved in TLS 1.3 where every session always includes a full key exchange, thereby making the "resumption secret" independent of the actual secrets that will be used for encryption of the handshake and application data.
An example illustrating the TLS 1.2 session resumption issue:
- You start a Wireshark capture and open Firefox with the SSLKEYLOGFILE environment variable set.
- You visit a website, for example your email or a webshop.
- At some point you are happy with the captured packet trace and stop the Wireshark capture. You make a copy of it, together with the SSLKEYLOGFILE file contents.
- You decide to close the website tab, but without quitting Firefox. This will typically terminate the network connection.
- Looking at the website was boring and as you got inspired, you reopen the website. This creates a new connection.
- You log in to the website, send an email or buy something.
- Finally you share the original capture and keys.
The problem here is that step 5 could end up using TLS 1.2 session resumption. An passive attacker (MitM) who sees your network traffic (for example, in a public Wi-Fi network in a coffee shop) will be able to use the secrets from step 7 to decrypt your activity in step 6. They could potentially learn your password, and do terrible things with it.
Moral of the story: yes, it is safe to share the packet capture with the SSLKEYLOGFILE, but be sure that it only includes keys for sessions you do not care about. If you want to create a trace for sharing, use a virtual machine, or use a separate browsing profile. An example of the latter can be found in slide 8 of my slides on performing TLS decryption with Wireshark:
If you want cannot start a new browsing profile, you could at least try to clear your cache. This should ensure that the next new connection uses fresh keys.
Although you mentioned it in your question, I'll repeat it once more for completeness: the decrypted trace may reveal cookies, URLs, pictures, web page contents and any other details that you shared during the capture session. Even if you stop your local capture, someone else might be eavesdropping and capture everything in the existing connection. Once you publish the secrets, they can decrypt everything in that connection.