Success on x86_64-linux (full log)

Attempted: nss

/nix/store/ail05likjg5m2qws9rvjd3qpkqxi6l7a-nss-3.38

Success on aarch64-linux (full log)

Attempted: nss

these paths will be fetched (1.13 MiB download, 4.48 MiB unpacked):
  /nix/store/5wq31rcya980b059ria4kdwm09qdy5wa-nss-3.38
copying path '/nix/store/5wq31rcya980b059ria4kdwm09qdy5wa-nss-3.38' from 'https://cache.nixos.org'...
/nix/store/5wq31rcya980b059ria4kdwm09qdy5wa-nss-3.38

What's the benefit of this? Sounds like enabling a potential security risk to me.

@xeji @fpletz It would allow for users to capture their own SSL/TLS encrypted traffic with tools like Wireshark.

I personally wanted to check how a website was getting its updates, so I opened up Firefox's element inspector (tab Network). The updates weren't showing up in there, so I was looking for a way to allow Wireshark traffic capture through SSL. Most of the suggestions were "Oh, just set this env variable, and you'll be able to decrypt the traffic". I tried this, and it didn't work. It wasn't immediately clear why, until I stumbled upon the link mentioned in the PR. I assumed that what was the case for Debian would also be the case for NixOS.

On the security risk side: there is a potential attack, but to exploit it, an attacker has to be able to:

• Set arbitrary enviornment variables
• Read a file the firefox process can write
• Intercept traffic

It's possible, but if those conditions are met, you are already screwed I'd say. Furthermore, the official Firefox binaries also include this option.

If this is still not wanted, I also see another course of action: give a warning when starting Firefox with the SSLKEYLOGFILE variable set, and have another Firefox package (nixpkgs.firefoxSslKeyLog) that has this option enabled.

P.S. Good question though, glad it is asked rather than blindly merged.

Thanks for explaining.

I don't think we should enable this feature by default. It does increase the attack surface. I agree it's not a straightforward attack, but this might for instance be used by an attacker who has short-term access to your computer to intercept traffic later...

For debugging TLS connections there are better options like installing a man-in-the middle proxy (like mitmproxy): it must only be installed when you really use it, plus it's generic and doesn't require modifying/rebuilding applications.

I assumed that what was the case for Debian would also be the case for NixOS.

Not necessarily. Each distro makes their own tradeoffs. Arch, for instance, does not enable this.

That said, I'm fine with adding the option but not with enabling it for firefox by default. A user who really wants it should then override firefox locally.

have another Firefox package (nixpkgs.firefoxSslKeyLog) that has this option enabled.

Definitely not. Since there are good alternatives for debugging, this feature isn't important enough to duplicate firefox.

That said, I'm fine with adding the option but not with enabling it for firefox by default. A user who really wants it should then override firefox locally.

I'm really not a fan of having users override Firefox locally, since it takes forever to build.

I understand. But we also struggle with firefox build timeouts on Hydra, so adding another firefox build doesn't sound great either.

@xeji I don't think having this environment variable is more dangerous then allowing LD_PRELOAD or some environment variable that alters the ca bundle where an attacker can do the same shenanigans.

@Mic92 I agree, but the fact that other attacks are possible shouldn't stop us from minimizing the attack surface. This basically adds an easily accessible backdoor to NSS, which I don't think is a necessary feature since there are good alternatives for debugging TLS connections.

So the alternative to this pull request would be documentation how nss can be overriden in combination with LD_LIBRARY_PATH to inject it into firefox.

Any updates on this pull request, please?

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.