Hacker News Reader

Comment by noahkunin | Hacker News Reader

18Fer here. Before I answer in greater detail, why do you think FIPS requires RHEL with mod_nss only? I don't see why an OpenSSL in FIPS mode wouldn't fit the bill too.

View on HN

Regardless of your detailed answer, FIPS crypto requirements are a topic of some amusement in professional cryptographic and security circles, and anything you do to push back on them will be a help basically to humanity.

I am in 100% agreement with you, FIPS is bonkers.

Nuke it from orbit. It's the only way to be sure. :)

https://access.redhat.com/solutions/95213

Dated May 28, 2014

If you don't have an account:

"So at this moment we cannot say whether mod_ssl is going to be a valid crypto module in FIPS mode under RHEL-6 although this is the intent."

That may have changed, and contradict other sources on redhat.com. There are a lot more KB articles on FIPS since the last time I really dug into it over a year ago.

Edit, yes, it looks like it was mod_nss only until the release of RHEL 5.9 last Jan. RHEL-6 was ongoing, but it looks like they claim mod_ssl will work now in other places in the knowledge-base.

You can't even use FIPS in Ubuntu/Debian at all: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/95001

FIPS is just one area where it seems like there's a lot of contradictory information for federal IT. After doing the FedRAMP dance, and reading things to the letter, we stopped working towards it and partnered with one of the vendors that got it first. Their remote access was plain text VNC, 8 character password max. I would say I was surprised the paperwork matters more than real security, but I wasn't.

So your post makes no sense. OpenSSL provides the FIPS portion directly. You can just download and compile it according to the instructions and you are now FIPS compliant just awaiting a certification. You can do this yourself, you don't need RedHat or Debian to do it for you.

This is one of the problems with Government and hopefully something that will change. All that is done is piece together bits of what outside vendors have put together and the piecing together is normally done by contractors.

So you think recompiling OpenSSL from scratch, in doing so, deviating from the upstream vendor's supported binaries, and the dependency problems with updates it will cause, just to support a mostly smoke and mirrors standard is a good idea? I'd don't really think that's a best practice in commercial or government IT.

Exactly what the American people have come to expect from the government. Unless its been gift wrapped by a contractor they lack any ability to do anything technical.

You make a RPM and you deploy it like you would any other package. Yes it is a best practice, in fact the people at Red Hat do the _exact_ same thing, the difference is they have the technical capability to make those kinds of changes, as do most people in the commercial IT sector. The government is the one place where they call it IT when its really just glorified procurement.

However thats not even the problem as you stated its supported just fine. It has been for almost 9 years. The bigger issue is there was a perception is wasn't and instead of working to see what reality was people just did nothing.

> Exactly what the American people have come to expect from the government. Unless its been gift wrapped by a contractor they lack any ability to do anything technical.

Exactly the expectations that 18F would like to change.

"just awaiting a certification."

You say that as if the certification part itself is remotely quick, predictable, or easy.

Reply on news.ycombinator.com