
Ask HN: Negative OpenSSL sentiments - aggresswift
While I admit that the recent Heartbleed security issue is a critical issue, I am getting perpetually flummoxed by the &#x27;I have the moral high ground&#x27; negative comments being thrown at the OpenSSL project &amp; developers. Innumerable blogs and HN threads are taking the stand of &#x27;how could they commit something like that&#x27;, &#x27;How idiotic was the committer&#x27;, &#x27;OpenSSL should not use a custom wrapper around malloc&#x27; and even taking personal shots at the two gentlemen who were referenced in the code.<p>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&#x27;t know whether there&#x27;s something like review-board for OpenSSL commits. 
* Donations to the OpenSSL foundation. C&#x27;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&#x27;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&#x2F;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 &amp; distributions can get fixes baked by the time the general alarm is sent.<p>1.http:&#x2F;&#x2F;www.tedunangst.com&#x2F;flak&#x2F;post&#x2F;analysis-of-openssl-freelist-reuse
======
notacoward
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_.

~~~
jacques_chester
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.

~~~
antocv
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.

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

~~~
amalag
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.

~~~
antocv
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.

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

------
morgante
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](https://www.openssl.org/support/acknowledgments.html)

~~~
hoilogoi
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.

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

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

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

------
MediaSquirrel
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?

~~~
wpietri
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.

~~~
antocv
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.

------
lazylizard
"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...](http://www.theage.com.au/articles/2004/10/07/1097089476287.html)

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

~~~
JackC
> 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](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.

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

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

~~~
mst
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.

~~~
grosskur
DJB already wrote his own crypto library, NaCL:

[http://nacl.cr.yp.to/](http://nacl.cr.yp.to/)

It's been packaged up as libsodium:

[https://github.com/jedisct1/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](http://cr.yp.to/qmail/qmailsec-20071101.pdf)

------
aggresswift
And here's a list of high profile web services hist by the bug:
[http://hackingnews.com/vulnerability/heartbleed-hit-list-
aff...](http://hackingnews.com/vulnerability/heartbleed-hit-list-affected-
websites/)

~~~
octatone2
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.

~~~
aggresswift
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.

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

~~~
Pacabel
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.

~~~
wpietri
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.

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

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

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

~~~
npsimons
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.

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

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

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

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

