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.
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.
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]
> 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.
I think appearance over function is true ever since politics and advertising were invented.
"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.
The problem is that being abrasive without displaying a clear, correct opinion won't lead to greater influence. The latter stance is the important bit.
Security projects need adversarial discussions to keep them honest, but that's a special case.
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.
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.
"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.
> "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. :)
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.
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.
FIPS validation means that you're using a reasonable set of algorithms. Like any standard they are imperfect and their development lags the state of the art in some cases. In my daily business, I worry more about casual incompetence, as it has a more direct affect on my boring daily life.
Re: Your rant about the NSA bribing people, etc.
Why do you magically trust OpenBSD? Much of the projects early funding was via DARPA. Whose to say the project leaders aren't NSA plants?
It isn't magical. I've spoken to many of them. I've seen the work they've done over the last 15 years. They earned my trust.
>Much of the projects early funding was via DARPA
No, a relatively small amount was via DARPA, and that funding was pulled due to Theo criticizing the US government. And that was not early in the project, it was like 8 years into the project's life. Doesn't really scream "NSA plants".
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!"
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
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.
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.
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.
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.
I know you're trolling, but some people might not, so I thought it might be helpful to point out that they are actually discovering and fixing vulnerabilities. For example, CVE-2010-5298:
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.
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).
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.
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.
I think the GP is talking about a trusting trust attack on OpenSSL: Change the compiler to compile OpenSSL differently, rather than change the source itself.
I guess it begs the question (FIPS mode seems to fail the "talk to a cryptographer rule"): why don't/aren't sec folks more involved to assure standards are meaningful? Was this a NIST-driven process or was it open to public comments?
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.
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.
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.
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? :)
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.
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...]
> Could you "accidentally" make a FIPS compliant library?
Let's differentiate between "FIPS compliant" and "FIPS certified".
FIPS complaint: you could get a FIPS certified product if you wanted, without changing your product.
FIPS certified: you paid NIST and a FIPS test lab some money, the lab tested your module, submitted a test report to NIST, and NIST published certificates saying that a certain version of your product (running on a particular OS and CPU architecture, for software modules) is FIPS certified.
So, yes, you could accidentally come up with a FIPS compliant crypto module. But getting certified costs actual money (last time I did it, as I recall just shy of $100k).
> 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?
To some extent it depends what you mean by 'feature' here. If it's a crypto algorithm offered by your module for external use, there is quite little leeway. If it's a fundamental feature of your product that internally uses exotic crypto, you can often convince your test lab to gloss over it.
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.
Worse than that, AFAIK, the cheapest way to keep up FIPS certification is essentially to change nothing (except as FIPS requirements change, which is "not really often").
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 :-)
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.
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 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.
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.
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):
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.
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.
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.
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...
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.
Just "write some software and get it certified"? Sounds so simple, why doesn't everyone do it?
Because it isn't just getting a body of code certified once.
Someone has to maintain that specific code and either upstream or backport important changes which require a re-certification, neither of which LibreSSL is interested in helping with.
Once LibreSSL has reached a point of minimal disruptive change, FIPS support could be re-implemented as a series of third-party patches, which could then be certified as needed.
For example, create a fipssl project which is patches to a specific version of LibreSSL; take the result (LibreSSL v1.x + fipssl v1.2 = libfipssl v1.2) and then get that certified. Companies/contractors which need FIPS certification then use libfipssl v1.2.
The fipssl maintainers then just have to track LibreSSL changes until their next release, which (for a series of small, maintainable patches) shouldn't be too difficult. The grsecurity project has been doing the same thing with the Linux kernel for years.
Well, need & money, both of which Red Hat has. I am unclear how a company that maintains an enterprise distribution and writes a lot of code cannot find the folks needed to do FIPS if it is that important for their government contracts.
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.
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.
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.
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!"
Between FIPS, the NIST and the OpenSSL foundation it's amazing that crypto even works.