Potential risks of publicly uploading a Wireshark trace with TLS-related information?

Question

Say I were to upload a Wireshark trace to a website that was publicly available. Say, with it, the SSL key log, certificate information, etc were available. If someone had the link to the trace, what dangers would there be?

Obviously, the content and information of the given trace session is visible to everyone, what about a past or future session that occurred? What about sessions that occurred with other clients or other servers? Could I be in danger of something like a Replay Attack or a Man-in-the-Middle attack?

Answer 1

If the wireshark trace was made from the perspective of a passive eavesdropper, then there is nothing in the trace that could be used to tamper with future SSL/TLS connections.

Keep in mind that there are many entities that are in a position to make the same trace that you made, including wireless hotspot operators, ISPs, backbone carriers, data centers, etc. If it were possible to tamper with future SSL/TLS connections using the trace that you made, then any of these entities could do the same thing. SSL/TLS was designed specifically to be resistant to this type of tampering.

Even if you run the trace at the client, and log session information to the SSLKEYLOGFILE, the information in this file will not be useful for tampering with future SSL/TLS connections, as this file contains only ephemeral keys and session keys used only for the session when the trace was made.

Answer 2

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.

1. 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.
2. 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:

1. You start a Wireshark capture and open Firefox with the SSLKEYLOGFILE environment variable set.
2. You visit a website, for example your email or a webshop.
3. 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.
4. You decide to close the website tab, but without quitting Firefox. This will typically terminate the network connection.
5. Looking at the website was boring and as you got inspired, you reopen the website. This creates a new connection.
6. You log in to the website, send an email or buy something.
7. 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: https://lekensteyn.nl/files/wireshark-tls-debugging-sharkfest19eu.pdf

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.