A SSLKEYLOGFILE environment variable makes Firefox and Google Chrome silently log their crypto keys as plaintext. What could possibly go wrong?

This 2014 discussion (https://groups.google.com/forum/#!topic/mozilla.dev.tech.cry...) says that originally the documentation for this feature said that it was only turned on in debug builds of Firefox. Then, somehow, it was quietly turned on for all builds, with no notification.

Take a look at the code in Firefox for this:

https://hg.mozilla.org/projects/nss/file/65605e800fd1/lib/ss...

Firefox understands several suspicious environment variables: SSLBYPASS, SSLKEYLOGFILE, NSS_SSL_REQUIRE_SAFE_NEGOTIATION, NSS_SSL_ENABLE_RENEGOTIATION, and NSS_SSL_CBC_RANDOM_IV, all of which have security implications. Some were put in for some Thunderbird problem involving Microsoft mail servers, but the common library may enable them in Firefox as well. That whole section of code should be present only debug builds, if at all.

It's funny how backdoors like this keep creeping into mainstream software, isn't it. Look at the code histories and see who put in those changes.

I also don't think readers should be encouraged so readily to put this into the persistent global environment.

[0] https://code.google.com/p/chromium/issues/detail?id=337734

I guess we can haggle over whether or not this meets the "definition" of a backdoor. "Can give unrestricted access to encryption keys" is backdoor in my book, but I'm not a fan of taxonomy, the retarded child of sciences :).

I can understand why this... um, this feature, would be useful in developer builds. Why it's present in anything that is shipped to users is beyond my ability to comprehend. It should be behind an ENABLE_DANGEROUS_PLAINTEXT_LOGGING switch that is off by default. What's the thought process by which someone decides giving this to users is a good idea? Is there something I'm missing here?

As such, having the browser loudly warn (irrespective of settings) about such unsafe defaults is still vastly better.

Yes. Loudly. As in "surrounds entire window with a red frame with INSECURE TEST MODE ENABLED", not as in "pops up notification that quietly fades out".

- .bashrc is run every time the shell is started (eg, subshells, su without -l or -)

- .bash_profile is run only when a 'log in' shell is started, eg, a tty, su -l, su-, new tab, etc.

Another technique that often, sadly, works is the old school man-in-the-middle.

I was recently looking at the api of an app on my phone, using ettercap to arp poison my phone and capture traffic on my laptop. Found the api call was over https (fwd secrecy and all looking good), I tried ssl-mitm with a fake cert... no errors in the app, clear text on my laptop. Happy and sad at the same time. :/

Was the fake cert trusted by your phone? If affirmative, did you manually add the root cert from your fake CA or at least accepted that cert as trusted?

If you didn't explicitly trust that cert and the application didn't complain we're in front of another completely wrong use of SSL.

The issue is not the network, but the way the app continued over an insecure connection.

(Or, to the news that the NSA/GHCQ/ASIO/et al. have been actively doing this for years already...)

In that case you can add its key to a trusted authorities in Firefox and then it swaps nothing, everything seems to be signed properly... Unless I misunderstood your comment.

The substituted public key allows the proxy to negotiate a TLS session between the browser and the proxy, impersonating the real server.

You avoid a certificate error if you install the signing CA certificate in the browser; but you still tamper with the traffic. There are scenarios where mitm doesn't work; for example Client Authenticated TLS. Things like certificate pinning, where the browser expects a specific public key, also break intetception.

I had to verify how two services (not web browsers) were communicating the other day and this was the easiest solution for me.