On 12/19/2016 03:07 PM, John Dennis wrote:
On 12/19/2016 03:12 AM, Standa Laznicka wrote:
On 12/16/2016 03:23 PM, Rob Crittenden wrote:
Standa Laznicka wrote:
Hello,
I started a design page for FreeIPA on FIPS-enabled systems:
https://www.freeipa.org/page/V4/FreeIPA-on-FIPS
Me and Tomáš are still investigating what of all things will need to
change in order to have FreeIPA on FIPS-enabled RHEL. So far I managed
to install and run patched FreeIPA server and client and connect them
together.
There are some issues with NSS when trying to create an HTTPS request
(apparently, NSS requires an NSS database password to set up an SSL
connection). I am actually thinking of removing NSSConnection from the
client altogether.
Can you expand on this a bit? NSS should only need a pin when it needs
access to a private key. What connection(s) are you talking about, and
what would you replace NSSConnection with?
rob
Hello Rob,
Thank you for this excellent question, in order to cut the email short I
seem to have omitted quite a few information.
One of the very first problems I had with FreeIPA with FIPS was that NSS
was always asking for password/pin. I was discussing this with the NSS
guys on their IRC chat last week and it turns out that NSS tries to
create a private key every time you want to use it as a backend for an
SSL connection on FIPS. I still don't think this is quite right so I may
open a bugzilla for that.
I don't understand, I thought the case you were having problems with
was the FreeIPA client, not the server. I assume when you use the term
"backend" you mean server, and yes when NSS is in server mode it will
access to keys. So isn't the problem NSS is not being initialized
correctly so that it recognizes it is in client mode and not server mode?
What I meant was "a client backend for an SSL connection" - we're using
NSS implementation of SSL (via python-nss) for HTTPS connections from
client to server during which we're getting a CA cert from an NSS
database but this eventually leads to a password prompt.
Anyway, the guys suggested me that we could try to create the database
with an empty password and everything will work. I don't quite like
that, too, but it's at least something if you don't want the `ipa`
command to always bug you for password you have no way knowing if you're
just a regular user.
What I think would be a better way to go is to use
httplib.HTTPSConnection. We have the needed certificates in
/etc/ipa/ca.crt anyway so why not use them instead. We had a discussion
with Honza this morning and it seems that with this approach we may get
rid of the NSSConnection class altogether (although I still need to
check a few spots) and start the process of moving away from NSS which
was discussed some year ago in an internal mailing list (for some
reason).
Will be happy to hear thoughts on this,
Standa
I'm not a big fan of NSS, it has it's issues. As the author of the
Python binding I'm quite aware of all the nasty behaviors NSS has and
needs to be worked around. I wouldn't be sad to see it go but OpenSSL
has it's own issues too. If you remove NSS you're also removing the
option to support smart cards, HSM's etc. Perhaps before removing
functionality it would be good to assess what the requirements are.
I'm sorry I generalized too much, the original topic was moving away
from python-nss (of which I am even more sorry as you're the author).
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
