[openssl-users] [openssl-1.0.2d] default SSL handshake fails
Hello, I was trying to establish a secure connection from an old Linux box to an internal AD server (via LDAPS) but it was failing during the handshake. The AD server accepts SSL2, SSL3 and TLS1. See below the output: $ openssl s_client -connect myserver.rogers.com:636 -CAfile /home/myuser/openssl/certs/myserver_cert.pem CONNECTED(0003) 182899955200:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 318 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated --- However, if I add any of the following command line options then it works: -ssl2, -ssl3, -tls1, -no_tls1, -no_tls1_1, -no_tls1_2. See below the output: $ openssl s_client -connect myserver.rogers.com:636 -CAfile /home/myuser/openssl/certs/myserver_cert.pem -tls1 CONNECTED(0003) depth=1 C = CA, O = Rogers Inc., OU = Security, CN = Architecture verify return:1 depth=0 CN = MYSERVER.rogers.com verify return:1 --- Certificate chain 0 s:/CN=MSERVER.rogers.com i:/C=CA/O=Rogers Inc./OU=Security/CN=Architecture --- Server certificate -BEGIN CERTIFICATE- ... -END CERTIFICATE- subject=/CN=MYSERVER.rogers.com issuer=/C=CA/O=Rogers Inc./OU=Security/CN=Architecture --- Acceptable client certificate CA names ... Client Certificate Types: RSA sign, DSA sign --- SSL handshake has read 4746 bytes and written 404 bytes --- New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1 Cipher: RC4-MD5 Session-ID: 6D055CFB1BC5194D8B3BD939EADFD5AFF2E19D92CA010A54696403E63E99 Session-ID-ctx: Master-Key: 707D5B10E21FF30B29238D6637C19ACC79382208DBE8F72A05C605424B63258B1B1C4A83C67F17B8E0A62EF67B2B6703 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1438364635 Timeout : 7200 (sec) Verify return code: 0 (ok) --- This is the OpenSSL version I'm using: $ openssl version -a OpenSSL 1.0.2d 9 Jul 2015 built on: reproducible build, date unspecified platform: linux-x86_64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM OPENSSLDIR: "/home/myuser/openssl" My client box is an old Red Hat Enterprise Linux AS release 4 (Nahant Update 9). Below is a little extra info on it, in case it helps: $ uname -a Linux elxin009 2.6.9-100.ELsmp #1 SMP Tue Feb 1 12:04:42 EST 2011 x86_64 x86_64 x86_64 GNU/Linux $ ldd ~/bin/openssl libssl.so.1.0.0 => /home/myuser/lib/libssl.so.1.0.0 (0x002a95558000) libcrypto.so.1.0.0 => /home/myuser/lib/libcrypto.so.1.0.0 (0x002a956c9000) libdl.so.2 => /lib64/libdl.so.2 (0x0035ebe0) libz.so.1 => /home/myuser/lib/libz.so.1 (0x002a959e2000) libc.so.6 => /lib64/tls/libc.so.6 (0x0035eb90) /lib64/ld-linux-x86-64.so.2 (0x00552000) One final additional information is that I tried to do the exact same thing from a CentOS 6.6 client server and it just worked without any issues using CentOS standard RPMs. However the OpenSSL version there is the following: $ openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013 built on: Mon Jun 15 18:29:40 UTC 2015 platform: linux-x86_64 options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: "/etc/pki/tls" engines: dynamic Since my ultimate goal is to connect to the server via LDAPS but apparently OpenLDAP doesn't let me force a particular protocol (TLS1) then I feel I'm stuck. Perhaps I will recompile OpenSSL without TLS to see if it works, but I really don't want to this way. Any ideas how I can make this work? Is this a bug during the handshake phase? Thank you, Felix This communication is confidential. We only send and receive email on the basis of the terms set out at www.rogers.com/web/content/
Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails
On Fri, Jul 31, 2015 at 06:43:18PM +, Felix Almeida wrote: > I was trying to establish a secure connection from an old Linux box to an > internal AD server (via LDAPS) but it was failing during the handshake. > The AD server accepts SSL2, SSL3 and TLS1. Is it Windows server 2003? It likely only supports RC4 and 3DES, and only if these appear in the first 64 elements of the client's cipherlist. When a TLS 1.2 handshake is sent, may newer ciphers appear before the server's RC4 and 3DES (the latter is broken in Microsoft Exchange on Windows 2003, but may work with LDAP). > However, if I add any of the following command line options then it works: > -ssl2, -ssl3, -tls1, -no_tls1, -no_tls1_1, -no_tls1_2. All these disable TLS 1.2 (and perhaps other protocol versions), and result in a shorter cipherlist. > SSL-Session: > Protocol : TLSv1 > Cipher: RC4-MD5 Bingo: RC4-MD5, it likely also supports RSA-SHA. Here's a sensibly trimmed, but widely interoperable cipherlist: $ c='HIGH:MEDIUM:@STRENGTH:+3DES:+RC4:!aNULL:!MD5:!SRP:!PSK:!aDSS:!kECDH:!kDH:!SEED,!IDEA:!RC2:!RC5' $ openssl s_client -cipher "$c" ... The resulting cipherlist with OpenSSL 1.0.2 is: 1:ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD 2:ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD 3:ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 4:ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 5:ECDHE-RSA-AES256-SHASSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 6:ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 7:DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD 8:DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 9:DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 10:DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 11:AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD 12:AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 13:AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 14:CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 15:ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD 16:ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD 17:ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 18:ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 19:ECDHE-RSA-AES128-SHASSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 20:ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 21:DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD 22:DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 23:DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 24:DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 25:AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD 26:AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 27:AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 28:CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1 29:ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1 30:ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1 31:EDH-RSA-DES-CBC3-SHASSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 32:DES-CBC3-SHASSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 33:ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 34:ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 35:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 Your LDAP server will choose #35: RC4-SHA. Other servers will make better choices, and nothing remotely mainstream or required for interoperability is excluded. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails
I've tested other OpenSSL versions and everything goes well up to version 1.0.1o, starting from 1.0.2 I see this handshake error. I also tried to disable TLS on 1.0.2d by passing "no-tls" to the config script, but this broke the building process (make stopped with an error). So I believe I will stick with version 1.0.1o for now. :-\ -Original Message- From: Felix Almeida Sent: Friday, July 31, 2015 2:43 PM To: 'openssl-users@openssl.org' Subject: [openssl-1.0.2d] default SSL handshake fails Hello, I was trying to establish a secure connection from an old Linux box to an internal AD server (via LDAPS) but it was failing during the handshake. The AD server accepts SSL2, SSL3 and TLS1. See below the output: $ openssl s_client -connect myserver.rogers.com:636 -CAfile /home/myuser/openssl/certs/myserver_cert.pem CONNECTED(0003) 182899955200:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 318 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated --- However, if I add any of the following command line options then it works: -ssl2, -ssl3, -tls1, -no_tls1, -no_tls1_1, -no_tls1_2. See below the output: $ openssl s_client -connect myserver.rogers.com:636 -CAfile /home/myuser/openssl/certs/myserver_cert.pem -tls1 CONNECTED(0003) depth=1 C = CA, O = Rogers Inc., OU = Security, CN = Architecture verify return:1 depth=0 CN = MYSERVER.rogers.com verify return:1 --- Certificate chain 0 s:/CN=MSERVER.rogers.com i:/C=CA/O=Rogers Inc./OU=Security/CN=Architecture --- Server certificate -BEGIN CERTIFICATE- ... -END CERTIFICATE- subject=/CN=MYSERVER.rogers.com issuer=/C=CA/O=Rogers Inc./OU=Security/CN=Architecture --- Acceptable client certificate CA names ... Client Certificate Types: RSA sign, DSA sign --- SSL handshake has read 4746 bytes and written 404 bytes --- New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1 Cipher: RC4-MD5 Session-ID: 6D055CFB1BC5194D8B3BD939EADFD5AFF2E19D92CA010A54696403E63E99 Session-ID-ctx: Master-Key: 707D5B10E21FF30B29238D6637C19ACC79382208DBE8F72A05C605424B63258B1B1C4A83C67F17B8E0A62EF67B2B6703 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1438364635 Timeout : 7200 (sec) Verify return code: 0 (ok) --- This is the OpenSSL version I'm using: $ openssl version -a OpenSSL 1.0.2d 9 Jul 2015 built on: reproducible build, date unspecified platform: linux-x86_64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM OPENSSLDIR: "/home/myuser/openssl" My client box is an old Red Hat Enterprise Linux AS release 4 (Nahant Update 9). Below is a little extra info on it, in case it helps: $ uname -a Linux elxin009 2.6.9-100.ELsmp #1 SMP Tue Feb 1 12:04:42 EST 2011 x86_64 x86_64 x86_64 GNU/Linux $ ldd ~/bin/openssl libssl.so.1.0.0 => /home/myuser/lib/libssl.so.1.0.0 (0x002a95558000) libcrypto.so.1.0.0 => /home/myuser/lib/libcrypto.so.1.0.0 (0x002a956c9000) libdl.so.2 => /lib64/libdl.so.2 (0x0035ebe0) libz.so.1 => /home/myuser/lib/libz.so.1 (0x002a959e2000) libc.so.6 => /lib64/tls/libc.so.6 (0x0035eb90) /lib64/ld-linux-x86-64.so.2 (0x00552000) One final additional information is that I tried to do the exact same thing from a CentOS 6.6 client server and it just worked without any issues using CentOS standard RPMs. However the OpenSSL version there is the following: $ openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013 built on: Mon Jun 15 18:29:40 UTC 2015 platform: linux-x86_64 options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: "/etc/pki/tls" engines: dynamic Since my ultimate go
Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails
On Fri, Jul 31, 2015 at 08:47:45PM +, Felix Almeida wrote: > I've tested other OpenSSL versions and everything goes well up to version > 1.0.1o, starting from 1.0.2 I see this handshake error. It seems you're posting follow-ups without checking whether your original post was answered. > I also tried to disable TLS on 1.0.2d by passing "no-tls" to the config > script, but this broke the building process (make stopped with an error). > So I believe I will stick with version 1.0.1o for now. :-\ Or configure a cipherlist more compatible with a long obsolete and no longer supported Windows 2003 TLS stack. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails
On 31-07-2015 23:06, Viktor Dukhovni wrote: On Fri, Jul 31, 2015 at 08:47:45PM +, Felix Almeida wrote: I've tested other OpenSSL versions and everything goes well up to version 1.0.1o, starting from 1.0.2 I see this handshake error. It seems you're posting follow-ups without checking whether your original post was answered. I also tried to disable TLS on 1.0.2d by passing "no-tls" to the config script, but this broke the building process (make stopped with an error). So I believe I will stick with version 1.0.1o for now. :-\ Or configure a cipherlist more compatible with a long obsolete and no longer supported Windows 2003 TLS stack. The Windows 2003 TLS stack became unsupported for most (but /not all/) users less than 20 days ago. Treating it as marginal and not as something that any core networking library needs to be compatible (even *tested* with) out of the box is another symptom of the useless attitudes that permeate the new OpenSSL leadership. The old OpenSSL project belonged to the long standing tradition of making sure that Internet software needs to work with the quirks of anything it could reasonably encounter on any real world network, including both the Internet, the US military networks (which have allegedly paid a boatload of money for continued Win2003 support) and any closed site networks that reuse Internet protocols for their internal operations. It would have been a serious brown bag moment for the old maintainers to discover this in a release made that close to (if not even overlapping) the vendor support period for such a widely deployed system. There is a lot of utility software which is linked to OpenSSL libraries with very little user configurability and which is simply expected to "just work" when transferring data off a (not so) old Windows computer. The old team would have gone out of their way to make sure the standard OpenSSL code would generate backward compatible hello records by default, e.g. by ensuring that the strongest enabled Win 5.x compatible cipher was within the first 64 ciphers if that is indeed the technical solution. Such real world quality issues are much more important than making sure broken test tools don't complain that code to prevent accidental heap corruption is not being called by the current test suite because the relevant coding errors have not yet happened. OpenSSL is supposed to make sure that practical tools such as wget, curl, fetchmail etc. etc. can talk to almost any old SSL/TLS implementation that might be found in a dusty basement or on an old backup tape somewhere. Talking to an old Netscape Navigator 3.x or a clunky old printer should have a high chance of working, while talking to anything popular that was up to date with official security updates less than 2 years ago (let alone a month) is a simple must. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Soborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails
On Sat, Aug 01, 2015 at 06:56:16AM +0200, Jakob Bohm wrote: > >Or configure a cipherlist more compatible with a long obsolete and > >no longer supported Windows 2003 TLS stack. Note, I am suggesting compatibility. Yes while the obsolescence is long-standing, I was aware that the support status changed just recently. The problem with 3DES (for Exchange) is known since 2007, but the fix was never made mainstream, you had to request an obscure Hotfix (no longer available). > The Windows 2003 TLS stack became unsupported for most > (but /not all/) users less than 20 days ago. Treating > it as marginal and not as something that any core > networking library needs to be compatible (even *tested* > with) out of the box is another symptom of the useless > attitudes that permeate the new OpenSSL leadership. You should apologize, I resent that remark. Behind the scenes I am working to ensure that we maintain reasonable compatibility with that stack while it still exists in the field, and have helped many users craft sensible work-arounds for the bugs in that platform. It is not so easy to work around the rather severe limitations of Schannel in Windows 2003. OpenSSL would have to by default disable many of the new ciphers in TLS 1.2. Are you suggesting that the exclusions I am recommending should have been on by default? To accommodate a relatively rare and clearly broken peer? We could consider such an accommodation, but I think that the wiser course of action is to document the work-around for those who need it. This is the first report of this problem I've seen for an application protocol other SMTP. It was however immediately recognizable. > The old OpenSSL project belonged to the long standing > tradition of making sure that Internet software needs to > work with the quirks of anything it could reasonably > encounter on any real world network, including both the > Internet, the US military networks (which have allegedly > paid a boatload of money for continued Win2003 support) > and any closed site networks that reuse Internet protocols > for their internal operations. You seem to be pining for the project that lacked any resources to pay attention to documentation or code quality. I think on the whole more sensible trade-offs are being made now. And compatibility is still important. > It would have been a serious brown bag moment for the old > maintainers to discover this in a release made that close > to (if not even overlapping) the vendor support period for > such a widely deployed system. There is a lot of utility > software which is linked to OpenSSL libraries with very > little user configurability and which is simply expected > to "just work" when transferring data off a (not so) old > Windows computer. Who are these "old maintainers" who aren't around any more? > The old team would have gone out of their way to make sure > the standard OpenSSL code would generate backward compatible > hello records by default, e.g. by ensuring that the > strongest enabled Win 5.x compatible cipher was within the > first 64 ciphers if that is indeed the technical solution. The technical solution is correct, and can be deployed by users who need it. By default radical trimming of the cipherlist in new OpenSSL releases to accommodate a rather obsolete and already relatively rare platform is likely not the right call. Perhaps some of that "old team" you pine for might speak up as to what they would like to see done. Keep in mind that users who want to keep running legacy servers, can also keep running legacy clients, they don't need to uprade to anything beyond 1.0.1, that's still supported, and interoperates with Schannel from 2003 by default. $ for r in *; do echo "=== $r ==="; $r/bin/openssl ciphers -v 'DEFAULT:!PSK:!SRP' | grep -n '^RC4-SHA'; done === OpenSSL_0_9_8 === 11:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 === OpenSSL_1_0_0 === 29:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 === OpenSSL_1_0_1 === 57:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 === OpenSSL_1_0_2 === 75:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 === OpenSSL_master === 93:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 [ The reason I'm excluding PSK and SRP is that IIRC the client only actually includes these in the HELLO cipher list when an appropriate password callback is enabled). ] > OpenSSL is supposed to make sure that practical tools such > as wget, curl, fetchmail etc. etc. can talk to almost any > old SSL/TLS implementation that might be found in a dusty > basement or on an old backup tape somewhere. Talking to an > old Netscape Navigator 3.x or a clunky old printer should > have a high chance of working, while talking to anything > popular that was up to date with official security updates > less than 2 years ago (let alone
Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails
On Sat, Aug 01, 2015 at 06:56:16AM +0200, Jakob Bohm wrote: > > The old team would have gone out of their way to make sure > the standard OpenSSL code would generate backward compatible > hello records by default So it's my understanding that you suggest the default OpenSSL client should: - Only support SSLv2, SSLv3 and TLS1.0 because things break when we we try to talk to some sites indicating we support TLS 1.1 and/or 1.2? Maybe we should even disable TLS 1.0 and SSLv3? - Don't send any TLS extentions, since some sites don't support it? - Don't send any cipher strings with the first byte different from 0 because some implemantation don't look at the first byte and might then select a cipher we didn't announce? - Enable all the work arounds for broken implementations again, even when they can be exploited? - Give RC4 such a priority by default that it's in the list before much stronger ciphers because that's the only cipher from our default list that works with some implementations, even when the RFCs say we should disable RC4 by default? I guess we should just stop trying to improve in general. Kurt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails
On Sat, Aug 01, 2015 at 04:23:54PM +0200, Kurt Roeckx wrote: > > The old team would have gone out of their way to make sure > > the standard OpenSSL code would generate backward compatible > > hello records by default > > So it's my understanding that you suggest the default OpenSSL > client should: > > - Only support SSLv2, SSLv3 and TLS1.0 because things break when > we we try to talk to some sites indicating we support TLS 1.1 > and/or 1.2? Maybe we should even disable TLS 1.0 and SSLv3? > - Don't send any TLS extentions, since some sites don't support > it? > - Don't send any cipher strings with the first byte different from > 0 because some implemantation don't look at the first byte and > might then select a cipher we didn't announce? > - Enable all the work arounds for broken implementations again, > even when they can be exploited? > - Give RC4 such a priority by default that it's in the list before > much stronger ciphers because that's the only cipher from our > default list that works with some implementations, even when the > RFCs say we should disable RC4 by default? > > I guess we should just stop trying to improve in general. There is a pragmatic "middle-ground" that I think we're actually largely successful at achieving. Nobody will adopt all the cool new stuff if it significantly breaks interoperability with the old. So we have, for example, the padding extension for the client HELLO to work around F5 problems, and various bug work-arounds are still enabled via SSL_OP_ALL. Neither full-steam ahead, nor maintaining compatibility crutches forever is the right answer. It turns out that the Windows 2003 stack issue has not received much attention outside the Postfix user community (Postfix enables anon_DH and anon_ECDH ciphers and so ran into this sooner than other applications). But even with Postfix, the impact has been rather modest, these systems are not that common. Should I have a made a greater fuss about ensuring interop with Windows 2003, I don't know. I certainly mentioned it on various non-Postfix lists at various times. Various members of the "old team" were on some of those lists. Perhaps more effort should have been made to accommodate such systems for a longer time, by enabling fewer new ciphers by default, but that's not what happened, and there have not been very many problem reports. All this I think points to a reasonably responsible process, with a largely reasonable outcome. If a consensus emerges around a "concise" cipherlist (note that to get there I had to disable DSS, which might not be popular in .gov circles, where perhaps it was actually used), I'd support that, but it is not clear to me that there's a compelling case to make this a default configuration. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails
On 01/08/2015 08:00, Viktor Dukhovni wrote: The Windows 2003 TLS stack became unsupported for most (but /not all/) users less than 20 days ago. Treating it as marginal and not as something that any core networking library needs to be compatible (even *tested* with) out of the box is another symptom of the useless attitudes that permeate the new OpenSSL leadership. You should apologize, I resent that remark. Behind the scenes I am working to ensure that we maintain reasonable compatibility with that stack while it still exists in the field, and have helped many users craft sensible work-arounds for the bugs in that platform. It is not so easy to work around the rather severe limitations of Schannel in Windows 2003. OpenSSL would have to by default disable many of the new ciphers in TLS 1.2. Are you suggesting that the exclusions I am recommending should have been on by default? To accommodate a relatively rare and clearly broken peer? We could consider such an accommodation, but I think that the wiser course of action is to document the work-around for those who need it. This is the first report of this problem I've seen for an application protocol other SMTP. It was however immediately recognizable. The old OpenSSL project belonged to the long standing tradition of making sure that Internet software needs to work with the quirks of anything it could reasonably encounter on any real world network, including both the Internet, the US military networks (which have allegedly paid a boatload of money for continued Win2003 support) and any closed site networks that reuse Internet protocols for their internal operations. You seem to be pining for the project that lacked any resources to pay attention to documentation or code quality. I think on the whole more sensible trade-offs are being made now. And compatibility is still important. It would have been a serious brown bag moment for the old maintainers to discover this in a release made that close to (if not even overlapping) the vendor support period for such a widely deployed system. There is a lot of utility software which is linked to OpenSSL libraries with very little user configurability and which is simply expected to "just work" when transferring data off a (not so) old Windows computer. Who are these "old maintainers" who aren't around any more? I have taken my time to answer this, as it deserved some careful thinking. The problem over the past year or so is not as much that any old maintainers have left, as that the entire project seems to have given off a "vibe" of being "under new management". Specifically, a number of decisions have the feel of a project that has been co-opted or taken over by someone eager to make sweeping changes for little apparent reason, someone with lots of idle lawyers on hand, like "Microsoft, various corporate partners, the CII, and/or the SFLC" (using a list from the latest public blog post), yet seemingly unaware of the dangers of combining a UK jurisdiction with phrases such as "the public benefit" in an area of technology which has historically been subject to much UK government interference over the past 70 years. I also see a tendency to throw historical decisions overboard with little effort to understand why such decisions might actually be or have been good decisions. For instance, in the penultimate blog post, most of the things removed under "dynamic memory cleanup" actually serve real purposes: protective parameter validation against future code bugs, thus by definition not counted in automated "coverage tools" (NULL checking before free), making malloc calls compile with C++ compilers (casting the return value of malloc to specific pointer type), forcing compiler errors if variable types change (that same cast!). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails
> Specifically, a number of decisions have the feel of a project that has been > co-opted or taken over by someone eager to make sweeping changes for > little apparent reason, someone with lots of idle lawyers on hand, like > "Microsoft, various corporate partners, the CII, and/or the SFLC" (using a > list > from the latest public blog post) Do you mean me? Or did you make a typo, and mean "members" rather than "someone" ? ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails
On 10/08/2015 20:12, Salz, Rich wrote: Specifically, a number of decisions have the feel of a project that has been co-opted or taken over by someone eager to make sweeping changes for little apparent reason, someone with lots of idle lawyers on hand, like "Microsoft, various corporate partners, the CII, and/or the SFLC" (using a list from the latest public blog post) Do you mean me? Or did you make a typo, and mean "members" rather than "someone" ? No, I meant someone like the examples at the end of the sentence. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
