117797 - RFE for encrypted password.conf for SSL server starts

Status: RESOLVED INVALID

(NSS :: Libraries, enhancement, P3)

Description

[Thomas Stangl]

Server products that use the NSS component to provide SSL capabilities sometimes 
require the ability to restart unattended.  The current solution is to provide a 
"password.conf" file that contains an unencrypted copy of the certificate and 
key database password.

Many customers balk at using the password.conf file to start servers unattended 
as a security risk.  

It would be a good idea to add an NSS utility that would encrypt a password for 
the password.conf file, and modify the libraries so the servers could read the 
encrypted password within the password.conf file.

Comment 1

[Wan-Teh Chang]

Bob, could you evaluate this RFE?  Thanks.

Comment 2

[Robert Relyea]

1) This is an old request, which has some very major down sides.

The problem is where to get the key to decrypt the password.conf files. If you
don't read the key from some secure hardware device, or generate the key from a
PBE. In the latter case you still need someone to type in the PBE. This means
without hardware support, the best you can do is obscure password.conf. Doing so
actually provides less security because it lulls the user into thinking that
they do not have to protect the password.conf file. Obsured files are no safer
from determined attackers than files in the clear.

The upshot is unattended operation is really only safe for a machines that have
been secured (either from direct attack, or the keys have been secured on
hardware tokens).

2) password.conf support is not part of NSS anyway. It's up to each server to
decide how it manages it's passwords, though because of statement 1 I highly
suggest that servers do not try to encrypt their password.conf unless that have 
secure way to get the key.

bob

Comment 3

[Wan-Teh Chang]

I am resolving this RFE invalid because password.conf is
not part of NSS.  (It is part of the "svrcore" component.)