Slashdot Mirror

OpenSSL problems are due to proprietary company controlling the project for certain proprietary interests.

Not really, OpenSSL is open-source, anyone can modify it.

The problem is the complete shittyness of the OpenSSL code.

Here's 49 pages of the stupidities that the LibreSSL people ( http://www.libressl.org/ ) found while going through the OpenSSL code: http://opensslrampage.org/

After the sh*t I've read on opensslrampage.org I don't even want to touch anything from openSSL any more, "audited" or not. There's so much cruft and abject stupidity in there I can't trust it ever again.

I feel dirty just knowing my Linux server has this crap infecting my web server and god knows what else. What a crapfest. The TLAs must be really pissed we finally are looking at this stuff, I guess at least that's a plus.

.
It's also one of the funniest developer-centric things I've ever read - no holds barred for these guys in their contempt of the code they're ripping to shreds. Win/win.

OpenSSL is a classic demonstration of one of the truths of computer programming - namely that good cryptography is HARD.

OpenSSL is a mess that demonstrates nothing of the sort. Cryptography is hard but openSSL lost before getting to that point by having horrid coding practices.

If you want to have a clear understanding of how bad it is, the OpenBSD team is live blogging the mess as they clean it up. In short, OpenSSL was not written by a responsible (or entirely competent) dev team.

The OpenSSL Vahalla Rampage seems to have petered out. Last post was "2 weeks ago." Guess they fixed everything.

Which just means they will introduce totally new bugs of their own, essentially 'resetting' all the security testing and reliability that the current code base has.

Which would be very little. Have you seen some of the stupidities in the OpenSSL code? http://opensslrampage.org/

A great presentation by the libreSSL people is here: http://www.youtube.com/watch?v=GnBbhXBDmwU

Let's go webshopping!

Seems to me LibreSSL is the way to go, but I can also see why the corporations would just use it as a side-stream for hints on what to fix. They have enough resources to rewrite openSSL from the inside rather than the the LibreSSL tear-down approach.

I don't think companies really "have enough resources" to rewrite OpenSSL. The problem is that you can't just throw money at a project and have stuff happen. You need people to implement those changes. And we're still in the clutches of the software crisis.

The problem with OpenSSL is that it is really, really bad code. It's security code, which few people have the expertise to handle. It has an idiosyncratic style, which few people want to look at, it's so painful. And it is so littered with backwards compatibility hacks and defective functions that very few people can know whether it's doing something right. Even the OpenSSL people don't know what it's doing, given all the comments about OpenSSL functions that they're not using properly.

So, best of luck to the CII, trying to "improve" OpenSSL without getting rid of all its weirdness. I think the OpenBSD people are right, and they should just tear down everything and rebuild it.

Yeah, been reading OpenSSL Valhalla Rampage
  Once it is released in Linux, I'm definitely switching.

While I applaud the efforts and support I do hope that the work of others will not be ignored. The audit is great news, but I do hope the existing and new developers will look to LibreSSL for code updates, ideas and their own audit results. If we can get a nice bidirectional and completely cooperative flow between the two projects than hopefully the final result will be a highly secured, audited product that we can all use.

heartbleed

...

WHY DIDN'T A TEST CATCH IT?

A couple of months before this posting, I would have thought OpenSSL has done positive things for the community. Now I know that this is unreliable software that must be replaced as soon as viable. I've since learned better. Maybe OpenSSL didn't always suck. But, at the time of this writing in May of 2014, it sucketh.

A couple of days ago (at the time of this writing), OpenSSL Vahalla Rampage: "Sometimes bad tests can be more harmful than no tests at all" documents yet another bad test in the OpenSSL code. The OpenSSL code is riddled with problems, including tests that don't work as intended. So, there is a simple answer to the question: why a test didn't catch heartbleed. The answer is that reliable testing was not being performed. Multiple tests that were created, didn't work, and so couldn't be relied upon anyway.

Thank goodness there is a competent team on this planet who knows how to do things right, and is now taking care of the problem. (The makers of OpenSSH are ripping OpenSSL to shreds, and creating LibReSSL, the library that is a re-implementation of SSL code.)

For tons more examples of how cripplingly bad OpenSSL has become, see other articles on the OpenSSL Vahalla Rampage site. The site will probably mean nothing to people who don't know programming (or don't have enough experience to have been introduced to techniques like manually freeing up memory that was dynamically allocated earlier). I don't quite comprehend some of the intricacies, but some I do, and those that I do, are ROFL-making material. Like this amusing observation (which will amuse anyone who has used to C preprocessor), and many others.

Perhaps one of the best examples is the code that uses a goto statement, to jump to this label:

if (0)
                {
err:

That gem was found from Flingpoo! : OpenSSL is written by monkeys, yet another ridiculing site documenting the current tragedy of OpenSSL. That site has some other wretched examples, like the #ifdef...if...#endif...else mis-construct.

heartbleed

...

WHY DIDN'T A TEST CATCH IT?

A couple of months before this posting, I would have thought OpenSSL has done positive things for the community. Now I know that this is unreliable software that must be replaced as soon as viable. I've since learned better. Maybe OpenSSL didn't always suck. But, at the time of this writing in May of 2014, it sucketh.

A couple of days ago (at the time of this writing), OpenSSL Vahalla Rampage: "Sometimes bad tests can be more harmful than no tests at all" documents yet another bad test in the OpenSSL code. The OpenSSL code is riddled with problems, including tests that don't work as intended. So, there is a simple answer to the question: why a test didn't catch heartbleed. The answer is that reliable testing was not being performed. Multiple tests that were created, didn't work, and so couldn't be relied upon anyway.

Thank goodness there is a competent team on this planet who knows how to do things right, and is now taking care of the problem. (The makers of OpenSSH are ripping OpenSSL to shreds, and creating LibReSSL, the library that is a re-implementation of SSL code.)

For tons more examples of how cripplingly bad OpenSSL has become, see other articles on the OpenSSL Vahalla Rampage site. The site will probably mean nothing to people who don't know programming (or don't have enough experience to have been introduced to techniques like manually freeing up memory that was dynamically allocated earlier). I don't quite comprehend some of the intricacies, but some I do, and those that I do, are ROFL-making material. Like this amusing observation (which will amuse anyone who has used to C preprocessor), and many others.

Perhaps one of the best examples is the code that uses a goto statement, to jump to this label:

if (0)
                {
err:

That gem was found from Flingpoo! : OpenSSL is written by monkeys, yet another ridiculing site documenting the current tragedy of OpenSSL. That site has some other wretched examples, like the #ifdef...if...#endif...else mis-construct.

heartbleed

...

WHY DIDN'T A TEST CATCH IT?

A couple of months before this posting, I would have thought OpenSSL has done positive things for the community. Now I know that this is unreliable software that must be replaced as soon as viable. I've since learned better. Maybe OpenSSL didn't always suck. But, at the time of this writing in May of 2014, it sucketh.

A couple of days ago (at the time of this writing), OpenSSL Vahalla Rampage: "Sometimes bad tests can be more harmful than no tests at all" documents yet another bad test in the OpenSSL code. The OpenSSL code is riddled with problems, including tests that don't work as intended. So, there is a simple answer to the question: why a test didn't catch heartbleed. The answer is that reliable testing was not being performed. Multiple tests that were created, didn't work, and so couldn't be relied upon anyway.

Thank goodness there is a competent team on this planet who knows how to do things right, and is now taking care of the problem. (The makers of OpenSSH are ripping OpenSSL to shreds, and creating LibReSSL, the library that is a re-implementation of SSL code.)

For tons more examples of how cripplingly bad OpenSSL has become, see other articles on the OpenSSL Vahalla Rampage site. The site will probably mean nothing to people who don't know programming (or don't have enough experience to have been introduced to techniques like manually freeing up memory that was dynamically allocated earlier). I don't quite comprehend some of the intricacies, but some I do, and those that I do, are ROFL-making material. Like this amusing observation (which will amuse anyone who has used to C preprocessor), and many others.

Perhaps one of the best examples is the code that uses a goto statement, to jump to this label:

if (0)
                {
err:

That gem was found from Flingpoo! : OpenSSL is written by monkeys, yet another ridiculing site documenting the current tragedy of OpenSSL. That site has some other wretched examples, like the #ifdef...if...#endif...else mis-construct.

Yeah, I've been trying to keep up. It's heavy stuff and a little over my head sometimes but never the less very interesting (and sometimes very amusing).

We cannot write complex bug-free software. PERIOD. OpenSSL is not windows. Headlines about OpenSSL bugs are not such a common occurrence. One bug happened at the wrong time, wrong place. This could have happened even if the world had opted for a proprietary library for this critical role. The only difference is that there would have been somebody to sue. Big consolation.

New theories come out of IT faculties around the world at regular intervals, that promise, if strictly followed, the holy grail of bug-free software. All of them eventually prove non-effective.

The only concrete effect of all these tactics is that the job of the programmer becomes more tedious, less interesting. One thing I can tell you from direct experience is that, the lowest the level of interest of the programmer, the higher the possibility will be that bugs may slip into his or her code.

Actually, it's possible to remove all errors and imperfections, if you would be satisfied with being boring. That's one thing I got from Douglas Crockford's Programming Style and Your Brain. Sometimes, especially for security-related software, "boring" is exactly what you want.

Unfortunately, SSL is anything but boring. It's barely standardized, and it's prone to getting new features. But just because the standard is exciting, doesn't mean the code has to be exciting. The OpenSSL developers may have received $2,000 in donations last year, but they make money by consulting on OpenSSL. They have a perverse incentive to keep OpenSSL confusing and buggy. The efforts for the LibreSSL project show just how needlessly exciting the OpenSSL code base is.

To prevent the next Heartbleed, it's more productive to donate to LibreSSL.

Why not fund openSSL developers to do the same with the OpenSSL code, but including much of the cross platform options that has made it so ubiquitous. And without the silly name,

Because all those cross-platform hacks directly contribute to its bugginess. The Heartbleed bug was facilitated by a cross-platform reimplementation of malloc that was written for speed rather than security.

And also because the OpenSSL developers have been demonstrated to sit on patches for years instead of fixing bugs.

For a morbidly good time, go look at OpenSSL Valhalla Rampage, a blog highlighting some of the insanity that the OpenBSD devs are encountering as they rewrite OpenSSL into LibreSSL. It becomes clear that Theo de Raadt was right, and the OpenSSL devs are not responsible people.

Not fundamentally broken? You obviously haven't been following http://opensslrampage.org/.

Finding an obscure bug every few years denotes "not fundamentally broken". A sea of bad frees and platefulls of spaghetti code is "fundamentally broken", especially for a high-value security product. The entire codebase is a ticking time bomb.

For some funny blow-by-blow commentary that the LibreSSL people are doing, check out http://opensslrampage.org/

Too many VMS jokes to count.... but just looking at the comments, OpenSSL's code is labyrinthine and full of cruft and useless files.

Are you on crack or just poorly trolling?

How is that even remotely "holding OpenSSL hostage" ??? they make their own version for their pet OS. No one forces *you* or anyone else to use it, no one is forbidden to fix OpenSSL meanwhile (except for these few developpers cleaning up LibreSSL I guess)

If you know how to fix OpenSSL, please be my guest, otherwise just stop spouting nonsense ...

oh, and by the way, seriously, go take a look at the horrible code that they're cleanning up and removing ... double free, missing checks, useless if/else conditions, memory mismanagments, and worse ... that cleanup was long overdue.

A Tumblr site popped up a few days ago called OpenSSL Valhalla Rampage. The blogger there is going through all the commits and posting the juicy funny comments there. This includes killing... and rekilling... VMS support (which reminds me of Maxim 37: there is no such thing as overkill...), stripping out now-stupid abstractions and optimizations of the unoptimizables, and more.

http://opensslrampage.org/

if OpenSSL had 5 pages of bugs so far... and was widely used in an ecosystem where the source was there, just imagine the nightmare of closed source projects...

patching 100 bugs on average introduces 3 new bugs. now i know bugs != security vulnerabilities. but bugs are why people complain about software stability.

also a 'vulnerability' bug has a black market value that is always going to be higher than bug bounties. however an old exploit has the added value of 'reporting' it after a new vulnerability is found and the old one is blamed perhaps by news of this 'old' vulnerability. it's a revolving door problem. back in 1997 i knew how to 'fix' broken open source ports tree applications, because i used freebsd and it was very buggy (though less buggy than the windows 95 machine i had).

as i see it the problem is marketing. to get people to buy computers they promote them as doing a lot of things that they can only just barely do. and often the code base is filled by people who don't care about quality and comprehensible coding. and for for profit they often take steps to make the code illegible as a so called security through obscurity (which never works for more than a few years).