Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security

LibreSSL Unaffected By DROWN 60

serviscope_minor writes: The OpenBSD people forked and heavily cleaned up OpenSSL to create LibreSSL due to dissatisfaction with the maintainance of OpenSSL, culminating in the heartbleed bug. The emphasis has been on cleaning up the code and improving security, which includes removing things such as SSL2 which has fundamental security flaws. As a result, LibreSSL is not affected by the DROWN bug. LibreSSL is largely compatible with OpenSSL. The main exceptions are in the cases where programs use insecure functions removed from libreSSL, or require bug compatiblity with OpenSSL.
This discussion has been archived. No new comments can be posted.

LibreSSL Unaffected By DROWN

Comments Filter:
  • by Anonymous Coward on Wednesday March 02, 2016 @12:21PM (#51622723)

    Removing old code is the best feeling in the world - it's kind of like spring cleaning!

  • by Anonymous Coward

    I abandoned Linux in favor of OpenBSD earlier this year. I'm tired of how spread thin Linux developers on some projects have become and/or how complacent. My needs are minimal albeit specialized, so I need developers who actually care about code quality. Theo and team most certainly care about code quality. I've given up a little in the transition to BSD, but the stability, predictability, and ease of use have won me over. I started looking at OpenBSD seriously in 2001, but never made the jump. Better late

    • Re: (Score:1, Insightful)

      by Anonymous Coward
      The perpetual drive to bring Linux "to the desktop" and to compete with much more visually polished OS's such as MacOS and Windows has caused Linux devs to abandon the original project priorities and go chasing shiny things and add too much bloat, because somebody somewhere things that is what people care about. Linux shouldn't be about trying to catch up to or compete with the commercial OS, it should be about making sure it does what it is good at flawlessly and securely. Security concerns are only goin
      • by gwolf ( 26339 )

        You say, original project priorities?
        As a Debian Developer, I can assure you, there are no original project priorities to speak of.
        Each one of us has their own priorities. The nice and happy thing is that many of those priorities have huge areas of overlap, so our common prioritarial prerequisites are a *very* large area.
        Add more, more people to the mix — Everybody in this boat needs a stable, reliable, fast, friendly operating system, with a decent package management software that can empower each of

    • by mlw4428 ( 1029576 ) on Wednesday March 02, 2016 @12:45PM (#51622881)
      The team working on OpenSSL is not the same team working on Linux. This is like being upset because the Photoshop team is thin on resources so you dump Windows. It's, frankly, a stupid thing to think.
      • Re: (Score:2, Interesting)

        by Anonymous Coward

        OP here... You miss my gist. Linux and attending userland software, of which OpenSSL is but one, are having massive quality control issues compared with the BSDs. I've been a Linux user on the server and desktop since the mid 90s. I've administered BSD servers since 2000. In 2001, I considered moving my personal requirements over the Linux, as I mentioned above, but never pulled the trigger. A host of things has made me re-think my position: systemd, the Debian developers debacles, general Balkanization of

      • by Anonymous Coward

        You missed the point, and so did the idiots who upmodded you.

        It doesn't matter who originally wrote the code.

        What matters is that so many Linux distro maintainers included the broken OpenSSL code in their distros, which directly affected the users of these Linux distros.

        Yet the OpenBSD maintainers, who clearly care far more about security than the Linux distro maintainers do, went out of their way to clean up and secure the broken OpenSSL code, and so OpenBSD users aren't affected by this serious flaw.

        That'

        • by CoderJoe ( 97563 ) *

          And what library did OpenBSD use for SSL/TLS before LibreSSL? Oh wait, it was that same OpenSSL as Linux, until Heartbleed caused them to fork the project and clean it up.

      • by Bengie ( 1121981 )
        Not the same team, but part of the same community and mindset that enables such poor quality code to exist.

        *I use "Linux" to mean the Linux community, and not the kernel, which is of decent standards.
        • Wait? What community? The Linux one? So are the LibreSSL guys not part of the Linux community anymore? What about the PolarSSL guys? The "Linux community" deals with Linux and arguably each distro is a subset of that community. The third-party packages (or rather the developers of those packages) aren't. At best they just work with the Linux community when needed (testing, getting the updates shipped, etc).
          • So are the LibreSSL guys not part of the Linux community anymore?

            I don't know that I'd say that OpenSSL is part of the Linux community, but LibreSSL definitely is not, since it's developed by the OpenBSD team.

  • by Anonymous Coward

    `Why is this newsworthy? "This just in: software without a feature doesn't have vulnerability related to said feature."

    • Re: (Score:1, Interesting)

      by Anonymous Coward

      I found it informative. You're just mad the OpenBSD people produce better code.

      • Re: (Score:2, Informative)

        They don't produce better code. LibreSSL is not vulnerable because LibreSSL is OpenSSL with SSLv2 turned off; they just deleted a feature. You can't compile it in, whereas on OpenSSL you have the option to run without SSLv2.

        OpenBSD LibreSSL is largely OpenSSL, and the part that has the vulnerability was *removed* rather than fixed. You might as well say a fork of Firefox has better code because it has no JavaScript engine and thus isn't vulnerable to Spidermonkey bugs.

        • by Anonymous Coward on Wednesday March 02, 2016 @01:28PM (#51623235)

          Removing support for an inherently broken and insecure feature is tantamount to writing better code.

        • by Anonymous Coward

          I would vociferously argue that, in fact, OpenBSD does produce superior code as a rule. Look at OpenBSD, OpenSSH, or any of the other software titles Theo and team write and support and compare those to Linux, or Gnome, or any other project. Theo and his guys care deeply about code auditing, something most Linux and Linux userland software devs regularly pass over or simply don't care.

        • OpenBSD team does produce better and new SSL code, you should research before asserting nonsense https://en.wikipedia.org/wiki/... [wikipedia.org]
          • More clearly: LibreSSL is immune to DROWN because they removed--not improved--the SSLv2 protocol handling code.

            Wikipedia says LibreSSL's "better SSL code" is mostly code pruning, with a close second being breaking and then fixing OpenSSL cross-platform portability. If you check the actual LibreSSL repositories, you'll notice an extreme minority of LibreSSL changes--by code volume and by actual commits--are code clean-up, and an even smaller minority are actual defect repair. Mostly, it's gutting.

        • by stooo ( 2202012 )

          >> LibreSSL is OpenSSL with SSLv2 turned off
          No. it isn't that.
          It's a complete rework and cleanup of much of the codebase

          • More clearly: In this case, it doesn't have the DROWN vulnerability because they deleted the SSLv2 protocol code. They did *not* improve the SSLv2 protocol code.

    • More accurately: "Software without an inherently vulnerable feature doesn't have vulnerability related to said feature."

  • Same for BoringSSL (Score:4, Informative)

    by Shawn Willden ( 2914343 ) on Wednesday March 02, 2016 @12:48PM (#51622893)

    BoringSSL is Google's internal fork of OpenSSL (though it's open source [googlesource.com]). It also removed all support for SSLv2 some time ago. Or, more accurately, it the SSLv2 implementation was never added to it.

    https://www.imperialviolet.org/2015/10/17/boringssl.html

    • BoringSSL is Google's internal fork of OpenSSL (though it's open source). It also removed all support for SSLv2 some time ago. Or, more accurately, it the SSLv2 implementation was never added to it.

      I don't quite follow: if it was a fork it would have come with SSLv2 since OpenSSL comes with it. How can it have not been added in the first place?

      • by Shawn Willden ( 2914343 ) on Wednesday March 02, 2016 @02:09PM (#51623541)

        BoringSSL is Google's internal fork of OpenSSL (though it's open source). It also removed all support for SSLv2 some time ago. Or, more accurately, it the SSLv2 implementation was never added to it.

        I don't quite follow: if it was a fork it would have come with SSLv2 since OpenSSL comes with it. How can it have not been added in the first place?

        From the blog post that I linked:

        Generally when people say “forking” they mean that they took a copy of the code and started landing patches independently of the original source. That's not what we did with BoringSSL. Rather than start with a copy, I started with an empty directory and went through OpenSSL function-by-function, reformatting, cleaning up (sometimes discarding) and documenting each one.

        However, Adam did say that the SSL code was handled a bit differently, it was copied then incrementally improved, and the improvements included removing SSLv2 support. So my claim that SSLv2 was never added to BoringSSL was wrong. It was copied over from OpenSSL, then removed.

  • Please stop (Score:5, Insightful)

    by WaffleMonster ( 969671 ) on Wednesday March 02, 2016 @01:05PM (#51623047)

    It's 2016.. If your in any way affected by SSLv2 + export ciphers and you still feel compelled to blame it on the TLS stack - please do everyone a favor and find a new line of work.

    • by illtud ( 115152 )

      But this attack works on OpenSSL with all SSLv2 ciphers removed, does it not? You need the fixed version with the capability to use SSLv2 ciphers removed, it wasn't fixable by configuration, from what I've understood.

    • It's 2016.. If your in any way affected by SSLv2 + export ciphers and you still feel compelled to blame it on the TLS stack - please do everyone a favor and find a new line of work.

      Fuck you. My employer's IoT trash cans are not flashable, and all of my skills are janitorial in nature. That's like telling a cancer patient to find another lung.

  • Any sane SSL configuration explicitly disable SSLv2 (and SSLv3) and is therefore not vulnerable to DROWN.

"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell

Working...