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.

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

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

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

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

  4. 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
  5. 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.

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

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

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