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

[Steffen Nurpmeso]

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!

--steffen
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[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

[Gisle Vanem]

Matt Caswell wrote:

> I just posted the following to lynx-dev:

I didn't get that post.

> 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

Okay, this was better. The command:
lynx https://www.ssllabs.com/ssltest/viewMyClient.html

now gives:
Protocol Features
Protocols
TLS 1.2 Yes
TLS 1.1 Yes*
TLS 1.0 Yes*
SSL 3 Yes*
SSL 2 No

--
--gv

[Kurt Roeckx]

On Tue, May 19, 2015 at 05:03:12PM +0100, Matt Caswell wrote:
> >
> > 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.

And because of this confusion I want to remove things like
TLSv1_client_method().

I think that we should just provide the SSLv23_client_method define
without the need to enable something, and I guess I missed
something during the review in that case.


Kurt

[Steffen Nurpmeso]

Kurt Roeckx <ku...@roeckx.be> wrote:
|I think that we should just provide the SSLv23_client_method define
|without the need to enable something, and I guess I missed
|something during the review in that case.

Thanks for the clarification.

--steffen

[Steffen Nurpmeso]

Steffen Nurpmeso <sda...@yandex.com> wrote:
|Kurt Roeckx <ku...@roeckx.be> wrote:
||I think that we should just provide the SSLv23_client_method define
||without the need to enable something, and I guess I missed
||something during the review in that case.
|
|Thanks for the clarification.

Ehm, one more nit: in order to be able to compile [master] i need
this patch (tests like it fwiw):

diff --git a/crypto/comp/comp_lcl.h b/crypto/comp/comp_lcl.h
index f1ec8d5..1360f56 100644
--- a/crypto/comp/comp_lcl.h
+++ b/crypto/comp/comp_lcl.h
@@ -71,4 +71,5 @@ struct comp_ctx_st {
unsigned long compress_out;
unsigned long expand_in;
unsigned long expand_out;
+ CRYPTO_EX_DATA ex_data;
};

[Kurt Roeckx]

On Tue, May 19, 2015 at 08:03:05PM +0200, Steffen Nurpmeso wrote:
> Steffen Nurpmeso <sda...@yandex.com> wrote:
> |Kurt Roeckx <ku...@roeckx.be> wrote:
> ||I think that we should just provide the SSLv23_client_method define
> ||without the need to enable something, and I guess I missed
> ||something during the review in that case.
> |
> |Thanks for the clarification.
>
> Ehm, one more nit: in order to be able to compile [master] i need
> this patch (tests like it fwiw):

It builds fine for me. Can you give the error where it fails to
build?


Kurt

[Matt Caswell]

On 19/05/15 17:40, Kurt Roeckx wrote:
> I think that we should just provide the SSLv23_client_method define
> without the need to enable something, and I guess I missed
> something during the review in that case.

The reason you need to enable something is that SSLv23_client_method is
now deprecated. If you want it to "just work" then you would need to
un-deprecate it. That's ok but it has the disadvantage that the old name
will then stick around indefinitely and quite probably will be used even
for new code.

Matt

[Steffen Nurpmeso]

Kurt Roeckx <ku...@roeckx.be> wrote:
|On Tue, May 19, 2015 at 08:03:05PM +0200, Steffen Nurpmeso wrote:
|> Steffen Nurpmeso <sda...@yandex.com> wrote:

|>|Kurt Roeckx <ku...@roeckx.be> wrote:
|>||I think that we should just provide the SSLv23_client_method define
|>||without the need to enable something, and I guess I missed
|>||something during the review in that case.
|>|

|>|Thanks for the clarification.
|>
|> Ehm, one more nit: in order to be able to compile [master] i need
|> this patch (tests like it fwiw):
|
|It builds fine for me. Can you give the error where it fails to
|build?

I never claimed the patch was correct, i still got

c_zlib.c:113:5: warning: excess elements in struct initializer
NULL,
^~~~

But understandably i wanted to adjust for upcoming 1.1.0 changes
asap (you seem to encourage people using [master] for this purpose
if i recall correctly) and then there was (i say «Ciao!» here)

c_zlib.c:113:5: warning: excess elements in struct initializer
NULL,
^~~~
/usr/include/stdio.h:84:14: note: expanded from macro 'NULL'
#define NULL __DARWIN_NULL
^~~~~~~~~~~~~
/usr/include/sys/_types.h:91:23: note: expanded from macro '__DARWIN_NULL'
#define __DARWIN_NULL ((void *)0)
^~~~~~~~~~~
c_zlib.c:203:57: error: no member named 'ex_data' in 'struct comp_ctx_st'
CRYPTO_new_ex_data(CRYPTO_EX_INDEX_COMP, ctx, &ctx->ex_data);
~~~ ^
c_zlib.c:204:30: error: no member named 'ex_data' in 'struct comp_ctx_st'
CRYPTO_set_ex_data(&ctx->ex_data, zlib_stateful_ex_idx, state);
~~~ ^
c_zlib.c:214:55: error: no member named 'ex_data' in 'struct comp_ctx_st'
(struct zlib_state *)CRYPTO_get_ex_data(&ctx->ex_data,
~~~ ^
c_zlib.c:219:58: error: no member named 'ex_data' in 'struct comp_ctx_st'
CRYPTO_free_ex_data(CRYPTO_EX_INDEX_COMP, ctx, &ctx->ex_data);
~~~ ^
c_zlib.c:228:55: error: no member named 'ex_data' in 'struct comp_ctx_st'
(struct zlib_state *)CRYPTO_get_ex_data(&ctx->ex_data,
~~~ ^
c_zlib.c:257:55: error: no member named 'ex_data' in 'struct comp_ctx_st'
(struct zlib_state *)CRYPTO_get_ex_data(&ctx->ex_data,
~~~ ^
1 warning and 6 errors generated.
make[2]: *** [c_zlib.o] Error 1
make[1]: *** [subdirs] Error 1
make: *** [build_crypto] Error 1
?2[steffen@sherwood openssl.git]$ gl1

--steffen

[Salz, Rich]

> c_zlib.c:113:5: warning: excess elements in struct initializer
> NULL,
> ^~~~

Are you sure you have an accurate copy of master?

The EX_DATA was removed in 9a555706a3fb8f6622e1049ab510a12f4e1bc6a2 as part of making the COMP structures opaque.

[Steffen Nurpmeso]

Matt Caswell <ma...@openssl.org> wrote:

|On 19/05/15 17:40, Kurt Roeckx wrote:
|> I think that we should just provide the SSLv23_client_method define
|> without the need to enable something, and I guess I missed
|> something during the review in that case.
|

|The reason you need to enable something is that SSLv23_client_method is
|now deprecated. If you want it to "just work" then you would need to
|un-deprecate it. That's ok but it has the disadvantage that the old name
|will then stick around indefinitely and quite probably will be used even
|for new code.

It seems to me you should introduce a multiple-step deprecation
scheme.
But this function series in particular is documented as
"effectively the way to go" in a very famous book that is so old
that it now can be downloaded for free, and i'd expect that almost
all software projects use it: turning it off overnight seems to be
a bad decision to me.

While here, so let me add my opinion, and that is that it would
possibly be better to allow NULL or (maybe better) (a) special
(*)-1(,2,3) constant(s) arguments to SSL_CTX_new() instead of
replacing SSLv23_(client_)?method() with a different
protocol-multiplexer. E.g,, SSL_CTX_new(SSL_METHOD_ANY) or the
like. I'd expect that the actual protocol limitation is done via
_set_options() or SSL_CONF_CTX_cmd() later on anyway, just as
documented.

--steffen

[Steffen Nurpmeso]

"Salz, Rich" <rs...@akamai.com> wrote:
|> c_zlib.c:113:5: warning: excess elements in struct initializer
|> NULL,
|> ^~~~
|
|Are you sure you have an accurate copy of master?
|
|The EX_DATA was removed in 9a555706a3fb8f6622e1049ab510a12f4e1bc6a2 \
|as part of making the COMP structures opaque.

That was the commit i had blamed as the culprit, yes. :)

¡Hasta la victoria siempre!

[Gisle Vanem]

Salz, Rich wrote:

>> c_zlib.c:113:5: warning: excess elements in struct initializer
>> NULL,
>> ^~~~
>
> Are you sure you have an accurate copy of master?
>
> The EX_DATA was removed in 9a555706a3fb8f6622e1049ab510a12f4e1bc6a2 as part of making the COMP structures opaque.

He's right, the c_zlib.c is broken if you compile with '-DZLIB'
(and not '-DZLIB_SHARED'):

crypto/comp/c_zlib.c(115) : error C2078: too many initializers
crypto/comp/c_zlib.c(203) : error C2039: 'ex_data' : is not a member of 'comp_ctx_st'
f:\mingw32\src\inet\crypto\openssl\crypto\comp\comp_lcl.h(68) : see declaration of 'comp_ctx_st'
crypto/comp/c_zlib.c(203) : error C2198: 'CRYPTO_new_ex_data' : too few arguments for call

Try it and see for yourself.

--
--gv