149165 - SSL stepdown handshakes may not happen on the same token as domestic

Status: RESOLVED INACTIVE

(NSS :: Libraries, defect, P2)

Description

[Julien Pierre]

The SSL server initialization code in SSL_ConfigSecureServer currently generates 
512-bit RSA stepdown keys in software only. This means that regardless of 
which token the higher-strength 1024 or 2048 bit certified public key lives in 
- be it softoken or a hardware token -, the stepdown handshake will always 
happen in software when the server is contacted by an export client.

We should try to generate the stepdown key in the same token so that we can 
benefit from hardware acceleration in the stepdown handshakes as well.

Comment 1

[Julien Pierre]

The function that would need to be modified to implement this is 
ssl3_createRSAStepDownKeys in lib/ssl/ssl3con.c . Instead of using 
SECKEY_CreateRSAPrivateKey, it should use a PKCS#11 call to generate the key.

This key will need to be a temporary key object, most likely a PKCS#11 public 
session object.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

SECKEY_CreateRSAPrivateKey calls PK11_GetBestSlot to get the slot which 
the user has chosed (via secmod.db) as the "best" slot for RSA ops.  
Then it calls PK11_GenerateKeyPair() to generate the pair in that slot.

If the user has an RSA accelerator, hopefully s/he has set secmod.db to 
make that accelerator the "best" slot for RSA.  

So, I'm not sure this is a problem that needs fixing.  But if it is, 
then I think the right way to do it is NOT to put more PK11 calls into
libSSL, but rather is to create another new SECKEY function that is 
similar to SECKEY_CreateRSAPrivateKey, except that it takes an additional
parameter which is another SECKEYPrivateKey *.  This new function, call it
SECKEY_CreateRSAPrivateKeyByKey finds the slot that holds the private key
passed as an argument, and generates the new key pair in that slot.  

Comment 3

[Julien Pierre]

OK, then the description of this bug isn't accurate, and the behavior isn't as 
bad as I thought. In the context of virtual servers, it's hard to say if there 
can really be such a thing as a "best" slot for RSA in an application. 

Moreover, I doubt that many servers have the RSA mechanism configured correctly 
in secmod.db - merely the slot is selected by virtue of where the server 
certificate lives - even if virtual servers aren't in the picture. Arguably this 
could be considered a server misconfiguration.

Still, in the case where a user has several SSL accelerator with multiple slots, 
it makes sense to stepdown on the same slot as the original handshake with 
domestic cipher suites, so as not to always hit the same accelerator, even one 
is configured as default for the RSA mechanism.

This is probably not a very high priority to fix since export cipher suites are 
on their way out.

Comment 4

[Wan-Teh Chang]

Assigned the bug to Nelson.

Comment 5

[Wan-Teh Chang]

Moved to target milestone 3.8 because the original
NSS 3.7 release has been renamed 3.8.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Remove target milestone of 3.8, since these bugs didn't get into that release.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Julien, 
Would your concerns in comment 3 be satisifed by my proposal in comment 2?

Comment 8

[Julien Pierre]

Nelson, in a word, yes.