Ask HN: Negative OpenSSL sentiments
Mistakes were made in code and processes, mistakes will continue to be made in code. What we need is: * A formal code review tool. I don't know whether there's something like review-board for OpenSSL commits. * Donations to the OpenSSL foundation. C'mon folks, practically all your online security depends on OpenSSL (Cisco, Juniper, Extreme, Huawei, Google, Yahoo, Wikipedia: I am looking at you). A bit of money back to OpenSSL (and OpenSSH + friends) would go a long way. Personally, I think these tools ought to be getting way more than Wikimedia (Just my two cents) * More eyes on the code. Whether it's refactoring the code, formal code audits or full time employees from the fortune 500 companies. * You to commit. This is an open project. 20/20 retrospective bashing does no one favours[1]. If you really feel strongly about something, get a patch out then start yammering about it. * A security mailing list. Something similar to xen-security-announce. That way, major vendors, cloud providers, OS & distributions can get fixes baked by the time the general alarm is sent.
1.http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
51 comments
[ 5.1 ms ] story [ 135 ms ] threadIt's pointless for Google, Yahoo et al, to enable inter-datacenter encryption if the front-end (TLS/SSL) is left wide open.
Companies are wasting bucks left and right on stupid shit lie oracle or microsoft licenses when free software and gratis versions exist.
Its a problem in structure and values of society. Had all enterprises valued freedom the entire society and each company would be better off. But no.
One large company I know has a technical review system which we use frequently to root cause failure and more importantly to update systems and workflows that will avoid the cockup being discussed in future. Blaming a team or oneself is not entertained (we don't care about the who), the important question is why and what can we do to fix it.
In my opinion, I think the OpenSSL team should come up with such a document and a list of corrective countermeasures.
There will always be bugs, sure, but differences in the engineering approach can result in orders-of-magnitude differences in the frequency of bugs.
For example, see "Some thoughts on security after ten years of qmail 1.0," where the qmail author explained why he thought qmail had a dramatically different security track record than sendmail: http://cr.yp.to/qmail/qmailsec-20071101.pdf
The kind of things he's talking about can't just happen on the level of "more people submitting patches" and "more financial contributions." You need a top-down approach that's designed to produce secure code.
It was a stupid, "really? again?" type bug that is typical of low-level badly written C programs and a common cause of security vulnerabilities.
Have you contributed (money, code, docs) to the project?
If the answer is no: person lacking skin in the game - irrelevant (even harmful) armchair comment.
Bad software is bad software regardless of who has funded it, who has committed code to it, or who has written its documentation.
One does not have to be a contributor to that software in order to analyze it and make a judgment regarding its quality.
Analyzing something and making a judgment is fine. But what happens after you do that? If you just file it away, fine. But if you go out and publicly bash somebody with little thought for the circumstances, it makes you look like an asshole, and it is generally, as Oskarth says, and irrelevant and possibly harmful comment.
Open source software is a gift to the world. If somebody does a lot of work to give you something and the first thing out of your mouth is, "This sucks! What's wrong with you for giving me an imperfect gift?" then it comes across as ungrateful. Because it is. Worse, it makes the gift-giver less likely to keep giving.
If you want to offer feedback to an open-source project, first ask yourself, "Am I telling them anything they don't know?" If you think you are, then offer it in a spirit of gratitude and constructive criticism. And think hard about going beyond offering opinions to offering money or labor.
One can say 'this code is terrible' without also saying 'How idiotic was the committer'.
(Deliberately invoking Godwin, because that's the level of logic I'm responding to :P )
* Initialization is even more complicated than the security needs dictate, and so is everything afterward.
* The internal abstractions are leaky, e.g. requiring a poll for read before you can write (and vice versa), because of the way handshakes are implemented.
* The normal error reporting is awful, so you must add extra code to get useful information.
* The documentation is terrible. It's hard to find what you need to know just to write your code, then hard to find information about the "idiosyncratic" command-line tools to test it. Want to know if your certificate code actually works? Have fun fighting theirs to find out.
A lot of people have felt forced to use OpenSSL because it was the de facto standard, or because NSS and GnuTLS were even worse (especially in terms of documentation). That leads to resentment, which has been just waiting for an outlet like this. I'm not saying it's right. I completely empathize with the plight of an under-resourced development team who could use some more help in some difficult areas. All I'm saying is that it's understandable.
A lot of what makes OpenSSL complicated is that it covers almost every crypto/algo/protocol permutation (there are lots) and it is heavily tuned to run fast on a variety of hardware.
I like PolarSSL as an alternative. It is just a collection of libraries. When I just need SHA256, I can just compile, link and use SHA256. No book-keeping, no boilerplate.
But it's not as wide-ranging or optimised.
And all the people who favor bsd style license instead.
Weve seen it before, a license which appeals to those who would benefit from it but not required to provide something back to the community - such projects fare worse in the long term than GPL or GNU projects.
I think this mentality also explains why people hate on openssl - they expect something for nothing.
Its 2014 we should know better than to trust corporations will do the right thing and require any modifications be released back to community. They wont and they dont.
However, for practical use everything else seems to be worse (with the possible exception of PolarSSL, which is sadly probably screwed politically by its licensing).
So, yeah, it's software, and therefore hateful. And I'm infinitely grateful to the developers anyway because, well, it exists, and damned if I have the time, motivation or competency to do any better.
The asshattery is, I agree, understandable. But it's still asshattery.
Why not give the software away as is current practice but then charge top-dollar to MSFT, Google, et al. for professional consulting? This way they could actually devote real resources to the project and implement some of the obvious process reforms that OP and others are suggesting.
The OpenSSL mission could & would be executed better if it was pursued as a business rather than a hobby. Capitalism doesn't cure all ills, but it might be able to cure this one.
Thoughts? Am I missing something?
I'm not sure OpenSSL is really a good match for that. I've never really studied this, but my impression is that open-source companies fall into two categories:
1) Very small consulting companies built around one or a few passionate people that scrape by rounding up contracts for specific features that businesses want, and
2) Larger companies that provide a substantial set of services around an open-source product (e.g., Chef, Puppet, RedHat, Ubuntu).
OpenSSL definitely doesn't match the latter, and I don't think it's great for the former. Having done consulting for years at a time, it's a giant pain in the ass. There's no reason to think people who are good at this sort of coding really want to spend half their time on sales, or would be good at it if they did. And adding features to OpenSSL is exactly what got us into this trouble.
This strikes me as the classic case for a tax: benefits are modest but spread widely. If you could painlessly charge each user $0.01/year, you could fund this work no problem. That leads you into all the issues you get with taxes, of course, but in this case I don't think they're obviously larger than the issues you get with capitalism.
It's a shame that the US Government has totally burned their reputation with security-minded techies, or they'd be an obvious way to collect and distribute, say, $100m/year for valuable internet infrastructure. Maybe this is a chance for Europe to step up.
They already have tons of money thrown at them from taxes.
Its just that surveillence and monitoring of citizens and industrial espionage has higher priority than...their stated goal? Theyre too busy analysing malware and making their own, exploiting openssl for their benefit while keeping and hoping none othet agency knows their exploits.
1: https://www.openssl.org/support/acknowledgments.html
Someone else made the comment that security can't be an afterthought, so PHP will probably never be auditable, and most people agree it should be dropped in favor of more robust technologies anyway.
But there are also people who have been annoyed with OpenSSL's needless complexity for many years. And they are speaking out too.
https://twitter.com/OpenSSLFact
The question is: Who are the ones more likely to drive us to a better solution than the status quo?
As other commenters have stated, the OpenSSL Project is not the only way to implement SSL. There are other open projects, though do not call themselves "OpenSSL".
I would imagine there is tremendous power over some peoples' minds when a project has the name "Open" and at least a small bit of history. They will defend it fervently without caring much about the code itself.
The OpenSSL Project's code is awful if for no other reason than it is far too complex to use, let alone when security is a requirement.
You can shift the focus to the programming language used or to "lack of funding" or whatever else you can conjure up, but the fact remains: OpenSSL's code is a mess.
Other SSL projects have implemented SSL in much simpler and smaller code. It makes one wonder how OpenSSL maintains its position as the default and we continue to accept the problems it creates.
Maybe because of attitudes like yours: "How dare anyone offer any critique on OpenSSL."
But bad code is bad code is bad code. And it doesn't take too much investigation of OpenSSL to realize it's not good code. To date the inertia of network effects has outweighed the badness of OpenSSL. Hopefully the Heartbleed fall-out will disrupt those network effects and get end-user developers to explore other implementations or spur renewed investment in improving OpenSSL. But it would be folly to continue on with the status quo.
The Spolsky argument is that you should never throw working code away. Part of the reason for doing so is that you will have subtle business logic embedded in the old code. However, in the case of SSL, there's a specified protocol. So, if there's a codebase to be rewritten from scratch, it's one that's an implementation of a spec.
That being said, I too get annoyed at a few misguided POVs:
1) "Open source sucks!" - This bug would probably never been found, and even less likely would it have been fixed had OpenSSL been closed source.
2) "C sucks!" - OpenSSL would not be so widely used if it was written in another less portable, less efficient language, and besides, bad code can be written in any language.
http://nacl.cr.yp.to/
It's been packaged up as libsodium:
https://github.com/jedisct1/libsodium
That said, even DJB doesn't trust himself to write bug-free C code:
http://cr.yp.to/qmail/qmailsec-20071101.pdf
None of the stuff you mention. Openssl is not in need of funding, or more eyes. Even the developers say more money won't fix it. Openssl is broken. It is so far gone that it is not salvageable. It needs replaced, not funded.
Right now we are almost at that state. It is honestly nearly that bad. Having a false sense of security can easily be worse than having no security at all.
Whenever something needs fixing in TLS we always hear about the OpenSSL patch first, so it seems like the project is healthy. I think this (and some of the context around the Debian incident) points out that we should be looking at replacements focused on implementation safety (bluishcoder's ATS-based demonstration looks like the right direction), good defaults, and a simpler API (one that also doesn't give so much leeway to shoot oneself in the foot through configurability).