openssl vs. libressl

[Jeremy Huddleston Sequoia]

> On Nov 13, 2015, at 12:53, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> On Friday November 13 2015 11:30:59 Jeremy Huddleston Sequoia wrote:
> 
>> 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
> 
> They surely do when you call them, but not when you only resolve them, i.e. load them dynamically. As I have tried to point out before, Qt loads these and most if not all optionally supported SSL functions dynamically. It is then up to the user to decide what s/he is actually going to use; see QSslContext::fromConfiguration().
> 
> It is perfectly possible to exclude support for SSL2 (since 2012) and SSL3 (since this year), btw.

You mean it is up to the developer that is a client of that Qt API, not the user.  We should be protecting our users from developers that don't know better.

>> And from the SSL_CTX_new(3) man page, the recommendation is to use SSLv23_method et al when compatibility is a concern
> 
> From the above method:
> 
>    case QSsl::SecureProtocols:
>        // SSLv2 and SSLv3 will be disabled by SSL options
>        // But we need q_SSLv23_server_method() otherwise AnyProtocol will be unable to connect on Win32.
>    case QSsl::TlsV1SslV3:
>        // SSLv2 will will be disabled by SSL options
>    case QSsl::AnyProtocol:
>    default:
>        sslContext->ctx = q_SSL_CTX_new(client ? q_SSLv23_client_method() : q_SSLv23_server_method());
>        break;

Great.  That's good for those codepaths.  So where is the SSLv2_client_method usage coming from?  We should remove that code.

>> 20 years!  There is absolutely NO excuse for any piece of software still using it.
> 
> Sure there is. That hypothetical 20+ year old closed-source binary library someone distantly related fundamental science colleague of mine still relies on and that magically still works with the latest Qt library... :)

That is not a relevant case here.  That 20+ year old closed-source binary library was linked against something older than OpenSSL itself.  OpenSSL was first released in 1998 at a time with SSLv2 was already known to be insecure. ;)

However, assuming you mean maybe 10 years old library, that still isn't quite relevant.  That library is linked against something that is providing that SSLv2 support (maybe OpenSSL 0.9.6), and changing what Qt uses and links against won't break it.  If that library is a Qt-based library, then it's likey on Qt2 or maybe Qt3 and won't care about what we do in Qt5.

If somehow that library magically uses the Qt5 library for SSL, then that's fine, too.  We should just have Qt5 map that API to SSLv23_client_method instead.

--Jeremy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4118 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20151113/584c965a/attachment.p7s>