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.
Video of the presentation (Score:4, Informative)
https://youtu.be/GnBbhXBDmwU [youtu.be]
Re:Multiplatform? (Score:5, Informative)
They removed support for OpenVMS, Pyramid, Tandem classic MacOS, and other stuff like that. I don't know if they removed Windows and OSX support, but it'd be pretty silly if they did.
Re:Throwing out all compatibility hooks makes it e (Score:4, Informative)
Throwing out all compatibility hooks makes it easy (Score:4, Informative)
Re:Multiplatform? (Score:2, Informative)
They did, this is BSD compatible only.
Re:"OpenSSL C dialect" (Score:5, Informative)
OpenSSL has basically wrote their own version of libc, and all the functions they've introduced differ is some very subtle ways from what appears in libc used by the rest of the world.
Rest assured, OpenBSD is no stranger to portable code. Just take a look at the number of platforms they support -- http://www.openbsd.org/plat.ht... [openbsd.org].
Re:"OpenSSL C dialect" (Score:5, Informative)
Yep. In fact, this was actually one of the reasons Heartbleed was so bad. Normally, anybody repeatedly attempting to read 64k chunks of heap space would hit an unallocated page pretty quickly, causing a crash alerting the victims to something being wrong. However, OpenSSL uses their own funky versions of malloc and free which pre-allocate large chunks of memory from the OS (as in, many pages), then implement their own in-process memory management on top of that. They don't free those pages back to the OS either, at least not anywhere near as soon as a sane memory manager would. This doesn't actually mean huge amounts of wasted memory - the library can mostly re-use the memory it has already requested, rather than grabbing more from the OS - but it does mean that just because something is freed doesn't mean it isn't still mapped into that process. The end result is that Heartbleed had no externally-visible evidence for the vast majority of its victims, so people didn't even know there was something to look for until the news broke.
Re:"OpenSSL C dialect" (Score:5, Informative)
What is this "C dialect" of which you speak?
The code is largely in a subset of C; there are certain language features that make it intrinsically harder to do static analysis and checking, and which you avoid in order to avoid introducing certain classes of problems into the code. Examples include unspecified array lengths for arrays declared at the ends of structures (a c99 feature first defined with a slightly different syntax by gcc), use of function pointers that don't end up with a const qualifier after initialization, serialization and deserialization of data objects containing pointers, variant length arrays, varradic functions, with or without in-band format strings for interpretation of arguments subsequent to the format strings, etc.. For a given compiler technology, it can also include dynamic scoping, locally scoped variable, and basic block replications which introduce issues when using some code constructs. Typically, there is also a requirement for single entry/single exit, and similar techniques that can use runtime assertions (statically or optionally compiled in) in order to test on larger data sets, although by definition, such things are relative Ad Hoc, and therefore not provable in terms of code coverage.
Similar dialects are defined by standards, such as "MISRA C" (Motor Industry Software Reliability Association), but of course, it costs money to get that standard, and it's not disclosed, so there's no open source compliance checkers, and there's no open source static analysis tools that can check the compliant code based on compliance related assumptions. One of the disclosed requirement is use of sized type everywhere, so fundamental C types are eschewed in favor of them; so you don't use "char", "short", "int", "long", and "long long", you use things like "uint8_t" and "int32_t", and so on. Another is that there are limits to allowed cyclomatic complexity, as determined by static analysis tools.
What it pretty much comes down to is that C by itself lets you get away with things that, if you are allowed to get away with them, makes the outcome of running the program indeterminate. It's still not possible to solve/prevent the halting problem in these dialects, but it's easier to avoid getting into a situation where you have to, if you use the constrained dialect and programming style in your code.
It's really be handy if some day MISRA or something similar became an open standard so that we could raise the level of discourse on these things, particularly as they apply to life support systems, since some people place both privacy, security of financial transactions, and so on, on an equal footing with straight life support.
Re:Multiplatform? (Score:5, Informative)
It does indeed appear to be OpenBSD only at present (from http://www.libressl.org/ [libressl.org] ):
Multi OS support will happen once we have
Flensed, refactored, rewritten, and fixed enough of the code so we have stable baseline that we trust and can be maintained/improved.
The right Portability team in place.
A Stable Commitment of Funding to support an increased development and porting effort.
Re:Multiplatform? (Score:5, Informative)
Partially true but...
A key issue is that the LibreSSL developers have a different approach to portability than OpenSSL has.
- OpenSSL keeps support for very very old platforms, old compilers, old platform and compiler bugs, etc, etc.
- OpenSSL implements this support by sprinkling the code with different code paths, depending on which platform it's being compiled to.
LibreSSL, like OpenSSH, takes a different approach:
- Aim at a modern platform (OpenBSD) and a modern C dialect.
- Support other platforms by providing implementations of whatever functions are missing on those platforms.
Re:Multiplatform? (Score:5, Informative)
It's in the slides. They stripped out code supporting Win16 (which won't run on modern Windows anyway), and they dropped support for pre OSX versions of Mac OS.
That said currently they are cleaning up and perfecting the code with one and only one sane target in mind, OpenBSD. The goal is to have a very good very secure fork of OpenSSL running on OpenBSD that is fully POSIX compliant. Once that has been achieved porting should be relatively pain free.
Give them time.
Re:Multiplatform? (Score:2, Informative)
I don't know if they removed Windows and OSX support, but it'd be pretty silly if they did.
They removed Windows and Mac OS pre-10 ("Classic"). Mac OS X should be fine, as it's basically Unix/BSD in the user land.
Re:Throwing out all compatibility hooks makes it e (Score:4, Informative)
This is because the C standard is full of crap such as undead(maybe it was half-unsigned?) chars and non-zero NULL and Harvard architecture hacks. If you want to be sure your program will work as intended when some starry-eyed clang/gcc developer reasons he can optimize away your security code because it is undefined behavior, you must support all the brain-dead architectures that motivated the standard, in order to serve as canaries.
This is not related to supporting non-standard shitty libcs and OSes which run on 64-bit architectures and yet do not support 64-bit pointers.
Re:The Linux Foundation is not actually that evil (Score:5, Informative)
Yes, I am extremely annoyed at the misquoting of my presentation, and my slides, by the person who wrote this summary for Slashdot. As I said in the talk, and in the slides, the Linux Foundation has not *yet* committed to support us. Discussions with them are ongoing. Saying that they have somehow "Ignored" us is both slanderous and wrong, and shows exactly what is wrong with Slashdot when they let garbage like this go up. If you have some sort of beef with the Linux Foundation, please take it up on your own time, and use your own name. Don't use mine, or LibreSSL's.
But hey, it's slashdot, everybody expects you to be a dumbass...
-Bob Beck
Please ensure you are actually quoting directly (Score:5, Informative)
I was in this talk, actually the person behind this camera and at no time did Bob state the following above:
Linux Foundation is turning a blind eye to LibreSSL
This is totally incorrect and should be removed. The slide doesn't even state that. Slashdot editorial committee needs to review their posts a lot closer prior to posting in a public space.
Re:Its easy to be critical (Score:3, Informative)
Not me. I'm not guilty. Even responses to requests for help in compiling against OpenSSL were a huge red flag: "If you're not compiling from source, we won't help you." Asking to clarify behavior about things in their API you're linking against was frowned upon, so I go get get the sources, and then I see why they don't want to help anyone -- they don't know how. Told the 3rd party I was contracting for at the time that I would not recommend OpenSSL for future projects, and to use GnuTLS, Mozilla's Network Security Services (NSS) (Apache mod_nss + mod_revocator), or for embedded: PolarSSL or MatrixSSL. When asked why I said the project did not have code quality or standard testing harnesses and that there were many unpatched bugs filed against the system which had gone unfixed for years.
The only people who are guilty are fucking morons. Saying "We're All Guilty" is just blame shifting. I was just building some business logic for a proprietary CMS / Portal and wrote that shit off on my first encounter -- Fuckers actually put OpenSSL on a distro CD for an OS that purports to be security focused. How retarded is that?!
After having more experience with NSS and MatirxSSL and seeing the complexity FUBAR in the entire security theater CA system I've been "rolling my own" security suites despite "common wisdom". That shit doesn't pass as "secure". Honestly I can't fathom why ANY of the OpenSSL codebase is being used in LibreSSL. Implementing these ciphers isn't hard, the math is well understood, the example code is published, and things like side-channel attack mitigation are well documented, if a bit tinfoil hatty (considering the state of end user OS security). The OpenSSL project does deserve bashing. It doesn't even have a proper test harness and unit test with proper code coverage. How can you even tell if both sides of an #ifdef are equivalent, let alone which one is faster? How can a security product be released with ANY untested branches of code?
Given the existing alternatives and reduction in their target platform environments it just seems fucked to me that LibreSSL would use anything other than the header files from OpenSSL. Sorry, anything to do with that cluster fuck is tainted. No amount of "well, you're guilty too" will dissuade me: OpenBSD, you got egg on your face, and you're aiming for more of the same with forking OpenSSL. Oh, wait... None of those SSL libs I mentioned are BSD licensed... Ah, I see. It's fanaticism vs security, round two, fight!
Re:Its easy to be critical (Score:4, Informative)
Oh, wait... None of those SSL libs I mentioned are BSD licensed...
None of those libraries have the same API either.
You are aware that OpenBSD are keeping API compatibility so that the ports tree of all the useful software that people actually want to use keeps running? I mean it's not like people need any of that software or anything.