Re: NSS_Context and FIPS

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).

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.

bob
>
> thanks
>
> rob


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