[Swan] NSS transition questions

[Paul Wouters]

On Thu, 23 May 2013, Greg Scott wrote:

> Looking forward to a long run with Libreswan - great to find you again!   I noticed a thread saying Libreswan now only uses NSS.  Is the old way with the key stored directly in ipsec.secrets and hostkey.secrets now gone forever?

Private cryptographic keys must be stored now in the NSS db.
Preshared keys can still reside in /etc/ipsec.secrets or its include files

Public certificates can be placed into /etc/ipsec.d/certs but this will
go away in the near future

Public CA certificates can be placed into /etc/ipsec.d/cacerts/ but this
will go away in the near future

CRLs can be placed into /etc/ipsec.d/crlts but this will go away in the
near future.

The reason for this is that we have a lot of custom ASN.1/X.509 parsing
code that is old, does not support upcoming and new algorithms and
hashes, and has no concept of FIPS restrictions. If we use NSS, then all
of that is done for us, and is actively maintained and extended for us
to use.

For CRL fetching, currently done by pluto, we will also migrate to another
nss module that does that for us. We then get modern CRL fetching for
free. And OCSP support will be back (we had it in really old versions
of openswan but it suffered bit rot)

CRL updates will likely be stored in /etc/ipsec.d/ in an NSS format.

> If now forced to use NSS, is there a way to import old pre shared keys into an NSS database?

Preshared keys require no change. They are never stored inside NSS.

> Here is the use case.  I have a central site with several branch sites, all running  various versions of Openswan.  Historically, when the time came to update any of these sites with new hardware, I could just copy the ipsec.secrets and hostkey.secrets file from the old to the new and everyone was happy.

You can still do that. If you only use PSK, then whether or not NSS is
used is irrelevant for you.

> But with NSS, I have to generate new keys and modify CONN definitions all over the place because there was no way to import the older hostkey.secrets keys into a new NSS database.   So any time any site changed to/from NSS, I had to modify CONN definitions at the central site, which could potentially affect all sites if I wasn't careful.

If you want to import certs and keys into the NSS, you can use the
"certutil" command from nss-tools. For the simple case of a PKCS#12
file (.p12 file), you can use "ipsec import /path/to/your.p12".
Note that the import does not change the leftcert= line, you will
still need to change that to leftcert=yourfriendlyname

(yourfriendly name is selected by you when you export PKCS#12 files.

We do want to make importing of certs/cacerts/crls easier too in the
future, but as I said, right now you can still leave those in the old
locations.

> That was my major beef against NSS when Openswan first started using it.  Also, installing directly from the  .tar.gz sources had no provision to include NSS as I recall.  RPM builds included NSS, but source builds from .tar.gz files did not, and since new RPMs for any given Fedora release stop coming after a year or so, I went to .tar.gz packages.  For a while, some sites used NSS and others did not and this was a royal pain to go back and forth until I gradually updated everyone.
>
> Since we apparently have to use NSS now, is there anything in place to ease the transition from the old way to the new NSS way?  Or can I continue installing Libreswan from .tar.gz files without NSS?

No the code has been removed. That is the main goal of using NSS where
we can. Remove old crufy ASN.1/X.509 parsing code. We don't want more
CVE's with those.

Paul