Slashdot Mirror

← Back to Stories (view on slashdot.org)

No More Security Fixes For Older OpenSSL Branches (csoonline.com)

Posted by timothy on from the son-you're-on-your-own dept.

itwbennett writes: The OpenSSL Software Foundation has released new patches for the popular open-source cryptographic library, but for two of its older branches, OpenSSL 1.0.0t and 0.9.8zh, they will likely be the last security updates because support for these these two branches will end on Dec. 31. Previous research has shown that many companies using in-house built software keep poor records of which library versions their developers used in which of their applications. 'This makes it very likely that some systems and applications with OpenSSL 0.9.8 and 1.0.0 will never be updated, leaving them exposed to any critical vulnerabilities found in the library in the future,' writes Lucian Constantin.

8 of 60 comments (clear)

  1. Re:This is awful and irresponsible. by Aethedor · · Score: 2

    Sticking with OpenSSL while other more secure and reliable SSL/TLS libraries exist, that's awful and irresponsible. I switched to mbed TLS (former PolarSSL) years ago and never cared to look back. I seriously can't understand why developers keep on using OpenSSL.

    --
    It doesn't have to be like this. All we need to do is make sure we keep talking.
  2. Re:This is awful and irresponsible. by AchilleTalon · · Score: 3, Insightful

    I don't believe the problem software will percolate up to the users' attention given the very root problem is companies using in-house software DO NOT keep track of what version of OpenSSL their own developers are using. So, even if you patch the old versions, you have absolutely no guarantee your own developers will use the patched version. So, given this, why should OpenSSL developers continue to patch OLD versions which NOBODY keeps track? Seems to me waste of time and resources that could be dedicated to the latest versions instead. It takes two to tango. The security problem is not only on the OpenSSL developers team's shoulders. My experience, is in-house developers don't give a fuck about security unless you force them, and even it that case, they are often doing it wrong.

    --
    Achille Talon
    Hop!
  3. Re: This is awful and irresponsible. by kthreadd · · Score: 2

    I would guess most of those web sites are running on GNU/Linux with OpenJDK which is supported. Both OpenJDK 6 and 7 are still supported. It's only the binaries that you get from Oracle that aren't supported anymore, at least not without a support contract.

  4. Re: No worries by kthreadd · · Score: 2

    There is no Ubuntu LTS using one of the unsupported branches. Ubuntu 10.04 was the last one using the 0.9.8 branch and Ubuntu dropped support for it in April. Ubuntu 12.04 and 14.04 uses the 1.0.1 branch which is still supported by upstream.

  5. Still on Windows 95? 1.0.0 was replaced in 1998 by raymorris · · Score: 3, Informative

    1.0.0 which is no longer being updated, was replaced by 1.0.1 in December of 1998. In other words, if you want to be secure, use a version from 1998 or later.

    That seems pretty reasonable to me.

  6. Re: Still on Windows 95? 1.0.0 was replaced in 199 by kthreadd · · Score: 3, Informative

    If you're talking about OpenSSL then you're off by a decade. 1.0.0 was released in 2010.

  7. misread. 1.0.1 (supported) is March 2012 by raymorris · · Score: 2

    You're correct, I read something wrong. 1.0.1, which is supported, is from March 2012.

    1. Re: misread. 1.0.1 (supported) is March 2012 by kthreadd · · Score: 2

      New versions of OpenSSL are in general source compatible with older versions. They are however not necessarily binary compatible. That means that you have to rebuild your program when going from OpenSSL 0.9.8 to 1.0.2 but in general without any source changes. OpenSSL has an unusual version numbering where 0.9.7, 0.9.8, 1.0.0, 1.0.1 and 1.0.2 are different major versions. 0.9.7, 0.9.8 and 1.0.0 are binary incompatible but starting with 1.0.0 all 1.0.x releases have been binary compatible.