Re: NSS_Context and FIPS

Robert Relyea wrote:
> On 10/21/2016 07:04 AM, Rob Crittenden wrote:
>> I'm trying to figure out how to dynamically enable FIPS support for
>> NSS Contexts.
>>
>> I started with multinit.c and initialize FIPS right after calling
>> NSS_InitContext() using this:
>
> So you can't change the state of an already open database. NSS will
> switch all new databases that are opened, and idle the old ones
> (basically they are open, but not really accessible).
>
>
>>
>>     if (!PK11_IsFIPS()) {
>>         fprintf(stderr, "Initializing FIPS\n");
>>         SECMODModule *mod = SECMOD_GetInternalModule();
>>         if (!mod) {
>>             fprintf(stderr, "No module!?\n");
>>             exit(1);
>>         }
>>         char * internal_name = PR_smprintf("%s",
>>             SECMOD_GetInternalModule()->commonName);
>>
>>         if ((SECMOD_DeleteInternalModule(internal_name) != SECSuccess) ||
>>          !PK11_IsFIPS()) {
>>                  fprintf(stderr, "Unable to enable FIPS mode on
>> certificate database\n");
>>                  exit(1);
>>         }
>>
>> I'm executing it like this, initializing only db1 and db2 as contexts:
>
> So when you do an initcontext, you're main database is usually not the
> same as the main database when you open NSS, so it won't get
> automatically switched.
>
> Is there a reason you are trying to do a dynamic switch to FIPS mode
> from within a library? (I'd like to know the use case).

I'm converting mod_nss to use contexts. I previously had an option to 
switch on FIPS mode which turned it on in NSS, did some sanity checking 
on the cipher options and required a password.

I'd be ok requiring an all or nothing with the FIPS databases if that 
simplifies thiungs.

> Dynamic switching is a pretty careful choreographed dance that
> applications like mozilla can execute with care. It usually involves
> both fips and non-fips tokens opened for a short period until all the
> references can be cleared. Databases opened before the switch will
> almost certainly be inaccessible.
>>
>> $ ./multinit --verbose --lib1_db db1/ --lib2_db db2 --lib1_command
>> list_certs --lib2_command list_certs --lib1_readonly --lib2_readonly
>> --order 12zi
>>
>> This is the output:
>>
>> $ ./multinit --verbose --lib1_db db1/ --lib2_db db2 --lib1_command
>> list_certs --lib2_command list_certs  --lib1_readonly --lib2_readonly
>> --order  12zi
>> * initializing with order "12zi"*
>> *NSS_Init for lib1*
>> Checking for FIPS
>> Initializing FIPS
>> *Executing nss command "list_certs" for lib1*
>> cacert CTu,Cu,Cu
>> *       Slot=NSS FIPS 140-2 Certificate DB*
>> *       Nickname=cacert*
>> *       Subject=<CN=Certificate Shack,O=example.com,C=US>*
>> *       Issuer=<CN=Certificate Shack,O=example.com,C=US>*
>> *       SN=01 *
>> Server-Cert                                                  u,u,u
>> *       Slot=NSS FIPS 140-2 Certificate DB*
>> *       Nickname=Server-Cert*
>> *       Subject=<CN=darlene.greyoak.com,O=example.com,C=US>*
>> *       Issuer=<CN=Certificate Shack,O=example.com,C=US>*
>> *       SN=04 *
>> *NSS_Init for lib2*
>> Checking for FIPS
>> FIPS already enabled
>> *Executing nss command "list_certs" for lib1*
>> *Executing nss command "list_certs" for lib2*
>> *NSS_Shutdown for lib2
>> *Shutdown lib2 state = 0
>> *Executing nss command "list_certs" for lib1*
>> *NSS_Shutdown for lib1
>> *Shutdown lib1 state = 0
>>
>> So db1 is successfully put into FIPS mode and the slot names are
>> changed as one would expect, but then lib2 isn't set into FIPS mode
>> and subsequently no certificates are discovered at all (I can only
>> assume because there is a mix of FIPS and non-FIPS tokens so it throws
>> up?)
> yes.
>>
>> Any idea what I'm doing wrong?
> pushing the limits of what is possible;).
>
> So things are acting as I would expect. your other lib will likely need
> to shutdown it's database and reopen it.

I'm still a little unclear. So if I open all the databases, and THEN set 
FIPS mode, that will do the trick? I was pretty sure I tried that but 
who knows.

thanks

rob

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