[Freeipa-devel] [DESIGN] FreeIPA on FIPS + NSS question

Standa Laznicka slaznick at redhat.com
Mon Dec 19 15:41:16 UTC 2016


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




More information about the Freeipa-devel mailing list