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.

Re:Video of the presentation

[Anonymous Coward]

Go go go LibreSSL, you guys have my complete support!!! I've filed four bugs and two enhancements with OpenSSL over the years, and all of them have been ignored by the OpenSSL devs. That's lame. I knew OpenSSL was a festering crock of shit, but what were we to do. Now we have LibreSSL and I would encourage everyone to send support, even if only just a pizza, and use LibreSSL.

Fake Security Gurus

[EmperorOfCanada]

I have met many security "Gurus" over the years who's primary skill is convincing Baby boomer management types that only they can save them. They then start spouting all the usual things like PKI infrastructure. Military grade encryption, Don't roll your own, industry standard, certified, obfuscation is not security, end to end encryption, and so on with little regard to properly implementing this stuff and generally no regard as to the business needs.

They will do an audit that will show that Russians and Chinese are trying to get into their servers hundreds of times a day and that it is only a matter of time before they do.

Often one of the first things these guys will do "after getting the billing spigot turned on" is to start pushing hardware that gives them the largest kickbacks and ideally require a certification they happen to hold and the IT people don't. So if the system uses switch A they will say switch A is vulnerable and prove it by showing the 10,000 security patches that company has been "forced" to release over the years. So they will install switch B. But if the company uses switch B then they will go with switch A.

The greatest part is that they effectively can deliver nothing but a pain in the ass and look like a hero. "I set up your IPTables to block a custom series of threats my company has identified (Boca Raton)" and if they are really good they will cut off access from root from the company's own administrators.

Often these Guru's entire credibility is based upon some nebulous activity in the past. I could see being an OpenSSL guy would be a huge one. I have long suspected that the main guys at OpenSSL have been spending most of their time giving keynote addresses and rounding up the consulting bucks. I am glad now that anyone who was associated with that project now basically has doggy doo doo on their faces and look like halfwits.

I have worked with these types of guys and they even tend to fall into 3 basic body types. There is the ex-cop looking guy, 50, 5 foot 6, white hair, moustache, round head, round body and talks like they are god's gift to security; these types will use obscure systems that nobody knows so nobody can easily call them on their BS; also these people came into their own in the Y2K days. Then there is the quasi hippy, Longer hair (still balding) not enough light, often thinks they are god's gift to women and security and will give endless advice on both. Usually have a Novell certification in some drawer and will defend Novell to this day. Then lastly there is the fat slob security guy. This one usually works with one of the other two. They are a half assed in nearly everything they do and only manage to keep the demons away by being in the server room 24/7. These people have built their credentials 100% by putting down other people and their technologies. The worst part about this last type is that sometimes they are actually quite skilled but do everything in as stupid way. "Oh I had to rewrite the Linux kernal using code from my wristwatch to make for a better time function for the random number generator. The only problem is that I have to manually reset it every 15 minutes.

Re:Fake Security Gurus

[rev0lt]

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.

Re:Throwing out all compatibility hooks makes it e

[Antique Geekmeister]

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.

Re:Fake Security Gurus

[EmperorOfCanada]

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.

Re:Multiplatform?

[Too Much Noise]

It does indeed appear to be OpenBSD only at present (from http://www.libressl.org/ [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.

Re:So, what about GnuTLS?

[RR]

You mean this GnuTLS? [arstechnica.com] (It had a "goto cleanup" bug similar to Apple's "goto fail" bug.) It isn't API compatible with OpenSSL, and OpenSSL came first. OpenSSL has first mover advantage, and more people are paranoid about GPL, even if it's LGPL.

The consensus among security experts seems to be that TLS (the protocol itself) sucks, OpenSSL sucks, GnuTLS sucks, NSS sucks, and TLS has horrible compatibility problems between implementations. They aren't giving us a lot of options, here.

So, I find it fascinating that OpenBSD is taking OpenSSL (which sucks) and trying to make LibreSSL into something that doesn't suck. I wish them the best of luck and funding.

Security: OpenSSH vs OpenSSL CVEs

[Anonymous Coward]

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.