On the topic of debugging, it's worth noting that TLS 1.3 is going to be quite a bit harder to debug from just network traces (without keying material) than TLS 1.2 was because more of the traffic is encrypted.
-Ekr On Tue, Apr 26, 2016 at 6:30 AM, Patrick McManus <mcma...@ducksong.com> wrote: > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
