SSLKEYLOGFILE always enabled

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

SSLKEYLOGFILE always enabled

Роман Донченко
Hello,

<https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format>  
states that:

"Obviously this is only a debugging measure and is only enabled if NSS is  
built with DEBUG and TRACE defined."

Analogously,  
<https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Reference/NSS_environment_variables>  
says:

"SSLKEYLOGFILE: [...] Note: The code must be built with TRACE defined to  
use this functionality."

However, the actual responsible code  
(<https://hg.mozilla.org/projects/nss/file/65605e800fd1/lib/ssl/sslsock.c#l2840>)  
doesn't seem to be protected by any compile-time conditions (except for  
NSS_HAVE_GETENV). And I've checked with a stock Ubuntu NSS package that  
SSLKEYLOGFILE works, even though SSLDEBUGFILE doesn't.

So who's in the wrong here? Is it a bug in the code, or in the  
documentation?

Roman.

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: SSLKEYLOGFILE always enabled

Patrick McManus-3
I looked into this once, and iirc the change was made intentionally and I
guess the documentation not updated. I just updated the wikis. Thanks.


On Sun, Jul 13, 2014 at 10:30 AM, Роман Донченко <[hidden email]> wrote:

> Hello,
>
> <https://developer.mozilla.org/en-US/docs/Mozilla/
> Projects/NSS/Key_Log_Format> states that:
>
> "Obviously this is only a debugging measure and is only enabled if NSS is
> built with DEBUG and TRACE defined."
>
> Analogously, <https://developer.mozilla.org/en-US/docs/Mozilla/
> Projects/NSS/Reference/NSS_environment_variables> says:
>
> "SSLKEYLOGFILE: [...] Note: The code must be built with TRACE defined to
> use this functionality."
>
> However, the actual responsible code (<https://hg.mozilla.org/
> projects/nss/file/65605e800fd1/lib/ssl/sslsock.c#l2840>) doesn't seem to
> be protected by any compile-time conditions (except for NSS_HAVE_GETENV).
> And I've checked with a stock Ubuntu NSS package that SSLKEYLOGFILE works,
> even though SSLDEBUGFILE doesn't.
>
> So who's in the wrong here? Is it a bug in the code, or in the
> documentation?
>
> Roman.
>
> --
> dev-tech-crypto mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: SSLKEYLOGFILE always enabled

Tom Ritter
Is having it in by default useful enough to outweigh the risk?

When the Dual_EC_DRBG news stories were blowing it, it was revealed
that you could switch to it by just changing the Windows Registry.
It's a Windows-supported backdoor - no malicious code needs to stay
running on your system - just flip that bit, and delete yourself.
After that, you're all set.

Similarly, having this feature provided by default seems like it
provides a very easy, supported way to extract sensitive key data to
the filesystem or some other covert channel - without invalidating
package signatures, hashes of libraries or binaries, etc.

Don't get me wrong, it's invaluable to be able to use it for
debugging, but I question to need to have it enabled by default...

-tom

On 13 July 2014 19:23, Patrick McManus <[hidden email]> wrote:

> I looked into this once, and iirc the change was made intentionally and I
> guess the documentation not updated. I just updated the wikis. Thanks.
>
>
> On Sun, Jul 13, 2014 at 10:30 AM, Роман Донченко <[hidden email]> wrote:
>
>> Hello,
>>
>> <https://developer.mozilla.org/en-US/docs/Mozilla/
>> Projects/NSS/Key_Log_Format> states that:
>>
>> "Obviously this is only a debugging measure and is only enabled if NSS is
>> built with DEBUG and TRACE defined."
>>
>> Analogously, <https://developer.mozilla.org/en-US/docs/Mozilla/
>> Projects/NSS/Reference/NSS_environment_variables> says:
>>
>> "SSLKEYLOGFILE: [...] Note: The code must be built with TRACE defined to
>> use this functionality."
>>
>> However, the actual responsible code (<https://hg.mozilla.org/
>> projects/nss/file/65605e800fd1/lib/ssl/sslsock.c#l2840>) doesn't seem to
>> be protected by any compile-time conditions (except for NSS_HAVE_GETENV).
>> And I've checked with a stock Ubuntu NSS package that SSLKEYLOGFILE works,
>> even though SSLDEBUGFILE doesn't.
>>
>> So who's in the wrong here? Is it a bug in the code, or in the
>> documentation?
>>
>> Roman.
>>
>> --
>> dev-tech-crypto mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-tech-crypto
>>
> --
> dev-tech-crypto mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-crypto
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: SSLKEYLOGFILE always enabled

Ryan Sleevi-5
On Tue, July 15, 2014 1:11 pm, Tom Ritter wrote:

>  Is having it in by default useful enough to outweigh the risk?
>
>  When the Dual_EC_DRBG news stories were blowing it, it was revealed
>  that you could switch to it by just changing the Windows Registry.
>  It's a Windows-supported backdoor - no malicious code needs to stay
>  running on your system - just flip that bit, and delete yourself.
>  After that, you're all set.
>
>  Similarly, having this feature provided by default seems like it
>  provides a very easy, supported way to extract sensitive key data to
>  the filesystem or some other covert channel - without invalidating
>  package signatures, hashes of libraries or binaries, etc.
>
>  Don't get me wrong, it's invaluable to be able to use it for
>  debugging, but I question to need to have it enabled by default...
>
>  -tom

Either you control your machine, or you do not. Either the OS provides
robust controls, or it does not.

If an attacker has physical access to your machine and can set this, or if
an attacker can control your operating environment such that the
environment variable is set, it's all over. This is no different than
malware hijacking your browser of choice and hooking the API calls - which
we do see for both Firefox and Chrome.

Now, we can talk about grades of attacks, and finer nuances, but for a
debug bit that has to be set client side, it really seems a no-op, and for
which common sense would suggest is not a reasonable threat model.

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: SSLKEYLOGFILE always enabled

Ryan Sleevi
In reply to this post by Tom Ritter
On Tue, July 15, 2014 1:11 pm, Tom Ritter wrote:

>  Is having it in by default useful enough to outweigh the risk?
>
>  When the Dual_EC_DRBG news stories were blowing it, it was revealed
>  that you could switch to it by just changing the Windows Registry.
>  It's a Windows-supported backdoor - no malicious code needs to stay
>  running on your system - just flip that bit, and delete yourself.
>  After that, you're all set.
>
>  Similarly, having this feature provided by default seems like it
>  provides a very easy, supported way to extract sensitive key data to
>  the filesystem or some other covert channel - without invalidating
>  package signatures, hashes of libraries or binaries, etc.
>
>  Don't get me wrong, it's invaluable to be able to use it for
>  debugging, but I question to need to have it enabled by default...
>
>  -tom

Either you control your machine, or you do not. Either the OS provides
robust controls, or it does not.

If an attacker has physical access to your machine and can set this, or if
an attacker can control your operating environment such that the
environment variable is set, it's all over. This is no different than
malware hijacking your browser of choice and hooking the API calls - which
we do see for both Firefox and Chrome.

Now, we can talk about grades of attacks, and finer nuances, but for a
debug bit that has to be set client side, it really seems a no-op, and for
which common sense would suggest is not a reasonable threat model.

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

RE: SSLKEYLOGFILE always enabled

Jonathan Schulze-Hewett
In reply to this post by Ryan Sleevi-5
Does having this enabled violate the FIPS 140 requirements on exposing key materials in the clear?

Sincerely,
Jonathan


-----Original Message-----
From: dev-tech-crypto [mailto:dev-tech-crypto-bounces+schulze-hewett=[hidden email]] On Behalf Of Ryan Sleevi
Sent: Tuesday, July 15, 2014 6:12 PM
To: mozilla's crypto code discussion list
Subject: Re: SSLKEYLOGFILE always enabled

On Tue, July 15, 2014 1:11 pm, Tom Ritter wrote:

>  Is having it in by default useful enough to outweigh the risk?
>
>  When the Dual_EC_DRBG news stories were blowing it, it was revealed
>  that you could switch to it by just changing the Windows Registry.
>  It's a Windows-supported backdoor - no malicious code needs to stay
>  running on your system - just flip that bit, and delete yourself.
>  After that, you're all set.
>
>  Similarly, having this feature provided by default seems like it
>  provides a very easy, supported way to extract sensitive key data to
>  the filesystem or some other covert channel - without invalidating
>  package signatures, hashes of libraries or binaries, etc.
>
>  Don't get me wrong, it's invaluable to be able to use it for
>  debugging, but I question to need to have it enabled by default...
>
>  -tom

Either you control your machine, or you do not. Either the OS provides
robust controls, or it does not.

If an attacker has physical access to your machine and can set this, or if
an attacker can control your operating environment such that the
environment variable is set, it's all over. This is no different than
malware hijacking your browser of choice and hooking the API calls - which
we do see for both Firefox and Chrome.

Now, we can talk about grades of attacks, and finer nuances, but for a
debug bit that has to be set client side, it really seems a no-op, and for
which common sense would suggest is not a reasonable threat model.

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: SSLKEYLOGFILE always enabled

Robert Relyea
On 07/16/2014 07:31 AM, Jonathan Schulze-Hewett wrote:
> Does having this enabled violate the FIPS 140 requirements on exposing key materials in the clear?

No, because the key logging fails if you are in FIPS mode (It used the
PK11_ExtractKeyValue() to get the key, which will return an error in
FIPS mode.

In general, it's pretty difficult for anything in the SSL layer to
actually foil FIPS because FIPS is implemented in softoken itself.

bob

>
> Sincerely,
> Jonathan
>
>
> -----Original Message-----
> From: dev-tech-crypto [mailto:dev-tech-crypto-bounces+schulze-hewett=[hidden email]] On Behalf Of Ryan Sleevi
> Sent: Tuesday, July 15, 2014 6:12 PM
> To: mozilla's crypto code discussion list
> Subject: Re: SSLKEYLOGFILE always enabled
>
> On Tue, July 15, 2014 1:11 pm, Tom Ritter wrote:
>>   Is having it in by default useful enough to outweigh the risk?
>>
>>   When the Dual_EC_DRBG news stories were blowing it, it was revealed
>>   that you could switch to it by just changing the Windows Registry.
>>   It's a Windows-supported backdoor - no malicious code needs to stay
>>   running on your system - just flip that bit, and delete yourself.
>>   After that, you're all set.
>>
>>   Similarly, having this feature provided by default seems like it
>>   provides a very easy, supported way to extract sensitive key data to
>>   the filesystem or some other covert channel - without invalidating
>>   package signatures, hashes of libraries or binaries, etc.
>>
>>   Don't get me wrong, it's invaluable to be able to use it for
>>   debugging, but I question to need to have it enabled by default...
>>
>>   -tom
> Either you control your machine, or you do not. Either the OS provides
> robust controls, or it does not.
>
> If an attacker has physical access to your machine and can set this, or if
> an attacker can control your operating environment such that the
> environment variable is set, it's all over. This is no different than
> malware hijacking your browser of choice and hooking the API calls - which
> we do see for both Firefox and Chrome.
>
> Now, we can talk about grades of attacks, and finer nuances, but for a
> debug bit that has to be set client side, it really seems a no-op, and for
> which common sense would suggest is not a reasonable threat model.
>


--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SSLKEYLOGFILE always enabled

Falcon Darkstar Momot
When it comes to key material, it's an outstanding idea to err on the
side of caution.

Does anyone actually require this feature in a non-debug build?  If not,
then it's completely unreasonable to leave it in such builds, even if
it's not the weakest link and even if it doesn't break compliance.

--Falcon Darkstar Momot
--Security Consultant, Leviathan Security Group

On 16/07/2014 16:37, Robert Relyea wrote:

> On 07/16/2014 07:31 AM, Jonathan Schulze-Hewett wrote:
>> Does having this enabled violate the FIPS 140 requirements on
>> exposing key materials in the clear?
>
> No, because the key logging fails if you are in FIPS mode (It used the
> PK11_ExtractKeyValue() to get the key, which will return an error in
> FIPS mode.
>
> In general, it's pretty difficult for anything in the SSL layer to
> actually foil FIPS because FIPS is implemented in softoken itself.
>
> bob
>>
>> Sincerely,
>> Jonathan
>>
>>
>> -----Original Message-----
>> From: dev-tech-crypto
>> [mailto:dev-tech-crypto-bounces+schulze-hewett=[hidden email]]
>> On Behalf Of Ryan Sleevi
>> Sent: Tuesday, July 15, 2014 6:12 PM
>> To: mozilla's crypto code discussion list
>> Subject: Re: SSLKEYLOGFILE always enabled
>>
>> On Tue, July 15, 2014 1:11 pm, Tom Ritter wrote:
>>>   Is having it in by default useful enough to outweigh the risk?
>>>
>>>   When the Dual_EC_DRBG news stories were blowing it, it was revealed
>>>   that you could switch to it by just changing the Windows Registry.
>>>   It's a Windows-supported backdoor - no malicious code needs to stay
>>>   running on your system - just flip that bit, and delete yourself.
>>>   After that, you're all set.
>>>
>>>   Similarly, having this feature provided by default seems like it
>>>   provides a very easy, supported way to extract sensitive key data to
>>>   the filesystem or some other covert channel - without invalidating
>>>   package signatures, hashes of libraries or binaries, etc.
>>>
>>>   Don't get me wrong, it's invaluable to be able to use it for
>>>   debugging, but I question to need to have it enabled by default...
>>>
>>>   -tom
>> Either you control your machine, or you do not. Either the OS provides
>> robust controls, or it does not.
>>
>> If an attacker has physical access to your machine and can set this,
>> or if
>> an attacker can control your operating environment such that the
>> environment variable is set, it's all over. This is no different than
>> malware hijacking your browser of choice and hooking the API calls -
>> which
>> we do see for both Firefox and Chrome.
>>
>> Now, we can talk about grades of attacks, and finer nuances, but for a
>> debug bit that has to be set client side, it really seems a no-op,
>> and for
>> which common sense would suggest is not a reasonable threat model.
>>
>
>
>
>

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SSLKEYLOGFILE always enabled

Ryan Sleevi-5
On Wed, July 16, 2014 11:42 pm, Falcon Darkstar Momot wrote:
>  When it comes to key material, it's an outstanding idea to err on the
>  side of caution.
>
>  Does anyone actually require this feature in a non-debug build?  If not,
>  then it's completely unreasonable to leave it in such builds, even if
>  it's not the weakest link and even if it doesn't break compliance.
>
>  --Falcon Darkstar Momot
>  --Security Consultant, Leviathan Security Group

Quite a few people, especially users of Chrome and Firefox, especially
those working to implement or deploy SPDY or HTTP/2.0 (which are over TLS,
ergo Wireshark/pcap can be a pain).

Given that the threat model requires a local attacker with same-privileges
as either of these applications (or influence over NSS environment), can
you describe a threat that could not be equally accomplished through
other, similarly trivial means (e.g. binary compromise)

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: SSLKEYLOGFILE always enabled

Falcon Darkstar Momot
On 17/07/2014 01:26, Ryan Sleevi wrote:

> On Wed, July 16, 2014 11:42 pm, Falcon Darkstar Momot wrote:
>>  When it comes to key material, it's an outstanding idea to err on the
>>  side of caution.
>>
>>  Does anyone actually require this feature in a non-debug build?  If not,
>>  then it's completely unreasonable to leave it in such builds, even if
>>  it's not the weakest link and even if it doesn't break compliance.
>>
>>  --Falcon Darkstar Momot
>>  --Security Consultant, Leviathan Security Group
> Quite a few people, especially users of Chrome and Firefox, especially
> those working to implement or deploy SPDY or HTTP/2.0 (which are over TLS,
> ergo Wireshark/pcap can be a pain).
>
> Given that the threat model requires a local attacker with same-privileges
> as either of these applications (or influence over NSS environment), can
> you describe a threat that could not be equally accomplished through
> other, similarly trivial means (e.g. binary compromise)
>
A better question to ask might be why those people cannot run their
browser with a debug build, since they are developing.

Don't wait for someone to construct an environment with a viable vector
or find a generally viable vector and show you; by that time you're
already late with the fix.  The conditional security argument isn't an
invalid one, but for something like this it defies common sense to
assume any risk at all no matter how minor (on behalf of production
users) for what appears to be zero gain.

-F


--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SSLKEYLOGFILE always enabled

Patrick McManus-3
If there would be a reduced risk by scoping the feature to debug builds I
would agree with you that it should be scoped. But Ryan suggests there
isn't. My much less informed opinion tends to agree with him.

On Thu, Jul 17, 2014 at 3:41 AM, Falcon Darkstar Momot <
[hidden email]> wrote:

>
> why those people cannot run their
> browser with a debug build, since they are developing.
>

I do want to point out that there is considerable value in the current
arrangement - "developing" turns out to have layers. I'm a core firefox
developer - Nick and I write the http/2 code and indeed we generally do it
with debug builds. So its not relevant to my day to day coding.

But a huge part of protocol development happens in the next layer - interop
testing between different servers and on networks with different gear than
is covered by the initial tests. That just takes lots of diversity and some
time. The tail of this pretty much goes on forever - its not just new
protocols.

When a problem shows up on bugzilla a pcap is often the sensible course of
action. These bug reporters are part of development too - hopefully they're
running pre-release channels but sometimes they are not. They "dogfood" the
product day to day and can't be using debug builds for that because its
just too slow. Asking them to download a debug build to file a bug report
will often result in no bug report. So that's the value of the current
setup on the client side - it increases the debugability of the product.
That's a big deal.

-P
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: SSLKEYLOGFILE always enabled

Tom Ritter
(CC-ing DD as I found this bug he reported asking about the same
thing: https://bugzilla.mozilla.org/show_bug.cgi?id=908046)

On 17 July 2014 07:33, Patrick McManus <[hidden email]> wrote:
> If there would be a reduced risk by scoping the feature to debug builds I
> would agree with you that it should be scoped. But Ryan suggests there
> isn't. My much less informed opinion tends to agree with him.

I agree that the level of access needed to exploit this feature is
identical to a level of access that could subvert the system in other
ways.  My concern is about the level of persistence needed to subvert
the system via this method or another. Even if an attacker needs the
same level of access, I don't believe that things that make an
attacker do more work, or be more noisy about their compromise, are
useless.

With the feature available, an attacker could ship SSL key information
off the system without binary modifications, filesystem modifications,
additional running processes, libraries loaded into memory. There's
not a lot of indicators of compromise, especially from a disk image
scenario - which is the usual forensics situation.

> I do want to point out that there is considerable value in the current
> arrangement - "developing" turns out to have layers. I'm a core firefox
> developer - Nick and I write the http/2 code and indeed we generally do it
> with debug builds. So its not relevant to my day to day coding.
>
> But a huge part of protocol development happens in the next layer - interop
> testing between different servers and on networks with different gear than
> is covered by the initial tests. That just takes lots of diversity and some
> time. The tail of this pretty much goes on forever - its not just new
> protocols.
>
> When a problem shows up on bugzilla a pcap is often the sensible course of
> action. These bug reporters are part of development too - hopefully they're
> running pre-release channels but sometimes they are not. They "dogfood" the
> product day to day and can't be using debug builds for that because its
> just too slow. Asking them to download a debug build to file a bug report
> will often result in no bug report. So that's the value of the current
> setup on the client side - it increases the debugability of the product.
> That's a big deal.

I understand, and I can certainly appreciate the convenience of this
as a debugging tool.  A search for Bugzilla for 'SSLKEYLOGFILE' in the
comments did not lead me to any results, although I did find the bugs
where it was changed[0] - it seems it may have been done more to
support Chrome than Firefox.

-tom

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=536474 and
https://bugzilla.mozilla.org/show_bug.cgi?id=762763
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto