30-Day Status Update On LibreSSL 164
ConstantineM writes: "Bob Beck — OpenBSD, OpenSSH and LibreSSL developer and the director of Alberta-based non-profit OpenBSD Foundation — gave a talk earlier today at BSDCan 2014 in Ottawa, discussing and illustrating the OpenSSL problems that have led to the creation of a big fork of OpenSSL that is still API-compatible with the original, providing for a drop-in replacement, without the #ifdef spaghetti and without its own "OpenSSL C" dialect.
Bob is claiming that the Maryland-incorporated OpenSSL Foundation is nothing but a for-profit front for FIPS consulting gigs, and that nobody at OpenSSL is actually interested in maintaining OpenSSL, but merely adding more and more features, with the existing bugs rotting in bug-tracking for a staggering 4 years (CVE-2010-5298 has been independently re-discovered by the OpenBSD team after having been quietly reported in OpenSSL's RT some 4 years prior). Bob reports that the bug-tracking system abandoned by OpenSSL has actually been very useful to the OpenBSD developers at finding and fixing even more of OpenSSL bugs in downstream LibreSSL, which still remain unfixed in upstream OpenSSL. It is revealed that a lot of crude cleaning has already been completed, and the process is still ongoing, but some new ciphers already saw their addition to LibreSSL — RFC 5639 EC Brainpool, ChaCha20, Poly1305, FRP256v1, and some derivatives based on the above, like ChaCha20-Poly1305 AEAD EVP from Adam Langley's Chromium OpenSSL patchset.
To conclude, Bob warns against portable LibreSSL knockoffs, and asks the community for Funding Commitment. The Linux Foundation has not yet committed support, but discussions are ongoing. Funding can be directed to the OpenBSD Foundation." Update: 05/18 14:28 GMT by S : Changed last paragraph to better reflect the Linux Foundation's involvement.
Bob is claiming that the Maryland-incorporated OpenSSL Foundation is nothing but a for-profit front for FIPS consulting gigs, and that nobody at OpenSSL is actually interested in maintaining OpenSSL, but merely adding more and more features, with the existing bugs rotting in bug-tracking for a staggering 4 years (CVE-2010-5298 has been independently re-discovered by the OpenBSD team after having been quietly reported in OpenSSL's RT some 4 years prior). Bob reports that the bug-tracking system abandoned by OpenSSL has actually been very useful to the OpenBSD developers at finding and fixing even more of OpenSSL bugs in downstream LibreSSL, which still remain unfixed in upstream OpenSSL. It is revealed that a lot of crude cleaning has already been completed, and the process is still ongoing, but some new ciphers already saw their addition to LibreSSL — RFC 5639 EC Brainpool, ChaCha20, Poly1305, FRP256v1, and some derivatives based on the above, like ChaCha20-Poly1305 AEAD EVP from Adam Langley's Chromium OpenSSL patchset.
To conclude, Bob warns against portable LibreSSL knockoffs, and asks the community for Funding Commitment. The Linux Foundation has not yet committed support, but discussions are ongoing. Funding can be directed to the OpenBSD Foundation." Update: 05/18 14:28 GMT by S : Changed last paragraph to better reflect the Linux Foundation's involvement.
Throwing out all compatibility hooks makes it easy (Score:4, Insightful)
If you clear out the various multi-platform work for OpenSSL, _of course_ it can progress more quickly and more securely. The multi-platform work is where so much of the work has been done.
Multiplatform? (Score:1, Insightful)
I had read early on that most of the code they had stripped out was code supporting Windows and OSX. Is that true or was that just the initial pass? Dumping hundreds of thousands of lines of code is impressive--but if it comes at the cost of multiplatform support it's not surprising.
Re:Throwing out all compatibility hooks makes it e (Score:3, Insightful)
Its easy to be critical (Score:5, Insightful)
What actually happened was that, for the most part, was that it was just used blindly as its the case with most cryptographic systems and API's.
Whatever the motivators for the OpenSSL group were, whatever the decisions that were made or not made, the simple fact of caveat emptor still applies.
Its good that LibreSSL is getting created, and thanks.. Seriously though, stop bashing the OpenSSL project, it is just as much the product of its community as its developers.
Re:Fake Security Gurus (Score:4, Insightful)
Re:Its easy to be critical (Score:2, Insightful)
Re:Throwing out all compatibility hooks makes it e (Score:5, Insightful)
They are re-writing LibreSSL for *OPENBSD* across all the hardware platforms OpenBSD runs on.
Once they have stabilized it, another team, the Portability team, will then add a portability layer for other OSes.
What is so difficult to understand, and why is everyone getting their knickers up in a bunch over it?
If you like OpenSSL, continue to use it. If you want a safe, secure ssl implementation, you wait for them to finish LibreSSL and use OpenBSD. If you want a safe, secure ssl implementation on other OSes, you wait for the Portability team to finish its work. To help speed it up, donate $$ so that they can bring in more programmers.
Any other bitching just shows what an idiot you are (not saying you're bitching, just pointing that out to the general peanut gallery).
Re:"OpenSSL C dialect" (Score:2, Insightful)
Common for modern allocators to snatch more than immediately requested and hang on to freed memory longer than necessary. This is the basis by which optimized/fragmentation avoidant allocators are able to function.
Which is why a library like OpenSSL shouldn't be doing the same thing. If the OS already does this, you end up duplicating the functionality. Also, "modern" allocators often try to have the memory space after it not be valid so they cause exceptions on reads beyond the buffer and put a canary at the end of the allocation and warn if it disappears so buffer overflows also get spotted even if they are tiny. OpenSSL failed to implement this.
Re:Throwing out all compatibility hooks makes it e (Score:5, Insightful)
Good idea.. I think I'll donate to the OpenSSL team who created and maintained the project for all these years.
You mean the ones that made the heartleed bug and let bug fixes and reports rot in the tracker for 4 years?
Personally I have no reason to believe BSD is any more capable considering laundry list of CVE's for OpenSSH including an insane PAKE credential bypass.
To which CVE do you refer?
Also turned off by lack of professionalism. Too many commit comments are childish reflecting lack of discipline I am uncomfortable seeing applied to a project of this type.
Well, here's something you'll hate even more. You know that the mathematiians that develop the underlying crypto algorithms also have a sense of humour and sometimes say things/crack jokes in frustration? Basically the jokes on you. Because the "unprofessionalism" goes all the way down to the maths and you can't escape it.
You have weird ideas of professionalism, by the way to the extent where I suspect you're a suit. It seems you consider cracking jokes in commit messages and on a project mailing list to be more important indications of professionalism than, say, letting bugs rot in a bug trcker for years and coding up and effective anti exploit mitigation layer in a crucial security library.
Re:Multiplatform? (Score:5, Insightful)
using /dev/*.random instead, which has many issues[1]
I must say, I really, really don't understand most of those issues, or more specifically, most of them seem like pointless fussing non issues.
So a large number of them are "what if someone fucks with /dev/random". Since those are protected by permissions that basically translates as "what if someeone gets root and fucks with /dev/random" which to me translates as "what if someone gets root". My general answer to that would be "j00 r pwn3d!". As far as I can see, if someone gets root, you're completely fucked anyway, since the can do something like:
* Simply read the local unencrypted data you're trying to send or are saving /prov/pid/mem and read your program memory /dev/kmem to compromise the RNG for builtin crypto /vmlinuz or whatever and reboot
* Open
* Same, but writing it to compromise the RNG
* Do the same to the
* Load a kernel module
* Screw with
* Replace the binary you believe you are running with one with compromised crypto
* Monkey with LD_PRELOAD to bring in a compromised libcrypto
* Replace the dynamic loader so you're not running the binary you believe you are.
and so on. In other words it seems that once the person has the ability to compromise /dev/random, you're already fucked six ways to sunday.
But I'm not 100% sure I've missed something in my assessment.
Re:Throwing out all compatibility hooks makes it e (Score:5, Insightful)
If you clear out the various multi-platform work for OpenSSL, _of course_ it can progress more quickly and more securely. The multi-platform work is where so much of the work has been done.
As a person making their living writing software for MacOS X and iOS, do I care about this code running in MacOS 9? I don't care one bit.
They explain it very well: You don't need to be "multi-platform" if you are standard. Instead of "we have thirteen implementions of SSL_memcpy that run on a dozen completely outdated platforms that nobody cares about", they use memcpy and say "if your platform doesn't support a standard C function correctly, fuck you and your platform". Which is the correct approach.