Closed Bug 616757 Opened 14 years ago Closed 13 years ago

When using non-RSA key exchange and renegotiating, NSS will always send a client certificate if the first handshake requested one, but subsequent renegotiation handshakes did not

Categories

(NSS :: Libraries, defect, P1)

3.12.7
defect

Tracking

(Not tracked)

RESOLVED FIXED
3.12.10

People

(Reporter: ryan.sleevi, Assigned: ryan.sleevi)

Details

Attachments

(2 files)

This bug particularly applies to DHE, but technically may apply to any non-RSA key exchange type.

Under the following sequence, NSS will send a Certificate message before the ClientKeyExchange:

1) NSS sends ClientHello
2) Peer sends ServerHello, selecting DHE cipher suite
3) Peer sends Certificate, ServerKeyExchange, CertificateRequest, ServerHelloDone
4) NSS invokes configured client certificate callback as part of ssl3_HandleCertificateRequest
5) NSS stores the certificate in ss->ssl3.clientCertificate and the private key in ss->ssl3.clientPrivateKey
6) NSS sends Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec, Finished
7) Peer sends ChangeCipherSpec, Finished
8) Peer sends HelloRequest
9) NSS sends ClientHello
10) Peer sends ServerHello, selecting DHE cipher suite again
11) Peer sends Certificate, ServerKeyExchange, ServerHelloDone (that is: omitting CertificateRequest)
*BUG* 12) NSS sends Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec, Finished

If an RSA cipher suite is selected during both steps, for step 12, NSS sends ClientKeyExchange, ChangeCipherSpec, Finished as expected, and the peer is able to complete.

An example of a server configuration that actively performs such a handshake is Apache 2.2.16+, configured with a non-default SSLVerifyDepth in a .htaccess rule, with a redirect configured to that page (see Attachment)

The reason this works for RSA, but not DHE, is because of the combination of these two lines:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/ssl3con.c&rev=1.149&mark=4846-4849#4842

clears the RSA private key after the CertificateVerify message is sent, and 

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/ssl3con.c&rev=1.149&mark=5731#5721

will only send a Certificate message if the private key is still valid. After the first handshake, the clientPrivateKey is cleared, so the renegotiation handshake does not cause the certificate to be sent (but clientCertificate is still valid). For DHE, clientPrivateKey is still held onto during the renegotiation, so it fails.
The comment appears to be related to the fact that fixed-DH would reuse the clientPrivateKey, which itself comes from the clientCertificate. However, NSS does not support fixed-DH client authentication, nor judging by the CVS history, has it ever.

Perhaps the simplest way to resolve this problem is to remove lines 4842-4846 and 4849, causing the clientPrivateKey to be unconditionally freed after the CertificateVerify has been calculated.
This problem was originally discovered in Chromium at http://code.google.com/p/chromium/issues/detail?id=62027 , and uploaded by the original bug reporter (geki007)
Alternatively, the state flag clientAuthRequested exists on sslSocketStr, which would seem appropriate to track whether a CertificateRequest was sent and, if not, disable sending certificates:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/sslimpl.h&rev=1.81&mark=1017#1016

but that flag does not appear to be used anywhere presently within NSS.
Sorry, slight correction - this first seems to have appeared in Apache 2.2.12, specifically http://svn.apache.org/viewvc?view=revision&revision=776281 . The changes at http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_kernel.c?annotate=776281&pathrev=776281#l2034 are what introduced the behaviour where it no longer sends a CertificateRequest during a renegotiation.
Ryan: thanks a lot for tracking down this bug and proposing a
fix.

I think the fix should also include moving this block of code
in ssl3_HandleCertificateRequest:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/ssl3con.c&rev=1.149&mark=5459-5471#5428

to ssl3_HandleServerHello, so that it is executed whether a
CertificateRequest is received or not.  Or we just extend your
proposed fix in comment 1 to also free clientCertChain and
clientCertificate unconditionally.
Assignee: nobody → ryan.sleevi
Status: NEW → ASSIGNED
Target Milestone: --- → 3.12.10
Attachment #496750 - Flags: review?(wtc)
Priority: -- → P1
does this also apply to firefox 4 beta9?

Cause i'm experencing this problem since i switched to beta9

my firefox 3.6 ubuntu version of firefox: 3.6.13 is working

I'm seeing such lines on the server (with FF4 beta9):
[Fri Jan 21 16:51:44 2011] [error] [client 85._, __ , _.238] Re-negotiation handshake failed: Not accepted by client!?

System: Ubuntu 10.04 with 2.6.32-27-generic 64bit
ps: i'm using the FF4 Beta9 from the offical mozilla website.
changing  (on the apache server)
SSLVerifyDepth 10
to
SSLVerifyDepth 1
fixes the problem.

Anyhow 3.6.13 worked, Firefox 4 Beta9 needs changes on the server?
Comment on attachment 496750 [details] [diff] [review]
Patch against NSS_3_12_BRANCH (checked in)

r=wtc.

Patch checked in on the NSS trunk (NSS 3.13).

Checking in ssl3con.c;
/cvsroot/mozilla/security/nss/lib/ssl/ssl3con.c,v  <--  ssl3con.c
new revision: 1.150; previous revision: 1.149
done

I will check this in on the NSS_3_12_BRANCH after it passes NSS
tinderboxes.
Attachment #496750 - Attachment description: Patch against NSS_3_12_BRANCH → Patch against NSS_3_12_BRANCH (checked in on trunk)
Attachment #496750 - Flags: review?(wtc) → review+
(In reply to comment #7)
Bernhard Redl wrote:
> does this also apply to firefox 4 beta9?

It should.
 
> my firefox 3.6 ubuntu version of firefox: 3.6.13 is working

This may be because Firefox 3.6.13 is using a different cipher
suite (TLS_RSA_WITH_AES_256_CBC_SHA), which is not affected by
this bug.

Please perform the following experiment with FF4 beta9.

1. Type "about:config" in the location bar.
2. In the "Filter" text field, type "ssl3.dhe_rsa_aes".
3. Change the value of "security.ssl3.dhe_rsa_aes_256_sha"
   to "false".
4. Restart FF4 beta9.

Does this allow FF4 beta9 to work with your server?

Remember to change the value of "security.ssl3.dhe_rsa_aes_256_sha"
back to "true" after this experiment.  Thanks!
Setting the value of "security.ssl3.dhe_rsa_aes_256_sha" to false FIXES the ISSUE.
Thx
(In reply to comment #10)
> (In reply to comment #7)
> Bernhard Redl wrote:
> > does this also apply to firefox 4 beta9?
> 
> It should.
> 
> > my firefox 3.6 ubuntu version of firefox: 3.6.13 is working
> 
> This may be because Firefox 3.6.13 is using a different cipher
> suite (TLS_RSA_WITH_AES_256_CBC_SHA), which is not affected by
> this bug.
> 
> Please perform the following experiment with FF4 beta9.
> 
> 1. Type "about:config" in the location bar.
> 2. In the "Filter" text field, type "ssl3.dhe_rsa_aes".
> 3. Change the value of "security.ssl3.dhe_rsa_aes_256_sha"
>    to "false".
> 4. Restart FF4 beta9.
> 
> Does this allow FF4 beta9 to work with your server?
> 
> Remember to change the value of "security.ssl3.dhe_rsa_aes_256_sha"
> back to "true" after this experiment.  Thanks!
Comment on attachment 496750 [details] [diff] [review]
Patch against NSS_3_12_BRANCH (checked in)

Patch checked in on the NSS_3_12_BRANCH (NSS 3.12.10).

Checking in ssl3con.c;
/cvsroot/mozilla/security/nss/lib/ssl/ssl3con.c,v  <--  ssl3con.c
new revision: 1.142.2.5; previous revision: 1.142.2.4
done
Attachment #496750 - Attachment description: Patch against NSS_3_12_BRANCH (checked in on trunk) → Patch against NSS_3_12_BRANCH (checked in)
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
getting the issue again on Firefox 5 Beta. Same workaround as before firefox4 patch:

1. Type "about:config" in the location bar.
2. In the "Filter" text field, type "ssl3.dhe_rsa_aes".
3. Change the value of "security.ssl3.dhe_rsa_aes_256_sha"
   to "false".
4. Restart FF4 beta9.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: