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 _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev