Decrypting TLS Browser Traffic with Wireshark

Re:Decrypting TLS Browser Traffic with Wireshark by Animats on Friday February 13, 2015 @01:44AM (#9043217)

That article seems to be a rewrite of this 2012 article: http://www.root9.net/2012/11/ssl-decryption-with-wireshark-p...

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.

[ Parent | on HN ]

Re:Decrypting TLS Browser Traffic with Wireshark by scintill76 on Friday February 13, 2015 @03:55AM (#9043477)

This does seem, at the least, irresponsible of the browser vendors. I'll be especially angry if Chrome doesn't have very prominent warnings, considering they harass some developers and power users with a warning about an "insecure" configuration Google basically forced them to use.[0] By analogy, I expect nothing less than a blinking red warning covering the entire browser window whenever keys are being logged because of an environment variable.

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

[ Parent | on HN ]

Re:Decrypting TLS Browser Traffic with Wireshark by reubenmorais on Friday February 13, 2015 @05:57AM (#9043745)

Chrome uses NSS, so the GP applies exactly to it: https://code.google.com/p/chromium/codesearch#chromium/src/n...

[ Parent | on HN ]

Re:Decrypting TLS Browser Traffic with Wireshark by Animats on Saturday February 14, 2015 @04:12PM (#9050804)

Some of those environment-variable "features" were workaround for problems in the past. Many of those could probably be removed outright. All of them should be removed from non-debug builds.

[ Parent | on HN ]

Re:Decrypting TLS Browser Traffic with Wireshark by nodata on Friday February 13, 2015 @04:02AM (#9043498)

Why are you calling this a backdoor?

[ Parent | on HN ]

Re:Decrypting TLS Browser Traffic with Wireshark by weland on Friday February 13, 2015 @04:30AM (#9043563)

It could be named "A rather unfortunate architectural decision that can make browsers write keys in plaintext without users explicitly enabling it" but that would be a little verbose. A malicious program can add a SSLKEYLOGFILE environment variable (if it's not systemwide, it doesn't need root privileges for that).

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?

[ Parent | on HN ]

Re:Decrypting TLS Browser Traffic with Wireshark by nodata on Friday February 13, 2015 @04:41AM (#9043586)

If the attacker can add an environment variable, they can add a command-line switch or about:config value or modify my firefox binary or install an addon that saves my password fields.

[ Parent | on HN ]

Re:Decrypting TLS Browser Traffic with Wireshark by vidarh on Friday February 13, 2015 @07:41AM (#9044011)

If I carelessly execute ~/Downloads/some-binary, my environment variables and config settings are now suspect , while overwriting my firefox binary requires root access.

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

[ Parent | on HN ]

Re:Decrypting TLS Browser Traffic with Wireshark by Animats on Friday February 13, 2015 @02:52PM (#9046779)

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".

[ Parent | on HN ]

Re:Decrypting TLS Browser Traffic with Wireshark by nodata on Monday February 16, 2015 @04:44AM (#9056030)

But poisoning your Firefox binary does not require root access. Just preload what you want.

[ Parent | on HN ]

Re:Decrypting TLS Browser Traffic with Wireshark by teddyh on Friday February 13, 2015 @06:36AM (#9043830)

While technically true, that did not prevent Shellshock from being a big deal.

[ Parent | on HN ]

Re:Decrypting TLS Browser Traffic with Wireshark by bodyfour on Friday February 13, 2015 @06:51AM (#9043876)

Shellshock was a big deal because the attacker only needed to control the value of an environment variable, not its name. There are many vectors to provide a string that will end up stored in some environment variable, far fewer that will allow you to specify a particular name/value pair.

[ Parent | on HN ]