
LibreSSL: FIPS mode is not coming back - zdw
http://marc.info/?l=openbsd-misc&m=139819485423701&w=2
======
andrewvc
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.

~~~
Spooky23
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 office securing my
private data with a more trivially flawed/bogus encryption implementation.

~~~
newman314
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!"

~~~
dfc
It Provides: _significant mitigation of civil liability_

I realize it does not mesh well with the narrative you are trying to advance
but take a look at the difference in HIPAA fines for an
individual/organization that demonstrated reasonable diligence and another
that willfully neglected HIPAA:

    
    
                            Per violation  Annual Maximum
      Reasonable Diligence  $100           $25,000
      Willful Neglect       $50,000        $1,500,000
    

[http://www.ama-assn.org//ama/pub/physician-
resources/solutio...](http://www.ama-assn.org//ama/pub/physician-
resources/solutions-managing-your-practice/coding-billing-
insurance/hipaahealth-insurance-portability-accountability-act/hipaa-
violations-enforcement.page)

------
api
I did some consulting once for a government lab. FIPS is idiotic. It's
primarily protectionism for commercial software vendors from OSS competition,
and it does not improve security. If anything it hurts-- it mandates closed-
source options that cannot easily be audited, and it slows down the upgrade
cycle thus preventing bugs that emerge from being quickly patched.

~~~
niels_olson
> It's primarily protectionism

This. It's also protectionism for government IA managers. And it stymies the
hell out of anyone trying to do research on a budget, which often depends on
open source (for both review, quality and cost reasons).

------
ebiester
For those who don't know what FIPS mode is (like me):
[https://developer.mozilla.org/en-
US/docs/Mozilla/Projects/NS...](https://developer.mozilla.org/en-
US/docs/Mozilla/Projects/NSS/FIPS_Mode_-_an_explanation)

~~~
endersshadow
Thank you for the primer. Can anybody comment as to why FIPS mode in OpenSSL
is considered harmful?

~~~
morrad
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.

~~~
ctz
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 number of choices ranging from stupid shit nobody sane would
choose (Dual EC DRBG) to ones which are trivial variations on hashes, HMAC or
block ciphers in OFB or CTR mode. Sadly, it says nothing about the quality or
construction of actual entropy sources.

Naturally, everything not 'approved' or 'allowed' cannot be offered by a FIPS
crypto module.

On the plus side, this means vendors can't offer proprietary stupid-shit like
LFSR stream ciphers. Unfortunately, the approved and allowed list rarely keeps
up with good quality or fixed crypto (you'll not find any eSTREAM finalists,
or EdDSA, or deterministic DSA, or curve25519 ECDH, for example).

Also, the rules are pretty poorly enforced: you'll still find new FIPS
certificates issued for boxes which do TLS < 1.2. This is a lie: MD5 is not
allowed or approved, and is a fundamental (if conservatively used) part of the
protocol in those versions.

Source: I used to make FIPS-approved HSMs. AMA? :)

~~~
mrweasel
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.

~~~
X-Istence
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...]

------
ChuckMcM
Its a reasonable stance, I expect someone will create libfipsssl for the
reason that they can charge money for it. For a while at Sun I suggested that
we meet the "OSI Network Standards" requirement by just sending a library with
stubs that would close out the link, and if they ever got called email us. The
humor didn't seem to reasonate with the Federal Systems people :-)

~~~
ballard
Definitely. It'll be expensive commercial open source w/ a subscription and
delayed to pass FIPS. And LibreSSL will still be more secure.

------
sandGorgon
_If people really need FIPS mode, somebody will fork again and create
libfipssl.com and charge a million bucks for it. And then the ones who need
FIPS mode can pay to get it, but they won 't pay us. The OpenBSD Foundation
will gladly take donations to improve libressl, but some money is just too
expensive to accept. Sitting on (or more accurately, under) a million dollars
in custom contracts creates what I will charitably call a priority inversion._

Donate here -
[http://www.openbsdfoundation.org/donations.html](http://www.openbsdfoundation.org/donations.html)

~~~
ninjin
Or here - [https://https.openbsd.org/cgi-
bin/donations](https://https.openbsd.org/cgi-bin/donations)

If you, like me, want to use a credit card but live somewhere where PayPal
blocks donations (Japan in my case).

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

~~~
bradleyjg
I don't think lobbying the US Federal government is in OpenBSD developers'
wheelhouse. Contractors working with the US government on the other hand have
a long, distinguished history of successfully doing just that. In fact, that's
largely the entire business model.

So it makes a lot of sense for each party to do what they are good at: OpenBSD
developers write a clean, secure library, and contractors lobby to be allowed
to use it.

~~~
mpyne
I think OpenBSD has actually done contracted work for various U.S. government
agencies. But on the other hand, I'm pretty sure that's the reason they've
already ripped FIPS out and washed their hands of it... working on government
projects is not fun and it's exactly the kind of thing they should outsource
if they can.

------
metafunctor
Great call.

Having personally been through the toils of FIPS certifying crypto libraries,
I smiled and nodded as I read this post.

FIPS is about compliance, not about security. LibreSSL is about security, full
stop.

------
ballard
This is great news.

FIPS mode is as my grandfather would say: "eyewash." Something that appears to
address something by checking boxes on a clipboard audit but doesn't provide
anything but security theater.

------
atonse
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...](http://freshbsd.org/search?project=openbsd&q=file.name:libssl)

~~~
gry
An unofficial mirror:
[https://github.com/libressl/libressl](https://github.com/libressl/libressl)

~~~
ballard
This is a dupe because it's already synced to git mirrors of openbsd sources.

[http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-
src/tree/lib/l...](http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-
src/tree/lib/libssl)

"When I grow up..." Tandem multiplication commit is hilarious.

~~~
gry
That's the beautiful thing about DVCS, no?

Please elaborate where the official git sources are.

~~~
midas007
There is none, OpenBSD uses CVS.

~~~
gry
Such is ilfe.

~~~
midas007
No problem, I wrote a script to fetch it for those uncomfortable with CVS.

[https://github.com/LibreSSL-Portable/libressl-
portable/blob/...](https://github.com/LibreSSL-Portable/libressl-
portable/blob/master/scripts/libressl.fetch)

------
rubyfan
OpenBSD lives their mantra and are unafraid of what the internet comment
boards have to say about it.

They do what they feel is right and believe others are free to benefit from it
or go make your own. The world needs more of this not less.

What the world needs less of is people with opinions and inability or
unwillingness to take action other than complain about the actions of others.

------
uuid_to_string
OpenBSD has to be commended for executing on a simple idea that sadly few
developers ever adopt:

You can make software more valuable by taking things out.

------
CopperWing
OpenSSL package maintainer for SUSE says openSUSE/SLES will stay with OpenSSL
(plus handpicked commits from LibreSSL repo), because of missing FIPS and
other questionable commits in LibreSSL.

[https://plus.google.com/110587864313334050808/posts/R8fkf1A4...](https://plus.google.com/110587864313334050808/posts/R8fkf1A4Md3)

------
ballard
FIPS mode is as my grandfather would say: "eyewash." Something that appears to
address something by doesn't. (FIPS mode is a "clipboard audit.")

------
ausjke
working on a FIPS embedded network product right at the moment, gosh it's a
maze to get even started, I'm still going to use the now patched openssl for
this, as really, the alternatives are not many, and openssl remains to be the
most deployed one in the field. checked NSS but its usage in embedded device
is rare, other ssls(ploarssl, matrixssl) may work, but again openssl just wins
on the popularity side, in a huge way.

------
sjs382
>OpenBSD Foundation will gladly take donations to improve libressl, but some
money is just too expensive to accept.

 _claps_

------
ticktocktick
So it will be consistent with OpenSSH, also a project of OpenBSD devs.

------
guyinblackshirt
that makes sense. probably FIPS-certified firewall vendors such as sonicwall
will be the ones affected by this.

------
bitwize
Lol, if WorldTechTribune were still around the headlines would write
themselves. "Windows contains military-grade encryption certified by the U.S.
government. Linux no longer does. Don't be fooled by the communist Al-Qaeda
sympathizers in open-SORES development! Windows is more secure!"

