Slashdot Mirror


LibreSSL Unaffected By DROWN

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.

34 of 60 comments (clear)

  1. See what happens when you rm -frv *_old.c by Anonymous Coward · · Score: 3, Insightful

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

  2. Another Fine Reason... by Anonymous Coward · · Score: 2, Interesting

    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 than never...

    1. Re:Another Fine Reason... by Anonymous Coward · · Score: 1, Insightful

      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 going to increase as we move forward and more and more of our lives and data are connected to the internet.

    2. Re:Another Fine Reason... by mlw4428 · · Score: 4, Insightful

      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.

    3. Re:Another Fine Reason... by Anonymous Coward · · Score: 2, Interesting

      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 Linux streams of thought on things that really do affect the direction of the kernel and various distros. It's all become too much. I want what I stated above: stability, predictability, and ease of use. OpenBSD and FreeBSD give me this, and after years of working with FreeBSD on servers, I admire the robustness and simplicity of administration compared to Linux. I chose OpenBSD for myself because of OpenBSD's fantastic laptop support for things like wireless chipsets, suspend, etc. I also like their more rapid development model (every 6 months).

    4. Re:Another Fine Reason... by Bengie · · Score: 1

      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.

    5. Re:Another Fine Reason... by mlw4428 · · Score: 2

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

    6. Re:Another Fine Reason... by shawn2772 · · Score: 1

      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.

    7. Re:Another Fine Reason... by gwolf · · Score: 2

      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 us to scratch our personal itches.
      Very few people have my very specific itch, and that's the reason some of my packages are maintained by myself only.
      If you were to see my work environment, you will recognize this particular developer is nowhere near the "shiny things" or "bloated environments", and my environment is quite typical to others I've seen at DebConfs. Of course, I also see lots of GNOMEs, and there's no reason to deny an important reason for GNOME to be default is because many people like it and care for it enough to keep it in good shape.

  3. Why is this newsworthy? by Anonymous Coward · · Score: 1, Insightful

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

    1. Re:Why is this newsworthy? by Anonymous Coward · · Score: 1, Interesting

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

    2. Re:Why is this newsworthy? by bluefoxlucid · · Score: 1, 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.

    3. Re: Why is this newsworthy? by Anonymous Coward · · Score: 4, Insightful

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

    4. Re:Why is this newsworthy? by Anonymous Coward · · Score: 1

      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.

    5. Re: Why is this newsworthy? by Anonymous Coward · · Score: 2, Funny

      No, it means you need to use broken, insecure, obsolete software to manage your broken, insecure, obsolete hardware.

    6. Re:Why is this newsworthy? by ralphsiegler · · Score: 1

      OpenBSD team does produce better and new SSL code, you should research before asserting nonsense https://en.wikipedia.org/wiki/...

    7. Re:Why is this newsworthy? by stooo · · Score: 1

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

      --
      aaaaaaa
    8. Re:Why is this newsworthy? by Chris+Mattern · · Score: 1

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

    9. Re:Why is this newsworthy? by greenfruitsalad · · Score: 1

      better at the substantially limited range and scope of functions. i've tried switching to BSD several times over the last 15 years. apart from speed of networking and (recently) ZFS, pretty much everything else was significantly poorer than its gnu/linux alternative. starting with gnu tools (vs bsd tools), drivers and ending with virtualisation, desktop software and clustering. unless i was building a firewall or a router, gnu/linux was the better option.

    10. Re:Why is this newsworthy? by bluefoxlucid · · Score: 1

      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.

    11. Re:Why is this newsworthy? by bluefoxlucid · · Score: 1

      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.

  4. Re:USE OPENBSD IF YOU WANT SECURE SERVERS by Aethedor · · Score: 1, Offtopic

    Use any other OS if you want to post messages without capitals.

    --
    It doesn't have to be like this. All we need to do is make sure we keep talking.
  5. Same for BoringSSL by shawn2772 · · Score: 3, Informative

    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.

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

    1. Re:Same for BoringSSL by serviscope_minor · · Score: 2

      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?

      --
      SJW n. One who posts facts.
    2. Re:Same for BoringSSL by shawn2772 · · Score: 3, Informative

      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.

  6. OpenVMS by ArchieBunker · · Score: 2

    OpenVMS is not case sensitive. For critical applications I'd pick it over Linux any day.

    --
    Only the State obtains its revenue by coercion. - Murray Rothbard
    1. Re:OpenVMS by greenfruitsalad · · Score: 1

      i don't think you would. btw, are we talking about ODS-2 or ODS-5 file naming?

  7. Please stop by WaffleMonster · · Score: 4, Insightful

    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.

    1. Re:Please stop by illtud · · Score: 1

      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.

    2. Re:Please stop by Bite+The+Pillow · · Score: 1

      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.

  8. Way to miss the point! by Anonymous Coward · · Score: 3, Insightful

    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's the point the GP was making: Linux distro maintainers will subject their users to any old shitty code. The OpenBSD maintainers, on the other hand, are far more cautious and don't put their users in the bad position that the Linux distro maintainers do.

    This incident shows that we can trust OpenBSD, and that we just can't trust most Linux distros.

    1. Re:Way to miss the point! by CoderJoe · · Score: 1

      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.

  9. Re:Narcissist much? by Bengie · · Score: 1

    Fixing OpenSSL is a futile endeavor of polishing crap. Some things can only be fixed by being taken out back.

  10. Any sane configuration is unaffected by manu0601 · · Score: 1

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