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!

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.

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.

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

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

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.

hoijui wrote: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.

dizekat wrote: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.

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