908046 - Turn off SSLKEYLOGFILE logging as default

Status: NEW

(Core :: Security, defect)

Description

[David Dahl :ddahl]

Seems like this behavior: https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslsock.c#2872

 ... should not be on by default in release builds?

See: https://isc.sans.edu/forums/diary/Psst+Your+Browser+Knows+All+Your+Secrets+/16415

Maybe it does not matter, just seems like something that should be deactivated by default.

Comment 1

[Stefan Baebler]

(In reply to David Dahl :ddahl from comment #0)
> deactivated by default.
Currently it is not "active" by default per se. Attacker must plant a SSLKEYLOGFILE environment variable to activate logging on the target machine AND be able to read that log file. If he already gained so much access, what is to stop him from tweaking some boolean setting in about:config or even installing a special Firefox build? Those are just (minor?) extra hurdles.

See also bug 536474, bug 762763, bug 770313 and http://www.imperialviolet.org/2012/06/25/wireshark.html

Comment 2

[David Dahl :ddahl]

(In reply to Stefan Baebler from comment #1)
> (In reply to David Dahl :ddahl from comment #0)
> > deactivated by default.
> Currently it is not "active" by default per se.

Sure, but I can imagine a rouge toolbar - that are so many many times installed without a user understanding how it got installed - sets the env var, etc... Not a high hurdle to jump.

Comment 3

[Stefan Baebler]

(In reply to David Dahl :ddahl from comment #2)
> Sure, but I can imagine a rouge toolbar - that are so many many times
> installed without a user understanding how it got installed - sets the env
> var, etc... Not a high hurdle to jump.
Yes, extra hurdle (not having it included in default release builds at all) would help a bit with the defense in depth.

Whoever legitimately requires such SSL debugging functionality can install browser compiled with DEBUG and TRACE precompile directives defined, as it was prior to NSS 3.14 (https://developer.mozilla.org/en-US/docs/NSS_Key_Log_Format )

Comment 4

[Mathew Hodson]

See also bug 1183318 where NSS disabled SSLKEYLOGFILE by default in optimized builds of the library.

In bug 1188657, Firefox started overriding the default so that SSLKEYLOGFILE could still be used in all Firefox builds from Mozilla.

Comment 5

[Richard Michael]

Please do not disable the availability of SSLKEYLOGFILE.

HTTP2 is de facto TLS-only, so without being able to decrypt browser / server traffic (e.g., with Wireshark) it is difficult to do web development. For example, debugging on-wire data, learning HTTP2, etc. I just used SSLKEYLOGFILE, because I needed to verify headers were indeed lowercase on the wire, as they are not shown lowercase in Firefox Devtools.

If anything, it would be very helpful if Firefox was able to log the session keys for specific URLs only. Otherwise, the key log file grows quickly when session keys are logged for all open tabs, requests, etc. I do agree this is arguably somewhat insecure, as well -- care must be taken not to use Firefox for any sensitive activity other than development debugging while SSLKEYLOGFILE is in the environment. Exposing a toggle for this in devtools would be ideal, because starting and stopping Firefox to change the environment is a moderately annoying hurdle when doing web dev.

I could see disabling SSLKEYLOGFILE in release builds, but leaving it enabled in developer and nightly builds (ideally with a toggle as I mentioned above). Although, disabling it in even release builds would make it difficult to reproduce and debug bugs using the specific version of Firefox in use by a bug reporter (users, customers, etc.), which is likely to be a release version.

Comment 6

[Virgo]

Hello, please leave SSLKEYLOGFILE enabled even in stable version of firefox.
It's important to investigate potential spyware injected in firefox.
I use openbsd74 and firefox 128.1 and I have suspected traffic that I need to analyze.
So please leave it enabled.

Comment 7

[Daniel Veditz [:dveditz]]

superseded by bug 1188657, which originally asked for more or less what this bug did but then got reversed.

Comment 8

[Daniel Veditz [:dveditz]]

Filed enhancement bug 1915224 as a substitute that is more likely to be accepted.