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 a month) is a simple must. Yes, open source
[openssl-users] NEed help
I am trying to compile openssl 1.0.2 SNAP 20150801 and now I get if [ -n libcrypto.so.1.0.0 libssl.so.1.0.0 ]; then (cd ..; make libcrypto.so.1.0.0); fi [ -z ] || gcc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=pentium3 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso fips_premain.c fipscanister.o libcrypto.a -ldl -lm -lc /usr/lib/libc.a(sha.o): In function `SHA': sha.o(.text+0x0): multiple definition of `SHA' libcrypto.a(sha_one.o):/usr/source/openssl-1.0.2-stable-SNAP-20150801/crypto/sha/sha_one.c:66: first defined here ld: Warning: size of symbol `SHA' changed from 142 to 92 in /usr/lib/libc.a(sha.o) /usr/lib/libc.a(malloc.o)(.text+0x16): undefined reference to `__progname' /usr/lib/libc.a(malloc.o)(.text+0xe0): undefined reference to `__progname' /usr/lib/libc.a(syslog.o): In function `vsyslog': syslog.o(.text+0x3a5): undefined reference to `__progname' /usr/lib/libc.a(getenv.o): In function `__findenv': getenv.o(.text+0x65): undefined reference to `environ' getenv.o(.text+0x72): undefined reference to `environ' /usr/lib/libc.a(exec.o): In function `execl': exec.o(.text+0x103): undefined reference to `environ' /usr/lib/libc.a(exec.o): In function `execv': exec.o(.text+0x26b): undefined reference to `environ' /usr/lib/libc.a(exec.o): In function `execvp': exec.o(.text+0x400): undefined reference to `environ' /usr/lib/libc.a(exec.o)(.text+0x4da): more undefined references to `environ' follow *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Pointers please on how to fix. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Abuse a man unjustly, and you will make friends for him. -Edgar Watson Howe ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Debugging a compile issue
A few weeks ago, I overloaded my server and compiler and now I get signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: verify error *** Error code 1 Stop. *** Error code 1 Stop. How can debug and rectify the situation? I do need to move forward. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Abuse a man unjustly, and you will make friends for him. -Edgar Watson Howe ___ 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] Debugging a compile issue
On Sat, Aug 01, 2015 at 04:15:16PM +, Dr. Stephen Henson wrote: On Sat, Aug 01, 2015, The Doctor wrote: A few weeks ago, I overloaded my server and compiler and now I get signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: verify error *** Error code 1 Stop. *** Error code 1 Stop. How can debug and rectify the situation? I do need to move forward. I answered this a while back. Sorry for missing the inital reply. You should have some files called cms.err and cms.out in the test directory. What is in them? cme.err file ls: error initializing month strings Error reading S/MIME message 135072992:error:0D0D40D1:asn1 encoding routines:SMIME_read_ASN1:no content type: asn_mime.c:440: amd cms.out is blank Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Abuse a man unjustly, and you will make friends for him. -Edgar Watson Howe ___ 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: 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] Debugging a compile issue
On Sat, Aug 01, 2015, The Doctor wrote: A few weeks ago, I overloaded my server and compiler and now I get signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: verify error *** Error code 1 Stop. *** Error code 1 Stop. How can debug and rectify the situation? I do need to move forward. I answered this a while back. You should have some files called cms.err and cms.out in the test directory. What is in them? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Debugging a compile issue
On Sat, Aug 01, 2015, The Doctor wrote: On Sat, Aug 01, 2015 at 04:15:16PM +, Dr. Stephen Henson wrote: On Sat, Aug 01, 2015, The Doctor wrote: A few weeks ago, I overloaded my server and compiler and now I get signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: verify error *** Error code 1 Stop. *** Error code 1 Stop. How can debug and rectify the situation? I do need to move forward. I answered this a while back. Sorry for missing the inital reply. You should have some files called cms.err and cms.out in the test directory. What is in them? cme.err file ls: error initializing month strings Error reading S/MIME message 135072992:error:0D0D40D1:asn1 encoding routines:SMIME_read_ASN1:no content type: asn_mime.c:440: That's weird, what kind of system is this? Not sure what is causing that ls error. There should also be a file test.cms created which is 6879 bytes long for that test on my system. The only immediate possibility I can think of is that the file isn't written to properly for some reason (disk full?). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
