Ask HN: Negative OpenSSL sentiments

I've tried not to be too critical of the developers, but I do understand where some of the negativity comes from. Have you ever tried to use OpenSSL, as a developer? It's kind of a crufty mess.

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

OpenSSL is less like a library, and more like a framework. You need to mesh your code to it pretty closely to get anything done. All you want is a SHA256? Too bad, here's a dozen things you need to do first.

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.

PolarSSLs biggest problem seems to be GPL.

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.

OpenSSL is one of those codebases that isn't so much measured in WTFs per minute as minutes to CANNOT UNSEE.

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.

Isn't documentation something that can be fixed by people as they use OpenSSL?

Documentation is in some ways harder to fix than code; you can fix what the code does, but documenting the intent can only be done by the author or someone involved in the original design.

If anything I'm pissed at large companies relying on a piece of software that's barely funded.

Especially large networking gear whose business is dependent on it. I am less pissed at a website using OpenSSL. Funding from the hardware companies would probably have prevented this issue.

GPL with a commercial license solves this. Even a not for gratis version of GPL would do.

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.

I'm with you when you say the hate on the developers (especially voluntary devs) is completely undeserved. What really baffles me about the whole debacle is how it's possible that software so widely used and of this importance is left mostly in the few hands of people who want to contribute. I get it that crypto is hard as hell and especially SSL/TLS requires skilled workers, but what I can't understand is why in all these years nobody stepped up and tried to start a collective effort to either fork the project and start a sweeping refactoring or start a completely new project with better foundations. You may argue that it's grunt work and nobody wants to do it, but if your company relies on this sensitive software is in your interest to put money on the table and pay people to do this kind of work.

It sounds to me like the way to solve this problem is to turn OpenSSL into a benevolent for profit company with an actual business model.

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?

Not sure why you're getting downvoted; it's a legitimate question.

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.

EU and most its memeber states intelligence agencies mission is to secure national infrastructure. Oh like the internet.

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.

I think the saddest thing is how incredibly short the list of OpenSSL sponsors is.[1] Every major internet company should be on there—throwing thousands of dollars at this is far less than they lose from responding to the vulnerabilities. As a critical piece of internet infrastructure, everyone with a large (monetary) stake in the integrity of that infrastructure should chip in some.

1: https://www.openssl.org/support/acknowledgments.html

Absolutely. I was really surprised to hear this. I'm sadly getting the impression that the only large entities who have thrown funding into audits are the intelligence agencies.

What we need is to not add fucking stupid features to TLS. TLS did not need an MTU discovery mechanism or keepalive; TCP already does both.

Wasn't the feature created so that it would be compatible with UDP as well?

Critical sentiments can be useful when they are of the form: “X didn't work, we moved to Y because blah blah and we did it by yada yada”.

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

"Hardware donations do not come from vendors who use OpenSSH on parts of their stuff. They come from individuals. The hardware vendors who use OpenSSH on all of their products have given us a total of one laptop since we developed OpenSSH five years ago. And asking them for that laptop took a year. That was IBM." - http://www.theage.com.au/articles/2004/10/07/1097089476287.h...

Crypto is complicated and very hard to do well. Hell, any complex software is hard to do well. There will always, always be bugs. While I am pissed off with so much moaning, and do agree they should be better funded, I think it is more the case of sensationalist blogging taking control of the narrative. Rather than "Booo OpenSSL" we should focus on recovering and raising awareness of the projects we all rely on every day.

> Crypto is complicated and very hard to do well. Hell, any complex software is hard to do well. There will always, always be bugs.

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.

Part of the reason people are annoyed it that this wasn't a complicated "crypto is hard" bug!

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.

Precisely!

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 are obviously systemic problems, like funding, corporate (and government) under-investment of time and talent, and implementing an imperfect standard. Those have a significant impact, to be sure.

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.

It's somewhat understandable; OpenSSL is a bit of a mess, and the two most recent occurrences have made me seriously think about learning more crypto in order to write a replacement, ala DJB (cf sendmail/qmail, bind/tinydns). Of course, while I think I wouldn't make any buffer overflow errors (I've got tools and training for that), I'm fairly certain I wouldn't get the crypto right the first time, and probably not the second either . . .

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.

I'd be fascinated to see what the results would be if the problem was tackled by somebody who was both capable of getting the crypto right, and willing to use DJB's substdio or any of the various equivalents.

DJB already wrote his own crypto library, NaCL:

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

And here's a list of high profile web services hist by the bug: http://hackingnews.com/vulnerability/heartbleed-hit-list-aff...

That's a very, very limited list of websites. It would be safer to assume that you need to reset your passwords, revoke access keys, for ALL websites you have credentials or keys on. However you should not do so until those websites have made a statement verifying that they have both patched, AND revoked their SSL certs.

True, the list was just referenced to show that everyone uses OpenSSL and that the large companies (practically every company in that list) should contribute to OpenSSL in some way.

It's pointless for Google, Yahoo et al, to enable inter-datacenter encryption if the front-end (TLS/SSL) is left wide open.

Couldn't agree more. Heuristic to use when someone is bashing someone else's code:

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.

I don't think that's very good reasoning.

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.

You two are talking about different things.

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.

I think by 'bashing' oskarth was trying to refer to the part where people are criticising not just the code but at least implicitly also the developers.

One can say 'this code is terrible' without also saying 'How idiotic was the committer'.

But if you continue to use that software then you probably need to be a little self-critical too.

Fork it. Nothing is stopping you.

when someone is bashing someone else's code if you mean free and open source code, I absolutely agree

Did you personally take part in the fighting in WWII? If not, how can you say that Hitler was a bad person?

(Deliberately invoking Godwin, because that's the level of logic I'm responding to :P )

Although I recognize that your intent is a reductio ad absurdum of the parent's point of view. you should also recognize that this comment draws a parallel between the volunteer devs of OpenSSL and Hitler.

It does seem like some members of the community nearly see it this way, considering their reactions.

"Mistakes were made" and "cut them a break" only goes so far. If your neighbor loans you a car that's great. If your neighbor loans you a car and it's a little bit dirty and grungy, that's not a big deal. If your neighbor loans you a car AND IT GIVES YOU CANCER because the metal is made out of radioactive waste, that's a bad thing. A very, very bad thing.

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.

Operating systems are filled with bugs and complexity. Yet OpenBSD has had two remote holes in a heck of a long time. Everything you cite as being necessary, was within the authors power to do. Some TLS implementations are close to being formally verified as not having undefined behaviour. OpenSSL is nowhere near that state. There's no point in helping it out when better run projects could use the resources better.

"mistakes will continue to be made in code" Not gravely if professional testing of the open source code is put into place. Yes it might be expensive but critical Internet libraries that serve a variety of purposes—with names such as Apache, Ruby, PHP, SSH and Linux– would benefit greatly from deep assessments.

Someone realized this a long time ago, and the Linux kernel is already being audited and tested, with regression tests, etc (see the Linux Testing Project). OpenSSH is also generally well regarded because of the same scrutiny.

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.

Just tell yourself that most of these clueless webmonkeys' companies and their "products" will not live for a tenth of the lifespan of OpenSSL. This helps for me.

Clearly if you moved to OpenOpenSSL.org you would be better off!

nooo man!!! noooo you are not the only one

>What we need is

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.