[openssl-dev] On SSLv23_method() drop and TLS_method() introduction

[Matt Caswell]

On 19/05/15 16:28, Steffen Nurpmeso wrote:
> Hello,
> i've just read on the Lynx list about compilation error because of
> a missing SSLv23_method() and indeed [1] says it is deprecated and
> a new TLS_client_method() is to be used instead.  Now i've
> searched on Gmane but i couldn't find just any word.  (Let's just
> hope that there will be TLS v1.4, .5...)  So well, now i've
> updated [master] and see indeed commit [32ec415] stating
> 
>   Also, SSLv23_method and SSLv23_server_method have been replaced
>   with TLS_method and TLS_server_method respectively. The old
>   SSLv23* names still exist as macros pointing at the new name,
>   although they are deprecated.
> 
> Looking at the diff it seems that OPENSSL_USE_DEPRECATED is
> required to get the names.
> 
>   [1] https://www.openssl.org/docs/ssl/SSL_CTX_new.html
> 
> Since my last v1.1.0 compile check was against an installation
> (got and) made on March 19th with OPENSSL_VERSION_NUMBER EQ
> 0x10100000L i would like to know how i can code my software to be
> (also future) compatible with OpenSSL.
> I would ask on @users but are no longer subscribed there.  (Also
> i think this is such a drastic change that it is worth a note
> here.)
> Can someone please shed any light on this, please?
> Thank you!

I just posted the following to lynx-dev:


On 19/05/15 15:04, Thorsten Glaser wrote:
> Gisle Vanem dixit:
>
>> +#if (OPENSSL_VERSION_NUMBER >= 0x10100000L)
>
> No. The change is not a property of the version number.
> I have OpenSSL 0.9.7 (plus patches…) without SSLv{2,3}.
>
> Index: HTTP.c
> ===================================================================
> RCS file: /cvs/src/gnu/usr.bin/lynx/WWW/Library/Implementation/HTTP.c,v
> retrieving revision 1.26
> retrieving revision 1.27
> diff -u -p -r1.26 -r1.27
> --- HTTP.c      13 Mar 2014 04:46:43 -0000      1.26
> +++ HTTP.c      4 Jan 2015 22:24:27 -0000       1.27
> @@ -124,7 +124,11 @@ SSL *HTGetSSLHandle(void)
>         ssl_opts &= ~SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS;
>  #endif
>         SSLeay_add_ssl_algorithms();
> +#if defined(OPENSSL_NO_SSL2) && defined(OPENSSL_NO_SSL3)
> +       ssl_ctx = SSL_CTX_new(TLSv1_client_method());
> +#else
>         ssl_ctx = SSL_CTX_new(SSLv23_client_method());
> +#endif
>         SSL_CTX_set_options(ssl_ctx, ssl_opts);
>         SSL_CTX_set_default_verify_paths(ssl_ctx);
>         SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_PEER, HTSSLCallback);
>
> This should do the trick.

This is not correct.

Despite their name the SSLv23_*method() functions have nothing to do
with the availability of SSLv2 or SSLv3. What these functions do is
negotiate with the peer the highest available SSL/TLS protocol version
available. The name is as it is for historic reasons. This is a very
common confusion and is the main reason why these names have been
deprecated in the latest dev version of OpenSSL.

The OP suggested this:

+#if (OPENSSL_VERSION_NUMBER >= 0x10100000L)
+       ssl_ctx = SSL_CTX_new(TLSv1_client_method());
+#else
        ssl_ctx = SSL_CTX_new(SSLv23_client_method());
+#endif

This is not quite correct either. TLSv1_client_method() will force
TLS1.0 only. This is the correct approach:

+#if (OPENSSL_VERSION_NUMBER >= 0x10100000L)
+       ssl_ctx = SSL_CTX_new(TLS_client_method());
+#else
        ssl_ctx = SSL_CTX_new(SSLv23_client_method());
+#endif

Alternatively you can continue to use the old SSLv23_client_method()
name - but if you do so you will have to enable deprecated functions.

Matt