OpenSSL alternative(s)

[hoijui]

regarding the heart-bleed thing, and discussions in the lobby.

what open-ssl alternatives do you know, and what do you think abotu them. or what do you think shoudl be happening, and how exactly, to solve the problem(s) which open-ssl creates.

[gajop]

to solve the problem(s) which open-ssl creates.

What problems is it creating? It was just a single security bug, an isolated incident, it's not like they have a bad track record.

[Kloot]

regarding the buffer overflow exploit thing, and discussions on the interwebs.

what alternatives do you know, and what do you think abotu them. or what do you think shoudl be happening, and how exactly, to solve the problem(s) which incompetent programmer(s) create(s).

(isn't it obvious? clearly The Solution™, which will also end world poverty, is to rewrite everything in java!)

[hoijui]

mmm.. close!
the solution would be, to write everything in java from the start.
... actually, you were not really close, but i give you, that you were on the right track.

more sieruus:
i was told, long before this incident, and now again, that OpenSSL code is very ugly. nobody wants to read and try to understand it, which makes stuff like this incident much easier/more likely to happen.
in other words, whether you believe that this was a deliberately implemented, or an accidental bug... the ugly code makes it easy to do this deliberately, and OpenSSL is used very widely -> problem!

[very_bad_soldier]

I guess OpenSSL will actually get *much* attention now and lots of people actually reviewing the code. Now switching to some niche SSL implementation is far more risky imo.

[hoijui]

... why?

if the code is really that ugly, and what they told me (and i believe them), it is, then this momentarily high attention will not help at all, and if you live in reality, you will also know that it will not be rewritten in a nice way (not gradually for sure, and with close to no chance from scratch). so this means: openssl bad, for ever.
it might be "totally" safe now (unlikely?), but even if it were, it would still be bad.
it would be better in my eyes, to have a less used so far, and probably more buggy code, but much cleaner, if it can be more reliably tested and reviewed more easily.

[Petah]

If you are asking for an alternative, context would be nice. Is it just for a web server?

http://en.wikipedia.org/wiki/Comparison ... mentations

And yes the code is pretty gross:

https://github.com/openssl/openssl/blob ... l/s3_lib.c

[hoijui]

alternative as in: wipe openssl off the face of the earth, and use the alternative instead. in other words.. a complete replacement, for wherever openssl is used now.

[raaar]

the bug only affects some versions of openssl:

http://en.wikipedia.org/wiki/Heartbleed ... tallations

[dizekat]

Me thinks the companies that move billions dollars should be paying more to developers.

Ultimately, the code written for free is usually someone's learning things. In case of Spring, people learning graphics programming and such, which works fine, in case of OpenSSL, people learning C and pointer arithmetics, which means the code sucks.

[Silentwings]

in case of OpenSSL, people learning C and pointer arithmetics

Completely agree with you in principle, but in this case maybe more like learning the usefulness of namespaces, debug range checking, documentation...

[tombom]

The OpenBSD team cloned OpenSSL to their repository and are doing an audit/rewrite of it http://opensslrampage.org/

dizekat is on to something, imo. It's messed up that things like OpenSSL are so important and make companies billions of dollars yet these same companies don't pay shit for it and rely on volunteers to do their work for them (this is why I think the GPL is a better license than most). Like if the OpenSSL team is tiny yet they're expected to be able to make a key security thing and do it perfectly something's very up

[Kloot]

wipe openssl off the face of the earth

if you live in reality

trolololo

In the real world, Newton's first law applies to software too. And since OpenSSL has by far the most inertia of all the foss SSL implementations, accelerating another one like GnuTLS to the same level of adoption / development / analysis is much harder without $$$ to drive the effort. Do pull your wallet.

Me thinks the companies that move billions dollars should be paying more to developers.

In principle it would be awesome, not to mention fair, if this could somehow be mandated for all big consumers of open-source software.

In practice developer salary doesn't correlate with code $metric_of_choice_here$, but it might help to attract more qualified (PhD level) researchers who understand just how intricate and difficult crypto really is. And let's at least try to be honest for one second: cryptographic vulnerabilities are often not of the "buffer overrun by noob programmer" variety, but of the subtle "this setting combined with that initialization parameter creates obscure theoretical weakness if more than N bytes are collected by attacker who can then perform session hijacking" type that eventually turn out to be practical after all (eg. when they show up in a leaked NSA presentation...) and are independent of how "gross" the code looks.

companies

Large companies (banks, etc) tend to use proprietary solutions which in the realm of cryptography is even worse, cf. RSASec getting bribed to select a backdoored RNG as the default option in their BSAFE (lolwat) toolkit allowing the NSA to completely bypass that implementation of SSL for TEN YEARS STRAIGHT. Although, the NSA being able to sit on your public commit stream 24/7 with who-knows-how-many mathematicians doing nothing but looking for exploits to add to their collection and think up funny codenames for maybe isn't the best situation either, but at least the community has a better chance to discover them too (as happened with heartbleed).

[dizekat]

The problem seem to be that nobody want to pay non-negligible money for something freely available to everyone else.

In practice developer salary doesn't correlate with code $metric_of_choice_here$, but it might help to attract more qualified (PhD level) researchers who understand just how intricate and difficult crypto really is.

I think the issue is that you want experienced people, and they very predominantly find that kind of job incredibly boring and won't do it for free.

For example, I *could* write wrappers for malloc, free, memcpy, macros for declaring things on stack, and so on and so forth, that would not permit you to copy beyond an allocated block. Wrapper functions for pointer arithmetic as well. Then edit the whole library to 100% work through those wrappers. Most programmers with some experience can do that.

It'll still be in C (no way in hell something not in C would get wide acceptance), but it'll be a lot more secure. It should not introduce any new vulnerabilities if done very boringly with no change to OpenSSL other than use of those wrappers.

But would I? I get paid good money to do far less boring work. And on the level of boringness, this fix I described above is 11 out of 10.

edit: other very interesting thing. In all those years, none of so called security experts, so called penetration testers, or the like, had as much as tested OpenSSL with malformed packets (with wrong value for one field). Never mind spotting that in the code - this bug ought to be simple enough to spot by randomly mutating packets.

[SinbadEV]

via Google+

http://www.libressl.org/

[SirMaverick]

i was told, long before this incident, and now again, that OpenSSL code is very ugly. nobody wants to read and try to understand it, which makes stuff like this incident much easier/more likely to happen.
in other words, whether you believe that this was a deliberately implemented, or an accidental bug... the ugly code makes it easy to do this deliberately, and OpenSSL is used very widely -> problem!

OpenSSL is by far the library with the widest support of architectures and SSL extensions. Not everyone could switch if they wanted to.
Others SSL implementations aren't more secure: http://pbs.twimg.com/media/Bk0DY8XCEAAPpS7.png:large
That table is not up to date anymore at least in PolarSSL they fixed some of the bugs.

For example, I *could* write wrappers for malloc, free, memcpy, macros for declaring things on stack, and so on and so forth, that would not permit you to copy beyond an allocated block. Wrapper functions for pointer arithmetic as well. Then edit the whole library to 100% work through those wrappers. Most programmers with some experience can do that.

In OpenBSD they have malloc and free implemented in a way that you cannot write beyond buffers or your application will crash. Those measure cost some performance.
What did OpenSSL do? They implemented their own malloc/free, allocate large amount of ram and manage it on their own. And loose all the security features just to be faster.

[hoijui]

i disagree with you, kloot. right now, there are tons of devs that hate openssl, and think it is important to get away from it. there are alternative projects, and the linux and bsd guys that decide over which packets get include, and which get used as standard for what purpose and so on, would surely also be more then happy to give at least ways to easily switch to alternatives, or even use alternatives to openssl as default in testing releases or so. and many linux users (guys like us) would like to use/test alternatives in practise too. and these things are all you need to get an alternative where it finally could be a valid replacement. i see no real obstacle (except maybe sabotaging acts of bad guys).
.. you wanne say you don't belie in it? who's payin' you?!?!?

[very_bad_soldier]

As expected:
http://arstechnica.com/information-tech ... d-openssl/