Slashdot Mirror
30-Day Status Update On LibreSSL
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.
https://youtu.be/GnBbhXBDmwU
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.
if its a festering insecure pile of shit who cares if it runs on more platforms? got to start over at some point, maybe work on a better foundation before more platforms...
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.
Like the big-endian x86 support in OpenSSL?
OpenBSD's OpenSSH has a separate portability layer, and they're doing just fine without the extra malloc wrappers. And no big-endian x86 support, either!
These guys are just awesome!!! I am so grateful to the OpenBSD team for taking this on. I'm going to back up being grateful by supporting this team in any manner that I am able to, and also try to find a way to support their efforts. Be it pizza, donating cash, or maybe even help them test their latest patches and provide any feedback I can.
they're mostly throwing out really old multi-platform stuff, like dos, vms, ebcdic, win16 etc.
This is a joke. I am joking. Joke joke joke.
The goals of LibreSSL include preserving API/ABI compatibility (keeping LibreSSL as a drop-in replacement).
The thing about OpenSSL et al is that everyone who used it had exactly the same opportunity to review the code and make a decision about its use.
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.
They did, this is BSD compatible only.
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....
The assertion in the OP is that OpenSSL is run for profit by guys who don't necessarily know security. My own experience with security gurus is the same as GP's; they talk in jargon and blow a lot of smoke.
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.
There's no place I could be, since I've found Serenity...
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.
It does indeed appear to be OpenBSD only at present (from http://www.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.
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.
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.
Military grade encryption
I've actually been in the military (more than a decade ago), and had contact with "top of the line" encryption systems. At the time, I was already using for myself OpenBSD and actual strong encryption. "Military Grade" is like the "Bio" sticker in food - a way of charging more for worthless shit.
I could see being an OpenSSL guy would be a huge one
I don't. OpenSSL has always been the disaster waiting to happen. The codebase is messy, no one really understands it, and there is no real criteria when adding stuff. I have no experience with it and I knew it was a big pile of stinking poo (its not like this hasn't been a probem before), so I hardly doubt that saying you're an OpenSSL dev would give anyone any credit.
Usually have a Novell certification in some drawer and will defend Novell to this day.
I'm not Novell certified (nor a security expert), but Novell DID have his awesomeness - at some level, unmatched today.
I do agree with most of what you said, but the problem is two-fold: actual security experts are either matematicians or hardcore developers, and more often than not, cannot communicate with regular people. And no, this is not a feature. Transmiting a concrete idea to a peer without noise is the ultimate developer experience - you need to develop a subset of the language that allows you to carry your own message without being subject to change on the endpoint; And because most of the guys entwined with computers are too tied in the digital all-or-nothing approach, they think its not their fault they cannot operate on an analog world. Which, by itself, is hilarious, because "digital computers" are actually a subset of the computing field.
In short, the problem is the nerd type. Get rid of them, have them behave and communicate like regular people, and all these bs types are out of a job. And for Pete's sake, its not like most of what is CS is hard.
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.
API/ABI compatibility is not the same as cross platform compatibility: the difficulties with 'malloc' incompatibility that led to replace a core libc function clal are precisely the sort of thing that the LibreSSL developers can simply throw out. Replacing it for cross-platform is an excellent example of the difficulties of just such cross compatibility work: preserving the ABI for some of the odder platforms on which OpenSSL currently works is precisely the cross-platform work that the LibreSSL developers can discard. And yes, it will speed the performance of the code. (Rewriting and replacing malloc for cross-compatibility is _guaranteed_ to be slower than native libc functions.)
I'm not suggesting that OpenSSL did not need a stripping of debris and a rewrite. I'm suggesting that if you ignore cross-compatibility and the installled user base, it's much easier to clean up old code.
No it's not, it is stated quite clearly that it is written for OpenBSD. OpenBSD is mostly "POSIX-compatible" but they aren't too shy to extend libc when there isn't a good alternative. The slides and the talk mention strlcpy/cat(unfortunately ignored by C11 but widely adopted everywhere but GLIBC) and reallocarray. Only obliquely referenced is a proper kernel API (P)RNG which is not available in most platforms(using /dev/*.random instead, which has many issues[1]).
However, like OpenSSH, you can expect the LibreSSL portability team to write wrappers to make the best of what there is in your OS. As opposed to the best Win16 could do.
[1] http://insanecoding.blogspot.j...
10 little-endian boys went out to dine, a big-endian carp ate one, and then there were -246.
Bang on. I have looked at the OpenSSL code and what I saw was terrible. It was a laundry list of not just bad coding practices but bad coding so bad that people don't even have terms for it. But as for communications I would think that upper management would be better with bad communications than with lies and over billing.
The real problem is that truly great security is invisible. But it is easier to look cool with heroic security. It is like people believing that medicine has to taste bad and have nasty side effects to work.
One of my favorite complaints about fake good security is when IT department implement complicated password regimes. Basically H@v1ng C0mp1icAted passwords is not actually mathematically sound. Long passwords are the real key. So complicateddogpassword is a zillion times better than insisting upon upper/lower/special characters. And then insisting upon changing the password regularly is about the stupidest thing ever. For one this costs a lot of money. The time wasted across a large company can easily be massive and a business decision not a technical one. Also companies that have frequent password changes then have frequent password forgetting, this then opens up a huge social networking hole.
I made a bet with a relative who works for government where they recently implemented monthly password changes that I could socially hack his password with only the contents of his wallet and his last pay stub. First I looked around his desk, under his keyboard, etc, Then I phoned into IT and said that I was him and that I forgot my password. They then walked me through inputting a new one no questions asked. I asked how they knew I was him and they said, because of what number I was phoning from. I then asked but what if I called from home and they said, oh they would have asked maybe my birthdate or something.
Then we walked around the office (it was a Sunday) and found some passwords on post-it notes and written on the bottom of keyboards. BTW his office processes documents that would be financially worthwhile for unscrupulous parties to obtain.
It's a matter of mistranslation. In Canadian, "Fuck off or I'll beat you with a hockey stick!" means "We would like to help you with your problem. However, I'm afraid the solution you are proposing would not work for the reasons we have already stated on a previous correspondence[3]. Maybe we could work together in the future.".
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.
Interestingly enough, that principle doesn't apply to OpenBSD itself, which considers it important to support dead platforms like the Alpha.
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.
10 little-endian boys went out to dine, a big-endian carp ate one, and then there were -246.
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
Wonder if the OpenSSL guys have a good consulting business maintaining exactly those ports for ancient government projects.
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).
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.
I think people forget that GNU has their own communications library for secure sockets... [url=http://www.gnutls.org/]GnuTLS[/url].
I know why OpenBSD won't use it (because it's LGPL), but why won't anyone else?
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
It does indeed appear to be OpenBSD only at present (from http://www.libressl.org/ ):
... and not really that multiplatform for future development, either, since it requires (as per the linked slide)
Modern C string capabilities (strl[cat,cpy]) asprintf etc.
None of the quoted functions are standard C and strl* are BSD-only - yay for GNU-BSD strn*/strl* string function wars :(
It's all nice and good practice that they want to use the best tools available to them on OpenBSD, but not caring for what's available on other platforms is not really how one does portability and *will* produce forks, regardless how much the LibreSSL authors want to 'discourage' it.
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.
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.
SJW n. One who posts facts.
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.
SJW n. One who posts facts.
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.
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.
Since 2007, OpenSSH has had 11 CVEs issued, while OpenSSL has had 61:
http://www.cvedetails.com/vendor/7161/Openssh.html
http://www.cvedetails.com/vendor/217/Openssl.html
In that time: OpenSSH's worst CVE score was a single 7.5 in 2007; OpenSSL has had six 7.5s, one 9.3, and one 10.0 scored CVEs. Note that Heartbleed (CVE-2014-0160) is rated as a 5.0.
If you check the slides, there are a few areas that they failed hard on. I don't know if you're a C developer, but I've coded a bit, and the slides scared me a bit.
Yeah, there was the "cross platform" stuff. Do we really need EBCDIC support? There's a simple rule about code. If you can't test it, you should pull it. Do you have a machine you can test on? They had Win32 Winsock code, which is a special case. But all modern Windows computers have a Berkely sockets type stack. This doesn't need special code, which means a lot less code to debug.
When the OpenSSL guys state (with some justification) that they have no resources, part of the problem is they waste it by having unused code paths. They'd save some testing time by having removed this code before.
But they also did "cross platform" it badly. They had their own printf, when printf has been done and safe for years. But just in case on some oddball platform, we have our own. They had 17 levels of nested #ifdef. If you don't know C, that's SCARY. There's no way you'd unwind that in your head, and there's near zero chance you'd be able to code a test plan for that. Why? Because you can think of #ifdef as a way of doing simple code modification... 17 levels deep of this type of modification is near impossible to think through and is nearly guaranteed for bugs.
Worst of all, in name of one platform, they came out with an oddball memory allocator. They added things to this allocator to the point where they couldn't run a normal one. Worse off? They got so used to BUGS in this allocator that they couldn't move off of it. And these bugs are directly related to the Heartbleed bug - it's a memory management bug. Instead of thinking "hey, we're doing a lot of weird stuff just for this odd platform" they made the decision "hey, lets go even deeper down the hole of bad code"
So, in name of "cross platform" they had many many design mistakes, including something that broke much of HTTPS. I wouldn't use "they were doing cross platform" as an excuse for their mistakes, because in this name, they had made much of their mistakes.
This wasn't in some text editor. This was in a piece of core crypto. The level of sloppiness allowed is zero.
They OpenBSD folks take their tone from Theo De Raadt, who generally is one of the ruder people out there. When i first heard the rants about OpenSSL, i was thinking "well, they didn't have to smack them down so hard." After reading the slides, Im thinking "yeah, I'd rant that hard" though i don't have the same Forum as the LibreSSL guys have.
Besides the "what if someone fucks with /dev/random" issues, there are problems like "what if the sysadmin forgets to create /dev/random in chroot" (ok, sysadmin failure but it can be protected against - and better to fail hard than fallback to a bad entropy source) and especially "what if an attacker holds open a bunch of FDs so opening /dev/random fails". This last one is perhaps the most worrying.