In studying SSL / TLS handshakes and encryption, I found a method that describes how to export the SSL / TLS session keys from Firefox to an user or environmental variable outside the browser, and then decrypt the TLS packets using Wireshark (method described at: https://isc.sans.edu/forums/diary/Psst+Your+Browser+Knows+All+Your+Secrets/16415 ). This method is very easy to do – I was able to decrypt communications with HTTPS sites, including login credentials.

Per the link above and my own testing, this method only works for Firefox and Chrome; not Internet Explorer or other non-browser SSL traffic (see https://msdn.microsoft.com/en-us/library/windows/desktop/aa387409%28v=vs.85%29.aspx for MSDN recommendation, but they essentially do not save the session keys in the clear by default). The method is also described on the Mozilla Development Network (MDN) site at: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format and also Information Security Exchange, for example at: Decrypting TLS in Wireshark when using DHE_RSA ciphersuites ).

The method does require access to the system settings to configure the necessary environment variable, but that is all. Both Firefox and Chrome look for the variable automatically, and if they find it, start logging keys to the location. The browsers do not alert the user or ask for permission, nor does there seem to be a way in Firefox’s about:config to turn this logging off. I realize that full access to the system to set up the variable could presume that the system is already compromised, but the level of protection seems much less than other security information. For example, system access does not allow easy access to the SAM or TPM security modules (there are other ways to get access of course, but it is not a point and click).

This method would seem to allow a very stealthy export of the SSL / TLS session keys (they are only 128 or 256 bits each) by third parties who could capture the network traffic separately from the key export and then decrypt at their leisure. This decryption could occur in spite of the use of any "perfect forward secrecy" asymmetric keys, and could reconstruct browsing sessions long after the fact. Any other program with access to your Windows folder structure could also ex filtrate the keys, and you would never know.

Why do Firefox and Chrome allow such easy leaking of these session keys? I read some speculation that this was a debugging feature, but why is it left on by default? Note that other browsers do not leak the session keys. Should I be concerned about this?

  • 1
    I'm not really clear on why you think this should be "hard". Developers often need access to what's going on on the wire. This is what this is for. I'd ask you why you think it should be more difficult, and how you're simultaneously let developers serve a need, and also make it hard to do. There's no separating the "good" developers from the "bad" developers in making this easy/hard, so why not make it built in? Commented Dec 4, 2015 at 21:59
  • 5
    That would give a false sense of security. Turning it off doesn't protect you from an attacker who compiles a customer version that turning it off does nothing. That's incredibly trivial. If you lose control of your environment it's game over. Commented Dec 5, 2015 at 1:10
  • 3
    @stevensether, I think being able to run an application with an environment variable set is easier than installing a modified app. One requires user permissions and the other UAW/root permissions. Commented Dec 5, 2015 at 1:17
  • 1
    @StoneTrue If an attacker can gain privileges as you, it's largely game over at that point and the additional powers of UAC/root don't gain an attacker a huge amount of power. On Windows a user can change the shortcuts to run whatever program they want. Attackers can copy custom versions of a program to a user-writable area, and execute there. Installing a plugin to the browser doesn't require root/uac privs. There's a TON of ways to get the exact same result without requiring root/admin perrmissions. Commented Jan 12, 2016 at 21:45
  • 1
    This is not a security issue. As @SteveSether says, if you own your box, you own your box. It isn't about whether it may or may not be trivially harder to exploit one method or another, there's no security boundary there, so no one is going to bother worrying about it. You make security decisions on the boundaries, not arbitrarily.
    – Xander
    Commented Jan 13, 2016 at 2:15

3 Answers 3


Why do Firefox and Chrome allow such easy leaking of these session keys?

To make it easier for developers to analyze their network captures. The first time I used this feature was when trying to understand what protocol is exactly used by the web-based noVNC. Using this functionality, I was able to decrypt the traffic in Wireshark.

I read some speculation that this was a debugging feature, but why is it left on by default? Note that other browsers do not leak the session keys.

By default no keys are logged / leaked. The feature exists for those who need it (see above).

Should I be concerned about this?

No. If someone is able to modify your system environment, you have larger issues. Not convinced? Did you know that Chrome has a --disable-web-security command line option? That disables protections such as the Same Origin Policy, allowing any website to modify your bank's website for example. What about the ability to install browser extensions which can listen to all of your HTTP requests and modify them without generating certificate errors?

Do not worry about this SSLKEYLOGFILE feature, it won't affect you and it is more likely that a browser extension will steal all your data or that someone will install a malicious certificate, perform a man-in-the-middle attack and inject advertisements.

  • 2
    I think one could make an argument for making the current-value of this setting obvious in the UI somehow. For example, if SSLKEYLOGFILE is set, put something in the browser UI near the lock-icon to make it clear that the TLS session keys are being logged to the disk. No developer is going to flip-out if that's visible, and it may even remind them that it has been enabled and needs to be disabled after use. It would also notice a hapless user that they are (potentially) being surveiled by someone with control of their machine (like a local sysadmin, hacker, etc.). Commented Jan 3, 2020 at 20:13
  • It bears mentioning that aside from developer debugging, some AntiVirus and -Malware software is using this to be able to inspect traffic for encrypted threats 'in-flight' that would be undetectable, before they're in browser memory or on your disk, otherwise (they just bypass firewall and NIDS). Which is preferrable to an MITM proxy, that can weaken security as you have to trust the Proxy TLS and lose information about the original connection's encryption.
    – nyov
    Commented Feb 23, 2020 at 19:52

I think the answer to this questions can only be: If you want to turn it off, try to get involved with the developers, or compile your own version and remove the option there.

Suggestion: Turning on private mode on the browser should disable this feature. Consider filing this on the bugtracker ;)

Regarding TLS/SSL safety: Remember, TLS means transport level security, SSL means secure sockets layer. Both just deal with the encrypted transport of data. What happens in the endpoint cannot be protected that way. If you do not have full control over your PC (company device, internet cafe etc) you should always consider the possibility of such a local data leak. Data needs to be decrypted inside the device to make it readable to you, and that always will be a weak point. Imagine the SSL certificate injection where all https traffic can be decrypted at your company´s firewall by simply adding a full trusted proxy certificate in your PC, and you would not even notice it.

So even if it sounds like a bad idea to make logging that easy, to me it is not a violation of the security mechanism behind.

  • Private mode does not disable the feature, but I agree that it should. Also, even within the PC, there are levels of security.
    – Stone True
    Commented Dec 8, 2015 at 15:54

Firefox and Chrome allow logging of the key materials to enable wireline debugging facilities.

  • 1
    But it seems to be a security issue. To draw a comparison, Microsoft could allow easy access to password hashes to enable debugging, yet hashes seem more difficult to access than cryto keys in Firefox and Chrome.
    – Stone True
    Commented Dec 7, 2015 at 20:13
  • 1
    True. But that's expanding your question scope very substantially. The facility was created for debugging and is on by default. The major defense is not allowing arbitrary changes to the environment variables supplied to your browsers on launch. I'm on the side of saying these features should have to be explicitly enabled and should not be on by default. Commented Dec 7, 2015 at 20:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .