11 ms·

OpenSSL 3.0

243 points by ddb 6y ago

JoshTriplett 6y ago
One of the major improvements here: this finalizes the license change to Apache 2.0, which makes OpenSSL finally GPL-compatible. That removes one of the major reasons people had to avoid it. (Specifically, OpenSSL is now compatible with anything licensed "GPLv3", "GPLv3 or later", or "GPLv2 or later". It's not compatible with "GPLv2 only", but that's a relatively small amount of software.) Other major improvements: TLS1.3 support, Linux kernel TLS support (hand off crypto to the kernel and then read/write as though you had a normal file descriptor and let the kernel handle the crypto), and opaque low-level structures (no more dependencies on OpenSSL internals).
- LeoPanthera 6y ago
  Isn't the Linux kernel "GPLv2 only"?
  - JoshTriplett 6y ago
    Yes, but it's unlikely to link in a userspace library. This does prevent adapting code from OpenSSL to put in the kernel, but there are plenty of other sources to adapt code from. There are a few other notable codebases that are GPLv2-only, but most projects using the GPL use either "v2 or later" or "v3 or later".
- wallacoloo 6y ago
  > Other major improvements: TLS1.3 support OpenSSL 1.1.1 already supports TLS 1.3
- NiekvdMaas 6y ago
  What does the license change mean for LibreSSL (OpenSSL fork) and GnuTLS which have "a better license" as their main selling point?
  - throwaway2048 6y ago
    libressl does not have a different license
    - jabl 6y ago
      My understanding is that new libressl code is under the openbsd license, though the original terms still apply as long as they have code under those terms left.
      - Conan_Kudo 6y ago
        There is no reasonable way that the old license will ever go away unless they do a relicensing effort like OpenSSL did. They won't, so it won't.
        jabl 6y ago
        You're most likely correct. I was just pointing out that libressl is not under a different license from openssl < 3.0 as a whole, nor is it under the openbsd license as a whole. Rather parts of it are under the old openssl + ssleay dual license, and other parts are under the openbsd license. And over time, the fraction under the openbsd license is bound to increase, although as you say, they will probably never reach the point where all the old code has been replaced.
  - jabl 6y ago
    The openbsd people behind libressl hate the apache 2.0 license, so they won't be able to copy such code from the openssl project any longer. I'm sure they're happy they have a TLS library with a license they like (new contributions are licensed under the openbsd license) and they can continue developing. As for gnutls, apache 2.0 license is still incompatible with (L)GPL 2.x, so projects under those licenses without the "or later" clause can't use openssl 3.x->. And of course, the gnutls and openssl API's are different, users can't just link against one or the other without code changes.
    - 6y ago
- bjoli 6y ago
  A bit of a digression: the Apache license includes better patent language, which got me thinking of the patents on ocb mode. Shouldn't they expire sometime early in this decade? Like next year or something?
  - wbl 6y ago
    Rogaway has licensed them to any TLS implementation for free.
- ta17711771 6y ago
  ...wasn't the major reason to avoid it the shitton of vulns it has had compared to libreSSL!?
  - toyg 6y ago
    The “shitton of vulnerabilities” is a recent phenomenon, it’s not what prevented people from using OpenSSL.
    - ta17711771 6y ago
      Perhaps a recently discovered phenomenon. It definitely should be the reason now!
- terrywang 6y ago
  - Linux Kernel TLS support Is this referring to kernel TLS offload (using linux kernel's TLS connection ooffload infrastrucuture)?
  - shoo 6y ago
    i am unfamiliar with kernel TLS offload [1], but superficially, it looks like that may be supported: https://github.com/openssl/openssl/blob/43a70f02022ebbc29aa71853f04f1dc0d9772846/INSTALL.md#enable-ktls https://github.com/openssl/openssl/blob/43a70f02022ebbc29aa7... `SOL_TLS` referenced here https://github.com/openssl/openssl/blob/f059e4cc435b7b850cfc8188d265a8925edff0bd/include/internal/ktls.h https://github.com/openssl/openssl/blob/f059e4cc435b7b850cfc... as defined here: https://github.com/torvalds/linux/commit/3c4d7559159bfe1e3b94df3a657b2cda3a34e218#diff-19d8c55950b68c71d87e12df129ae8f7R337 https://github.com/torvalds/linux/commit/3c4d7559159bfe1e3b9... [1] https://www.kernel.org/doc/html/latest/networking/tls-offload.html https://www.kernel.org/doc/html/latest/networking/tls-offloa...
  - aisio 6y ago
    Yes it supports Kernel TLS offload support. Both in SW mode (where the kernel does the TLS operations) and HW mode https://www.kernel.org/doc/html/latest/networking/tls-offload.html https://www.kernel.org/doc/html/latest/networking/tls-offloa...
- scottlamb 6y ago
  Does anyone know if OpenSSL-derived projects like BoringSSL and ring will follow suit in switching to Apache 2.0? And if so, have a guess at how long that will take?
- tpolzer 6y ago
  Doesn't "GPLv2 or later" specifically allow you to fork into "GPLv2 only"? How can a license be incompatible with only the latter then?
  - yc12340 6y ago
    > How can a license be incompatible with only the latter then? Your parent comment said no such thing. It says, that you need GPL v3 to be compatible with Apache 2. "Or later" clause on GPL 2-licensed project offers you a way to re-license the project under GPL v3.
  - CrLf 6y ago
    IANAL, but “GPLv2 or later” allows you (the recipient of the license) to choose either GPLv2 or GPLv3 (i.e. the one that’s more convenient to you) but does not allow you to prevent others (the recipients of your modified version) from having the same choice. This goes both ways, “GPLv2 or later” cannot be changed to either GPLv2 or GPLv3 only without permission from everybody that has ever contributed to the codebase. The FSF requires copyright attribution from cotributors, that’s why they were able to switch their projects to GPLv3-only.
    - yc12340 6y ago
      > “GPLv2 or later” cannot be changed to either GPLv2 or GPLv3 only without permission... What? Of course it can be changed to either. It literally says so in the license name.
      - zvr 6y ago
        No, it does not say such thing. “GPLv2 or later” says you are allowed to use it under GPLv2 or GPLv3 (for now). It does not allow to change it to GPL-2.0-only (to use the correct SPDX identifier).
        yc12340 6y ago
        > “GPLv2 or later” says you are allowed to use it under GPLv2 or GPLv3 I am afraid, that you are wrong. GPL does not govern usage of software at all. You don't need to agree to GPL in order to use GPL licensed software. This is literally said in text of GPL itself. The preamble ("this program is free software...") is not part of GPL itself — it is just short informative text. And you are misremembering, what preamble says. Citing from GNU website: > This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. I believe, that we should erase all SPDX-whatever nonsense from Linux source code, and replace it back with proper preamble — least other users of GPL software start to misremember as well.
- chrisweekly 6y ago
  Thanks Josh, that's a helpful summary!
- gray_-_wolf 6y ago
  > Specifically, OpenSSL is now compatible with anything licensed "GPLv3", "GPLv3 or later", or "GPLv2 or later". It's not compatible with "GPLv2 only", but that's a relatively small amount of software. Does this mean I cannot use openssl in my gpl-2.0-only program? How does that work? Doesn't gpl-2.0-later imply that I can also take the code and use it in gpl-2.0-only? Is there some tldr on this topic somewhere? I'm not good with these legal things to ELI5 would be nice :/
  - jabl 6y ago
    > Does this mean I cannot use openssl in my gpl-2.0-only program? Correct. > How does that work? The GPL 2.0 and Apache-2.0 licenses contain terms which are incompatible with each other. > Doesn't gpl-2.0-later imply that I can also take the code and use it in gpl-2.0-only? Yes, in that case you can choose whether you use the code subject to the gpl 2.0, 3.0 or any later version. If you combine that code with some gpl-2.0-only code then you're choosing to use the first code under 2.0, and the combined work is then gpl-2.0-only. > Is there some tldr on this topic somewhere? I'm not good with these legal things to ELI5 would be nice :/ The GNU project maintains a list of licenses and some comments about them, and conveniently categorizes them according to their GPL compatibility. https://www.gnu.org/licenses/license-list.html https://www.gnu.org/licenses/license-list.html See also the chart at http://gplv3.fsf.org/dd3-faq http://gplv3.fsf.org/dd3-faq for compatibility between the different GPL versions and variants.
    - gray_-_wolf 6y ago
      > > Does this mean I cannot use openssl in my gpl-2.0-only program? > Correct. Well that sucks. I guess I'll need to look into libressl.
      - jabl 6y ago
        You might also check out GnuTLS which is under the LGPL 2.1+ license. If you're using Linux it's certainly already available from your package manager.
      - 6y ago
- 2OEH8eoCRo0 6y ago
  It's incredible how much time and energy is spent on what license things use.
  - flatiron 6y ago
    But think of what the gpl has given to us!
- wcoenen 6y ago
  > TLS1.3 support TLS 1.3 support was already added in OpenSSL 1.1.1 https://www.openssl.org/news/openssl-1.1.1-notes.html https://www.openssl.org/news/openssl-1.1.1-notes.html
Mizza 6y ago
I worry that this is going to break so many programs and scripts in the same way that the switch from Linux 2.6 did..
- pilif 6y ago
  That already happened once with OpenSSL 1.1 which also wasn’t really backwards compatible. It was messy then, it will be messy now, though when you took the 1.1 opportunity to modernize your code to current best-practice as requested by the library rather than just fixing the minimum, you might be pretty ok this time around
  - Mizza 6y ago
    You know, I think it was a deep memory of the switch off of 0.9.8 that gave me the initial thought without realizing. Maybe the older programs will be more prepared after all. Although I hope they weren't expecting a single-digit increment..
  - jeltz 6y ago
    This release actually seems less painful than 1.1 which broke a lot of APIs.
- kroeckx 6y ago
  The plan at least is that at little as possible should break. If you do find a problem, please file an issue.
- macintux 6y ago
  From other threads it sounds like the licensing may turn out to be a larger pain point than any backwards incompatibility in the code.
saghm 6y ago
Obvious question that it don't see answered on the page: why not 2.0?
- dharmab 6y ago
  https://www.openssl.org/blog/blog/2018/11/28/version/ https://www.openssl.org/blog/blog/2018/11/28/version/ They want to use the same version numbers for OpenSSL and a FIPS module, and the FIPS module was already versioned at 2.X.X.
moonchild 6y ago
> OpenSSL versions with the same major number are API and ABI compatible Finally! > A proper HTTP(S) client in libcrypto supporting GET and POST, redirection, plain and ASN.1-encoded contents, proxies, and timeouts Is this really necessary? If you want a 'real' http client, you're probably using libcurl anyway (which is permissively licensed, more stable, and supports http/3).
- JoshTriplett 6y ago
  > Is this really necessary? If you want a 'real' http client, you're probably using libcurl anyway (which is permissively licensed, more stable, and supports http/3). I'd guess it's there to support cryptographic protocols that require downloading/checking keys via HTTPS. Right before that line is "Implementation of the Certificate Management Protocol (CMP, RFC 4210) also covering CRMF (RFC 4211) and HTTP transfer (RFC 6712)". And yes, use curl.
- hannob 6y ago
  Up until now OCSP checks were basically broken in openssl for all OCSP servers which speak only HTTP/1.1 (which is most of them) and only worked with a crude hack where you add an extra HTTP header via command line. Not sure if this fixes it, but if you include functionality that relies on HTTP then you better support HTTP.
- Tobu 6y ago
  HTTPS is a really huge scope to tackle, and requires a lot of policy which OpenSSL traditionally hasn't encoded (how to root trust, for example — possibly involving system stores or custom ones, stapling, pinning…). Also, OpenSSL generally is embedded in HTTP clients, and having distinct implementations of HTTP calling into each other from the same library seems terrible, with potential for security issues related to policy or implementation mismatches. Of course, there's all the traditional bug surface of any code that talks to the network to consider as well. Defining an interface for calling back into another HTTP library might be doable, but there's still a question of scope creep. The motivation seems to be this fork and pull request: - https://github.com/mpeylo/cmpossl https://github.com/mpeylo/cmpossl - https://github.com/openssl/openssl/issues/5926 https://github.com/openssl/openssl/issues/5926 The use case is far away from what most users of OpenSSL need, and could quite easily be tackled outside OpenSSL.
woodruffw 6y ago
There's simply no way anybody will confuse OpenSSL 3.0, SSL 3, and TLS 1.3 :-)
- tumetab1 6y ago
  Came to the comments to try understand why SSL 3 was on HN. This link should be named OpenSSL release 3.0
- erwan 6y ago
  I'm confused as to why they didn't skip a version release; for clarity's sake.
  - jamesog 6y ago
    There was a proposal, which was declined: https://github.com/openssl/openssl/pull/8367 https://github.com/openssl/openssl/pull/8367
hyperman1 6y ago
Reading chapter 3, upgrading from 1.1.1, it seems strange for a security library to promote ignoring and even suppresing warnings. The best option, upgrading, is mentioned last. I would prefer my security libraries to scream bloody murder if I am using them in a deprecated way.
- saagarjha 6y ago
  “Deprecated” need not mean “insecure”.
  - hyperman1 6y ago
    Are you willing to take the risk? Deprecated might mean: There are known weaknesses. Or: Less reviewed code path.
    - dtech 6y ago
      As an initial upgrade, that is a decent strategy. Staying behind is even more insecure.
    - kroeckx 6y ago
      It's mostly about deprecating old APIs where a newer more general API is available, sometimes for more than 10 years.
    - user5994461 6y ago
      Deprecated can mean anything. They cannot remove any function due to being a C shared library. Removing functions or global symbols would break linking and runtime initialization.
ensiferum 6y ago
As important as openssl is for many projects I find the engineering quality of it to be lackluster. My project is still on an older version and I wanted to upgrade. I tried to build approximately 7 versions for windows using msvs 2017 and msvs 2019. None even build but fail with compiler errors or linker errors! On Linux if I go to system provided 1.2.x openssl version and try to build against that my code breaks with thousands of mysterious errors about undefined types (in openssl headers). I mean Openssl solves a big problem but from engineering perspective the library is one giant problem. And I haven't even remarked on the horrible API design yet.
- kakwa_ 6y ago
  I've mixed opinions over the recent breakages I've witnessed in OpenSSL. On one hand, I absolutely hate a library which breaks its API (I think lack of stability in interfaces is one of the bigger bane of the software industry and causes numerous issues down the line). But in the specific case with OpenSSL, the breakages are legitimate imho. Most of the breakages I have seen are to clean-up interfaces and have a clear boundary between OpenSSL internals and items controlled by third party apps. Concretely, they are switching from an API which exposed the internal structures directly to a getter/setter pattern. Example in from one of my project: old: ts_response->tst_info->serial new: TS_TST_INFO_get_serial(TS_RESP_get_tst_info(ts_response)) Breaking APIs is always a balancing act, it's not something which must happen willy-nilly, but it's sometimes a necessary evil, and in the specific case of OpenSSL, if the project wants to go forward and improve in quality and stability, they are kind of forced to do it, it's just a bit regrettable that better design decisions had not be made from the start.
  - ensiferum 6y ago
    I'm not even talking about clear cut API breakage. I'm talking about that if I do #include <openssl.h> and build against the 1.2.x system installed OpenSSL I will get thousands of errors from headers internal to OpenSSL.
    - fanf2 6y ago
blitmap 6y ago
I don't have much familiarity with OpenSSL and crypto scares me away from reading the sources. I wish someone could give a full run-down of everything that is in OpenSSL, an overview. You hear all the time about it being bloated and supporting too many things. I wish I better understood that. It's why people turn to wolfssl and mbedtls, right? Smaller projects that aim for minimalism and robustness probably suffer from a lack of peer review with a more niche community backing them. Trade-offs trade-offs. I also wish I understood where they compete: OpenSSL <-> WolfSSL <-> mbedtls
- als0 6y ago
  > It's why people turn to wolfssl and mbedtls, right? I tried to use a single algorithm from OpenSSL for an embedded project and seems like it needs hacking for all the dependencies to be met. I gave up. With mbedTLS it was done within a minute (simpler to build and read IMO). There aren't many differences between mbedTLS and WolfSSL. Both are small libraries designed for embedded use. The latter supports TLS 1.3. Today OpenSSL probably has the best support for hardware acceleration and secure elements.
  - blitmap 6y ago
    I had not considered that it may have support for hardware accelerated crypto.
- oefrha 6y ago
  The documentation already has an overview: https://www.openssl.org/docs/manmaster/man7/ https://www.openssl.org/docs/manmaster/man7/
  - blitmap 6y ago
    That goes a long way, thank you :-) One of the other comments was saying OpenSSL probably has the best support for secure elements (hardware accelerated crypto?).
- stock_toaster 6y ago
aorth 6y ago
> 1.7 Versioning Scheme > The OpenSSL versioning scheme has changed with the 3.0 release. The new versioning scheme has this format: > MAJOR.MINOR.PATCH Yay. OpenSSL finally switches to semantic versioning. \o/
- NikolaeVarius 6y ago
  That isn't semver
  - aorth 6y ago
    What do you mean? According to https://semver.org/ https://semver.org/: > Given a version number MAJOR.MINOR.PATCH, increment the: > MAJOR version when you make incompatible API changes, > MINOR version when you add functionality in a backwards compatible manner, and > PATCH version when you make backwards compatible bug fixes. > Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. Seems like semantic versioning to me! At least the major, minor, and patch will mean something now.
    - NikolaeVarius 6y ago
      SemVer is a spec. In the same way that people for some reason think that Terraform is SemVer just because it LOOKS like it even though nothing actually claims that they are using SemVer https://github.com/hashicorp/terraform/issues/15839 https://github.com/hashicorp/terraform/issues/15839 The only thing that OpenSSL claims to enforce about their versioning policy is > A change in the second (MINOR) number indicates that new features may have been added. OpenSSL versions with the same major number are API and ABI compatible. If the major number changes then API and ABI compatibility is not guaranteed.
saghul 6y ago
Pity that the bits required for QUIC didn't make the cut: https://github.com/openssl/openssl/pull/8797 https://github.com/openssl/openssl/pull/8797

243 points by ddb 6y ago

One of the major improvements here: this finalizes the license change to Apache 2.0, which makes OpenSSL finally GPL-compatible. That removes one of the major reasons people had to avoid it. (Specifically, OpenSSL is now compatible with anything licensed "GPLv3", "GPLv3 or later", or "GPLv2 or later". It's not compatible with "GPLv2 only", but that's a relatively small amount of software.) Other major improvements: TLS1.3 support, Linux kernel TLS support (hand off crypto to the kernel and then read/write as though you had a normal file descriptor and let the kernel handle the crypto), and opaque low-level structures (no more dependencies on OpenSSL internals).

LeoPanthera 6y ago
Isn't the Linux kernel "GPLv2 only"?
- JoshTriplett 6y ago
  Yes, but it's unlikely to link in a userspace library. This does prevent adapting code from OpenSSL to put in the kernel, but there are plenty of other sources to adapt code from. There are a few other notable codebases that are GPLv2-only, but most projects using the GPL use either "v2 or later" or "v3 or later".
wallacoloo 6y ago
> Other major improvements: TLS1.3 support OpenSSL 1.1.1 already supports TLS 1.3
NiekvdMaas 6y ago
What does the license change mean for LibreSSL (OpenSSL fork) and GnuTLS which have "a better license" as their main selling point?
- throwaway2048 6y ago
  libressl does not have a different license
  - jabl 6y ago
    My understanding is that new libressl code is under the openbsd license, though the original terms still apply as long as they have code under those terms left.
    - Conan_Kudo 6y ago
      There is no reasonable way that the old license will ever go away unless they do a relicensing effort like OpenSSL did. They won't, so it won't.
      - jabl 6y ago
        You're most likely correct. I was just pointing out that libressl is not under a different license from openssl < 3.0 as a whole, nor is it under the openbsd license as a whole. Rather parts of it are under the old openssl + ssleay dual license, and other parts are under the openbsd license. And over time, the fraction under the openbsd license is bound to increase, although as you say, they will probably never reach the point where all the old code has been replaced.
- jabl 6y ago
  The openbsd people behind libressl hate the apache 2.0 license, so they won't be able to copy such code from the openssl project any longer. I'm sure they're happy they have a TLS library with a license they like (new contributions are licensed under the openbsd license) and they can continue developing. As for gnutls, apache 2.0 license is still incompatible with (L)GPL 2.x, so projects under those licenses without the "or later" clause can't use openssl 3.x->. And of course, the gnutls and openssl API's are different, users can't just link against one or the other without code changes.
  - 6y ago
bjoli 6y ago
A bit of a digression: the Apache license includes better patent language, which got me thinking of the patents on ocb mode. Shouldn't they expire sometime early in this decade? Like next year or something?
- wbl 6y ago
  Rogaway has licensed them to any TLS implementation for free.
ta17711771 6y ago
...wasn't the major reason to avoid it the shitton of vulns it has had compared to libreSSL!?
- toyg 6y ago
  The “shitton of vulnerabilities” is a recent phenomenon, it’s not what prevented people from using OpenSSL.
  - ta17711771 6y ago
    Perhaps a recently discovered phenomenon. It definitely should be the reason now!
terrywang 6y ago
- Linux Kernel TLS support Is this referring to kernel TLS offload (using linux kernel's TLS connection ooffload infrastrucuture)?
- shoo 6y ago
  i am unfamiliar with kernel TLS offload [1], but superficially, it looks like that may be supported: https://github.com/openssl/openssl/blob/43a70f02022ebbc29aa71853f04f1dc0d9772846/INSTALL.md#enable-ktls https://github.com/openssl/openssl/blob/43a70f02022ebbc29aa7... `SOL_TLS` referenced here https://github.com/openssl/openssl/blob/f059e4cc435b7b850cfc8188d265a8925edff0bd/include/internal/ktls.h https://github.com/openssl/openssl/blob/f059e4cc435b7b850cfc... as defined here: https://github.com/torvalds/linux/commit/3c4d7559159bfe1e3b94df3a657b2cda3a34e218#diff-19d8c55950b68c71d87e12df129ae8f7R337 https://github.com/torvalds/linux/commit/3c4d7559159bfe1e3b9... [1] https://www.kernel.org/doc/html/latest/networking/tls-offload.html https://www.kernel.org/doc/html/latest/networking/tls-offloa...
- aisio 6y ago
  Yes it supports Kernel TLS offload support. Both in SW mode (where the kernel does the TLS operations) and HW mode https://www.kernel.org/doc/html/latest/networking/tls-offload.html https://www.kernel.org/doc/html/latest/networking/tls-offloa...
scottlamb 6y ago
Does anyone know if OpenSSL-derived projects like BoringSSL and ring will follow suit in switching to Apache 2.0? And if so, have a guess at how long that will take?
tpolzer 6y ago
Doesn't "GPLv2 or later" specifically allow you to fork into "GPLv2 only"? How can a license be incompatible with only the latter then?
- yc12340 6y ago
  > How can a license be incompatible with only the latter then? Your parent comment said no such thing. It says, that you need GPL v3 to be compatible with Apache 2. "Or later" clause on GPL 2-licensed project offers you a way to re-license the project under GPL v3.
- CrLf 6y ago
  IANAL, but “GPLv2 or later” allows you (the recipient of the license) to choose either GPLv2 or GPLv3 (i.e. the one that’s more convenient to you) but does not allow you to prevent others (the recipients of your modified version) from having the same choice. This goes both ways, “GPLv2 or later” cannot be changed to either GPLv2 or GPLv3 only without permission from everybody that has ever contributed to the codebase. The FSF requires copyright attribution from cotributors, that’s why they were able to switch their projects to GPLv3-only.
  - yc12340 6y ago
    > “GPLv2 or later” cannot be changed to either GPLv2 or GPLv3 only without permission... What? Of course it can be changed to either. It literally says so in the license name.
    - zvr 6y ago
      No, it does not say such thing. “GPLv2 or later” says you are allowed to use it under GPLv2 or GPLv3 (for now). It does not allow to change it to GPL-2.0-only (to use the correct SPDX identifier).
      - yc12340 6y ago
        > “GPLv2 or later” says you are allowed to use it under GPLv2 or GPLv3 I am afraid, that you are wrong. GPL does not govern usage of software at all. You don't need to agree to GPL in order to use GPL licensed software. This is literally said in text of GPL itself. The preamble ("this program is free software...") is not part of GPL itself — it is just short informative text. And you are misremembering, what preamble says. Citing from GNU website: > This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. I believe, that we should erase all SPDX-whatever nonsense from Linux source code, and replace it back with proper preamble — least other users of GPL software start to misremember as well.
chrisweekly 6y ago
Thanks Josh, that's a helpful summary!
gray_-_wolf 6y ago
> Specifically, OpenSSL is now compatible with anything licensed "GPLv3", "GPLv3 or later", or "GPLv2 or later". It's not compatible with "GPLv2 only", but that's a relatively small amount of software. Does this mean I cannot use openssl in my gpl-2.0-only program? How does that work? Doesn't gpl-2.0-later imply that I can also take the code and use it in gpl-2.0-only? Is there some tldr on this topic somewhere? I'm not good with these legal things to ELI5 would be nice :/
- jabl 6y ago
  > Does this mean I cannot use openssl in my gpl-2.0-only program? Correct. > How does that work? The GPL 2.0 and Apache-2.0 licenses contain terms which are incompatible with each other. > Doesn't gpl-2.0-later imply that I can also take the code and use it in gpl-2.0-only? Yes, in that case you can choose whether you use the code subject to the gpl 2.0, 3.0 or any later version. If you combine that code with some gpl-2.0-only code then you're choosing to use the first code under 2.0, and the combined work is then gpl-2.0-only. > Is there some tldr on this topic somewhere? I'm not good with these legal things to ELI5 would be nice :/ The GNU project maintains a list of licenses and some comments about them, and conveniently categorizes them according to their GPL compatibility. https://www.gnu.org/licenses/license-list.html https://www.gnu.org/licenses/license-list.html See also the chart at http://gplv3.fsf.org/dd3-faq http://gplv3.fsf.org/dd3-faq for compatibility between the different GPL versions and variants.
  - gray_-_wolf 6y ago
    > > Does this mean I cannot use openssl in my gpl-2.0-only program? > Correct. Well that sucks. I guess I'll need to look into libressl.
    - jabl 6y ago
      You might also check out GnuTLS which is under the LGPL 2.1+ license. If you're using Linux it's certainly already available from your package manager.
    - 6y ago
2OEH8eoCRo0 6y ago
It's incredible how much time and energy is spent on what license things use.
- flatiron 6y ago
  But think of what the gpl has given to us!
wcoenen 6y ago
> TLS1.3 support TLS 1.3 support was already added in OpenSSL 1.1.1 https://www.openssl.org/news/openssl-1.1.1-notes.html https://www.openssl.org/news/openssl-1.1.1-notes.html

Mizza 6y ago

I worry that this is going to break so many programs and scripts in the same way that the switch from Linux 2.6 did..

pilif 6y ago
That already happened once with OpenSSL 1.1 which also wasn’t really backwards compatible. It was messy then, it will be messy now, though when you took the 1.1 opportunity to modernize your code to current best-practice as requested by the library rather than just fixing the minimum, you might be pretty ok this time around
- Mizza 6y ago
  You know, I think it was a deep memory of the switch off of 0.9.8 that gave me the initial thought without realizing. Maybe the older programs will be more prepared after all. Although I hope they weren't expecting a single-digit increment..
- jeltz 6y ago
  This release actually seems less painful than 1.1 which broke a lot of APIs.
kroeckx 6y ago
The plan at least is that at little as possible should break. If you do find a problem, please file an issue.
macintux 6y ago
From other threads it sounds like the licensing may turn out to be a larger pain point than any backwards incompatibility in the code.

saghm 6y ago

Obvious question that it don't see answered on the page: why not 2.0?

dharmab 6y ago
https://www.openssl.org/blog/blog/2018/11/28/version/ https://www.openssl.org/blog/blog/2018/11/28/version/ They want to use the same version numbers for OpenSSL and a FIPS module, and the FIPS module was already versioned at 2.X.X.

moonchild 6y ago

> OpenSSL versions with the same major number are API and ABI compatible Finally! > A proper HTTP(S) client in libcrypto supporting GET and POST, redirection, plain and ASN.1-encoded contents, proxies, and timeouts Is this really necessary? If you want a 'real' http client, you're probably using libcurl anyway (which is permissively licensed, more stable, and supports http/3).

JoshTriplett 6y ago
> Is this really necessary? If you want a 'real' http client, you're probably using libcurl anyway (which is permissively licensed, more stable, and supports http/3). I'd guess it's there to support cryptographic protocols that require downloading/checking keys via HTTPS. Right before that line is "Implementation of the Certificate Management Protocol (CMP, RFC 4210) also covering CRMF (RFC 4211) and HTTP transfer (RFC 6712)". And yes, use curl.
hannob 6y ago
Up until now OCSP checks were basically broken in openssl for all OCSP servers which speak only HTTP/1.1 (which is most of them) and only worked with a crude hack where you add an extra HTTP header via command line. Not sure if this fixes it, but if you include functionality that relies on HTTP then you better support HTTP.
Tobu 6y ago
HTTPS is a really huge scope to tackle, and requires a lot of policy which OpenSSL traditionally hasn't encoded (how to root trust, for example — possibly involving system stores or custom ones, stapling, pinning…). Also, OpenSSL generally is embedded in HTTP clients, and having distinct implementations of HTTP calling into each other from the same library seems terrible, with potential for security issues related to policy or implementation mismatches. Of course, there's all the traditional bug surface of any code that talks to the network to consider as well. Defining an interface for calling back into another HTTP library might be doable, but there's still a question of scope creep. The motivation seems to be this fork and pull request: - https://github.com/mpeylo/cmpossl https://github.com/mpeylo/cmpossl - https://github.com/openssl/openssl/issues/5926 https://github.com/openssl/openssl/issues/5926 The use case is far away from what most users of OpenSSL need, and could quite easily be tackled outside OpenSSL.

woodruffw 6y ago

There's simply no way anybody will confuse OpenSSL 3.0, SSL 3, and TLS 1.3 :-)

tumetab1 6y ago
Came to the comments to try understand why SSL 3 was on HN. This link should be named OpenSSL release 3.0
erwan 6y ago
I'm confused as to why they didn't skip a version release; for clarity's sake.
- jamesog 6y ago
  There was a proposal, which was declined: https://github.com/openssl/openssl/pull/8367 https://github.com/openssl/openssl/pull/8367

hyperman1 6y ago

Reading chapter 3, upgrading from 1.1.1, it seems strange for a security library to promote ignoring and even suppresing warnings. The best option, upgrading, is mentioned last. I would prefer my security libraries to scream bloody murder if I am using them in a deprecated way.

saagarjha 6y ago
“Deprecated” need not mean “insecure”.
- hyperman1 6y ago
  Are you willing to take the risk? Deprecated might mean: There are known weaknesses. Or: Less reviewed code path.
  - dtech 6y ago
    As an initial upgrade, that is a decent strategy. Staying behind is even more insecure.
  - kroeckx 6y ago
    It's mostly about deprecating old APIs where a newer more general API is available, sometimes for more than 10 years.
  - user5994461 6y ago
    Deprecated can mean anything. They cannot remove any function due to being a C shared library. Removing functions or global symbols would break linking and runtime initialization.

ensiferum 6y ago

As important as openssl is for many projects I find the engineering quality of it to be lackluster. My project is still on an older version and I wanted to upgrade. I tried to build approximately 7 versions for windows using msvs 2017 and msvs 2019. None even build but fail with compiler errors or linker errors! On Linux if I go to system provided 1.2.x openssl version and try to build against that my code breaks with thousands of mysterious errors about undefined types (in openssl headers). I mean Openssl solves a big problem but from engineering perspective the library is one giant problem. And I haven't even remarked on the horrible API design yet.

kakwa_ 6y ago
I've mixed opinions over the recent breakages I've witnessed in OpenSSL. On one hand, I absolutely hate a library which breaks its API (I think lack of stability in interfaces is one of the bigger bane of the software industry and causes numerous issues down the line). But in the specific case with OpenSSL, the breakages are legitimate imho. Most of the breakages I have seen are to clean-up interfaces and have a clear boundary between OpenSSL internals and items controlled by third party apps. Concretely, they are switching from an API which exposed the internal structures directly to a getter/setter pattern. Example in from one of my project: old: ts_response->tst_info->serial new: TS_TST_INFO_get_serial(TS_RESP_get_tst_info(ts_response)) Breaking APIs is always a balancing act, it's not something which must happen willy-nilly, but it's sometimes a necessary evil, and in the specific case of OpenSSL, if the project wants to go forward and improve in quality and stability, they are kind of forced to do it, it's just a bit regrettable that better design decisions had not be made from the start.
- ensiferum 6y ago
  I'm not even talking about clear cut API breakage. I'm talking about that if I do #include <openssl.h> and build against the 1.2.x system installed OpenSSL I will get thousands of errors from headers internal to OpenSSL.
  - fanf2 6y ago

blitmap 6y ago

I don't have much familiarity with OpenSSL and crypto scares me away from reading the sources. I wish someone could give a full run-down of everything that is in OpenSSL, an overview. You hear all the time about it being bloated and supporting too many things. I wish I better understood that. It's why people turn to wolfssl and mbedtls, right? Smaller projects that aim for minimalism and robustness probably suffer from a lack of peer review with a more niche community backing them. Trade-offs trade-offs. I also wish I understood where they compete: OpenSSL <-> WolfSSL <-> mbedtls

als0 6y ago
> It's why people turn to wolfssl and mbedtls, right? I tried to use a single algorithm from OpenSSL for an embedded project and seems like it needs hacking for all the dependencies to be met. I gave up. With mbedTLS it was done within a minute (simpler to build and read IMO). There aren't many differences between mbedTLS and WolfSSL. Both are small libraries designed for embedded use. The latter supports TLS 1.3. Today OpenSSL probably has the best support for hardware acceleration and secure elements.
- blitmap 6y ago
  I had not considered that it may have support for hardware accelerated crypto.
oefrha 6y ago
The documentation already has an overview: https://www.openssl.org/docs/manmaster/man7/ https://www.openssl.org/docs/manmaster/man7/
- blitmap 6y ago
  That goes a long way, thank you :-) One of the other comments was saying OpenSSL probably has the best support for secure elements (hardware accelerated crypto?).
stock_toaster 6y ago

aorth 6y ago

> 1.7 Versioning Scheme > The OpenSSL versioning scheme has changed with the 3.0 release. The new versioning scheme has this format: > MAJOR.MINOR.PATCH Yay. OpenSSL finally switches to semantic versioning. \o/

NikolaeVarius 6y ago
That isn't semver
- aorth 6y ago
  What do you mean? According to https://semver.org/ https://semver.org/: > Given a version number MAJOR.MINOR.PATCH, increment the: > MAJOR version when you make incompatible API changes, > MINOR version when you add functionality in a backwards compatible manner, and > PATCH version when you make backwards compatible bug fixes. > Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. Seems like semantic versioning to me! At least the major, minor, and patch will mean something now.
  - NikolaeVarius 6y ago
    SemVer is a spec. In the same way that people for some reason think that Terraform is SemVer just because it LOOKS like it even though nothing actually claims that they are using SemVer https://github.com/hashicorp/terraform/issues/15839 https://github.com/hashicorp/terraform/issues/15839 The only thing that OpenSSL claims to enforce about their versioning policy is > A change in the second (MINOR) number indicates that new features may have been added. OpenSSL versions with the same major number are API and ABI compatible. If the major number changes then API and ABI compatibility is not guaranteed.

saghul 6y ago

Pity that the bits required for QUIC didn't make the cut: https://github.com/openssl/openssl/pull/8797 https://github.com/openssl/openssl/pull/8797