Slashdot Mirror


OpenSSL 1.0.2 Released

kthreadd writes The OpenSSL project has released its second feature release of the OpenSSL 1.0 series, version 1.0.2 which is ABI compatible with the 1.0.0 and 1.0.1 series. Major new features in this release include Suite B support for TLS 1.2 and DTLS 1.2 and support for DTLS 1.2. selection. Other major changes include TLS automatic EC curve selection, an API to set TLS supported signature algorithms and curves, the SSL_CONF configuration API, support for TLS Brainpool, support for ALPN and support for CMS support for RSA-PSS, RSA-OAEP, ECDH and X9.42 DH.

23 of 97 comments (clear)

  1. libressl-2.1.3 by Anonymous Coward · · Score: 2, Informative
    1. Re:libressl-2.1.3 by Anon+E.+Muss · · Score: 5, Insightful

      libressl is NOT portable. Supporting BSD and Linux is not the definition of "portable" (see also: "We play both types of music: Country and Western"). The libressl code depends on the non-standard #include_next preprocessor directive, so it can only build with GCC (and probably clang, which emulates many GCC-isms). Forget about building on Windows using Microsoft's C compiler.

      OpenSSL remains the only portable SSL library that can be used by both open source and commercial developers alike. Which is really a shame, because OpenSSL sucks. All the bad things the libressl people have said about OpenSSL are absolutely true.

      --
      The key sequence to access my Slashdot bookmark in Firefox is Alt-B-S. I don't believe this is a coincidence.
    2. Re:libressl-2.1.3 by ron_ivi · · Score: 3, Insightful

      NOT portable .... Forget about building on Windows using Microsoft's C compiler.

      Just because one compiler for one platform fails to support a popular C extension doesn't mean the library isn't portable.

      You can always choose to complie on that platform using one of the compliers that *does* support the extension.

    3. Re:libressl-2.1.3 by armanox · · Score: 5, Informative

      Actually, libressl supports OS X and HP-UX as well. Some groundwork is in place for supporting AIX and IRIX (I no longer have access to AIX to continue porting, and I'm not sure IRIX will ever work right). If you really wanted it to work with MSVC, you could write, test, and propose the patches to make it work. I'm all for eliminating GCCisms (the areas I've been poking at the code I'm not trying to eliminate GCCisms, not my priority).

      --
      I'm starting to think GNU is the problem with "GNU/Linux" these days.
    4. Re:libressl-2.1.3 by armanox · · Score: 2

      I forgot Solaris in the supported list! Tested on Solaris 10-11.

      --
      I'm starting to think GNU is the problem with "GNU/Linux" these days.
    5. Re:libressl-2.1.3 by MSG · · Score: 2

      OpenSSL remains the only portable SSL library that can be used by both open source and commercial developers alike

      Kind of. Its license actually isn't compatible with the GPL, so there's a whole lot of Free Software developers that can't use it.

    6. Re:libressl-2.1.3 by peppepz · · Score: 5, Interesting

      OpenSSL remains the only portable SSL library that can be used by both open source and commercial developers alike. Which is really a shame, because OpenSSL sucks. All the bad things the libressl people have said about OpenSSL are absolutely true.

      We have GnuTLS which is only one year younger than OpenSSL, has a nicer API, is portable to Windows, has a better track record with regard to binary compatibility, a better build system, and can be used by commercial software (it’s LGPLv2.1). Comparison of features with other SSL libraries.

    7. Re:libressl-2.1.3 by Carewolf · · Score: 2

      OpenSSL remains the only portable SSL library that can be used by both open source and commercial developers alike. Which is really a shame, because OpenSSL sucks. All the bad things the libressl people have said about OpenSSL are absolutely true.

      We have GnuTLS which is only one year younger than OpenSSL, has a nicer API, is portable to Windows, has a better track record with regard to binary compatibility, a better build system, and can be used by commercial software (it’s LGPLv2.1). Comparison of features with other SSL libraries.

      It also has a much worse track record in security, which is why no one uses it as the a primary SSL library and only as a library for operating on certificates.

  2. Obligatory reminder that an alternative exists by Rinisari · · Score: 2, Informative
    1. Re:Obligatory reminder that an alternative exists by Anonymous Coward · · Score: 4, Interesting

      http://www.libressl.org/

      That site doesn't support SSL...

    2. Re:Obligatory reminder that an alternative exists by Aethedor · · Score: 4, Informative

      Why start with something bad to make something good. If you want a good SSL library, try PolarSSL. It's a quite unknown, but great library. Unlike OpenSSL, this one has good documentation. The Hiawatha webserver uses it and it easily gives me an A+ score at SSL labs.

      --
      It doesn't have to be like this. All we need to do is make sure we keep talking.
    3. Re:Obligatory reminder that an alternative exists by TechyImmigrant · · Score: 5, Informative

      We tried contacting the PolarSSL developers about contributing code to fix their random number problem. No response. No random numbers -> no security.

      No matter what the security problem, it's always the random numbers, or lack thereof that is the problem.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    4. Re:Obligatory reminder that an alternative exists by ArchieBunker · · Score: 2, Informative

      SSL is broken anyhow. The feds have all the top level keys and can listen with impunity.

      --
      Only the State obtains its revenue by coercion. - Murray Rothbard
    5. Re:Obligatory reminder that an alternative exists by devman · · Score: 3, Insightful

      SSL/TLS has nothing to do with what certificates the client and server trust. You can bootstrap a TLS stream using a pre-shared key if you want, or with DANE, or with explicitly selected certificates. The fact that most clients use CAs for trust anchors is not a failure of SSL/TLS.

    6. Re:Obligatory reminder that an alternative exists by Desler · · Score: 2

      If this doesn't need some way to ensure that I really connect with it instead of an intercepting mitm that injects its own version, what does?

      In what universe do you live in that SSL prevents a MITM attack? MITM attacks exist in order to allow an attacker to monitor and modify your supposedly "secure" connections. You ensure that what you downloaded is what you meant to download by using the signify utility as mentioned on the page and verify that the package you download was signed by the OpenSSL devs.

    7. Re:Obligatory reminder that an alternative exists by Desler · · Score: 2

      And to head off the obvious rejoinder, yes, their private key can be compromised to allow an attacker to sign malicious packages. But if that is a genuine concern, why would you possibly trust the security of the SSL connection to their site?

    8. Re:Obligatory reminder that an alternative exists by Antique+Geekmeister · · Score: 4, Informative

      You _can_ do so, but the hardcoded reliance on the master signature authorities in nearly every popular software tool makes such efforts problematic. It's exceedingly difficult to _excise_ these master keys, or to display them as "not trusted due to federal key access", without breaking many tools.

  3. Re:Do you really trust the OpenSSL Corporation? by Anonymous Coward · · Score: 5, Insightful

    Do you think the absence of documentation is due only to laziness?

    Yes. "Never attribute to malice that which can be explained by incompetence." Not every fuckup is a conspiracy.

    I don't know any programmers who like writing documentation. Start with that, and add that the OpenSSL code is complicated and poorly written, and it's no wonder the documentation is lacking.

  4. OpenSSL and the Internet by Anonymous Coward · · Score: 2, Insightful

    It's an affront to common sense that the Internet's security largely relies on this wretched library, with its utterly dismal coding standards, its hideously, and unnecessarily, baroque and complex API, and its pathetic documentation.

    1. Re:OpenSSL and the Internet by Electricity+Likes+Me · · Score: 2

      This is stupid.

      If there's one lesson in the history of computing, it's that every type of possible side-channel leaks information like crazy if not properly controlled. So in what world does it make sense to mix up your application or transport protocol with your security protocol? The examples you give have nothing to do with the underlying transport protocols, or overlaying application protocols that have been in use.

  5. Re:Do you really trust the OpenSSL Corporation? by caseih · · Score: 3, Insightful

    Sorry but that's all just pure baseless speculation on your part and fear mongering. The NSA can snoop SSL traffice regardless of ssl library simply by doing a man in the middle attack. And you'd never know it either, since they would be using a recognized root certificate. So I don't see what this issue has to do with openssl. And If they can brute force sniff SSL, I don't see how other ssl libraries are much safer.

    Several of the OpenSSL developers have commented here on slashdot and expressed chagrin combined with determination to fix the problems which years ago were not considered problems--they were bad but accepted solutions for the portability problem. But times have changed, and openssl is changing too. As others have said it's still the most portable, and it is a good choice, and I do trust it. I think their response to heartbleed was admirable. They acknowledged and fixed the problem promptly.

  6. Re: Hey Dice you dumb fucks by joaommp · · Score: 2

    If a browser crashes because of a site, it's the browser's developers fault.

  7. A different perspective by Elessar · · Score: 2

    First of full disclosure...I am a member of the OpenSSL development team.

    I've read a lot of anti-OpenSSL comments here along with some fairly amusing conspiracy theories! Some criticism is fair but much is not in my view.

    OpenSSL is a very different project to what it was a year ago. This time last year the development team was very small (6 people...not all of whom were active coders, most of whom were doing it in their spare time). Supporting the project was (and still is) a thankless task, and they did their best - but frankly the resources were not there to do the job properly. There is now a whole new team, built upon the original, running the project. We have gone from 6 people to 15 and brought on board a number of full timers. I know most of that team personally, and I can tell you that you couldn't hope to find a more dedicated and experienced team. There is a strong sense of responsibility, along with lots of plans in place for how to make things better.

    A lot is said about the problems with OpenSSL. Let me tell you about some of its strengths. The library will run on practically anything from desktops, to high end servers, to embedded devices, to mainframes, to mobile phones. It is highly optimised and is *fast*. We are lucky enough to have Andy Polyakov on the team who brings an exceptional talent in performing those optimisations. Due to its position in the market place OpenSSL is probably the most studied security software product out there. That study has intensified since Heartbleed. During the last year there have been a number of security issues identified and fixed as a result of that intensified study. This is a *good* news story.

    I am really excited about what the future holds for the project. We are busy working on 1.1.0, which brings with it a focus on reducing complexity. Improved documentation (which I've seen mentioned a number of times on this page) is also on our roadmap. I'm not complacent...I know there is a lot still to do...but I have a huge amount of confidence in the team that is now in place.