51466 - SSL client rejects server cert with keyUsage = digitalSignature

Status: NEW

(NSS :: Libraries, defect, P3)

Description

[Nelson Bolyard (seldom reads bugmail)]

In the IETF-TLS mailing list, Rene Eberhard wrote:

> But be careful with server key exchange messages
> containing a cert with keyUsage = digitalSignature.
> Not all browsers can handle this properly =(. Some reject
> the cert even it has been used for signing a temp rsa key.

When I asked him what browsers do that, he replied to me:

> Unfortunately only Netscape browsers behave that way.
> At least when RSA_EXPORT is used and the temp RSA key
> has been signed with a signing only cert NS should 
> accept that cert.

By reviewing the code, I have found that:
1) the client will only accept a server key exchange message if 
   a) The cipher suite's KEA is limited to 512 bits, or 
   b) it's fortezza.
   It should also allow it if the server's cert is signing-only.

2) our server code only sends the server key exchange message if
   a) it's fortezza, or 
   b) the KEA is RSA_EXPORT and the RSA private key size is > 512.
   It should also allow it if the server's cert is signing-only.

Note that SSL3 and TLS specs differ in the permitted uses of 
signing-only certs.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Fixing this will require some additional code in the cert library.
I should create another bug, against the cert library, and make 
this bug depend on that one.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Attachment: Proposed new implementation of CERT_GetNickName()

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Doh! the attachment above got attached to the wrong bug.
I wish there was a way to delete that attachment.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Changing target milestone to 3.3

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

The fix for this will not be in NSS 3.3 or 3.4

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 15065 [details]
Proposed new implementation of CERT_GetNickName()

obsoleting this attachment. It was attached to the wrong bug, and is not
relevant to this bug.

Comment 7

[Erwann Abalea]

The problem still exists today.

A digitalSignature only server certificate, used with a DHE+RSA ciphersuite, displays an error message on the client (sec_error_inadequate_key_usage).

Comment 8

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

It seems like, in order to support this, we need to pass the intended key usage (encryption or digitalSignature) to the cert authentication callback, which means we would need a new cert auth callback interface. Also, if the application does any caching of cert authentication results, it needs to consider the key usage to be part of the cache key.

Perhaps, we could add this new cert auth callback function as part of the work on enabling non-blocking cert auth callbacks (bug 542832).

Comment 9

[Wan-Teh Chang]

I remember I wrote a comment about this problem in some other
bug report recently, so there is a duplicate of this bug in
Bugzilla.

Comment 10

[Kaspar]

Isn't it more CERT_CheckKeyUsage() in certdb.c which might have to be tweaked (the rsaKey case)?

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certdb/certdb.c&rev=1.116&mark=1265-1266#1250

Comment 11

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

See the comments in bug 237877, especially Nelson's comment bug 237877 comment 1.

For ECDHE_RSA and DHE_RSA cipher suites, we should verify the cert is valid for digital signatures; for normal RSA cipher suites, we should verify the cert is valid for encryption. It seems like it will be impossible to do this with the old non-libpkix API, but it should be possible with libpkix.

Do we guarantee that SSL_GetChannelInfo can be called by the auth cert callback to retrieve the cipher suite used? If so, SSL_GetChannelInfo + SSL_GetCipherSuiteInfo can be used to determine which key agreement scheme is used, and this can be used to determine the required key usage. So, perhaps no new auth certificate callback is needed.

Comment 12

[Wan-Teh Chang]

As Kaspar noted, we can tweak CERT_CheckKeyUsage to require
digitalSignature or keyEncipherment for RSA server certificates.
We already give ecKey that kind of special treatment:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certdb/certdb.c&rev=1.116&mark=1250,1259,1274-1276#1246

Proper key usage extension of an RSA server certificate can be enforced
in ssl3_HandleServerKeyExchange (or rather ssl3_VerifySignedHashes)
and ssl3_SendClientKeyExchange.