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
[openssl-users] We're working on license changes
Please see https://www.openssl.org/blog/blog/2015/08/01/cla/ for some more details. Summary: Moving to Apache 2, CLA's coming, it will take time. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Unexpected error when I untar OpenSSL 1.0.2d
On Mon, Jul 27, 2015 at 10:21:07PM +0100, Matt Caswell wrote: On 27/07/15 20:50, Pavneet Jauhal wrote: Hi All, When I attempt to untar OpenSSL 1.0.2d tar-ball, I get an unexpected failure. Error looks something like this; openssl-1.0.2d/VMS/VMSify-conf.pl openssl-1.0.2d/VMS/WISHLIST.TXT tar: A lone zero block at 52140 I only see this with GNU tar. GNU tar is stricter than other tar programs. It expects to see a double zero block at the end of the tar file, and in this case there is only one. This is caused by a bug in a program called tardy which we use during the release process to clean up our tar files. Due to this problem we have now dropped its use so (hopefully) this shouldn't happen again. The error message is actually only a warning. The tar file should have still extracted successfully. It is safe to ignore this. Hi Matt. I took a look at tardy after reading your email. If the OpenSSL project would benefit from continued usage of tardy, you can re-build tardy 1.28 after applying my POSIX trailing zero-records fix [1]. Cheers. --mancha [1] http://sf.net/projects/mancha/files/misc/tardy-1.28_posix-eoa.diff -- https://twitter.com/mancha140 pgpLb1F1VNKKO.pgp Description: PGP signature ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Unexpected error when I untar OpenSSL 1.0.2d
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31/07/15 19:12, mancha wrote: On Mon, Jul 27, 2015 at 10:21:07PM +0100, Matt Caswell wrote: On 27/07/15 20:50, Pavneet Jauhal wrote: Hi All, When I attempt to untar OpenSSL 1.0.2d tar-ball, I get an unexpected failure. Error looks something like this; openssl-1.0.2d/VMS/VMSify-conf.pl openssl-1.0.2d/VMS/WISHLIST.TXT tar: A lone zero block at 52140 I only see this with GNU tar. GNU tar is stricter than other tar programs. It expects to see a double zero block at the end of the tar file, and in this case there is only one. This is caused by a bug in a program called tardy which we use during the release process to clean up our tar files. Due to this problem we have now dropped its use so (hopefully) this shouldn't happen again. The error message is actually only a warning. The tar file should have still extracted successfully. It is safe to ignore this. Hi Matt. I took a look at tardy after reading your email. If the OpenSSL project would benefit from continued usage of tardy, you can re-build tardy 1.28 after applying my POSIX trailing zero-records fix [1]. That's cool. I did try to contact the original dev to get it fixed but got no response. After that we made the necessary changes so that we could remove the dependence so I don't think we will put it back in again now. It's good you've got a fix though for other users who run into this. Thanks Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVu8Y8AAoJENnE0m0OYESR/icIAIZbtlHyueMXd5ZzyYgT5S6/ dotbRjtE1iCaF/hxxPSMozIS80EfL4Ukww6zyd6UfSAszMg7fFLXPlWk66QBgRzs wNtG19pw15xrD/Aw5qz3VUZerGGmxi2OOE7r0jFIdrOOgZGVvXMepz7hRYR7kjTN qoIe7uYAmXtvnoagzZKukXA31sRS6MUYnji8cftGfcOcd7Ao6ARDt2R4c3RMC9B1 fIEBvQ/KTRDgRJOc7dUr8eB6SbY8YbWC/CMHpbAk85h7rIkqHETEuZXMO34rPfAG 3i0kYSOnGe7IBmDjEy8pxKaFhOeAEB/mCsZZCqC+FrWAZ0pywiNqtJBwopWiwAs= =l17J -END PGP SIGNATURE- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[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
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 goal is to
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] Size of OpenSSL ECDSA/DSA Implementation
Am 22.07.2015 um 12:08 schrieb Jakob Bohm: On 21/07/2015 22:07, Michaela Schoenbauer wrote: Hi, I'm currently working on my Master thesis, and the topic is about ECDSA implementations and DSA implementations in the context of small embedded systems. I'd like to try out OpenSSL but I'm not sure if I can configure it to be small enough for the embedded devices I use. For my purpose a custom built of the library should exclude all SSL/TLS functionality and only include (a) ECDSA support and (b) DSA support in another built. Does anyone know how small I can make the OpenSSL library? May the results be smaller than 10KB or which results can I expect? If anyone already tried something similar or has some answers/hints I would be thankful. Unfortunately, since the introduction (many years ago) of the EVP interface abstraction, it has gotten a lot harder to link libcrypto (the non-SSL part of OpenSSL) with just a few algorithms and little else. Best chance is to: 1. Use OpenSSL 1.0.2, not the future 1.1.0 which has removed some of what you need for this. 2. Build OpenSSL as static libraries, not as shared libraries/DLLs. 3. Use the raw ecdsa/dsa functions from ecdsa.h/dsa.h 4. Write your test program to only do the signing OR verification, not the key generation or other functions. 5. Write your test program to operate directly on the internal structures so you don't need the code space for the i2d/d2i conversion functions. 6. Use linker diagnostics and/or object dumper programs to see which functions and source files get linked into your embedded binary. 7. Look at the actual implementation code in the OpenSSL source code to see if there is even more that can be trimmed out, e.g. by splitting some source files that contain multiple functions so one file contains the functions you use, and another file ther other. 8. Look at the actual ecdsa/dsa implementation code to see if it invokes the RNG for each signature or uses a cryptographic formula to deterministically generate a message/key dependent adversary unknowable per-signature key. This makes a big size difference because the RNG itself needs so much non-dsa code. 9. For ecdsa, look at the implementation code to see if it branches into different implementations depending on the curve used for the public/private key pair. If so, create a special version supporting only the curve you use for your test. With all this, you might be able to get a code size a lot smaller than what you would get by just following the official guides on how to do the same operation with supported high level functions. But I am not at all sure if you can still get as low as you need. A completely different approach is to just cut and paste snippets from the OpenSSL ecdsa/dsa code and hand optimize it for minimum size. As another datapoint for your investigation, the ECDSA-like signature scheme recently promoted by D.J.Bernstein apparently hand optimized assembler code, yet I seem to recall it being larger than 10Kio code. 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 Thank you so much for your detailed answer and your help! I will try your tips. Michaela ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
