openssl vs. libressl

[Jeremy Huddleston Sequoia]

> On Nov 13, 2015, at 10:09, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> On Friday November 13 2015 09:20:11 Jeremy Huddleston Sequoia wrote:
>> They *force* the use of the insecure SSLv2 transport (which was broken years ago and replace with SSLv3, which itself was broken).
> 
> Where, how?

I don't understand what you mean here.  These methods *force* the use of SSLv2 even if secure alternatives are available:

qt.network.ssl: QSslSocket: cannot resolve SSLv2_client_method
qt.network.ssl: QSslSocket: cannot resolve SSLv2_server_method

See SSL_CTX_new(3).

>> Qt probably doesn't use SSLv2 itself or else that warning would have had a different level of urgency.
>> 
>> It looks like it does.
> 
> Again, where? 

Again, based on your earlier report:

qt.network.ssl: QSslSocket: cannot resolve SSLv2_client_method
qt.network.ssl: QSslSocket: cannot resolve SSLv2_server_method

And from the SSL_CTX_new(3) man page, the recommendation is to use SSLv23_method et al when compatibility is a concern

     SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)
             A TLS/SSL connection established with these methods may understand the SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols.

             A client will send out TLSv1 client hello messages including extensions and will indicate that it also understands TLSv1.1,
             TLSv1.2 and permits a fallback to SSLv3.  A server will support SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols.  This is the
             best choice when compatibility is a concern.


>> Why?  What problems are you facing?  I've been using Libressl exclusively and haven't seen issues in anything I use.
> 
> The problem of serving as a guinea pig with software that still depends on the full openssl API.

The things removed in Libressl are not core API.  They are specific protocols and functions that are known to be exploitable and insecure *by design*.  There is no way to make them function in a secure and binary compatible way.  Furthermore, these vulnerabilities in SSLv2 have been known and alternatives available (within OpenSSL itself) for almost 20 years!  There is absolutely NO excuse for any piece of software still using it.