openssl vs. libressl

Jeremy Huddleston Sequoia jeremyhu at
Fri Nov 13 09:20:11 PST 2015

> On Nov 13, 2015, at 01:33, René J.V. Bertin <rjvbertin at> wrote:
> On Thursday November 12 2015 15:56:58 Jeremy Huddleston Sequoia wrote:
> If LibreSSL should become the default, the best compromise in this particular case might yet be to provide a variant that allows Qt to build with the shipped OpenSSL version rather than against the "system" (MacPorts) version.

No, the best solution for our users is to fix Qt to not force the use of insecure transport encryption like SSLv2 and instead use functions that pick the most secure, supported encryption.

The best solution for all users is to then send those patches upstream to Qt.

> I don't really want into this kind of discussion, but 
>> Libressl doesn't "emulate" OpenSSL.  It is a derivative of OpenSSL with a focus on better architecture and security. 
> AFAIK it's a rewrite (has to be, to avoid licensing/copyright issues) that aims to be API compatible. No matter its other goals of being better, that still means it emulates the original

No more than OpenSSL 1.0.2 aims to "emulate" OpenSSL 1.0.1.  It's just a fork with a focus on refactoring and security over bitrot and bad API design.

>> Qt should stop using them (even with OpenSSL).
> That's really cheap and easy to say. Qt is a middleware that's in a position (system GUI API) not unlike that of major OSes which have to contend with backward compatibility. Telling it to "stop using them" is not unlike telling Apple they should stop shipping anything but the latest version of a whole range of things shipped with the OS (python comes to mind).

No, I think you do not at all understand what I said.  I said that Qt should stop using those functions from OpenSSL as they are insecure.  They *force* the use of the insecure SSLv2 transport (which was broken years ago and replace with SSLv3, which itself was broken).  Libressl removed SSLv2 support in one of its earlier releases, and SSLv3 support is being removed soon.


> There's a responsibility to ensure that users who do not know better aren't forced to rely on outdated security mechanisms, not a hard obligation to know better and protect all users against every possibly foolish thing they might use the software for. I am not enough of a security expert to be certain that there are *no* use cases in which SSLv2 is good enough and possibly even preferable over more secure methods.

Well, I am.  There is no case in which SSLv2 is sufficient for anything.

> And just like (I presume) current OS X doesn't rely on major features known to have issues in the Python versions shipped, Qt probably doesn't use SSLv2 itself or else that warning would have had a different level of urgency.

It looks like it does.

Qt might be (internally) trying different encryption types, but if that's the case, it should just rely on the library to negotiate the best one instead of trying to do that itself.

> The warnings come from an app (qtdiag) that tests which SSL APIs are available, possibly because the presence was detected at build and Qt is designed to be deployed in binary form to systems with a different OpenSSL version installed.
> In the meantime I'll be replacing libressl with good ole openssl again.

Why?  What problems are you facing?  I've been using Libressl exclusively and haven't seen issues in anything I use.


More information about the macports-users mailing list