Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LibreSSL: FIPS mode is not coming back

marc.info

Post reply on HN
Print view View original

31–40 of 98 posts

Re: LibreSSL: FIPS mode is not coming back

#31

Post by sanxiyn »

ef47d35620c1 wrote: post #24
tptacek wrote: post #12

Earlier quoted context omitted.

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…

Also, I believe that only binaries can be FIPS certified, not source code, so there are times when one has to use an old, out-dated openssl binary in order to be compliant.

OpenSSL FIPS certification (#1747) is for source code, not for binary. This is highly unusual indeed, but it is not the case that only binaries can be FIPS certified.

On the other hand, you can't change the source without losing the certification, so it doesn't actually matter.

Re: LibreSSL: FIPS mode is not coming back

#32

Post by morrad »

ctz wrote: post #21
morrad wrote: 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…

Thanks for the correction. I'm on the hardware side of things, so my understanding was that the "allowed" algorithms were actually required, and I'm relieved to hear that's not the case.

Re: LibreSSL: FIPS mode is not coming back

#33

Post by forgottenpass »

andrewvc wrote: 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.

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.

Re: LibreSSL: FIPS mode is not coming back

#34

Post by antocv »

Spooky23 wrote: post #29
andrewvc wrote: 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…

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.

Re: LibreSSL: FIPS mode is not coming back

#35

Post by 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

Re: LibreSSL: FIPS mode is not coming back

#36

Post by [deleted] »

ef47d35620c1 wrote: post #22
andrewvc wrote: 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.

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

[deleted]

Re: LibreSSL: FIPS mode is not coming back

#37

Post by higherpurpose »

danielweber wrote: post #27
shawn-furyan wrote: post #20

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.

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

Re: LibreSSL: FIPS mode is not coming back

#38

Post by danielweber »

Spooky23 wrote: post #29
andrewvc wrote: 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…

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

Re: LibreSSL: FIPS mode is not coming back

#39

Post by x0x0 »

Spooky23 wrote: post #29
andrewvc wrote: 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…

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.

Re: LibreSSL: FIPS mode is not coming back

#40

Post by rst »

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

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.

Post reply on HN