LibreSSL: FIPS mode is not coming back
marc.info
marc.info
Between FIPS, the NIST and the OpenSSL foundation it's amazing that crypto even works.
Abrasiveness and a willingness to ruffle the feathers of purveyors of bogus security is a public service.
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.
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]
I think appearance over function is true ever since politics and advertising were invented.
Leads to a lot of facepalming when you are actually trying to get something done.
Security projects need adversarial discussions to keep them honest, but that's a special case.
I think this is more of a correct opinion (to reduce whale blubber) than intentionally pissing people off.
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'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.
* 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.
Given the state of the OpenSSL codebase, I think this has a greater chance of happening than most other forks.
> * 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
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".
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!"
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
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.
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.
Deleted comment
http://www.tedunangst.com/flak/post/analysis-of-openssl-free...
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 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.
On the other hand, you can't change the source without losing the certification, so it doesn't actually matter.
This is why you might have to use old versions of OpenSSL for FIPS compliance - not all versions might be certified.
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.
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.
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? :)
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.
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...]
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.
Donate here - http://www.openbsdfoundation.org/donations.html
If you, like me, want to use a credit card but live somewhere where PayPal blocks donations (Japan in my case).
Perhaps the solution is to fix FIPS instead of berating the people forced to use it.
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.
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.
That's also a huge number of people (and companies).
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.
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.
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.
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.
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://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-src/tree/lib/l...
"When I grow up..." Tandem multiplication commit is hilarious.
Please elaborate where the official git sources are.
https://github.com/LibreSSL-Portable/libressl-portable/blob/...
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.
You can make software more valuable by taking things out.
https://plus.google.com/110587864313334050808/posts/R8fkf1A4...
claps