Live data from Hacker News

LibreSSL: FIPS mode is not coming back

marc.info

41–50 of 98 posts

Re: LibreSSL: FIPS mode is not coming back

#41
post #21
post #11

Earlier quoted context omitted.

My understanding is the FIPS requires that the SSL library implements a certain suite of protocols (including the Dual EC DRBG discussed in the linked mailing list post) which have known cryptographic weaknesses.

This is not true. FIPS requires that any 'approved' included crypto algorithm implementations are self-tested, and pass a verification program (just a big bunch of somewhat poorly conceived known answer tests). It also has a list of 'allowed' algorithms, which don't need to be tested but can be offered by a FIPS crypto module. The CSPRNG used for key generation must be of an approved construction, but there are a num…

A question if I may: Could you "accidentally" make a FIPS compliant library? Assuming that the LibreSSL fork where to include ONLY the FIPS approved ciphers and hashing algorithms, it should be possible to have a library that could be passed of a compliant.

If I understand you correctly, the issue with FIPS is that you would have to be able to disable all but a subset of the features, regardless of these feature being worse or better than what is defined in the FIPS documents?

That's a bit more that one question, but I would like to know. Thanks.

Re: LibreSSL: FIPS mode is not coming back

#42
post #21

Earlier quoted context omitted.

This is not true. FIPS requires that any 'approved' included crypto algorithm implementations are self-tested, and pass a verification program (just a big bunch of somewhat poorly conceived known answer tests). It also has a list of 'allowed' algorithms, which don't need to be tested but can be offered by a FIPS crypto module. The CSPRNG used for key generation must be of an approved construction, but there are a num…

A question if I may: Could you "accidentally" make a FIPS compliant library? Assuming that the LibreSSL fork where to include ONLY the FIPS approved ciphers and hashing algorithms, it should be possible to have a library that could be passed of a compliant. If I understand you correctly, the issue with FIPS is that you would have to be able to disable all but a subset of the features, regardless of these feature bein…

It is not just that the library can only contain those specific approved ciphers and hashing algorithms, they also have to be certified through a lab, then that lab has to sign off on it (this costs thousands of dollars). You have to build in a self-test system that verifies the integrity of the FIPS components using known answer tests, and the FIPS module itself has to be able to self-check itself against a known hash, so your linker has to be nice enough to put the FIPS module at a known location (making exploitation simpler).

The whole FIPS canister thing in OpenSSL is a HUGE pain in the behind when you are building a library/product using it, and overall doesn't increase security one single bit. Yes your crypto is now FIPS 140 certified, big whoop.

[Note: I am going off the OpenSSL FIPS canister implementation details here...]

Re: LibreSSL: FIPS mode is not coming back

#43
post #5

This basically means libressl can not be used by the US Govt or any contractor working with the US Govt, which is a HUGE number of companies. By proxy, it means that libressl will not make its way into Fedora or RHEL, which also limits the adoption of it a fair bit. Perhaps the solution is to fix FIPS instead of berating the people forced to use it.

US Govt or contractors can apply for a waiver that you can perpetually renew that will allow you to use non FIPS-140 certified cryptography in a product...

Re: LibreSSL: FIPS mode is not coming back

#44

Earlier quoted context omitted.

I've got to say that I like the abrasiveness. The security industry is rife with imposters and pretenders. All of the artifice and bogus claims make it very easy for people, organizations, industries... hell, governments to be misled into devoting huge amounts of resources into propping up what amounts to security theater, which is generally actively harmful. Abrasiveness and a willingness to ruffle the feathers of p…

There is hardly a shortage of abrasiveness in the security industry. That said, I find zero things wrong with OpenBSD's work to make LibreSSL. If anyone doesn't like it, I'll offer them their money back.

I don't think that the first statement is correct. OpenBSD is not nearly so visible as RSA, Norton, Verisign, et. al., and those brands are heavily invested in the theatrical aspects of security to the point of emphasizing appearances over actual security.

The part of the industry that is visible to the general public, and even probably most of the technical community are brands such as those, and you can't trust them. What BSD is doing here is saying, "You know that thing that all of those brands told you [and industry, and the government] is important? It doesn't improve security at all, and so we're going to ridicule the practice so that maybe it will get a stink that travels beyond our tiny realm of influence."

That's more valuable than politeness, because politeness doesn't create a stink, and OpenBSD is not well enough known to effect change without making a stink.

Addendum: To summarize my view of the situation, I think that the reason that a lot of the people that we think of as "good" security people are abrasive is that it's sooo much easier and more profitable to promise security than it is to deliver it. This means that the security industry is overflowing with bullshit and bad information. Since there's so much bullshit, the "good" security people have to be very quick, curt, and categorical about labeling the bullshit since most of us are almost completely incapable of distinguishing bullshit from delicious, nutritious food, and so are all too willing to lap it up. [sorry for the grossness, but I think that this must be what the situation feels like to "good" security people]

[Edit 2:31 PM CDT to add Addendum]

[Edited 2:45 PM CDT for clarity]

Re: LibreSSL: FIPS mode is not coming back

#45
post #3

The OpenBSD people sure are abrasive, but they deserve a ton of praise for taking on a tough task that no one else was willing to do, and for fixing the damn mess. Between FIPS, the NIST and the OpenSSL foundation it's amazing that crypto even works.

This stance is counterproductive in my eyes. Lots of security standards, including state/local government and some healthcare environments require FIPS compliance. FIPS isn't perfect, but screens out low-quality crypto implementations that most organizations lack the expertise to evaluate. Dual_EC and that ilk is obviously a serious problem, but FIPS validation addresses other pertinent problems -- like my doctor's o…

Compliance is needed just so that you can get it checked off on a list. It does not necessarily mean that you are safer. It could mean better safety but does not guarantee it.

What it does provide is that in the wake of an incident, the ability to say: "Hey! But I was PCI, FIPS, HIPAA, FedRamp etc. compliant!"

Re: LibreSSL: FIPS mode is not coming back

#46
post #5

This basically means libressl can not be used by the US Govt or any contractor working with the US Govt, which is a HUGE number of companies. By proxy, it means that libressl will not make its way into Fedora or RHEL, which also limits the adoption of it a fair bit. Perhaps the solution is to fix FIPS instead of berating the people forced to use it.

I'm sure Red Hat has the money to pay someone to implement FIPS for their port.

I'm sure they do, too. It isn't that simple.

Re: LibreSSL: FIPS mode is not coming back

#47
Just looking at the wholesale cleanup [1] makes me shudder to think about how tough the code was to maintain in the past.

Kudos to the libssl team for injecting some much-needed energy into such a critical library.

If only this were available on GitHub, we could more easily browse the code and learn about patterns and anti-patterns in writing secure code.

[1] http://freshbsd.org/search?project=openbsd&q=file.name:libss...

Re: LibreSSL: FIPS mode is not coming back

#48

Earlier quoted context omitted.

There is hardly a shortage of abrasiveness in the security industry. That said, I find zero things wrong with OpenBSD's work to make LibreSSL. If anyone doesn't like it, I'll offer them their money back.

"Fortunately" (and I don't mean to encourage it), the abrasive people in the crypto community are like that when they tend to be right - and don't want "newbies" to do stupid dangerous mistakes, so their tone comes out a little aggressive by default. But yeah, it could be improved. The community should work together on solving issues the right way.

Fortunately or unfortunately, there are also a reasonable number of abrasive people who tend not to be right, so I'm not sure it's a good marker either way. There's a whole rock-star persona around people who make consulting careers out of trying to position themselves as security badasses, and not all of them are.

Re: LibreSSL: FIPS mode is not coming back

#49
post #47

Just looking at the wholesale cleanup [1] makes me shudder to think about how tough the code was to maintain in the past. Kudos to the libssl team for injecting some much-needed energy into such a critical library. If only this were available on GitHub, we could more easily browse the code and learn about patterns and anti-patterns in writing secure code. [1] http://freshbsd.org/search?project=openbsd&q=file.name:lib…

If you want it on GitHub, put it on GitHub. Put it where you'd like.

Re: LibreSSL: FIPS mode is not coming back

#50
post #46

Earlier quoted context omitted.

I'm sure Red Hat has the money to pay someone to implement FIPS for their port.

I'm sure they do, too. It isn't that simple.

What isn't simple about Red Hat paying a third-party to write some software and get it certified? Other companies are doing it for themselves, surely Red Hat can find someone qualified.
Post reply on HN