I don't think the case for making this change (even to release builds) has been successfully made yet and the ability to debug and iterate on the quality of the application network stack is hurt by it.
The Key Log - in release builds - is part of the debugging strategy and is used fairly commonly in the network stack diagnostics. The first line of defense is dev tools, the second is NSPR logging, and the third is wireshark with a key log because sometimes what is logged is not what is really happening on the 'wire' (thus the need to troubleshoot). Bug reporters are often not developers and sometimes do not have the option of (or willingness to) running other builds. Removing functionality that helps with that is damaging to our strategic goal of building our Core and emphasizing quality. Bug 1188657 suggests that this functionality is for diagnosing tricky TLS bugs, but its just as helpful for diagnosing anything using TLS which we of course hope to make be everything. But of course if it represents a security hole then it is medicine that needs to be swallowed - I wouldn't argue against that. That's why I say the case hasn't been made yet. The mechanism requires machine level control to enable - the same level of control that can alter the firefox binary, or annotate the CA root key store or any number of other well understood things. Daniel suggests that Chrome will keep this functionality. The bug 1183318 handwaves around social engineering attacks against this - but of course that's the same vector for machine level control of those other attacks as well - I don't see anything really improved by making this change, but our usability and ability to iterate on quality are damaged. Maybe I'm mis understanding the attack this change ameliorates? Minimally we should be having this discussion about a change in functionality for Firefox 49 - not something that just moved up a release-train channel. Lastly, as a more strategic point I think reducing the tooling around HTTPS serves to dis-incentivize HTTPS. Obviously, we don't want to do that. Sometimes there are tradeoffs to be made, I'm skeptical of this one though. On Tue, Apr 26, 2016 at 12:44 AM, Martin Thomson <m...@mozilla.com> wrote: > In NSS, we have landed bug 1183318 [1], which I expect will be part of > Firefox 48. > > This disables the use of the SSLKEYLOGFILE environment variable in > optimized builds of NSS. That means all released Firefox channels > won't have this feature as it rides the trains. > > This feature is sometimes used to extract TLS keys for decrypting > Wireshark traces [2]. The landing of this bug means that it will no > longer be possible to log all your secret keys unless you have a debug > build. > > This is a fairly specialized thing to want to do, and weighing > benefits against risks in this case is an exercise in comparing very > small numbers, which is hard. I realize that this is very helpful for > a select few people, but we decided to take the safe option in the > absence of other information. > > (I almost forgot to send this, but then [3] reminded me in a very > timely fashion.) > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1183318 > [2] > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format > [3] > https://lists.mozilla.org/pipermail/dev-platform/2016-April/014573.html > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
