Re: Intent to (sort of) unship SSLKEYLOGFILE logging

[Eric Rescorla]

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

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

[Adam Roach]

I think we need to have reasonable answers to Patrick's questions before 
landing this patch. It's clear what we're losing, but unclear what we're 
gaining.


/a

On 4/26/16 08:30, Patrick McManus 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  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



--
Adam Roach
Principal Platform Engineer
Office of the CTO
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

[Patrick Meenan]

+1 to Patrick's points.  With HTTP/2 still in it's early stages a lot of CDN's 
and server dev's use the keylogs to help debug their integrations.  I know 
several of them have been using the keylogs that WebPageTest automatically 
pulls when it captures a tcpdump during testing.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

[Gian-Carlo Pascutto]

On 26-04-16 14:54, Richard Barnes wrote:
> I guess there's some marginal security in turning off this capability
> in release browsers (though I have difficulty precisely articulating
> the threat model where it makes sense).

Chrome's position on this is relevant to that statement:
https://twitter.com/sleevi_/status/723451779317256194

-- 
GCP
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

[Patrick McManus]

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

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

[Daniel Stenberg]

On Tue, 26 Apr 2016, Martin Thomson wrote:

Maybe I'm unusual, but I just run debug builds when I want to investigate 
this sort of thing.


That's easy for you and for all of us suitably involved and technically aware. 
When ordinary users run into trouble and we ask them to wireshark their 
traffic as part of tracking down a problem, removing this feature will raise 
the bar substanially for them.


I can see the reasoning for this action, but I can also see how it will make 
our network debugging lives harder.


--

 / daniel.haxx.se
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

[Richard Barnes]

Keeping it in Nightly / Developer Edition seems like about the right
compromise to me.  I guess there's some marginal security in turning off
this capability in release browsers (though I have difficulty precisely
articulating the threat model where it makes sense).  But if we're going to
disable it at all, we should keep it around for developer-focused builds.

--Richard

On Tue, Apr 26, 2016 at 5:44 AM, Martin Thomson  wrote:

> On Tue, Apr 26, 2016 at 6:08 PM, Jonas Sicking  wrote:
> > Limiting this to aurora builds might make the most sense here since
> > that's what we're pushing as the build that developers should use.
>
> I'm OK with that; that's why I asked here.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1188657
> ___
> 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

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

[Martin Thomson]

On Tue, Apr 26, 2016 at 6:08 PM, Jonas Sicking  wrote:
> Limiting this to aurora builds might make the most sense here since
> that's what we're pushing as the build that developers should use.

I'm OK with that; that's why I asked here.

https://bugzilla.mozilla.org/show_bug.cgi?id=1188657
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

[Jonas Sicking]

On Mon, Apr 25, 2016 at 11:17 PM, Martin Thomson  wrote:
> On Tue, Apr 26, 2016 at 4:10 PM, Xidorn Quan  wrote:
>> Could we probably restrict it to non-release builds (aurora and nightly)
>> rather than restrict them to debug builds only? Debug builds are harder to
>> get, and are slow.
>
> That was suggested, but we decided against it in bug 1188657.  I think
> that we'd be happy to land a patch that restored this if there was
> enough demand.  Maybe I'm unusual, but I just run debug builds when I
> want to investigate this sort of thing.

I don't think that we should expect web developers to ever run debug
builds. I've never heard of one that does.

Not even addon developers run debug builds from my understanding. I've
been told multiple times that NS_ASSERTION and MOZ_ASSERT are useless
as tools for deprecating functions from addon developers since they
just don't see them.

Limiting this to aurora builds might make the most sense here since
that's what we're pushing as the build that developers should use.

/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

[Xidorn Quan]

On Tue, Apr 26, 2016 at 2:56 PM, Mike Hommey  wrote:

> On Tue, Apr 26, 2016 at 02:27:31PM +0800, Xidorn Quan wrote:
> > On Tue, Apr 26, 2016 at 2:17 PM, Martin Thomson  wrote:
> >
> > > On Tue, Apr 26, 2016 at 4:10 PM, Xidorn Quan 
> > > wrote:
> > > > Could we probably restrict it to non-release builds (aurora and
> nightly)
> > > > rather than restrict them to debug builds only? Debug builds are
> harder
> > > to
> > > > get, and are slow.
> > >
> > > That was suggested, but we decided against it in bug 1188657.  I think
> > > that we'd be happy to land a patch that restored this if there was
> > > enough demand.  Maybe I'm unusual, but I just run debug builds when I
> > > want to investigate this sort of thing.
> > >
> >
> > I don't think anyone other than browser developers would be willing to
> > build browser themselves. I myself don't even usually build the browser
> in
> > my personal laptop, and I certainly won't build it just for analysing the
> > traffic...
>
> Very few developers will need to analyze traffic at a level requiring
> SSLKEYLOGFILE. In most cases, you get well enough in Firefox's builtin
> developer tools. And even if that's not enough, you can get NSS from a
> debug build, stick it into a non debug build, and use SSLKEYLOGFILE.
> (presumably, one only needs libssl3.so/libssl3.dylib/ssl3.dll)
>

Probably not so many developers need to analyze traffic frequently, but
people may occasionally want to use it, e.g., to learn how browser works in
some cases.

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

[Daniel Stenberg]

On Tue, 26 Apr 2016, Mike Hommey wrote:


Very few developers will need to analyze traffic at a level requiring
SSLKEYLOGFILE.


Yes, but a larger share of users will do a network capture and submit to 
Firefox developers on request when we debug network oriented problems. It is 
almost standard practise and with a world going more and more HTTPS and don't 
see the need reducued going forward.


Additionally, our friends in Chrome land say they are keeping SSLKEYLOGFILE 
support.


--

 / daniel.haxx.se
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

[Mike Hommey]

On Tue, Apr 26, 2016 at 02:27:31PM +0800, Xidorn Quan wrote:
> On Tue, Apr 26, 2016 at 2:17 PM, Martin Thomson  wrote:
> 
> > On Tue, Apr 26, 2016 at 4:10 PM, Xidorn Quan 
> > wrote:
> > > Could we probably restrict it to non-release builds (aurora and nightly)
> > > rather than restrict them to debug builds only? Debug builds are harder
> > to
> > > get, and are slow.
> >
> > That was suggested, but we decided against it in bug 1188657.  I think
> > that we'd be happy to land a patch that restored this if there was
> > enough demand.  Maybe I'm unusual, but I just run debug builds when I
> > want to investigate this sort of thing.
> >
> 
> I don't think anyone other than browser developers would be willing to
> build browser themselves. I myself don't even usually build the browser in
> my personal laptop, and I certainly won't build it just for analysing the
> traffic...

Very few developers will need to analyze traffic at a level requiring
SSLKEYLOGFILE. In most cases, you get well enough in Firefox's builtin
developer tools. And even if that's not enough, you can get NSS from a
debug build, stick it into a non debug build, and use SSLKEYLOGFILE.
(presumably, one only needs libssl3.so/libssl3.dylib/ssl3.dll)

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

[Martin Thomson]

On Tue, Apr 26, 2016 at 4:10 PM, Xidorn Quan  wrote:
> Could we probably restrict it to non-release builds (aurora and nightly)
> rather than restrict them to debug builds only? Debug builds are harder to
> get, and are slow.

That was suggested, but we decided against it in bug 1188657.  I think
that we'd be happy to land a patch that restored this if there was
enough demand.  Maybe I'm unusual, but I just run debug builds when I
want to investigate this sort of thing.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform