Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Encryption Security

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.
This discussion has been archived. No new comments can be posted.

30-Day Status Update On LibreSSL

Comments Filter:
  • by Antique Geekmeister ( 740220 ) on Saturday May 17, 2014 @07:28PM (#47028501)

    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)

    by im_thatoneguy ( 819432 ) on Saturday May 17, 2014 @07:32PM (#47028515)

    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.

  • by sulfide ( 1382739 ) on Saturday May 17, 2014 @07:34PM (#47028521)
    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...
  • by Megan Woods ( 2920951 ) on Saturday May 17, 2014 @08:01PM (#47028629)
    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.
  • by tomhath ( 637240 ) on Saturday May 17, 2014 @08:12PM (#47028687)
    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.
  • by Anonymous Coward on Saturday May 17, 2014 @08:47PM (#47028899)
    the bashing is legitimate when you consider that they themselves admit so much of their time was devoted to private & for-profit projects that they couldn't give the codebase proper attention and person-power, allowing it to get so bad that experienced coders had a difficult time deciphering it (no pun originally intended) If they were able to admit that themselves, then responsibly they should have immediately slammed the brakes for a proper code review, and told all clients "X amount of your money will now directly support maintaining the codebase, don't like it? tough. this is important.". It doesn't sound like that happened at all, it was sail-till-it-sinks. These projects are too important to be poorly managed - if you can't do it right STOP. Simple fact is, They let it get out of hand. The bug tracker alone shows the community tried to step up and do its part.
  • by the_B0fh ( 208483 ) on Sunday May 18, 2014 @12:21AM (#47029779) Homepage

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

  • by Anonymous Coward on Sunday May 18, 2014 @03:49AM (#47030253)

    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.

  • by serviscope_minor ( 664417 ) on Sunday May 18, 2014 @04:38AM (#47030327) Journal

    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)

    by serviscope_minor ( 664417 ) on Sunday May 18, 2014 @04:54AM (#47030363) Journal

    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
    * Open /prov/pid/mem and read your program memory
    * Same, but writing it to compromise the RNG
    * Do the same to the /dev/kmem to compromise the RNG for builtin crypto
    * Load a kernel module
    * Screw with /vmlinuz or whatever and reboot
    * 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.

  • by gnasher719 ( 869701 ) on Sunday May 18, 2014 @05:44AM (#47030447)

    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.

Always leave room to add an explanation if it doesn't work out.