Submitted by Members of the OpenBSD project, already known for the OpenBSD operating system and related projects such as OpenSSH, OpenBGPD, OpenNTPD, OpenSMTPD, are creating a fork of the OpenSSL project, likely to be called LibreSSL. (OpenSSL and OpenBSD are completely separate projects with different people working on them.)
Apparently, the focus is not so much on taking OpenSSL into a completely different direction, but more on a massive code cleanup and long-overdue maintenance.
Oh and anyone interested in following the development:
http://opensslrampage.org/
Edited 2014-04-24 00:30 UTC
Who is this tedunangst guy? Is it really true that OpenBSD people are crazy assholes?
Who is this tedunangst guy?
His name is Ted Unangst. The surname is from the German where un = not and angst = fear
Is it really true that OpenBSD people are crazy assholes?
Only if that is a term that describes people who spend lots of their spare time writing code that is as secure as the best.
As well it would have to describe people who not only write good code but who make it available free of charge with a licence that only has one restriction.
(See: http://www.openbsd.org/cgi-bin/cvsweb/src/share/misc/license.templa…)
And to cap it all this project’s plan is:
1/ Clean out the cruft and replace all insecure code with quality work.
2/ Bed it down and audit after it checks out as functional on OpenBSD
3/ After a break from doing the above and when manpower and funds are up to it, engineer a portable version in the manner that OpenSSH has. That makes it much easier for porting to other platforms.
Crazy? For doing all that work for $0? Maybe.
Assholes? Assholes don’t provide other platforms with well documented reliable source code that needs little work to get working.
I sometimes wonder why people think the OpenBSD guys are assholes. I’ve been following the lists for a while (though less than I used to) and to be honest, the few assholes there are pretty much always trolls that have nothing to do with OpenBSD. So I tend to think it’s hearsay that starts to confirm itself when repeated often enough by people who 1) don’t read the source, 2) take things out of context or 3) feel offended way too easily.
/rant
Edited 2014-04-24 17:38 UTC
Guilt by association with Theo de Raadt. And personally, I think Theo isn’t really as bad as Linus and I don’t think you can really be arseholes about security. It’s a serious issue and there can be no pussyfooting.
The funny thing is how often this is said by people who also laud Linus for is frankness.
Edited 2014-04-25 08:56 UTC
Linus ain’t got nothing on Theo de Raadt.
Theo is actually comparatively mellow these days.
No. When Linus called the OpenBSD guys masturbating monkeys for their fixation on security over other bugs, Theo won by explaining that they treat any bug (including documentation) as having potential security implications. ie, they don’t concentrate on security bugs, but that they look at every bug in terms of security. So Linus was being the arsehole and he got his arse kicked.
* This was my recollection of events.
Edited 2014-04-26 09:18 UTC
A better developer than you and I will ever be.
….does it matter what we answer? You have already made up your mind.
Edited 2014-04-24 06:31 UTC
This is gold.
How comes everyone was using this library blindly like that, did no one ever have the balls to audit it?
Edited 2014-04-24 05:20 UTC
They did, but it appears not all is green on the other side of the fence (playing devil’s advocate):
http://arstechnica.com/information-technology/2014/04/tech-giants-c…
OTOH, I must mention this:
Not always the best kinds of people when it comes to communication/dialogue & leadership skills of such an important yet unforgiving project.
One mistake is all it takes for the whole world to come down your throat with an ax – or at the minimum gnash their teeth at you, while no one else wants to (or is even able to) lift a finger, since it requires a very thorough understanding of the inner workings of cryptography, network security, etc.
It’s certainly not the easiest project to be a developer/maintainer for, that’s for damn sure.
Eww. I hate the name.
However, good work.
It should be noted that they didn’t remove Windows support; rather, they removed old Win32 support. They removed old code that worked around an absence of features that Windows used to lack (POSIX-style sockets, for example), but now supports. So, Win9x will no longer be supported, likely NT4 won’t work.
Libre cómo el aire
Libre cómo el viento
Cómo las estrellas en el firmamento !
Como el mar.
The name of the project is LibReSSL.
Considering neither NT4 nor Win98 haven’t been supported by…well pretty much anybody for over a decade? Can’t really say as I blame ’em for tossing the cruft.
I created my own crypto lib a few years ago to learn and as a personal challenge. It’s not nearly as feature complete as openssl, but it could be if I continued to work on it – ideally I could commit to it professionally rather than as a side-hobby competing for my personal time. I figured there would be little interest in yet another unknown 3rd party crypto package, however given the quality issues with openssl maybe there is an opening for independent projects?
I actually love this kind of work, but I’m always forced to revert to less interesting web-dev stuff because that’s what pays the bills; I have yet to find anyone interested in funding my pet projects. Any takers?
How feature complete is it compared to crypto++? Or more importantly, how much do you know about withstanding attacks to styles of implementations of common crypto functionality? My limited understanding of the subject is that you can eliminate the very common buffer-related errors, but there are still a whole host of other designs which can be attacked.
kwan_e,
[q]How feature complete is it compared to crypto++? Or more importantly, how much do you know about withstanding attacks to styles of implementations of common crypto functionality? My limited understanding of the subject is that you can eliminate the very common buffer-related errors, but there are still a whole host of other designs which can be attacked.[q]
Well, that’s the thing. You don’t know until it gets revealed
With careful & consistent coding, you should avoid buffer overflows which are so common with C. That’s pretty bad that openssl had these. Side channel attacks are tougher though because even the timing of code can leak information. The most obvious way to solve this is to make every operation take the same amount of time. For asymmetric encryption like RSA, that means running more iterations than actually needed to encrypt/decrypt data.
Symmetric algorithms generally already have an even time distribution, however there are other subtle issues: Symmetric ciphers like AES can have very complicated local attacks whereby the attacker controls which pages of the lookup tables are in cache, which can happen when the lookup tables are in a shared library accessible to the attacker. Therefor a timing attack could leak information about the bits that determine which cache entries get used. There’s lots of entropy complicating matters, but over enough measurements there will conceivably be a correlation. A solution needs to eliminate this correlation.
Also, historically many implementations have failed due to faulty random number generation. TBH I’ve never worked on this since my code just reads from /dev/random.
Even though I’m aware of the issues, sometimes it can be easy to slip up and make invalid assumptions. I still enjoy the challenge though. In any case, hardware implementations (ie intel’s new aes instructions) are hopefully not vulnerable
Edited 2014-04-24 13:06 UTC
More info about cache attacks:
http://tau.ac.il/~tromer/papers/cache-joc-20090619.pdf
A long, yet very interesting read!
It’s stuff like this that makes me wonder if it is wise to keep redeveloping crypto suites and possibly reinventing the same lines of attacks that a more mature library may have dealt with already.
kwan_e,
Well, on the other hand these recent breaks show just how bad it is to have a monoculture with little diversity. When there’s a failure, it’s catastrophic. Diversity is necessary for good security practices, and yet the general attitude in the community actively discourages it.
For what it’s worth, my symmetric aes encryption code wasn’t vulnerable to this cache attack. Obviously it’s hard to tell what other unknown vulnerabilities there might be though.
I think the solution shouldn’t be discouraging alternatives, but creating and encouraging the widespread use of new tools to help us audit the code for side channel flaws. The paper above documents some very powerful analytic techniques that could be built into a standard framework in such a way that anybody could benefit (crypto and even in other libraries). It would certainly help build confidence that an implementation isn’t vulnerable to these kinds of extremely subtle problems. This would be true both of independent crypto code as well as openssl/dmcrypt/etc.
True. There could also be a case for “randomly” choosing an implementation to do the actual crypto to maybe make it a tad less predictable which implementation’s flaws to attack. There could be something like that in existence, but I don’t know enough to be aware of one.
Or maybe I’m making too much of side channel attacks and that buffer errors, or even simply waiting for new buffer errors to be injected as will always be the case in C, is still a much more effective attack.
Edited 2014-04-25 14:05 UTC
If the upheavel is half as good as the libreoffice movement from the document foundation. there won’t be a distro left that supports openssl in a year
And also an efficient programming language:
http://bluishcoder.co.nz/2014/04/11/preventing-heartbleed-bugs-with…
The language (ATS) emits C, and it is easy to embed in a C project, which is what was done here with OpenSSL.
Good riddance. OpenSSL is a huge bloated convoluted and undocumented piece of code. All the BIO system is fucked up and makes it tweak it for your own uses a mess.
I hope LibreSSL is actually at least better documented. That alone will make me happy.
I hope LibreSSL is actually at least better documented. That alone will make me happy.
OpenBSD treats documentation as if it were code.
Even a spelling error is classed as a bug that must be fixed.
It’s a bit early to see docs for libReSSL but you can get an idea by going to the on-line man pages:http://www.openbsd.org/cgi-bin/man.cgi
The source code is visible via http://www.openbsd.org/cgi-bin/cvsweb/ which lets you browse the CVS contents without downloading piles of stuff.
I don’t know (without searching for) where all the stuff for SSL is located but you can see that all of the OpenBSD generated source is formatted uniformly and commented.
For now their API will stay compatible. Knowing the OpenBSD guys they’ll probably add a new API.
I think I did see mentioned somewhere they want to split it in several libraries.
One library could be just a compatibility layer the lowlevel library would then have the better API.
Edited 2014-04-24 08:42 UTC
I am ever grateful for the quality work that OpenBSD does, not just for openbsd but for the wider open ecosystem.
Without distracting from this much needec cleanup – one does have to ask – how did this happen? What lessons are there to be learned?
I think this “inquiry” and “report” shouldn’t be done just in forum posts ,… but taken much more seriously with a much publicised review and report, funded and resourced properly – especially by those huge organisations (eg redhat but others too) who can afford, and can’t afford not to, do that.
So many products depend on openssl code…. it is important for the industry to understand what and how things went wrong for openssl.
The open ecosystem is always much more honest with itself than closed commercial software – and it will benefit hugely from such a review.
If I was cisco, redhat, sony, etc … I’d be supporting such a coordinated review and lessons learned. I’d be surprised if an outcome wasn’t better funding for such important code.
I can’t think of any better team to do an audit over OpenSSL. This all brings the subject of how grossly underfunded most opensource projects are. The world owes the OpenBSD foundation for OpenSSH already and these guys barely have money to pay for the electricity. Oh and the linux distributions, which all carry this code, haven’t given a cent.
Even more sad is that collectively the opensource community is lacking to address the bigger issues revealed by Snowden, and there is nothing to do about it.
And now that some companies with deep pockets are apparently understanding they depend on a bunch of volunteers for their most critical operations they give the money to some intermediaries (TLF) so that they “manage” it.
I concur. Say what you want about Theo de Raadt and his beliefs, but when it comes to computer security, he and his team definitely know a thing or two, to put it lightly.
I also believe that this Heartbleed bug has finally awakened many companies to start taking open source projects seriously. Funding for some very sorely needed projects is finally starting to become reality, which is great news for all of us. So although this bug was incredibly devastating, some very good things have come as a result of it.
Edited 2014-04-26 18:32 UTC
1c3d0g,
I’m not so sure, I see it time and time again where companies only take security seriously *after the fact*. When you raise the point that something *needs* to be fixed, many will just shrug it off and point out that there’s no budget for fixing theoretical vulnerabilities. It puts all of us at risk, but the only time they are genuinely interested in security is when it’s compromised. All of a sudden it becomes important. Does anyone else see this?
I suspect after this Heartbleed bug passes over, things will revert to business as usual and nothing will fundamentally shift in the secure space. We’ll have to wait and see, I suppose, but from where I’m standing it already looks like interest has faded.