Re: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction
He's right, the c_zlib.c is broken if you compile with '-DZLIB' (and not '-DZLIB_SHARED'): Ah. Thanks, now I get it. The attached patch seems to fix the build, but exposes a possible memory leak; ssltest fails. I won't get a chance to look at this until next week, in case anyone wants to look at it early. comp.patch Description: comp.patch ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction
Matt Caswell m...@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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction
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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction
Kurt Roeckx k...@roeckx.be wrote: |On Tue, May 19, 2015 at 08:03:05PM +0200, Steffen Nurpmeso wrote: | Steffen Nurpmeso sdao...@yandex.com wrote: ||Kurt Roeckx k...@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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction
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! --steffen ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction
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. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction
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 - 1.26
+++ HTTP.c 4 Jan 2015 22:24:27 - 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
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction
Kurt Roeckx k...@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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction
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
0x1010L 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 = 0x1010L)
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 - 1.26
+++ HTTP.c 4 Jan 2015 22:24:27 - 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 = 0x1010L)
+ 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 = 0x1010L)
+ 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
Re: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction
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 = 0x1010L) + 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 = 0x1010L) + 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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction
Steffen Nurpmeso sdao...@yandex.com wrote:
|Kurt Roeckx k...@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;
};
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction
On Tue, May 19, 2015 at 08:03:05PM +0200, Steffen Nurpmeso wrote: Steffen Nurpmeso sdao...@yandex.com wrote: |Kurt Roeckx k...@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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
