188856 - https gets Error Code: -8173 when DHE ciphers negotiated

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Joe Barnett]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030111
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030111

I get the above message when attempting to connect to the above secure site. 
Similarly, I have also received that message when connecting to a secure site I
maintain for development purposes (unfortunately, my dev sites are located on an
'internal only' machine).  Other secure sites, such as https://rhn.redhat.com/,
do not seem to cause such problems.

The only similarity I can find between https://https.openbsd.org/cgi-bin/order
and my internal secure site is that Apache is built against OpenSSL 0.9.7 (beta3
in the OpenBSD case, and 0.9.7 release in my case).  In my example, I've tried
serving the site with both Apache 1.3 and 2.0 and have experienced the problem.
 A slightly older apache, built against OpenSSL 0.9.6b, worked without incident.

I generally get a new Mozilla build every few days, and this has been happening
only since early last week.  I tested 1.0.2, and even the latest "generally
released" 1.3a(b?) and they connect to these sites.  It's only in the latest of
the nightly builds that I've seen this problem.

Reproducible: Always

Steps to Reproduce:
1. point the browser to https://https.openbsd.org/cgi-bin/order
2.
3.

Actual Results:  
A modal(?) error window pops up, with the message "Error establishing and
encrypted connection to <site>.  Error Code: -8173".  Nothing further.  The
browser keeps the current page displayed (not the secure page I intended to visit).

Expected Results:  
Should have displayed the intended page.

Run of the mill Mozilla install, classis theme.  Machine is a home-built Athlon,
256MB RAM, ATI Rage128 video (32MB).  Connected via DSL.  Red Hat 7.3, current
patches.  This machine also has OpenSSL 0.9.7 installed (does Mozilla even
utilize this?).

This machine also boots into Windows 2000, and I noticed the same behaviour with
the latest Mozilla for Windows builds as well.

Comment 1

[Matthias Versen [:Matti]]

-> PSM

Comment 2

[John Unruh]

Confirming with the Jan 13 Win2000 commercial trunk build. Works on Mozilla
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030102

Comment 3

[Sean Harding]

Another example: https://www.arrl.org

Comment 4

[John Unruh]

Attachment: Text file

I can reach the test sites if I disable SSL3 and TLS. After turning those
options back on, I used ssltap to create an attachment while trying to reach
https://www.arrl.org. Save the attachment as file.txt.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

If I'm not mistaken, -8173 == -8192 + 19 , so this is error

SEC_ERROR_NO_MEMORY                         =   SEC_ERROR_BASE + 19,

So, either the browser really is running out of memory (not necessarily 
caused by anything directly related to https), or else some code is falsely
setting this error code.  

Can this be reproduced with tstclnt?

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

This must be a version of mozilla in which the new DHE ciphersuites have
been enabled.  The client and server have negotiated a DHE ciphersuite.
The error occurs in NSS.  The calls stack is shown below.  The relevant
code is the following code in PK11_GenerateKeyPair:

    crv = PK11_GETTAB(slot)->C_GenerateKeyPair(session_handle, &mechanism,
	pubTemplate,pubCount,privTemplate,privCount,&pubID,&privID);


    if (crv != CKR_OK) {
	if (restore)  {
	    PK11_RestoreROSession(slot,session_handle);
	} else PK11_ExitSlotMonitor(slot);
	PORT_SetError( PK11_MapError(crv) );
	return NULL;
    }

The variable crv contains the value 2, which is CKR_HOST_MEMORY.

The stack is:

PORT_SetError(int 0xffffe013) line 178 + 12 bytes
PK11_GenerateKeyPair(PK11SlotInfoStr * 0x005313b0, unsigned long 0x00000020, 
void * 0x0012e81c, SECKEYPublicKeyStr * * 0x0012e848, int 0x00000000, int 
0x00000000, void * 0x00000000) line 2086 + 21 bytes
SECKEY_CreateDHPrivateKey(SECKEYDHParamsStr * 0x0012e81c, SECKEYPublicKeyStr * * 
0x0012e848, void * 0x00000000) line 223 + 27 bytes
sendDHClientKeyExchange(sslSocketStr * 0x00543d08, SECKEYPublicKeyStr * 
0x005539a8) line 3310 + 15 bytes
ssl3_SendClientKeyExchange(sslSocketStr * 0x00543d08) line 3851 + 13 bytes
ssl3_HandleServerHelloDone(sslSocketStr * 0x00543d08) line 4737 + 9 bytes
ssl3_HandleHandshakeMessage(sslSocketStr * 0x00543d08, unsigned char * 
0x00548924, unsigned int 0x00000000) line 7213 + 9 bytes
ssl3_HandleHandshake(sslSocketStr * 0x00543d08, sslBufferStr * 0x00543eb0) line 
7300 + 25 bytes
ssl3_HandleRecord(sslSocketStr * 0x00543d08, SSL3Ciphertext * 0x0012e9b8, 
sslBufferStr * 0x00543eb0) line 7564 + 13 bytes
ssl3_GatherCompleteHandshake(sslSocketStr * 0x00543d08, int 0x00000000) line 203 
+ 22 bytes
ssl_GatherRecord1stHandshake(sslSocketStr * 0x00543d08) line 1256 + 11 bytes
ssl_Do1stHandshake(sslSocketStr * 0x00543d08) line 145 + 13 bytes
ssl_SecureSend(sslSocketStr * 0x00543d08, const unsigned char * 0x0012eaa0, int 
0x00000012, int 0x00000000) line 1024 + 9 bytes
ssl_SecureWrite(sslSocketStr * 0x00543d08, const unsigned char * 0x0012eaa0, int 
0x00000012) line 1058 + 19 bytes
ssl_Write(PRFileDesc * 0x00543c98, const void * 0x0012eaa0, int 0x00000012) line 
1262 + 21 bytes

The next question is: why did the key gen functions return that error code?

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

In the previous comment, I asked why, when attempting to generate an 
ephemeral Diffie Hellman key pair, does NSC_GenerateKeyPair return 
CKR_HOST_MEMORY? 

The answer is as follows.  The relevant stack is:

pk11_Attribute2SSecItem(PLArenaPool * 0x00554f50, SECItemStr * 0x005546a4, 
PK11ObjectStr * 0x0055a9f0, unsigned long 0xd5a0db00) line 1225
pk11_mkPrivKey(PK11ObjectStr * 0x0055a9f0, unsigned long 0x00000002) line 1884
pk11_handlePrivateKeyObject(PK11SessionStr * 0x004db718, PK11ObjectStr * 
0x0055a9f0, unsigned long 0x00000002) line 1242 + 13 bytes
pk11_handleKeyObject(PK11SessionStr * 0x004db718, PK11ObjectStr * 0x0055a9f0) 
line 1502 + 17 bytes
pk11_handleObject(PK11ObjectStr * 0x0055a9f0, PK11SessionStr * 0x004db718) line 
1687 + 13 bytes
NSC_GenerateKeyPair(unsigned long 0x00000001, CK_MECHANISM * 0x0012e6b8, 
CK_ATTRIBUTE * 0x0012e644, unsigned long 0x00000008, CK_ATTRIBUTE * 0x0012e770, 
unsigned long 0x00000007, unsigned long * 0x0012e5ac, unsigned long * 
0x0012e754) line 3316 + 13 bytes
PK11_GenerateKeyPair(PK11SlotInfoStr * 0x005313b0, unsigned long 0x00000020, 
void * 0x0012e81c, SECKEYPublicKeyStr * * 0x0012e848, int 0x00000000, int 
0x00000001, void * 0x00000000) line 2079 + 55 bytes
SECKEY_CreateDHPrivateKey(SECKEYDHParamsStr * 0x0012e81c, SECKEYPublicKeyStr * * 
0x0012e848, void * 0x00000000) line 226 + 27 bytes
sendDHClientKeyExchange(sslSocketStr * 0x00543d08, SECKEYPublicKeyStr * 
0x005539a8) line 3310 + 15 bytes

The DH key pair has been generated by blapi without error.  
Softoken is now trying to setup the private key object in the token.
pk11_mkPrivKey calls pk11_Attribute2SSecItem(arena,&privKey->u.dh.publicValue,
                                             object,CKA_NETSCAPE_DB);
which attempts to fetch the CKA_NETSCAPE_DB attribute from the private key
object by calling pk11_FindAttribute.  

pk11_FindAttribute returns NULL,
so pk11_Attribute2SSecItem returns CKR_TEMPLATE_INCOMPLETE to pk11_mkPrivKey.
pk11_mkPrivKey returns NULL to pk11_handlePrivateKeyObject (we lose the crv 
value CKR_TEMPLATE_INCOMPLETE at this level).
pk11_handlePrivateKeyObject sees the NULL, and sets the crv to CKR_HOST_MEMORY,
which is wrong in this case.

So, here are the remaining observations/comments about this NSS bug.

1. pk11_mkPrivKey should return both a key pointer and a CRV value, so that 
its caller doesn't have to guess at the real problem.

2. why does it fail to find the CKA_NETSCAPE_DB attribute?

3. DHE ciphersuites worked some time ago.  Why/how did this regression occur?
The fact that we haven't previously detected this regression is one cost of 
having a client-side only implementation of DHE.  :-(

I am turning this into an NSS bug.  In the meantime, users should be able to
disable the DHE ciphersuites using the new extended ciphersuite selection GUI
in mozilla.

Comment 8

[Wan-Teh Chang]

Changed owner and QA contact.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

One more comment. 

If pk11_handlePrivateKeyObject had returned CKR_TEMPLATE_INCOMPLETE,
then it would have been mapped into SEC_ERROR_BAD_DATA, which SSL would
have mapped into SEC_ERROR_KEYGEN_FAIL, which would have correctly 
described the problem.

Raising to P1 due to the regression.  The DHE ciphersuites were to be a
major new feature.  The fact that they're all failing is rather embarrasing.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

I reproduced this error with the following NSS command:

tstclnt -c p -d /tmp/newdb -h www.arrl.org -vvv -f < stdin.txt > /dev/null

where stdin.txt is a two line file.  The first line is

GET / HTTP/1.0

The second line is blank.  Both lines are ended with CR LF.

Comment 11

[Wan-Teh Chang]

Bob, could you take a look at this bug?  Thanks.

Comment 12

[John Unruh]

*** Bug 189017 has been marked as a duplicate of this bug. ***

Comment 13

[Wan-Teh Chang]

This bug will be moved to NSS 3.7.2 when Bugzilla
has a 3.7.2 target milestone for NSS.

Comment 14

[Boris Zbarsky [:bzbarsky]]

*** Bug 190039 has been marked as a duplicate of this bug. ***

Comment 15

[Tom Mraz]

*** Bug 190925 has been marked as a duplicate of this bug. ***

Comment 16

[Tom Mraz]

Another example of a site with the problem https://www.pipni.cz/ (Apache 2.0.x +
mod_ssl)

Comment 17

[Tom Mraz]

*** Bug 181440 has been marked as a duplicate of this bug. ***

Comment 18

[Wan-Teh Chang]

This bug should not block Mozilla 1.3b.  All the
DHE ciphersuites have been removed from the Mozilla
client to work around this bug.  We will add them
back when we fix this bug.

Comment 19

[Robert Relyea]

Attachment: 1) Return proper error code in more cases. 2) Fix bug in DH KeyPair Generation.

the essential part of this fix in pkcs11c.c where we add the CKA_NETSCAPE_DB
attribute on Diffie-Hellman key gen. I don't know why the code would have even
thought of working without this (unless we were testing with pregenerated
keys).

The rest of the fix is to surface more of the PKCS #11 error back up. There is
a separate bug to continue tracking the issue of lost PKCS #11 errors.

Comment 20

[David P James]

*** Bug 189357 has been marked as a duplicate of this bug. ***

Comment 21

[David P James]

From bug 189357:

These sites also display this problem:
http://mail.copi.org/
https://www.nmrc.ie/

Does not seem to be a problem with WinXP:
http://bugzilla.mozilla.org/show_bug.cgi?id=189357#c4

Comment 22

[David G King]

Just retested the original instructions on a WinXP machine running Trunk build
2003012804, and got error -8173. Also tried mail.copi.org and also got the error.

This is a problem in WinXP.

Comment 23

[Wan-Teh Chang]

Attachment: Fix a typo in pk11_GetPubKey

Vipul Gupta of Sun submitted this patch.

Comment 24

[Wan-Teh Chang]

The workaround we checked in (see bug 190640) did
not make it into today's Mozilla trunk build.
Please download the Mozilla trunk build tomorrow
and verify the workaround again.  Thanks.

Please comment on the workaround in bug 190640.

Comment 25

[lhecking]

It appears that the version I built from cvs (cvs update about 12h ago) fixes my
problem [Re: comment #21, https:ww.nmrc.ie/].

Comment 26

[Robert Relyea]

The above fixes plus wtc's review comments on these fixes have been checked into
the NSS 3.7 BRANCH and the NSS tip.

Comment 27

[Wan-Teh Chang]

Comment on attachment 112879 [details] [diff] [review]
1) Return proper error code in more cases. 2) Fix bug in DH KeyPair Generation.

I've reviewed the checked-in version of this patch,
in which Bob has addressed the issues I pointed out
in my first code review.  r=wtc.

Bob, I noticed that you add this comment in three places
in lib/softoken/pkcs11c.c:
    *crvp = CKR_DEVICE_ERROR; /* should map NSS SECError */
What do this comment mean?  Is this a "to do" reminder?

Nelson, I'd like you to review the following changes in this
patch:

>Index: pkcs11c.c
>===================================================================
>RCS file: /cvsroot/mozilla/security/nss/lib/softoken/pkcs11c.c,v
>retrieving revision 1.38.10.1
>diff -u -r1.38.10.1 pkcs11c.c
>--- pkcs11c.c	13 Dec 2002 00:02:07 -0000	1.38.10.1
>+++ pkcs11c.c	28 Jan 2003 18:27:15 -0000
[...]
>@@ -3311,6 +3308,7 @@
> 	pk11_DeleteAttributeType(privateKey,CKA_PRIME);
> 	pk11_DeleteAttributeType(privateKey,CKA_BASE);
> 	pk11_DeleteAttributeType(privateKey,CKA_VALUE);
>+    	pk11_DeleteAttributeType(privateKey,CKA_NETSCAPE_DB);
> 	key_type = CKK_DH;
> 
> 	/* extract the necessary parameters and copy them to private keys */
>@@ -3345,6 +3343,10 @@
> 				pk11_item_expand(&dhPriv->publicValue));
> 	if (crv != CKR_OK) goto dhgn_done;
> 
>+        crv = pk11_AddAttributeType(privateKey,CKA_NETSCAPE_DB,
>+			   pk11_item_expand(&dhPriv->publicValue));
>+	if (crv != CKR_OK) goto dhgn_done;
>+
> 	crv=pk11_AddAttributeType(privateKey, CKA_VALUE, 
> 			      pk11_item_expand(&dhPriv->privateValue));
>

Comment 28

[Nelson Bolyard (seldom reads bugmail)]

Regarding the question about the meaning of the comment 
     /* should map NSS SECError */
This comment refers to bug 190501, which is also targetted to be fixed in 
NSS 3.8.  That bug reports that in many places in softoken, the wrong PKCS 11
error code is returned.  The proper thing to do, in many cases, is to map the
SEC_ERROR code to a PKCS 11 error code.  Recently, more places have been added
to softoken that fail to determine the proper error code.  Bob has marked them
with comments like that one.

r=nbb for the portion of code shown above.  

Comment 29

[Wan-Teh Chang]

Nelson answered my question and reviewed the essential
part of the patch.  The patch has been checked in on
the NSS TIP and NSS_3_7_BRANCH.  Marked the bug fixed.
Will request approval for checking in to mozilla 1.3.

Comment 30

[Wan-Teh Chang]

Comment on attachment 112879 [details] [diff] [review]
1) Return proper error code in more cases. 2) Fix bug in DH KeyPair Generation.

This patch has been reviewed by me and nelsonb (see
comment 28).  Requesting approval for mozilla 1.3.

Comment 31

[Asa Dotzler [:asa]]

Comment on attachment 112879 [details] [diff] [review]
1) Return proper error code in more cases. 2) Fix bug in DH KeyPair Generation.

a=asa (on behalf of drivers) for checkin to 1.3.

Comment 32

[Wan-Teh Chang]

Fix checked into the NSS_CLIENT_TAG for mozilla 1.3.

Comment 33

[Nelson Bolyard (seldom reads bugmail)]

Changed subject to reflect the problem