LibreSSL: FIPS mode is not coming back

http://marc.info/?l=openbsd-misc&m=139819485423701&w=2

by zdw • 12 years ago

275 92 12 years ago

api• 12 years ago

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_olson2• 12 years ago

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

andrewvc• 12 years ago

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.

shawn-furyan2• 12 years ago

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 purveyors of bogus security is a public service.

danielweber2• 12 years ago

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.

ballard10• 12 years ago

Abrasiveness and being opinionated are mostly orthogonal.

I think this is more of a correct opinion (to reduce whale blubber) than intentionally pissing people off.

ef47d35620c12• 12 years ago

That's part of the culture. It's nothing personal. Don't take it to heart if what they say offends you.

Spooky232• 12 years ago

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.

antocv• 12 years ago

Its one thing to certify a doctor and another to certify software.

There are formal proofs for software. FIPS doesnt work with software, it takes 6 months just to pass the process??

What does FIPS mean if after the 6th month another heartbleed is found? FIPS remains but the product is useless.

danielweber2• 12 years ago

As they said, someone else is perfectly free (it's a BSD license) to use their work to build a libfips.

x0x0• 12 years ago

Nonsense.

What would you do if you where the NSA and you've now been repeatedly caught lying, bribing (RSA dual ec), and backdooring (dual ec) security software? At this point, you have a problem: working for the nsa probably taints you in the eyes of many, and nobody (rightly) trust you.

But what nation states do have is money and bribery. So you do two things: you attempt to subvert (oh, your brother got busted for dui? We know the judge and can make those charges go away or he can do a dime in state; feeling cooperative now?) developers, and you can do your best to make the code shit and as complex as possible in the hopes that if it's awful enough, somewhere in there is a security issue. Since you can afford to buy as many devs as needed, you can probably find them. I saw the phrase coined on here and unfortunately don't recall the source, but the future of backdoors is probably bugdoors. So Libressl -- rip out shit code, reduce complexity, remove unnecessary algorithms and implementations to further remove complexity -- is the necessary fix. Every option in a program increases net complexity, typically in a factorial manner, and complicates testing. What we need is simple, tested, secure code that handles the minimal use cases for web browsers and web servers. It doesn't need to support dead oses, dead compilers, or the government's wish list of complexity inducing certifications.

newman3142• 12 years ago

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

cptskippy• 12 years ago

They point they were making that wasn't clearly elaborated upon is that the code in OpenSSL for FIPS compliance is a charade and is only there to satisfy FIPS requirements. The presence of that code doesn't guarantee or ensure the anything.

These compliance standards generally exist to deflect liability in the event of a breech and aren't necessarily there to protect anything. Take PCI for example, much of the DSS requirements are verified by audit and if you've ever gone through the audit, it's mostly certification without verification. The auditor usually trusts that things like segmentation diagrams are accurate. There's a level of accountability but it's primarily about deflecting liability.

ballard10• 12 years ago

FIPS mode is like a clipboard audit. It appears to fulfill a requirement like A+ certifications do for hiring qualified candidates, but instead puts blind faith in process ahead of content.

forgottenpass• 12 years ago

The OpenBSD people sure are abrasive

I've said it before, all "opinionated software" is abrasive, the scale is really how much you notice it based on if you like the faces and decisions involved. It'd be non-controversial to the HN crowd, but there are plenty of developers are happy to trash any GPL/share-alike project on the same grounds.

ternaryoperator• 12 years ago

all "opinionated software" is abrasive

I don't know you, so this is not directed at you. However, this is the kind of line I hear from abrasive people defending their unwillingness to temper what they say.

It's perfectly possible to have opinionated software (take JUnit or TeX, for example) that simply performs its task in an opinionated way without its authors belittling competitors or being disrespectful to others whose work doesn't fulfill their view of how things should be.

personZ• 12 years ago

but they deserve a ton of praise for taking on a tough task that no one else was willing to do

There seemed to be some serious momentum behind getting proper resources and financing in place for a real effort that the project deserves, but all of that dissolved when this team started making a lot of sound and fury about their fork of something purportedly "beyond fixing".

Aside from several incidents of spite-driven commits that were simply wrong (and dangerous), it is unfortunate that so many people who worked so hard on such an important project are treated so poorly, everyone rushing to condemn the code as was.

dwc• 12 years ago

I tend to think the reason that support dissolved was that many people, myself included, think OpenBSD will do a better job of responsible maintenance. I have no good reason to think throwing money at OpenSSL would actually improve anything that matters. Much more likely we'd just get more of what we've been getting.

_pmf_• 12 years ago

"Fixing" it in a way that guarantees that the changes will not be pulled back into OpenSSL has the following problems:

* the fork will lag behind when new features are introduced into OpenSSL

* the fork will lag behind when new fixes for OpenSSL are implemented

This creates a permanent maintenance burden for the LibreSSL maintainers; sure they have attention now, but in 3 months nobody will give a shit any more.

rlpb• 12 years ago

Unless the rest of the world switches to using LibreSSL by default, (eg. for security reasons). Then the situation could reverse.

Given the state of the OpenSSL codebase, I think this has a greater chance of happening than most other forks.

_cipher_• 12 years ago

"Fixing" it in a way that guarantees that the changes will not be pulled back into OpenSSL has the following problems:
* the fork will lag behind when new features are introduced into OpenSSL
* the fork will lag behind when new fixes for OpenSSL are implemented
This creates a permanent maintenance burden for the LibreSSL maintainers; sure they have attention now, but in 3 months nobody will give a shit any more.

So, it's gonna be apache all over again. Where they maintained their own fork, with no security patches applied.

Or perhaps like OpenSSH, where a linux user is forced to `./configure && make && make install'.

I'm trusting your opinion, after careful reviewing of all your commits. :)

/irony off

ebiester• 12 years ago

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

endersshadow• 12 years ago

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

morrad3• 12 years ago

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.

tptacek2• 12 years ago

FIPS compliance includes support for dubious cryptography and protocol standards. While it doesn't necessitate things like Dual_EC and extended_random, it does create a hospitable environment for their inclusion.

"FIPS support" also demands configurations that rule out some cryptography, some of it bad, some of it reasonable. FIPS support doesn't require OpenSSL not to implement those algorithms, but it does require a mode of operation that does.

Against that complexity, the only win is the ability to deploy the FIPS-compliant code in FedGov settings, which is something that an OpenBSD fork of OpenSSL doesn't need to do to be successful.

niels_olson2• 12 years ago

Rather than explain (which I would fail at), let me cite the best sources I know of.

Here's the bug I submitted to the chromium project while I beta tested the Cr-48, requesting FIPS support. The closeout comments cite excellent sources. Interesting that this was done right about the time the Heartbleed bug was probably being found as well.

https://code.google.com/p/chromium/issues/detail?id=194867

gooseyard• 12 years ago

The tactic that the OpenSSL project took to get the FIPS 140-2 validation, but to avoid having to do it over again every time a new openssl release was issued, was to build all the parts of openssl that were audited into a single object (fipscanister.o) that is to be loaded at run time. It is stored at some location on the machine along with a fingerprint, and when one enables FIPS mode, fipscanister.o's fingerprint is confirmed, and then the object is loaded.

In practice, what this means is that you take one of the fips-openssl-x.y.z releases, and build fipscanister.o from it; that has the fundamental crypto bits in it, it's released as infrequently as possible. Then you build a plain old openssl-x.y.z release with a flag to enable the fips feature. At runtime when you enable FIPS mode, your local openssl library would switch to using crypto functions from fipscanister.o, which might be a year or two old. The idea is that the crypto bits don't generally change, although the rest of libssl/libcrypto might change several times during the year.

Anyway building and using openssl this way is a giant pain in the ass, especially if you statically link. To make matters even more confusing, Redhat took an altogether different tack, and have their own variant of openssl that, when FIPS mode is enabled, switches to using the Linux Kernel crypto functions, which they got independently NIST validated, so if you're deploying the RHEL machines in the .gov space, a different FIPS 140-2 validation applies to you.

It leads to a fair amount of crap in the configure scripts, and macros throughout the code.

SEJeff• 12 years ago

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.

protomyth3• 12 years ago

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

mburns2• 12 years ago

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

StavrosK• 12 years ago

Yes, and the way to fix FIPS is to refuse to support it until it gets fixed.

morrad3• 12 years ago

Good luck convincing your competitors to not take the business you're leaving on the table with that. :(

bradleyjg• 12 years ago

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• 12 years ago

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.

marcosdumay• 12 years ago

On the plus side, it'll be actually secure for all the other people that care more about a security lib being secure than by it havins a stamp.

That's also a huge number of people (and companies).

rst• 12 years ago

Not unless RedHat is willing to foot the bill for FIPS certification of a variant, or wait for someone else to do it. The LibreSSL folks have indicated that they won't stand in the way of anyone who wants to do that (in this very note!). It just won't be them.

BTW, even some core OpenSSL developers think that the FIPS validation process is worse than useless. Here's OpenSSL developer Steve Marquess arguing that a FIPS-validated version of something will generally be less secure than the non-validated version (citing, in particular, how delays and cost of recertification can prevent deployment of fixes for known bugs):

http://veridicalsystems.com/blog/secure-or-compliant-pick-on...

But OpenSSL, as an organization, has so far been willing to play along with the process anyway. The difference is that the LibreSSL folks have enough of the courage of their convictions that they are not playing along.

tssva• 12 years ago

Redhat already foots the bill for certification of the OpenSSL library they ship. They also foot the bill to have the versions of OpenSSH, dm-crypt, the kernel crypto api and libgcrypt certified.

X-Istence2• 12 years ago

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

ballard10• 12 years ago

Sounds good because it suggests sec industry disengagement. Probably simpler to do that and maintain it as a set of minimal patches to LibreSSL, because not many people need it. Either way, it should be secure by default.

ChuckMcM• 12 years ago

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

ballard10• 12 years ago

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

ticktocktick• 12 years ago

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

ausjke• 12 years ago

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.

guyinblackshirt• 12 years ago

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

sandGorgon• 12 years ago

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

ninjin• 12 years ago

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

atonse• 12 years ago

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

djcapelis• 12 years ago

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

gry3• 12 years ago

An unofficial mirror: https://github.com/libressl/libressl

ballard10• 12 years ago

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

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

metafunctor• 12 years ago

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.

bitwize• 12 years ago

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

ballard10• 12 years ago

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

ballard10• 12 years ago

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.

uuid_to_string• 12 years ago

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• 12 years ago

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

rubyfan• 12 years ago

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.

sjs382• 12 years ago

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

claps

LibreSSL: FIPS mode is not coming back

Related Stories