ssl libraries

I only recently checked the OpenSSL site and found out that they've changed their license from 4 clause BSD to an Apache style license. Many sites mention a license conflict between BSD 4 clause licenses and GNU GPL licenses. Several programs I use try to avoid the issue by adding a waiver to their license to allow linking with OpenSSL. Some examples are Dillo and D+. The issue can also be avoided in many cases by using software with a license other than the GNU GPL. So, the new switch to an Apache style license solves the license conflict issue in many cases (although it may cause new license conflict issues).

There's a useful reference on license information at the curl site:
https://curl.haxx.se/legal/licmix.html

There was an interesting thread about the GPL/BSD 4 clause license conflict on the lynx development list. Various SSL library options such as OpenSSL, gnutls and nss were discussed. It was mentioned that parts of the gnutls library (the compatibility layer) was licensed under GPLv3 which is incompatible with GPLv2 only ( https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility ). The thread concluded with a recommendation to use the nss library to avoid license conflicts. It also mentioned that contacting everyone who worked on the project to re-license lynx would be too difficult. I guess there was some accommodation made after the thread because the latest version of lynx includes a COPYHEADER file that includes permission to use libraries such as OpenSSL and gnutls.

With the license change to OpenSSL, I hoped that the various license issues one might run across when building and distributing software that need SSL support had been solved. I've been using OpenSSL for a long time and it's always been highly portable and worked on a variety of platforms. However, when I downloaded the latest version of OpenSSL, I found that was no longer the case. With the various OpenSSL security issues in the news, work has been done to update the library and make it more secure. It appears, in this particular case, the security enhancements have come at the cost of portability. I used to be able to build OpenSSL using the ActiveState version of Perl. Now, OpenSSL is designed to only allow use of ActiveState or Windows native Perl builds using the Visual C++ compiler. If I continue to use the mingw compiler, I need a msys or cygwin based version of Perl. I'd previously built OpenSSL for DOS with no issues. Looking through some of the code, I'm afraid to even give it a try with the latest version of OpenSSL. OpenSSL is also much more dependent on Perl than it used to be. If I'm building a C library, it would be nice if it was only dependent on C code to build instead of requiring an interpreted language that's rather complicated to build.

I found it was time to either redesign my build of Perl (since a native Perl could no longer be used with MinGW to build OpenSSL) or to look for a new SSL library alternative. I'll share some of the results in my search for SSL library alternatives.

The major SSL options are OpenSSL, gnutls (with GNU GPL license) and nss (from Mozilla with Mozilla Public License). There are OpenSSL compatibility layers for gnutls (GPLv3 license) and nss ( Nss_compat_ossl originally from Fedora and no longer supported ). From some of the articles I read online, OpenSSL and nss were mentioned as more secure than gnutls. I also read that gnutls was a popular option on certain Linux systems such as Debian.

However, these aren't the only SSL libraries. There are several other options for embedded systems and other specialty uses. It's actually hard to track the options since the names of some of them keep changing. Typically, a program needs to offer support specifically for one or more of these library options because there usually isn't a compatibility layer to use that SSL library in place of a more common SSL library. Curl is a great example of a program that supports multiple SSL library options. D+ included support for cyassl. However, cyassl is now known as wolfssl. axtls looked like an interesting possibility because of its BSD license. It supposedly builds on Windows, but I didn't have any luck with it. Of all the various lightweight and/or embedded options, the only one I was able to get to build out of the box on Windows was mbedtls (formerly polarssl). mbedtls is available under a GPL license. Rather than try to track all the options and library name changes, I'll refer to the Wikipedia list:
https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

After the recent security issues with OpenSSL, there were also forks of OpenSSL. These include LibreSSL (a fork by the OpenBSD developers) and BoringSSL (by Google). I tried building BoringSSL, but it required an interpreter (similar to OpenSSL), so why not stick with OpenSSL instead of switching to BoringSSL. I also tried building some of the various SSL options with cmake and had no luck at all.

I'd tried building LibreSSL in the past with no luck either. The fork was originally just designed for BSD systems and support for other platforms was added later. There are even some posts on the Internet about how early versions of LibreSSL include issues that made it insecure on Linux and other non-BSD systems. Once support was added for other platforms, I ran into an issue with what platforms were supported. The developers only supported the MinGW64 project on Windows. I use a version of MinGW based on an earlier version of the original MinGW which has a more lenient license. I've been adapting the mingwrt and w32api libraries, but they're based on the original public domain licensed versions of the libraries. So, when I previously tried to build LibreSSL, it wasn't compatible with my MinGW compiler. However, after the various changes to OpenSSL, I decided to give LibreSSL another try. Was pleasantly surprised this time when it only required minor patching with my particular version of MinGW in order to get it to build. It also uses the standard GNU autotools style configure/make/make install rather than requiring Perl just to configure and build it. If anyone's interested in the patches, feel free to contact me about getting a copy.

At this point, I'm considering switching to the LibreSSL fork. Several Linux distributions that use musl as their main C library are using LibreSSL as their SSL library of choice. They included patches to get various libraries and programs to build with LibreSSL instead of OpenSSL. There are also some patches at the LibreSSL site.

However, there are still some issues with switching. Many of the programs that included a waiver for OpenSSL, do not provide a similar waiver for LibreSSL. I certainly be interested in hearing how others are handling this particular issue. It would be nice if LibreSSL users could contact some of these projects and ask about a waiver for LibreSSL as well as OpenSSL. Some of the projects that come to mind are D+, Dillo, lynx, opusfile. Curl, libarchive and libssh2 can also use LibreSSL instead of OpenSSL, but there aren't any issues with license conflicts unless one adds a GNU GPL licensed library or a similar incompatible license to the mix.

I'd be interested to hear what others use as their SSL library of choice when building cross-platform applications and why they chose that particular library. You can find further discussion of this topic on the CPPDesign mailing list ( http://www.distasis.com/connect.htm ).