From rishabh.dubey at igate.com Wed Apr 1 06:12:36 2015 From: rishabh.dubey at igate.com (Rishabh K Dubey) Date: Wed, 1 Apr 2015 06:12:36 +0000 Subject: [openssl-users] Is it mandatory to reverse windows signature while doing verification in OpenSSL? Message-ID: Dear, We have signed data on Win 7 using Crypto APIs and generated signature. We have observed this signature data needs to be reversed for verification using OpenSSL. If we reverse signature data and pass it to OpenSSL verification command then OpenSSL verifies it successfully. We wanted to confirm, whether such reversing of signature bytes is valid operation or not. Thanks in advance. Regards, Rishabh ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailadmin at igate.com . IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Apr 1 06:27:33 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 1 Apr 2015 06:27:33 +0000 Subject: [openssl-users] Is it mandatory to reverse windows signature while doing verification in OpenSSL? In-Reply-To: References: Message-ID: <20150401062732.GQ17637@mournblade.imrryr.org> On Wed, Apr 01, 2015 at 06:12:36AM +0000, Rishabh K Dubey wrote: > We have signed data on Win 7 using Crypto APIs and generated > signature. What sort of "signature" is that? > We have observed this signature data needs to be reversed > for verification using OpenSSL. What does "reversed" mean? > If we reverse signature data and > pass it to OpenSSL verification command then OpenSSL verifies it > successfully. What command would that be? > We wanted to confirm, whether such reversing of > signature bytes is valid operation or not. Rather difficult to say, since you've provided zero information. -- Viktor. From thomas.francis.jr at pobox.com Wed Apr 1 13:47:22 2015 From: thomas.francis.jr at pobox.com (Tom Francis) Date: Wed, 1 Apr 2015 09:47:22 -0400 Subject: [openssl-users] Is it mandatory to reverse windows signature while doing verification in OpenSSL? In-Reply-To: References: Message-ID: If you mean you?re using CryptSignHash(), and are reversing the bytes in the resulting signature, then yes, this is normal. You?ll need to reverse the bytes when verifying the signature with ANY other toolkit/library, including CNG. :) If it?s not too late, you should store the signature with the bytes reversed, and then reverse the bytes when you want to verify the signature with CryptVerifySignature(), so that nothing else needs to reverse the bytes. If you later switch from CryptoAPI to CNG, then you?ll be able to remove the byte reversing code, since CNG uses the same byte order as OpenSSL. CryptoAPI tends to put all large integer data in least significant byte first order (probably because somebody was accustomed to little endian on x86?). Every other library I?ve used does the opposite, so I strongly recommend any storage be different from what CryptoAPI produces/expects unless your main intent is to work only with CryptoAPI. TOM > On Apr 1, 2015, at 2:12 AM, Rishabh K Dubey wrote: > > Dear, > > > > We have signed data on Win 7 using Crypto APIs and generated signature. We have observed this such reversing of signature bytes is valid operation or not. Thanks in advance. > > > > Regards, > > Rishabh > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailadmin at igate.com. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From jonetsu at teksavvy.com Wed Apr 1 16:03:59 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Wed, 01 Apr 2015 12:03:59 -0400 Subject: [openssl-users] FIPS errors: finding causes for failure Message-ID: Hello, ? As part of development, still using the fips_hmac test code, this time on a target unit using 1.0.1e, the following errors are shown at the console: 3069614096:error:2D088086:FIPS routines:FIPS_selftest_x931:selftest failed:fips_rand_selftest.c:171: 3069614096:error:2D082086:FIPS routines:FIPS_selftest_cmac:selftest failed:fips_cmac_selftest.c:178: 3069614096:error:2D080086:FIPS routines:FIPS_selftest_aes:selftest failed:fips_aes_selftest.c:97: 3069614096:error:2D090086:FIPS routines:FIPS_selftest_aes_xts:selftest failed:fips_aes_selftest.c:383: 3069614096:error:2D083086:FIPS routines:FIPS_selftest_des:selftest failed:fips_des_selftest.c:102: What is the troubleshooting path from here ?? Is it only by going to the appropriate code line ?? In the first case, the FIPS_selftest_x931() is concerned, with the 171 line being: FIPSerr(FIPS_F_FIPS_SELFTEST_X931,FIPS_R_SELFTEST_FAILED).? Which basically means that the actual test code has to be examined. There is documentation in the User Guide, section 6.3.1, although it does not seem to be practical to find out the cause of the failure.? There are seemingly no log messages generated.? Information that would give hints as to why a specific test could fail would be useful.? In this case, there's mention of the V seed value being corrupted but only for simulation mode. In short, how to find what could be the cause(s) of FIPS test(s) failure(s) ? Regards. From steve at openssl.org Wed Apr 1 16:16:09 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 1 Apr 2015 16:16:09 +0000 Subject: [openssl-users] FIPS errors: finding causes for failure In-Reply-To: References: Message-ID: <20150401161609.GA20801@openssl.org> On Wed, Apr 01, 2015, jonetsu wrote: > Hello, > > ? As part of development, still using the fips_hmac test code, this time on a target unit using 1.0.1e, the following errors are shown at the console: > > 3069614096:error:2D088086:FIPS > routines:FIPS_selftest_x931:selftest > failed:fips_rand_selftest.c:171: > > 3069614096:error:2D082086:FIPS > routines:FIPS_selftest_cmac:selftest > failed:fips_cmac_selftest.c:178: > > 3069614096:error:2D080086:FIPS > routines:FIPS_selftest_aes:selftest > failed:fips_aes_selftest.c:97: > > 3069614096:error:2D090086:FIPS > routines:FIPS_selftest_aes_xts:selftest > failed:fips_aes_selftest.c:383: > > 3069614096:error:2D083086:FIPS > routines:FIPS_selftest_des:selftest > failed:fips_des_selftest.c:102: > > What is the troubleshooting path from here ?? Is it only by going to the appropriate code line ?? In the first case, the FIPS_selftest_x931() is concerned, with the 171 line being: FIPSerr(FIPS_F_FIPS_SELFTEST_X931,FIPS_R_SELFTEST_FAILED).? Which basically means that the actual test code has to be examined. There is documentation in the User Guide, section 6.3.1, although it does not seem to be practical to find out the cause of the failure.? There are seemingly no log messages generated.? Information that would give hints as to why a specific test could fail would be useful.? In this case, there's mention of the V seed value being corrupted but only for simulation mode. > > In short, how to find what could be the cause(s) of FIPS test(s) failure(s) ? > Does fips_test_suite from the FIPS module produce similar errors? Most tests are known answer tests (KAT). That is they pass known inputs to the algorithm and check to see if the output matches the expected value. As such the only reason a self test could fail is that the algorithm is misbehaving: the most common reason for that is a compiler bug. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rishabh.dubey at igate.com Thu Apr 2 04:11:36 2015 From: rishabh.dubey at igate.com (Rishabh K Dubey) Date: Thu, 2 Apr 2015 04:11:36 +0000 Subject: [openssl-users] Is it mandatory to reverse windows signature while doing verification in OpenSSL? In-Reply-To: References: Message-ID: Thanks Tom for Quick response. Regards, Rishabh -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Tom Francis Sent: Wednesday, April 01, 2015 7:17 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Is it mandatory to reverse windows signature while doing verification in OpenSSL? If you mean you?re using CryptSignHash(), and are reversing the bytes in the resulting signature, then yes, this is normal. You?ll need to reverse the bytes when verifying the signature with ANY other toolkit/library, including CNG. :) If it?s not too late, you should store the signature with the bytes reversed, and then reverse the bytes when you want to verify the signature with CryptVerifySignature(), so that nothing else needs to reverse the bytes. If you later switch from CryptoAPI to CNG, then you?ll be able to remove the byte reversing code, since CNG uses the same byte order as OpenSSL. CryptoAPI tends to put all large integer data in least significant byte first order (probably because somebody was accustomed to little endian on x86?). Every other library I?ve used does the opposite, so I strongly recommend any storage be different from what CryptoAPI produces/expects unless your main intent is to work only with CryptoAPI. TOM > On Apr 1, 2015, at 2:12 AM, Rishabh K Dubey wrote: > > Dear, > > > > We have signed data on Win 7 using Crypto APIs and generated signature. We have observed this such reversing of signature bytes is valid operation or not. Thanks in advance. > > > > Regards, > > Rishabh > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailadmin at igate.com. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailadmin at igate.com . IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From piotr.lobacz at radmor.com.pl Thu Apr 2 06:19:37 2015 From: piotr.lobacz at radmor.com.pl (Piotr =?UTF-8?Q?=C5=81obacz?=) Date: Thu, 02 Apr 2015 08:19:37 +0200 Subject: [openssl-users] QNX cross-compiled openssl with fips In-Reply-To: <1427798472.3082.6.camel@piotr-desktop> References: <1427356003.3211.9.camel@piotr-desktop> <1427450661.3208.3.camel@piotr-desktop> <1427798472.3082.6.camel@piotr-desktop> Message-ID: <1427955577.3152.3.camel@piotr-desktop> Ok finally my app is working and compiled with c++ compiler but the problem persist because elf incore is bad for QNX apps compiled with g++ or QCC compiler. It generates bad digest. Even incore2 generates bad digest, and i dunno why that happens. Any sugesstions? Dnia 2015-03-31, wto o godzinie 12:41 +0200, Piotr ?obacz pisze: > Ok i have finally managed to cross-compile openssl with fips for QNX > platform. What i did wass modifing the fipsld script not to input this > magical number[ $? -ne 42 ] && exit $? and the returned output of > "${FIPS_SIG}" -exe "${TARGET}" was saved in SIG variable, because this > line SIG=`"${TARGET}" tried to execute QNX compiled code on linux, what > is rather impossible, to get the returned digest and recompile the > target with it. Now with these little changes i was finally able to run > openssl fips cross compiled app on qnx and i can gladly say that it > works. > > Dnia 2015-03-27, pi? o godzinie 11:04 +0100, Piotr ?obacz pisze: > > Another problem is that compiled cross-compiled OpenSSL with fips should > > start in its own prompt but it only spews the expected signature and > > exits. I have modified fipsld scripts as shown in the manual and this > > does not help. Incore was used from the tarball but maybe i have to use > > some special modifications for QNX incore? > > > > Dnia 2015-03-26, czw o godzinie 08:46 +0100, Piotr ?obacz pisze: > > > Hello, > > > i have been able to cross-compile openssl with fips module and what i > > > want now is to use it within my project which is using C++. According to > > > the manual https://wiki.openssl.org/index.php/Fipsld_and_C%2B%2B i have > > > to modify fipsld to fipsld++. Everything works properly if i'm compiling > > > my own libraries which are being linked with static crypto.a but if i'm > > > going to compile some tests which are linking with those libraries i get > > > this error: > > > > > > /usr/lib/fips_premain.o: In function `FINGERPRINT_premain()': > > > /usr/lib/fips_premain.c:103: undefined reference to `FIPS_text_start()' > > > /usr/lib/fips_premain.c:116: undefined reference to > > > `FIPS_incore_fingerprint(unsigned char*, unsigned int)' > > > > > > According to the manual, problem occurs with C++ linker, but i have it > > > modified in fipsld++ so that now PREMAIN_DSO looks like: > > > > > > -x c "${PREMAIN_C}" -x none \ > > > > > > and this does not help. On Linux with gcc this was helpful but on QNX > > > cross compilation it does not. > > > > > > I would be pleased if somebody could point me what am i doing wrong... > > > > > > -- ________________________________________________________________________ Piotr ?obacz Biuro System?w i Oprogramowania RADMOR S.A. tel. (58) 6996 929 e-mail: piotr.lobacz at radmor.com.pl www.radmor.com.pl RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia NIP: 586-010-21-39 REGON: 190432077 KRS: 0000074029 (S?d Rejonowy Gda?sk-P??noc w Gda?sku) Kapita? zak?adowy wp?acony: 9 282 830 PLN From piotr.lobacz at radmor.com.pl Thu Apr 2 06:58:21 2015 From: piotr.lobacz at radmor.com.pl (Piotr =?UTF-8?Q?=C5=81obacz?=) Date: Thu, 02 Apr 2015 08:58:21 +0200 Subject: [openssl-users] QNX cross-compiled openssl with fips In-Reply-To: References: <1427356003.3211.9.camel@piotr-desktop> <1427450661.3208.3.camel@piotr-desktop> <1427798472.3082.6.camel@piotr-desktop> <1427955577.3152.3.camel@piotr-desktop> Message-ID: <1427957901.3152.7.camel@piotr-desktop> Yeah i have tried with it and modified it. But mine problem is that i am cross-compiling. I have used incore to generate digest and it works with qcc and i386-pc-nto-qnx6.4.0-gcc. But with i386-pc-nto-qnx6.4.0-g++ and QCC which is for c++ it does not work it generates bad digest. What is a problem because i have to use a machine with qnx to run the compiled code to get the proper digest and than recompile with it, what actually works because i've tested it. Dnia 2015-04-02, czw o godzinie 02:34 -0400, Jeffrey Walton pisze: > On Thu, Apr 2, 2015 at 2:19 AM, Piotr ?obacz wrote: > > Ok finally my app is working and compiled with c++ compiler but the > > problem persist because elf incore is bad for QNX apps compiled with g++ > > or QCC compiler. It generates bad digest. Even incore2 generates bad > > digest, and i dunno why that happens. Any suggestions? > > You might try fipsld++ > (https://wiki.openssl.org/index.php/Fipsld_and_C%2B%2B). Its for > handling C++ compilers. > > I'm not sure why the various symbols are not exported with extern "C". > > I don't recall trying it with a cross compile, though. It may work, it > may not work. Either way, it may give you some ideas. > > Jeff -- ________________________________________________________________________ Piotr ?obacz Biuro System?w i Oprogramowania RADMOR S.A. tel. (58) 6996 929 e-mail: piotr.lobacz at radmor.com.pl www.radmor.com.pl RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia NIP: 586-010-21-39 REGON: 190432077 KRS: 0000074029 (S?d Rejonowy Gda?sk-P??noc w Gda?sku) Kapita? zak?adowy wp?acony: 9 282 830 PLN From noloader at gmail.com Thu Apr 2 07:54:47 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 2 Apr 2015 03:54:47 -0400 Subject: [openssl-users] Is it mandatory to reverse windows signature while doing verification in OpenSSL? In-Reply-To: References: Message-ID: > We have signed data on Win 7 using Crypto APIs and generated signature. We > have observed this signature data needs to be reversed for verification > using OpenSSL. If we reverse signature data and pass it to OpenSSL > verification command then OpenSSL verifies it successfully. We wanted to > confirm, whether such reversing of signature bytes is valid operation or > not. Thanks in advance. > As Tom said, reversing the bytes is quite common when interop'ing with MS CAPI. See, for example, http://www.google.com/search?q=ms+capi+reverse+bytes. For the longest time, it was the only library I was aware that you had to be mindful of the endian issues. Poly1305 is now a similar island. Crypto++'s Integer class recently modified to take the little endian strings and byte arrays for testing straight from Bernstein's parameters. Jeff From rishabh.dubey at igate.com Thu Apr 2 08:46:22 2015 From: rishabh.dubey at igate.com (Rishabh K Dubey) Date: Thu, 2 Apr 2015 08:46:22 +0000 Subject: [openssl-users] Is it mandatory to reverse windows signature while doing verification in OpenSSL? In-Reply-To: References: Message-ID: Thanks Jeff for quick confirmation. Regards, Rishabh -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jeffrey Walton Sent: Thursday, April 02, 2015 1:25 PM To: OpenSSL Users List Subject: Re: [openssl-users] Is it mandatory to reverse windows signature while doing verification in OpenSSL? > We have signed data on Win 7 using Crypto APIs and generated > signature. We have observed this signature data needs to be reversed > for verification using OpenSSL. If we reverse signature data and pass > it to OpenSSL verification command then OpenSSL verifies it > successfully. We wanted to confirm, whether such reversing of > signature bytes is valid operation or not. Thanks in advance. > As Tom said, reversing the bytes is quite common when interop'ing with MS CAPI. See, for example, http://www.google.com/search?q=ms+capi+reverse+bytes. For the longest time, it was the only library I was aware that you had to be mindful of the endian issues. Poly1305 is now a similar island. Crypto++'s Integer class recently modified to take the little endian strings and byte arrays for testing straight from Bernstein's parameters. Jeff _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailadmin at igate.com . IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From igenyar at gmail.com Fri Apr 3 00:21:10 2015 From: igenyar at gmail.com (Igenyar Saharam) Date: Thu, 2 Apr 2015 17:21:10 -0700 Subject: [openssl-users] looking for source code of check_availability Message-ID: Hello, There are two questions. I am studying the book of Network Security with OpenSSL. In the source code listed, it refers to one function called "check_availability" but I cannot find the source of it. If you happen to have it, could you please let me know? Thank you for the help. While I am trying to implement "check_availability" myself, I use "select()" but sometimes it returns errno of EINTR. In such case, what shall I do? I don't know how to handle it properly. Is it risky to keep trying? Thanks again. Regards, Igenyar -------------- next part -------------- An HTML attachment was scrubbed... URL: From aerowolf at gmail.com Fri Apr 3 05:11:36 2015 From: aerowolf at gmail.com (Kyle Hamilton) Date: Thu, 02 Apr 2015 22:11:36 -0700 Subject: [openssl-users] JAR file of openssl source code. In-Reply-To: References: Message-ID: <551E2108.3010900@gmail.com> OpenSSL is written in C. It is distributed as a .tar.gz file, not a .jar file. jar is the format used by Java and certain Java Native Interface code, and is based on the zip file format. It's not generally to distribute C. tar.gz is a tar archive file (tar being the 'tape archive' program of UNIX and Linux), which has then been compressed with GNU gzip. It can be opened on Windows using 7-Zip, WinRAR, or many other tools. On GNU/Linux, it can be unpacked with `tar -xzvf openssl-versioncode.tar.gz`. On other UNIXen, it can be opened (assuming GNU gzip has been installed) with `gzip -d openssl-versioncode.tar.gz | tar xvf -`. The code can be downloaded from https://www.openssl.org/source/ . -Kyle H On 3/22/2015 11:29 AM, Niraj Sorathiya wrote: > > Hi, > > Thanks Matt and jar file of openssl source code is available ? > I searched a lot but didn't get. > > Regards, > Niraj. > > On 22-Mar-2015 8:01 PM, "Matt Caswell" > wrote: > > > > On 22/03/15 04:14, Niraj Sorathiya wrote: > > Hi, > > > > Can anyone tell me starting point or location of main method in > openssl > > source code which starts openssl command line toolkit ? > > > > Hi Niraj > > "main" is located in apps/openssl.c > > Matt > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From erwann.abalea at opentrust.com Fri Apr 3 08:56:54 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Fri, 03 Apr 2015 10:56:54 +0200 Subject: [openssl-users] Fwd to openssl-users Re: [openssl-dev] Why the issuer cannot be found? In-Reply-To: References: Message-ID: <551E55D6.3000403@opentrust.com> (Forwarded to openssl-users) The subjectName of file4.pem matches the issuerName of file3.pem, the signature block in file3.pem, when verified with the public key of file4.pem, gives a correct signature for the tbsCertificate of file3.pem. But Openssl also (incorrectly, IMO) checks that file4.pem.SKI matches file3.pem.AKI, and refuses to go further (here, AKI doesn't match SKI). -- Erwann ABALEA Le 03/04/2015 03:10, Yuting Chen a ?crit : > I used OpenSSL to verify a certificate file (file3.pem) against > another certificate file (file4.pem). OpenSSL reports that it cannot > find the issuer of the cert in file3.pem; while when I displays > file3.pem and file4.pem, it appears that the issuer of the cert in > file3.pem is the same as the subject of the cert in file4.pem. Did I > miss anything? > From piotr.lobacz at radmor.com.pl Fri Apr 3 09:16:58 2015 From: piotr.lobacz at radmor.com.pl (Piotr =?UTF-8?Q?=C5=81obacz?=) Date: Fri, 03 Apr 2015 11:16:58 +0200 Subject: [openssl-users] QNX cross-compiled openssl with fips In-Reply-To: <1427957901.3152.7.camel@piotr-desktop> References: <1427356003.3211.9.camel@piotr-desktop> <1427450661.3208.3.camel@piotr-desktop> <1427798472.3082.6.camel@piotr-desktop> <1427955577.3152.3.camel@piotr-desktop> <1427957901.3152.7.camel@piotr-desktop> Message-ID: <1428052618.3105.6.camel@piotr-desktop> Ok, whith few modifications to fipsld++ i can now link to libcrypto.so and libcrypto.a and applications are working correctly, but mine problem still persists because if i would like to dlopen my shared library compiled with static libcrypto.a and i'll try to run fips mode from that library i get an error: 755413103 which, i have read, means that library has an incorect digest and verification has failed. Now i found that fips_premain_dso is used to generate/get this digest from library but it does not generate or even does not output anything and it does not matter if it is linux/QNX or whatever platform it is. Maybe i'm using it wrong but could anubody tell me how to use this fips_premain_dso? I'm using it like that: LD_LIBRARY_PATH=/path/to/where/my/lib/is fips_premain_dso mylib.so And that does not output anything. Dnia 2015-04-02, czw o godzinie 08:58 +0200, Piotr ?obacz pisze: > Yeah i have tried with it and modified it. But mine problem is that i am > cross-compiling. I have used incore to generate digest and it works with > qcc and i386-pc-nto-qnx6.4.0-gcc. But with i386-pc-nto-qnx6.4.0-g++ and > QCC which is for c++ it does not work it generates bad digest. What is a > problem because i have to use a machine with qnx to run the compiled > code to get the proper digest and than recompile with it, what actually > works because i've tested it. > > Dnia 2015-04-02, czw o godzinie 02:34 -0400, Jeffrey Walton pisze: > > On Thu, Apr 2, 2015 at 2:19 AM, Piotr ?obacz wrote: > > > Ok finally my app is working and compiled with c++ compiler but the > > > problem persist because elf incore is bad for QNX apps compiled with g++ > > > or QCC compiler. It generates bad digest. Even incore2 generates bad > > > digest, and i dunno why that happens. Any suggestions? > > > > You might try fipsld++ > > (https://wiki.openssl.org/index.php/Fipsld_and_C%2B%2B). Its for > > handling C++ compilers. > > > > I'm not sure why the various symbols are not exported with extern "C". > > > > I don't recall trying it with a cross compile, though. It may work, it > > may not work. Either way, it may give you some ideas. > > > > Jeff > -- ________________________________________________________________________ Piotr ?obacz Biuro System?w i Oprogramowania RADMOR S.A. tel. (58) 6996 929 e-mail: piotr.lobacz at radmor.com.pl www.radmor.com.pl RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia NIP: 586-010-21-39 REGON: 190432077 KRS: 0000074029 (S?d Rejonowy Gda?sk-P??noc w Gda?sku) Kapita? zak?adowy wp?acony: 9 282 830 PLN From piotr.lobacz at radmor.com.pl Fri Apr 3 13:16:40 2015 From: piotr.lobacz at radmor.com.pl (Piotr =?UTF-8?Q?=C5=81obacz?=) Date: Fri, 03 Apr 2015 15:16:40 +0200 Subject: [openssl-users] QNX cross-compiled openssl with fips In-Reply-To: <1428052618.3105.6.camel@piotr-desktop> References: <1427356003.3211.9.camel@piotr-desktop> <1427450661.3208.3.camel@piotr-desktop> <1427798472.3082.6.camel@piotr-desktop> <1427955577.3152.3.camel@piotr-desktop> <1427957901.3152.7.camel@piotr-desktop> <1428052618.3105.6.camel@piotr-desktop> Message-ID: <1428067000.3105.9.camel@piotr-desktop> Ok i have finally managed to find what is the problem. The generated value of digest under linux had bad value. Now i have to correct incore file for QNX platform. Wish me luck or if anybody can help me with this i would be pleased. :) Dnia 2015-04-03, pi? o godzinie 11:16 +0200, Piotr ?obacz pisze: > Ok, whith few modifications to fipsld++ i can now link to libcrypto.so > and libcrypto.a and applications are working correctly, but mine problem > still persists because if i would like to dlopen my shared library > compiled with static libcrypto.a and i'll try to run fips mode from that > library i get an error: 755413103 which, i have read, means that library > has an incorect digest and verification has failed. Now i found that > fips_premain_dso is used to generate/get this digest from library but it > does not generate or even does not output anything and it does not > matter if it is linux/QNX or whatever platform it is. Maybe i'm using it > wrong but could anubody tell me how to use this fips_premain_dso? I'm > using it like that: > > LD_LIBRARY_PATH=/path/to/where/my/lib/is fips_premain_dso mylib.so > > And that does not output anything. > > Dnia 2015-04-02, czw o godzinie 08:58 +0200, Piotr ?obacz pisze: > > Yeah i have tried with it and modified it. But mine problem is that i am > > cross-compiling. I have used incore to generate digest and it works with > > qcc and i386-pc-nto-qnx6.4.0-gcc. But with i386-pc-nto-qnx6.4.0-g++ and > > QCC which is for c++ it does not work it generates bad digest. What is a > > problem because i have to use a machine with qnx to run the compiled > > code to get the proper digest and than recompile with it, what actually > > works because i've tested it. > > > > Dnia 2015-04-02, czw o godzinie 02:34 -0400, Jeffrey Walton pisze: > > > On Thu, Apr 2, 2015 at 2:19 AM, Piotr ?obacz wrote: > > > > Ok finally my app is working and compiled with c++ compiler but the > > > > problem persist because elf incore is bad for QNX apps compiled with g++ > > > > or QCC compiler. It generates bad digest. Even incore2 generates bad > > > > digest, and i dunno why that happens. Any suggestions? > > > > > > You might try fipsld++ > > > (https://wiki.openssl.org/index.php/Fipsld_and_C%2B%2B). Its for > > > handling C++ compilers. > > > > > > I'm not sure why the various symbols are not exported with extern "C". > > > > > > I don't recall trying it with a cross compile, though. It may work, it > > > may not work. Either way, it may give you some ideas. > > > > > > Jeff > > > -- ________________________________________________________________________ Piotr ?obacz Biuro System?w i Oprogramowania RADMOR S.A. tel. (58) 6996 929 e-mail: piotr.lobacz at radmor.com.pl www.radmor.com.pl RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia NIP: 586-010-21-39 REGON: 190432077 KRS: 0000074029 (S?d Rejonowy Gda?sk-P??noc w Gda?sku) Kapita? zak?adowy wp?acony: 9 282 830 PLN From joris at mesosphere.io Fri Apr 3 19:48:37 2015 From: joris at mesosphere.io (Joris Van Remoortere) Date: Fri, 3 Apr 2015 12:48:37 -0700 Subject: [openssl-users] HTTP / HTTPS on same port Message-ID: Hello, I would like to ask your opinion and advice on accepting HTTP / HTTPS connections on the same port. I currently have a prototype that peeks at the first byte after accepting a new connection, and dispatches to the appropriate routines based on whether the first byte is 0x16 or not. This came from looking at the TLS handshake protocol ( http://en.wikipedia.org/wiki/Transport_Layer_Security#Handshake_protocol) and testing different libraries. The motivation for this was to avoid the configuration nightmare of introducing a second port, both in our code, and for administrators (firewall rules, etc.). 1) Is it valid to assume that the 1st byte of the handshake protocol is a valid way to disambiguate the traffic? 2) Are there any corner cases I might be missing? 3) Are there any security reasons for not doing this? Thanks for your advice, Joris -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Apr 3 19:53:59 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 3 Apr 2015 19:53:59 +0000 Subject: [openssl-users] removing compression? Message-ID: I am thinking about removing compression and would like to know what the community thinks. At a minimum, I am going to remove the ability to add compression at run-time. This was never really documented. Moving forward, if someone wants to add a new compression scheme they will need to modify the OpenSSL source. This means COMP_METHOD becomes an internal datatype. But on a larger scale, does anyone use TLS compression? It has certainly caused problems with HTTP (see http://en.wikipedia.org/wiki/CRIME). And the best practice these days is to do it at the application layer, and feed the compressed bytes down to TLS. If this will cause problems for you, please post on the list, ideally within the next week. Thanks. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Apr 3 19:55:02 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 3 Apr 2015 19:55:02 +0000 Subject: [openssl-users] HTTP / HTTPS on same port In-Reply-To: References: Message-ID: <086a897304b147fc9cd07f8d28cbd028@ustx2ex-dag1mb2.msg.corp.akamai.com> It is a hack. Most people do it the other way and look for a G or P as the first letter. From andreas.magana.ctr at us.af.mil Fri Apr 3 19:52:34 2015 From: andreas.magana.ctr at us.af.mil (MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT) Date: Fri, 3 Apr 2015 19:52:34 +0000 Subject: [openssl-users] updating list of server account password Message-ID: <6ABA33135553E04E978A5ECCC07560D231A071B5@52ZHTX-D07-03C.area52.afnoapps.usaf.mil> Hello Mike, Don and Matt, At the point I am at this list of servers in my script I would really need someone with more experience to see if I even have the right scripting. #!/usr/bin/perl use strict; use Expect; my $timeout = 60; my @servers = qw( remotehost03 remotehost04 remotehost05 remotehost06 ); for my $server (@servers) { # do your thing with $server change_password($server); } sub change_password { my $system = shift; my $filename = "/var/tmp/expect_script.log"; my $ssh = Expect->new('ssh amagana@' . $system); $ssh->debug(1); $ssh->expect ( $timeout, [ qr/Password:/], [ qr/Are you sure you want to continue connecting \(yes\/no\)?/] ); if ($ssh->match() =~ m/Are you sure you want to continue connecting \(yes\/no\)?/ ) { $ssh->send("yes\r"); } elsif ($ssh->match() =~ m/Password:/ ) { $ssh->send("mypassword\n"); } #$ssh->log_file($filename, 'w'); $ssh->expect(60, '$'); $ssh->send("su - root\n"); $ssh->expect(60, 'Password:'); $ssh->send("rootpassword\n"); $ssh->expect(60, '#'); $ssh->send("passwd amagana\n"); $ssh->expect(60, 'New Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, 'Re-enter new Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, '#'); $ssh->close(); Respectfully, #!/usr/bin/perl use strict; use Expect; my $timeout = 60; my $filename = "/var/tmp/expect_script.log"; my $ssh = Expect->new('ssh amagana at remotehost'); $ssh->debug(1); $ssh->expect ( $timeout, [ qr/Password:/], [ qr/Are you sure you want to continue connecting \(yes\/no\)?/] ); if ($ssh->match() =~ m/Are you sure you want to continue connecting \(yes\/no\)?/ ) { $ssh->send("yes\r"); } elsif ($ssh->match() =~ m/Password:/ ) { $ssh->send("mypassword\n"); } #$ssh->log_file($filename, 'w'); $ssh->expect(60, '$'); $ssh->send("su - root\n"); $ssh->expect(60, 'Password:'); $ssh->send("rootpassword\n"); $ssh->expect(60, '#'); $ssh->send("passwd amagana\n"); $ssh->expect(60, 'New Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, 'Re-enter new Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, '#'); $ssh->close(); //SIGNED// Andy Maga?a UNIX Systems Administrator Diligent Contractor, 72nd Air Base Wing Tinker Air Force Base, Oklahoma Commercial: (405) 734-0341 -----Original Message----- From: mike nicholas [mailto:xmikenicholasx at gmail.com] Sent: Wednesday, April 01, 2015 9:46 AM To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT Cc: ESRY JR., DON; Matt Zagrabelny; expectperl-discuss at lists.sourceforge.net Subject: Re: [Expectperl-discuss] expect.pm not updating password Try something like this: my $exp = new Expect; $exp->log_stdout(1); $username = "XXXXXX"; $exp->spawn( "ssh -l ${username} ${ip} " ) or die "cannot spawn $command: $! \n"; $exp->log_file("./${log_dir}/$ip\_info.log"); print "\nspawning ssh connection to $ip on $time\n\n"; $exp->log_file->print( "\nspawning ssh connection to $ip on $time\n\n" ); $exp->expect(8, [ 'connecting' => sub { $exp->send("yes \n"); exp_continue; } ], [ 'assword:' => sub { $exp->send("$pw\n"); exp_continue; } ], [ '-re', '> ?$' => sub { break; }], [ 'try again' => sub { die " died from bad password.\n"; }], [ 'refused' => sub { die " died from connection refused.\n"; exp_continue; } ], [ eof => sub { die " died from eof.\n"; }], [ timeout => sub { $exp->hard_close(); }], ); On Wed, Apr 1, 2015 at 9:24 AM, MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT wrote: Now that I have a working script and thanks very much to you Matt and Don, I am trying to put in my script an if else because sometimes my script will encounter this : Are you sure you want to continue connecting (yes/no)?') what I did create are some variables is this correct and may I see an example if statement so that the script can make a decision and keep going? use Expect; my $knownhost = $ssh->expect(60, 'Are you sure you want to continue connecting (yes/no)?'); my $answer = $ssh->send("yes\n"); my $filename = "/var/tmp/expect_script.log"; //SIGNED// Andy Maga?a UNIX Systems Administrator Diligent Contractor, 72nd Air Base Wing Tinker Air Force Base, Oklahoma Commercial: (405) 734-0341 -----Original Message----- From: ESRY JR., DON [mailto:de3253 at att.com] Sent: Tuesday, March 31, 2015 4:16 PM To: Matt Zagrabelny; MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT Cc: expectperl-discuss at lists.sourceforge.net Subject: RE: [Expectperl-discuss] expect.pm not updating password I think you will want a log file to identify where the script failed. I recommend that you take out the 'w' from the $ssh->log_file($filename, 'w'); so it will append to the file rather than over writing it for each server. And then put in some sort of header for each server, something like: my $header = "\n\n======= $system =======\n"; $ssh->print_log_file($header); Or if you prefer a separate file for each server, then my $filename = "/var/tmp/expect_script_". $system ".log"; little stuff like this can be very frustrating. -----Original Message----- From: Matt Zagrabelny [mailto:mzagrabe at d.umn.edu] Sent: Tuesday, March 31, 2015 4:56 PM To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT Cc: expectperl-discuss at lists.sourceforge.net Subject: Re: [Expectperl-discuss] expect.pm not updating password On Tue, Mar 31, 2015 at 3:37 PM, MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT wrote: > Thank you Matt, > > I just don't know how to put it in a working way I learn by examples I > am a novice on perl and the modules. Maybe spend a day or two writing some basic perl programs so you feel more comfortable with this stuff. I'm sure there are truckloads of perl tutorials out there. I added some context below. You'll need to clean up the leading '>' characters. -m > > #!/usr/bin/perl > use strict; > > use Expect; > > # my @servers = qw( > # server1.example.net > # server2.example.net > # server3.example.net > # server4.example.net > # server5.example.net > # ); > # > # for my $server (@servers) { > # # do your thing with $server change_password($server); > # } > sub change_password { my $system = shift; my $filename = "/var/tmp/expect_script.log"; my $ssh = Expect->new('ssh amagana@' . $system); > $ssh->debug(1); > $ssh->log_file($filename, 'w'); > $ssh->expect(60, 'Password:'); > $ssh->send("mycurrentpassword\n"); > $ssh->expect(60, '$'); > $ssh->send("su - root\n"); > $ssh->expect(60, 'Password:'); > $ssh->send("myrootpassword\n"); > $ssh->expect(60, '#'); > $ssh->send("passwd amagana\n"); > $ssh->expect(60, 'New Password:'); > $ssh->send("mynewpassword\n"); > $ssh->expect(60, 'Re-enter new Password:'); > $ssh->send("mynewpassword\n"); $ssh->expect(60, '#'); > $ssh->send("exit\n"); $ssh->close(); } ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Expectperl-discuss mailing list Expectperl-discuss at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/expectperl-discuss ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Expectperl-discuss mailing list Expectperl-discuss at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/expectperl-discuss -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3357 bytes Desc: not available URL: From matt at openssl.org Fri Apr 3 20:43:27 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 03 Apr 2015 21:43:27 +0100 Subject: [openssl-users] HTTP / HTTPS on same port In-Reply-To: References: Message-ID: <551EFB6F.6000003@openssl.org> On 03/04/15 20:48, Joris Van Remoortere wrote: > Hello, > > I would like to ask your opinion and advice on accepting HTTP / HTTPS > connections on the same port. > > I currently have a prototype that peeks at the first byte after > accepting a new connection, and dispatches to the appropriate routines > based on whether the first byte is 0x16 or not. This came from looking > at the TLS handshake protocol > (http://en.wikipedia.org/wiki/Transport_Layer_Security#Handshake_protocol) > and testing different libraries. > > The motivation for this was to avoid the configuration nightmare of > introducing a second port, both in our code, and for administrators > (firewall rules, etc.). > > 1) Is it valid to assume that the 1st byte of the handshake protocol is > a valid way to disambiguate the traffic? > 2) Are there any corner cases I might be missing? There is a potential issue to consider if you were going to do it this way. All modern clients will send 0x16 as the first byte of their ClientHello. However this was not always the case, and you may encounter some legacy clients that do not do this (for example OpenSSL 0.9.8 doesn't). Historically it was common to send SSLv2 backward compatible ClientHellos - even if what is eventually negotiated is SSLv3 or above. OpenSSL 0.9.8 will happily negotiate TLS1.0 by sending a SSLv2 backward compatible ClientHello. Note this doesn't have anything to do with the support for SSLv2 itself. Even servers which have disabled SSLv2 (which is considered good practice), will usually accept this ClientHello format (OpenSSL 1.0.2 does). The first two bytes of the backward compatible format are the message length. The most significant bit of the first byte is always set, so this means you could conceivably receive anything from 0x80 or above, as well as 0x16 as your first byte. You may wish to look at how OpenSSL does protocol version detection to help you. See the function ssl23_get_client_hello() in ssl/s23_srvr.c of the OpenSSL 1.0.2 source code. Matt From Michael.Wojcik at microfocus.com Fri Apr 3 20:12:11 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 3 Apr 2015 20:12:11 +0000 Subject: [openssl-users] HTTP / HTTPS on same port In-Reply-To: <086a897304b147fc9cd07f8d28cbd028@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <086a897304b147fc9cd07f8d28cbd028@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Salz, Rich > Sent: Friday, April 03, 2015 15:55 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] HTTP / HTTPS on same port > > It is a hack. That's debatable. What's so sacred about separating traffic by port? Valid TLS traffic and valid plaintext HTTP traffic are distinguishable - there aren't any ambiguous cases. > Most people do it the other way and look for a G or P as the first letter. Now *that* is a hack. And wrong, and broken. Looking at the first few bytes to see if they're 1) ASCII uppercase letters and 2) form the prefix of a valid HTTP command would be satisfactory. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com From cloos at jhcloos.com Fri Apr 3 23:40:38 2015 From: cloos at jhcloos.com (James Cloos) Date: Fri, 03 Apr 2015 19:40:38 -0400 Subject: [openssl-users] HTTP / HTTPS on same port In-Reply-To: (Joris Van Remoortere's message of "Fri, 3 Apr 2015 12:48:37 -0700") References: Message-ID: >>>>> "JR" == Joris Van Remoortere writes: JR> I would like to ask your opinion and advice on accepting HTTP / HTTPS JR> connections on the same port. IPP support both w/ and w/o tls on port 631. Cups handles it like this: http://www.pwg.org/archives/ipp/2014/017906.html -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From Tyson at AI.SRI.COM Sat Apr 4 02:07:20 2015 From: Tyson at AI.SRI.COM (Mabry Tyson) Date: Fri, 03 Apr 2015 19:07:20 -0700 Subject: [openssl-users] Modulus field in text display of a certificate Message-ID: <551F4758.3090009@AI.SRI.COM> I happened to notice what seems to be an output glitch in the textual output of a certificate. I received a copy of the QuoVadis Root CA 2 certificate as a file. When I examined the certificate via openssl x509 -text -in /tmp/QV.cer (using OpenSSL 1.0.1 14 Mar 2012 as installed in Ubuntu 14.04) I noticed an extra first zero byte of the Modulus was shown, as compared to the display of that certificate in Firefox. > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 1289 (0x509) > Signature Algorithm: sha1WithRSAEncryption > Issuer: C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2 > ... > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (4096 bit) > Modulus: > 00:9a:18:ca:4b:94:0d:00:2d:af:03:29:8a:f0:0f: > ... > 09:62:04:92:16:10:d8:9e:27:47:fb:3b:21:e3:f8: > eb:1d:5b I believe there should be 4096/8 = 512 bytes in that modulus. There are 15 bytes shown per line. 512/15 = 34 with a remainder of 2. This output shows 513 bytes (34 lines plus a remainder of 3). From jb-openssl at wisemo.com Sat Apr 4 03:31:37 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Sat, 04 Apr 2015 05:31:37 +0200 Subject: [openssl-users] Fwd to openssl-users Re: [openssl-dev] Why the issuer cannot be found? In-Reply-To: <551E55D6.3000403@opentrust.com> References: <551E55D6.3000403@opentrust.com> Message-ID: <551F5B19.9020701@wisemo.com> (top posting like the rest of the thread) What makes you think it is incorrect to check the Key Identifier (where present) before checking a signature against a key? What other reasonable purpose could the Key Identifier fields serve? On 03/04/2015 10:56, Erwann Abalea wrote: > (Forwarded to openssl-users) > > The subjectName of file4.pem matches the issuerName of > file3.pem, the signature block in file3.pem, when verified > with the public key of file4.pem, gives a correct signature > for the tbsCertificate of file3.pem. But Openssl also > (incorrectly, IMO) checks that file4.pem.SKI matches > file3.pem.AKI, and refuses to go further (here, AKI doesn't > match SKI). > > Le 03/04/2015 03:10, Yuting Chen a ?crit : > > I used OpenSSL to verify a certificate file (file3.pem) > > against another certificate file (file4.pem). OpenSSL > > reports that it cannot find the issuer of the cert in > > file3.pem; while when I displays file3.pem and file4.pem, > > it appears that the issuer of the cert in file3.pem is the > > same as the subject of the cert in file4.pem. Did I miss > > anything? P.S. Don't put your e-mail sig in the middle of the mail, it causes standards-compliant mail programs to cut off everything below it when replying (because everyting below the -- marker is, by definition, just the e-mail sig). 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 From james.arivazhagan at gmail.com Sat Apr 4 03:40:01 2015 From: james.arivazhagan at gmail.com (James) Date: Sat, 4 Apr 2015 09:10:01 +0530 Subject: [openssl-users] HTTP / HTTPS on same port In-Reply-To: References: Message-ID: Hi, I suggested one such implementation in mongoose opensource web server You can check it in . https://groups.google.com/forum/#!msg/mongoose-users/IAzYHF0do-I/INc_VmLAe6gJ This is the function I added let me know if it is useful. static int CheckSSL(int nSocket) { /* taken from s23_svr.c int ssl23_get_client_hello(SSL *s) of openssl */ char szData [12] ; int nRet = 0 ; int n; memset ( szData, 0, sizeof(szData)); n = recv ( nSocket, szData, 11, MSG_PEEK ) ; if (n > 2) { if((szData[0] & 0x80) && (szData[2] == 1)) // SSL2_MT_CLIENT_HELLO { // SSLv2 nRet = 1; } else if(n > 9) { if ((szData[0] == 22 ) && // SSL3_RT_HANDSHAKE (szData[1] == 0x03) && // SSL3_VERSION_MAJOR (szData[5] == 1) && // SSL3_MT_CLIENT_HELLO ((szData[3] == 0 && szData[4] < 5) || (szData[9] == szData[1]))) { // SSLv3 nRet = 1; } } } return nRet; } On Sat, Apr 4, 2015 at 5:10 AM, James Cloos wrote: > >>>>> "JR" == Joris Van Remoortere writes: > > JR> I would like to ask your opinion and advice on accepting HTTP / HTTPS > JR> connections on the same port. > > IPP support both w/ and w/o tls on port 631. > > Cups handles it like this: > > http://www.pwg.org/archives/ipp/2014/017906.html > > -JimC > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Sat Apr 4 05:18:54 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Sat, 04 Apr 2015 07:18:54 +0200 Subject: [openssl-users] Modulus field in text display of a certificate In-Reply-To: <551F4758.3090009@AI.SRI.COM> References: <551F4758.3090009@AI.SRI.COM> Message-ID: <551F743E.6060106@wisemo.com> On 04/04/2015 04:07, Mabry Tyson wrote: > I happened to notice what seems to be an output glitch in the textual > output of a certificate. > > I received a copy of the QuoVadis Root CA 2 certificate as a file. > When I examined the certificate via > openssl x509 -text -in /tmp/QV.cer (using OpenSSL 1.0.1 14 Mar > 2012 as installed in Ubuntu 14.04) > I noticed an extra first zero byte of the Modulus was shown, as > compared to the display of that certificate in Firefox. > >> Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: 1289 (0x509) >> Signature Algorithm: sha1WithRSAEncryption >> Issuer: C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2 >> ... >> Subject Public Key Info: >> Public Key Algorithm: rsaEncryption >> Public-Key: (4096 bit) >> Modulus: >> 00:9a:18:ca:4b:94:0d:00:2d:af:03:29:8a:f0:0f: >> ... >> 09:62:04:92:16:10:d8:9e:27:47:fb:3b:21:e3:f8: >> eb:1d:5b > I believe there should be 4096/8 = 512 bytes in that modulus. There > are 15 bytes shown per line. 512/15 = 34 with a remainder of 2. This > output shows 513 bytes (34 lines plus a remainder of 3). > > This is a consequence of the ASN.1 DER/BER encoding rules: All INTEGER fields are signed, so when the most significant bit of a 2048 bit value is set, then it needs to be encoded and processed with an extra leading 0 byte. OpenSSL displays that leading 0 byte, while NSS (used by Firefox) apparently hides it. 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 From jb-openssl at wisemo.com Sat Apr 4 05:28:06 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Sat, 04 Apr 2015 07:28:06 +0200 Subject: [openssl-users] Modulus field in text display of a certificate In-Reply-To: <551F743E.6060106@wisemo.com> References: <551F4758.3090009@AI.SRI.COM> <551F743E.6060106@wisemo.com> Message-ID: <551F7666.6020304@wisemo.com> On 04/04/2015 07:18, Jakob Bohm wrote: > On 04/04/2015 04:07, Mabry Tyson wrote: >> I happened to notice what seems to be an output glitch in the textual >> output of a certificate. >> >> I received a copy of the QuoVadis Root CA 2 certificate as a file. >> When I examined the certificate via >> openssl x509 -text -in /tmp/QV.cer (using OpenSSL 1.0.1 14 Mar >> 2012 as installed in Ubuntu 14.04) >> I noticed an extra first zero byte of the Modulus was shown, as >> compared to the display of that certificate in Firefox. >> >>> Certificate: >>> Data: >>> Version: 3 (0x2) >>> Serial Number: 1289 (0x509) >>> Signature Algorithm: sha1WithRSAEncryption >>> Issuer: C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2 >>> ... >>> Subject Public Key Info: >>> Public Key Algorithm: rsaEncryption >>> Public-Key: (4096 bit) >>> Modulus: >>> 00:9a:18:ca:4b:94:0d:00:2d:af:03:29:8a:f0:0f: >>> ... >>> 09:62:04:92:16:10:d8:9e:27:47:fb:3b:21:e3:f8: >>> eb:1d:5b >> I believe there should be 4096/8 = 512 bytes in that modulus. There >> are 15 bytes shown per line. 512/15 = 34 with a remainder of 2. >> This output shows 513 bytes (34 lines plus a remainder of 3). >> >> > This is a consequence of the ASN.1 DER/BER encoding rules: > All INTEGER fields are signed, so when the most significant > bit of a 2048 bit value is set, then it needs to be encoded > and processed with an extra leading 0 byte. (And ditto for a 4096 bit value of cause) > > OpenSSL displays that leading 0 byte, while NSS (used by > Firefox) apparently hides it. > 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 From jb-openssl at wisemo.com Sat Apr 4 05:30:52 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Sat, 04 Apr 2015 07:30:52 +0200 Subject: [openssl-users] HTTP / HTTPS on same port In-Reply-To: References: <086a897304b147fc9cd07f8d28cbd028@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <551F770C.40002@wisemo.com> On 03/04/2015 22:12, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Salz, Rich >> Sent: Friday, April 03, 2015 15:55 >> To: openssl-users at openssl.org >> Subject: Re: [openssl-users] HTTP / HTTPS on same port >> >> It is a hack. > That's debatable. What's so sacred about separating traffic by port? Valid TLS traffic and valid plaintext HTTP traffic are distinguishable - there aren't any ambiguous cases. > >> Most people do it the other way and look for a G or P as the first letter. > Now *that* is a hack. And wrong, and broken. Looking at the first few bytes to see if they're 1) ASCII uppercase letters and 2) form the prefix of a valid HTTP command would be satisfactory. > Actually, I would code any HTTP request parser to accept lower case,even if I would code request generators to issue the standard request keywordsin uppercase only (as required by the spec). Basic Postel principle in action, really. Additionally the HTTP/1.1 spec (RFC2616) explicitly allows future method namesto contain any US-ASCII char except control chars (0x00..0x1F), space (0x20) and the following separators: "()<>@,;:\\\"/[]?={}", see RFC2616 section 5.1.1 which references the definitions of token and CHAR in section 2.2. In the updated HTTP/1.1 spec (RFC7230 et.seq.), the equivalent rules are in RFC7230 section 3.1.1 with token and tchar defined in section 3.2.6 . Another possibility for HTTP and HTTPS on the same port is to implement RFC2817, which specifies a way to use a HTTP request to switch a connection to HTTPS. 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 From kurt at roeckx.be Sat Apr 4 14:08:11 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 4 Apr 2015 16:08:11 +0200 Subject: [openssl-users] [openssl-dev] removing compression? In-Reply-To: References: Message-ID: <20150404140811.GA611@roeckx.be> On Fri, Apr 03, 2015 at 07:53:59PM +0000, Salz, Rich wrote: > > And the best practice these days is to do it at the application > layer, and feed the compressed bytes down to TLS. The BREACH attack makes use of that. Kurt From openssl-users at dukhovni.org Sat Apr 4 15:15:06 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 4 Apr 2015 15:15:06 +0000 Subject: [openssl-users] [openssl-dev] removing compression? In-Reply-To: References: Message-ID: <20150404151505.GM17637@mournblade.imrryr.org> On Fri, Apr 03, 2015 at 07:53:59PM +0000, Salz, Rich wrote: > I am thinking about removing compression and would like to know > what the community thinks. At the very least drop "zlib-dynamic" support. This has caused "DLL-hell" on some platforms, when a dynamically loaded libz conflicts with a different statically compiled libz in another library. For example, some "ports" versions of FreeBSD Postfix with OpenSSL and MySQL crash in SSL_accept when compression is negotiated (because MySQL includes an internal libz in those builds). My own builds of OpenSSL have always (over a decade now) been "no-zlib". -- Viktor. From tanner at gmx.net Sat Apr 4 16:04:07 2015 From: tanner at gmx.net (Thomas Tanner) Date: Sat, 04 Apr 2015 18:04:07 +0200 Subject: [openssl-users] removing compression? In-Reply-To: References: Message-ID: <55200B77.5060204@gmx.net> On 03.04.15 21:53, Salz, Rich wrote: > But on a larger scale, does anyone use TLS compression? It has > certainly caused problems with HTTP (see > http://en.wikipedia.org/wiki/CRIME). And the best practice these days is > to do it at the application layer, and feed the compressed bytes down to > TLS. How about at least implementing the length hiding mitigation suggested by the BREACH paper http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf by randomly interspersing flush commands into the data stream (description and example implementation https://github.com/wnyc/breach_buster)? It's not perfect but for some use cases better than having no compression at all. From openssl-users at dukhovni.org Sat Apr 4 16:23:33 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 4 Apr 2015 16:23:33 +0000 Subject: [openssl-users] Fwd to openssl-users Re: [openssl-dev] Why the issuer cannot be found? In-Reply-To: <551F5B19.9020701@wisemo.com> References: <551E55D6.3000403@opentrust.com> <551F5B19.9020701@wisemo.com> Message-ID: <20150404162332.GQ17637@mournblade.imrryr.org> On Sat, Apr 04, 2015 at 05:31:37AM +0200, Jakob Bohm wrote: > (top posting like the rest of the thread) > > What makes you think it is incorrect to check the Key > Identifier (where present) before checking a signature > against a key? > > What other reasonable purpose could the Key Identifier > fields serve? Indeed I have code that relies on OpenSSL taking the SKI and AKI into account. -- Viktor. From noloader at gmail.com Sat Apr 4 19:39:13 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sat, 4 Apr 2015 15:39:13 -0400 Subject: [openssl-users] removing compression? In-Reply-To: References: Message-ID: On Fri, Apr 3, 2015 at 3:53 PM, Salz, Rich wrote: > I am thinking about removing compression and would like to know what the > community thinks. > What the community thinks does not matter. If your threat model includes recovery via compression through protocols like TLS, HTTPS and SPDY, then you have to disable it. Or if you have a "defensive" security posture, then you should disable it. You can disable it in TLS by configuring OpenSSL with no-comp: ./configure no-ssl2 no-ssl3 no-com --prefix=/usr/local For what its worth, I've been disabling compression since the attacks surfaced. I've never had a problem. Jeff From noloader at gmail.com Sat Apr 4 19:40:43 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sat, 4 Apr 2015 15:40:43 -0400 Subject: [openssl-users] [openssl-dev] removing compression? In-Reply-To: <20150404151505.GM17637@mournblade.imrryr.org> References: <20150404151505.GM17637@mournblade.imrryr.org> Message-ID: On Sat, Apr 4, 2015 at 11:15 AM, Viktor Dukhovni wrote: > On Fri, Apr 03, 2015 at 07:53:59PM +0000, Salz, Rich wrote: > > My own builds of OpenSSL have always (over a decade now) been > "no-zlib". > That's kind of interesting (to me). Did you disable it because you were suspicious of compression leaking information? Or did you disable it because of dll hell issues? From michael at metaparadigm.com Sat Apr 4 19:46:56 2015 From: michael at metaparadigm.com (Michael Clark) Date: Sun, 05 Apr 2015 03:46:56 +0800 Subject: [openssl-users] Crash in SSL_do_handshake: s->method->ssl_renegotiate_check(s) Message-ID: <55203FB0.3030600@metaparadigm.com> Hi, I am trying to write the simplest possible example of an async TLS client and server using non-blocking IO and SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE events. The main purpose is to test the async IO code paths with a). an absence of all of the complex options in s_client and s_server, and b). self-contained source that is easy to read. I am having an issue where the server crashes on subsequent connections *if* I close the connection file descriptor. See the note in openssl_async_echo_server.cc on line 239. If I leak a file descriptor and the next connection uses a new fd then the server works fine. Does openssl have an internal map of file descriptors? Am I freeing the connection correctly? SSL_free(ssl_conn.ssl); // TODO - crashes on subsequent connections in SSL_do_handshake if we close the fd. // ssl_lib.c::SSL_do_handshake::s->method->ssl_renegotiate_check(s); // Why? reuse of same fd number for subsequent connection? // comment the following line and the server works but leaks fds close(ssl_conn.conn_fd); Here is the code: https://github.com/michaeljclark/async_tls_test/blob/master/src/openssl_async_echo_server.cc https://github.com/michaeljclark/async_tls_test/blob/master/src/openssl_async_echo_client.cc Both files are standalone with no dependencies (one of the goals) and can be compiled as so: clang++ -std=c++11 openssl_async_echo_client.cc -lcrypto -lssl -o openssl_async_echo_client clang++ -std=c++11 openssl_async_echo_server.cc -lcrypto -lssl -o openssl_async_echo_server or alternatively they can be built using the Makefile in the git repo which contains all dependencies beside openssl e.g. demo cert.pem, key.pem and cacert.pem: https://github.com/michaeljclark/async_tls_test/ e.g. git clone https://github.com/michaeljclark/async_tls_test.git cd async_tls_test make I would appreciate if anyone could help me out. It may well be a bug in my demo code or it could be a bug in openssl. I've used a smattering of C++1y where it simplifies the code (connection hash table, poll descriptor management) but it is mostly plain C. A simple example of a *working* async openssl client and server would be quite useful... Michael. From noloader at gmail.com Sat Apr 4 20:22:13 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sat, 4 Apr 2015 16:22:13 -0400 Subject: [openssl-users] Fwd to openssl-users Re: [openssl-dev] Why the issuer cannot be found? In-Reply-To: <551F5B19.9020701@wisemo.com> References: <551E55D6.3000403@opentrust.com> <551F5B19.9020701@wisemo.com> Message-ID: > What makes you think it is incorrect to check the Key > Identifier (where present) before checking a signature > against a key? An X.509 certificate does one thing: it binds a public key to an identity. In PKI, a public key alone means nothing because trust is placed in principals or issuers. In end entity certificate, you don't need the Issuer DN and AKI because they are disjoint and uncertified. You need the issuing certificate with a valid signature. But it would be helpful to find the issuer's certificate easily. If the AKI is missing, wrong or a duplicate, then it just means that you lost the ability to find an issuing certificate easily. OpenSSL could be more flexible or friendly in its building strategy. But that could move into the "which directory" problem rather quickly. If Yuting Chen provided a store with the required certificates, then OpenSSL is probably incorrect. Chen's original email does not detail it, so its hard to say at the moment. > What other reasonable purpose could the Key Identifier > fields serve? Its a hint to help find the issuing certificate. Its supposed to be used when an issuer has multiple signing keys. The AKI does not need to be a key identifier. It can also be be the { Issuer DN, Serial Number } pair of the issuer's certificate. Jeff From noloader at gmail.com Sat Apr 4 21:36:19 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sat, 4 Apr 2015 17:36:19 -0400 Subject: [openssl-users] Fwd to openssl-users Re: [openssl-dev] Why the issuer cannot be found? In-Reply-To: References: <551E55D6.3000403@opentrust.com> <551F5B19.9020701@wisemo.com> Message-ID: > OpenSSL could be more flexible or friendly in its building strategy. > But that could move into the "which directory" problem rather quickly. > This is kind of interesting. Looking at RFC 5280, section 4.2.1.1 Authority Key Identifier (p. 26): The value of the keyIdentifier field SHOULD be derived from the public key used to verify the certificate's signature or a method that generates unique values. So there's no requirement that the digest of the signer's public key be used in the subject's AKI. It looks like it could be a totally random value. The only requirement is that its unique. Now this is odd or at least counter-intuitive: the standard does not require that Authority Key Identifier in the subject certificate actually match the Subject Key Identifier in the signer. Its not stated and labeled MUST; in fact, it does not appear to be stated. I'm looking at sections 4.2.1.1 Authority Key Identifier and 4.2.1.2 Subject Key Identifier (maybe its stated elsewhere). If I am reading things correctly: I think that means OpenSSL is incorrect if its rejecting a valid path that could be constructed. I have to be careful how I say this since it depends on OpenSSL having the required certificates to construct the path (among other things). But a mismatched AKI is *not* a reason to reject. Jeff From michael at metaparadigm.com Sat Apr 4 22:12:35 2015 From: michael at metaparadigm.com (Michael Clark) Date: Sun, 05 Apr 2015 06:12:35 +0800 Subject: [openssl-users] Crash in SSL_do_handshake: s->method->ssl_renegotiate_check(s) In-Reply-To: <55203FB0.3030600@metaparadigm.com> References: <55203FB0.3030600@metaparadigm.com> Message-ID: <552061D3.30602@metaparadigm.com> On 5/4/15 3:46 am, Michael Clark wrote: > SSL_free(ssl_conn.ssl); > // TODO - crashes on subsequent connections in SSL_do_handshake if we > close the fd. > // > ssl_lib.c::SSL_do_handshake::s->method->ssl_renegotiate_check(s); > // Why? reuse of same fd number for subsequent connection? > // comment the following line and the server works but leaks fds > close(ssl_conn.conn_fd); This is what is happening: http://i.imgur.com/6R6sg4L.png For some reason s->s3 is NULL and ssl3_renegotiate_check is called. The code (*1) is using TLSv1_server_method() ~mc [1] https://github.com/michaeljclark/async_tls_test -------------- next part -------------- An HTML attachment was scrubbed... URL: From chenyt at cs.sjtu.edu.cn Sat Apr 4 22:31:10 2015 From: chenyt at cs.sjtu.edu.cn (Yuting Chen) Date: Sat, 4 Apr 2015 15:31:10 -0700 Subject: [openssl-users] Fwd to openssl-users Re: [openssl-dev] Why the issuer cannot be found? In-Reply-To: References: <551E55D6.3000403@opentrust.com> <551F5B19.9020701@wisemo.com> Message-ID: In fact I did not use any store (thus openssl should be correct). I just tested the logic (openssl verify -CAfile $ca_file $file) and found that it is a little tricky to find the issuer of a certificate (e.g., name/sn-based, key id based), and the behavior is unpredictable. Sometimes a certificate may have two or more authority key ids (it should be incorrect, but I just produced some certificates to test the logic, and found that the issuer can be found or not found.) Sounds like that the issuer cannot be found because the authority key id of file3.pem does not match with the subject key id of file4.pem. Meanwhile the building strategy is flexible. I also made some certificates contains two or more instances of authority key ids, and the issuer can be found (or sometimes cannot be found). On Sat, Apr 4, 2015 at 2:35 PM, Yuting Chen wrote: > In fact I did not use any store (thus openssl should be correct). I just > tested the logic (openssl verify -CAfile $ca_file $file) and found that it > is a little tricky to find the issuer of a certificate (e.g., > name/sn-based, key id based), and the behavior is unpredictable. Sometimes > a certificate may have two or more authority key ids (it should be > incorrect, but I just produced some certificates to test the logic, and > found that the issuer can be found or not found.) > > Sounds like that the issuer cannot be found because the authority key id > of file3.pem does not match with the subject key id of file4.pem. Meanwhile > the building strategy is flexible. I also made some certificates contains > two or more instances of authority key ids, and the issuer can be found (or > sometimes cannot be found). > > On Sat, Apr 4, 2015 at 1:22 PM, Jeffrey Walton wrote: > >> > What makes you think it is incorrect to check the Key >> > Identifier (where present) before checking a signature >> > against a key? >> >> An X.509 certificate does one thing: it binds a public key to an >> identity. In PKI, a public key alone means nothing because trust is >> placed in principals or issuers. >> >> In end entity certificate, you don't need the Issuer DN and AKI >> because they are disjoint and uncertified. You need the issuing >> certificate with a valid signature. But it would be helpful to find >> the issuer's certificate easily. >> >> If the AKI is missing, wrong or a duplicate, then it just means that >> you lost the ability to find an issuing certificate easily. >> >> OpenSSL could be more flexible or friendly in its building strategy. >> But that could move into the "which directory" problem rather quickly. >> >> If Yuting Chen provided a store with the required certificates, then >> OpenSSL is probably incorrect. Chen's original email does not detail >> it, so its hard to say at the moment. >> >> > What other reasonable purpose could the Key Identifier >> > fields serve? >> >> Its a hint to help find the issuing certificate. Its supposed to be >> used when an issuer has multiple signing keys. >> >> The AKI does not need to be a key identifier. It can also be be the { >> Issuer DN, Serial Number } pair of the issuer's certificate. >> >> Jeff >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From minfrin at sharp.fm Sat Apr 4 23:32:02 2015 From: minfrin at sharp.fm (Graham Leggett) Date: Sun, 5 Apr 2015 01:32:02 +0200 Subject: [openssl-users] Crash in SSL_do_handshake: s->method->ssl_renegotiate_check(s) In-Reply-To: <55203FB0.3030600@metaparadigm.com> References: <55203FB0.3030600@metaparadigm.com> Message-ID: <75CCD74D-2D6F-494C-A993-8E9EF88545E8@sharp.fm> On 04 Apr 2015, at 9:46 PM, Michael Clark wrote: > I am having an issue where the server crashes on subsequent connections > *if* I close the connection file descriptor. See the note in > openssl_async_echo_server.cc on line 239. If I leak a file descriptor > and the next connection uses a new fd then the server works fine. Does > openssl have an internal map of file descriptors? Am I freeing the > connection correctly? In the past when I have built async SSL code, I?ve used memory pools from the Apache Portable runtime (APR) to make sure that all the created resources get properly cleaned up when connections are closed. You need to make sure everything you create is properly released when done. If you don?t, you either leak or crash. Regards, Graham ? From michael at metaparadigm.com Sat Apr 4 23:35:32 2015 From: michael at metaparadigm.com (Michael Clark) Date: Sun, 05 Apr 2015 07:35:32 +0800 Subject: [openssl-users] Crash in SSL_do_handshake: s->method->ssl_renegotiate_check(s) In-Reply-To: <75CCD74D-2D6F-494C-A993-8E9EF88545E8@sharp.fm> References: <55203FB0.3030600@metaparadigm.com> <75CCD74D-2D6F-494C-A993-8E9EF88545E8@sharp.fm> Message-ID: <55207544.8020702@metaparadigm.com> On 5/4/15 7:32 am, Graham Leggett wrote: > On 04 Apr 2015, at 9:46 PM, Michael Clark wrote: > >> I am having an issue where the server crashes on subsequent connections >> *if* I close the connection file descriptor. See the note in >> openssl_async_echo_server.cc on line 239. If I leak a file descriptor >> and the next connection uses a new fd then the server works fine. Does >> openssl have an internal map of file descriptors? Am I freeing the >> connection correctly? > In the past when I have built async SSL code, I?ve used memory pools from the Apache Portable runtime (APR) to make sure that all the created resources get properly cleaned up when connections are closed. > > You need to make sure everything you create is properly released when done. If you don?t, you either leak or crash. > Yes however this is a case where I am closing the fd, and calling SSL_free on the ssl object. i.e. cleaning up, then I get the crash. When I leak the fd, it works fine. Note this is on OS X. Just discovered I am not getting POLLHUP on Linux, rather POLLIN and read returning 0. Still debugging... ~mc From rsalz at akamai.com Sat Apr 4 23:57:20 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 4 Apr 2015 23:57:20 +0000 Subject: [openssl-users] Modulus field in text display of a certificate In-Reply-To: <551F4758.3090009@AI.SRI.COM> References: <551F4758.3090009@AI.SRI.COM> Message-ID: <16d5c7d4dc59408e9969894175ecd06f@ustx2ex-dag1mb2.msg.corp.akamai.com> > > Modulus: > > 00:9a:18:ca:4b:94:0d:00:2d:af:03:29:8a:f0:0f: The leading zero is so that you don't confuse it with a sign bit. From rsalz at akamai.com Sun Apr 5 00:06:03 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 5 Apr 2015 00:06:03 +0000 Subject: [openssl-users] removing compression? In-Reply-To: <55200B77.5060204@gmx.net> References: <55200B77.5060204@gmx.net> Message-ID: <8a72356eae914fa6bc7c512ea1337b34@ustx2ex-dag1mb2.msg.corp.akamai.com> > by randomly interspersing flush commands into the data stream (description > and example implementation https://github.com/wnyc/breach_buster)? > It's not perfect but for some use cases better than having no compression at > all. Flushing the stream seems like an application-level thing to do, and not something openssl generally does. It might be better than having no compression at all, the question is do we need compression in openssl at all? :) From michael at metaparadigm.com Sun Apr 5 03:03:42 2015 From: michael at metaparadigm.com (Michael Clark) Date: Sun, 05 Apr 2015 11:03:42 +0800 Subject: [openssl-users] Crash in SSL_do_handshake: s->method->ssl_renegotiate_check(s) In-Reply-To: <55207544.8020702@metaparadigm.com> References: <55203FB0.3030600@metaparadigm.com> <75CCD74D-2D6F-494C-A993-8E9EF88545E8@sharp.fm> <55207544.8020702@metaparadigm.com> Message-ID: <5520A60E.1050002@metaparadigm.com> On 5/4/15 7:35 am, Michael Clark wrote: > On 5/4/15 7:32 am, Graham Leggett wrote: >> On 04 Apr 2015, at 9:46 PM, Michael Clark wrote: >> >>> I am having an issue where the server crashes on subsequent connections >>> *if* I close the connection file descriptor. See the note in >>> openssl_async_echo_server.cc on line 239. If I leak a file descriptor >>> and the next connection uses a new fd then the server works fine. Does >>> openssl have an internal map of file descriptors? Am I freeing the >>> connection correctly? >> In the past when I have built async SSL code, I?ve used memory pools from the Apache Portable runtime (APR) to make sure that all the created resources get properly cleaned up when connections are closed. >> >> You need to make sure everything you create is properly released when done. If you don?t, you either leak or crash. >> > Yes however this is a case where I am closing the fd, and calling > SSL_free on the ssl object. i.e. cleaning up, then I get the crash. When > I leak the fd, it works fine. > > Note this is on OS X. Just discovered I am not getting POLLHUP on Linux, > rather POLLIN and read returning 0. > > Still debugging... Apologies all. It wasn't a TLS bug rather I had neglected to remove a connection from an fd->connection map. Now works on Darwin/OSX: https://github.com/michaeljclark/async_tls_test Just working through poll peculiarities on Linux. Thanks. From noloader at gmail.com Sun Apr 5 03:11:26 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sat, 4 Apr 2015 23:11:26 -0400 Subject: [openssl-users] Crash in SSL_do_handshake: s->method->ssl_renegotiate_check(s) In-Reply-To: <5520A60E.1050002@metaparadigm.com> References: <55203FB0.3030600@metaparadigm.com> <75CCD74D-2D6F-494C-A993-8E9EF88545E8@sharp.fm> <55207544.8020702@metaparadigm.com> <5520A60E.1050002@metaparadigm.com> Message-ID: On Sat, Apr 4, 2015 at 11:03 PM, Michael Clark wrote: > ... > Now works on Darwin/OSX: https://github.com/michaeljclark/async_tls_test > > Just working through poll peculiarities on Linux. Thanks. Related: libevent (http://libevent.org/) does a pretty good job of abstracting that away. I believe it works on Linux, BSDs, OS X and Windows. But you'll have to switch to a fully asynchronous architecture. Jeff From michael at metaparadigm.com Sun Apr 5 04:31:52 2015 From: michael at metaparadigm.com (Michael Clark) Date: Sun, 05 Apr 2015 12:31:52 +0800 Subject: [openssl-users] Crash in SSL_do_handshake: s->method->ssl_renegotiate_check(s) In-Reply-To: References: <55203FB0.3030600@metaparadigm.com> <75CCD74D-2D6F-494C-A993-8E9EF88545E8@sharp.fm> <55207544.8020702@metaparadigm.com> <5520A60E.1050002@metaparadigm.com> Message-ID: <5520BAB8.1070908@metaparadigm.com> On 5/4/15 11:11 am, Jeffrey Walton wrote: > On Sat, Apr 4, 2015 at 11:03 PM, Michael Clark wrote: >> ... >> Now works on Darwin/OSX: https://github.com/michaeljclark/async_tls_test >> >> Just working through poll peculiarities on Linux. Thanks. > Related: libevent (http://libevent.org/) does a pretty good job of > abstracting that away. I believe it works on Linux, BSDs, OS X and > Windows. But you'll have to switch to a fully asynchronous > architecture. Thanks. Yes there is ASIO too: https://think-async.com/Asio/AsioStandalone http://stackoverflow.com/questions/18506739/boostasio-http-server-extremely-slow I've looked at libevent. There is also libev and libuv. I think they may use the BIO method for async operation, which doesn't share fds with openssl; only memory buffers. The BIO approach may require additional buffer copies. Extra buffer copies may be negligible compared to the encryption overhead, however AES-NI is very fast in terms of cycles per byte. With connection establishment excluded (a large chunk of the TLS overhead) and the case of 16 parallel keepalive connections pumping objects to/from the server (to/from RAM or SSD); the overhead might be appreciable. I am able to get about 18GB/sec AES encryption with AES-NI on a 6-core/12-thread machine with openssl AES-NI. That is a substantial proportion of the memory bandwidth of the machine which is approximately ~60GB/sec. I guess buffer copies will happen in L2/L3 cache where the bandwidth is higher, so perhaps this is less of an issue. In any case I was thinking of using the SSL_ERROR_WANT_READ / SSL_ERROR_WANT_WRITE approach vs the BIO approach. Exploring this at the moment... I'm a beggar for punishment and I like to be aware of the quirks at the foundations and have written my own event abstraction layer that uses poll, kqueue and epoll. It doesn't handle TLS *yet*. I wanted to implement a simple poll-based echo server to get the hang of the OpenSSL API. https://github.com/metaparadigm/latypus https://github.com/metaparadigm/latypus/blob/master/src/pollset.h With plain HTTP latypus can do ~255,000 reqs/sec (16 threads) vs nginx ~140,000 req/sec (16 processes), logging enabled, on a 16 core AWS r3.4xlarge instance. This is mainly due to a more efficient logging implementation (in memory async ring buffer). latypus is slower than nginx with logging disabled but it does not have an open file cache. I would also like to instrument the server to log TLS options, ciphers and versions. Something most current generation servers do not do. For this I need to be comfortable with the OpenSSL API. Hence the simple async echo server. Also want to use C++1y vs C, and use existing language infrastructure where possible e.g. std::set, std::map, std::vector, etc Many of the current C engines reinvent their own hash tables, lists and buffers. i.e. there are as many hash table implementations as there are servers. ~mc -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at levitte.org Sun Apr 5 05:11:38 2015 From: richard at levitte.org (Richard Levitte) Date: Sun, 05 Apr 2015 07:11:38 +0200 (CEST) Subject: [openssl-users] A question to the VMS folks out there (SSL_TASK) Message-ID: <20150405.071138.34178156689300513.richard@levitte.org> Hi, this is a question to the VMS folks out there. A few days ago, I took SSL_TASK out of the OpenSSL master branch (that is, the files crypto/bio/bss_rtcp.c and ssl/ssl_task.c). It never really belonged in OpenSSL but stayed there for reasons only historians can tell at this point. I'm currently having a hg repo with the files as part of the vms-ports effort (https://sourceforge.net/p/vms-ports/ssl_task/), but I'm starting to wonder if anyone is still using this stuff or if it's just dead code by now. The answer will make all the difference to my willingness to keep this code alive or not. Cheers, Richard -- Richard Levitte richard at levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish From chenyt at cs.sjtu.edu.cn Sun Apr 5 20:55:50 2015 From: chenyt at cs.sjtu.edu.cn (Yuting Chen) Date: Sun, 5 Apr 2015 13:55:50 -0700 Subject: [openssl-users] openssl is flexible when verifying Message-ID: Hi, when I verify an X509 cert against a ca certificate, I found that the cert can pass validation even if it has two instances of X509v3 Basic Constraints, X509v3 Subject Key ids, and authority key ids. Seems that some issues are not important in verification. (I guess one reason is that one subject key id is the same as the authority key id, and thus openssl may regard it as a self-signed certificate? ) Should this be forbidden? command: openssl verify -x509_strict -verbose -CAfile myroot.pem mycert.pem -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: myroot.pem Type: application/x-x509-ca-cert Size: 1815 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: myfile.pem Type: application/x-x509-ca-cert Size: 2612 bytes Desc: not available URL: From david.rufino at gmail.com Sun Apr 5 21:04:46 2015 From: david.rufino at gmail.com (David Rufino) Date: Sun, 5 Apr 2015 22:04:46 +0100 Subject: [openssl-users] ecc negotiation Message-ID: Hello, It's possible I'm doing something wrong here, but I can't seem to negotiate ecdhe with an elliptic curve other than P-256. To reproduce the issue, using openssl 1.0.2 openssl s_server -key server.key -cert server.crt -msg -debug -dhparam dhparam.pem -cipher ECDHE-RSA-AES128-SHA -tls1_2 gnutls-cli 127.0.0.1 -p 4433 -d 4 --insecure --priority="NORMAL:-KX-ALL:+ ECDHE-RSA:-CURVE-ALL:+CURVE-SECP224R1" which gives the error :SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1366: changing to p256r1 succeeds. is there a particular why the negotation would fail with p224 ? my understanding is that openssl supports all the nist curves. Regards, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From chenyt at cs.sjtu.edu.cn Sun Apr 5 21:26:18 2015 From: chenyt at cs.sjtu.edu.cn (Yuting Chen) Date: Sun, 5 Apr 2015 14:26:18 -0700 Subject: [openssl-users] openssl is flexible when verifying In-Reply-To: References: Message-ID: I checked some other certificates, and found that some non self-signed certificates having duplicate extension instances can be verified by openssl. I guess openssl is quite gentle when validating these malformed certificates. On Sun, Apr 5, 2015 at 1:55 PM, Yuting Chen wrote: > Hi, when I verify an X509 cert against a ca certificate, I found that the > cert can pass validation even if it has two instances of X509v3 Basic > Constraints, X509v3 Subject Key ids, and authority key ids. Seems that some > issues are not important in verification. (I guess one reason is that one > subject key id is the same as the authority key id, and thus openssl may > regard it as a self-signed certificate? ) Should this be forbidden? > command: openssl verify -x509_strict -verbose -CAfile myroot.pem > mycert.pem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Sun Apr 5 22:42:06 2015 From: matt at openssl.org (Matt Caswell) Date: Sun, 05 Apr 2015 23:42:06 +0100 Subject: [openssl-users] ecc negotiation In-Reply-To: References: Message-ID: <5521BA3E.6010004@openssl.org> On 05/04/15 22:04, David Rufino wrote: > Hello, > > It's possible I'm doing something wrong here, but I can't seem to > negotiate ecdhe with an elliptic curve other than P-256. To reproduce > the issue, using openssl 1.0.2 > > openssl s_server -key server.key -cert server.crt -msg -debug -dhparam > dhparam.pem -cipher ECDHE-RSA-AES128-SHA -tls1_2 > > gnutls-cli 127.0.0.1 -p 4433 -d 4 --insecure > --priority="NORMAL:-KX-ALL:+ECDHE-RSA:-CURVE-ALL:+CURVE-SECP224R1" > > which gives the error > > :SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1366: > > changing to p256r1 succeeds. is there a particular why the negotation > would fail with p224 ? my understanding is that openssl supports all the > nist curves. Try adding "-named_curve secp224r1" to your s_server arguments. This specifies the curve to use for ECDHE keys. The default if you don't specify a named curve is P-256 which is why it works when you are using that curve. Matt From matt at openssl.org Sun Apr 5 22:46:00 2015 From: matt at openssl.org (Matt Caswell) Date: Sun, 05 Apr 2015 23:46:00 +0100 Subject: [openssl-users] ecc negotiation In-Reply-To: <5521BA3E.6010004@openssl.org> References: <5521BA3E.6010004@openssl.org> Message-ID: <5521BB28.5030608@openssl.org> On 05/04/15 23:42, Matt Caswell wrote: > > > On 05/04/15 22:04, David Rufino wrote: >> Hello, >> >> It's possible I'm doing something wrong here, but I can't seem to >> negotiate ecdhe with an elliptic curve other than P-256. To reproduce >> the issue, using openssl 1.0.2 >> >> openssl s_server -key server.key -cert server.crt -msg -debug -dhparam >> dhparam.pem -cipher ECDHE-RSA-AES128-SHA -tls1_2 >> >> gnutls-cli 127.0.0.1 -p 4433 -d 4 --insecure >> --priority="NORMAL:-KX-ALL:+ECDHE-RSA:-CURVE-ALL:+CURVE-SECP224R1" >> >> which gives the error >> >> :SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1366: >> >> changing to p256r1 succeeds. is there a particular why the negotation >> would fail with p224 ? my understanding is that openssl supports all the >> nist curves. > > > Try adding "-named_curve secp224r1" to your s_server arguments. This > specifies the curve to use for ECDHE keys. The default if you don't > specify a named curve is P-256 which is why it works when you are using > that curve. BTW, you can also use "-named_curve auto", which will just pick an appropriate curve. Matt From noloader at gmail.com Sun Apr 5 23:15:13 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 5 Apr 2015 19:15:13 -0400 Subject: [openssl-users] openssl is flexible when verifying In-Reply-To: References: Message-ID: On Sun, Apr 5, 2015 at 5:26 PM, Yuting Chen wrote: > I checked some other certificates, and found that some non self-signed > certificates having duplicate extension instances can be verified by > openssl. I guess openssl is quite gentle when validating these malformed > certificates. Well, I don't think its OpenSSL per se in this instance. The underlying problem is the malleability in the standard. In this case, its RFC 5280 and: "Applications are not required to verify that key identifiers match when performing certification path validation." - http://tools.ietf.org/html/rfc5280#section-4.2.1.2 In this case, there could be 1, 2, or 10 of them. And its not required that OpenSSL actually use any of them in path validation. (Rejecting a valid path due to an incorrect AKI is a different story). From wangqun at alumni.nus.edu.sg Mon Apr 6 01:13:21 2015 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Sun, 5 Apr 2015 18:13:21 -0700 (MST) Subject: [openssl-users] Is there any plan for FIPS to be supported on Linux-aarch64? Message-ID: <1428282801225-57389.post@n7.nabble.com> Hello, We are porting our products to Linux-aarch64. Our products are using OpenSSL with FIPS. I know that OpenSSL 1.0.2 started to support Linux-aarch64, but our products need OpenSSL FIPS as well. My question is when OpenSSL FIPS will be supported on Linux-aarch64? Thanks in advance, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/Is-there-any-plan-for-FIPS-to-be-supported-on-Linux-aarch64-tp57389.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From chenyt at cs.sjtu.edu.cn Mon Apr 6 02:47:20 2015 From: chenyt at cs.sjtu.edu.cn (Yuting Chen) Date: Sun, 5 Apr 2015 19:47:20 -0700 Subject: [openssl-users] openssl is flexible when verifying In-Reply-To: References: Message-ID: Read a little code of openssl, and found that in the function X509_check_issued(X509 *issuer, X509 *subject), The statement x509v3_cache_extensions(subject); is called for four times, but one certificate did not get the subject keyid (as the block of if(subject->akid) is called for three times). Seems that if the certificate has two key ids, the verification is performed just on the basis of their names (supposing that subject->akid==NULL). Not so sure about the correctness of my reasoning. It could be better if we can discard these certificates, as they will disturb the verification. On Sun, Apr 5, 2015 at 2:26 PM, Yuting Chen wrote: > I checked some other certificates, and found that some non self-signed > certificates having duplicate extension instances can be verified by > openssl. I guess openssl is quite gentle when validating these malformed > certificates. > > On Sun, Apr 5, 2015 at 1:55 PM, Yuting Chen wrote: > >> Hi, when I verify an X509 cert against a ca certificate, I found that the >> cert can pass validation even if it has two instances of X509v3 Basic >> Constraints, X509v3 Subject Key ids, and authority key ids. Seems that some >> issues are not important in verification. (I guess one reason is that one >> subject key id is the same as the authority key id, and thus openssl may >> regard it as a self-signed certificate? ) Should this be forbidden? >> command: openssl verify -x509_strict -verbose -CAfile myroot.pem >> mycert.pem >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chenyt at cs.sjtu.edu.cn Mon Apr 6 05:01:55 2015 From: chenyt at cs.sjtu.edu.cn (Yuting Chen) Date: Sun, 5 Apr 2015 22:01:55 -0700 Subject: [openssl-users] openssl is flexible when verifying In-Reply-To: References: Message-ID: I completely agree with Jeffrey's comments, "Applications are not required to verify that key identifiers match when performing certification path validation." (RFC5280) But when the certificate has two authority key ids, openssl may take it as a certificate having no authority key ids (I think the certificate is partially parsed and verified). >From the source code of openssl, it does match the ids, if available (in v3_purp.c). if(X509_NAME_cmp(X509_get_subject_name(issuer), X509_get_issuer_name(subject))) return X509_V_ERR_SUBJECT_ISSUER_MISMATCH; x509v3_cache_extensions(issuer); x509v3_cache_extensions(subject); if(subject->akid) { int ret = X509_check_akid(issuer, subject->akid); if (ret != X509_V_OK) return ret; } On Sun, Apr 5, 2015 at 7:47 PM, Yuting Chen wrote: > Read a little code of openssl, and found that in > the function > X509_check_issued(X509 *issuer, X509 *subject), > > The statement > x509v3_cache_extensions(subject); > is called for four times, but one certificate did not > get the subject keyid (as the block of if(subject->akid) is > called for three times). Seems that if the certificate > has two key ids, the verification is performed just on > the basis of their names (supposing that > subject->akid==NULL). > > Not so sure about the correctness of my > reasoning. It could be better if we can discard > these certificates, as they will disturb the > verification. > > > On Sun, Apr 5, 2015 at 2:26 PM, Yuting Chen wrote: > >> I checked some other certificates, and found that some non self-signed >> certificates having duplicate extension instances can be verified by >> openssl. I guess openssl is quite gentle when validating these malformed >> certificates. >> >> On Sun, Apr 5, 2015 at 1:55 PM, Yuting Chen >> wrote: >> >>> Hi, when I verify an X509 cert against a ca certificate, I found that >>> the cert can pass validation even if it has two instances of X509v3 Basic >>> Constraints, X509v3 Subject Key ids, and authority key ids. Seems that some >>> issues are not important in verification. (I guess one reason is that one >>> subject key id is the same as the authority key id, and thus openssl may >>> regard it as a self-signed certificate? ) Should this be forbidden? >>> command: openssl verify -x509_strict -verbose -CAfile myroot.pem >>> mycert.pem >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbellino at mrv.com Mon Apr 6 12:03:21 2015 From: pbellino at mrv.com (Philip Bellino) Date: Mon, 6 Apr 2015 12:03:21 +0000 Subject: [openssl-users] FIPS wrapper to lock low level AES calls in FIPS mode Message-ID: Hello, We are using Openssl-1.0.2a with FIPS 2.0.9 on Linux PPC environment. We have code that we assume needs updating, to avoid using low level routines in FIPS. For example, our snmp v3 implementation currently decrypts/encrypts using AES_set_encrypt_key() and AES_cfb128_encrypt(). The old decryption routine is as follows: BOOL /* TRUE:=ok, FALSE=error condition */ sc_aes_decrypt(SN_PRIVPROT privProto, /* usm priv protocol type */ UCHAR * key, /* priv key */ UINT keylen, /* priv key length */ UCHAR * iv, /* iv buffer */ UINT ivlen, /* iv length */ UCHAR * ciphertext, /* encrypted buffer: the cipher text */ UINT ctlen, /* encrypted data length */ UCHAR * plaintext, /* OUT: decrypted buffer */ int *ptlen) { /* IN: decrypt buf len, OUT: decrypt data */ static char fname[] = "sc_aes_decrypt"; AES_KEY aes_key; char my_iv[16]; int new_ivlen = 0; int ret; ret = AES_set_encrypt_key(key, (keylen * 8), &aes_key); if (ret < 0) { errorMsg("%s: call to AES_set_encrypt_key() failed (error=%d)", fname, ret); return FALSE; } memcpy(my_iv, iv, ivlen); /* * Decrypt the data. */ AES_cfb128_encrypt(ciphertext, plaintext, ctlen, &aes_key, my_iv, &new_ivlen, AES_DECRYPT); *ptlen = ctlen; return TRUE; } AES_set_encrypt_key() is no longer useable in FIPS mode as shown in the following code snippet from openssl-1.0.2a/crypto/aes/aes_misc.c - /* FIPS wrapper functions to block low level AES calls in FIPS mode */ int AES_set_encrypt_key(const unsigned char *userKey, const int bits, AES_KEY *key) { #ifdef OPENSSL_FIPS fips_cipher_abort(AES); #endif return private_AES_set_encrypt_key(userKey, bits, key); } I could not find a parallel routine for AES_set_encrypt_key() in the high level EVP routines. I also looked on the Openssl wiki. Do I need one? Does one exist? I am attempting to replace the old code with FIPS safe EVP routines EVP_CIPHER_CTX_init(), EVP_DecryptInit_ex() using EVP_aes_128_cfb, EVP_DecryptUpdate(), EVP_DecryptFinal_ex() and EVP_CIPHER_CTX_cleanup(). The data passed into the decrypt routine is not a fixed length (not necessarily a multiple of block size). Is that the correct path? Are there any gotchas I should watch out for, for example, with padding issues? I am asking because my first attempt at the new code results in a decryption error from Openssl crypto/evp/evp_enc.c EVP_DecryptFinal_ex() line 519 if (b > 1) { if (ctx->buf_len) { EVPerr(EVP_F_EVP_DECRYPTFINAL_EX, EVP_R_WRONG_FINAL_BLOCK_LENGTH); return (0); } Any help/guidance would be most appreciated. Thank you. Phil Bellino Principal Software Engineer | MRV Communications Inc. 300 Apollo Drive | Chelmsford, MA 01824 Phone: 978-674-6870 | Fax: 978-674-6799 www.mrv.com [MRV-email] [E-Banner] The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 6563 bytes Desc: image001.png URL: From david.rufino at gmail.com Mon Apr 6 13:40:16 2015 From: david.rufino at gmail.com (David Rufino) Date: Mon, 6 Apr 2015 14:40:16 +0100 Subject: [openssl-users] ecc negotiation In-Reply-To: <5521BB28.5030608@openssl.org> References: <5521BA3E.6010004@openssl.org> <5521BB28.5030608@openssl.org> Message-ID: Great, that works, thank you. Is this the default behavior when using the C API? Thanks, David On Sunday, April 5, 2015, Matt Caswell wrote: > > > On 05/04/15 23:42, Matt Caswell wrote: > > > > > > On 05/04/15 22:04, David Rufino wrote: > >> Hello, > >> > >> It's possible I'm doing something wrong here, but I can't seem to > >> negotiate ecdhe with an elliptic curve other than P-256. To reproduce > >> the issue, using openssl 1.0.2 > >> > >> openssl s_server -key server.key -cert server.crt -msg -debug -dhparam > >> dhparam.pem -cipher ECDHE-RSA-AES128-SHA -tls1_2 > >> > >> gnutls-cli 127.0.0.1 -p 4433 -d 4 --insecure > >> --priority="NORMAL:-KX-ALL:+ECDHE-RSA:-CURVE-ALL:+CURVE-SECP224R1" > >> > >> which gives the error > >> > >> :SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1366: > >> > >> changing to p256r1 succeeds. is there a particular why the negotation > >> would fail with p224 ? my understanding is that openssl supports all the > >> nist curves. > > > > > > Try adding "-named_curve secp224r1" to your s_server arguments. This > > specifies the curve to use for ECDHE keys. The default if you don't > > specify a named curve is P-256 which is why it works when you are using > > that curve. > > BTW, you can also use "-named_curve auto", which will just pick an > appropriate curve. > > Matt > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Mon Apr 6 13:54:07 2015 From: marquess at openssl.com (Steve Marquess) Date: Mon, 06 Apr 2015 09:54:07 -0400 Subject: [openssl-users] Is there any plan for FIPS to be supported on Linux-aarch64? In-Reply-To: <1428282801225-57389.post@n7.nabble.com> References: <1428282801225-57389.post@n7.nabble.com> Message-ID: <55228FFF.203@openssl.com> On 04/05/2015 09:13 PM, Aaron wrote: > Hello, > > We are porting our products to Linux-aarch64. Our products are using OpenSSL > with FIPS. I know that OpenSSL 1.0.2 started to support Linux-aarch64, but > our products need OpenSSL FIPS as well. > > My question is when OpenSSL FIPS will be supported on Linux-aarch64? When we have a sponsor to cover the non-trivial costs of a "platform" validation. We're working on some iOS and Android ARMv8 platforms, but have nothing planned for Linux on ARMv8. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From nicolae.rosia at gmail.com Mon Apr 6 14:09:45 2015 From: nicolae.rosia at gmail.com (Nicolae Rosia) Date: Mon, 6 Apr 2015 17:09:45 +0300 Subject: [openssl-users] Is there any plan for FIPS to be supported on Linux-aarch64? In-Reply-To: <55228FFF.203@openssl.com> References: <1428282801225-57389.post@n7.nabble.com> <55228FFF.203@openssl.com> Message-ID: Is the documentation for the current validation available? Maybe someone can pick it up and work from there. On Mon, Apr 6, 2015 at 4:54 PM, Steve Marquess wrote: > On 04/05/2015 09:13 PM, Aaron wrote: >> Hello, >> >> We are porting our products to Linux-aarch64. Our products are using OpenSSL >> with FIPS. I know that OpenSSL 1.0.2 started to support Linux-aarch64, but >> our products need OpenSSL FIPS as well. >> >> My question is when OpenSSL FIPS will be supported on Linux-aarch64? > > When we have a sponsor to cover the non-trivial costs of a "platform" > validation. > > We're working on some iOS and Android ARMv8 platforms, but have nothing > planned for Linux on ARMv8. > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation, Inc. > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at opensslfoundation.com > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From marquess at openssl.com Mon Apr 6 14:44:00 2015 From: marquess at openssl.com (Steve Marquess) Date: Mon, 06 Apr 2015 10:44:00 -0400 Subject: [openssl-users] Is there any plan for FIPS to be supported on Linux-aarch64? In-Reply-To: References: <1428282801225-57389.post@n7.nabble.com> <55228FFF.203@openssl.com> Message-ID: <55229BB0.6060306@openssl.com> On 04/06/2015 10:09 AM, Nicolae Rosia wrote: > Is the documentation for the current validation available? Maybe > someone can pick it up and work from there. It doesn't work that way. With FIPS 140-2 the software itself is never the problem, it's everything else. The OpenSSL FIPS Object Module is entirely open source, but having the source code does you no good when what you want is a software product that satisfies the USG procurement requirements for FIPS 140-2 validated cryptography. Remember that the challenge with FIPS 140-2 isn't to have working code (you have that already with stock OpenSSL); it is to have code (in a peculiar form, a "cryptographic module") that has been officially blessed by an arcane and tedious bureaucratic process. That blessing (validation) is something that costs money, for accredited test lab and CMVP fees, not to mention a substantial amount of labor. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From nicolae.rosia at gmail.com Mon Apr 6 14:59:09 2015 From: nicolae.rosia at gmail.com (Nicolae Rosia) Date: Mon, 6 Apr 2015 17:59:09 +0300 Subject: [openssl-users] Is there any plan for FIPS to be supported on Linux-aarch64? In-Reply-To: <55229BB0.6060306@openssl.com> References: <1428282801225-57389.post@n7.nabble.com> <55228FFF.203@openssl.com> <55229BB0.6060306@openssl.com> Message-ID: I see. Still, the documentation sent to the lab would be helpful to the community to better understand/review the existing code. On Mon, Apr 6, 2015 at 5:44 PM, Steve Marquess wrote: > On 04/06/2015 10:09 AM, Nicolae Rosia wrote: >> Is the documentation for the current validation available? Maybe >> someone can pick it up and work from there. > > It doesn't work that way. With FIPS 140-2 the software itself is never > the problem, it's everything else. > > The OpenSSL FIPS Object Module is entirely open source, but having the > source code does you no good when what you want is a software product > that satisfies the USG procurement requirements for FIPS 140-2 validated > cryptography. Remember that the challenge with FIPS 140-2 isn't to have > working code (you have that already with stock OpenSSL); it is to have > code (in a peculiar form, a "cryptographic module") that has been > officially blessed by an arcane and tedious bureaucratic process. > > That blessing (validation) is something that costs money, for accredited > test lab and CMVP fees, not to mention a substantial amount of labor. > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation, Inc. > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at opensslfoundation.com > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From pbellino at mrv.com Mon Apr 6 15:00:30 2015 From: pbellino at mrv.com (Philip Bellino) Date: Mon, 6 Apr 2015 15:00:30 +0000 Subject: [openssl-users] FIPS wrapper to lock low level AES calls in FIPS mode Message-ID: Hello, I would like to retract my previous email on this subject. I found the routine EVP_CIPHER_CTX_set_key_length(), and have successfully implemented. I apologize for wasting anyone's time who may have read the original email. Thanks, Phil From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Philip Bellino Sent: Monday, April 06, 2015 8:03 AM To: openssl-users at openssl.org Subject: [openssl-users] FIPS wrapper to lock low level AES calls in FIPS mode Hello, We are using Openssl-1.0.2a with FIPS 2.0.9 on Linux PPC environment. We have code that we assume needs updating, to avoid using low level routines in FIPS. For example, our snmp v3 implementation currently decrypts/encrypts using AES_set_encrypt_key() and AES_cfb128_encrypt(). The old decryption routine is as follows: BOOL /* TRUE:=ok, FALSE=error condition */ sc_aes_decrypt(SN_PRIVPROT privProto, /* usm priv protocol type */ UCHAR * key, /* priv key */ UINT keylen, /* priv key length */ UCHAR * iv, /* iv buffer */ UINT ivlen, /* iv length */ UCHAR * ciphertext, /* encrypted buffer: the cipher text */ UINT ctlen, /* encrypted data length */ UCHAR * plaintext, /* OUT: decrypted buffer */ int *ptlen) { /* IN: decrypt buf len, OUT: decrypt data */ static char fname[] = "sc_aes_decrypt"; AES_KEY aes_key; char my_iv[16]; int new_ivlen = 0; int ret; ret = AES_set_encrypt_key(key, (keylen * 8), &aes_key); if (ret < 0) { errorMsg("%s: call to AES_set_encrypt_key() failed (error=%d)", fname, ret); return FALSE; } memcpy(my_iv, iv, ivlen); /* * Decrypt the data. */ AES_cfb128_encrypt(ciphertext, plaintext, ctlen, &aes_key, my_iv, &new_ivlen, AES_DECRYPT); *ptlen = ctlen; return TRUE; } AES_set_encrypt_key() is no longer useable in FIPS mode as shown in the following code snippet from openssl-1.0.2a/crypto/aes/aes_misc.c - /* FIPS wrapper functions to block low level AES calls in FIPS mode */ int AES_set_encrypt_key(const unsigned char *userKey, const int bits, AES_KEY *key) { #ifdef OPENSSL_FIPS fips_cipher_abort(AES); #endif return private_AES_set_encrypt_key(userKey, bits, key); } I could not find a parallel routine for AES_set_encrypt_key() in the high level EVP routines. I also looked on the Openssl wiki. Do I need one? Does one exist? I am attempting to replace the old code with FIPS safe EVP routines EVP_CIPHER_CTX_init(), EVP_DecryptInit_ex() using EVP_aes_128_cfb, EVP_DecryptUpdate(), EVP_DecryptFinal_ex() and EVP_CIPHER_CTX_cleanup(). The data passed into the decrypt routine is not a fixed length (not necessarily a multiple of block size). Is that the correct path? Are there any gotchas I should watch out for, for example, with padding issues? I am asking because my first attempt at the new code results in a decryption error from Openssl crypto/evp/evp_enc.c EVP_DecryptFinal_ex() line 519 if (b > 1) { if (ctx->buf_len) { EVPerr(EVP_F_EVP_DECRYPTFINAL_EX, EVP_R_WRONG_FINAL_BLOCK_LENGTH); return (0); } Any help/guidance would be most appreciated. Thank you. Phil Bellino Principal Software Engineer | MRV Communications Inc. 300 Apollo Drive | Chelmsford, MA 01824 Phone: 978-674-6870 | Fax: 978-674-6799 www.mrv.com [MRV-email] [Image removed by sender. E-Banner] The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited. [E-Banner] The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: ~WRD000.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 6563 bytes Desc: image001.png URL: From andreas.magana.ctr at us.af.mil Mon Apr 6 15:43:21 2015 From: andreas.magana.ctr at us.af.mil (MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT) Date: Mon, 6 Apr 2015 15:43:21 +0000 Subject: [openssl-users] updating list of server account password In-Reply-To: <4AC3DD69EE75BE42901DD77C9F5A12E508F5E3B8@GAALPA1MSGUSRAF.ITServices.sbc.com> References: <6ABA33135553E04E978A5ECCC07560D231A071B5@52ZHTX-D07-03C.area52.afnoapps.usaf.mil> <4AC3DD69EE75BE42901DD77C9F5A12E508F5E3B8@GAALPA1MSGUSRAF.ITServices.sbc.com> Message-ID: <6ABA33135553E04E978A5ECCC07560D231A075DF@52ZHTX-D07-03C.area52.afnoapps.usaf.mil> Thank you Don and Matt and Mike, Your help got me here and I learned so much and there is much more to learn but I enjoy it. My script has a list of four Solaris 10 servers. Launching the perl expect.pm script from a Red Hat server it went to each box and changed my password with no problems. Thank you again. Here is the example script I used. #!/usr/bin/perl use strict; use Expect; my $timeout = 60; my @servers = qw( Solaris-host03 Solaris-host04 Solaris-host05 Solaris-host06 ); for my $server (@servers) { # do your thing with $server change_password($server); } sub change_password { my $system = shift; my $filename = "/var/tmp/expect_script.log"; my $ssh = Expect->new('ssh amagana@' . $system); #my $ssh = Expect->new('ssh amagana at tstorweb01'); $ssh->debug(1); $ssh->expect ( $timeout, [ qr/Password:/], [ qr/Are you sure you want to continue connecting \(yes\/no\)?/] ); if ($ssh->match() =~ m/Are you sure you want to continue connecting \(yes\/no\)?/ ) { $ssh->send("yes\r"); } elsif ($ssh->match() =~ m/Password:/ ) { $ssh->send("mycurrentpassword\n"); } $filename = "/var/tmp/expect_script_". $system ".log"; $ssh->expect(60, '$'); $ssh->send("su - root\n"); $ssh->expect(60, 'Password:'); $ssh->send("rootpassword\n"); $ssh->expect(60, '#'); $ssh->send("passwd amagana\n"); $ssh->expect(60, 'New Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, 'Re-enter new Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, '#'); $ssh->close(); } //SIGNED// Andy Maga?a UNIX Systems Administrator Diligent Contractor, 72nd Air Base Wing Tinker Air Force Base, Oklahoma Commercial: (405) 734-0341 -----Original Message----- From: ESRY JR., DON [mailto:de3253 at att.com] Sent: Friday, April 03, 2015 3:19 PM To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT; openssl-users at openssl.org Cc: Matt Zagrabelny; mike nicholas Subject: RE: updating list of server account password It looks to me like it will work. There is NO WAY that I would run a password changing script without logging everything I did. I would suggest again that you log the results. You have that line commented out. And with the 'w' you will overwrite the log everytime you run that sub so it will only have the last server you run it on. I suggest that you take out the 'w'. With the 'w' everytime you call that sub it will wipe out the file. This means that when you one it for remotehost6 it will wipe out everything from remotehost5 So I recommend that you replace: #$ssh->log_file($filename, 'w'); With $ssh->log_file($filename); I also recommend that you put in a couple of exits; 1 to close the root shell and the other to close your login shell. If you prefer a safer test, try running the hostname command rather than the passwd command. $ssh->expect(60, '$'); $ssh->send("su - root\n"); $ssh->expect(60, 'Password:'); $ssh->send("rootpassword\n"); $ssh->expect(60, '#'); $ssh->send("hostname\n"); # you might want to leave this in anyway to make reading the log easier $ssh->expect(60, '#'); $ssh->send("uptime\n"); #$ssh->send("passwd amagana\n"); #$ssh->expect(60, 'New Password:'); #$ssh->send("mynewpassword\n"); #$ssh->expect(60, 'Re-enter new Password:'); #$ssh->send("mynewpassword\n"); $ssh->expect(60, '#'); $ssh->send("exit\n"); $ssh->expect(60, '$'); $ssh->send("exit\n"); $ssh->close(); -----Original Message----- From: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT [mailto:andreas.magana.ctr at us.af.mil] Sent: Friday, April 03, 2015 3:53 PM To: openssl-users at openssl.org Cc: ESRY JR., DON; Matt Zagrabelny; mike nicholas Subject: updating list of server account password Hello Mike, Don and Matt, At the point I am at this list of servers in my script I would really need someone with more experience to see if I even have the right scripting. #!/usr/bin/perl use strict; use Expect; my $timeout = 60; my @servers = qw( remotehost03 remotehost04 remotehost05 remotehost06 ); for my $server (@servers) { # do your thing with $server change_password($server); } sub change_password { my $system = shift; my $filename = "/var/tmp/expect_script.log"; my $ssh = Expect->new('ssh amagana@' . $system); $ssh->debug(1); $ssh->expect ( $timeout, [ qr/Password:/], [ qr/Are you sure you want to continue connecting \(yes\/no\)?/] ); if ($ssh->match() =~ m/Are you sure you want to continue connecting \(yes\/no\)?/ ) { $ssh->send("yes\r"); } elsif ($ssh->match() =~ m/Password:/ ) { $ssh->send("mypassword\n"); } #$ssh->log_file($filename, 'w'); $ssh->expect(60, '$'); $ssh->send("su - root\n"); $ssh->expect(60, 'Password:'); $ssh->send("rootpassword\n"); $ssh->expect(60, '#'); $ssh->send("passwd amagana\n"); $ssh->expect(60, 'New Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, 'Re-enter new Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, '#'); $ssh->close(); Respectfully, #!/usr/bin/perl use strict; use Expect; my $timeout = 60; my $filename = "/var/tmp/expect_script.log"; my $ssh = Expect->new('ssh amagana at remotehost'); $ssh->debug(1); $ssh->expect ( $timeout, [ qr/Password:/], [ qr/Are you sure you want to continue connecting \(yes\/no\)?/] ); if ($ssh->match() =~ m/Are you sure you want to continue connecting \(yes\/no\)?/ ) { $ssh->send("yes\r"); } elsif ($ssh->match() =~ m/Password:/ ) { $ssh->send("mypassword\n"); } #$ssh->log_file($filename, 'w'); $ssh->expect(60, '$'); $ssh->send("su - root\n"); $ssh->expect(60, 'Password:'); $ssh->send("rootpassword\n"); $ssh->expect(60, '#'); $ssh->send("passwd amagana\n"); $ssh->expect(60, 'New Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, 'Re-enter new Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, '#'); $ssh->close(); //SIGNED// Andy Maga?a UNIX Systems Administrator Diligent Contractor, 72nd Air Base Wing Tinker Air Force Base, Oklahoma Commercial: (405) 734-0341 -----Original Message----- From: mike nicholas [mailto:xmikenicholasx at gmail.com] Sent: Wednesday, April 01, 2015 9:46 AM To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT Cc: ESRY JR., DON; Matt Zagrabelny; expectperl-discuss at lists.sourceforge.net Subject: Re: [Expectperl-discuss] expect.pm not updating password Try something like this: my $exp = new Expect; $exp->log_stdout(1); $username = "XXXXXX"; $exp->spawn( "ssh -l ${username} ${ip} " ) or die "cannot spawn $command: $! \n"; $exp->log_file("./${log_dir}/$ip\_info.log"); print "\nspawning ssh connection to $ip on $time\n\n"; $exp->log_file->print( "\nspawning ssh connection to $ip on $time\n\n" ); $exp->expect(8, [ 'connecting' => sub { $exp->send("yes \n"); exp_continue; } ], [ 'assword:' => sub { $exp->send("$pw\n"); exp_continue; } ], [ '-re', '> ?$' => sub { break; }], [ 'try again' => sub { die " died from bad password.\n"; }], [ 'refused' => sub { die " died from connection refused.\n"; exp_continue; } ], [ eof => sub { die " died from eof.\n"; }], [ timeout => sub { $exp->hard_close(); }], ); On Wed, Apr 1, 2015 at 9:24 AM, MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT wrote: Now that I have a working script and thanks very much to you Matt and Don, I am trying to put in my script an if else because sometimes my script will encounter this : Are you sure you want to continue connecting (yes/no)?') what I did create are some variables is this correct and may I see an example if statement so that the script can make a decision and keep going? use Expect; my $knownhost = $ssh->expect(60, 'Are you sure you want to continue connecting (yes/no)?'); my $answer = $ssh->send("yes\n"); my $filename = "/var/tmp/expect_script.log"; //SIGNED// Andy Maga?a UNIX Systems Administrator Diligent Contractor, 72nd Air Base Wing Tinker Air Force Base, Oklahoma Commercial: (405) 734-0341 -----Original Message----- From: ESRY JR., DON [mailto:de3253 at att.com] Sent: Tuesday, March 31, 2015 4:16 PM To: Matt Zagrabelny; MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT Cc: expectperl-discuss at lists.sourceforge.net Subject: RE: [Expectperl-discuss] expect.pm not updating password I think you will want a log file to identify where the script failed. I recommend that you take out the 'w' from the $ssh->log_file($filename, 'w'); so it will append to the file rather than over writing it for each server. And then put in some sort of header for each server, something like: my $header = "\n\n======= $system =======\n"; $ssh->print_log_file($header); Or if you prefer a separate file for each server, then my $filename = "/var/tmp/expect_script_". $system ".log"; little stuff like this can be very frustrating. -----Original Message----- From: Matt Zagrabelny [mailto:mzagrabe at d.umn.edu] Sent: Tuesday, March 31, 2015 4:56 PM To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT Cc: expectperl-discuss at lists.sourceforge.net Subject: Re: [Expectperl-discuss] expect.pm not updating password On Tue, Mar 31, 2015 at 3:37 PM, MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT wrote: > Thank you Matt, > > I just don't know how to put it in a working way I learn by examples I > am a novice on perl and the modules. Maybe spend a day or two writing some basic perl programs so you feel more comfortable with this stuff. I'm sure there are truckloads of perl tutorials out there. I added some context below. You'll need to clean up the leading '>' characters. -m > > #!/usr/bin/perl > use strict; > > use Expect; > > # my @servers = qw( > # server1.example.net > # server2.example.net > # server3.example.net > # server4.example.net > # server5.example.net > # ); > # > # for my $server (@servers) { > # # do your thing with $server change_password($server); > # } > sub change_password { my $system = shift; my $filename = "/var/tmp/expect_script.log"; my $ssh = Expect->new('ssh amagana@' . $system); > $ssh->debug(1); > $ssh->log_file($filename, 'w'); > $ssh->expect(60, 'Password:'); > $ssh->send("mycurrentpassword\n"); > $ssh->expect(60, '$'); > $ssh->send("su - root\n"); > $ssh->expect(60, 'Password:'); > $ssh->send("myrootpassword\n"); > $ssh->expect(60, '#'); > $ssh->send("passwd amagana\n"); > $ssh->expect(60, 'New Password:'); > $ssh->send("mynewpassword\n"); > $ssh->expect(60, 'Re-enter new Password:'); > $ssh->send("mynewpassword\n"); $ssh->expect(60, '#'); > $ssh->send("exit\n"); $ssh->close(); } ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Expectperl-discuss mailing list Expectperl-discuss at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/expectperl-discuss ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Expectperl-discuss mailing list Expectperl-discuss at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/expectperl-discuss -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3357 bytes Desc: not available URL: From cathy.fauntleroy at vdtg.com Mon Apr 6 15:34:50 2015 From: cathy.fauntleroy at vdtg.com (Cathy Fauntleroy) Date: Mon, 6 Apr 2015 11:34:50 -0400 Subject: [openssl-users] Getting Apache to Recognize New OpenSSL Install Message-ID: <002201d0707f$395a96a0$ac0fc3e0$@vdtg.com> Hello Users, I am in need of some assistance/documentation. My current setup is: Windows 2008 R2, Apache 2.2.25 w/OpenSSL 0.9.8. I need to enable TLS1.1, 1.2 but understand that 0.9.8 does not support those protocols. So, I installed OpenSSL 1.0.2a and made system environment mappings to the CNF and CFG files. The install was successful but Apache is not recognizing the updated OpenSSL version. I am not very familiar with the intricacies of configuring this product. Can anyone tell me how (or point me to documentation) I can get Apache to recognize the updated OpenSSL installation? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.magana.ctr at us.af.mil Mon Apr 6 15:52:36 2015 From: andreas.magana.ctr at us.af.mil (MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT) Date: Mon, 6 Apr 2015 15:52:36 +0000 Subject: [openssl-users] updating list of server account password In-Reply-To: References: <6ABA33135553E04E978A5ECCC07560D231A071B5@52ZHTX-D07-03C.area52.afnoapps.usaf.mil> Message-ID: <6ABA33135553E04E978A5ECCC07560D231A07612@52ZHTX-D07-03C.area52.afnoapps.usaf.mil> //SIGNED// Andy Maga?a UNIX Systems Administrator Diligent Contractor, 72nd Air Base Wing Tinker Air Force Base, Oklahoma Commercial: (405) 734-0341 -----Original Message----- From: mike nicholas [mailto:xmikenicholasx at gmail.com] Sent: Monday, April 06, 2015 10:48 AM To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT Cc: ESRY JR. DON; openssl-users at openssl.org; Matt Zagrabelny Subject: Re: updating list of server account password So the else if will only run if the first if is not true, that doesn't seem right,. On Apr 3, 2015 2:52 PM, "MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT" wrote: Hello Mike, Don and Matt, At the point I am at this list of servers in my script I would really need someone with more experience to see if I even have the right scripting. #!/usr/bin/perl use strict; use Expect; my $timeout = 60; my @servers = qw( remotehost03 remotehost04 remotehost05 remotehost06 ); for my $server (@servers) { # do your thing with $server change_password($server); } sub change_password { my $system = shift; my $filename = "/var/tmp/expect_script.log"; my $ssh = Expect->new('ssh amagana@' . $system); $ssh->debug(1); $ssh->expect ( $timeout, [ qr/Password:/], [ qr/Are you sure you want to continue connecting \(yes\/no\)?/] ); if ($ssh->match() =~ m/Are you sure you want to continue connecting \(yes\/no\)?/ ) { $ssh->send("yes\r"); } elsif ($ssh->match() =~ m/Password:/ ) { $ssh->send("mypassword\n"); } #$ssh->log_file($filename, 'w'); $ssh->expect(60, '$'); $ssh->send("su - root\n"); $ssh->expect(60, 'Password:'); $ssh->send("rootpassword\n"); $ssh->expect(60, '#'); $ssh->send("passwd amagana\n"); $ssh->expect(60, 'New Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, 'Re-enter new Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, '#'); $ssh->close(); Mike, If that does not seem right what can I change it to make it right? Respectfully, #!/usr/bin/perl use strict; use Expect; my $timeout = 60; my $filename = "/var/tmp/expect_script.log"; my $ssh = Expect->new('ssh amagana at remotehost'); $ssh->debug(1); $ssh->expect ( $timeout, [ qr/Password:/], [ qr/Are you sure you want to continue connecting \(yes\/no\)?/] ); if ($ssh->match() =~ m/Are you sure you want to continue connecting \(yes\/no\)?/ ) { $ssh->send("yes\r"); } elsif ($ssh->match() =~ m/Password:/ ) { $ssh->send("mypassword\n"); } #$ssh->log_file($filename, 'w'); $ssh->expect(60, '$'); $ssh->send("su - root\n"); $ssh->expect(60, 'Password:'); $ssh->send("rootpassword\n"); $ssh->expect(60, '#'); $ssh->send("passwd amagana\n"); $ssh->expect(60, 'New Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, 'Re-enter new Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, '#'); $ssh->close(); //SIGNED// Andy Maga?a UNIX Systems Administrator Diligent Contractor, 72nd Air Base Wing Tinker Air Force Base, Oklahoma Commercial: (405) 734-0341 -----Original Message----- From: mike nicholas [mailto:xmikenicholasx at gmail.com] Sent: Wednesday, April 01, 2015 9:46 AM To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT Cc: ESRY JR., DON; Matt Zagrabelny; expectperl-discuss at lists.sourceforge.net Subject: Re: [Expectperl-discuss] expect.pm not updating password Try something like this: my $exp = new Expect; $exp->log_stdout(1); $username = "XXXXXX"; $exp->spawn( "ssh -l ${username} ${ip} " ) or die "cannot spawn $command: $! \n"; $exp->log_file("./${log_dir}/$ip\_info.log"); print "\nspawning ssh connection to $ip on $time\n\n"; $exp->log_file->print( "\nspawning ssh connection to $ip on $time\n\n" ); $exp->expect(8, [ 'connecting' => sub { $exp->send("yes \n"); exp_continue; } ], [ 'assword:' => sub { $exp->send("$pw\n"); exp_continue; } ], [ '-re', '> ?$' => sub { break; }], [ 'try again' => sub { die " died from bad password.\n"; }], [ 'refused' => sub { die " died from connection refused.\n"; exp_continue; } ], [ eof => sub { die " died from eof.\n"; }], [ timeout => sub { $exp->hard_close(); }], ); On Wed, Apr 1, 2015 at 9:24 AM, MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT wrote: Now that I have a working script and thanks very much to you Matt and Don, I am trying to put in my script an if else because sometimes my script will encounter this : Are you sure you want to continue connecting (yes/no)?') what I did create are some variables is this correct and may I see an example if statement so that the script can make a decision and keep going? use Expect; my $knownhost = $ssh->expect(60, 'Are you sure you want to continue connecting (yes/no)?'); my $answer = $ssh->send("yes\n"); my $filename = "/var/tmp/expect_script.log"; //SIGNED// Andy Maga?a UNIX Systems Administrator Diligent Contractor, 72nd Air Base Wing Tinker Air Force Base, Oklahoma Commercial: (405) 734-0341 -----Original Message----- From: ESRY JR., DON [mailto:de3253 at att.com] Sent: Tuesday, March 31, 2015 4:16 PM To: Matt Zagrabelny; MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT Cc: expectperl-discuss at lists.sourceforge.net Subject: RE: [Expectperl-discuss] expect.pm not updating password I think you will want a log file to identify where the script failed. I recommend that you take out the 'w' from the $ssh->log_file($filename, 'w'); so it will append to the file rather than over writing it for each server. And then put in some sort of header for each server, something like: my $header = "\n\n======= $system =======\n"; $ssh->print_log_file($header); Or if you prefer a separate file for each server, then my $filename = "/var/tmp/expect_script_". $system ".log"; little stuff like this can be very frustrating. -----Original Message----- From: Matt Zagrabelny [mailto:mzagrabe at d.umn.edu] Sent: Tuesday, March 31, 2015 4:56 PM To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT Cc: expectperl-discuss at lists.sourceforge.net Subject: Re: [Expectperl-discuss] expect.pm not updating password On Tue, Mar 31, 2015 at 3:37 PM, MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT wrote: > Thank you Matt, > > I just don't know how to put it in a working way I learn by examples I > am a novice on perl and the modules. Maybe spend a day or two writing some basic perl programs so you feel more comfortable with this stuff. I'm sure there are truckloads of perl tutorials out there. I added some context below. You'll need to clean up the leading '>' characters. -m > > #!/usr/bin/perl > use strict; > > use Expect; > > # my @servers = qw( > # server1.example.net > # server2.example.net > # server3.example.net > # server4.example.net > # server5.example.net > # ); > # > # for my $server (@servers) { > # # do your thing with $server change_password($server); > # } > sub change_password { my $system = shift; my $filename = "/var/tmp/expect_script.log"; my $ssh = Expect->new('ssh amagana@' . $system); > $ssh->debug(1); > $ssh->log_file($filename, 'w'); > $ssh->expect(60, 'Password:'); > $ssh->send("mycurrentpassword\n"); > $ssh->expect(60, '$'); > $ssh->send("su - root\n"); > $ssh->expect(60, 'Password:'); > $ssh->send("myrootpassword\n"); > $ssh->expect(60, '#'); > $ssh->send("passwd amagana\n"); > $ssh->expect(60, 'New Password:'); > $ssh->send("mynewpassword\n"); > $ssh->expect(60, 'Re-enter new Password:'); > $ssh->send("mynewpassword\n"); $ssh->expect(60, '#'); > $ssh->send("exit\n"); $ssh->close(); } ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Expectperl-discuss mailing list Expectperl-discuss at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/expectperl-discuss ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Expectperl-discuss mailing list Expectperl-discuss at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/expectperl-discuss From cathy.fauntleroy at vdtg.com Mon Apr 6 16:04:31 2015 From: cathy.fauntleroy at vdtg.com (Cathy Fauntleroy) Date: Mon, 6 Apr 2015 12:04:31 -0400 Subject: [openssl-users] FW: Getting Apache to Recognize New OpenSSL Install In-Reply-To: <002201d0707f$395a96a0$ac0fc3e0$@vdtg.com> References: <002201d0707f$395a96a0$ac0fc3e0$@vdtg.com> Message-ID: <003801d07083$5e942c20$1bbc8460$@vdtg.com> A follow-up question.Should I have installed Apache 2.2.25 with no OpenSSL (instead of the one I did install with OpenSSL 0.9.8)? I'm thinking that perhaps with the no ssl install, Apache would more easily recognize my OpenSSL 1.0.2 instance. I appreciate your thoughts and suggestions. Thanks. Cathy Fauntleroy, Security+ Van Dyke Technology Group Email: cathy.fauntleroy at vdtg.com Office: (443) 832-4768 From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Cathy Fauntleroy Sent: Monday, April 6, 2015 11:35 AM To: openssl-users at openssl.org Subject: [openssl-users] Getting Apache to Recognize New OpenSSL Install Hello Users, I am in need of some assistance/documentation. My current setup is: Windows 2008 R2, Apache 2.2.25 w/OpenSSL 0.9.8. I need to enable TLS1.1, 1.2 but understand that 0.9.8 does not support those protocols. So, I installed OpenSSL 1.0.2a and made system environment mappings to the CNF and CFG files. The install was successful but Apache is not recognizing the updated OpenSSL version. I am not very familiar with the intricacies of configuring this product. Can anyone tell me how (or point me to documentation) I can get Apache to recognize the updated OpenSSL installation? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Untitled attachment 00054.txt URL: From erwann.abalea at opentrust.com Mon Apr 6 16:40:28 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Mon, 06 Apr 2015 18:40:28 +0200 Subject: [openssl-users] Fwd to openssl-users Re: [openssl-dev] Why the issuer cannot be found? In-Reply-To: <551F5B19.9020701@wisemo.com> References: <551E55D6.3000403@opentrust.com> <551F5B19.9020701@wisemo.com> Message-ID: <5522B6FC.8030501@opentrust.com> Le 04/04/2015 05:31, Jakob Bohm a ?crit : > (top posting like the rest of the thread) (I don't like it either, but that's what Thunderbird proposes by default). > What makes you think it is incorrect to check the Key > Identifier (where present) before checking a signature > against a key? Because the presented file4.pem is a valid issuer certificate for the one found in file3.pem? RFC5280 section 6.1 gives the validation algorithm, and the Key Identifier isn't mentioned. 6.1.3(a) checks for signature, validity, revocation status, and names (i.e. that issuercert.subjectName = cert.issuerName). You're not supposed to follow exactly the same algorithm (or the one described in X.509), but whatever you choose, the result MUST be equivalent. > What other reasonable purpose could the Key Identifier > fields serve? A helper to build a certificate chain to be passed to the validation algorithm. > On 03/04/2015 10:56, Erwann Abalea wrote: > > (Forwarded to openssl-users) > > > > The subjectName of file4.pem matches the issuerName of > > file3.pem, the signature block in file3.pem, when verified > > with the public key of file4.pem, gives a correct signature > > for the tbsCertificate of file3.pem. But Openssl also > > (incorrectly, IMO) checks that file4.pem.SKI matches > > file3.pem.AKI, and refuses to go further (here, AKI doesn't > > match SKI). > > > > Le 03/04/2015 03:10, Yuting Chen a ?crit : > > > I used OpenSSL to verify a certificate file (file3.pem) > > > against another certificate file (file4.pem). OpenSSL > > > reports that it cannot find the issuer of the cert in > > > file3.pem; while when I displays file3.pem and file4.pem, > > > it appears that the issuer of the cert in file3.pem is the > > > same as the subject of the cert in file4.pem. Did I miss > > > anything? > > P.S. > > Don't put your e-mail sig in the middle of the mail, it causes > standards-compliant mail programs to cut off everything below > it when replying (because everyting below the -- marker > is, by definition, just the e-mail sig). I know, I often forget to manually switch between "corporate" and "hard core" modes. And Thunderbird doesn't help. -- Erwann ABALEA From openssl-users at dukhovni.org Mon Apr 6 17:26:34 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 6 Apr 2015 17:26:34 +0000 Subject: [openssl-users] Fwd to openssl-users Re: [openssl-dev] Why the issuer cannot be found? In-Reply-To: <5522B6FC.8030501@opentrust.com> References: <551E55D6.3000403@opentrust.com> <551F5B19.9020701@wisemo.com> <5522B6FC.8030501@opentrust.com> Message-ID: <20150406172634.GX17637@mournblade.imrryr.org> On Mon, Apr 06, 2015 at 06:40:28PM +0200, Erwann Abalea wrote: > >What makes you think it is incorrect to check the Key > >Identifier (where present) before checking a signature > >against a key? > > Because the presented file4.pem is a valid issuer certificate for the one > found in file3.pem? > RFC5280 section 6.1 gives the validation algorithm, and the Key Identifier > isn't mentioned. > 6.1.3(a) checks for signature, validity, revocation status, and names (i.e. > that issuercert.subjectName = cert.issuerName). > > You're not supposed to follow exactly the same algorithm (or the one > described in X.509), but whatever you choose, the result MUST be equivalent. On the other hand issuers should not issue certificates whose AKID keyid does not match the subject key identifier of the issuer CA. OpenSSL has been checking this condition for two decades at least, and changing this is an incompatible change that cannot be made in any releases prior to 1.1.0 (not yet released). Even then, I am not convinced that the proposed change is warranted. -- Viktor. From marquess at openssl.com Mon Apr 6 17:38:43 2015 From: marquess at openssl.com (Steve Marquess) Date: Mon, 06 Apr 2015 13:38:43 -0400 Subject: [openssl-users] Is there any plan for FIPS to be supported on Linux-aarch64? In-Reply-To: References: <1428282801225-57389.post@n7.nabble.com> <55228FFF.203@openssl.com> <55229BB0.6060306@openssl.com> Message-ID: <5522C4A3.6040504@openssl.com> On 04/06/2015 10:59 AM, Nicolae Rosia wrote: > I see. Still, the documentation sent to the lab would be helpful to > the community to better understand/review the existing code. We don't send any documentation to the test labs unless they are performing validations actions for us, for which we must pay them. Also FYI for change letters the (unique/creative component of the) documentation is trivial. As with most FIPS 140-2 documentation such paperwork is very low in nutritional value and of essentially no value to the end user. In particular it isn't going to help anyone "better understand/review" the existing code. The code itself is open source, so as Obi-Wan said, "use the source, Luke". -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From chenyt at cs.sjtu.edu.cn Mon Apr 6 17:55:05 2015 From: chenyt at cs.sjtu.edu.cn (Yuting Chen) Date: Mon, 6 Apr 2015 10:55:05 -0700 Subject: [openssl-users] openssl is flexible when verifying In-Reply-To: References: Message-ID: Not sure about how to completely solve the problem. As the function X509V3_get_d2i(STACK_OF(X509_EXTENSION) *x, int nid, int *crit, int *idx) is called, crit is not actually used. (e.g., in v3_purp.c, line 462) x->akid =X509_get_ext_d2i(x, NID_authority_key_identifier, NULL, NULL); If the value of crit can be retrieved, we may fix function X509_check_issued (around line 701). if(X509_NAME_cmp(X509_get_subject_name(issuer), X509_get_issuer_name(subject))) return X509_V_ERR_SUBJECT_ISSUER_MISMATCH; x509v3_cache_extensions(issuer); x509v3_cache_extensions(subject); if(subject->akid) { int ret = X509_check_akid(issuer, subject->akid); if (ret != X509_V_OK) return ret; } + else if (crit==-2) //subject has more than one akids + return X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH; -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.magana.ctr at us.af.mil Mon Apr 6 18:11:27 2015 From: andreas.magana.ctr at us.af.mil (MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT) Date: Mon, 6 Apr 2015 18:11:27 +0000 Subject: [openssl-users] updating list of server account password In-Reply-To: References: <6ABA33135553E04E978A5ECCC07560D231A071B5@52ZHTX-D07-03C.area52.afnoapps.usaf.mil> <6ABA33135553E04E978A5ECCC07560D231A07612@52ZHTX-D07-03C.area52.afnoapps.usaf.mil> Message-ID: <6ABA33135553E04E978A5ECCC07560D231A0766D@52ZHTX-D07-03C.area52.afnoapps.usaf.mil> What does the ${ip} mean? //SIGNED// Andy Maga?a UNIX Systems Administrator Diligent Contractor, 72nd Air Base Wing Tinker Air Force Base, Oklahoma Commercial: (405) 734-0341 -----Original Message----- From: mike nicholas [mailto:xmikenicholasx at gmail.com] Sent: Monday, April 06, 2015 10:58 AM To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT Cc: ESRY JR. DON; openssl-users at openssl.org; Matt Zagrabelny Subject: Re: updating list of server account password Try something like this: my $exp = new Expect; $exp->log_stdout(1); $username = "XXXXXX"; $exp->spawn( "ssh -l ${username} ${ip} " ) or die "cannot spawn $command: $! \n"; $exp->log_file("./${log_dir}/$ip\_info.log"); print "\nspawning ssh connection to $ip on $time\n\n"; $exp->log_file->print( "\nspawning ssh connection to $ip on $time\n\n" ); $exp->expect(8, [ 'connecting' => sub { $exp->send("yes \n"); exp_continue; } ], [ 'assword:' => sub { $exp->send("$pw\n"); exp_continue; } ], [ '-re', '> ?$' => sub { break; }], [ 'try again' => sub { die " died from bad password.\n"; }], [ 'refused' => sub { die " died from connection refused.\n"; exp_continue; } ], [ eof => sub { die " died from eof.\n"; }], [ timeout => sub { $exp->hard_close(); }], ); On Mon, Apr 6, 2015 at 10:52 AM, MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT wrote: //SIGNED// Andy Maga?a UNIX Systems Administrator Diligent Contractor, 72nd Air Base Wing Tinker Air Force Base, Oklahoma Commercial: (405) 734-0341 -----Original Message----- From: mike nicholas [mailto:xmikenicholasx at gmail.com] Sent: Monday, April 06, 2015 10:48 AM To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT Cc: ESRY JR. DON; openssl-users at openssl.org; Matt Zagrabelny Subject: Re: updating list of server account password So the else if will only run if the first if is not true, that doesn't seem right,. On Apr 3, 2015 2:52 PM, "MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT" wrote: Hello Mike, Don and Matt, At the point I am at this list of servers in my script I would really need someone with more experience to see if I even have the right scripting. #!/usr/bin/perl use strict; use Expect; my $timeout = 60; my @servers = qw( remotehost03 remotehost04 remotehost05 remotehost06 ); for my $server (@servers) { # do your thing with $server change_password($server); } sub change_password { my $system = shift; my $filename = "/var/tmp/expect_script.log"; my $ssh = Expect->new('ssh amagana@' . $system); $ssh->debug(1); $ssh->expect ( $timeout, [ qr/Password:/], [ qr/Are you sure you want to continue connecting \(yes\/no\)?/] ); if ($ssh->match() =~ m/Are you sure you want to continue connecting \(yes\/no\)?/ ) { $ssh->send("yes\r"); } elsif ($ssh->match() =~ m/Password:/ ) { $ssh->send("mypassword\n"); } #$ssh->log_file($filename, 'w'); $ssh->expect(60, '$'); $ssh->send("su - root\n"); $ssh->expect(60, 'Password:'); $ssh->send("rootpassword\n"); $ssh->expect(60, '#'); $ssh->send("passwd amagana\n"); $ssh->expect(60, 'New Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, 'Re-enter new Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, '#'); $ssh->close(); Mike, If that does not seem right what can I change it to make it right? Respectfully, #!/usr/bin/perl use strict; use Expect; my $timeout = 60; my $filename = "/var/tmp/expect_script.log"; my $ssh = Expect->new('ssh amagana at remotehost'); $ssh->debug(1); $ssh->expect ( $timeout, [ qr/Password:/], [ qr/Are you sure you want to continue connecting \(yes\/no\)?/] ); if ($ssh->match() =~ m/Are you sure you want to continue connecting \(yes\/no\)?/ ) { $ssh->send("yes\r"); } elsif ($ssh->match() =~ m/Password:/ ) { $ssh->send("mypassword\n"); } #$ssh->log_file($filename, 'w'); $ssh->expect(60, '$'); $ssh->send("su - root\n"); $ssh->expect(60, 'Password:'); $ssh->send("rootpassword\n"); $ssh->expect(60, '#'); $ssh->send("passwd amagana\n"); $ssh->expect(60, 'New Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, 'Re-enter new Password:'); $ssh->send("mynewpassword\n"); $ssh->expect(60, '#'); $ssh->close(); //SIGNED// Andy Maga?a UNIX Systems Administrator Diligent Contractor, 72nd Air Base Wing Tinker Air Force Base, Oklahoma Commercial: (405) 734-0341 -----Original Message----- From: mike nicholas [mailto:xmikenicholasx at gmail.com] Sent: Wednesday, April 01, 2015 9:46 AM To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT Cc: ESRY JR., DON; Matt Zagrabelny; expectperl-discuss at lists.sourceforge.net Subject: Re: [Expectperl-discuss] expect.pm not updating password Try something like this: my $exp = new Expect; $exp->log_stdout(1); $username = "XXXXXX"; $exp->spawn( "ssh -l ${username} ${ip} " ) or die "cannot spawn $command: $! \n"; $exp->log_file("./${log_dir}/$ip\_info.log"); print "\nspawning ssh connection to $ip on $time\n\n"; $exp->log_file->print( "\nspawning ssh connection to $ip on $time\n\n" ); $exp->expect(8, [ 'connecting' => sub { $exp->send("yes \n"); exp_continue; } ], [ 'assword:' => sub { $exp->send("$pw\n"); exp_continue; } ], [ '-re', '> ?$' => sub { break; }], [ 'try again' => sub { die " died from bad password.\n"; }], [ 'refused' => sub { die " died from connection refused.\n"; exp_continue; } ], [ eof => sub { die " died from eof.\n"; }], [ timeout => sub { $exp->hard_close(); }], ); On Wed, Apr 1, 2015 at 9:24 AM, MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT wrote: Now that I have a working script and thanks very much to you Matt and Don, I am trying to put in my script an if else because sometimes my script will encounter this : Are you sure you want to continue connecting (yes/no)?') what I did create are some variables is this correct and may I see an example if statement so that the script can make a decision and keep going? use Expect; my $knownhost = $ssh->expect(60, 'Are you sure you want to continue connecting (yes/no)?'); my $answer = $ssh->send("yes\n"); my $filename = "/var/tmp/expect_script.log"; //SIGNED// Andy Maga?a UNIX Systems Administrator Diligent Contractor, 72nd Air Base Wing Tinker Air Force Base, Oklahoma Commercial: (405) 734-0341 -----Original Message----- From: ESRY JR., DON [mailto:de3253 at att.com] Sent: Tuesday, March 31, 2015 4:16 PM To: Matt Zagrabelny; MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT Cc: expectperl-discuss at lists.sourceforge.net Subject: RE: [Expectperl-discuss] expect.pm not updating password I think you will want a log file to identify where the script failed. I recommend that you take out the 'w' from the $ssh->log_file($filename, 'w'); so it will append to the file rather than over writing it for each server. And then put in some sort of header for each server, something like: my $header = "\n\n======= $system =======\n"; $ssh->print_log_file($header); Or if you prefer a separate file for each server, then my $filename = "/var/tmp/expect_script_". $system ".log"; little stuff like this can be very frustrating. -----Original Message----- From: Matt Zagrabelny [mailto:mzagrabe at d.umn.edu] Sent: Tuesday, March 31, 2015 4:56 PM To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT Cc: expectperl-discuss at lists.sourceforge.net Subject: Re: [Expectperl-discuss] expect.pm not updating password On Tue, Mar 31, 2015 at 3:37 PM, MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT wrote: > Thank you Matt, > > I just don't know how to put it in a working way I learn by examples I > am a novice on perl and the modules. Maybe spend a day or two writing some basic perl programs so you feel more comfortable with this stuff. I'm sure there are truckloads of perl tutorials out there. I added some context below. You'll need to clean up the leading '>' characters. -m > > #!/usr/bin/perl > use strict; > > use Expect; > > # my @servers = qw( > # server1.example.net > # server2.example.net > # server3.example.net > # server4.example.net > # server5.example.net > # ); > # > # for my $server (@servers) { > # # do your thing with $server change_password($server); > # } > sub change_password { my $system = shift; my $filename = "/var/tmp/expect_script.log"; my $ssh = Expect->new('ssh amagana@' . $system); > $ssh->debug(1); > $ssh->log_file($filename, 'w'); > $ssh->expect(60, 'Password:'); > $ssh->send("mycurrentpassword\n"); > $ssh->expect(60, '$'); > $ssh->send("su - root\n"); > $ssh->expect(60, 'Password:'); > $ssh->send("myrootpassword\n"); > $ssh->expect(60, '#'); > $ssh->send("passwd amagana\n"); > $ssh->expect(60, 'New Password:'); > $ssh->send("mynewpassword\n"); > $ssh->expect(60, 'Re-enter new Password:'); > $ssh->send("mynewpassword\n"); $ssh->expect(60, '#'); > $ssh->send("exit\n"); $ssh->close(); } ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Expectperl-discuss mailing list Expectperl-discuss at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/expectperl-discuss ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Expectperl-discuss mailing list Expectperl-discuss at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/expectperl-discuss From sanumesh at in.ibm.com Mon Apr 6 18:20:09 2015 From: sanumesh at in.ibm.com (Sandeep Umesh) Date: Mon, 6 Apr 2015 23:50:09 +0530 Subject: [openssl-users] openssl impact on CVE-2015-2808 Message-ID: Hello Users, Just want to understand the impact of openssl for RC4 Bar mitzvah attack. Please correct me if my understanding is wrong, basically this attack is triggered based on the design of RC4. openssl is one of the implementers of RC4 algo. I am not sure if there will be any design change or openssl will try to disable RC4 support... But, Is disabling RC4 algo usage in the applications which are using openssl a better approach? Thanks Regards Sandeep -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Mon Apr 6 18:36:35 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 6 Apr 2015 14:36:35 -0400 Subject: [openssl-users] openssl impact on CVE-2015-2808 In-Reply-To: References: Message-ID: > Please correct me if my understanding is wrong, basically this attack is > triggered based on the design of RC4. > openssl is one of the implementers of RC4 algo. There are biases in the stream created by RC4. In theory, and adversary could use the biases to as a launchpad to recover plain text (but I seem to recall it needs a lot of cipher text). RC4 has been wounded again, but it has not been broken. > I am not sure if there will be any design change or openssl will try to > disable RC4 support... Probably not. Just add "!RC4" to you cipher suite list to remove it if you don't want it. For example, "HIGH:!ADH:!RC4:!MD5". > But, Is disabling RC4 algo usage in the applications which are using openssl > a better approach? Thanks In TLS 1.2, you have the AES/GCM cipher suites. You also have the upcoming ChaCha20/Poly1305 cipher suites. (ChaCha20/Poly1305 is predicated on the TLS Working Group choosing to adopt them, see https://www.ietf.org/mail-archive/web/tls/current/msg15722.html). In TLS 1.1 and below, you only have block ciphers if you remove RC4. You'll have to make due with AES/CBC (or another block cipher). Jeff From chenyt at cs.sjtu.edu.cn Mon Apr 6 18:42:57 2015 From: chenyt at cs.sjtu.edu.cn (Yuting Chen) Date: Mon, 6 Apr 2015 11:42:57 -0700 Subject: [openssl-users] openssl is flexible when verifying In-Reply-To: References: Message-ID: As Jeffrey Walton's comment, the standard is very malleable, making cert path validation a little unpredictable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.farrell at oracle.com Mon Apr 6 17:54:50 2015 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Mon, 06 Apr 2015 18:54:50 +0100 Subject: [openssl-users] FW: Getting Apache to Recognize New OpenSSL Install In-Reply-To: <003801d07083$5e942c20$1bbc8460$@vdtg.com> References: <002201d0707f$395a96a0$ac0fc3e0$@vdtg.com> <003801d07083$5e942c20$1bbc8460$@vdtg.com> Message-ID: <5522C86A.7000605@oracle.com> There might be people on the OpenSSL list who can answer this, but your question is really about Apache configuration or installation. You'll probably get more knowledgable answers on an Apache list. Regards, jjf On 06/04/2015 17:04, Cathy Fauntleroy wrote: > > A follow-up question?Should I have installed Apache 2.2.25 with no > OpenSSL (instead of the one I did install with OpenSSL 0.9.8)? I?m > thinking that perhaps with the no ssl install, Apache would more > easily recognize my OpenSSL 1.0.2 instance. I appreciate your > thoughts and suggestions. > > Thanks? > > */Cathy Fauntleroy,/**Security+* > > *Van Dyke Technology Group* > > *Email:**cathy.fauntleroy at vdtg.com * > > *Office: (443) 832-4768* > > *From:* openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *Cathy Fauntleroy > *Sent:* Monday, April 6, 2015 11:35 AM > *To:* openssl-users at openssl.org > *Subject:* [openssl-users] Getting Apache to Recognize New OpenSSL Install > > Hello Users, > > I am in need of some assistance/documentation. My current setup is: > Windows 2008 R2, Apache 2.2.25 w/OpenSSL 0.9.8. I need to enable > TLS1.1, 1.2 but understand that 0.9.8 does not support those > protocols. So, I installed OpenSSL 1.0.2a and made system environment > mappings to the CNF and CFG files. The install was successful but > Apache is not recognizing the updated OpenSSL version. I am not very > familiar with the intricacies of configuring this product. Can anyone > tell me how (or point me to documentation) I can get Apache to > recognize the updated OpenSSL installation? > > Thanks?** > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- J. J. Farrell w: +44 161 493 4838 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Mon Apr 6 19:46:58 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 6 Apr 2015 19:46:58 +0000 Subject: [openssl-users] openssl impact on CVE-2015-2808 In-Reply-To: References: Message-ID: Bar Mitzvah is an improvement on existing attacks against RC4. It's a credible exposure under some threat models. Primarily it's an issue for sites with a lot of RC4 conversations, since it depends on the use of weak keys, which are a large subset of all RC4 keys. When a conversation (randomly) chooses a weak key, some information is leaked to the attacker, who can then try to brute-force parts of the conversation. Typically that will be something like a session ID - generally only useful for the lifetime of the session - or a commonly-used user password. (The Bar Mitzvah paper describes how it can be used to improve brute-force attacks on user passwords that are passed in RC4-encrypted data.) So: If your systems participate in a lot of RC4 conversations, and your threat model includes passive attackers gaining sufficient information to make brute-forcing small pieces of data feasible, then Bar Mitzvah is a problem. We can't tell you whether it's something you need to be concerned about. That depends on YOUR threat model. If you don't know what your threat model is, then you can't make informed security decisions. The attack applies to all implementations of RC4, and its use by any SSL/TLS implementation. OpenSSL can't fix the problem. A future release of OpenSSL may remove RC4 suites from the default list (indeed, it's probably all but inevitable), so applications won't use it unless they enable it. For now, it's enabled by default. Michael Wojcik Technology Specialist, Micro Focus From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Sandeep Umesh Sent: Monday, April 06, 2015 14:20 To: OpenSSL User Support ML Subject: [openssl-users] openssl impact on CVE-2015-2808 Just want to understand the impact of openssl for RC4 Bar mitzvah attack. Please correct me if my understanding is wrong, basically this attack is triggered based on the design of RC4. openssl is one of the implementers of RC4 algo. I am not sure if there will be any design change or openssl will try to disable RC4 support... But, Is disabling RC4 algo usage in the applications which are using openssl a better approach? Thanks This message has been scanned for malware by Websense. www.websense.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cathy.fauntleroy at vdtg.com Mon Apr 6 19:50:44 2015 From: cathy.fauntleroy at vdtg.com (Cathy Fauntleroy) Date: Mon, 6 Apr 2015 15:50:44 -0400 Subject: [openssl-users] FW: Getting Apache to Recognize New OpenSSL Install In-Reply-To: <5522C86A.7000605@oracle.com> References: <002201d0707f$395a96a0$ac0fc3e0$@vdtg.com> <003801d07083$5e942c20$1bbc8460$@vdtg.com> <5522C86A.7000605@oracle.com> Message-ID: <005c01d070a2$f8a96bd0$e9fc4370$@vdtg.com> I've posed the same question on the Apache user forum but have not received any responses. Thanks. Cathy From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jeremy Farrell Sent: Monday, April 6, 2015 1:55 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] FW: Getting Apache to Recognize New OpenSSL Install There might be people on the OpenSSL list who can answer this, but your question is really about Apache configuration or installation. You'll probably get more knowledgable answers on an Apache list. Regards, jjf On 06/04/2015 17:04, Cathy Fauntleroy wrote: A follow-up question.Should I have installed Apache 2.2.25 with no OpenSSL (instead of the one I did install with OpenSSL 0.9.8)? I'm thinking that perhaps with the no ssl install, Apache would more easily recognize my OpenSSL 1.0.2 instance. I appreciate your thoughts and suggestions. Thanks. Cathy Fauntleroy, Security+ Van Dyke Technology Group Email: cathy.fauntleroy at vdtg.com Office: (443) 832-4768 From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Cathy Fauntleroy Sent: Monday, April 6, 2015 11:35 AM To: openssl-users at openssl.org Subject: [openssl-users] Getting Apache to Recognize New OpenSSL Install Hello Users, I am in need of some assistance/documentation. My current setup is: Windows 2008 R2, Apache 2.2.25 w/OpenSSL 0.9.8. I need to enable TLS1.1, 1.2 but understand that 0.9.8 does not support those protocols. So, I installed OpenSSL 1.0.2a and made system environment mappings to the CNF and CFG files. The install was successful but Apache is not recognizing the updated OpenSSL version. I am not very familiar with the intricacies of configuring this product. Can anyone tell me how (or point me to documentation) I can get Apache to recognize the updated OpenSSL installation? Thanks. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- J. J. Farrell w: +44 161 493 4838 -------------- next part -------------- An HTML attachment was scrubbed... URL: From foleyj at cisco.com Mon Apr 6 20:04:05 2015 From: foleyj at cisco.com (John Foley) Date: Mon, 06 Apr 2015 16:04:05 -0400 Subject: [openssl-users] FW: Getting Apache to Recognize New OpenSSL Install In-Reply-To: <005c01d070a2$f8a96bd0$e9fc4370$@vdtg.com> References: <002201d0707f$395a96a0$ac0fc3e0$@vdtg.com> <003801d07083$5e942c20$1bbc8460$@vdtg.com> <5522C86A.7000605@oracle.com> <005c01d070a2$f8a96bd0$e9fc4370$@vdtg.com> Message-ID: <5522E6B5.7020704@cisco.com> Have you recompiled Apache? Or did you only recompile OpenSSL 1.0.2a? There is no binary compatibility between 0.9.8 and 1.0.2. You'll need to recompile Apache if you haven't done this. Or, possibly a newer Apache binary (2.4.12) would work with your OpenSSL 1.0.2a build. On 04/06/2015 03:50 PM, Cathy Fauntleroy wrote: > > I?ve posed the same question on the Apache user forum but have not > received any responses. > > > > Thanks? > > */Cathy /*** > > > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *Jeremy Farrell > *Sent:* Monday, April 6, 2015 1:55 PM > *To:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] FW: Getting Apache to Recognize New > OpenSSL Install > > > > There might be people on the OpenSSL list who can answer this, but > your question is really about Apache configuration or installation. > You'll probably get more knowledgable answers on an Apache list. > > Regards, > jjf > > On 06/04/2015 17:04, Cathy Fauntleroy wrote: > > A follow-up question?Should I have installed Apache 2.2.25 with no > OpenSSL (instead of the one I did install with OpenSSL 0.9.8)? > I?m thinking that perhaps with the no ssl install, Apache would > more easily recognize my OpenSSL 1.0.2 instance. I appreciate > your thoughts and suggestions. > > > > Thanks? > > > */Cathy Fauntleroy,/* *Security+* > > *Van Dyke Technology Group* > > *Email:** cathy.fauntleroy at vdtg.com > * > > *Office: (443) 832-4768* > > > > *From:* openssl-users [mailto:openssl-users-bounces at openssl.org] > *On Behalf Of *Cathy Fauntleroy > *Sent:* Monday, April 6, 2015 11:35 AM > *To:* openssl-users at openssl.org > *Subject:* [openssl-users] Getting Apache to Recognize New OpenSSL > Install > > > > Hello Users, > > > > I am in need of some assistance/documentation. My current setup > is: Windows 2008 R2, Apache 2.2.25 w/OpenSSL 0.9.8. I need to > enable TLS1.1, 1.2 but understand that 0.9.8 does not support > those protocols. So, I installed OpenSSL 1.0.2a and made system > environment mappings to the CNF and CFG files. The install was > successful but Apache is not recognizing the updated OpenSSL > version. I am not very familiar with the intricacies of > configuring this product. Can anyone tell me how (or point me to > documentation) I can get Apache to recognize the updated OpenSSL > installation? > > > > Thanks? > > > > > > > _______________________________________________ > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > -- > J. J. Farrell > w: +44 161 493 4838 > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Apr 6 21:40:22 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 6 Apr 2015 21:40:22 +0000 Subject: [openssl-users] updating list of server account password In-Reply-To: <6ABA33135553E04E978A5ECCC07560D231A07612@52ZHTX-D07-03C.area52.afnoapps.usaf.mil> References: <6ABA33135553E04E978A5ECCC07560D231A071B5@52ZHTX-D07-03C.area52.afnoapps.usaf.mil> <6ABA33135553E04E978A5ECCC07560D231A07612@52ZHTX-D07-03C.area52.afnoapps.usaf.mil> Message-ID: Perhaps you don't want to post this kind of thing to a global mailing list for all users of openssl? -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz > -----Original Message----- > From: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT > [mailto:andreas.magana.ctr at us.af.mil] > Sent: Monday, April 06, 2015 11:53 AM > To: mike nicholas > Cc: openssl-users at openssl.org; ESRY JR. DON; Matt Zagrabelny > Subject: Re: [openssl-users] updating list of server account password > > > > //SIGNED// > > Andy Maga?a > UNIX Systems Administrator > Diligent Contractor, 72nd Air Base Wing > Tinker Air Force Base, Oklahoma > Commercial: (405) 734-0341 > > > -----Original Message----- > From: mike nicholas [mailto:xmikenicholasx at gmail.com] > Sent: Monday, April 06, 2015 10:48 AM > To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT > Cc: ESRY JR. DON; openssl-users at openssl.org; Matt Zagrabelny > Subject: Re: updating list of server account password > > So the else if will only run if the first if is not true, that doesn't seem right,. > > On Apr 3, 2015 2:52 PM, "MAGANA, ANDREAS S I CTR USAF AFMC 72 > ABW/SCOOT" wrote: > > > Hello Mike, Don and Matt, > > At the point I am at this list of servers in my script I would really need > someone with more experience to see if I even have the right scripting. > > > #!/usr/bin/perl > use strict; > > use Expect; > > my $timeout = 60; > > my @servers = qw( > remotehost03 > remotehost04 > remotehost05 > remotehost06 > ); > > > for my $server (@servers) { > # do your thing with $server > > change_password($server); > > } > > sub change_password { > my $system = shift; > > my $filename = "/var/tmp/expect_script.log"; > my $ssh = Expect->new('ssh amagana@' . $system); > > > $ssh->debug(1); > $ssh->expect ( $timeout, > [ qr/Password:/], > [ qr/Are you sure you want to continue connecting \(yes\/no\)?/] > ); > > if ($ssh->match() =~ m/Are you sure you want to continue > connecting \(yes\/no\)?/ ) { > $ssh->send("yes\r"); > } > > elsif ($ssh->match() =~ m/Password:/ ) { > $ssh->send("mypassword\n"); > } > > > #$ssh->log_file($filename, 'w'); > $ssh->expect(60, '$'); > $ssh->send("su - root\n"); > $ssh->expect(60, 'Password:'); > $ssh->send("rootpassword\n"); > $ssh->expect(60, '#'); > $ssh->send("passwd amagana\n"); > $ssh->expect(60, 'New Password:'); > $ssh->send("mynewpassword\n"); > $ssh->expect(60, 'Re-enter new Password:'); > $ssh->send("mynewpassword\n"); > $ssh->expect(60, '#'); > $ssh->close(); > > > > > > > > > > > Mike, > > If that does not seem right what can I change it to make it right? > > > > > > > > > > > > > > > > Respectfully, > > > #!/usr/bin/perl > use strict; > > use Expect; > my $timeout = 60; > my $filename = "/var/tmp/expect_script.log"; > my $ssh = Expect->new('ssh amagana at remotehost'); > > $ssh->debug(1); > $ssh->expect ( $timeout, > [ qr/Password:/], > [ qr/Are you sure you want to continue connecting \(yes\/no\)?/] > ); > > if ($ssh->match() =~ m/Are you sure you want to continue > connecting \(yes\/no\)?/ ) { > $ssh->send("yes\r"); > } > > elsif ($ssh->match() =~ m/Password:/ ) { > $ssh->send("mypassword\n"); > } > > > #$ssh->log_file($filename, 'w'); > $ssh->expect(60, '$'); > $ssh->send("su - root\n"); > $ssh->expect(60, 'Password:'); > $ssh->send("rootpassword\n"); > $ssh->expect(60, '#'); > $ssh->send("passwd amagana\n"); > $ssh->expect(60, 'New Password:'); > $ssh->send("mynewpassword\n"); > $ssh->expect(60, 'Re-enter new Password:'); > $ssh->send("mynewpassword\n"); > $ssh->expect(60, '#'); > $ssh->close(); > > > > > > > > > > > > > > > > > > > > > > > //SIGNED// > > Andy Maga?a > UNIX Systems Administrator > Diligent Contractor, 72nd Air Base Wing > Tinker Air Force Base, Oklahoma > Commercial: (405) 734-0341 > > > -----Original Message----- > From: mike nicholas [mailto:xmikenicholasx at gmail.com] > Sent: Wednesday, April 01, 2015 9:46 AM > To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT > Cc: ESRY JR., DON; Matt Zagrabelny; expectperl- > discuss at lists.sourceforge.net > Subject: Re: [Expectperl-discuss] expect.pm not updating password > > Try something like this: > > my $exp = new Expect; > > $exp->log_stdout(1); > > $username = "XXXXXX"; > > $exp->spawn( "ssh -l ${username} ${ip} " ) or die "cannot spawn > $command: $! \n"; > > $exp->log_file("./${log_dir}/$ip\_info.log"); > > print "\nspawning ssh connection to $ip on $time\n\n"; > > $exp->log_file->print( "\nspawning ssh connection to $ip on > $time\n\n" ); > > $exp->expect(8, > > [ 'connecting' => sub { $exp->send("yes \n"); exp_continue; } ], > > [ 'assword:' => sub { $exp->send("$pw\n"); exp_continue; } ], > > [ '-re', '> ?$' => sub { break; }], > > [ 'try again' => sub { die " died from bad password.\n"; }], > > [ 'refused' => sub { die " died from connection refused.\n"; > exp_continue; } ], > > [ eof => sub { die " died from eof.\n"; }], > > [ timeout => sub { $exp->hard_close(); }], > > ); > > > On Wed, Apr 1, 2015 at 9:24 AM, MAGANA, ANDREAS S I CTR USAF > AFMC 72 ABW/SCOOT wrote: > > > Now that I have a working script and thanks very much to you > Matt and Don, > > I am trying to put in my script an if else because sometimes my > script will encounter this : > > Are you sure you want to continue connecting (yes/no)?') > > > > what I did create are some variables is this correct and may I see > an example if statement so that the script can make a decision and keep > going? > > use Expect; > my $knownhost = $ssh->expect(60, 'Are you sure you want to > continue connecting (yes/no)?'); > my $answer = $ssh->send("yes\n"); > my $filename = "/var/tmp/expect_script.log"; > > > > //SIGNED// > > Andy Maga?a > UNIX Systems Administrator > Diligent Contractor, 72nd Air Base Wing > Tinker Air Force Base, Oklahoma > Commercial: (405) 734-0341 > > > -----Original Message----- > From: ESRY JR., DON [mailto:de3253 at att.com] > Sent: Tuesday, March 31, 2015 4:16 PM > To: Matt Zagrabelny; MAGANA, ANDREAS S I CTR USAF AFMC 72 > ABW/SCOOT > Cc: expectperl-discuss at lists.sourceforge.net > > Subject: RE: [Expectperl-discuss] expect.pm not updating > password > > I think you will want a log file to identify where the script failed. > > I recommend that you take out the 'w' from the $ssh- > >log_file($filename, 'w'); so it will append to the file rather than over writing > it for each server. > > And then put in some sort of header for each server, something > like: > my $header = "\n\n======= $system =======\n"; $ssh- > >print_log_file($header); > > Or if you prefer a separate file for each server, then my > $filename = "/var/tmp/expect_script_". $system ".log"; > > little stuff like this can be very frustrating. > > > -----Original Message----- > From: Matt Zagrabelny [mailto:mzagrabe at d.umn.edu] > Sent: Tuesday, March 31, 2015 4:56 PM > To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT > Cc: expectperl-discuss at lists.sourceforge.net > Subject: Re: [Expectperl-discuss] expect.pm not updating > password > > On Tue, Mar 31, 2015 at 3:37 PM, MAGANA, ANDREAS S I CTR > USAF AFMC 72 ABW/SCOOT wrote: > > Thank you Matt, > > > > I just don't know how to put it in a working way I learn by > examples I > > am a novice on perl and the modules. > > Maybe spend a day or two writing some basic perl programs so > you feel more comfortable with this stuff. I'm sure there are truckloads of > perl tutorials out there. > > I added some context below. You'll need to clean up the leading > '>' characters. > > -m > > > > > > #!/usr/bin/perl > > use strict; > > > > use Expect; > > > > # my @servers = qw( > > # server1.example.net > > # server2.example.net > > # server3.example.net > > # server4.example.net > > # server5.example.net > > # ); > > # > > # for my $server (@servers) { > > # # do your thing with $server > > change_password($server); > > > # } > > > > sub change_password { > my $system = shift; > > my $filename = "/var/tmp/expect_script.log"; > my $ssh = Expect->new('ssh amagana@' . $system); > > > > $ssh->debug(1); > > $ssh->log_file($filename, 'w'); > > $ssh->expect(60, 'Password:'); > > $ssh->send("mycurrentpassword\n"); > > $ssh->expect(60, '$'); > > $ssh->send("su - root\n"); > > $ssh->expect(60, 'Password:'); > > $ssh->send("myrootpassword\n"); > > $ssh->expect(60, '#'); > > $ssh->send("passwd amagana\n"); > > $ssh->expect(60, 'New Password:'); > > $ssh->send("mynewpassword\n"); > > $ssh->expect(60, 'Re-enter new Password:'); > > $ssh->send("mynewpassword\n"); $ssh->expect(60, '#'); > > $ssh->send("exit\n"); $ssh->close(); > > } > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel > Website, sponsored > by Intel and developed in partnership with Slashdot Media, is > your hub for all > things parallel software development, from weekly thought > leadership blogs to > news, videos, case studies, tutorials and more. Take a look and > join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Expectperl-discuss mailing list > Expectperl-discuss at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/expectperl-discuss > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel > Website, sponsored > by Intel and developed in partnership with Slashdot Media, is > your hub for all > things parallel software development, from weekly thought > leadership blogs to > news, videos, case studies, tutorials and more. Take a look and > join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Expectperl-discuss mailing list > Expectperl-discuss at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/expectperl-discuss > > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From noloader at gmail.com Mon Apr 6 21:58:22 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 6 Apr 2015 17:58:22 -0400 Subject: [openssl-users] openssl is flexible when verifying In-Reply-To: References: Message-ID: On Mon, Apr 6, 2015 at 2:42 PM, Yuting Chen wrote: > As Jeffrey Walton's comment, the standard is > very malleable, making cert path validation a > little unpredictable. > Generally speaking, RFC 6125 is used to validate a PKIX certificate. Unfortunately, the RFC does not mention AKIs and SKIs. As far as validations go, they do not exist. So the validation steps have to be synthesized from RFC 5280. I think it also means anything goes as far as validating the AKIs and SKIs. PKI is the wild, wild, west. Jeff From drueter at assyst.com Tue Apr 7 00:11:22 2015 From: drueter at assyst.com (David Rueter) Date: Mon, 6 Apr 2015 17:11:22 -0700 Subject: [openssl-users] Disable SSL3 and enable TLS1? / Ambiguous "DES-CBC3-SHA" Message-ID: <1c5a01d070c7$61d6bc10$25843430$@assyst.com> I would like to disable SSL3 (to prevent POODLE attacks), but I would like to leave TLS1 enabled (particularly DES-CBC3-SHA, AES128-SHA and AES256-SHA). However disabling SSL3 with !SSLv3 disables TLSv1 also. Furthermore, disabling SSL3 with -SSLv3 then adding in individual ciphers such as +DES-CBC3-SHA seems to re-enable SSLv3. In looking at https://www.openssl.org/docs/apps/ciphers.html it looks like SSL_RSA_WITH_3DES_EDE_CBC_SHA and TLS_RSA_WITH_3DES_EDE_CBC_SHA are both referred to as DES-CBC3-SHA. Is this intentional? Are not SSL_RSA_WITH_3DES_EDE_CBC_SHA and TLS_RSA_WITH_3DES_EDE_CBC_SHA different ciphers? Is there no way to disable SSL3 while leaving TLS_RSA_WITH_3DES_EDE_CBC_SHA enabled? -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.arivazhagan at gmail.com Tue Apr 7 01:44:35 2015 From: james.arivazhagan at gmail.com (James) Date: Tue, 7 Apr 2015 07:14:35 +0530 Subject: [openssl-users] Disable SSL3 and enable TLS1? / Ambiguous "DES-CBC3-SHA" In-Reply-To: <1c5a01d070c7$61d6bc10$25843430$@assyst.com> References: <1c5a01d070c7$61d6bc10$25843430$@assyst.com> Message-ID: Hi, Can you try this option SSL_CTX_set_options(m_SslCtx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3); instead of disabling using the cipher list regards, James Arivazhagan On Tue, Apr 7, 2015 at 5:41 AM, David Rueter wrote: > I would like to disable SSL3 (to prevent POODLE attacks), but I would like > to leave TLS1 enabled (particularly DES-CBC3-SHA, AES128-SHA and > AES256-SHA). > > > > However disabling SSL3 with !SSLv3 disables TLSv1 also. Furthermore, > disabling SSL3 with -SSLv3 then adding in individual ciphers such as > +DES-CBC3-SHA seems to re-enable SSLv3. > > > > In looking at https://www.openssl.org/docs/apps/ciphers.html it looks > like SSL_RSA_WITH_3DES_EDE_CBC_SHA and TLS_RSA_WITH_3DES_EDE_CBC_SHA are > both referred to as DES-CBC3-SHA. > > > > Is this intentional? Are not SSL_RSA_WITH_3DES_EDE_CBC_SHA and > TLS_RSA_WITH_3DES_EDE_CBC_SHA different ciphers? > > > > Is there no way to disable SSL3 while leaving > TLS_RSA_WITH_3DES_EDE_CBC_SHA enabled? > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From drueter at assyst.com Tue Apr 7 01:58:25 2015 From: drueter at assyst.com (David Rueter) Date: Mon, 6 Apr 2015 18:58:25 -0700 Subject: [openssl-users] Disable SSL3 and enable TLS1? / Ambiguous "DES-CBC3-SHA" In-Reply-To: References: <1c5a01d070c7$61d6bc10$25843430$@assyst.com> Message-ID: <1ca301d070d6$567c8de0$0375a9a0$@assyst.com> James, thanks for the reply. At this point I am using compiled Windows binaries, and am running a compiled Windows application that uses the SSL DLLs. The Windows application does let me specify a cipher list, but I do not have source to that application to re-build. I don?t think that in this situation I am able to call SSL_CTX_set_options. I guess I might be stuck if I can?t use the cipher list to disable SSL3 while leaving TLS1 enabled. Not the end of the world, but not ideal. Sincerely, David Rueter From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of James Sent: Monday, April 06, 2015 6:45 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Disable SSL3 and enable TLS1? / Ambiguous "DES-CBC3-SHA" Hi, Can you try this option SSL_CTX_set_options(m_SslCtx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3); instead of disabling using the cipher list regards, James Arivazhagan On Tue, Apr 7, 2015 at 5:41 AM, David Rueter > wrote: I would like to disable SSL3 (to prevent POODLE attacks), but I would like to leave TLS1 enabled (particularly DES-CBC3-SHA, AES128-SHA and AES256-SHA). However disabling SSL3 with !SSLv3 disables TLSv1 also. Furthermore, disabling SSL3 with -SSLv3 then adding in individual ciphers such as +DES-CBC3-SHA seems to re-enable SSLv3. In looking at https://www.openssl.org/docs/apps/ciphers.html it looks like SSL_RSA_WITH_3DES_EDE_CBC_SHA and TLS_RSA_WITH_3DES_EDE_CBC_SHA are both referred to as DES-CBC3-SHA. Is this intentional? Are not SSL_RSA_WITH_3DES_EDE_CBC_SHA and TLS_RSA_WITH_3DES_EDE_CBC_SHA different ciphers? Is there no way to disable SSL3 while leaving TLS_RSA_WITH_3DES_EDE_CBC_SHA enabled? _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Apr 7 02:44:13 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 7 Apr 2015 02:44:13 +0000 Subject: [openssl-users] Disable SSL3 and enable TLS1? / Ambiguous "DES-CBC3-SHA" In-Reply-To: <1c5a01d070c7$61d6bc10$25843430$@assyst.com> References: <1c5a01d070c7$61d6bc10$25843430$@assyst.com> Message-ID: <20150407024413.GB17637@mournblade.imrryr.org> On Mon, Apr 06, 2015 at 05:11:22PM -0700, David Rueter wrote: > I would like to disable SSL3 (to prevent POODLE attacks), but I would like > to leave TLS1 enabled (particularly DES-CBC3-SHA, AES128-SHA and > AES256-SHA). You're confusing SSLv3 the protocol, with SSLv3 ciphersuites. To disable the protocol set "SSL_OP_NO_SSLv3" via SSL_CTX_set_options(). > Is there no way to disable SSL3 while leaving TLS_RSA_WITH_3DES_EDE_CBC_SHA > enabled? Yes, disable the protocol, not the ciphers. -- Viktor. From james.arivazhagan at gmail.com Tue Apr 7 04:55:08 2015 From: james.arivazhagan at gmail.com (James) Date: Tue, 7 Apr 2015 10:25:08 +0530 Subject: [openssl-users] Disable SSL3 and enable TLS1? / Ambiguous "DES-CBC3-SHA" In-Reply-To: <20150407024413.GB17637@mournblade.imrryr.org> References: <1c5a01d070c7$61d6bc10$25843430$@assyst.com> <20150407024413.GB17637@mournblade.imrryr.org> Message-ID: Hi, Some time back, to fix POODLE, I tried to fix with cipher suite, but still I can use the the protocol SSLv3. The server responds with openssl s_client -connect ip:port -ssl3 So The fix should come using SSL_CTX_set_options. I understand since you are using the compiled binary, you may not be in a position to use this API. May be you can try with the latest version of openssl with the POODLE fix. regards, James On Tue, Apr 7, 2015 at 8:14 AM, Viktor Dukhovni wrote: > On Mon, Apr 06, 2015 at 05:11:22PM -0700, David Rueter wrote: > > > I would like to disable SSL3 (to prevent POODLE attacks), but I would > like > > to leave TLS1 enabled (particularly DES-CBC3-SHA, AES128-SHA and > > AES256-SHA). > > You're confusing SSLv3 the protocol, with SSLv3 ciphersuites. To disable > the protocol set "SSL_OP_NO_SSLv3" via SSL_CTX_set_options(). > > > Is there no way to disable SSL3 while leaving > TLS_RSA_WITH_3DES_EDE_CBC_SHA > > enabled? > > Yes, disable the protocol, not the ciphers. > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Apr 7 08:30:32 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 07 Apr 2015 10:30:32 +0200 Subject: [openssl-users] removing compression? In-Reply-To: <8a72356eae914fa6bc7c512ea1337b34@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <55200B77.5060204@gmx.net> <8a72356eae914fa6bc7c512ea1337b34@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <552395A8.1010500@wisemo.com> On 05/04/2015 02:06, Salz, Rich wrote: >> by randomly interspersing flush commands into the data stream (description >> and example implementation https://github.com/wnyc/breach_buster)? >> It's not perfect but for some use cases better than having no compression at >> all. > Flushing the stream seems like an application-level thing to do, and not something openssl generally does. > > It might be better than having no compression at all, the question is do we need compression in openssl at all? :) "Flushing the zlib stream" is a call to the zlib library, which causes the insertion of extra bits in the compressed stream. It can only be done by the layer that actually calls zlib, in this case OpenSSL. This is especially true, when (as a critical aspect of this side channel mitigation) the other parts of the SSL stream (record splitting, TCP buffering) is intentionally NOT flushed. Thus the point is that by having the code that directly calls zlib (in this case OpenSSL) randomly telling zlib to flush through data into completed zlib-layer records, then bundling together the compressed stream into the same TLS record, the length and compressibility of the plaintext is masked from observers looking at the TLS record sizes, thereby mitigating or even blocking the CRIME attack family. To avoid simply forcing the attacker to generate more transmissions with each chosen plaintext portion, the randomization should be deterministic for any given uncompressed plaintext, yet highly unpredictable for anyone without access to the OpenSSL internal state, even across load-balanced processes. So perhaps the randomization should be keyed by a MAC of the plaintext, which is in turn keyed by site constant values, such as (for servers) the complete set of loaded private keys and certificates, or (for clients) various local secrets or a random value persisted on first run and reused thereafter. An open issue is how to design the randomization so it also stops attackers who try multiple similar chosen plaintext strings for each desired probe of the secret plaintext, and then apply statistical methods to filter out our masking noise. Adding equivalent code in a HTTP library would similarly mitigate/block the BREACH attack family. At the protocol level, the definition of deflate compression causes all the generated variant streams to be equivalent representations of the same uncompressed plaintext, thus there is no protocol visible change, just deliberate compression inefficiency. Conceptually, this is somewhat similar to the 1/N-1 record splitting used to mitigate IV chaining attacks in TLS 1.0 CBC encryption. A completely alternative technique, not limited to compressed streams, could be to randomly vary the exact number of padding bytes within the typically 4 bit) range permitted by the protocol, but this would be limited to CBC mode encryption, not being available for stream and GCM encryptions. 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 From olivier.szika at stormshield.eu Tue Apr 7 10:31:55 2015 From: olivier.szika at stormshield.eu (Olivier SZIKA) Date: Tue, 7 Apr 2015 12:31:55 +0200 (CEST) Subject: [openssl-users] Corrupted ssl session id In-Reply-To: <313422085.27486398.1428402589281.JavaMail.zimbra@stormshield.eu> Message-ID: <2035207167.27487748.1428402715723.JavaMail.zimbra@stormshield.eu> Hi all, I use openssl library in a daemon, and there are a lot of crashes around ssl session management. A crash happens when ssl sessions are flushed via SSL_CTX_flush_sessions(), because they could have bad session id. Here, the life of one session: ptr_addr: refcount: type[session_id] (function:line) 0x807807600: 1:SSL_SESSION [0x0] (SSL_SESSION_new:205) 0x807807600: 1:--> SSL_SESSION CHECK BEFORE [0x0] (ssl3_get_new_session_ticket:2236) 0x807807600: 1:--> SSL_SESSION CHECK AFTER [0xaa685c61] (ssl3_get_new_session_ticket:2244) 0x807807600: 2:SSL_SESSION [0xaa685c61] (SSL_CTX_add_session:673) 0x807807600: 3:SSL_SESSION [0xaa685c61] (ssl_update_cache:2456) 0x807807600: 2:SSL_SESSION_FREE [0xaa685c61] (SSL_free:559) 0x807807600: 3:SSL_SESSION [0xaa685c61] (SSL_set_session:855) 0x807807600: 3:--> SSL_SESSION CHECK BEFORE [0xaa685c61] (ssl3_client_hello:731) 0x807807600: 3:--> SSL_SESSION CHECK AFTER [0xaa685c61] (ssl3_client_hello:733) 0x807807600: 3:--> SSL_SESSION CHECK BEFORE [0xaa685c61] (ssl3_get_new_session_ticket:2236) 0x807807600: 3:--> SSL_SESSION CHECK AFTER [0xe47912b1] (ssl3_get_new_session_ticket:2244) 0x807807600: 2:SSL_SESSION_FREE [0xe47912b1] (SSL_free:559) ... The server requests new session ticket (SSL3_ST_CR_SESSION_TICKET_[AB]), but the session id is already initialized. To fix it, I thought to free the old ssl session and to create a new one in ssl3_connect(), in case SSL3_ST_CR_SESSION_TICKET_[AB], before ssl3_get_new_session_ticket() call, but I'm not sure it's a good fix. Could you help me? Do you need more details about my issue? Thanks, Olivier From John.Unsworth at owmessaging.com Tue Apr 7 11:15:03 2015 From: John.Unsworth at owmessaging.com (John Unsworth) Date: Tue, 7 Apr 2015 11:15:03 +0000 Subject: [openssl-users] Include files location in 1.0.2a Message-ID: I build openssl as static libraries that are then included in applications. Up till 1.0.2 all the include files have been in one directory so building the applications just involved using the single include folder, which I copied from the openssl build, and the openssl static libraries. However in 1.0.2a the files in include are just redirects to the real include files that are scattered all over the place. This means that I will have to locate and assemble them into a single include directory again unless I want to build against a complete preserved openssl build structure which would take up too much space (4 platforms release, plus debug for windows, for 32 and 64 bit so 10 builds). Am I missing something? John. -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Unsworth at owmessaging.com Tue Apr 7 12:14:41 2015 From: John.Unsworth at owmessaging.com (John Unsworth) Date: Tue, 7 Apr 2015 12:14:41 +0000 Subject: [openssl-users] Include files location in 1.0.2a In-Reply-To: References: Message-ID: Sorry, my fault. I wasn't following the instructions which tells me to look in the "prefix" tree and there are all the include files nicely together again. Apologies for time wasting. John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Unsworth Sent: 07 April 2015 12:15 To: openssl-users at openssl.org Subject: [openssl-users] Include files location in 1.0.2a I build openssl as static libraries that are then included in applications. Up till 1.0.2 all the include files have been in one directory so building the applications just involved using the single include folder, which I copied from the openssl build, and the openssl static libraries. However in 1.0.2a the files in include are just redirects to the real include files that are scattered all over the place. This means that I will have to locate and assemble them into a single include directory again unless I want to build against a complete preserved openssl build structure which would take up too much space (4 platforms release, plus debug for windows, for 32 and 64 bit so 10 builds). Am I missing something? John. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amiralex32 at gmail.com Tue Apr 7 12:49:34 2015 From: amiralex32 at gmail.com (Amir Reda) Date: Tue, 7 Apr 2015 14:49:34 +0200 Subject: [openssl-users] AES-GCM processing time Message-ID: dear all i am using Authenticated Encryption AES-GCM. i am trying to calculate the processing time for encrypting a data message of size 500 byte clock_t startEncryption, endEncryption; double msecs1; startEncryption = clock(); unsigned char plaintext[500] = {'f','a','3','1','3','2','2','5','f','8','8','4','0','6','e','5','a','5','5','9','0','9','c','5','a','f','f','5','2','6','9','a','8','6','a','7','a','9','5','3','1','5','3','4','f','7','d','a','2','e','4','c','3','0','3','d','8','a','3','1','8','a','7','2','1','c','3','c','0','c','9','5','9','5','6','8','0','9','5','3','2','f','c','f','0','e','2','4','4','9','a','6','b','5','2','5','b','1','6','a','e','d','f','5','a','a','0','d','e','6','5','7','b','a','6','3','7','b','3','9','f','a','3','1','3','2','2','5','f','8','8','4','0','6','e','5','a','5','5','9','0','9','c','5','a','f','f','5','2','6','9','a','8','6','a','7','a','9','5','3','1','5','3','4','f','7','d','a','2','e','4','c','3','0','3','d','8','a','3','1','8','a','7','2','1','c','3','c','0','c','9','5','9','5','6','8','0','9','5','3','2','f','c','f','0','e','2','4','4','9','a','6','b','5','2','5','b','1','6','a','e','d','f','5','a','a','0','d','e','6','5','7','b','a','6','3','7','b','3','9', 'f','a','3','1','3','2','2','5','f','8','8','4','0','6','e','5','a','5','5','9','0','9','c','5','a','f','f','5','2','6','9','a','8','6','a','7','a','9','5','3','1','5','3','4','f','7','d','a','2','e','4','c','3','0','3','d','8','a','3','1','8','a','7','2','1','c','3','c','0','c','9','5','9','5','6','8','0','9','5','3','2','f','c','f','0','e','2','4','4','9','a','6','b','5','2','5','b','1','6','a','e','d','f','5','a','a','0','d','e','6','5','7','b','a','6','3','7','b','3','9' ,'f','a','3','1','3','2','2','5','f','8','8','4','0','6','e','5','a','5','5','9','0','9','c','5','a','f','f','5','2','6','9','a','8','6','a','7','a','9','5','3','1','5','3','4','f','7','d','a','2','e','4','c','3','0','3','d','8','a','3','1','8','a','7','2','1','c','3','c','0','c','9','5','9','5','6','8','0','9','5','3','2','f','c','f','0','e','2','4','4','9','a','6','b','5','2','5','b','1','6','a','e','d','f','5','a','a','0','d','e','6','5','7','b','a','6','3','7','b','3','9' ,'f','a','3','1','3','2','2','5','f','8','8','4','0','6','e','5','a','5','5','9'}; unsigned char key [32] = {'f','e','f','f','e',9,9,2,8,6,6,5,7,3,1,'c',6,'d',6,'a',8,'f',9,4,6,7,3,0,8,3,0,8}; //unsigned char key [48] = "000000000000000000000000"; unsigned char aad[8] = {'f','e','e','d','f','a','c','e'}; //unsigned char iv[24] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; unsigned char iv[16] = {9,3,1,3,2,2,5,'d','f',8,8,4,0,6,'e',5}; unsigned char cipher[500]; unsigned char tag[16]; unsigned char extractedpalintext[500]; int encryptionsize = 0; encryptionsize = servertest.AuthenticationEncryption(plaintext,500,aad,8,key,32,iv,16,cipher,tag); servertest.AuthenticationDecryption(cipher,500,aad,8,tag,key,32,iv,16,extractedpalintext); servertest.AuthenticationDecryption(cipher,120,fakeaad,40,tag,key,32,iv,120,extractedpalintext); endEncryption = clock(); msecs1 = ((double) (endEncryption - startEncryption)) * 1000000.0 / CLOCKS_PER_SEC; cout<<"time for encryption "<< " start "< 0) { cout<<"success final decryption"< From rsalz at akamai.com Tue Apr 7 12:52:43 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 7 Apr 2015 12:52:43 +0000 Subject: [openssl-users] removing compression? In-Reply-To: <552395A8.1010500@wisemo.com> References: <55200B77.5060204@gmx.net> <8a72356eae914fa6bc7c512ea1337b34@ustx2ex-dag1mb2.msg.corp.akamai.com> <552395A8.1010500@wisemo.com> Message-ID: <4a138429210c497a931ea56ad8edfa69@ustx2ex-dag1mb2.msg.corp.akamai.com> Jakob, Thanks very much for the detailed response! I'm still not convinced that tls-layer compression is a good thing. You seem to be saying it could possibly be made to work, but ... do I have that view right? -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From Michael.Wojcik at microfocus.com Tue Apr 7 13:08:11 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 7 Apr 2015 13:08:11 +0000 Subject: [openssl-users] AES-GCM processing time In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Amir Reda > Sent: Tuesday, April 07, 2015 08:50 > i am using Authenticated Encryption AES-GCM. i am trying to calculate the processing time for encrypting a data > message of size 500 byte You'll need a pretty high-resolution timer to time encrypting 500 bytes. >??? startEncryption = clock(); The C library function clock() does not provide a high-resolution timer. In fact, it doesn't provide a timer at all. Consult the documentation, or, better, the C standard (ISO 9899). > this made the processing time is 0 msec No, because "processing time" is not what clock() returns, and a zero difference doesn't mean "no time elapsed". You need to consult the documentation for your platform to determine what high-resolution timers are available. Even with that, however, your test design is largely useless, because what you're trying to measure will be swamped by environmental effects (unless you're running on in an extremely restricted platform, like a single-task embedded system). At the very least, you need to measure many encryptions and take the average. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com From rsalz at akamai.com Tue Apr 7 13:11:16 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 7 Apr 2015 13:11:16 +0000 Subject: [openssl-users] AES-GCM processing time In-Reply-To: References: Message-ID: <2262d85fc4ab4c989e1fbb47de4c43ad@ustx2ex-dag1mb2.msg.corp.akamai.com> > At the > very least, you need to measure many encryptions and take the average. +1 Also look at the openssl speed app. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From drueter at assyst.com Tue Apr 7 15:09:31 2015 From: drueter at assyst.com (David Rueter) Date: Tue, 7 Apr 2015 08:09:31 -0700 Subject: [openssl-users] Disable SSL3 and enable TLS1? / Ambiguous "DES-CBC3-SHA" In-Reply-To: <20150407024413.GB17637@mournblade.imrryr.org> References: <1c5a01d070c7$61d6bc10$25843430$@assyst.com> <20150407024413.GB17637@mournblade.imrryr.org> Message-ID: <1da201d07144$da52aaf0$8ef800d0$@assyst.com> >> You're confusing SSLv3 the protocol, with SSLv3 ciphersuites. Yes, I admit I am not distinguishing between these. However, !SSLv3 in the cipher list does evidently disable the SSLv3 protocol as well--as evidenced by testing with https://www.ssllabs.com/ssltest Since I don't have source for the application I can only control OpenSSL's behavior through the cypher list. I guess I will have to choose between leaving SSLv3 enabled and breaking Android and IE on XP users (that require TLSv1). >From the symptoms, it sure seems like OpenSSL mistakenly uses the string "DES-CBC3-SHA" to refer to both TLS and SSL3 (see https://www.openssl.org/docs/apps/ciphers.html ) Is this really intentional? In other words, is the SSLv3 cipher SSL_RSA_WITH_3DES_EDE_CBC_SHA actually the same as the TLS cipher TLS_RSA_WITH_DES_CBC_SHA? -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Monday, April 06, 2015 7:44 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Disable SSL3 and enable TLS1? / Ambiguous "DES-CBC3-SHA" On Mon, Apr 06, 2015 at 05:11:22PM -0700, David Rueter wrote: > I would like to disable SSL3 (to prevent POODLE attacks), but I would > like to leave TLS1 enabled (particularly DES-CBC3-SHA, AES128-SHA and > AES256-SHA). You're confusing SSLv3 the protocol, with SSLv3 ciphersuites. To disable the protocol set "SSL_OP_NO_SSLv3" via SSL_CTX_set_options(). > Is there no way to disable SSL3 while leaving > TLS_RSA_WITH_3DES_EDE_CBC_SHA enabled? Yes, disable the protocol, not the ciphers. -- Viktor. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From openssl-users at dukhovni.org Tue Apr 7 15:31:54 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 7 Apr 2015 15:31:54 +0000 Subject: [openssl-users] Disable SSL3 and enable TLS1? / Ambiguous "DES-CBC3-SHA" In-Reply-To: <1da201d07144$da52aaf0$8ef800d0$@assyst.com> References: <1c5a01d070c7$61d6bc10$25843430$@assyst.com> <20150407024413.GB17637@mournblade.imrryr.org> <1da201d07144$da52aaf0$8ef800d0$@assyst.com> Message-ID: <20150407153154.GF17637@mournblade.imrryr.org> On Tue, Apr 07, 2015 at 08:09:31AM -0700, David Rueter wrote: > >> You're confusing SSLv3 the protocol, with SSLv3 ciphersuites. > > Yes, I admit I am not distinguishing between these. However, !SSLv3 in the > cipher list does evidently disable the SSLv3 protocol as well--as evidenced > by testing with https://www.ssllabs.com/ssltest When there are no SSLv3 ciphers left, the protocol is not offerred, but this also disables TLSv1 and TLSv1.1 as they use the same set of ciphers. > From the symptoms, it sure seems like OpenSSL mistakenly uses the string > "DES-CBC3-SHA" to refer to both TLS and SSL3 (see > https://www.openssl.org/docs/apps/ciphers.html ) There is no mistake. The same cipher-suite: DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 applies to SSLv3, TLSv1, TLSv1.1 and TLSv1.2. > intentional? In other words, is the SSLv3 cipher > SSL_RSA_WITH_3DES_EDE_CBC_SHA actually the same as the TLS cipher > TLS_RSA_WITH_[3]DES_[EDE_]CBC_SHA? Yes, they are one and the same (SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2): RFC 6101: CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; RFC 2246: CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; RFC 4346: CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; RFC 5246: CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; As for: CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; it is not triple DES, it is single-DES, and corresponds (RFC 6101) to: CipherSuite SSL_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; which OpenSSL calls: DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 -- Viktor. From jb-openssl at wisemo.com Tue Apr 7 16:49:55 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 07 Apr 2015 18:49:55 +0200 Subject: [openssl-users] removing compression? In-Reply-To: <4a138429210c497a931ea56ad8edfa69@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <55200B77.5060204@gmx.net> <8a72356eae914fa6bc7c512ea1337b34@ustx2ex-dag1mb2.msg.corp.akamai.com> <552395A8.1010500@wisemo.com> <4a138429210c497a931ea56ad8edfa69@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <55240AB3.50602@wisemo.com> On 07/04/2015 14:52, Salz, Rich wrote: > Jakob, > > Thanks very much for the detailed response! I'm still not convinced that tls-layer compression is a good thing. You seem to be saying it could possibly be made to work, but ... do I have that view right? I was merely trying to explain Thomas Tanner's suggestion for how to protect TLS compression against the (mostly HTTPS specific) attacks. However, as has been hinted at by others, TLS layer compression appears to be both useful and harmless for protocols that do not have the higher level properties that allow the CRIME/BREACH attacks. Specifically a small secret near a slightly longer chosen plaintext, surrounded by a lot of known plaintext, plus the ability to provoke a medium number of sessions each varying almost exclusively in the chosen plaintext. It also appears the HTTP/2.0 draft aka SPDY requires compressionto be enabled, though I don't know if that is at the TLS or HTTP level. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Apr 7 16:57:23 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 07 Apr 2015 18:57:23 +0200 Subject: [openssl-users] Disable SSL3 and enable TLS1? / Ambiguous "DES-CBC3-SHA" In-Reply-To: <1da201d07144$da52aaf0$8ef800d0$@assyst.com> References: <1c5a01d070c7$61d6bc10$25843430$@assyst.com> <20150407024413.GB17637@mournblade.imrryr.org> <1da201d07144$da52aaf0$8ef800d0$@assyst.com> Message-ID: <55240C73.6030808@wisemo.com> On 07/04/2015 17:09, David Rueter wrote: >>> You're confusing SSLv3 the protocol, with SSLv3 ciphersuites. > Yes, I admit I am not distinguishing between these. However, !SSLv3 in the > cipher list does evidently disable the SSLv3 protocol as well--as evidenced > by testing with https://www.ssllabs.com/ssltest > > Since I don't have source for the application I can only control OpenSSL's > behavior through the cypher list. I guess I will have to choose between > leaving SSLv3 enabled and breaking Android and IE on XP users (that require > TLSv1). Is OpenSSL in its own DLL/DLLs? If so, could you simply recompile OpenSSL (at latestpatchlevel) without the SSL3 protocol? This would also provide all the other security fixes that have been added to OpenSSL since someone gave you the program. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From h15234 at mailas.com Tue Apr 7 17:02:30 2015 From: h15234 at mailas.com (h15234 at mailas.com) Date: Tue, 07 Apr 2015 10:02:30 -0700 Subject: [openssl-users] openssl 1.0.2 shared build's linking is not consistent - bin and libs linked to different libcrypto.so's In-Reply-To: <1426605729.1719828.241558337.16F10CB8@webmail.messagingengine.com> References: <1426605729.1719828.241558337.16F10CB8@webmail.messagingengine.com> Message-ID: <1428426150.4021554.250348757.570FA0B1@webmail.messagingengine.com> bump On Tue, Mar 17, 2015, at 08:22 AM, h15234 at mailas.com wrote: > I'm trying to build a library self-consistent instance of openssl 1.0.2 on linux/64. > > Setting *FLAGS & rpath, although the openssl binary links correctly against its own {libcrypto,libssl}.so, the libssl.so links against *system*, not its own, libcrypto. > > I've tried a bunch of combinations of *FLAGS. Always the same result. The current env/result is: > > cd ./openssl-1.0.2 > > export SHARED_LDFLAGS="-L/usr/local/sslTEST/lib64 -Wl,-rpath,/usr/local/sslTEST/lib64 -lssl -lcrypto" > export LDFLAGS=${SHARED_LDFLAGS} > export LIBDEPS=${SHARED_LDFLAGS} > > > ./config \ > --openssldir=/usr/local/sslTEST \ > --libdir=lib64 \ > threads shared zlib \ > enable-ec_nistp_64_gcc_128 \ > no-idea \ > no-ssl2 \ > no-rc5 \ > no-mdc2 \ > no-hw \ > no-ec2m \ > enable-rfc3779 > > make depend > make > make install > > There are no apparent errors in the build output. > > The build results in > > /usr/local/sslTEST/bin/openssl version > OpenSSL 1.0.2 22 Jan 2015 > > ldd \ > /usr/local/sslTEST/bin/openssl \ > /usr/local/sslTEST/lib64/libssl.so.1.0.0 \ > /usr/local/sslTEST/lib64/libcrypto.so.1.0.0 > > /usr/local/sslTEST/bin/openssl: > linux-vdso.so.1 (0x00007ffefffd7000) > libssl.so.1.0.0 => /usr/local/sslTEST/lib64/libssl.so.1.0.0 (0x00007f93cbe0e000) > !! libcrypto.so.1.0.0 => /usr/local/sslTEST/lib64/libcrypto.so.1.0.0 (0x00007f93cb9ce000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f93cb77f000) > libz.so.1 => /lib64/libz.so.1 (0x00007f93cb569000) > libc.so.6 => /lib64/libc.so.6 (0x00007f93cb1c1000) > /lib64/ld-linux-x86-64.so.2 (0x00007f93cc07a000) > > /usr/local/sslTEST/lib64/libssl.so.1.0.0: > linux-vdso.so.1 (0x00007ffd01636000) > !! libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007ff4abf33000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007ff4abd2f000) > libz.so.1 => /lib64/libz.so.1 (0x00007ff4abb18000) > libc.so.6 => /lib64/libc.so.6 (0x00007ff4ab771000) > /lib64/ld-linux-x86-64.so.2 (0x00007ff4ac60d000) > > /usr/local/sslTEST/lib64/libcrypto.so.1.0.0: > linux-vdso.so.1 (0x00007ffe1f55d000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f9a10f46000) > libz.so.1 => /lib64/libz.so.1 (0x00007f9a10d30000) > libc.so.6 => /lib64/libc.so.6 (0x00007f9a10988000) > /lib64/ld-linux-x86-64.so.2 (0x00007f9a115d5000) > > > where you can see the different libcrypto's are linked. > > What specific combination and settings of FLAGS are required to ensure that the bins & libs are all self-consistently linked/rpath'd only against this build's libs? > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From drueter at assyst.com Tue Apr 7 17:15:31 2015 From: drueter at assyst.com (David Rueter) Date: Tue, 7 Apr 2015 10:15:31 -0700 Subject: [openssl-users] Disable SSL3 and enable TLS1? / Ambiguous "DES-CBC3-SHA" In-Reply-To: <55240C73.6030808@wisemo.com> References: <1c5a01d070c7$61d6bc10$25843430$@assyst.com> <20150407024413.GB17637@mournblade.imrryr.org> <1da201d07144$da52aaf0$8ef800d0$@assyst.com> <55240C73.6030808@wisemo.com> Message-ID: <1e3801d07156$74ae71e0$5e0b55a0$@assyst.com> >> Is OpenSSL in its own DLL/DLLs? Yes, the OpenSSL DLL?s libeay32.dll and ssleay32.dll are used, and in fact I have updated them to 1.0.2a Yes, performing my own build on these DLL?s is an option, and I may pursue it. I just need to get a Windows dev environment set up to build these. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jakob Bohm Sent: Tuesday, April 07, 2015 9:57 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Disable SSL3 and enable TLS1? / Ambiguous "DES-CBC3-SHA" On 07/04/2015 17:09, David Rueter wrote: You're confusing SSLv3 the protocol, with SSLv3 ciphersuites. Yes, I admit I am not distinguishing between these. However, !SSLv3 in the cipher list does evidently disable the SSLv3 protocol as well--as evidenced by testing with https://www.ssllabs.com/ssltest Since I don't have source for the application I can only control OpenSSL's behavior through the cypher list. I guess I will have to choose between leaving SSLv3 enabled and breaking Android and IE on XP users (that require TLSv1). Is OpenSSL in its own DLL/DLLs? If so, could you simply recompile OpenSSL (at latest patchlevel) without the SSL3 protocol? This would also provide all the other security fixes that have been added to OpenSSL since someone gave you the program. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From drueter at assyst.com Tue Apr 7 17:20:32 2015 From: drueter at assyst.com (David Rueter) Date: Tue, 7 Apr 2015 10:20:32 -0700 Subject: [openssl-users] Disable SSL3 and enable TLS1? / Ambiguous "DES-CBC3-SHA" In-Reply-To: <20150407153154.GF17637@mournblade.imrryr.org> References: <1c5a01d070c7$61d6bc10$25843430$@assyst.com> <20150407024413.GB17637@mournblade.imrryr.org> <1da201d07144$da52aaf0$8ef800d0$@assyst.com> <20150407153154.GF17637@mournblade.imrryr.org> Message-ID: <1e5401d07157$28014650$7803d2f0$@assyst.com> Got it! Thanks for the detailed explanation. I did not realize that the same ciphers were used by both SSL3 and TLS1. The behavior now makes all the sense in the world. Thanks! -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Tuesday, April 07, 2015 8:32 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Disable SSL3 and enable TLS1? / Ambiguous "DES-CBC3-SHA" On Tue, Apr 07, 2015 at 08:09:31AM -0700, David Rueter wrote: > >> You're confusing SSLv3 the protocol, with SSLv3 ciphersuites. > > Yes, I admit I am not distinguishing between these. However, !SSLv3 > in the cipher list does evidently disable the SSLv3 protocol as > well--as evidenced by testing with https://www.ssllabs.com/ssltest When there are no SSLv3 ciphers left, the protocol is not offerred, but this also disables TLSv1 and TLSv1.1 as they use the same set of ciphers. > From the symptoms, it sure seems like OpenSSL mistakenly uses the > string "DES-CBC3-SHA" to refer to both TLS and SSL3 (see > https://www.openssl.org/docs/apps/ciphers.html ) There is no mistake. The same cipher-suite: DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 applies to SSLv3, TLSv1, TLSv1.1 and TLSv1.2. > intentional? In other words, is the SSLv3 cipher > SSL_RSA_WITH_3DES_EDE_CBC_SHA actually the same as the TLS cipher > TLS_RSA_WITH_[3]DES_[EDE_]CBC_SHA? Yes, they are one and the same (SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2): RFC 6101: CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; RFC 2246: CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; RFC 4346: CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; RFC 5246: CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; As for: CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; it is not triple DES, it is single-DES, and corresponds (RFC 6101) to: CipherSuite SSL_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; which OpenSSL calls: DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 -- Viktor. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From richmoore44 at gmail.com Tue Apr 7 17:37:38 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Tue, 7 Apr 2015 18:37:38 +0100 Subject: [openssl-users] removing compression? In-Reply-To: <55240AB3.50602@wisemo.com> References: <55200B77.5060204@gmx.net> <8a72356eae914fa6bc7c512ea1337b34@ustx2ex-dag1mb2.msg.corp.akamai.com> <552395A8.1010500@wisemo.com> <4a138429210c497a931ea56ad8edfa69@ustx2ex-dag1mb2.msg.corp.akamai.com> <55240AB3.50602@wisemo.com> Message-ID: On 7 April 2015 at 17:49, Jakob Bohm wrote: > It also appears the HTTP/2.0 draft aka SPDY requires > compression to be enabled, though I don't know if that > is at the TLS or HTTP level. > HTTP/2 does not require TLS compression. It does however use it's own compression for headers (hpack) which is designed to be safe from attacks like CRIME. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Apr 7 18:52:47 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 7 Apr 2015 18:52:47 +0000 Subject: [openssl-users] removing compression? In-Reply-To: <55240AB3.50602@wisemo.com> References: <55200B77.5060204@gmx.net> <8a72356eae914fa6bc7c512ea1337b34@ustx2ex-dag1mb2.msg.corp.akamai.com> <552395A8.1010500@wisemo.com> <4a138429210c497a931ea56ad8edfa69@ustx2ex-dag1mb2.msg.corp.akamai.com> <55240AB3.50602@wisemo.com> Message-ID: Yes, some others have spoken up so compression at the TLS layer will stay. The ability to add new compression methods at run-time is likely to go away. From noloader at gmail.com Tue Apr 7 22:37:17 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 7 Apr 2015 18:37:17 -0400 Subject: [openssl-users] removing compression? In-Reply-To: References: <55200B77.5060204@gmx.net> <8a72356eae914fa6bc7c512ea1337b34@ustx2ex-dag1mb2.msg.corp.akamai.com> <552395A8.1010500@wisemo.com> <4a138429210c497a931ea56ad8edfa69@ustx2ex-dag1mb2.msg.corp.akamai.com> <55240AB3.50602@wisemo.com> Message-ID: On Tue, Apr 7, 2015 at 1:37 PM, Richard Moore wrote: > On 7 April 2015 at 17:49, Jakob Bohm wrote: >> >> It also appears the HTTP/2.0 draft aka SPDY requires >> compression to be enabled, though I don't know if that >> is at the TLS or HTTP level. > > HTTP/2 does not require TLS compression. It does however use it's own > compression for headers (hpack) which is designed to be safe from attacks > like CRIME. A me too: earlier version of SPDY required compression, and user agents had to support it. It seems to still be the case in version 4 (http://mbelshe.github.io/SPDY-Specification/draft-mbelshe-spdy-00.xml). I'm not sure if/how SPDY differs from HTTP/2 (other than I know they are different but aligned). It seems to me the trick to avoid CRMIE-like attacks is to make sure the compression is semantically secure. In the case of CRIME, information should not be gained across different messages (in this case, each message alone was secure - it was the different messages over time that got folks in trouble). But I'm not sure about other attacks on the compression layer. From noloader at gmail.com Wed Apr 8 00:06:41 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 7 Apr 2015 20:06:41 -0400 Subject: [openssl-users] Disable SSL3 and enable TLS1? / Ambiguous "DES-CBC3-SHA" In-Reply-To: <1e3801d07156$74ae71e0$5e0b55a0$@assyst.com> References: <1c5a01d070c7$61d6bc10$25843430$@assyst.com> <20150407024413.GB17637@mournblade.imrryr.org> <1da201d07144$da52aaf0$8ef800d0$@assyst.com> <55240C73.6030808@wisemo.com> <1e3801d07156$74ae71e0$5e0b55a0$@assyst.com> Message-ID: On Tue, Apr 7, 2015 at 1:15 PM, David Rueter wrote: >>> Is OpenSSL in its own DLL/DLLs? > > Yes, the OpenSSL DLL?s libeay32.dll and ssleay32.dll are used, and in fact I > have updated them to 1.0.2a > > Yes, performing my own build on these DLL?s is an option, and I may pursue > it. I just need to get a Windows dev environment set up to build these. You also have the option of using Thomas Hruska's Win32-OpenSSL at https://slproweb.com/products/Win32OpenSSL.html. Thomas makes 1.0.2a available for download on his site. Jeff From rsalz at akamai.com Wed Apr 8 00:12:16 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 8 Apr 2015 00:12:16 +0000 Subject: [openssl-users] removing compression? In-Reply-To: References: <55200B77.5060204@gmx.net> <8a72356eae914fa6bc7c512ea1337b34@ustx2ex-dag1mb2.msg.corp.akamai.com> <552395A8.1010500@wisemo.com> <4a138429210c497a931ea56ad8edfa69@ustx2ex-dag1mb2.msg.corp.akamai.com> <55240AB3.50602@wisemo.com> Message-ID: <71f1bfaf4e4d4a46a64eed1f3718da06@ustx2ex-dag1mb2.msg.corp.akamai.com> > I'm not sure if/how SPDY differs from HTTP/2 (other than I know they are > different but aligned). I Google just turned off spdy for "official" http/2. http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html From noloader at gmail.com Wed Apr 8 02:06:39 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 7 Apr 2015 22:06:39 -0400 Subject: [openssl-users] openssl 1.0.2 shared build's linking is not consistent - bin and libs linked to different libcrypto.so's In-Reply-To: <1426605729.1719828.241558337.16F10CB8@webmail.messagingengine.com> References: <1426605729.1719828.241558337.16F10CB8@webmail.messagingengine.com> Message-ID: > Setting *FLAGS & rpath, although the openssl binary links correctly > against its own {libcrypto,libssl}.so, the libssl.so links against *system*, > not its own, libcrypto. You can verify the RPATHs are actually present by dumping the DT_RUNPATH section of the ELF executable: readelf -d | grep -i RPATH > What specific combination and settings of FLAGS are required to > ensure that the bins & libs are all self-consistently linked/rpath'd only > against this build's libs? As far as I know, you only need an RPATH on Linux (OS X and Android are a different story). Your executable is probably missing it, so the link/loader first loads the system libssl and libcrypto. After that, the link/loader considers the dependency fulfilled and does not load your versions of the libraries. If you can't rebuild the executables, then consider using an LD_LIBRARY_PATH (http://linux.die.net/man/8/ld-linux). To avoid this on all platforms (DLL hell), I just link statically against the OpenSSL libraries. Some consider it blasphemy, I consider it peace of mind. Jeff On Tue, Mar 17, 2015 at 11:22 AM, wrote: > I'm trying to build a library self-consistent instance of openssl 1.0.2 on linux/64. > > Setting *FLAGS & rpath, although the openssl binary links correctly against its own {libcrypto,libssl}.so, the libssl.so links against *system*, not its own, libcrypto. > > I've tried a bunch of combinations of *FLAGS. Always the same result. The current env/result is: > > cd ./openssl-1.0.2 > > export SHARED_LDFLAGS="-L/usr/local/sslTEST/lib64 -Wl,-rpath,/usr/local/sslTEST/lib64 -lssl -lcrypto" > export LDFLAGS=${SHARED_LDFLAGS} > export LIBDEPS=${SHARED_LDFLAGS} > > > ./config \ > --openssldir=/usr/local/sslTEST \ > --libdir=lib64 \ > threads shared zlib \ > enable-ec_nistp_64_gcc_128 \ > no-idea \ > no-ssl2 \ > no-rc5 \ > no-mdc2 \ > no-hw \ > no-ec2m \ > enable-rfc3779 > > make depend > make > make install > > There are no apparent errors in the build output. > > The build results in > > /usr/local/sslTEST/bin/openssl version > OpenSSL 1.0.2 22 Jan 2015 > > ldd \ > /usr/local/sslTEST/bin/openssl \ > /usr/local/sslTEST/lib64/libssl.so.1.0.0 \ > /usr/local/sslTEST/lib64/libcrypto.so.1.0.0 > > /usr/local/sslTEST/bin/openssl: > linux-vdso.so.1 (0x00007ffefffd7000) > libssl.so.1.0.0 => /usr/local/sslTEST/lib64/libssl.so.1.0.0 (0x00007f93cbe0e000) > !! libcrypto.so.1.0.0 => /usr/local/sslTEST/lib64/libcrypto.so.1.0.0 (0x00007f93cb9ce000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f93cb77f000) > libz.so.1 => /lib64/libz.so.1 (0x00007f93cb569000) > libc.so.6 => /lib64/libc.so.6 (0x00007f93cb1c1000) > /lib64/ld-linux-x86-64.so.2 (0x00007f93cc07a000) > > /usr/local/sslTEST/lib64/libssl.so.1.0.0: > linux-vdso.so.1 (0x00007ffd01636000) > !! libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007ff4abf33000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007ff4abd2f000) > libz.so.1 => /lib64/libz.so.1 (0x00007ff4abb18000) > libc.so.6 => /lib64/libc.so.6 (0x00007ff4ab771000) > /lib64/ld-linux-x86-64.so.2 (0x00007ff4ac60d000) > > /usr/local/sslTEST/lib64/libcrypto.so.1.0.0: > linux-vdso.so.1 (0x00007ffe1f55d000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f9a10f46000) > libz.so.1 => /lib64/libz.so.1 (0x00007f9a10d30000) > libc.so.6 => /lib64/libc.so.6 (0x00007f9a10988000) > /lib64/ld-linux-x86-64.so.2 (0x00007f9a115d5000) > > > where you can see the different libcrypto's are linked. > > Wht specific combination and settings of FLAGS are required to ensure that the bins & libs are all self-consistently linked/rpath'd only against this build's libs? From h15234 at mailas.com Wed Apr 8 02:13:52 2015 From: h15234 at mailas.com (h15234 at mailas.com) Date: Tue, 07 Apr 2015 19:13:52 -0700 Subject: [openssl-users] openssl 1.0.2 shared build's linking is not consistent - bin and libs linked to different libcrypto.so's In-Reply-To: References: <1426605729.1719828.241558337.16F10CB8@webmail.messagingengine.com> Message-ID: <1428459232.4163281.250546949.5DC5AFA9@webmail.messagingengine.com> On Tue, Apr 7, 2015, at 07:06 PM, Jeffrey Walton wrote: > > Setting *FLAGS & rpath, although the openssl binary links correctly > > against its own {libcrypto,libssl}.so, the libssl.so links against *system*, > > not its own, libcrypto. > > You can verify the RPATHs are actually present by dumping the > DT_RUNPATH section of the ELF executable: > > readelf -d | grep -i RPATH Here readelf -d `which openssl` | egrep -i "rpath|ssl|crypto" 0x0000000000000001 (NEEDED) Shared library: [libssl.so.1.0.0] 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.0.0] 0x000000000000001d (RUNPATH) Library runpath: [/usr/local/ssl/lib64] > > What specific combination and settings of FLAGS are required to > > ensure that the bins & libs are all self-consistently linked/rpath'd only > > against this build's libs? > > As far as I know, you only need an RPATH on Linux (OS X and Android > are a different story). > > Your executable is probably missing it, so the link/loader first loads > the system libssl and libcrypto. After that, the link/loader considers > the dependency fulfilled and does not load your versions of the > libraries. Hm, confused. This export SHARED_LDFLAGS="-L/usr/local/sslTEST/lib64 -Wl,-rpath,/usr/local/sslTEST/lib64 -lssl -lcrypto" is supposed to take care of the rpath. Apparently not. "Your executable is probably missing it" ... from where? How/where else to specify? > If you can't rebuild the executables, then consider using an > LD_LIBRARY_PATH (http://linux.die.net/man/8/ld-linux). I avoid run-time path'ing whenever possible > To avoid this on all platforms (DLL hell), I just link statically > against the OpenSSL libraries. Some consider it blasphemy, I consider > it peace of mind. The thought's crossed my mind. But higher powers here have deemed it blasphemous. Thanks Hanlon From noloader at gmail.com Wed Apr 8 02:20:32 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 7 Apr 2015 22:20:32 -0400 Subject: [openssl-users] openssl 1.0.2 shared build's linking is not consistent - bin and libs linked to different libcrypto.so's In-Reply-To: <1428459232.4163281.250546949.5DC5AFA9@webmail.messagingengine.com> References: <1426605729.1719828.241558337.16F10CB8@webmail.messagingengine.com> <1428459232.4163281.250546949.5DC5AFA9@webmail.messagingengine.com> Message-ID: On Tue, Apr 7, 2015 at 10:13 PM, wrote: > On Tue, Apr 7, 2015, at 07:06 PM, Jeffrey Walton wrote: >> > Setting *FLAGS & rpath, although the openssl binary links correctly >> > against its own {libcrypto,libssl}.so, the libssl.so links against *system*, >> > not its own, libcrypto. >> >> You can verify the RPATHs are actually present by dumping the >> DT_RUNPATH section of the ELF executable: >> >> readelf -d | grep -i RPATH > > Here > > readelf -d `which openssl` | egrep -i "rpath|ssl|crypto" > 0x0000000000000001 (NEEDED) Shared library: [libssl.so.1.0.0] > 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.0.0] > 0x000000000000001d (RUNPATH) Library runpath: [/usr/local/ssl/lib64] I believe this is different than "/usr/local/sslTEST/bin/openssl" and friends. It looks like the one you found in in /usr/local/ssl/bin, and not /usr/local/sslTEST/bin. >> "Your executable is probably missing it" > ... from where? How/where else to specify? My bad. I was not aware you were talking about the openssl program itself. I thought you were discussing arbitrary executables you were building. Jeff From h15234 at mailas.com Wed Apr 8 02:31:04 2015 From: h15234 at mailas.com (h15234 at mailas.com) Date: Tue, 07 Apr 2015 19:31:04 -0700 Subject: [openssl-users] openssl 1.0.2 shared build's linking is not consistent - bin and libs linked to different libcrypto.so's In-Reply-To: References: <1426605729.1719828.241558337.16F10CB8@webmail.messagingengine.com> <1428459232.4163281.250546949.5DC5AFA9@webmail.messagingengine.com> Message-ID: <1428460264.4167419.250551825.7048014D@webmail.messagingengine.com> Hi > > readelf -d `which openssl` | egrep -i "rpath|ssl|crypto" > > 0x0000000000000001 (NEEDED) Shared library: [libssl.so.1.0.0] > > 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.0.0] > > 0x000000000000001d (RUNPATH) Library runpath: [/usr/local/ssl/lib64] > > I believe this is different than "/usr/local/sslTEST/bin/openssl" and > friends. It looks like the one you found in in /usr/local/ssl/bin, and > not /usr/local/sslTEST/bin. Yep. But it's correct and relevant. Now. I've switched to /usr/local/ssl. /usr/local/sslTEST -- which I used in earlier tests -- no longer exists, > >> "Your executable is probably missing it" > > ... from where? How/where else to specify? > > My bad. I was not aware you were talking about the openssl program > itself. I thought you were discussing arbitrary executables you were > building. Nah. Specifically a problem with just openssl. Everything ELSE I build has no such problems. Set rpath as above, and libs are linked peristently as I intend. Hanlon From de.techno at gmail.com Wed Apr 8 03:18:48 2015 From: de.techno at gmail.com (dE) Date: Wed, 08 Apr 2015 08:48:48 +0530 Subject: [openssl-users] Close socket without SSL_shutdown Message-ID: <55249E18.5090905@gmail.com> I'm using SSL over non-blocking socket. As a result SSL_shutdown returns immediately with error code 5 (underlying socket issue), sometimes after doing this, the program crashes on SSL_CTX_free. So I was wondering about closing the socket without doing an SSL_shutdown. Is this safe? Any security consequences? From jb-openssl at wisemo.com Wed Apr 8 08:46:06 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 08 Apr 2015 10:46:06 +0200 Subject: [openssl-users] Disable SSL3 and enable TLS1? / Ambiguous "DES-CBC3-SHA" In-Reply-To: References: <1c5a01d070c7$61d6bc10$25843430$@assyst.com> <20150407024413.GB17637@mournblade.imrryr.org> <1da201d07144$da52aaf0$8ef800d0$@assyst.com> <55240C73.6030808@wisemo.com> <1e3801d07156$74ae71e0$5e0b55a0$@assyst.com> Message-ID: <5524EACE.6040202@wisemo.com> On 08/04/2015 02:06, Jeffrey Walton wrote: > On Tue, Apr 7, 2015 at 1:15 PM, David Rueter wrote: >>>> Is OpenSSL in its own DLL/DLLs? >> Yes, the OpenSSL DLL?s libeay32.dll and ssleay32.dll are used, and in fact I >> have updated them to 1.0.2a >> >> Yes, performing my own build on these DLL?s is an option, and I may pursue >> it. I just need to get a Windows dev environment set up to build these. > You also have the option of using Thomas Hruska's Win32-OpenSSL at > https://slproweb.com/products/Win32OpenSSL.html. > > Thomas makes 1.0.2a available for download on his site. Not useful! Those are default builds with SSL3 enabled. The suggestion was to buildOpenSSL with the unwanted features (in this case SSL3) disabled at configure/build time. 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 From noloader at gmail.com Wed Apr 8 09:22:42 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 8 Apr 2015 05:22:42 -0400 Subject: [openssl-users] Disable SSL3 and enable TLS1? / Ambiguous "DES-CBC3-SHA" In-Reply-To: <5524EACE.6040202@wisemo.com> References: <1c5a01d070c7$61d6bc10$25843430$@assyst.com> <20150407024413.GB17637@mournblade.imrryr.org> <1da201d07144$da52aaf0$8ef800d0$@assyst.com> <55240C73.6030808@wisemo.com> <1e3801d07156$74ae71e0$5e0b55a0$@assyst.com> <5524EACE.6040202@wisemo.com> Message-ID: >> You also have the option of using Thomas Hruska's Win32-OpenSSL at >> https://slproweb.com/products/Win32OpenSSL.html. >> >> Thomas makes 1.0.2a available for download on his site. > > Not useful! Those are default builds with SSL3 enabled. > The suggestion was to buildOpenSSL with the unwanted > features (in this case SSL3) disabled at configure/build > time. Oh, you're right. I was commenting on the pain points of a Win32 compile. I did not see the third message in the thread. From Michael.Wojcik at microfocus.com Wed Apr 8 12:30:05 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 8 Apr 2015 12:30:05 +0000 Subject: [openssl-users] removing compression? In-Reply-To: References: <55200B77.5060204@gmx.net> <8a72356eae914fa6bc7c512ea1337b34@ustx2ex-dag1mb2.msg.corp.akamai.com> <552395A8.1010500@wisemo.com> <4a138429210c497a931ea56ad8edfa69@ustx2ex-dag1mb2.msg.corp.akamai.com> <55240AB3.50602@wisemo.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jeffrey Walton > Sent: Tuesday, April 07, 2015 18:37 > To: OpenSSL Users List > Subject: Re: [openssl-users] removing compression? > > It seems to me the trick to avoid CRMIE-like attacks is to make sure > the compression is semantically secure. In the case of CRIME, > information should not be gained across different messages (in this > case, each message alone was secure - it was the different messages > over time that got folks in trouble). > > But I'm not sure about other attacks on the compression layer. Compression will always be a side channel that leaks information if the size of the message changes in a way that has a predictable relationship to the input. As with any side channel, the only real options are denying the attacker access to it (infeasible in the case of communications compression) or whitening it by adding noise. The random-flush technique Jakob discussed yesterday is one way to add noise; random-length incompressible padding is another. The CRIME and BREACH attacks are just two (more) instances of the very general category of side-channel attacks on ciphertext that represents largely-predictable parts of plaintext. Defense amounts to making the plaintext less predictable or confusing the relationship between the two. For that reason, if I had an application running under a threat model that included attackers mounting passive or active attacks on the compression side channel, I'd want to disable any automatic compression mechanism, personally. But I suspect many OpenSSL applications don't include that in their threat model, because their traffic doesn't provide suitable opportunities, or it's not of sufficient value, or the users just don't care. So I have no strong feelings either way about this feature in OpenSSL. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com From fweimer at redhat.com Wed Apr 8 15:00:23 2015 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 08 Apr 2015 17:00:23 +0200 Subject: [openssl-users] [openssl-dev] removing compression? In-Reply-To: References: Message-ID: <55254287.3030206@redhat.com> On 04/03/2015 09:53 PM, Salz, Rich wrote: > If this will cause problems for you, please post on the list, ideally within the next week. PostgreSQL uses OpenSSL compression by default, and it is a deliberate feature (there is no application-layer compression support). -- Florian Weimer / Red Hat Product Security From nicboul at gmail.com Thu Apr 9 01:04:04 2015 From: nicboul at gmail.com (Nicolas J. Bouliane) Date: Wed, 8 Apr 2015 21:04:04 -0400 Subject: [openssl-users] Leak in SSL_do_handshake Message-ID: Hi, I'm using SSL_do_handshake, and I'd like to know how to free the memory allocated internally by this function. Via valgrind, I'm getting this trace: ==7430== 4,169 (104 direct, 4,065 indirect) bytes in 1 blocks are definitely lost in loss record 51 of 51 ==7430== at 0x4028308: malloc (vg_replace_malloc.c:263) ==7430== by 0x40EF05B: default_malloc_ex (in /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0) ==7430== by 0x40EF755: CRYPTO_malloc (in /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0) ==7430== by 0x41ACE6C: asn1_item_ex_combine_new (in /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0) ==7430== by 0x41B047C: ASN1_item_ex_d2i (in /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0) ==7430== by 0x41B0C34: ASN1_item_d2i (in /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0) ==7430== by 0x41A7B14: d2i_X509 (in /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0) ==7430== by 0x4055873: ssl3_get_server_certificate (in /usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.0) ==7430== by 0x405A7CF: ssl3_connect (in /usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.0) ==7430== by 0x407BCDC: SSL_do_handshake (in /usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.0) # openssl version OpenSSL 1.0.2a 19 Mar 2015 please tell me if you need more info, thank you, Nicolas From h15234 at mailas.com Thu Apr 9 13:28:41 2015 From: h15234 at mailas.com (h15234 at mailas.com) Date: Thu, 09 Apr 2015 06:28:41 -0700 Subject: [openssl-users] openssl 1.0.2 shared build's linking is not consistent - bin and libs linked to different libcrypto.so's In-Reply-To: <1428460264.4167419.250551825.7048014D@webmail.messagingengine.com> References: <1426605729.1719828.241558337.16F10CB8@webmail.messagingengine.com> <1428459232.4163281.250546949.5DC5AFA9@webmail.messagingengine.com> <1428460264.4167419.250551825.7048014D@webmail.messagingengine.com> Message-ID: <1428586121.1250473.251247929.0E39CFAF@webmail.messagingengine.com> Since it'll apparently remain a mystery how to tame the build system to do what you want it to do and link/rpath the libraries consistently, a workaround is to just ignore it -- and fix the link AFTER the build's done. Noting On Tue, Apr 7, 2015, at 07:06 PM, Jeffrey Walton wrote: > As far as I know, you only need an RPATH on Linux (OS X and Android > are a different story). After the build, since there's no proper RPATH for the libssl.so with any combination of FLAGs that I've been able to figure out, ldd libssl.so.1.0.0 | egrep "ssl|crypto" libcrypto.so.1.0.0 => /lib/libcrypto.so.1.0.0 (0x00007f55e46c0000) readelf --dynamic libssl.so.1.0.0 | egrep -i "rpath|runpath" (empty) For anyone actually interested this does the trick patchelf --set-rpath "/path/to/ssl/lib" --force-rpath libssl.so.1.0.0 readelf --dynamic libssl.so.1.0.0 | egrep -i "rpath|runpath" 0x000000000000000f (RPATH) Library rpath: [/path/to/ssl/lib] ldd libssl.so | egrep "ssl|crypto" libcrypto.so.1.0.0 => /path/to/ssl/lib/libcrypto.so.1.0.0 (0x00007f476b4fc000) From dpb795795 at gmail.com Thu Apr 9 19:13:05 2015 From: dpb795795 at gmail.com (Deepak) Date: Fri, 10 Apr 2015 00:43:05 +0530 Subject: [openssl-users] Password based key derivation Message-ID: <832958C0-DB14-43FD-A4B0-953E38A7DAFE@gmail.com> Hi, Any help on following questions is appreciated. 1) Can the function PKCS5_PBKDF2_HMAC_SHA1() in 0.9.8zf be used to derive a key for AES-256-CBC encryption from user supplied passphrase? 2) Is PKCS5_PBKDF2_HMAC_SHA1() preferable to EVP_BytesToKey() and why ? I see PKCS5_PBKDF2_HMAC_SHA1() uses HMACs and is part of standard. On debugging, could see PKCS5_PBKDF2_HMAC_SHA1() working with 256-bit key but after returning from the function, the data in the stack frame gets corrupted for me and overwrites few other parameters leading to Seg Fault. Thank you, Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Thu Apr 9 21:09:25 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 9 Apr 2015 17:09:25 -0400 Subject: [openssl-users] Password based key derivation In-Reply-To: <832958C0-DB14-43FD-A4B0-953E38A7DAFE@gmail.com> References: <832958C0-DB14-43FD-A4B0-953E38A7DAFE@gmail.com> Message-ID: > 1) Can the function PKCS5_PBKDF2_HMAC_SHA1() in 0.9.8zf be used to > derive a key for AES-256-CBC encryption from user supplied passphrase? For the function PKCS5_PBKDF2_HMAC_SHA1, Yes. See https://wiki.openssl.org/index.php/Manual:PKCS5_PBKDF2_HMAC(3). I'm not sure what the significance of 0.9.8zf is. > 2) Is PKCS5_PBKDF2_HMAC_SHA1() preferable to EVP_BytesToKey() and why ? Yes. See https://wiki.openssl.org/index.php/Manual:EVP_BytesToKey(3). From thomas.francis.jr at pobox.com Thu Apr 9 21:18:02 2015 From: thomas.francis.jr at pobox.com (Tom Francis) Date: Thu, 9 Apr 2015 17:18:02 -0400 Subject: [openssl-users] Password based key derivation In-Reply-To: <832958C0-DB14-43FD-A4B0-953E38A7DAFE@gmail.com> References: <832958C0-DB14-43FD-A4B0-953E38A7DAFE@gmail.com> Message-ID: <18D09D63-E750-483E-9508-0567F3156860@pobox.com> > On Apr 9, 2015, at 3:13 PM, Deepak wrote: > > Hi, > > Any help on following questions is appreciated. > > 1) Can the function PKCS5_PBKDF2_HMAC_SHA1() in 0.9.8zf be used to derive a key for AES-256-CBC encryption from user supplied passphrase? Yes. > 2) Is PKCS5_PBKDF2_HMAC_SHA1() preferable to EVP_BytesToKey() and why ? I see PKCS5_PBKDF2_HMAC_SHA1() uses HMACs and is part of standard. EVP_BytesToKey is pretty old and very simple. It?s not really appropriate to use it for anything new (of course, if you?re trying to remain compatible with something that used it in the past, you?d need to keep using it). You might want to consider PKCS5_PBKDF2_HMAC() instead, since some people like to avoid SHA-1 these days. Please note that PKCS5_PBKDF2_HMAC* should be slower than EVP_BytesToKey(), and that?s a good thing. :) See also http://openssl-users.openssl.narkive.com/AzXOpacU/openssl-support-for-rfc2898-pbkdf2 > On debugging, could see PKCS5_PBKDF2_HMAC_SHA1() working with 256-bit key but after returning from the function, the data in the stack frame gets corrupted for me and overwrites few other parameters leading to Seg Fault. That would suggest you?ve misused the function in some way. :) You might want to be sure that you have allocated memory for the out parameter, as it will not be allocated for you ? that?s the only thing which comes to mind immediately. TOM > > > Thank you, > > Deepak > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From wangqun at alumni.nus.edu.sg Fri Apr 10 01:10:40 2015 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Thu, 9 Apr 2015 18:10:40 -0700 (MST) Subject: [openssl-users] Is there any plan for FIPS to be supported on Linux-aarch64? In-Reply-To: <5522C4A3.6040504@openssl.com> References: <1428282801225-57389.post@n7.nabble.com> <55228FFF.203@openssl.com> <55229BB0.6060306@openssl.com> <5522C4A3.6040504@openssl.com> Message-ID: <1428628240705-57485.post@n7.nabble.com> Thanks so much for the quick response, Steve. Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/Is-there-any-plan-for-FIPS-to-be-supported-on-Linux-aarch64-tp57389p57485.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From noloader at gmail.com Fri Apr 10 04:46:51 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 10 Apr 2015 00:46:51 -0400 Subject: [openssl-users] Where is the table of configuration options in 1.0.2? Message-ID: Previous version of OpenSSL had a big table of configuration options in Configure. You could do something like `./Configure ben-debug` and get a build for OS X with symbols. 1.0.2 seems to be missing the table and it ignores exported CFLAGS. (Ignoring CFLAGS is not new behavior, buts its kind of annoying now because I need to change them and the table is missing). Where do I find the table of configuration options so I can change CFLAGS? From openssl-users at dukhovni.org Fri Apr 10 05:36:05 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 10 Apr 2015 05:36:05 +0000 Subject: [openssl-users] Where is the table of configuration options in 1.0.2? In-Reply-To: References: Message-ID: <20150410053605.GJ17637@mournblade.imrryr.org> On Fri, Apr 10, 2015 at 12:46:51AM -0400, Jeffrey Walton wrote: > Where do I find the table of configuration options so I can change CFLAGS? $ ./Configure TABLE | grep '^\*\*\*' | awk '{print $NF}' Are you sure you're not confusing 1.0.2 with master? In master the internals are changing... -- Viktor. From noloader at gmail.com Fri Apr 10 05:48:56 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 10 Apr 2015 01:48:56 -0400 Subject: [openssl-users] Where is the table of configuration options in 1.0.2? In-Reply-To: <20150410053605.GJ17637@mournblade.imrryr.org> References: <20150410053605.GJ17637@mournblade.imrryr.org> Message-ID: On Fri, Apr 10, 2015 at 1:36 AM, Viktor Dukhovni wrote: > On Fri, Apr 10, 2015 at 12:46:51AM -0400, Jeffrey Walton wrote: > >> Where do I find the table of configuration options so I can change CFLAGS? > > $ ./Configure TABLE | grep '^\*\*\*' | awk '{print $NF}' > > Are you sure you're not confusing 1.0.2 with master? In master > the internals are changing... > Oh, you're right. I am working from Git. Sorry about that. From Sudhakar.Shanmugam at target.com Fri Apr 10 11:06:44 2015 From: Sudhakar.Shanmugam at target.com (Sudhakar.Shanmugam) Date: Fri, 10 Apr 2015 11:06:44 +0000 Subject: [openssl-users] Permission denied while creating the key Message-ID: <898E9CCF96AA7848B0BD71CD36EE08354A708333@TCEMAIL18P.hq.target.com> I?m facing below error while creating the private key, has anyone encountered this error? mftlx1001[/opt/mft/shared/software]> openssl genrsa -out mfra.key 2048 -config openssl.cnf mfra.key: Permission denied 32096:error:0200100D:system library:fopen:Permission denied:bss_file.c:352:fopen('mfra.key','w') 32096:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:354: -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Unsworth at owmessaging.com Fri Apr 10 11:21:03 2015 From: John.Unsworth at owmessaging.com (John Unsworth) Date: Fri, 10 Apr 2015 11:21:03 +0000 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken Message-ID: I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris 32 bit. I want to upgrade but both 1.0.2 and 1.0.2a cause problems. 1 When building 1.0.2 using ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 -xldscope=hidden openssl s_client crashes on start: -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 Segmentation Fault (core dumped) -bash-3.00$ pstack core core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4, 44) + 8 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, 2c0624) + 38c 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, 13000) + 138 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94 0001328c do_cmd (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8 00012f08 main (4, ffbffa84, 2eb4c8, 2a0000, 2b3e78, 2b4adc) + 3a4 00012a08 _start (0, 0, 0, 0, 0, 2b3e78) + 108 2 So I then rebuilt adding no-asm flag. It manages to connect but negotiation fails with an error: 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:s3_pkt.c:1456:SSL alert number 20 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: This is against the server that is still running 1.0.1h and can be successfully connected with openssl built with 1.0.1h. Note that the 64 bit build seems to work perfectly. Unfortunately for historical reasons we need to use the 32 bit version. The 32 bit builds that we use on Windows and Linux also work perfectly. Is it something to do with byte order? Regards, John. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri Apr 10 11:47:03 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 10 Apr 2015 13:47:03 +0200 Subject: [openssl-users] Permission denied while creating the key In-Reply-To: <898E9CCF96AA7848B0BD71CD36EE08354A708333@TCEMAIL18P.hq.target.com> References: <898E9CCF96AA7848B0BD71CD36EE08354A708333@TCEMAIL18P.hq.target.com> Message-ID: <5527B837.1020403@wisemo.com> On 10/04/2015 13:06, Sudhakar.Shanmugam wrote: > > I?m facing below error while creating the private key, has anyone > encountered this error? > > mftlx1001[/opt/mft/shared/software]> openssl genrsa -out mfra.key 2048 > -config openssl.cnf > > mfra.key: Permission denied > > 32096:error:0200100D:system library:fopen:Permission > denied:bss_file.c:352:fopen('mfra.key','w') > > 32096:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:354: > > You are trying to save the secret key in /opt/mft/shared/software/mfra.key You are not running as root (this is GOOD!). You are not supposed to (and not allowed to) put the key file there, because that directory is only supposed to contain software AND because everybody else can read that directory. You should put the key in a directory where only you have access, and where you do have write access. For example [/home/Sudhakar.Shanmugam/secrets]>chmod 0700 . [/home/Sudhakar.Shanmugam/secrets]>umask 077 [/home/Sudhakar.Shanmugam/secrets]>/opt/mft/shared/software/openssl genrsa -out mfra.key 2048 -config /opt/mft/shared/software/openssl.cnf Please try not to get hacked. 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 From jonetsu at teksavvy.com Fri Apr 10 13:55:50 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 10 Apr 2015 09:55:50 -0400 Subject: [openssl-users] FIPS mode restrictions and DES Message-ID: Is it possible to use DES_crypt() in OpenSSL FIPS mode ?? Some low level non-EVP methods are allowed, I think.? The question comes from seeing if it is possible to use the OpenSSL password() method in FIPS mode. Regards. From John.Unsworth at owmessaging.com Fri Apr 10 13:53:44 2015 From: John.Unsworth at owmessaging.com (John Unsworth) Date: Fri, 10 Apr 2015 13:53:44 +0000 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: Message-ID: I have compiled 1.0.1m in the same way and that works fine using asm. John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Unsworth Sent: 10 April 2015 12:21 To: openssl-users at openssl.org Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris 32 bit. I want to upgrade but both 1.0.2 and 1.0.2a cause problems. 1 When building 1.0.2 using ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 -xldscope=hidden openssl s_client crashes on start: -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 Segmentation Fault (core dumped) -bash-3.00$ pstack core core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4, 44) + 8 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, 2c0624) + 38c 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, 13000) + 138 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94 0001328c do_cmd (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8 00012f08 main (4, ffbffa84, 2eb4c8, 2a0000, 2b3e78, 2b4adc) + 3a4 00012a08 _start (0, 0, 0, 0, 0, 2b3e78) + 108 2 So I then rebuilt adding no-asm flag. It manages to connect but negotiation fails with an error: 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:s3_pkt.c:1456:SSL alert number 20 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: This is against the server that is still running 1.0.1h and can be successfully connected with openssl built with 1.0.1h. Note that the 64 bit build seems to work perfectly. Unfortunately for historical reasons we need to use the 32 bit version. The 32 bit builds that we use on Windows and Linux also work perfectly. Is it something to do with byte order? Regards, John. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonetsu at teksavvy.com Fri Apr 10 15:01:15 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 10 Apr 2015 11:01:15 -0400 Subject: [openssl-users] FIPS mode restrictions and DES In-Reply-To: References: Message-ID: > From: jonetsu > Date: 04/10/15 09:55 > Is it possible to use DES_crypt() in OpenSSL FIPS mode ?? Some low > level non-EVP methods are allowed, I think.? The question comes from > seeing if it is possible to use the OpenSSL password() method in FIPS > mode. Hmmm...? In any case, trying to squeeze DES in a FIPS validation might be pushing it a bit.? Any drop-in replacement for the crypto() method in glibc2 (that supports SHA-256, SHA-512) ? Regards. From yoom at misoccer.us Fri Apr 10 15:02:59 2015 From: yoom at misoccer.us (Yoom Nguyen) Date: Fri, 10 Apr 2015 11:02:59 -0400 (EDT) Subject: [openssl-users] Can openssl be build on Redhat? In-Reply-To: Message-ID: <9518054.233408.1428678179162.JavaMail.root@misoccer.us> I am having so much problem building 1.0.2 on an Redhat 7 EN OS. I cam compile with the following options. export CFLAGS="-fPIC" ./config shared no-ssl2 no-ssl3 --openssldir=/usr/local/openssl When I ran the: make test I received the following errors. /usr/bin/ld: cannot find -lssl make[2]: *** [link_app.gnu] Error 1 make[2]: Leaving directory '/opt/software/openssl-1.0.2a/test' make[2]: *** [bntest] Error 2 make[2]: Leaving directory '/opt/software/openssl-1.0.2a/test' make[2]: *** [tests] Error 2 Can openssl 1.0.2 be build on Redhat 7 EN? If you know any trick to work around Redhat's build dependency please share. Someone have mention perhaps, I am missing the openssl-dev packages. I have search and could not find it any where and what to do with it. Redhat has it for download but the RPM is make specific for their early version of openssl 1.0.1 Thank you Y From wieland at purdue.edu Fri Apr 10 17:50:33 2015 From: wieland at purdue.edu (Jeff Wieland) Date: Fri, 10 Apr 2015 13:50:33 -0400 Subject: [openssl-users] Can openssl be build on Redhat? In-Reply-To: <9518054.233408.1428678179162.JavaMail.root@misoccer.us> References: <9518054.233408.1428678179162.JavaMail.root@misoccer.us> Message-ID: <55280D69.1010607@purdue.edu> For building it under Solaris, in addition to the --openssldir= directive, I also use --prefix=. They need to point to the same place: --prefix=/usr/local/openssl --openssldir=/usr/local/openssl See if that helps. Yoom Nguyen wrote: > I am having so much problem building 1.0.2 on an Redhat 7 EN OS. > I cam compile with the following options. > > export CFLAGS="-fPIC" > ./config shared no-ssl2 no-ssl3 --openssldir=/usr/local/openssl > > When I ran the: > > make test > > I received the following errors. > > /usr/bin/ld: cannot find -lssl > make[2]: *** [link_app.gnu] Error 1 > make[2]: Leaving directory '/opt/software/openssl-1.0.2a/test' > make[2]: *** [bntest] Error 2 > make[2]: Leaving directory '/opt/software/openssl-1.0.2a/test' > make[2]: *** [tests] Error 2 > > Can openssl 1.0.2 be build on Redhat 7 EN? > If you know any trick to work around Redhat's build dependency please share. > > Someone have mention perhaps, I am missing the openssl-dev packages. > I have search and could not find it any where and what to do with it. > Redhat has it for download but the RPM is make specific for their early version of openssl 1.0.1 > > > Thank you > Y > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- Jeff Wieland | Purdue University Network Systems Administrator | ITIS UNIX Platforms Voice: (765)496-8234 | 155 S. Grant Street FAX: (765)494-6620 | West Lafayette, IN 47907 From jb-openssl at wisemo.com Fri Apr 10 18:07:07 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 10 Apr 2015 20:07:07 +0200 Subject: [openssl-users] FIPS mode restrictions and DES In-Reply-To: References: Message-ID: <5528114B.4060209@wisemo.com> On 10/04/2015 17:01, jonetsu wrote: >> From: jonetsu >> Date: 04/10/15 09:55 >> Is it possible to use DES_crypt() in OpenSSL FIPS mode ? Some low >> level non-EVP methods are allowed, I think. The question comes from >> seeing if it is possible to use the OpenSSL password() method in FIPS >> mode. > Hmmm... In any case, trying to squeeze DES in a FIPS validation might be pushing it a bit. Any drop-in replacement for the crypto() method in glibc2 (that supports SHA-256, SHA-512) ? > > Regards. I see two possibilities without using any crypto outside the FIPS validated functionality: a) If triple DES (TDEA in NIST-speak) is included, then you can emulate DES by repeating the same 56 bit key 2 or 3 times. For instance if you need DES with the key 0x123456789ABCDE, you can just use 112 bit triple DES with the key 0x123456789ABCDE123456789ABCDE or 168 bit triple DES with the key 0x123456789ABCDE123456789ABCDE123456789ABCDE . Then with that problem solved, you can recreate the "unix password"formula using the FIPS validated TDEA code via EVP. b) If triple DES is not included, then you will have to use one of the modern password encodings found on Linux and BSD. Those use standard hashes such as MD5 (not allowed!), SHA1 (possibly not allowed, at least not for long), SHA-2-256 (clearly still allowed and probably in the FIPS validated EVP API). Then once again use the EVP API to reimplement the formula found in libcrypt (which uses a non-validated copy of the standard algorithm and is thus not allowed). Of cause it is possible that one of the large distributions suchas Red Hat may have already done the footwork as part ofcreating a US government edition of their Linux distribution.For example I have heard rumors that most federal US courtsuse a case management system running on Red Hat, whichwould probably imply that they are using a FIPS validatedimplementation of the Linux password encoding formula. 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 From jonetsu at teksavvy.com Fri Apr 10 18:10:28 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 10 Apr 2015 14:10:28 -0400 Subject: [openssl-users] FIPS: Using FIPS_post_set_callback() to capture all errors Message-ID: Hello, >From fips_test_suite.c, does the use of FIPS_POST_FAIL be cover all types of FIPS errors ? While FIPS_POST_FAIL would be about POST failures, what would the corruption referred-to by FIPS_POST_CORRUPT ?? Is it likely to be encountered in a production environment ? When a FIPS_POST_FAIL is encountered, the test_suite returns a 1. A 0 is returned when an expected failure occurs in FIPS_POST_CORRUPT, otherwise a 1.? Is this behaviour of returning 1 when an error is encountered only a test suite practice, or should it be also used in production ?? Eg. will the return value influence the behavior of OpenSSL when an error happens (eg. not allowing any crypto from then on) ? Regards. From yoom at misoccer.us Sun Apr 12 16:30:01 2015 From: yoom at misoccer.us (Yoom Nguyen) Date: Sun, 12 Apr 2015 12:30:01 -0400 (EDT) Subject: [openssl-users] Can this Errors be ignore? In-Reply-To: <9518054.233408.1428678179162.JavaMail.root@misoccer.us> Message-ID: <6242092.236788.1428856201212.JavaMail.root@misoccer.us> Can the following error to be ignore? I received the following errors after ran make test: /usr/bin/ld: cannot find -lssl make[2]: *** [link_app.gnu] Error 1 make[2]: Leaving directory '/opt/software/openssl-1.0.2a/test' make[2]: *** [bntest] Error 2 make[2]: Leaving directory '/opt/software/openssl-1.0.2a/test' make[2]: *** [tests] Error 2 I am trying to compile 1.0.2a on an Redhat 7 EN OS. I compile with the following options. export CFLAGS="-fPIC" ./config shared no-ssl2 no-ssl3 --openssldir=/usr/local/openssl Any suggestion or advice will be much appreciate. Thank you Y From noloader at gmail.com Sun Apr 12 22:57:21 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 12 Apr 2015 18:57:21 -0400 Subject: [openssl-users] Can this Errors be ignore? In-Reply-To: <6242092.236788.1428856201212.JavaMail.root@misoccer.us> References: <9518054.233408.1428678179162.JavaMail.root@misoccer.us> <6242092.236788.1428856201212.JavaMail.root@misoccer.us> Message-ID: On Sun, Apr 12, 2015 at 12:30 PM, Yoom Nguyen wrote: > > Can the following error to be ignore? The self tests are important, and I probably would not ignore them. > I received the following errors after ran make test: > > /usr/bin/ld: cannot find -lssl > make[2]: *** [link_app.gnu] Error 1 > make[2]: Leaving directory '/opt/software/openssl-1.0.2a/test' > make[2]: *** [bntest] Error 2 > make[2]: Leaving directory '/opt/software/openssl-1.0.2a/test' > make[2]: *** [tests] Error 2 > > I am trying to compile 1.0.2a on an Redhat 7 EN OS. > I compile with the following options. > > export CFLAGS="-fPIC" > ./config shared no-ssl2 no-ssl3 --openssldir=/usr/local/openssl > > > Any suggestion or advice will be much appreciate. export LD_LIBRARY_PATH="$PWD:$LD_LIBRARY_PATH" make test You may have the same problem with the openssl program after installing in it /usr/local/openssl. It appears RUNPATH is not set: $ readelf -d /usr/local/ssl/bin/openssl | egrep "(RPATH|RUNPATH)" $ From jonetsu at teksavvy.com Mon Apr 13 15:33:09 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Mon, 13 Apr 2015 08:33:09 -0700 (MST) Subject: [openssl-users] FIPS mode restrictions and DES In-Reply-To: <5528114B.4060209@wisemo.com> References: <5528114B.4060209@wisemo.com> Message-ID: <1428939189931-57527.post@n7.nabble.com> Thanks for the comments - much appreciated. The following question might be on the naive side of things, but then I'm all new to this. Since crypt() in glibc2 supports SHA-256 and SHA-512 for password, and assuming that these two are FIPS compatible, what would be the (financial) overhead of having the crypto part of glibc2 go through validation ? It sounds very odd, not to mention very expensive, but I'm asking nevertheless, in case there is a possibility. In other words, is the only practical and viable option regarding this to re-implement crypt() using EVP methods ? - thanks. Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57527.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From rsalz at akamai.com Mon Apr 13 15:48:41 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 13 Apr 2015 15:48:41 +0000 Subject: [openssl-users] FIPS mode restrictions and DES In-Reply-To: <1428939189931-57527.post@n7.nabble.com> References: <5528114B.4060209@wisemo.com> <1428939189931-57527.post@n7.nabble.com> Message-ID: > In other words, is the only > practical and viable option regarding this to re-implement crypt() using EVP > methods ? - thanks. Yes. That would be so much easier than anything you can imagine. From jb-openssl at wisemo.com Mon Apr 13 16:14:20 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 13 Apr 2015 18:14:20 +0200 Subject: [openssl-users] FIPS mode restrictions and DES In-Reply-To: References: <5528114B.4060209@wisemo.com> <1428939189931-57527.post@n7.nabble.com> Message-ID: <552BEB5C.1040007@wisemo.com> On 13/04/2015 17:48, Salz, Rich wrote: >> In other words, is the only >> practical and viable option regarding this to re-implement crypt() using EVP >> methods ? - thanks. > Yes. That would be so much easier than anything you can imagine. Yes, the only thing easier would be if someone (maybe Red Hat) already has a FIPS validatedopen source implementation of crypt(). 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 From marquess at openssl.com Mon Apr 13 16:48:21 2015 From: marquess at openssl.com (Steve Marquess) Date: Mon, 13 Apr 2015 12:48:21 -0400 Subject: [openssl-users] FIPS mode restrictions and DES In-Reply-To: <552BEB5C.1040007@wisemo.com> References: <5528114B.4060209@wisemo.com> <1428939189931-57527.post@n7.nabble.com> <552BEB5C.1040007@wisemo.com> Message-ID: <552BF355.4080008@openssl.com> On 04/13/2015 12:14 PM, Jakob Bohm wrote: > On 13/04/2015 17:48, Salz, Rich wrote: >>> In other words, is the only >>> practical and viable option regarding this to re-implement crypt() >>> using EVP >>> methods ? - thanks. >> Yes. That would be so much easier than anything you can imagine. > Yes, the only thing easier would be if someone (maybe Red Hat) > already has a FIPS validatedopen source implementation of > crypt(). And even if Red Hat does, you would be limited to using the specific commercial versions of RHEL that included that specific validated binary module. With the very unique exception of the OpenSSL FIPS Object Module, there are no FIPS 140-2 validated cryptographic modules that can be obtained in source form and compiled by the end user. The fact that Red Hat (or whomever) has taken open source code and obtained a FIPS 140-2 validation of binaries generated from that code does you no good unless you have those specific binaries, which is to say you're a commercial customer paying for a commercial license from that vendor. Then, even for the OpenSSL FIPS module the validation imposes some pretty perverse constraints (from the usual software engineering perspective). You have to start with a snail-mailed CD, you have to build the binary module in a very special way that will conflict with whatever configuration management you use, etc.; you have to treat it differently that all the other software components of your product. FIPS 140-2 is the tail that wags the dog. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From jb-openssl at wisemo.com Mon Apr 13 17:30:47 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 13 Apr 2015 19:30:47 +0200 Subject: [openssl-users] FIPS mode restrictions and DES In-Reply-To: <552BF355.4080008@openssl.com> References: <5528114B.4060209@wisemo.com> <1428939189931-57527.post@n7.nabble.com> <552BEB5C.1040007@wisemo.com> <552BF355.4080008@openssl.com> Message-ID: <552BFD47.5010802@wisemo.com> On 13/04/2015 18:48, Steve Marquess wrote: > On 04/13/2015 12:14 PM, Jakob Bohm wrote: >> On 13/04/2015 17:48, Salz, Rich wrote: >>>> In other words, is the only >>>> practical and viable option regarding this to re-implement crypt() >>>> using EVP >>>> methods ? - thanks. >>> Yes. That would be so much easier than anything you can imagine. >> Yes, the only thing easier would be if someone (maybe Red Hat) >> already has a FIPS validatedopen source implementation of >> crypt(). > And even if Red Hat does, you would be limited to using the specific > commercial versions of RHEL that included that specific validated binary > module. > > With the very unique exception of the OpenSSL FIPS Object Module, there > are no FIPS 140-2 validated cryptographic modules that can be obtained > in source form and compiled by the end user. The fact that Red Hat (or > whomever) has taken open source code and obtained a FIPS 140-2 > validation of binaries generated from that code does you no good unless > you have those specific binaries, which is to say you're a commercial > customer paying for a commercial license from that vendor. > > Then, even for the OpenSSL FIPS module the validation imposes some > pretty perverse constraints (from the usual software engineering > perspective). You have to start with a snail-mailed CD, you have to > build the binary module in a very special way that will conflict with > whatever configuration management you use, etc.; you have to treat it > differently that all the other software components of your product. FIPS > 140-2 is the tail that wags the dog. > > -Steve M. Of cause. One point is that if this is a delivery for someone subject to the FIPS-only procurementrequirement imposed on various US Government related entities, then whatever OS theyuse, MUST (by that requirement) have already passed this for its password handling. This provides a baseline of already validated stuff on which other contractors can thenbuild, with reasonable care to the (bureaucratic) FIPS requirements. So if the OPs customer is already using/requiring a specificLinux/BSD/Solaris/etc. distribution, and that distributioncontains a FIPS 140-2 validated crypt() function for its loginprocessing, then the OP could reuse that. Red Hat is anexample here. Another possibility is that Red Hat or some other open source supplier to the US government has already reimplemented crypt() in terms of some other FIPS-validated piece of software, such as the OpenSSL FIPS module, with that crypt() reimplementation being outside the cryptographic boundary and thus reusable on other "platforms" with the same FIPS module. 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 From jonetsu at teksavvy.com Mon Apr 13 17:54:05 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Mon, 13 Apr 2015 10:54:05 -0700 (MST) Subject: [openssl-users] FIPS mode restrictions and DES In-Reply-To: <552BFD47.5010802@wisemo.com> References: <5528114B.4060209@wisemo.com> <1428939189931-57527.post@n7.nabble.com> <552BEB5C.1040007@wisemo.com> <552BF355.4080008@openssl.com> <552BFD47.5010802@wisemo.com> Message-ID: <1428947645188-57533.post@n7.nabble.com> Thanks for all the comments, they're much appreciated. It is a Debian system, so there is no Red Hat FIPS validation (or SuSE which also has one I think) or validated components that can be used. If I may, I'd like to ask about including the Linux kernel in the validation. Now, including glibc2 was a pretty bad idea, it cannot get better with the kernel. In this case, IPSec (libreswan) is using the kernel's crypto functions. So it seems there would be no way out of this one. Any insight on this matter ? - thanks. Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57533.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From rsalz at akamai.com Mon Apr 13 18:28:02 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 13 Apr 2015 18:28:02 +0000 Subject: [openssl-users] FIPS mode restrictions and DES In-Reply-To: <1428947645188-57533.post@n7.nabble.com> References: <5528114B.4060209@wisemo.com> <1428939189931-57527.post@n7.nabble.com> <552BEB5C.1040007@wisemo.com> <552BF355.4080008@openssl.com> <552BFD47.5010802@wisemo.com> <1428947645188-57533.post@n7.nabble.com> Message-ID: <2f7c75080d9f4b7b9d8ddeb2f3a1c7d9@usma1ex-dag1mb2.msg.corp.akamai.com> > If I may, I'd like to ask about including the Linux kernel in the validation. As the old joke goes, "if you have to ask, you can't afford it." From jonetsu at teksavvy.com Tue Apr 14 12:51:16 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Tue, 14 Apr 2015 05:51:16 -0700 (MST) Subject: [openssl-users] FIPS mode restrictions and DES In-Reply-To: <2f7c75080d9f4b7b9d8ddeb2f3a1c7d9@usma1ex-dag1mb2.msg.corp.akamai.com> References: <5528114B.4060209@wisemo.com> <1428939189931-57527.post@n7.nabble.com> <552BEB5C.1040007@wisemo.com> <552BF355.4080008@openssl.com> <552BFD47.5010802@wisemo.com> <1428947645188-57533.post@n7.nabble.com> <2f7c75080d9f4b7b9d8ddeb2f3a1c7d9@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <1429015876160-57541.post@n7.nabble.com> Salz, Rich wrote > As the old joke goes, "if you have to ask, you can't afford it." Well, exploration can be free. I noticed that Strongswan uses a plug-in architecture for crypto that seemingly allows the use of OpenSSL instead of the kernel for crypto operations, for use under FIPS. Does anyone have an idea of the order of magnitude in performance loss this could be for IPSec, to use crypto from OpenSSL instead of the kernel ? Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57541.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From marquess at openssl.com Tue Apr 14 13:29:50 2015 From: marquess at openssl.com (Steve Marquess) Date: Tue, 14 Apr 2015 09:29:50 -0400 Subject: [openssl-users] FIPS mode restrictions and DES In-Reply-To: <552BFD47.5010802@wisemo.com> References: <5528114B.4060209@wisemo.com> <1428939189931-57527.post@n7.nabble.com> <552BEB5C.1040007@wisemo.com> <552BF355.4080008@openssl.com> <552BFD47.5010802@wisemo.com> Message-ID: <552D164E.6070000@openssl.com> On 04/13/2015 01:30 PM, Jakob Bohm wrote: > .. >> >> With the very unique exception of the OpenSSL FIPS Object Module, there >> are no FIPS 140-2 validated cryptographic modules that can be obtained >> in source form and compiled by the end user. The fact that Red Hat (or >> whomever) has taken open source code and obtained a FIPS 140-2 >> validation of binaries generated from that code does you no good unless >> you have those specific binaries, which is to say you're a commercial >> customer paying for a commercial license from that vendor. >> >> Then, even for the OpenSSL FIPS module the validation imposes some >> pretty perverse constraints (from the usual software engineering >> perspective). You have to start with a snail-mailed CD, you have to >> build the binary module in a very special way that will conflict with >> whatever configuration management you use, etc.; you have to treat it >> differently that all the other software components of your product. FIPS >> 140-2 is the tail that wags the dog. >> >> -Steve M. > Of cause. > > One point is that if this is a delivery for someone > subject to the FIPS-only procurementrequirement > imposed on various US Government related entities, > then whatever OS theyuse, MUST (by that requirement) > have already passed this for its password handling. This is *technically* true, in the narrow sense that supposedly any OS used in DoD should be CC certified and so forth. Should not must. In practice it is very common -- at FIPS 140-2 Level 1 -- for software *products* to use FIPS 140-2 validated crypto on non-certified, non-validated operating systems. Just take a look at Table 2 in the OpenSSL FIPS Object Module Security Policy: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf and note that of the 101 platforms ("OEs") appearing there, most of those operating systems are neither CC certified nor have any other FIPS 140-2 validated crypto. Keep in mind that at Level 1 the validation applies to the cryptographic module, not the calling application that uses that module nor the operating system that runs it. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From jonetsu at teksavvy.com Tue Apr 14 13:42:17 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Tue, 14 Apr 2015 09:42:17 -0400 Subject: [openssl-users] FIPS mode restrictions and DES In-Reply-To: <552D164E.6070000@openssl.com> References: <5528114B.4060209@wisemo.com> <1428939189931-57527.post@n7.nabble.com> <552BEB5C.1040007@wisemo.com> <552BF355.4080008@openssl.com> <552BFD47.5010802@wisemo.com> <552D164E.6070000@openssl.com> Message-ID: > From: "Steve Marquess" > Date: 04/14/15 09:31 > and note that of the 101 platforms ("OEs") appearing there, most of > those operating systems are neither CC certified nor have any other FIPS > 140-2 validated crypto. Keep in mind that at Level 1 the validation > applies to the cryptographic module, not the calling application that > uses that module nor the operating system that runs it. I came across a Red Hat Security Policy document that clearly puts the XFRM out of the Security Policy domain.? See section 1.1.2, page 8, in: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1386.pdf This blurs the concept of FIPS validation.? Looks more and more that the validation will only care about what is being declared as going for validation.? In this case (policy might have changed since 2010) they simply say that no, we do not declare the crypto done via XFRM as part of the Security Policy.? And the FIPS lab says, OK, fine.? Hmmm.... Regards. From marquess at openssl.com Tue Apr 14 13:49:02 2015 From: marquess at openssl.com (Steve Marquess) Date: Tue, 14 Apr 2015 09:49:02 -0400 Subject: [openssl-users] FIPS mode restrictions and DES In-Reply-To: References: <5528114B.4060209@wisemo.com> <1428939189931-57527.post@n7.nabble.com> <552BEB5C.1040007@wisemo.com> <552BF355.4080008@openssl.com> <552BFD47.5010802@wisemo.com> <552D164E.6070000@openssl.com> Message-ID: <552D1ACE.7080506@openssl.com> On 04/14/2015 09:42 AM, jonetsu wrote: > > >> From: "Steve Marquess" Date: 04/14/15 09:31 >> > >> and note that of the 101 platforms ("OEs") appearing there, most >> of those operating systems are neither CC certified nor have any >> other FIPS 140-2 validated crypto. Keep in mind that at Level 1 the >> validation applies to the cryptographic module, not the calling >> application that uses that module nor the operating system that >> runs it. > > I came across a Red Hat Security Policy document that clearly puts > the XFRM out of the Security Policy domain. See section 1.1.2, page > 8, in: > > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1386.pdf > > This blurs the concept of FIPS validation. Looks more and more that > the validation will only care about what is being declared as going > for validation. In this case (policy might have changed since 2010) > they simply say that no, we do not declare the crypto done via XFRM > as part of the Security Policy. And the FIPS lab says, OK, fine. > Hmmm.... No, it doesn't blur anything. That is a Level 1 validation. At Level 1 only the "cryptographic module" is within scope of the FIPS 140-2 validation. The "cryptographic module" is a concept that is rather precisely defined in that context. You often hear the term "boundary" in reference to cryptographic modules. The operating system, and any crypto it may contain, is out of scope == outside the boundary. The calling application(s), and any other crypto it may contain, is out of scope. Any other applications residing on the same system, and any crypto they may contain, are out of scope. The Level 1 validation covers *only* the specific "cryptographic module". -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From John.Unsworth at owmessaging.com Tue Apr 14 16:17:06 2015 From: John.Unsworth at owmessaging.com (John Unsworth) Date: Tue, 14 Apr 2015 16:17:06 +0000 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: Message-ID: Is no-one interested at all about this problem? Or do I need to send it to another place? Regards, John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Unsworth Sent: 10 April 2015 14:54 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken I have compiled 1.0.1m in the same way and that works fine using asm. John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Unsworth Sent: 10 April 2015 12:21 To: openssl-users at openssl.org Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris 32 bit. I want to upgrade but both 1.0.2 and 1.0.2a cause problems. 1 When building 1.0.2 using ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 -xldscope=hidden openssl s_client crashes on start: -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 Segmentation Fault (core dumped) -bash-3.00$ pstack core core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4, 44) + 8 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, 2c0624) + 38c 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, 13000) + 138 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94 0001328c do_cmd (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8 00012f08 main (4, ffbffa84, 2eb4c8, 2a0000, 2b3e78, 2b4adc) + 3a4 00012a08 _start (0, 0, 0, 0, 0, 2b3e78) + 108 2 So I then rebuilt adding no-asm flag. It manages to connect but negotiation fails with an error: 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:s3_pkt.c:1456:SSL alert number 20 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: This is against the server that is still running 1.0.1h and can be successfully connected with openssl built with 1.0.1h. Note that the 64 bit build seems to work perfectly. Unfortunately for historical reasons we need to use the 32 bit version. The 32 bit builds that we use on Windows and Linux also work perfectly. Is it something to do with byte order? Regards, John. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Apr 14 16:41:03 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 14 Apr 2015 16:41:03 +0000 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: Message-ID: You could mail it to RT and then it will at least be logged and not forgotten. But no response within four days isn't surprising. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at redhat.com Tue Apr 14 18:45:23 2015 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 14 Apr 2015 20:45:23 +0200 Subject: [openssl-users] DTLS without sockets (or at least an unconnected socket) Message-ID: <552D6043.4080603@redhat.com> Is it possible to use DTLS with some sort of non-socket BIO? Basically, I have datagrams which I know belong to a specific DTLS session, and I want to feed them to OpenSSL and get back further datagrams to send out in response. (This is similar to what SSLEngine does in OpenJDK, except there it's for plain TLS.) An example how to establish a DTLS session with multiple peers over an unconnected socket would help, too. -- Florian Weimer / Red Hat Product Security From matt at openssl.org Tue Apr 14 19:02:34 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 14 Apr 2015 20:02:34 +0100 Subject: [openssl-users] DTLS without sockets (or at least an unconnected socket) In-Reply-To: <552D6043.4080603@redhat.com> References: <552D6043.4080603@redhat.com> Message-ID: <552D644A.1030601@openssl.org> On 14/04/15 19:45, Florian Weimer wrote: > Is it possible to use DTLS with some sort of non-socket BIO? > > Basically, I have datagrams which I know belong to a specific DTLS > session, and I want to feed them to OpenSSL and get back further > datagrams to send out in response. (This is similar to what SSLEngine > does in OpenJDK, except there it's for plain TLS.) DTLS currently supports UDP and SCTP for the underlying BIO. In theory you could implement your own BIO to do whatever you want but it would have to support the BIO ctrls that DTLS uses - see crypto/bio/bss_dgram.c (in particular the dgram_ctrl and dgram_sctp_ctrl functions) > > An example how to establish a DTLS session with multiple peers over an > unconnected socket would help, too. > To do that you need to use DTLSv1_listen(). I recently wrote a man page for this function, but it hasn't hit the repo yet. Attached FYI. You might also want to check this page: http://sctp.fh-muenster.de/index.html Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: DTLSv1_listen.pod Type: application/x-perl Size: 4030 bytes Desc: not available URL: From fweimer at redhat.com Tue Apr 14 19:24:13 2015 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 14 Apr 2015 21:24:13 +0200 Subject: [openssl-users] DTLS without sockets (or at least an unconnected socket) In-Reply-To: <552D644A.1030601@openssl.org> References: <552D6043.4080603@redhat.com> <552D644A.1030601@openssl.org> Message-ID: <552D695D.8060500@redhat.com> On 04/14/2015 09:02 PM, Matt Caswell wrote: > > > On 14/04/15 19:45, Florian Weimer wrote: >> Is it possible to use DTLS with some sort of non-socket BIO? >> >> Basically, I have datagrams which I know belong to a specific DTLS >> session, and I want to feed them to OpenSSL and get back further >> datagrams to send out in response. (This is similar to what SSLEngine >> does in OpenJDK, except there it's for plain TLS.) > > DTLS currently supports UDP and SCTP for the underlying BIO. In theory > you could implement your own BIO to do whatever you want but it would > have to support the BIO ctrls that DTLS uses - see > crypto/bio/bss_dgram.c (in particular the dgram_ctrl and dgram_sctp_ctrl > functions) Interesting. Is this part of the public API? >> An example how to establish a DTLS session with multiple peers over an >> unconnected socket would help, too. >> > > To do that you need to use DTLSv1_listen(). I recently wrote a man page > for this function, but it hasn't hit the repo yet. Attached FYI. Thanks. DTLSv1_listen is very odd because it has a socket address as an ?out? parameter, but no socket address length as an ?in/out? argument. It doesn't seem very transport-agnostic, either. -- Florian Weimer / Red Hat Product Security From kevpfowler at gmail.com Tue Apr 14 20:03:56 2015 From: kevpfowler at gmail.com (Kevin Fowler) Date: Tue, 14 Apr 2015 16:03:56 -0400 Subject: [openssl-users] FIPS mode restrictions and DES In-Reply-To: <1429015876160-57541.post@n7.nabble.com> References: <5528114B.4060209@wisemo.com> <1428939189931-57527.post@n7.nabble.com> <552BEB5C.1040007@wisemo.com> <552BF355.4080008@openssl.com> <552BFD47.5010802@wisemo.com> <1428947645188-57533.post@n7.nabble.com> <2f7c75080d9f4b7b9d8ddeb2f3a1c7d9@usma1ex-dag1mb2.msg.corp.akamai.com> <1429015876160-57541.post@n7.nabble.com> Message-ID: Two things to consider with IPSec: key exchange mechanisms as provided by packages like StrongSwan, and the actual encryption/authentication of packets that is typically being done by the kernel stack and I believe is based on the Kernel Crypto API. So I believe to do IPSec you do need both crypto "libraries" to be FIPS-validated, perhaps as separate crypto modules. Kevin On Tue, Apr 14, 2015 at 8:51 AM, jonetsu wrote: > Salz, Rich wrote > > As the old joke goes, "if you have to ask, you can't afford it." > > Well, exploration can be free. I noticed that Strongswan uses a plug-in > architecture for crypto that seemingly allows the use of OpenSSL instead of > the kernel for crypto operations, for use under FIPS. Does anyone have an > idea of the order of magnitude in performance loss this could be for IPSec, > to use crypto from OpenSSL instead of the kernel ? > > Regards. > > > > > -- > View this message in context: > http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57541.html > Sent from the OpenSSL - User mailing list archive at Nabble.com. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevpfowler at gmail.com Tue Apr 14 20:03:57 2015 From: kevpfowler at gmail.com (Kevin Fowler) Date: Tue, 14 Apr 2015 16:03:57 -0400 Subject: [openssl-users] FIPS mode restrictions and DES In-Reply-To: <1429015876160-57541.post@n7.nabble.com> References: <5528114B.4060209@wisemo.com> <1428939189931-57527.post@n7.nabble.com> <552BEB5C.1040007@wisemo.com> <552BF355.4080008@openssl.com> <552BFD47.5010802@wisemo.com> <1428947645188-57533.post@n7.nabble.com> <2f7c75080d9f4b7b9d8ddeb2f3a1c7d9@usma1ex-dag1mb2.msg.corp.akamai.com> <1429015876160-57541.post@n7.nabble.com> Message-ID: Two things to consider with IPSec: key exchange mechanisms as provided by packages like StrongSwan, and the actual encryption/authentication of packets that is typically being done by the kernel stack and I believe is based on the Kernel Crypto API. So I believe to do IPSec you do need both crypto "libraries" to be FIPS-validated, perhaps as separate crypto modules. Kevin On Tue, Apr 14, 2015 at 8:51 AM, jonetsu wrote: > Salz, Rich wrote > > As the old joke goes, "if you have to ask, you can't afford it." > > Well, exploration can be free. I noticed that Strongswan uses a plug-in > architecture for crypto that seemingly allows the use of OpenSSL instead of > the kernel for crypto operations, for use under FIPS. Does anyone have an > idea of the order of magnitude in performance loss this could be for IPSec, > to use crypto from OpenSSL instead of the kernel ? > > Regards. > > > > > -- > View this message in context: > http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57541.html > Sent from the OpenSSL - User mailing list archive at Nabble.com. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Apr 14 20:16:53 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 14 Apr 2015 21:16:53 +0100 Subject: [openssl-users] DTLS without sockets (or at least an unconnected socket) In-Reply-To: <552D695D.8060500@redhat.com> References: <552D6043.4080603@redhat.com> <552D644A.1030601@openssl.org> <552D695D.8060500@redhat.com> Message-ID: <552D75B5.7030209@openssl.org> On 14/04/15 20:24, Florian Weimer wrote: > On 04/14/2015 09:02 PM, Matt Caswell wrote: >> >> >> On 14/04/15 19:45, Florian Weimer wrote: >>> Is it possible to use DTLS with some sort of non-socket BIO? >>> >>> Basically, I have datagrams which I know belong to a specific DTLS >>> session, and I want to feed them to OpenSSL and get back further >>> datagrams to send out in response. (This is similar to what SSLEngine >>> does in OpenJDK, except there it's for plain TLS.) >> >> DTLS currently supports UDP and SCTP for the underlying BIO. In theory >> you could implement your own BIO to do whatever you want but it would >> have to support the BIO ctrls that DTLS uses - see >> crypto/bio/bss_dgram.c (in particular the dgram_ctrl and dgram_sctp_ctrl >> functions) > > Interesting. Is this part of the public API? Yes. To write your own BIO you would need to create a custom BIO_METHOD which is defined in bio.h. All of the various ctrls are also defined in bio.h. > >>> An example how to establish a DTLS session with multiple peers over an >>> unconnected socket would help, too. >>> >> >> To do that you need to use DTLSv1_listen(). I recently wrote a man page >> for this function, but it hasn't hit the repo yet. Attached FYI. > > Thanks. DTLSv1_listen is very odd because it has a socket address as an > ?out? parameter, but no socket address length as an ?in/out? argument. > It doesn't seem very transport-agnostic, either. > It is assumed that the sockaddr structure that you pass in is big enough for whatever addressing scheme the underlying BIO is using. Thus if you're listening on an IPv4 address pass in a pointer to a "struct sockaddr_in". If you're listening on an IPv6 address pass in a pointer to a "struct sockaddr_in6". Agreed, it's not particularly transport-agnostic. Perhaps just a plain "void *" would be better. By the time it gets passed to your BIO ctrl function (if you implement your own) it's been cast to a "void *" anyway! Matt From noloader at gmail.com Wed Apr 15 11:45:57 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 15 Apr 2015 07:45:57 -0400 Subject: [openssl-users] FIPS mode restrictions and DES In-Reply-To: <552D164E.6070000@openssl.com> References: <5528114B.4060209@wisemo.com> <1428939189931-57527.post@n7.nabble.com> <552BEB5C.1040007@wisemo.com> <552BF355.4080008@openssl.com> <552BFD47.5010802@wisemo.com> <552D164E.6070000@openssl.com> Message-ID: >> One point is that if this is a delivery for someone >> subject to the FIPS-only procurementrequirement >> imposed on various US Government related entities, >> then whatever OS theyuse, MUST (by that requirement) >> have already passed this for its password handling. > > This is *technically* true, in the narrow sense that supposedly any OS > used in DoD should be CC certified and so forth. Should not must. > > In practice it is very common -- at FIPS 140-2 Level 1 -- for software > *products* to use FIPS 140-2 validated crypto on non-certified, > non-validated operating systems. Just take a look at Table 2 in the > OpenSSL FIPS Object Module Security Policy: > > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf > > and note that of the 101 platforms ("OEs") appearing there, most of > those operating systems are neither CC certified nor have any other FIPS > 140-2 validated crypto. Keep in mind that at Level 1 the validation > applies to the cryptographic module, not the calling application that > uses that module nor the operating system that runs it. Another example is the various frameworks that provide the TextEdit boxes where passwords are entered. FIPS requires zeroization at level 1, and I guarantee none of those frameworks wipe the memory from the TextEdit. Hell, Apple has a secure allocator that does not even bother calling the secure deleter. It calls the default deleter for some reason. See the source code for libsecurity_utilities at [1,2,3]. And Apple really could have used zeroization: http://www.cnet.com/news/mac-os-x-lion-reveals-passwords-in-sleep-mode/. As this vulnerability shows, wiping secrets from memory is not a theoretical defense. [1] http://www.opensource.apple.com/source/libsecurity_keychain/libsecurity_keychain-40768/lib/SecKeychainItem.cpp [2] http://www.opensource.apple.com/source/libsecurity_keychain/libsecurity_keychain-40768/lib/Item.cpp [3] http://www.opensource.apple.com/source/libsecurity_utilities/libsecurity_utilities-38535/lib/alloc.cpp From noloader at gmail.com Wed Apr 15 11:59:22 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 15 Apr 2015 07:59:22 -0400 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: Message-ID: On Tue, Apr 14, 2015 at 12:17 PM, John Unsworth wrote: > Is no-one interested at all about this problem? Or do I need to send it to > another place? > Can you try with a different compiler? Is Clang available to you? (If not, I can provide you with a script or recipe to build it). Here's what one person was just saying about Sun's compiler on another list. He maintains another crypto-toolkit: > ... ghastly C compilers (or, in Sun's case, a non-C compiler that pretended > to be a compiler so you had to use all sorts of trickery to determine whether > there was a real compiler present or not). Otherwise, Rich's suggestion sounds like it might be the best that you can hope for. Jeff From foleyj at cisco.com Wed Apr 15 12:30:47 2015 From: foleyj at cisco.com (John Foley) Date: Wed, 15 Apr 2015 08:30:47 -0400 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: Message-ID: <552E59F7.8080506@cisco.com> Do you see the same stack trace when simply using the random number generator: ./openssl rand 64 What if you simply use SHA1: ./openssl sha1 On 04/14/2015 12:17 PM, John Unsworth wrote: > > Is no-one interested at all about this problem? Or do I need to send > it to another place? > > > > Regards, > > John. > > > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *John Unsworth > *Sent:* 10 April 2015 14:54 > *To:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is > broken > > > > I have compiled 1.0.1m in the same way and that works fine using asm. > > > > John. > > > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *John Unsworth > *Sent:* 10 April 2015 12:21 > *To:* openssl-users at openssl.org > *Subject:* [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken > > > > I have an application that runs quite happily using OpenSSL 1.0.1h on > Solaris 32 bit. I want to upgrade but both 1.0.2 and 1.0.2a cause > problems. > > > > 1 When building 1.0.2 using > > > > ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 > -xldscope=hidden > > > > openssl s_client crashes on start: > > > > -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 > > Segmentation Fault (core dumped) > > -bash-3.00$ pstack core > > core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250 > > 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4, > 44) + 8 > > 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530 > > 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, 2c0624) + 38c > > 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, 13000) + 138 > > 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88 > > 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94 > > 0001328c do_cmd (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8 > > 00012f08 main (4, ffbffa84, 2eb4c8, 2a0000, 2b3e78, 2b4adc) + 3a4 > > 00012a08 _start (0, 0, 0, 0, 0, 2b3e78) + 108 > > > > 2 So I then rebuilt adding no-asm flag. It manages to connect but > negotiation fails with an error: > > > > 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad > record mac:s3_pkt.c:1456:SSL alert number 20 > > 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake > failure:s23_lib.c:177: > > > > This is against the server that is still running 1.0.1h and can be > successfully connected with openssl built with 1.0.1h. > > > > Note that the 64 bit build seems to work perfectly. Unfortunately for > historical reasons we need to use the 32 bit version. > > > > The 32 bit builds that we use on Windows and Linux also work > perfectly. Is it something to do with byte order? > > > > Regards, > > John. > > > > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Unsworth at owmessaging.com Wed Apr 15 13:22:15 2015 From: John.Unsworth at owmessaging.com (John Unsworth) Date: Wed, 15 Apr 2015 13:22:15 +0000 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: Message-ID: Thanks for the suggestion. I rebuilt with gcc and get just the same problem. Regards, John. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jeffrey Walton Sent: 15 April 2015 12:59 To: OpenSSL Users List Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken On Tue, Apr 14, 2015 at 12:17 PM, John Unsworth wrote: > Is no-one interested at all about this problem? Or do I need to send it to > another place? > Can you try with a different compiler? Is Clang available to you? (If not, I can provide you with a script or recipe to build it). Here's what one person was just saying about Sun's compiler on another list. He maintains another crypto-toolkit: > ... ghastly C compilers (or, in Sun's case, a non-C compiler that pretended > to be a compiler so you had to use all sorts of trickery to determine whether > there was a real compiler present or not). Otherwise, Rich's suggestion sounds like it might be the best that you can hope for. Jeff _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From John.Unsworth at owmessaging.com Wed Apr 15 13:56:05 2015 From: John.Unsworth at owmessaging.com (John Unsworth) Date: Wed, 15 Apr 2015 13:56:05 +0000 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: <552E59F7.8080506@cisco.com> References: <552E59F7.8080506@cisco.com> Message-ID: core 'core' of 24243: ./openssl rand 64 000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018, ffbfe01c, 44) + 8 00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530 00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650, 2c0644) + 38c 00226c00 ssleay_rand_status (c734, 0, 2b9f7c, 2c05cc, 2a0e70, 13000) + 138 00065eb4 app_RAND_load_file (ffbfe418, 2d5238, 0, 2800, 0, 1) + 88 00077cb8 rand_main (0, 0, ff242b30, 0, 0, 0) + 4b8 0001328c do_cmd (2eb4e8, 2, ffbffae0, 2b4728, 13e64, 2b3e98) + b8 00012f08 main (3, ffbffadc, 2eb4e8, 2a0000, 2b3e98, 2b4afc) + 3a4 00012a08 _start (0, 0, 0, 0, 0, 2b3e98) + 108 Regards, John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Foley Sent: 15 April 2015 13:31 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken Do you see the same stack trace when simply using the random number generator: ./openssl rand 64 What if you simply use SHA1: ./openssl sha1 On 04/14/2015 12:17 PM, John Unsworth wrote: Is no-one interested at all about this problem? Or do I need to send it to another place? Regards, John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Unsworth Sent: 10 April 2015 14:54 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken I have compiled 1.0.1m in the same way and that works fine using asm. John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Unsworth Sent: 10 April 2015 12:21 To: openssl-users at openssl.org Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris 32 bit. I want to upgrade but both 1.0.2 and 1.0.2a cause problems. 1 When building 1.0.2 using ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 -xldscope=hidden openssl s_client crashes on start: -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 Segmentation Fault (core dumped) -bash-3.00$ pstack core core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4, 44) + 8 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, 2c0624) + 38c 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, 13000) + 138 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94 0001328c do_cmd (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8 00012f08 main (4, ffbffa84, 2eb4c8, 2a0000, 2b3e78, 2b4adc) + 3a4 00012a08 _start (0, 0, 0, 0, 0, 2b3e78) + 108 2 So I then rebuilt adding no-asm flag. It manages to connect but negotiation fails with an error: 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:s3_pkt.c:1456:SSL alert number 20 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: This is against the server that is still running 1.0.1h and can be successfully connected with openssl built with 1.0.1h. Note that the 64 bit build seems to work perfectly. Unfortunately for historical reasons we need to use the 32 bit version. The 32 bit builds that we use on Windows and Linux also work perfectly. Is it something to do with byte order? Regards, John. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From foleyj at cisco.com Wed Apr 15 14:10:08 2015 From: foleyj at cisco.com (John Foley) Date: Wed, 15 Apr 2015 10:10:08 -0400 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: <552E59F7.8080506@cisco.com> Message-ID: <552E7140.6060405@cisco.com> How about the ./openssl sha1 command? Does that bomb too? It might be interesting to copy crypto/sha/asm/sha1-sparcv9.pl from the 1.0.1 source into the 1.0.2 source. Then clean, configure, compile and try again. There were changes to this file between 1.0.1 and 1.0.2. Perhaps a bug was introduced. I'm assuming this script generates the SHA source for your target platform. On 04/15/2015 09:56 AM, John Unsworth wrote: > > core 'core' of 24243: ./openssl rand 64 > > 000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018, ffbfe01c, > 44) + 8 > > 00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530 > > 00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650, 2c0644) + 38c > > 00226c00 ssleay_rand_status (c734, 0, 2b9f7c, 2c05cc, 2a0e70, 13000) + 138 > > 00065eb4 app_RAND_load_file (ffbfe418, 2d5238, 0, 2800, 0, 1) + 88 > > 00077cb8 rand_main (0, 0, ff242b30, 0, 0, 0) + 4b8 > > 0001328c do_cmd (2eb4e8, 2, ffbffae0, 2b4728, 13e64, 2b3e98) + b8 > > 00012f08 main (3, ffbffadc, 2eb4e8, 2a0000, 2b3e98, 2b4afc) + 3a4 > > 00012a08 _start (0, 0, 0, 0, 0, 2b3e98) + 108 > > > > Regards, > > John. > > > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *John Foley > *Sent:* 15 April 2015 13:31 > *To:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is > broken > > > > Do you see the same stack trace when simply using the random number > generator: > > ./openssl rand 64 > > What if you simply use SHA1: > > ./openssl sha1 > > > On 04/14/2015 12:17 PM, John Unsworth wrote: > > Is no-one interested at all about this problem? Or do I need to > send it to another place? > > > > Regards, > > John. > > > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] > *On Behalf Of *John Unsworth > *Sent:* 10 April 2015 14:54 > *To:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build > is broken > > > > I have compiled 1.0.1m in the same way and that works fine using asm. > > > > John. > > > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] > *On Behalf Of *John Unsworth > *Sent:* 10 April 2015 12:21 > *To:* openssl-users at openssl.org > *Subject:* [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is > broken > > > > I have an application that runs quite happily using OpenSSL 1.0.1h > on Solaris 32 bit. I want to upgrade but both 1.0.2 and 1.0.2a > cause problems. > > > > 1 When building 1.0.2 using > > > > ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 > -xldscope=hidden > > > > openssl s_client crashes on start: > > > > -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 > > Segmentation Fault (core dumped) > > -bash-3.00$ pstack core > > core 'core' of 468: ./openssl s_client -connect > eos.es.cpth.ie:4250 > > 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, > ffbfebc4, 44) + 8 > > 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530 > > 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, > 2c0624) + 38c > > 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, > 13000) + 138 > > 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88 > > 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94 > > 0001328c do_cmd (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8 > > 00012f08 main (4, ffbffa84, 2eb4c8, 2a0000, 2b3e78, 2b4adc) + 3a4 > > 00012a08 _start (0, 0, 0, 0, 0, 2b3e78) + 108 > > > > 2 So I then rebuilt adding no-asm flag. It manages to connect but > negotiation fails with an error: > > > > 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert > bad record mac:s3_pkt.c:1456:SSL alert number 20 > > 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake > failure:s23_lib.c:177: > > > > This is against the server that is still running 1.0.1h and can be > successfully connected with openssl built with 1.0.1h. > > > > Note that the 64 bit build seems to work perfectly. Unfortunately > for historical reasons we need to use the 32 bit version. > > > > The 32 bit builds that we use on Windows and Linux also work > perfectly. Is it something to do with byte order? > > > > Regards, > > John. > > > > > > > > > _______________________________________________ > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Unsworth at owmessaging.com Wed Apr 15 15:13:16 2015 From: John.Unsworth at owmessaging.com (John Unsworth) Date: Wed, 15 Apr 2015 15:13:16 +0000 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: <552E7140.6060405@cisco.com> References: <552E59F7.8080506@cisco.com> <552E7140.6060405@cisco.com> Message-ID: That seems to have fixed the crash. -bash-3.00$ ./openssl rand 64 z??M??Ov??@?t????E?^?Q!?\?b_??Y???iT-&n?????B+?9kx??%hR?z-bash-3.00$ Not sure about the output though. However negotiation causes a core: -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 CONNECTED(00000004) depth=0 CN = jusworth-lt4.eu.cp.net verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = jusworth-lt4.eu.cp.net verify error:num=21:unable to verify the first certificate verify return:1 Segmentation Fault (core dumped) -bash-3.00$ pstack core core 'core' of 12587: ./openssl s_client -connect eos.es.cpth.ie:4250 000ed408 sha512_block_data_order (30e538, 30c050, 71a, 30e588, 30c050, 64f98fa7) + 8 0009fb30 ssl3_digest_cached_records (2f8ae0, 6, 2f8ea0, 14, 100, 2f8ea0) + 1cc 000980ec ssl3_get_certificate_request (2f8ae0, 2f8ea0, 2f8ea0, 10, a42e0, 2f8ae0) + 90 00093ad8 ssl3_connect (2f8ae0, 0, 1180, 1000, 1130, ffffffff) + 6c0 000aa2b8 ssl23_get_server_hello (2f8ae0, 16, 3, 3, 2f8ea0, 301638) + 648 000a9198 ssl23_connect (2f8ae0, 0, 3000, 2b4d64, 2b3d78, 1) + 588 000aa60c ssl23_write (2f8ae0, 2f0270, 0, 3000, ff247c94, a8c10) + 4c 0004ee64 s_client_main (0, 0, 1, 2b4d64, 2f8ae0, 2f4280) + 7374 0001328c do_cmd (2eb3c8, 3, ffbffad0, 2b4638, 13e64, 2b3d78) + b8 00012f08 main (4, ffbffacc, 2eb3c8, 29fc00, 2b3d78, 2b49dc) + 3a4 00012a08 _start (0, 0, 0, 0, 0, 2b3d78) + 108 Regards, John From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Foley Sent: 15 April 2015 15:10 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken How about the ./openssl sha1 command? Does that bomb too? It might be interesting to copy crypto/sha/asm/sha1-sparcv9.pl from the 1.0.1 source into the 1.0.2 source. Then clean, configure, compile and try again. There were changes to this file between 1.0.1 and 1.0.2. Perhaps a bug was introduced. I'm assuming this script generates the SHA source for your target platform. On 04/15/2015 09:56 AM, John Unsworth wrote: core 'core' of 24243: ./openssl rand 64 000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018, ffbfe01c, 44) + 8 00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530 00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650, 2c0644) + 38c 00226c00 ssleay_rand_status (c734, 0, 2b9f7c, 2c05cc, 2a0e70, 13000) + 138 00065eb4 app_RAND_load_file (ffbfe418, 2d5238, 0, 2800, 0, 1) + 88 00077cb8 rand_main (0, 0, ff242b30, 0, 0, 0) + 4b8 0001328c do_cmd (2eb4e8, 2, ffbffae0, 2b4728, 13e64, 2b3e98) + b8 00012f08 main (3, ffbffadc, 2eb4e8, 2a0000, 2b3e98, 2b4afc) + 3a4 00012a08 _start (0, 0, 0, 0, 0, 2b3e98) + 108 Regards, John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Foley Sent: 15 April 2015 13:31 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken Do you see the same stack trace when simply using the random number generator: ./openssl rand 64 What if you simply use SHA1: ./openssl sha1 On 04/14/2015 12:17 PM, John Unsworth wrote: Is no-one interested at all about this problem? Or do I need to send it to another place? Regards, John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Unsworth Sent: 10 April 2015 14:54 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken I have compiled 1.0.1m in the same way and that works fine using asm. John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Unsworth Sent: 10 April 2015 12:21 To: openssl-users at openssl.org Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris 32 bit. I want to upgrade but both 1.0.2 and 1.0.2a cause problems. 1 When building 1.0.2 using ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 -xldscope=hidden openssl s_client crashes on start: -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 Segmentation Fault (core dumped) -bash-3.00$ pstack core core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4, 44) + 8 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, 2c0624) + 38c 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, 13000) + 138 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94 0001328c do_cmd (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8 00012f08 main (4, ffbffa84, 2eb4c8, 2a0000, 2b3e78, 2b4adc) + 3a4 00012a08 _start (0, 0, 0, 0, 0, 2b3e78) + 108 2 So I then rebuilt adding no-asm flag. It manages to connect but negotiation fails with an error: 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:s3_pkt.c:1456:SSL alert number 20 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: This is against the server that is still running 1.0.1h and can be successfully connected with openssl built with 1.0.1h. Note that the 64 bit build seems to work perfectly. Unfortunately for historical reasons we need to use the 32 bit version. The 32 bit builds that we use on Windows and Linux also work perfectly. Is it something to do with byte order? Regards, John. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From foleyj at cisco.com Wed Apr 15 15:44:40 2015 From: foleyj at cisco.com (John Foley) Date: Wed, 15 Apr 2015 11:44:40 -0400 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: <552E59F7.8080506@cisco.com> <552E7140.6060405@cisco.com> Message-ID: <552E8768.6060704@cisco.com> Looks like the crash is in SHA-512 this time, not SHA-1. There's a separate perl script to generate that assembly code. Try the 1.0.1 version of sha512-sparcv9.pl. The output from your rand command is valid. You can use the -base64 option if you want something more readable. On 04/15/2015 11:13 AM, John Unsworth wrote: > > That seems to have fixed the crash. > > > > -bash-3.00$ ./openssl rand 64 > > z??M??Ov??@?t????E?^?Q!?\?b_??Y???iT-&n?????B+?9kx??%hR?z-bash-3.00$ > > > > Not sure about the output though. > > > > However negotiation causes a core: > > > > -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 > > CONNECTED(00000004) > > depth=0 CN = jusworth-lt4.eu.cp.net > > verify error:num=20:unable to get local issuer certificate > > verify return:1 > > depth=0 CN = jusworth-lt4.eu.cp.net > > verify error:num=21:unable to verify the first certificate > > verify return:1 > > Segmentation Fault (core dumped) > > -bash-3.00$ pstack core > > core 'core' of 12587: ./openssl s_client -connect eos.es.cpth.ie:4250 > > 000ed408 sha512_block_data_order (30e538, 30c050, 71a, 30e588, 30c050, > 64f98fa7) + 8 > > 0009fb30 ssl3_digest_cached_records (2f8ae0, 6, 2f8ea0, 14, 100, > 2f8ea0) + 1cc > > 000980ec ssl3_get_certificate_request (2f8ae0, 2f8ea0, 2f8ea0, 10, > a42e0, 2f8ae0) + 90 > > 00093ad8 ssl3_connect (2f8ae0, 0, 1180, 1000, 1130, ffffffff) + 6c0 > > 000aa2b8 ssl23_get_server_hello (2f8ae0, 16, 3, 3, 2f8ea0, 301638) + 648 > > 000a9198 ssl23_connect (2f8ae0, 0, 3000, 2b4d64, 2b3d78, 1) + 588 > > 000aa60c ssl23_write (2f8ae0, 2f0270, 0, 3000, ff247c94, a8c10) + 4c > > 0004ee64 s_client_main (0, 0, 1, 2b4d64, 2f8ae0, 2f4280) + 7374 > > 0001328c do_cmd (2eb3c8, 3, ffbffad0, 2b4638, 13e64, 2b3d78) + b8 > > 00012f08 main (4, ffbffacc, 2eb3c8, 29fc00, 2b3d78, 2b49dc) + 3a4 > > 00012a08 _start (0, 0, 0, 0, 0, 2b3d78) + 108 > > > > Regards, > > John > > > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *John Foley > *Sent:* 15 April 2015 15:10 > *To:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is > broken > > > > How about the ./openssl sha1 command? Does that bomb too? > > It might be interesting to copy crypto/sha/asm/sha1-sparcv9.pl from > the 1.0.1 source into the 1.0.2 source. Then clean, configure, > compile and try again. There were changes to this file between 1.0.1 > and 1.0.2. Perhaps a bug was introduced. I'm assuming this script > generates the SHA source for your target platform. > > > On 04/15/2015 09:56 AM, John Unsworth wrote: > > core 'core' of 24243: ./openssl rand 64 > > 000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018, > ffbfe01c, 44) + 8 > > 00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530 > > 00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650, > 2c0644) + 38c > > 00226c00 ssleay_rand_status (c734, 0, 2b9f7c, 2c05cc, 2a0e70, > 13000) + 138 > > 00065eb4 app_RAND_load_file (ffbfe418, 2d5238, 0, 2800, 0, 1) + 88 > > 00077cb8 rand_main (0, 0, ff242b30, 0, 0, 0) + 4b8 > > 0001328c do_cmd (2eb4e8, 2, ffbffae0, 2b4728, 13e64, 2b3e98) + b8 > > 00012f08 main (3, ffbffadc, 2eb4e8, 2a0000, 2b3e98, 2b4afc) + 3a4 > > 00012a08 _start (0, 0, 0, 0, 0, 2b3e98) + 108 > > > > Regards, > > John. > > > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] > *On Behalf Of *John Foley > *Sent:* 15 April 2015 13:31 > *To:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build > is broken > > > > Do you see the same stack trace when simply using the random > number generator: > > ./openssl rand 64 > > What if you simply use SHA1: > > ./openssl sha1 > > > > On 04/14/2015 12:17 PM, John Unsworth wrote: > > Is no-one interested at all about this problem? Or do I need > to send it to another place? > > > > Regards, > > John. > > > > *From:*openssl-users > [mailto:openssl-users-bounces at openssl.org] *On Behalf Of *John > Unsworth > *Sent:* 10 April 2015 14:54 > *To:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit > build is broken > > > > I have compiled 1.0.1m in the same way and that works fine > using asm. > > > > John. > > > > *From:*openssl-users > [mailto:openssl-users-bounces at openssl.org] *On Behalf Of *John > Unsworth > *Sent:* 10 April 2015 12:21 > *To:* openssl-users at openssl.org > *Subject:* [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build > is broken > > > > I have an application that runs quite happily using OpenSSL > 1.0.1h on Solaris 32 bit. I want to upgrade but both 1.0.2 and > 1.0.2a cause problems. > > > > 1 When building 1.0.2 using > > > > ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 > -xldscope=hidden > > > > openssl s_client crashes on start: > > > > -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 > > Segmentation Fault (core dumped) > > -bash-3.00$ pstack core > > core 'core' of 468: ./openssl s_client -connect > eos.es.cpth.ie:4250 > > 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, > ffbfebc4, 44) + 8 > > 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530 > > 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, > 2c0624) + 38c > > 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, > 13000) + 138 > > 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88 > > 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94 > > 0001328c do_cmd (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) > + b8 > > 00012f08 main (4, ffbffa84, 2eb4c8, 2a0000, 2b3e78, > 2b4adc) + 3a4 > > 00012a08 _start (0, 0, 0, 0, 0, 2b3e78) + 108 > > > > 2 So I then rebuilt adding no-asm flag. It manages to connect > but negotiation fails with an error: > > > > 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 > alert bad record mac:s3_pkt.c:1456:SSL alert number 20 > > 4280581268:error:140790E5:SSL routines:ssl23_write:ssl > handshake failure:s23_lib.c:177: > > > > This is against the server that is still running 1.0.1h and > can be successfully connected with openssl built with 1.0.1h. > > > > Note that the 64 bit build seems to work perfectly. > Unfortunately for historical reasons we need to use the 32 bit > version. > > > > The 32 bit builds that we use on Windows and Linux also work > perfectly. Is it something to do with byte order? > > > > Regards, > > John. > > > > > > > > > > _______________________________________________ > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > _______________________________________________ > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Unsworth at owmessaging.com Wed Apr 15 16:26:31 2015 From: John.Unsworth at owmessaging.com (John Unsworth) Date: Wed, 15 Apr 2015 16:26:31 +0000 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: <552E8768.6060704@cisco.com> References: <552E59F7.8080506@cisco.com> <552E7140.6060405@cisco.com> <552E8768.6060704@cisco.com> Message-ID: Still exactly the same crash. And even if these assembly code problems can be fixed there is still the negotiation error after compiling with no-asm. 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:s3_pkt.c:1456:SSL alert number 20 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Foley Sent: 15 April 2015 16:45 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken Looks like the crash is in SHA-512 this time, not SHA-1. There's a separate perl script to generate that assembly code. Try the 1.0.1 version of sha512-sparcv9.pl. The output from your rand command is valid. You can use the -base64 option if you want something more readable. On 04/15/2015 11:13 AM, John Unsworth wrote: That seems to have fixed the crash. -bash-3.00$ ./openssl rand 64 z??M??Ov??@?t????E?^?Q!?\?b_??Y???iT-&n?????B+?9kx??%hR?z-bash-3.00$ Not sure about the output though. However negotiation causes a core: -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 CONNECTED(00000004) depth=0 CN = jusworth-lt4.eu.cp.net verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = jusworth-lt4.eu.cp.net verify error:num=21:unable to verify the first certificate verify return:1 Segmentation Fault (core dumped) -bash-3.00$ pstack core core 'core' of 12587: ./openssl s_client -connect eos.es.cpth.ie:4250 000ed408 sha512_block_data_order (30e538, 30c050, 71a, 30e588, 30c050, 64f98fa7) + 8 0009fb30 ssl3_digest_cached_records (2f8ae0, 6, 2f8ea0, 14, 100, 2f8ea0) + 1cc 000980ec ssl3_get_certificate_request (2f8ae0, 2f8ea0, 2f8ea0, 10, a42e0, 2f8ae0) + 90 00093ad8 ssl3_connect (2f8ae0, 0, 1180, 1000, 1130, ffffffff) + 6c0 000aa2b8 ssl23_get_server_hello (2f8ae0, 16, 3, 3, 2f8ea0, 301638) + 648 000a9198 ssl23_connect (2f8ae0, 0, 3000, 2b4d64, 2b3d78, 1) + 588 000aa60c ssl23_write (2f8ae0, 2f0270, 0, 3000, ff247c94, a8c10) + 4c 0004ee64 s_client_main (0, 0, 1, 2b4d64, 2f8ae0, 2f4280) + 7374 0001328c do_cmd (2eb3c8, 3, ffbffad0, 2b4638, 13e64, 2b3d78) + b8 00012f08 main (4, ffbffacc, 2eb3c8, 29fc00, 2b3d78, 2b49dc) + 3a4 00012a08 _start (0, 0, 0, 0, 0, 2b3d78) + 108 Regards, John From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Foley Sent: 15 April 2015 15:10 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken How about the ./openssl sha1 command? Does that bomb too? It might be interesting to copy crypto/sha/asm/sha1-sparcv9.pl from the 1.0.1 source into the 1.0.2 source. Then clean, configure, compile and try again. There were changes to this file between 1.0.1 and 1.0.2. Perhaps a bug was introduced. I'm assuming this script generates the SHA source for your target platform. On 04/15/2015 09:56 AM, John Unsworth wrote: core 'core' of 24243: ./openssl rand 64 000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018, ffbfe01c, 44) + 8 00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530 00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650, 2c0644) + 38c 00226c00 ssleay_rand_status (c734, 0, 2b9f7c, 2c05cc, 2a0e70, 13000) + 138 00065eb4 app_RAND_load_file (ffbfe418, 2d5238, 0, 2800, 0, 1) + 88 00077cb8 rand_main (0, 0, ff242b30, 0, 0, 0) + 4b8 0001328c do_cmd (2eb4e8, 2, ffbffae0, 2b4728, 13e64, 2b3e98) + b8 00012f08 main (3, ffbffadc, 2eb4e8, 2a0000, 2b3e98, 2b4afc) + 3a4 00012a08 _start (0, 0, 0, 0, 0, 2b3e98) + 108 Regards, John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Foley Sent: 15 April 2015 13:31 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken Do you see the same stack trace when simply using the random number generator: ./openssl rand 64 What if you simply use SHA1: ./openssl sha1 On 04/14/2015 12:17 PM, John Unsworth wrote: Is no-one interested at all about this problem? Or do I need to send it to another place? Regards, John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Unsworth Sent: 10 April 2015 14:54 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken I have compiled 1.0.1m in the same way and that works fine using asm. John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Unsworth Sent: 10 April 2015 12:21 To: openssl-users at openssl.org Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris 32 bit. I want to upgrade but both 1.0.2 and 1.0.2a cause problems. 1 When building 1.0.2 using ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 -xldscope=hidden openssl s_client crashes on start: -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 Segmentation Fault (core dumped) -bash-3.00$ pstack core core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4, 44) + 8 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, 2c0624) + 38c 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, 13000) + 138 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94 0001328c do_cmd (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8 00012f08 main (4, ffbffa84, 2eb4c8, 2a0000, 2b3e78, 2b4adc) + 3a4 00012a08 _start (0, 0, 0, 0, 0, 2b3e78) + 108 2 So I then rebuilt adding no-asm flag. It manages to connect but negotiation fails with an error: 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:s3_pkt.c:1456:SSL alert number 20 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: This is against the server that is still running 1.0.1h and can be successfully connected with openssl built with 1.0.1h. Note that the 64 bit build seems to work perfectly. Unfortunately for historical reasons we need to use the 32 bit version. The 32 bit builds that we use on Windows and Linux also work perfectly. Is it something to do with byte order? Regards, John. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Apr 15 10:37:01 2015 From: rt at openssl.org (The default queue via RT) Date: Wed, 15 Apr 2015 12:37:01 +0200 Subject: [openssl-users] [openssl.org #3804] AutoReply: BUG: OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: Message-ID: Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "BUG: OpenSSL 1.0.2 Solaris 32 bit build is broken", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [openssl.org #3804]. Please include the string: [openssl.org #3804] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, rt at openssl.org ------------------------------------------------------------------------- I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris 32 bit. I want to upgrade but neither 1.0.2 nor 1.0.2a work. Solaris 10 Solaris Studio 12.4 Make test log attached. 1 When building 1.0.2 using ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 -xldscope=hidden openssl s_client crashes on start: -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 Segmentation Fault (core dumped) -bash-3.00$ pstack core core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4, 44) + 8 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, 2c0624) + 38c 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, 13000) + 138 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94 0001328c do_cmd (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8 00012f08 main (4, ffbffa84, 2eb4c8, 2a0000, 2b3e78, 2b4adc) + 3a4 00012a08 _start (0, 0, 0, 0, 0, 2b3e78) + 108 2 So I then rebuilt adding no-asm flag. It manages to connect but negotiation fails with an error: 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:s3_pkt.c:1456:SSL alert number 20 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: This is against the server that is still running 1.0.1h and can be successfully connected with openssl s_client built with 1.0.1h. The 64 bit build seems to work perfectly. The 32 bit builds that we use on Windows and Linux also work perfectly. 1.0.2a build fails in the same way. gcc build fails in the same way. I have built 1.0.1m with asm and that works fine. Regards, John. From carson at taltos.org Wed Apr 15 18:40:12 2015 From: carson at taltos.org (Carson Gaspar) Date: Wed, 15 Apr 2015 11:40:12 -0700 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: Message-ID: <552EB08C.5000702@taltos.org> On 4/15/15 4:59 AM, Jeffrey Walton wrote: > Can you try with a different compiler? Is Clang available to you? (If > not, I can provide you with a script or recipe to build it). > > Here's what one person was just saying about Sun's compiler on another > list. He maintains another crypto-toolkit: > >> ... ghastly C compilers (or, in Sun's case, a non-C compiler that pretended >> to be a compiler so you had to use all sorts of trickery to determine whether >> there was a real compiler present or not). Libel. Once Upon a Time, Sun shipped something called /usr/ucb/cc which was an abomination, but wouldn't be in any sane user's PATH. Oracle ships gcc (which compiles a language called gcc, which only vaguely resembles C, because the authors don't believe in the C standards), and also has the Solaris Studio compiler suite, which is an excellent C compiler (but doesn't know all of the bizarre dialects of gcc, e.g. 'a ?: b' *shudder*). The real issue is usually inline assembly being in GNU format, which is incompatible with all others. Oracle's /usr/ccs/bin/as doesn't always understand all the GNUisms. But none of this is relevant to the OP's issue. -- Carson From John.Unsworth at owmessaging.com Wed Apr 15 19:34:35 2015 From: John.Unsworth at owmessaging.com (John Unsworth) Date: Wed, 15 Apr 2015 19:34:35 +0000 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: Message-ID: Bug opened. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich Sent: 14 April 2015 17:41 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken You could mail it to RT and then it will at least be logged and not forgotten. But no response within four days isn't surprising. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Wed Apr 15 19:47:45 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 15 Apr 2015 19:47:45 +0000 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: <552EB08C.5000702@taltos.org> References: <552EB08C.5000702@taltos.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Carson Gaspar > Sent: Wednesday, April 15, 2015 14:40 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken > > On 4/15/15 4:59 AM, Jeffrey Walton wrote: > > > Here's what one person was just saying about Sun's compiler on another > > list. He maintains another crypto-toolkit: > > > >> ... ghastly C compilers (or, in Sun's case, a non-C compiler that pretended > >> to be a compiler so you had to use all sorts of trickery to determine > whether > >> there was a real compiler present or not). > > Libel. Once Upon a Time, Sun shipped something called /usr/ucb/cc which > was an abomination, but wouldn't be in any sane user's PATH. Oracle > ships gcc (which compiles a language called gcc, which only vaguely > resembles C, because the authors don't believe in the C standards), and > also has the Solaris Studio compiler suite, which is an excellent C > compiler (but doesn't know all of the bizarre dialects of gcc, e.g. 'a > ?: b' *shudder*). > > The real issue is usually inline assembly being in GNU format, which is > incompatible with all others. Oracle's /usr/ccs/bin/as doesn't always > understand all the GNUisms. Thanks. I had resisted posting something similar. I was particularly irked by the context-less, hearsay claim that the Solaris C compiler isn't a conforming implementation. Oh yeah? How not? Usually when I see someone complain about a C implementation, it's because they haven't bothered to check ISO 9899 and find out what C actually is. I'll also note that I've been writing C code for numerous platforms (MS-DOS, all the incarnations of Windows, many UNIX variants, OS/400, z/OS...) for decades, and the Solaris compilers have *never* given me problems. That's more than I can say for the compilers from Microsoft, HP, and some other vendors. Or for GCC, even when beaten into "OK, I'll try really hard to pretend to be C" mode. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com From foleyj at cisco.com Wed Apr 15 20:08:55 2015 From: foleyj at cisco.com (John Foley) Date: Wed, 15 Apr 2015 16:08:55 -0400 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: <552E59F7.8080506@cisco.com> <552E7140.6060405@cisco.com> <552E8768.6060704@cisco.com> Message-ID: <552EC557.4020907@cisco.com> This appears to be a different problem than the crash in SHA. Since you're seeing a "bad record mac", it appears the TLS handshake has made it through the ChangeCipherSpec message. Do you know which cipher suite is being negotiated? If it's AES, it may be worth trying a 3DES cipher suite. If the issue is in the AES layer, one of the 3DES cipher suites should work. By the way, have you run a 'make test' after building OpenSSL? Are all the test suites passing? If not, which one is failing? On 04/15/2015 12:26 PM, John Unsworth wrote: > > Still exactly the same crash. And even if these assembly code problems > can be fixed there is still the negotiation error after compiling with > no-asm. > > > > 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad > record mac:s3_pkt.c:1456:SSL alert number 20 > > 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake > failure:s23_lib.c:177: > > > > John. > > > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *John Foley > *Sent:* 15 April 2015 16:45 > *To:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is > broken > > > > Looks like the crash is in SHA-512 this time, not SHA-1. There's a > separate perl script to generate that assembly code. Try the 1.0.1 > version of sha512-sparcv9.pl. > > The output from your rand command is valid. You can use the -base64 > option if you want something more readable. > > > On 04/15/2015 11:13 AM, John Unsworth wrote: > > That seems to have fixed the crash. > > > > -bash-3.00$ ./openssl rand 64 > > z??M??Ov??@?t????E?^?Q!?\?b_??Y???iT-&n?????B+?9kx??%hR?z-bash-3.00$ > > > > Not sure about the output though. > > > > However negotiation causes a core: > > > > -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 > > CONNECTED(00000004) > > depth=0 CN = jusworth-lt4.eu.cp.net > > verify error:num=20:unable to get local issuer certificate > > verify return:1 > > depth=0 CN = jusworth-lt4.eu.cp.net > > verify error:num=21:unable to verify the first certificate > > verify return:1 > > Segmentation Fault (core dumped) > > -bash-3.00$ pstack core > > core 'core' of 12587: ./openssl s_client -connect > eos.es.cpth.ie:4250 > > 000ed408 sha512_block_data_order (30e538, 30c050, 71a, 30e588, > 30c050, 64f98fa7) + 8 > > 0009fb30 ssl3_digest_cached_records (2f8ae0, 6, 2f8ea0, 14, 100, > 2f8ea0) + 1cc > > 000980ec ssl3_get_certificate_request (2f8ae0, 2f8ea0, 2f8ea0, 10, > a42e0, 2f8ae0) + 90 > > 00093ad8 ssl3_connect (2f8ae0, 0, 1180, 1000, 1130, ffffffff) + 6c0 > > 000aa2b8 ssl23_get_server_hello (2f8ae0, 16, 3, 3, 2f8ea0, 301638) > + 648 > > 000a9198 ssl23_connect (2f8ae0, 0, 3000, 2b4d64, 2b3d78, 1) + 588 > > 000aa60c ssl23_write (2f8ae0, 2f0270, 0, 3000, ff247c94, a8c10) + 4c > > 0004ee64 s_client_main (0, 0, 1, 2b4d64, 2f8ae0, 2f4280) + 7374 > > 0001328c do_cmd (2eb3c8, 3, ffbffad0, 2b4638, 13e64, 2b3d78) + b8 > > 00012f08 main (4, ffbffacc, 2eb3c8, 29fc00, 2b3d78, 2b49dc) + 3a4 > > 00012a08 _start (0, 0, 0, 0, 0, 2b3d78) + 108 > > > > Regards, > > John > > > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] > *On Behalf Of *John Foley > *Sent:* 15 April 2015 15:10 > *To:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build > is broken > > > > How about the ./openssl sha1 command? Does that bomb too? > > It might be interesting to copy crypto/sha/asm/sha1-sparcv9.pl > from the 1.0.1 source into the 1.0.2 source. Then clean, > configure, compile and try again. There were changes to this file > between 1.0.1 and 1.0.2. Perhaps a bug was introduced. I'm > assuming this script generates the SHA source for your target > platform. > > > > On 04/15/2015 09:56 AM, John Unsworth wrote: > > core 'core' of 24243: ./openssl rand 64 > > 000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018, > ffbfe01c, 44) + 8 > > 00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530 > > 00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650, > 2c0644) + 38c > > 00226c00 ssleay_rand_status (c734, 0, 2b9f7c, 2c05cc, 2a0e70, > 13000) + 138 > > 00065eb4 app_RAND_load_file (ffbfe418, 2d5238, 0, 2800, 0, 1) + 88 > > 00077cb8 rand_main (0, 0, ff242b30, 0, 0, 0) + 4b8 > > 0001328c do_cmd (2eb4e8, 2, ffbffae0, 2b4728, 13e64, 2b3e98) > + b8 > > 00012f08 main (3, ffbffadc, 2eb4e8, 2a0000, 2b3e98, > 2b4afc) + 3a4 > > 00012a08 _start (0, 0, 0, 0, 0, 2b3e98) + 108 > > > > Regards, > > John. > > > > *From:*openssl-users > [mailto:openssl-users-bounces at openssl.org] *On Behalf Of *John > Foley > *Sent:* 15 April 2015 13:31 > *To:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit > build is broken > > > > Do you see the same stack trace when simply using the random > number generator: > > ./openssl rand 64 > > What if you simply use SHA1: > > ./openssl sha1 > > > > > On 04/14/2015 12:17 PM, John Unsworth wrote: > > Is no-one interested at all about this problem? Or do I > need to send it to another place? > > > > Regards, > > John. > > > > *From:*openssl-users > [mailto:openssl-users-bounces at openssl.org] *On Behalf Of > *John Unsworth > *Sent:* 10 April 2015 14:54 > *To:* openssl-users at openssl.org > > *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 > bit build is broken > > > > I have compiled 1.0.1m in the same way and that works fine > using asm. > > > > John. > > > > *From:*openssl-users > [mailto:openssl-users-bounces at openssl.org] *On Behalf Of > *John Unsworth > *Sent:* 10 April 2015 12:21 > *To:* openssl-users at openssl.org > > *Subject:* [openssl-users] OpenSSL 1.0.2 Solaris 32 bit > build is broken > > > > I have an application that runs quite happily using > OpenSSL 1.0.1h on Solaris 32 bit. I want to upgrade but > both 1.0.2 and 1.0.2a cause problems. > > > > 1 When building 1.0.2 using > > > > ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 > -xldscope=hidden > > > > openssl s_client crashes on start: > > > > -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 > > Segmentation Fault (core dumped) > > -bash-3.00$ pstack core > > core 'core' of 468: ./openssl s_client -connect > eos.es.cpth.ie:4250 > > 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, > ffbfebc0, ffbfebc4, 44) + 8 > > 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, > 14) + 530 > > 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, > 2c0630, 2c0624) + 38c > > 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, > 2a0e50, 13000) + 138 > > 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, > 1) + 88 > > 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94 > > 0001328c do_cmd (2eb4c8, 3, ffbffa88, 2b4738, 13e64, > 2b3e78) + b8 > > 00012f08 main (4, ffbffa84, 2eb4c8, 2a0000, 2b3e78, > 2b4adc) + 3a4 > > 00012a08 _start (0, 0, 0, 0, 0, 2b3e78) + 108 > > > > 2 So I then rebuilt adding no-asm flag. It manages to > connect but negotiation fails with an error: > > > > 4280581268:error:140943FC:SSL > routines:ssl3_read_bytes:sslv3 alert bad record > mac:s3_pkt.c:1456:SSL alert number 20 > > 4280581268:error:140790E5:SSL routines:ssl23_write:ssl > handshake failure:s23_lib.c:177: > > > > This is against the server that is still running 1.0.1h > and can be successfully connected with openssl built with > 1.0.1h. > > > > Note that the 64 bit build seems to work perfectly. > Unfortunately for historical reasons we need to use the 32 > bit version. > > > > The 32 bit builds that we use on Windows and Linux also > work perfectly. Is it something to do with byte order? > > > > Regards, > > John. > > > > > > > > > > > _______________________________________________ > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > _______________________________________________ > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > _______________________________________________ > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Charles.Barbe at allworx.com Wed Apr 15 21:43:48 2015 From: Charles.Barbe at allworx.com (Barbe, Charles) Date: Wed, 15 Apr 2015 21:43:48 +0000 Subject: [openssl-users] af_alg engine: digests work but ciphers do not? Message-ID: I'm wondering if anybody has any experience with the af_alg engine located here: http://src.carnivore.it/users/common/af_alg/about/ I am able to compile the engine and can run commands such as: openssl speed md5 -engine af_alg and I see that openssl has loaded the engine as indicated by this line in the output: engine "af_alg" set and can enable dmesg logging on the linux driver for my particular hardware and see that the driver is being used as expected. However, if I try to do a cipher instead of a digest, my driver is not used. For example, when I run: openssl speed aes-256-cbc -engine af_alg I see the engine get loaded but my dmesg logging indicates that the kernel driver was not used. And i get the same results for any of my supported ciphers. I have followed all the instructions in the URL located above including modifying my openssl.conf to include the proper configuration of the supported ciphers for my hardware but to no avail. Here is what the top of my openssl.conf looks like: # # OpenSSL example configuration file. # This is mostly being used for generation of certificate requests. # # This definition stops the following lines choking if HOME isn't # defined. HOME = . RANDFILE = $ENV::HOME/.rnd # Extra OBJECT IDENTIFIER info: #oid_file = $ENV::HOME/.oid oid_section = new_oids openssl_conf = openssl_def [openssl_def] engines = openssl_engines [openssl_engines] af_alg = af_alg_engine [af_alg_engine] default_algorithms = ALL CIPHERS=aes-128-cbc aes-192-cbc aes-256-cbc des-cbc des-ede3-cbc DIGESTS=md4 md5 sha1 sha224 sha256 sha512 # To use this configuration file with the "-extfile" option of the # "openssl x509" utility, name here the section containing the # X.509v3 extensions to use: # extensions = # (Alternatively, use a configuration file that has only # X.509v3 extensions in its main [= default] section.) [ new_oids ] # We can add new OIDs in here for use by 'ca', 'req' and 'ts'. For reference, I am running the following: linux kernel v 3.19 openssl v 1.0.1m running on a TI am3352 Any help on why digests seem to be working with the af_alg engine but ciphers do not would be much appreciated. Charles A. Barbe Senior Software Engineer Allworx, a Windstream company 245 East Main St | Rochester NY | 14604 Charles.Barbe at allworx.com | 585.421.5565 ---------------------------------------------------------------------- This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. From John.Unsworth at owmessaging.com Wed Apr 15 21:11:30 2015 From: John.Unsworth at owmessaging.com (John Unsworth) Date: Wed, 15 Apr 2015 21:11:30 +0000 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: <552EC557.4020907@cisco.com> References: <552E59F7.8080506@cisco.com> <552E7140.6060405@cisco.com> <552E8768.6060704@cisco.com> <552EC557.4020907@cisco.com> Message-ID: I can?t dictate what cipher suite our customers will use, all have to work. It seems to me that for the time being I will have to stay with the 1.0.1 builds. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Foley Sent: 15 April 2015 21:09 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken This appears to be a different problem than the crash in SHA. Since you're seeing a "bad record mac", it appears the TLS handshake has made it through the ChangeCipherSpec message. Do you know which cipher suite is being negotiated? If it's AES, it may be worth trying a 3DES cipher suite. If the issue is in the AES layer, one of the 3DES cipher suites should work. By the way, have you run a 'make test' after building OpenSSL? Are all the test suites passing? If not, which one is failing? On 04/15/2015 12:26 PM, John Unsworth wrote: Still exactly the same crash. And even if these assembly code problems can be fixed there is still the negotiation error after compiling with no-asm. 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:s3_pkt.c:1456:SSL alert number 20 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Foley Sent: 15 April 2015 16:45 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken Looks like the crash is in SHA-512 this time, not SHA-1. There's a separate perl script to generate that assembly code. Try the 1.0.1 version of sha512-sparcv9.pl. The output from your rand command is valid. You can use the -base64 option if you want something more readable. On 04/15/2015 11:13 AM, John Unsworth wrote: That seems to have fixed the crash. -bash-3.00$ ./openssl rand 64 z??M??Ov??@?t????E?^?Q!?\?b_??Y???iT-&n?????B+?9kx??%hR?z-bash-3.00$ Not sure about the output though. However negotiation causes a core: -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 CONNECTED(00000004) depth=0 CN = jusworth-lt4.eu.cp.net verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = jusworth-lt4.eu.cp.net verify error:num=21:unable to verify the first certificate verify return:1 Segmentation Fault (core dumped) -bash-3.00$ pstack core core 'core' of 12587: ./openssl s_client -connect eos.es.cpth.ie:4250 000ed408 sha512_block_data_order (30e538, 30c050, 71a, 30e588, 30c050, 64f98fa7) + 8 0009fb30 ssl3_digest_cached_records (2f8ae0, 6, 2f8ea0, 14, 100, 2f8ea0) + 1cc 000980ec ssl3_get_certificate_request (2f8ae0, 2f8ea0, 2f8ea0, 10, a42e0, 2f8ae0) + 90 00093ad8 ssl3_connect (2f8ae0, 0, 1180, 1000, 1130, ffffffff) + 6c0 000aa2b8 ssl23_get_server_hello (2f8ae0, 16, 3, 3, 2f8ea0, 301638) + 648 000a9198 ssl23_connect (2f8ae0, 0, 3000, 2b4d64, 2b3d78, 1) + 588 000aa60c ssl23_write (2f8ae0, 2f0270, 0, 3000, ff247c94, a8c10) + 4c 0004ee64 s_client_main (0, 0, 1, 2b4d64, 2f8ae0, 2f4280) + 7374 0001328c do_cmd (2eb3c8, 3, ffbffad0, 2b4638, 13e64, 2b3d78) + b8 00012f08 main (4, ffbffacc, 2eb3c8, 29fc00, 2b3d78, 2b49dc) + 3a4 00012a08 _start (0, 0, 0, 0, 0, 2b3d78) + 108 Regards, John From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Foley Sent: 15 April 2015 15:10 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken How about the ./openssl sha1 command? Does that bomb too? It might be interesting to copy crypto/sha/asm/sha1-sparcv9.pl from the 1.0.1 source into the 1.0.2 source. Then clean, configure, compile and try again. There were changes to this file between 1.0.1 and 1.0.2. Perhaps a bug was introduced. I'm assuming this script generates the SHA source for your target platform. On 04/15/2015 09:56 AM, John Unsworth wrote: core 'core' of 24243: ./openssl rand 64 000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018, ffbfe01c, 44) + 8 00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530 00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650, 2c0644) + 38c 00226c00 ssleay_rand_status (c734, 0, 2b9f7c, 2c05cc, 2a0e70, 13000) + 138 00065eb4 app_RAND_load_file (ffbfe418, 2d5238, 0, 2800, 0, 1) + 88 00077cb8 rand_main (0, 0, ff242b30, 0, 0, 0) + 4b8 0001328c do_cmd (2eb4e8, 2, ffbffae0, 2b4728, 13e64, 2b3e98) + b8 00012f08 main (3, ffbffadc, 2eb4e8, 2a0000, 2b3e98, 2b4afc) + 3a4 00012a08 _start (0, 0, 0, 0, 0, 2b3e98) + 108 Regards, John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Foley Sent: 15 April 2015 13:31 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken Do you see the same stack trace when simply using the random number generator: ./openssl rand 64 What if you simply use SHA1: ./openssl sha1 On 04/14/2015 12:17 PM, John Unsworth wrote: Is no-one interested at all about this problem? Or do I need to send it to another place? Regards, John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Unsworth Sent: 10 April 2015 14:54 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken I have compiled 1.0.1m in the same way and that works fine using asm. John. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Unsworth Sent: 10 April 2015 12:21 To: openssl-users at openssl.org Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris 32 bit. I want to upgrade but both 1.0.2 and 1.0.2a cause problems. 1 When building 1.0.2 using ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 -xldscope=hidden openssl s_client crashes on start: -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 Segmentation Fault (core dumped) -bash-3.00$ pstack core core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4, 44) + 8 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, 2c0624) + 38c 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, 13000) + 138 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94 0001328c do_cmd (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8 00012f08 main (4, ffbffa84, 2eb4c8, 2a0000, 2b3e78, 2b4adc) + 3a4 00012a08 _start (0, 0, 0, 0, 0, 2b3e78) + 108 2 So I then rebuilt adding no-asm flag. It manages to connect but negotiation fails with an error: 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:s3_pkt.c:1456:SSL alert number 20 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: This is against the server that is still running 1.0.1h and can be successfully connected with openssl built with 1.0.1h. Note that the 64 bit build seems to work perfectly. Unfortunately for historical reasons we need to use the 32 bit version. The 32 bit builds that we use on Windows and Linux also work perfectly. Is it something to do with byte order? Regards, John. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Unsworth at owmessaging.com Thu Apr 16 10:42:52 2015 From: John.Unsworth at owmessaging.com (John Unsworth) Date: Thu, 16 Apr 2015 10:42:52 +0000 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: <552E59F7.8080506@cisco.com> <552E7140.6060405@cisco.com> <552E8768.6060704@cisco.com> <552EC557.4020907@cisco.com> Message-ID: This is from 1.0.1m openssl s_client: TLSv1/SSLv3, Cipher is AES256-GCM-SHA384 1.0.2 make test built with asm gets this far ../util/shlib_wrap.sh ./destest Doing cbcm Doing ecb Doing ede ecb Doing cbc Doing desx cbc Doing ede cbc Doing pcbc Doing cfb8 cfb16 cfb32 cfb48 cfb64 cfb64() ede_cfb64() done Doing ofb Doing ofb64 Doing ede_ofb64 Doing cbc_cksum Doing quad_cksum input word alignment test 0 1 2 3 output word alignment test 0 1 2 3 fast crypt test ../util/shlib_wrap.sh ./ideatest ecb idea ok cbc idea ok cfb64 idea ok ../util/shlib_wrap.sh ./shatest test 1 ok test 2 ok test 3 ok ../util/shlib_wrap.sh ./sha1test make[1]: *** [test_sha] Segmentation Fault (core dumped) 1.0.2 make test built with no-asm gets this far: ../util/shlib_wrap.sh ./destest Doing cbcm Doing ecb Doing ede ecb Doing cbc Doing desx cbc Doing ede cbc Doing pcbc Doing cfb8 cfb16 cfb32 cfb48 cfb64 cfb64() ede_cfb64() done Doing ofb Doing ofb64 Doing ede_ofb64 Doing cbc_cksum Doing quad_cksum input word alignment test 0 1 2 3 output word alignment test 0 1 2 3 fast crypt test ../util/shlib_wrap.sh ./ideatest ecb idea ok cbc idea ok cfb64 idea ok ../util/shlib_wrap.sh ./shatest test 1 ok test 2 ok test 3 ok ../util/shlib_wrap.sh ./sha1test test 1 ok test 2 ok test 3 ok ../util/shlib_wrap.sh ./sha256t Testing SHA-256 ... passed. Testing SHA-224 ... passed. ../util/shlib_wrap.sh ./sha512t Testing SHA-512 ... passed. Testing SHA-384 ... passed. ../util/shlib_wrap.sh ./md4test test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test 6 ok test 7 ok ../util/shlib_wrap.sh ./md5test test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test 6 ok test 7 ok ../util/shlib_wrap.sh ./hmactest test 0 ok test 1 ok test 2 ok test 3 ok ../util/shlib_wrap.sh ./md2test No MD2 support ../util/shlib_wrap.sh ./mdc2test pad1 - ok pad2 - ok ../util/shlib_wrap.sh ./wp_test Testing Whirlpool ......... passed. ../util/shlib_wrap.sh ./rmdtest test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test 6 ok test 7 ok test 8 ok ../util/shlib_wrap.sh ./rc2test ecb RC2 ok ../util/shlib_wrap.sh ./rc4test test 0 ok test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test end processing ....................done test multi-call ....................done bulk test ok ../util/shlib_wrap.sh ./rc5test No RC5 support ../util/shlib_wrap.sh ./bftest testing blowfish in raw ecb mode testing blowfish in ecb mode testing blowfish set_key testing blowfish in cbc mode testing blowfish in cfb64 mode testing blowfish in ofb64 ../util/shlib_wrap.sh ./casttest ecb cast5 ok This test will take some time....123456789ABCDEF ok ../util/shlib_wrap.sh ./randtest test 1 done test 2 done test 3 done test 4 done starting big number library test, could take a while... test BN_add test BN_sub test BN_lshift1 test BN_lshift (fixed) test BN_lshift test BN_rshift1 test BN_rshift test BN_sqr Square test failed! make[1]: *** [test_bn] Error 1 make[1]: Leaving directory `/export/home/metabld/META_OpenSSL/openssl-1.0.2/test' make: *** [tests] Error 2 From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of John Foley Sent: 15 April 2015 21:09 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken This appears to be a different problem than the crash in SHA. Since you're seeing a "bad record mac", it appears the TLS handshake has made it through the ChangeCipherSpec message. Do you know which cipher suite is being negotiated? If it's AES, it may be worth trying a 3DES cipher suite. If the issue is in the AES layer, one of the 3DES cipher suites should work. By the way, have you run a 'make test' after building OpenSSL? Are all the test suites passing? If not, which one is failing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rongliang.lei001 at gmail.com Thu Apr 16 20:31:53 2015 From: rongliang.lei001 at gmail.com (Rongliang Lei) Date: Thu, 16 Apr 2015 16:31:53 -0400 Subject: [openssl-users] Fwd: Itanium problem In-Reply-To: References: Message-ID: I used Fips module 2.0.9 and OpenSSL 1.0.1M. It built fine in windows for x64,win32 and Itanium. However, it only runs fine for x64 and Win32. For Itanium system, my executable exits immediately right after it runs, and it generated with follow sequence "d375fa8a9fd9d8f90fede1f1a9e548132d63230f". I tried dynamic load the libeay32.dll or ssleay32.dll. It has same problem. Any idea about this issue? -------------- next part -------------- An HTML attachment was scrubbed... URL: From carson at taltos.org Thu Apr 16 20:33:16 2015 From: carson at taltos.org (Carson Gaspar) Date: Thu, 16 Apr 2015 13:33:16 -0700 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: <552E59F7.8080506@cisco.com> <552E7140.6060405@cisco.com> <552E8768.6060704@cisco.com> <552EC557.4020907@cisco.com> Message-ID: <55301C8C.50502@taltos.org> As a counter-example, I just built OpenSSL 1.0.2a 32-bit on SPARC and 'make test' is just fine. Host: Sun Fire v490 Compiler: Solaris Studio 12.2 OS: Solaris 10 u9 Configure args: solaris-sparcv9-cc So I suspect the OP is suffering from some local issue. -- Carson From openssl-users at dukhovni.org Thu Apr 16 20:49:06 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 16 Apr 2015 20:49:06 +0000 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: <55301C8C.50502@taltos.org> References: <552E59F7.8080506@cisco.com> <552E7140.6060405@cisco.com> <552E8768.6060704@cisco.com> <552EC557.4020907@cisco.com> <55301C8C.50502@taltos.org> Message-ID: <20150416204905.GM17637@mournblade.imrryr.org> On Thu, Apr 16, 2015 at 01:33:16PM -0700, Carson Gaspar wrote: > As a counter-example, I just built OpenSSL 1.0.2a 32-bit on SPARC and 'make > test' is just fine. Somewhat (Solaris) related question: * Do you have access to any SunOS 5.10 systems? * If you do, can you check whether /bin/sh supports the POSIX "export" built-in syntax: export NAME=value or does one have to write (in some order): NAME=value; export NAME I pushed an update to a test script in the master branch that uses the POSIX "export" syntax, and perhaps folks still using SunOS 5.10 might be unhappy if that breaks (when 1.1.x comes out). -- Viktor. From carson at taltos.org Thu Apr 16 20:54:08 2015 From: carson at taltos.org (Carson Gaspar) Date: Thu, 16 Apr 2015 13:54:08 -0700 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: <20150416204905.GM17637@mournblade.imrryr.org> References: <552E59F7.8080506@cisco.com> <552E7140.6060405@cisco.com> <552E8768.6060704@cisco.com> <552EC557.4020907@cisco.com> <55301C8C.50502@taltos.org> <20150416204905.GM17637@mournblade.imrryr.org> Message-ID: <55302170.9060507@taltos.org> On 4/16/15 1:49 PM, Viktor Dukhovni wrote: > Somewhat (Solaris) related question: > > * Do you have access to any SunOS 5.10 systems? > > * If you do, can you check whether /bin/sh supports > the POSIX "export" built-in syntax: > > export NAME=value > > or does one have to write (in some order): > > NAME=value; export NAME > > I pushed an update to a test script in the master branch that uses > the POSIX "export" syntax, and perhaps folks still using SunOS 5.10 > might be unhappy if that breaks (when 1.1.x comes out). /bin/sh is non-POSIX on Solaris 5.10. One must use /usr/xpg4/bin/sh (or ksh, bash, etc.) if one expects 'export foo=bar' to work. -- Carson From openssl-users at dukhovni.org Thu Apr 16 21:58:39 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 16 Apr 2015 21:58:39 +0000 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: <55302170.9060507@taltos.org> References: <552E7140.6060405@cisco.com> <552E8768.6060704@cisco.com> <552EC557.4020907@cisco.com> <55301C8C.50502@taltos.org> <20150416204905.GM17637@mournblade.imrryr.org> <55302170.9060507@taltos.org> Message-ID: <20150416215838.GN17637@mournblade.imrryr.org> On Thu, Apr 16, 2015 at 01:54:08PM -0700, Carson Gaspar wrote: > >I pushed an update to a test script in the master branch that uses > >the POSIX "export" syntax, and perhaps folks still using SunOS 5.10 > >might be unhappy if that breaks (when 1.1.x comes out). > > /bin/sh is non-POSIX on Solaris 5.10. One must use /usr/xpg4/bin/sh (or ksh, > bash, etc.) if one expects 'export foo=bar' to work. So I guess we'll have to modify that test script, on the assumption that SunOS 5.10 (Solaris 10) might have OpenSSL 1.1.0 users when that comes later out. -- Viktor. From John.Unsworth at owmessaging.com Fri Apr 17 10:15:33 2015 From: John.Unsworth at owmessaging.com (John Unsworth) Date: Fri, 17 Apr 2015 10:15:33 +0000 Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: <55301C8C.50502@taltos.org> References: <552E59F7.8080506@cisco.com> <552E7140.6060405@cisco.com> <552E8768.6060704@cisco.com> <552EC557.4020907@cisco.com> <55301C8C.50502@taltos.org> Message-ID: Good call. I built with just solaris-sparcv9-cc and that works fine. Adding -xcode=pic32 introduces the problems. I need that flag because I am adding the openssl static library into my shared library. John. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Carson Gaspar Sent: 16 April 2015 21:33 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken As a counter-example, I just built OpenSSL 1.0.2a 32-bit on SPARC and 'make test' is just fine. Host: Sun Fire v490 Compiler: Solaris Studio 12.2 OS: Solaris 10 u9 Configure args: solaris-sparcv9-cc So I suspect the OP is suffering from some local issue. -- Carson From foleyj at cisco.com Fri Apr 17 12:59:50 2015 From: foleyj at cisco.com (John Foley) Date: Fri, 17 Apr 2015 08:59:50 -0400 Subject: [openssl-users] Fwd: Itanium problem In-Reply-To: References: Message-ID: <553103C6.60907@cisco.com> I'm impressed you were able to do a FIPS build for Windows x64. I didn't think this was possible. ;-) This looks like the hash that FINGERPRINT_premain() spits out when the signature hasn't been embedded into the binary. You may want to confirm the signature is embedded during the build process. On 04/16/2015 04:31 PM, Rongliang Lei wrote: > > I used Fips module 2.0.9 and OpenSSL 1.0.1M. It built fine in windows > for x64,win32 and Itanium. However, it only runs fine for x64 and > Win32. For Itanium system, my executable exits immediately right after > it runs, and it generated with follow sequence > "d375fa8a9fd9d8f90fede1f1a9e548132d63230f". I tried dynamic load the > libeay32.dll or ssleay32.dll. It has same problem. Any idea about > this issue? > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Unsworth at owmessaging.com Fri Apr 17 13:28:15 2015 From: John.Unsworth at owmessaging.com (John Unsworth) Date: Fri, 17 Apr 2015 13:28:15 +0000 Subject: [openssl-users] [openssl.org #3804] BUG: OpenSSL 1.0.2 Solaris 32 bit build is broken Message-ID: If I build using just ./Configure solaris-sparcv9-cc Everything works fine. However ./Configure solaris-sparcv9-cc -xcode=pic32 Causes the problem. John. From rt at openssl.org Fri Apr 17 14:00:50 2015 From: rt at openssl.org (John Unsworth via RT) Date: Fri, 17 Apr 2015 16:00:50 +0200 Subject: [openssl-users] [openssl.org #3804] BUG: OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: Message-ID: If I build using just ./Configure solaris-sparcv9-cc Everything works fine. However ./Configure solaris-sparcv9-cc -xcode=pic32 Causes the problem. John. From rongliang.lei001 at gmail.com Fri Apr 17 14:56:57 2015 From: rongliang.lei001 at gmail.com (Rongliang Lei) Date: Fri, 17 Apr 2015 10:56:57 -0400 Subject: [openssl-users] Fwd: Itanium problem In-Reply-To: <553103C6.60907@cisco.com> References: <553103C6.60907@cisco.com> Message-ID: Do you mean it is impossible to do a FIPS build for Windows ia64(Itanium System)? On Fri, Apr 17, 2015 at 8:59 AM, John Foley wrote: > I'm impressed you were able to do a FIPS build for Windows x64. I didn't > think this was possible. ;-) > > This looks like the hash that FINGERPRINT_premain() spits out when the > signature hasn't been embedded into the binary. You may want to confirm > the signature is embedded during the build process. > > > > On 04/16/2015 04:31 PM, Rongliang Lei wrote: > > > I used Fips module 2.0.9 and OpenSSL 1.0.1M. It built fine in windows for > x64,win32 and Itanium. However, it only runs fine for x64 and Win32. For > Itanium system, my executable exits immediately right after it runs, and it > generated with follow sequence "d375fa8a9fd9d8f90fede1f1a9e548132d63230f". > I tried dynamic load the libeay32.dll or ssleay32.dll. It has same > problem. Any idea about this issue? > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Fri Apr 17 15:13:30 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 17 Apr 2015 15:13:30 +0000 Subject: [openssl-users] Fwd: Itanium problem In-Reply-To: <553103C6.60907@cisco.com> References: <553103C6.60907@cisco.com> Message-ID: <20150417151329.GA8417@openssl.org> On Fri, Apr 17, 2015, John Foley wrote: > I'm impressed you were able to do a FIPS build for Windows x64. I > didn't think this was possible. ;-) > WIN64 uses PIC and there aren't any relocation issues so in some ways it's less trouble than WIN32. > This looks like the hash that FINGERPRINT_premain() spits out when the > signature hasn't been embedded into the binary. You may want to confirm > the signature is embedded during the build process. > Yes that's the cause. Itanium wasn't a platform that was specifically included during the validation so the build system might not handle it properly and the result most likely wouldn't be validated anyway. Do normal WIN64 binaries work? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rongliang.lei001 at gmail.com Fri Apr 17 15:25:14 2015 From: rongliang.lei001 at gmail.com (Rongliang Lei) Date: Fri, 17 Apr 2015 11:25:14 -0400 Subject: [openssl-users] Fwd: Itanium problem In-Reply-To: <20150417151329.GA8417@openssl.org> References: <553103C6.60907@cisco.com> <20150417151329.GA8417@openssl.org> Message-ID: Normal WIN64 works fine so far On Fri, Apr 17, 2015 at 11:13 AM, Dr. Stephen Henson wrote: > On Fri, Apr 17, 2015, John Foley wrote: > > > I'm impressed you were able to do a FIPS build for Windows x64. I > > didn't think this was possible. ;-) > > > > WIN64 uses PIC and there aren't any relocation issues so in some ways it's > less trouble than WIN32. > > > This looks like the hash that FINGERPRINT_premain() spits out when the > > signature hasn't been embedded into the binary. You may want to confirm > > the signature is embedded during the build process. > > > > Yes that's the cause. Itanium wasn't a platform that was specifically > included > during the validation so the build system might not handle it properly and > the > result most likely wouldn't be validated anyway. > > Do normal WIN64 binaries work? > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri Apr 17 16:11:24 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 17 Apr 2015 18:11:24 +0200 Subject: [openssl-users] Fwd: Itanium problem In-Reply-To: References: <553103C6.60907@cisco.com> <20150417151329.GA8417@openssl.org> Message-ID: <553130AC.50805@wisemo.com> On 17/04/2015 17:25, Rongliang Lei wrote: > Normal WIN64 works fine so far > > On Fri, Apr 17, 2015 at 11:13 AM, Dr. Stephen Henson > > wrote: > > On Fri, Apr 17, 2015, John Foley wrote: > > > I'm impressed you were able to do a FIPS build for Windows x64. I > > didn't think this was possible. ;-) > > > > WIN64 uses PIC and there aren't any relocation issues so in some > ways it's > less trouble than WIN32. > > > This looks like the hash that FINGERPRINT_premain() spits out > when the > > signature hasn't been embedded into the binary. You may want to > confirm > > the signature is embedded during the build process. > > > > Yes that's the cause. Itanium wasn't a platform that was > specifically included > during the validation so the build system might not handle it > properly and the > result most likely wouldn't be validated anyway. > > Do normal WIN64 binaries work? > Normal Win64? You mean Win64 for HP/Digital Alpha AXP, aka Windows 2000 Release Candidate? Or Win64 for Itanium, aka Windows XP 64 bit edition, Gold and Service pack 1? Or the latest one (possibly not yet released) Win64 for Arm ARCHitecture v8? You surely cannot mean that amd64 port, introduced in Windows 2003 (NT 5.02)? Just joking :-) 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Fri Apr 17 16:36:34 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 17 Apr 2015 12:36:34 -0400 Subject: [openssl-users] Fwd: Itanium problem In-Reply-To: References: Message-ID: On Thu, Apr 16, 2015 at 4:31 PM, Rongliang Lei wrote: > > I used Fips module 2.0.9 and OpenSSL 1.0.1M. It built fine in windows for > x64,win32 and Itanium. However, it only runs fine for x64 and Win32. For > Itanium system, my executable exits immediately right after it runs, and it > generated with follow sequence "d375fa8a9fd9d8f90fede1f1a9e548132d63230f". I > tried dynamic load the libeay32.dll or ssleay32.dll. It has same problem. > Any idea about this issue? > I seem to recall the hash like "d375fa8a9fd9d8f90fede1f1a9e548132d63230f" will be returned with an exit code of 42 (magic). When something encounters it (was it fipsld?), it writes the signature to the file. You can see remnants of it at the wiki page on fipsld++:https://wiki.openssl.org/index.php/Fipsld_and_C%2B%2B#fipsld_Modifications . You're free to modify the fipsld script within reason. Its not sequestered. Jeff From vqurius at gmail.com Sun Apr 19 02:12:24 2015 From: vqurius at gmail.com (Q Rius) Date: Sat, 18 Apr 2015 19:12:24 -0700 Subject: [openssl-users] CMS_encrypt with ECDH key Message-ID: I'm trying to implement CMS encrypt using ECDH keys. Ref openssl CMS with ECDH EnvelopedData The command line works flawlessly but my program is giving an error - Error Encrypting Data 140508524291744:error:2E06507D:CMS routines:CMS_add1_recipient_cert:not supported for this key type:cms_env.c:210: In code below, recip.pem was created using steps here openssl CMS with ECDH EnvelopedData int main (int argc, char **argv) { CMS_ContentInfo *cms1 = NULL; BIO *in = NULL, *out = NULL, *tbio = NULL; X509 *rcert = NULL; int ret = 1; int flags = CMS_STREAM; OpenSSL_add_all_algorithms(); ERR_load_crypto_strings(); tbio = BIO_new_file("recip.pem", "r"); if (!tbio) goto err; rcert = PEM_read_bio_X509(tbio, NULL, 0, NULL); if (!rcert) goto err; in = BIO_new_file("encr.txt", "r"); flags |= CMS_PARTIAL; cms1 = CMS_encrypt(NULL, in, EVP_des_ede3_cbc(), flags); CMS_RecipientInfo *ri; ri = CMS_add1_recipient_cert(cms1, rcert, flags); if (!ri) goto err; if(!CMS_final(cms1, in, NULL, flags)) goto err; if (!cms1) goto err; out = BIO_new_file("cms1.pem", "w"); if(!out) goto err; if(!PEM_write_bio_CMS_stream(out, cms1, in, flags)) goto err; ret = 0; err: ##cleanup } The documentation states ECC keys are not supported yet the commandline cms app is able to do it without a problem. I stepped through the cms app but am unable to figure out what I'm doing differently. Also tried the cms_enc.c from the demos folder but that does not handle ecc keys as well. TIA! -------------- next part -------------- An HTML attachment was scrubbed... URL: From de.techno at gmail.com Sun Apr 19 17:28:11 2015 From: de.techno at gmail.com (dE) Date: Sun, 19 Apr 2015 22:58:11 +0530 Subject: [openssl-users] CTX_free crash Message-ID: <5533E5AB.9030109@gmail.com> I got a program which does the following sequence of operations -- SSL_shutdown(ssl) SSL_free (ssl); SSL_CTX_free ( ctx ); close(socket) Where 'socket' is the underlying non-blocking socket the ssl connection is established over. bio is also set to non-blocking. Sometimes, the program crashes when doing an SSL_CTX_free; before the crash, ctx is an invalid pointer, that's why I can get a valid value from SSL_CTX_get_max_cert_list (ctx), so it's not a double free problem. I tried removing SSL_shutdown(ssl) with no improvements. From rsalz at akamai.com Sun Apr 19 18:40:23 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 19 Apr 2015 18:40:23 +0000 Subject: [openssl-users] CTX_free crash In-Reply-To: <5533E5AB.9030109@gmail.com> References: <5533E5AB.9030109@gmail.com> Message-ID: > Sometimes, the program crashes when doing an SSL_CTX_free; before the > crash, ctx is an invalid pointer, that's why I can get a valid value from > SSL_CTX_get_max_cert_list (ctx), so it's not a double free problem. You mean it's a VALID pointer? We'll need a more detailed backtrace. From noloader at gmail.com Sun Apr 19 23:32:17 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 19 Apr 2015 19:32:17 -0400 Subject: [openssl-users] How to add CT Precertificate SCTs to a server certificate? Message-ID: Browsers are starting to enforce Certificate Transparency (CT). Below is a sample of CT Precertificate SCTs, which is required for CT. It includes a new certificate extension with an OID of 1.3.6.1.4.1.11129.2.4.2. How do we use `openssl req` and a CONF file to add the information (assuming we already have the certified timestamps)? ***** $ openssl s_client -connect embed.ct.digicert.com:443 -tls1 -servername embed.ct.digicert.com | \ openssl x509 -text -noout depth=1 C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA verify error:num=20:unable to get local issuer certificate Certificate: Data: Version: 3 (0x2) Serial Number: 03:e0:aa:80:19:13:06:8a:28:73:f0:24:29:3e:e4:61 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA Validity Not Before: Nov 13 00:00:00 2014 GMT Not After : Nov 18 12:00:00 2015 GMT Subject: C=US, ST=Utah, L=Lehi, O=DigiCert, Inc., CN=embed.ct.digicert.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:9a:64:73:61:53:66:b8:aa:80:c7:cc:53:67:6a: df:da:a9:b1:6a:c5:53:63:55:5f:14:4c:b3:27:d1: 3c:e4:0a:1a:e7:16:48:bc:15:46:7e:63:e8:27:3c: c5:28:bd:79:cf:34:d5:9a:67:1e:0c:27:6e:ec:00: 5e:69:38:5b:a7:16:4f:b9:09:ec:fc:7e:f2:41:b7: f9:54:f4:6c:c3:22:a6:f5:99:f4:be:9d:64:26:75: 9e:b2:b9:16:d7:f5:51:9f:53:ce:74:ca:d6:d6:7a: 4a:d4:4d:0e:4d:73:93:30:3c:b9:b8:1d:a0:d8:94: 8c:59:7e:82:a4:4c:82:fc:c3:73:7f:b1:56:28:4e: b5:f7:73:53:ac:7b:30:a4:bc:b9:6c:c0:b6:67:0d: 19:5e:40:22:11:11:8c:6d:3a:87:47:08:e6:5c:7b: 17:7c:64:7a:a1:ff:8c:7c:37:b6:b7:91:2c:c2:90: 7e:cc:48:1f:57:1e:f9:db:d4:ac:cf:d9:2b:60:ff: 13:2d:88:c5:7e:d8:eb:ec:ed:85:d7:9e:f9:56:32: ca:c1:6b:24:64:9f:63:ba:83:ee:a1:85:4a:e3:ad: 45:8c:92:95:3a:e0:80:91:9b:60:b5:75:88:86:4e: 0f:81:8c:b5:f4:77:fd:e5:f3:36:f6:33:d6:2b:a0: c4:91 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier: keyid:0F:80:61:1C:82:31:61:D5:2F:28:E7:8D:46:38:B4:2C:E1:C6:D9:E2 X509v3 Subject Key Identifier: 88:4F:83:16:87:AD:AE:1E:FF:04:4A:79:66:92:C6:9F:62:69:4F:B1 X509v3 Subject Alternative Name: DNS:embed.ct.digicert.com X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl3.digicert.com/ssca-sha2-g3.crl Full Name: URI:http://crl4.digicert.com/ssca-sha2-g3.crl X509v3 Certificate Policies: Policy: 2.16.840.1.114412.1.1 CPS: https://www.digicert.com/CPS Authority Information Access: OCSP - URI:http://ocsp.digicert.com CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2SecureServerCA.crt X509v3 Basic Constraints: critical CA:FALSE CT Precertificate SCTs: Signed Certificate Timestamp: Version : v1(0) Log ID : A4:B9:09:90:B4:18:58:14:87:BB:13:A2:CC:67:70:0A: 3C:35:98:04:F9:1B:DF:B8:E3:77:CD:0E:C8:0D:DC:10 Timestamp : Nov 13 16:57:03.632 2014 GMT Extensions: none Signature : ecdsa-with-SHA256 30:45:02:20:06:14:6A:E3:6D:0F:84:5D:6A:98:E7:29: 94:80:8B:F2:A4:23:85:68:4E:F9:BC:50:7C:FF:7B:94: EB:20:54:82:02:21:00:91:63:83:FD:F6:31:5E:38:08: AF:A7:5E:00:B7:0B:9B:1F:8B:FD:4D:7E:49:3C:43:E6: 64:E5:4B:F9:60:D7:89 Signed Certificate Timestamp: Version : v1(0) Log ID : 68:F6:98:F8:1F:64:82:BE:3A:8C:EE:B9:28:1D:4C:FC: 71:51:5D:67:93:D4:44:D1:0A:67:AC:BB:4F:4F:FB:C4 Timestamp : Nov 13 16:57:03.619 2014 GMT Extensions: none Signature : ecdsa-with-SHA256 30:45:02:20:61:4F:69:89:80:6A:62:2D:8E:A2:D0:24: A5:E2:1D:74:67:51:77:C1:9B:DE:99:DE:16:56:2B:02: 77:A8:25:49:02:21:00:D3:41:6C:5D:88:40:F0:7A:FE: E0:25:09:86:71:63:86:49:54:DD:96:E4:B5:9B:4A:84: 65:A9:25:12:F1:B7:E0 Signature Algorithm: sha256WithRSAEncryption 62:0c:d1:51:08:8a:a3:d1:df:bc:53:ba:e9:58:67:41:ea:5f: e3:51:f2:0b:9d:24:b4:77:6a:cf:96:ff:c5:ce:1c:55:1e:77: 8a:49:46:7d:19:ef:52:4f:d3:24:b1:f2:95:60:67:40:d4:d1: f4:27:e4:66:55:45:c6:a5:51:a6:87:d0:09:af:f6:48:9b:df: 24:c9:28:ad:47:b9:f6:a3:86:cb:64:64:3d:90:92:0e:94:f7: d2:8b:d6:79:b4:df:f2:3f:f5:6e:ea:08:b3:b0:37:87:a3:30: a7:f1:db:b7:86:b2:39:64:35:93:ee:5f:7b:01:51:5f:b1:e1: e0:d1:5d:a6:e6:a3:53:3f:66:97:16:8f:18:c4:fa:fc:8e:85: 79:a1:95:7b:69:0b:f5:a4:92:1f:04:cf:ed:f6:95:e3:8f:b4: 2a:6a:be:0c:a2:b6:53:99:5d:50:78:23:1c:fb:cb:2e:1d:be: b5:8d:83:2e:08:96:f8:c9:be:96:13:ed:61:0f:cf:57:44:ff: 3a:d5:10:b0:bd:08:1f:27:c4:cf:97:17:e8:6a:62:bc:6d:e9: 64:39:a0:36:79:d6:02:84:b7:47:26:9b:5d:b1:92:aa:f1:36: 1a:31:9e:27:f2:25:54:89:17:ac:56:54:b0:e0:41:67:e4:b8: 7b:e0:2c:88 From thulasi.goriparthi at gmail.com Mon Apr 20 11:19:37 2015 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Mon, 20 Apr 2015 16:49:37 +0530 Subject: [openssl-users] access to ecdh_method and ecdsa_method structure definitions Message-ID: Hi all, What is the reason behind keeping ecdh_method and ecdsa_method structure definitions in local header files ech_locl.h and ecs_locl.h respectively unlike their peers.. dh_method, dsa_method, rsa_meth_st and rand_meth_st which are defined in exported header files? Thanks, Thulasi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Apr 20 13:57:47 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 20 Apr 2015 13:57:47 +0000 Subject: [openssl-users] How to add CT Precertificate SCTs to a server certificate? In-Reply-To: References: Message-ID: <7a3d88ef1c3247e4ab5153107a96a308@usma1ex-dag1mb2.msg.corp.akamai.com> > How do we use `openssl req` and a CONF file to add the information > (assuming we already have the certified timestamps)? Ouch, that's gonna be nasty. Look at ASN1_generate_nconf.pod Most likely have to use the SEQUENCE type, recursively. Ouch indeed. A patch to let you specify the DER directly would be useful. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From jetson23 at hotmail.com Mon Apr 20 15:03:37 2015 From: jetson23 at hotmail.com (Jason Schultz) Date: Mon, 20 Apr 2015 15:03:37 +0000 Subject: [openssl-users] Peer closing connection with a FIN without first sending a close_notify Message-ID: Greetings. We am seeing the following situation and are not quite sure the proper way to handle it, so I thought I'd solicit the mailing list. Our application is an FTP server using OpenSSL. The peer is a non-OpenSSL FTP client in active mode. The problem comes in with how the FTP client handles closing the data connection after doing a put and transferring a file from client to our server. Instead of sending a close_notify, it closes the connection with a TCP FIN. On our server, calls to SSL_read() and SSL_get_error() indicate an SSL_ERROR_SYSCALL, which we treat as a protocol violation and abort the connection. When the FTP implementation sees the abort, it tears down the connection and throws the file away. Regarding SSL_ERROR_SYSCALL, the OpenSSL documentation says this: "Some I/O error occurred. The OpenSSL error queue may contain more information on the error. If the error queue is empty (i.e. ERR_get_error() returns 0), ret can be used to find out more about the error: If ret == 0, an EOF was observed that violates the protocol. If ret == -1, the underlying BIO reported an I/O error (for socket I/O on Unix systems, consult errno for details)." >From this information, we determined we were seeing the case where ERR_get_error() returns 0, meaning an EOF was observed that violates the protocol; the FIN being sent without being preceded by a close_notify. If we change our server to look for this specific case, and indicate a close to the FTP application instead of an abort, the FTP transfer completes successfully. This is where our questions arise. First of all, the FTP client's close without being preceded by a close_notify seems to be a violation of the protocol, and OpenSSL handles it as such. Does changing the way it's handled open up our application to truncation attacks? We have also read that this particular behavior is not unheard of in SSL implementations, and treating the TCP FIN as a proper way to close the connection as described above is OK. Given the conflicting information we have seen, what is the opinion of the OpenSSL team? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From de.techno at gmail.com Mon Apr 20 15:11:00 2015 From: de.techno at gmail.com (dE) Date: Mon, 20 Apr 2015 20:41:00 +0530 Subject: [openssl-users] CTX_free crash In-Reply-To: References: <5533E5AB.9030109@gmail.com> Message-ID: <55351704.3060700@gmail.com> On 04/20/15 00:10, Salz, Rich wrote: >> Sometimes, the program crashes when doing an SSL_CTX_free; before the >> crash, ctx is an invalid pointer, that's why I can get a valid value from >> SSL_CTX_get_max_cert_list (ctx), so it's not a double free problem. > You mean it's a VALID pointer? > > We'll need a more detailed backtrace. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users I mean it's not null or does not hold garbage. #0 0x00007ffff6d54210 in ?? () from /usr/lib64/libssl.so.1.0.0 #1 0x00007ffff67cac4d in ?? () from /usr/lib64/libcrypto.so.1.0.0 #2 0x00007ffff67cb14f in lh_delete () from /usr/lib64/libcrypto.so.1.0.0 #3 0x00007ffff6d5ab14 in ?? () from /usr/lib64/libssl.so.1.0.0 #4 0x00007ffff67cb3cc in lh_doall_arg () from /usr/lib64/libcrypto.so.1.0.0 #5 0x00007ffff6d5afc7 in SSL_CTX_flush_sessions () from /usr/lib64/libssl.so.1.0.0 #6 0x00007ffff6d55f0a in SSL_CTX_free () from /usr/lib64/libssl.so.1.0.0 Wait for the debugging symbols... From openssl-users at dukhovni.org Mon Apr 20 15:51:58 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 20 Apr 2015 15:51:58 +0000 Subject: [openssl-users] How to add CT Precertificate SCTs to a server certificate? In-Reply-To: <7a3d88ef1c3247e4ab5153107a96a308@usma1ex-dag1mb2.msg.corp.akamai.com> References: <7a3d88ef1c3247e4ab5153107a96a308@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <20150420155158.GG25758@mournblade.imrryr.org> On Mon, Apr 20, 2015 at 01:57:47PM +0000, Salz, Rich wrote: > > How do we use `openssl req` and a CONF file to add the information > > (assuming we already have the certified timestamps)? > > Ouch, that's gonna be nasty. Look at ASN1_generate_nconf.pod Most likely have to use the SEQUENCE type, recursively. Ouch indeed. > > A patch to let you specify the DER directly would be useful. No patch required: http://web.mit.edu/crypto/openssl.cnf # DER hex encoding of an extension: beware experts only! # obj=DER:02:03 # Where 'obj' is a standard or added object # You can even override a supported extension: # basicConstraints= critical, DER:30:03:01:01:FF -- Viktor. From steve at openssl.org Mon Apr 20 15:52:29 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 20 Apr 2015 15:52:29 +0000 Subject: [openssl-users] How to add CT Precertificate SCTs to a server certificate? In-Reply-To: <7a3d88ef1c3247e4ab5153107a96a308@usma1ex-dag1mb2.msg.corp.akamai.com> References: <7a3d88ef1c3247e4ab5153107a96a308@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <20150420155229.GA31263@openssl.org> On Mon, Apr 20, 2015, Salz, Rich wrote: > > How do we use `openssl req` and a CONF file to add the information > > (assuming we already have the certified timestamps)? > > Ouch, that's gonna be nasty. Look at ASN1_generate_nconf.pod Most likely have to use the SEQUENCE type, recursively. Ouch indeed. > > A patch to let you specify the DER directly would be useful. > You can use DER directly but CTs (at least those I've seen) don't use DER or ASN.1 internally: they use TLS like syntax contained in an OCTET STRING wrapper. So if you have the encoding of the CT you use the ASN.1 generator to produce an OCTET STRING and place the hex form of the CT in that. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rsalz at akamai.com Mon Apr 20 16:01:35 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 20 Apr 2015 16:01:35 +0000 Subject: [openssl-users] How to add CT Precertificate SCTs to a server certificate? In-Reply-To: <20150420155158.GG25758@mournblade.imrryr.org> References: <7a3d88ef1c3247e4ab5153107a96a308@usma1ex-dag1mb2.msg.corp.akamai.com> <20150420155158.GG25758@mournblade.imrryr.org> Message-ID: <417230d75d2b46b2ae841426f6189ce4@usma1ex-dag1mb2.msg.corp.akamai.com> > > A patch to let you specify the DER directly would be useful. > > No patch required: Looks like a doc bug then. From steve at openssl.org Mon Apr 20 16:06:13 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 20 Apr 2015 16:06:13 +0000 Subject: [openssl-users] How to add CT Precertificate SCTs to a server certificate? In-Reply-To: <417230d75d2b46b2ae841426f6189ce4@usma1ex-dag1mb2.msg.corp.akamai.com> References: <7a3d88ef1c3247e4ab5153107a96a308@usma1ex-dag1mb2.msg.corp.akamai.com> <20150420155158.GG25758@mournblade.imrryr.org> <417230d75d2b46b2ae841426f6189ce4@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <20150420160613.GA32208@openssl.org> On Mon, Apr 20, 2015, Salz, Rich wrote: > > > A patch to let you specify the DER directly would be useful. > > > > No patch required: > > Looks like a doc bug then. Err... https://www.openssl.org/docs/apps/x509v3_config.html#ARBITRARY-EXTENSIONS Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rsalz at akamai.com Mon Apr 20 16:10:45 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 20 Apr 2015 16:10:45 +0000 Subject: [openssl-users] How to add CT Precertificate SCTs to a server certificate? In-Reply-To: <20150420160613.GA32208@openssl.org> References: <7a3d88ef1c3247e4ab5153107a96a308@usma1ex-dag1mb2.msg.corp.akamai.com> <20150420155158.GG25758@mournblade.imrryr.org> <417230d75d2b46b2ae841426f6189ce4@usma1ex-dag1mb2.msg.corp.akamai.com> <20150420160613.GA32208@openssl.org> Message-ID: <1eb1d6398ac3446789f3c9541e399deb@usma1ex-dag1mb2.msg.corp.akamai.com> > https://www.openssl.org/docs/apps/x509v3_config.html#ARBITRARY- > EXTENSIONS Oops. I on ly looked at asn1_generate. Should there be a cross-link? From steve at openssl.org Mon Apr 20 16:11:15 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 20 Apr 2015 16:11:15 +0000 Subject: [openssl-users] CMS_encrypt with ECDH key In-Reply-To: References: Message-ID: <20150420161115.GA32516@openssl.org> On Sat, Apr 18, 2015, Q Rius wrote: > I'm trying to implement CMS encrypt using ECDH keys. Ref openssl CMS with > ECDH EnvelopedData > > The command line works flawlessly but my program is giving an error - > > Error Encrypting Data > 140508524291744:error:2E06507D:CMS routines:CMS_add1_recipient_cert:not > supported for this key type:cms_env.c:210: > > In code below, recip.pem was created using steps here openssl CMS with ECDH > EnvelopedData > > > int main (int argc, char **argv) > { > CMS_ContentInfo *cms1 = NULL; > BIO *in = NULL, *out = NULL, *tbio = NULL; > X509 *rcert = NULL; > int ret = 1; > int flags = CMS_STREAM; > > OpenSSL_add_all_algorithms(); > ERR_load_crypto_strings(); > > tbio = BIO_new_file("recip.pem", "r"); > if (!tbio) > goto err; > > rcert = PEM_read_bio_X509(tbio, NULL, 0, NULL); > if (!rcert) > goto err; > > in = BIO_new_file("encr.txt", "r"); > flags |= CMS_PARTIAL; > cms1 = CMS_encrypt(NULL, in, EVP_des_ede3_cbc(), flags); > > CMS_RecipientInfo *ri; > ri = CMS_add1_recipient_cert(cms1, rcert, flags); > if (!ri) > goto err; > > if(!CMS_final(cms1, in, NULL, flags)) > goto err; > > if (!cms1) > goto err; > > out = BIO_new_file("cms1.pem", "w"); > if(!out) > goto err; > > if(!PEM_write_bio_CMS_stream(out, cms1, in, flags)) > goto err; > > ret = 0; > > err: > > ##cleanup > > } > > The documentation states ECC keys are not supported yet the commandline cms > app is able to do it without a problem. I stepped through the cms app but > am unable to figure out what I'm doing differently. Also tried the > cms_enc.c from the demos folder but that does not handle ecc keys as well. > Are you're sure you are linking against OpenSSL 1.0.2 or later? OpenSSL 1.0.1 and ealier do not support ECDH for CMS. Your program works OK here except you need to delete the CMS_final part: finalisations is performed on the fly when writing if you use the flag CMS_STREAM. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From openssl-users at dukhovni.org Mon Apr 20 16:26:43 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 20 Apr 2015 16:26:43 +0000 Subject: [openssl-users] Peer closing connection with a FIN without first sending a close_notify In-Reply-To: References: Message-ID: <20150420162643.GJ25758@mournblade.imrryr.org> On Mon, Apr 20, 2015 at 03:03:37PM +0000, Jason Schultz wrote: > We am seeing the following situation and are not quite sure the proper > way to handle it, so I thought I'd solicit the mailing list. Our application > is an FTP server using OpenSSL. The peer is a non-OpenSSL FTP client in > active mode. The problem comes in with how the FTP client handles closing > the data connection after doing a put and transferring a file from client > to our server. Instead of sending a close_notify, it closes the connection > with a TCP FIN. That's wrong. This client snatches defeat from the jaws of victory, by failing to take advantage of the TLS shutdown facility to securely signal end of data. Without SSL shutdown the data transfer is vulnerable to truncation attacks. > > On our server, calls to SSL_read() and SSL_get_error() indicate an > SSL_ERROR_SYSCALL, which we treat as a protocol violation and abort the > connection. When the FTP implementation sees the abort, it tears down > the connection and throws the file away. That's sensible default behaviour I think, but you may need work-arounds for broken clients. > If we change our server to look for this specific case, and indicate a > close to the FTP application instead of an abort, the FTP transfer completes > successfully. Apply this work-around to as few clients as possible. > This is where our questions arise. First of all, the FTP client's close > without being preceded by a close_notify seems to be a violation of the > protocol, and OpenSSL handles it as such. Correct. > Does changing the way it's handled open up our application to truncation > attacks? Yes. > We have also read that this particular behavior is not unheard of in SSL > implementations, and treating the TCP FIN as a proper way to close the > connection as described above is OK. Only when the application-level protocol contains sufficient framing, to make additional framing in TLS redundant. This is not the case in FTP in stream mode. FTP in block mode can signal end of file via the block headers, and then TLS shutdown is not needed. (I've never seen FTP used in block mode). > Given the conflicting information we have seen, what is the opinion of > the OpenSSL team? I don't speak for the team. My opinion is that the client is broken unless it is using FTP in some manner that provides in-band file integrity. So any work-around may require client-specific configuration so as not to downgrade all clients. -- Viktor. From scott_n at xypro.com Mon Apr 20 18:32:15 2015 From: scott_n at xypro.com (Scott Neugroschl) Date: Mon, 20 Apr 2015 18:32:15 +0000 Subject: [openssl-users] BIO_new_dgram() called in apps/s_server.h Message-ID: I am building OpenSSL 1.0.2a with no-dgram and no-dtls1. When I do so, I get a linker error that BIO_new_dgram() is undefined. The following appears to fix the issue: ====cut here==== --- s_server.c.orig 2015-03-19 17:17:53 -0700 +++ s_server.c 2015-04-20 11:27:30 -0700 @@ -2183,6 +2183,7 @@ # endif #endif +#ifndef OPENSSL_NO_DGRAM if (stype == SOCK_DGRAM) { sbio = BIO_new_dgram(s, BIO_NOCLOSE); @@ -2220,6 +2221,9 @@ SSL_set_options(con, SSL_OP_COOKIE_EXCHANGE); } else sbio = BIO_new_socket(s, BIO_NOCLOSE); +#else + sbio = BIO_new_socket(s, BIO_NOCLOSE); +#endif if (s_nbio_test) { BIO *test; ====cut here==== Does this fix make sense? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | From scott_n at xypro.com Mon Apr 20 18:34:48 2015 From: scott_n at xypro.com (Scott Neugroschl) Date: Mon, 20 Apr 2015 18:34:48 +0000 Subject: [openssl-users] BIO_new_dgram() called in apps/s_server.c Message-ID: Correction to subject, it's s_server.c My typo. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Scott Neugroschl Sent: Monday, April 20, 2015 11:32 AM To: openssl-users at mta.opensslfoundation.net Subject: [openssl-users] BIO_new_dgram() called in apps/s_server.h I am building OpenSSL 1.0.2a with no-dgram and no-dtls1. When I do so, I get a linker error that BIO_new_dgram() is undefined. The following appears to fix the issue: ====cut here==== --- s_server.c.orig 2015-03-19 17:17:53 -0700 +++ s_server.c 2015-04-20 11:27:30 -0700 @@ -2183,6 +2183,7 @@ # endif #endif +#ifndef OPENSSL_NO_DGRAM if (stype == SOCK_DGRAM) { sbio = BIO_new_dgram(s, BIO_NOCLOSE); @@ -2220,6 +2221,9 @@ SSL_set_options(con, SSL_OP_COOKIE_EXCHANGE); } else sbio = BIO_new_socket(s, BIO_NOCLOSE); +#else + sbio = BIO_new_socket(s, BIO_NOCLOSE); #endif if (s_nbio_test) { BIO *test; ====cut here==== Does this fix make sense? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From john.vollaro at optum.com Mon Apr 20 21:10:10 2015 From: john.vollaro at optum.com (Vollaro, John) Date: Mon, 20 Apr 2015 21:10:10 +0000 Subject: [openssl-users] NULL EVP_PKEY Message-ID: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF96CA@APSWP0838.ms.ds.uhc.com> I am having a problem reading a password protected private key file (.pem) using the OpenSSL library (programmatically). I just get a NULL key returned. I am using the OpenSSL 1.0.2a 19 Mar 2015 library in a Windows environment. The code snippet as follows: char *pemFileName = "C:\\Work\\mypemfile.pem"; char passwordBuffer[12]; strcpy(passwordBuffer, "pwd1234"); OpenSSL_add_all_algorithms(); BIO *bio_key = BIO_new( BIO_s_file() ); BIO_read_filename( bio_key, pemFileName ); EVP_PKEY *sigkey = PEM_read_bio_PrivateKey( bio_key, NULL, NULL,(void *)passwordBuffer ); pemFileName is the (correct) path to the private key file. I did read that calling OpenSSL_add_all_algorithms() loads OpenSSL's table of algorithms and was a fix to this issue. In my case it has not helped. Thanks for any help in soliving this issue. John Vollaro Phone 860.221.0129 This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Apr 20 21:24:40 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 20 Apr 2015 21:24:40 +0000 Subject: [openssl-users] NULL EVP_PKEY In-Reply-To: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF96CA@APSWP0838.ms.ds.uhc.com> References: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF96CA@APSWP0838.ms.ds.uhc.com> Message-ID: <789a0246a064427086db75e66faff281@usma1ex-dag1mb2.msg.corp.akamai.com> > I am having a problem reading a password protected private key file (.pem) using the OpenSSL library (programmatically). Can you read it using the openssl command-line tool? -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From de.techno at gmail.com Tue Apr 21 09:52:17 2015 From: de.techno at gmail.com (dE) Date: Tue, 21 Apr 2015 15:22:17 +0530 Subject: [openssl-users] CTX_free crash In-Reply-To: References: <5533E5AB.9030109@gmail.com> Message-ID: <55361DD1.4050304@gmail.com> On 04/20/15 00:10, Salz, Rich wrote: >> Sometimes, the program crashes when doing an SSL_CTX_free; before the >> crash, ctx is an invalid pointer, that's why I can get a valid value from >> SSL_CTX_get_max_cert_list (ctx), so it's not a double free problem. > You mean it's a VALID pointer? > > We'll need a more detailed backtrace. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users Relevant parts of the BT #0 0x00007ffff54bde97 in raise () from /lib64/libc.so.6 #1 0x00007ffff54bf208 in abort () from /lib64/libc.so.6 #2 0x00007ffff54feea0 in ?? () from /lib64/libc.so.6 #3 0x00007ffff55048be in ?? () from /lib64/libc.so.6 #4 0x00007ffff55050ab in ?? () from /lib64/libc.so.6 #5 0x00007ffff6827f7c in CRYPTO_free (str=0x8fbfe0) at mem.c:401 #6 0x00007ffff67e99a0 in X509_VERIFY_PARAM_free (param=0x8fbfe0) at x509_vpm.c:102 #7 0x00007ffff6d5302a in SSL_CTX_free (a=0x8fe090) at ssl_lib.c:1944 From jb-openssl at wisemo.com Tue Apr 21 11:08:00 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 21 Apr 2015 13:08:00 +0200 Subject: [openssl-users] Peer closing connection with a FIN without first sending a close_notify In-Reply-To: <20150420162643.GJ25758@mournblade.imrryr.org> References: <20150420162643.GJ25758@mournblade.imrryr.org> Message-ID: <55362F90.4020903@wisemo.com> On 20/04/2015 18:26, Viktor Dukhovni wrote: > On Mon, Apr 20, 2015 at 03:03:37PM +0000, Jason Schultz wrote: > >> We have also read that this particular behavior is not unheard of in SSL >> implementations, and treating the TCP FIN as a proper way to close the >> connection as described above is OK. > Only when the application-level protocol contains sufficient framing, > to make additional framing in TLS redundant. This is not the case > in FTP in stream mode. FTP in block mode can signal end of file via > the block headers, and then TLS shutdown is not needed. (I've never > seen FTP used in block mode). I may have, once, when transferring data from an IBM mainframe (VM/CMS) to a PC. No longer recall the options I had to specify to the ftp client. 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 From jb-openssl at wisemo.com Tue Apr 21 11:12:59 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 21 Apr 2015 13:12:59 +0200 Subject: [openssl-users] BIO_new_dgram() called in apps/s_server.c In-Reply-To: References: Message-ID: <553630BB.90805@wisemo.com> Obvious simplification: ====cut here==== --- s_server.c.orig 2015-03-19 17:17:53 -0700 +++ s_server.c 2015-04-20 11:27:30 -0700 @@ -2183,6 +2183,7 @@ # endif #endif +#ifndef OPENSSL_NO_DGRAM if (stype == SOCK_DGRAM) { sbio = BIO_new_dgram(s, BIO_NOCLOSE); @@ -2220,6 +2221,9 @@ SSL_set_options(con, SSL_OP_COOKIE_EXCHANGE); } else +#endif sbio = BIO_new_socket(s, BIO_NOCLOSE); if (s_nbio_test) { ====cut here==== On 20/04/2015 20:34, Scott Neugroschl wrote: > Correction to subject, it's s_server.c My typo. > > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Scott Neugroschl > Sent: Monday, April 20, 2015 11:32 AM > To: openssl-users at mta.opensslfoundation.net > Subject: [openssl-users] BIO_new_dgram() called in apps/s_server.h > > > I am building OpenSSL 1.0.2a with no-dgram and no-dtls1. When I do so, I get a linker error that BIO_new_dgram() is undefined. > > The following appears to fix the issue: > > ====cut here==== > --- s_server.c.orig 2015-03-19 17:17:53 -0700 > +++ s_server.c 2015-04-20 11:27:30 -0700 > @@ -2183,6 +2183,7 @@ > # endif > #endif > > +#ifndef OPENSSL_NO_DGRAM > if (stype == SOCK_DGRAM) { > > sbio = BIO_new_dgram(s, BIO_NOCLOSE); @@ -2220,6 +2221,9 @@ > SSL_set_options(con, SSL_OP_COOKIE_EXCHANGE); > } else > sbio = BIO_new_socket(s, BIO_NOCLOSE); > +#else > + sbio = BIO_new_socket(s, BIO_NOCLOSE); #endif > > if (s_nbio_test) { > BIO *test; > ====cut here==== > > Does this fix make sense? > -- Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 This message is only for its intended recipient, delete if misaddressed. WiseMo - Remote Service Management for PCs, Phones and Embedded 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 From jetson23 at hotmail.com Tue Apr 21 11:30:07 2015 From: jetson23 at hotmail.com (Jason Schultz) Date: Tue, 21 Apr 2015 11:30:07 +0000 Subject: [openssl-users] Peer closing connection with a FIN without first sending a close_notify In-Reply-To: <20150420162643.GJ25758@mournblade.imrryr.org> References: , <20150420162643.GJ25758@mournblade.imrryr.org> Message-ID: Thanks for your response, Viktor. You views fall in line with our opinions on how the situation should be handled. Any other opinions? > Date: Mon, 20 Apr 2015 16:26:43 +0000 > From: openssl-users at dukhovni.org > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Peer closing connection with a FIN without first sending a close_notify > > On Mon, Apr 20, 2015 at 03:03:37PM +0000, Jason Schultz wrote: > > > We am seeing the following situation and are not quite sure the proper > > way to handle it, so I thought I'd solicit the mailing list. Our application > > is an FTP server using OpenSSL. The peer is a non-OpenSSL FTP client in > > active mode. The problem comes in with how the FTP client handles closing > > the data connection after doing a put and transferring a file from client > > to our server. Instead of sending a close_notify, it closes the connection > > with a TCP FIN. > > That's wrong. This client snatches defeat from the jaws of victory, > by failing to take advantage of the TLS shutdown facility to securely > signal end of data. Without SSL shutdown the data transfer is > vulnerable to truncation attacks. > > > > On our server, calls to SSL_read() and SSL_get_error() indicate an > > SSL_ERROR_SYSCALL, which we treat as a protocol violation and abort the > > connection. When the FTP implementation sees the abort, it tears down > > the connection and throws the file away. > > That's sensible default behaviour I think, but you may need > work-arounds for broken clients. > > > If we change our server to look for this specific case, and indicate a > > close to the FTP application instead of an abort, the FTP transfer completes > > successfully. > > Apply this work-around to as few clients as possible. > > > This is where our questions arise. First of all, the FTP client's close > > without being preceded by a close_notify seems to be a violation of the > > protocol, and OpenSSL handles it as such. > > Correct. > > > Does changing the way it's handled open up our application to truncation > > attacks? > > Yes. > > > We have also read that this particular behavior is not unheard of in SSL > > implementations, and treating the TCP FIN as a proper way to close the > > connection as described above is OK. > > Only when the application-level protocol contains sufficient framing, > to make additional framing in TLS redundant. This is not the case > in FTP in stream mode. FTP in block mode can signal end of file via > the block headers, and then TLS shutdown is not needed. (I've never > seen FTP used in block mode). > > > Given the conflicting information we have seen, what is the opinion of > > the OpenSSL team? > > I don't speak for the team. My opinion is that the client is broken > unless it is using FTP in some manner that provides in-band file > integrity. > > So any work-around may require client-specific configuration so as > not to downgrade all clients. > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Charles.Barbe at allworx.com Tue Apr 21 13:00:19 2015 From: Charles.Barbe at allworx.com (Barbe, Charles) Date: Tue, 21 Apr 2015 13:00:19 +0000 Subject: [openssl-users] af_alg engine: digests work but ciphers do not? In-Reply-To: References: Message-ID: I've spent the last few days configuring the cryptodev engine on my platform and I am also seeing the same behavior with that engine as I did with af_alg. It seems like OpenSSL does not even attempt to use the engine for ciphers. My next step is to start plowing through the openssl code to figure out how control is supposed to get passed to an engine - I believe this happens in evp_enc.c. Something tells me I'm just missing something fundamental here... like a configuration option on build or maybe something I missed in openssl.conf. Does anybody have any expertise in this? Charles A. Barbe Senior Software Engineer Allworx, a Windstream company 245 East Main St | Rochester NY | 14604 Charles.Barbe at allworx.com | 585.421.5565 ________________________________________ From: openssl-users [openssl-users-bounces at openssl.org] on behalf of Barbe, Charles [Charles.Barbe at allworx.com] Sent: Wednesday, April 15, 2015 5:43 PM To: openssl-users at openssl.org Subject: [openssl-users] af_alg engine: digests work but ciphers do not? I'm wondering if anybody has any experience with the af_alg engine located here: http://src.carnivore.it/users/common/af_alg/about/ I am able to compile the engine and can run commands such as: openssl speed md5 -engine af_alg and I see that openssl has loaded the engine as indicated by this line in the output: engine "af_alg" set and can enable dmesg logging on the linux driver for my particular hardware and see that the driver is being used as expected. However, if I try to do a cipher instead of a digest, my driver is not used. For example, when I run: openssl speed aes-256-cbc -engine af_alg I see the engine get loaded but my dmesg logging indicates that the kernel driver was not used. And i get the same results for any of my supported ciphers. I have followed all the instructions in the URL located above including modifying my openssl.conf to include the proper configuration of the supported ciphers for my hardware but to no avail. Here is what the top of my openssl.conf looks like: # # OpenSSL example configuration file. # This is mostly being used for generation of certificate requests. # # This definition stops the following lines choking if HOME isn't # defined. HOME = . RANDFILE = $ENV::HOME/.rnd # Extra OBJECT IDENTIFIER info: #oid_file = $ENV::HOME/.oid oid_section = new_oids openssl_conf = openssl_def [openssl_def] engines = openssl_engines [openssl_engines] af_alg = af_alg_engine [af_alg_engine] default_algorithms = ALL CIPHERS=aes-128-cbc aes-192-cbc aes-256-cbc des-cbc des-ede3-cbc DIGESTS=md4 md5 sha1 sha224 sha256 sha512 # To use this configuration file with the "-extfile" option of the # "openssl x509" utility, name here the section containing the # X.509v3 extensions to use: # extensions = # (Alternatively, use a configuration file that has only # X.509v3 extensions in its main [= default] section.) [ new_oids ] # We can add new OIDs in here for use by 'ca', 'req' and 'ts'. For reference, I am running the following: linux kernel v 3.19 openssl v 1.0.1m running on a TI am3352 Any help on why digests seem to be working with the af_alg engine but ciphers do not would be much appreciated. Charles A. Barbe Senior Software Engineer Allworx, a Windstream company 245 East Main St | Rochester NY | 14604 Charles.Barbe at allworx.com | 585.421.5565 ---------------------------------------------------------------------- This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From steve at openssl.org Tue Apr 21 14:05:46 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 21 Apr 2015 14:05:46 +0000 Subject: [openssl-users] af_alg engine: digests work but ciphers do not? In-Reply-To: References: Message-ID: <20150421140546.GA22572@openssl.org> On Tue, Apr 21, 2015, Barbe, Charles wrote: > I've spent the last few days configuring the cryptodev engine on my platform and I am also seeing the same behavior with that engine as I did with af_alg. It seems like OpenSSL does not even attempt to use the engine for ciphers. My next step is to start plowing through the openssl code to figure out how control is supposed to get passed to an engine - I believe this happens in evp_enc.c. > > Something tells me I'm just missing something fundamental here... like a configuration option on build or maybe something I missed in openssl.conf. > [snip] > However, if I try to do a cipher instead of a digest, my driver is not used. For example, when I run: > > openssl speed aes-256-cbc -engine af_alg > The speed command uses EVP for all digest operations but uses low level APIs for cipher operations when you don't include the -evp option. ENGINEs only work at the EVP level so your above command will just use the built in ciphers. If instead you do: openssl speed -evp aes-256-cbc It should work if you've set up an ENGINE to provide the default implementation. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From john.vollaro at optum.com Tue Apr 21 14:27:50 2015 From: john.vollaro at optum.com (Vollaro, John) Date: Tue, 21 Apr 2015 14:27:50 +0000 Subject: [openssl-users] NULL EVP_PKEY In-Reply-To: <789a0246a064427086db75e66faff281@usma1ex-dag1mb2.msg.corp.akamai.com> References: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF96CA@APSWP0838.ms.ds.uhc.com> <789a0246a064427086db75e66faff281@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9A22@APSWP0838.ms.ds.uhc.com> It does not work using the openssl command-line tool. I suspect that the .pem file I have only has the public key. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich Sent: Monday, April 20, 2015 5:25 PM To: openssl-users at openssl.org; Lichti, Richard Subject: Re: [openssl-users] NULL EVP_PKEY > I am having a problem reading a password protected private key file (.pem) using the OpenSSL library (programmatically). Can you read it using the openssl command-line tool? -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. From Charles.Barbe at allworx.com Tue Apr 21 17:10:40 2015 From: Charles.Barbe at allworx.com (Barbe, Charles) Date: Tue, 21 Apr 2015 17:10:40 +0000 Subject: [openssl-users] af_alg engine: digests work but ciphers do not? In-Reply-To: <20150421140546.GA22572@openssl.org> References: , <20150421140546.GA22572@openssl.org> Message-ID: That was it... thank you so much!!! Charles A. Barbe Senior Software Engineer Allworx, a Windstream company 245 East Main St | Rochester NY | 14604 Charles.Barbe at allworx.com | 585.421.5565 ________________________________________ From: openssl-users [openssl-users-bounces at openssl.org] on behalf of Dr. Stephen Henson [steve at openssl.org] Sent: Tuesday, April 21, 2015 10:05 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] af_alg engine: digests work but ciphers do not? On Tue, Apr 21, 2015, Barbe, Charles wrote: > I've spent the last few days configuring the cryptodev engine on my platform and I am also seeing the same behavior with that engine as I did with af_alg. It seems like OpenSSL does not even attempt to use the engine for ciphers. My next step is to start plowing through the openssl code to figure out how control is supposed to get passed to an engine - I believe this happens in evp_enc.c. > > Something tells me I'm just missing something fundamental here... like a configuration option on build or maybe something I missed in openssl.conf. > [snip] > However, if I try to do a cipher instead of a digest, my driver is not used. For example, when I run: > > openssl speed aes-256-cbc -engine af_alg > The speed command uses EVP for all digest operations but uses low level APIs for cipher operations when you don't include the -evp option. ENGINEs only work at the EVP level so your above command will just use the built in ciphers. If instead you do: openssl speed -evp aes-256-cbc It should work if you've set up an ENGINE to provide the default implementation. 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 ---------------------------------------------------------------------- This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. From scott_n at xypro.com Tue Apr 21 18:42:37 2015 From: scott_n at xypro.com (Scott Neugroschl) Date: Tue, 21 Apr 2015 18:42:37 +0000 Subject: [openssl-users] Compiling for multiple platforms? Message-ID: I'm cross-compiling for multiple platforms. Any changes I make to platform A have to be reflected in platform B. Currently, I have to have two full source trees, and ensure that they're in sync. Is there a way to specify where objects and binaries go? Or, alternatively, where the source lives (rather like OpenSSH's --srcdir option)? I.e, what I'd like to see is openssl | +- src | | | +- apps | | | +- cryto | | | ... | +- platformA | | | +- libcrypto.a | | | +- libssl.a | | | +- openssl | +- platformA | +- libcrypto.a | +- libssl.a | +- openssl --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Apr 21 18:45:35 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 21 Apr 2015 18:45:35 +0000 Subject: [openssl-users] Compiling for multiple platforms? In-Reply-To: References: Message-ID: > Is there a way to specify where objects and binaries go? Or, alternatively, where the source lives (rather like OpenSSH's --srcdir option)? Not currently. This might change as the make "system" is being reviewed and overhauled. Until then, rsync is your best option, as long as all your platforms look like unix :) -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From scott_n at xypro.com Tue Apr 21 18:50:25 2015 From: scott_n at xypro.com (Scott Neugroschl) Date: Tue, 21 Apr 2015 18:50:25 +0000 Subject: [openssl-users] BIO_new_dgram() called in apps/s_server.c Message-ID: Reposting because I sent it to the "mta" address: I am building OpenSSL 1.0.2a with no-dgram and no-dtls1. When I do so, I get a linker error that BIO_new_dgram() is undefined. The following appears to fix the issue: ====cut here==== --- s_server.c.orig 2015-03-19 17:17:53 -0700 +++ s_server.c 2015-04-20 11:27:30 -0700 @@ -2183,6 +2183,7 @@ # endif #endif +#ifndef OPENSSL_NO_DGRAM if (stype == SOCK_DGRAM) { sbio = BIO_new_dgram(s, BIO_NOCLOSE); @@ -2220,6 +2221,9 @@ SSL_set_options(con, SSL_OP_COOKIE_EXCHANGE); } else sbio = BIO_new_socket(s, BIO_NOCLOSE); +#else + sbio = BIO_new_socket(s, BIO_NOCLOSE); +#endif if (s_nbio_test) { BIO *test; ====cut here==== Does this fix make sense? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.vollaro at optum.com Tue Apr 21 21:21:47 2015 From: john.vollaro at optum.com (Vollaro, John) Date: Tue, 21 Apr 2015 21:21:47 +0000 Subject: [openssl-users] Delete a post to openssl-user mailing list Message-ID: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9D3E@APSWP0838.ms.ds.uhc.com> Is it possible to remove a message I posted to the openssl-user email forum? This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. From roy_shanku at yahoo.com Tue Apr 21 23:54:22 2015 From: roy_shanku at yahoo.com (Shanku Roy) Date: Tue, 21 Apr 2015 23:54:22 +0000 (UTC) Subject: [openssl-users] Builing libcrypto/libssl without symbolic link Message-ID: <1383649440.1590706.1429660462610.JavaMail.yahoo@mail.yahoo.com> Hello OpneSSL Community, OpenSSL build system currently creates symbolic links to actual binaries?and actual binaries are?named as *.so.1.0.0 : lrw-r--r-- root???? root????????????? 2015-04-10 02:33 libcrypto.so -> libcrypto.so.1.0.0 -rw-r--r-- root???? root????? 1988088 2015-04-10 02:27 libcrypto.so.1.0.0 lrw-r--r-- root???? root????????????? 2015-04-10 02:33 libssl.so -> libssl.so.1.0.0 -rw-r--r-- root???? root?????? 354824 2015-04-10 02:27 libssl.so.1.0.0 Is there any configure option in OpenSSL build scripts to not generate the symbolic links and rather generate actual binary as libcrypto.so/libssl.so from the build process like following: -rw-r--r-- root???? root????? 1235987 2013-03-11 08:15 libcrypto.so-rw-r--r-- root???? root?????? 268972 2013-03-11 08:15 libssl.so If not then is there a simple way to modify OpenSSL build scripts to achieve this? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From roy_shanku at yahoo.com Wed Apr 22 00:12:45 2015 From: roy_shanku at yahoo.com (Shanku Roy) Date: Wed, 22 Apr 2015 00:12:45 +0000 (UTC) Subject: [openssl-users] Building libcrypto/libssl without symbolic link Message-ID: <1392557800.1633459.1429661565215.JavaMail.yahoo@mail.yahoo.com> Hello OpneSSL Community, OpenSSL build system currently creates symbolic links to actual binaries and actual binaries are named as *.so.1.0.0 : lrw-r--r-- root root 2015-04-10 02:33 libcrypto.so -> libcrypto.so.1.0.0 -rw-r--r-- root root 1988088 2015-04-10 02:27 libcrypto.so.1.0.0 lrw-r--r-- root root 2015-04-10 02:33 libssl.so -> libssl.so.1.0.0 -rw-r--r-- root root 354824 2015-04-10 02:27 libssl.so.1.0.0 Is there any configure option in OpenSSL build scripts to not generate the symbolic links and rather generate actual binary as libcrypto.so/libssl.so from the build process like following: -rw-r--r-- root root 1235987 2013-03-11 08:15 libcrypto.so -rw-r--r-- root root 268972 2013-03-11 08:15 libssl.so If not then is there a simple way to modify OpenSSL build scripts to achieve this? Thanks From openssl-users at dukhovni.org Wed Apr 22 00:13:26 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 22 Apr 2015 00:13:26 +0000 Subject: [openssl-users] Delete a post to openssl-user mailing list In-Reply-To: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9D3E@APSWP0838.ms.ds.uhc.com> References: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9D3E@APSWP0838.ms.ds.uhc.com> Message-ID: <20150422001326.GG25758@mournblade.imrryr.org> On Tue, Apr 21, 2015 at 09:21:47PM +0000, Vollaro, John wrote: > Is it possible to remove a message I posted to the openssl-user email forum? No. -- Viktor. From openssl-users at dukhovni.org Wed Apr 22 03:47:19 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 22 Apr 2015 03:47:19 +0000 Subject: [openssl-users] Building libcrypto/libssl without symbolic link In-Reply-To: <1392557800.1633459.1429661565215.JavaMail.yahoo@mail.yahoo.com> References: <1392557800.1633459.1429661565215.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20150422034718.GI25758@mournblade.imrryr.org> On Wed, Apr 22, 2015 at 12:12:45AM +0000, Shanku Roy wrote: > lrw-r--r-- root root 2015-04-10 02:33 libcrypto.so -> libcrypto.so.1.0.0 > -rw-r--r-- root root 1988088 2015-04-10 02:27 libcrypto.so.1.0.0 > > Is there any configure option in OpenSSL build scripts to not generate > the symbolic links and rather generate actual binary as > libcrypto.so/libssl.so from the build process like following: The library "soname" is part of the ABI. What platform are you building for where it would not be appropriate to encode the ABI compatibility name into the library name? -- Viktor. From erik at efca.com Wed Apr 22 06:31:18 2015 From: erik at efca.com (Erik Forsberg) Date: Tue, 21 Apr 2015 23:31:18 -0700 Subject: [openssl-users] Building libcrypto/libssl without symbolic link Message-ID: Not sure what platform the other person is using, but, for the record the soname 1.0.0 causes big problems on Solaris 11 and up. Solaris 11 ships an OpenSSL 1.0.0 version in standard library locations, if anyone just builds anything higher than that, and do NOT modify build to add -R runtime load paths, you will see the libssl built link with Solaris 11 libcrypto which is not good. There are functions in 1.0.1 that do not exist in 1.0.0 I have seen a change in version naming strategy in main branch, so hopefully this will soon be not an issue. FYI, changing LD_LIBRARY_PATH using crle, is a bad idea on Solaris 11, made my boot environment un-bootable. For Solaris at least, I think its a good idea to modify makefiles to always provide the -R option to the linker. I have used that for a very long time, and avoided any collisions with standard Solaris versions. >-- Original Message -- > >On Wed, Apr 22, 2015 at 12:12:45AM +0000, Shanku Roy wrote: > >> lrw-r--r-- root root 2015-04-10 02:33 libcrypto.so -> libcrypto.so.1.0.0 >> -rw-r--r-- root root 1988088 2015-04-10 02:27 libcrypto.so.1.0.0 >> >> Is there any configure option in OpenSSL build scripts to not generate >> the symbolic links and rather generate actual binary as >> libcrypto.so/libssl.so from the build process like following: > >The library "soname" is part of the ABI. What platform are you >building for where it would not be appropriate to encode the ABI >compatibility name into the library name? > >-- > Viktor. >_______________________________________________ >openssl-users mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From kiwi.tigrou at yopmail.com Wed Apr 22 09:24:20 2015 From: kiwi.tigrou at yopmail.com (stacy) Date: Wed, 22 Apr 2015 11:24:20 +0200 Subject: [openssl-users] evp test for CTR mode Message-ID: <6bd1b4f3695f040f2089c4aff16142d7@wifirst.net> Hi, I played with autotest offered by openssl, more precisely /test/evp_test. Is there a way to test vectors tests from NIST SP800-38A for CTR mode (only vectors from RFC 3686 are taillable in evptests.txt). I add the vectors in the files but the results are not the expected results. Is there a link with endianess? I read in the code (extract from /crypto/modes/ctr128.c) : /* NOTE: the IV/counter CTR mode is big-endian. The code itself * is endian-neutral. */ Maybe i have to modified IV before passing it to openssl? Thanks From klybzh22 at wifirst.net Wed Apr 22 09:28:06 2015 From: klybzh22 at wifirst.net (klybzh22 at wifirst.net) Date: Wed, 22 Apr 2015 11:28:06 +0200 Subject: [openssl-users] evp test for CTR mode Message-ID: <90344812be52d2161157ed9a04651e32@wifirst.net> Hi, I played with autotest offered by openssl, more precisely /test/evp_test. Is there a way to test vectors tests from NIST SP800-38A for CTR mode (only vectors from RFC 3686 are taillable in evptests.txt). I add the vectors in the files but the results are not the expected results. Is there a link with endianess? I read in the code (extract from /crypto/modes/ctr128.c) : /* NOTE: the IV/counter CTR mode is big-endian. The code itself * is endian-neutral. */ Maybe i have to modified IV before passing it to openssl? Thanks From steve at openssl.org Wed Apr 22 13:10:59 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 22 Apr 2015 13:10:59 +0000 Subject: [openssl-users] NULL EVP_PKEY In-Reply-To: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9A22@APSWP0838.ms.ds.uhc.com> References: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF96CA@APSWP0838.ms.ds.uhc.com> <789a0246a064427086db75e66faff281@usma1ex-dag1mb2.msg.corp.akamai.com> <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9A22@APSWP0838.ms.ds.uhc.com> Message-ID: <20150422131059.GA15681@openssl.org> On Tue, Apr 21, 2015, Vollaro, John wrote: > It does not work using the openssl command-line tool. > I suspect that the .pem file I have only has the public key. > It would help if you indicated what error you got from the openssl utility. If the file only contains a public key it should exit immediately if it has a private key and is encrypted it will prompt you for a passphrase. Other problems (e.g. corrupted key) may result in ASN.1 parsing errors. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From roy_shanku at yahoo.com Wed Apr 22 13:41:23 2015 From: roy_shanku at yahoo.com (Shanku Roy) Date: Wed, 22 Apr 2015 13:41:23 +0000 (UTC) Subject: [openssl-users] Building libcrypto/libssl without symbolic link In-Reply-To: <20150422034718.GI25758@mournblade.imrryr.org> References: <20150422034718.GI25758@mournblade.imrryr.org> Message-ID: <1867949816.1979893.1429710083420.JavaMail.yahoo@mail.yahoo.com> Am cross compiling the FIPS enabled version for Android; In Android, some apps are having trouble loading their bundled libcrypto library when the binary is named as *.so.1.0.0 instead of libcrypto.so as platform library. ----- Original Message ----- From: Viktor Dukhovni To: openssl-users at openssl.org Cc: Sent: Tuesday, April 21, 2015 11:47 PM Subject: Re: [openssl-users] Building libcrypto/libssl without symbolic link On Wed, Apr 22, 2015 at 12:12:45AM +0000, Shanku Roy wrote: > lrw-r--r-- root root 2015-04-10 02:33 libcrypto.so -> libcrypto.so.1.0.0 > -rw-r--r-- root root 1988088 2015-04-10 02:27 libcrypto.so.1.0.0 > > Is there any configure option in OpenSSL build scripts to not generate > the symbolic links and rather generate actual binary as > libcrypto.so/libssl.so from the build process like following: The library "soname" is part of the ABI. What platform are you building for where it would not be appropriate to encode the ABI compatibility name into the library name? -- Viktor. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From john.vollaro at optum.com Wed Apr 22 13:55:49 2015 From: john.vollaro at optum.com (Vollaro, John) Date: Wed, 22 Apr 2015 13:55:49 +0000 Subject: [openssl-users] Delete a post to openssl-user mailing list In-Reply-To: <20150422001326.GG25758@mournblade.imrryr.org> References: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9D3E@APSWP0838.ms.ds.uhc.com> <20150422001326.GG25758@mournblade.imrryr.org> Message-ID: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9FD5@APSWP0838.ms.ds.uhc.com> Can a message be removed by the system administrator of the openssl-user email forum? My original post about " NULL EVP_PKEY" was flag by my company as a security risk. The data in the post was "fake". I have been directed to remove the post if possible. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Tuesday, April 21, 2015 8:13 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Delete a post to openssl-user mailing list On Tue, Apr 21, 2015 at 09:21:47PM +0000, Vollaro, John wrote: > Is it possible to remove a message I posted to the openssl-user email forum? No. -- Viktor. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. From erwann.abalea at opentrust.com Wed Apr 22 14:20:20 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Wed, 22 Apr 2015 16:20:20 +0200 Subject: [openssl-users] Delete a post to openssl-user mailing list In-Reply-To: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9FD5@APSWP0838.ms.ds.uhc.com> References: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9D3E@APSWP0838.ms.ds.uhc.com> <20150422001326.GG25758@mournblade.imrryr.org> <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9FD5@APSWP0838.ms.ds.uhc.com> Message-ID: <5537AE24.1090708@opentrust.com> Bonjour, The password "pwd1234" is obviously a test one, as is the file path "c:/work/mypemfile.pem". Knowing that you're using OpenSSL 1.0.2a shouldn't be a problem either. What is the security risk? -- Erwann ABALEA Le 22/04/2015 15:55, Vollaro, John a ?crit : > Can a message be removed by the system administrator of the openssl-user email forum? > > My original post about " NULL EVP_PKEY" was flag by my company as a security risk. > The data in the post was "fake". I have been directed to remove the post if possible. > > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni > Sent: Tuesday, April 21, 2015 8:13 PM > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Delete a post to openssl-user mailing list > > On Tue, Apr 21, 2015 at 09:21:47PM +0000, Vollaro, John wrote: > >> Is it possible to remove a message I posted to the openssl-user email forum? > No. > From foleyj at cisco.com Wed Apr 22 14:26:14 2015 From: foleyj at cisco.com (John Foley) Date: Wed, 22 Apr 2015 10:26:14 -0400 Subject: [openssl-users] Building libcrypto/libssl without symbolic link In-Reply-To: <1867949816.1979893.1429710083420.JavaMail.yahoo@mail.yahoo.com> References: <20150422034718.GI25758@mournblade.imrryr.org> <1867949816.1979893.1429710083420.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5537AF86.6080404@cisco.com> Are you packaging libcrypto.so into the APK yourself? The Android OS comes with it's own resident copy of libcrypto. You can leverage this from your app without having to package libcrypto into your application. This assumes the version of libcrypto that comes with Android meets your needs. Given the various flavors of Android out in the wild, this may limit what your application can do with libcrypto. If you're packaging libcrypto into your APK, one problem I've seen in Android is the System.LoadLibrary() call will use the host resident copy of libcrypto instead of the one packaged in the APK. One way to get around this is to hack the linker step in the OpenSSL makefile to rename libcrypto to something different. You'll need to make sure the -soname option on the linker step is consistent with whatever you name the library. For instance, you can name it libcryptoX.so, and pass in this same name to the -soname option. Confirm that it works using objdump to view the ELF header. The soname will be in the ELF header. Then package libcryptoX.so into your APK and use this name with the System.LoadLibrary() call. On 04/22/2015 09:41 AM, Shanku Roy wrote: > Am cross compiling the FIPS enabled version for Android; In Android, some apps are having trouble loading their bundled libcrypto library when the binary is named as *.so.1.0.0 instead of libcrypto.so as platform library. > > > ----- Original Message ----- > From: Viktor Dukhovni > To: openssl-users at openssl.org > Cc: > Sent: Tuesday, April 21, 2015 11:47 PM > Subject: Re: [openssl-users] Building libcrypto/libssl without symbolic link > > On Wed, Apr 22, 2015 at 12:12:45AM +0000, Shanku Roy wrote: >> lrw-r--r-- root root 2015-04-10 02:33 libcrypto.so -> libcrypto.so.1.0.0 >> -rw-r--r-- root root 1988088 2015-04-10 02:27 libcrypto.so.1.0.0 >> >> Is there any configure option in OpenSSL build scripts to not generate >> the symbolic links and rather generate actual binary as >> libcrypto.so/libssl.so from the build process like following: > The library "soname" is part of the ABI. What platform are you > building for where it would not be appropriate to encode the ABI > compatibility name into the library name? > From rsalz at akamai.com Wed Apr 22 14:27:40 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 22 Apr 2015 14:27:40 +0000 Subject: [openssl-users] Delete a post to openssl-user mailing list In-Reply-To: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9FD5@APSWP0838.ms.ds.uhc.com> References: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9D3E@APSWP0838.ms.ds.uhc.com> <20150422001326.GG25758@mournblade.imrryr.org> <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9FD5@APSWP0838.ms.ds.uhc.com> Message-ID: > Can a message be removed by the system administrator of the openssl-user > email forum? There are several places that archive openssl mailing lists. > My original post about " NULL EVP_PKEY" was flag by my company as a security risk. That seems erroneous to me. > I have been directed to remove the post if possible. Not really possible. You can try to track down all the archive sites (some are listed on www.openssl.org, but probably not all). From Michael.Wojcik at microfocus.com Wed Apr 22 14:39:00 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 22 Apr 2015 14:39:00 +0000 Subject: [openssl-users] Delete a post to openssl-user mailing list In-Reply-To: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9FD5@APSWP0838.ms.ds.uhc.com> References: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9D3E@APSWP0838.ms.ds.uhc.com> <20150422001326.GG25758@mournblade.imrryr.org> <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9FD5@APSWP0838.ms.ds.uhc.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Vollaro, John > Sent: Wednesday, April 22, 2015 09:56 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Delete a post to openssl-user mailing list > > Can a message be removed by the system administrator of the openssl-user > email forum? No. It's a mailing list. When your message was accepted by the list server, the server sent copies of it to every subscriber. That means (nearly) every subscriber had a copy at some point; most probably still have one or more, in a "deleted items" mail folder, in backups, etc. Some of those subscribers are actually robots - often gateways and archives like Gmane, which forwarded your message on and/or saved a copy in some repository that can be queried later. So, for example, your original message is also available from the Gmane web interface: http://article.gmane.org/gmane.comp.encryption.openssl.user/54716 And that means it's been indexed and cached by Google and other web spiders. You'll never track down all the copies. Even if you did, you'll never get everyone who has one to delete it. I'm afraid that cat is not only out of the bag, but no longer visible from the bag with the naked eye and receeding at high speed. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com From jonetsu at teksavvy.com Wed Apr 22 14:43:03 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Wed, 22 Apr 2015 07:43:03 -0700 (MST) Subject: [openssl-users] Delete a post to openssl-user mailing list In-Reply-To: <5537AE24.1090708@opentrust.com> References: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9D3E@APSWP0838.ms.ds.uhc.com> <20150422001326.GG25758@mournblade.imrryr.org> <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9FD5@APSWP0838.ms.ds.uhc.com> <5537AE24.1090708@opentrust.com> Message-ID: <1429713783002-57670.post@n7.nabble.com> > What is the security risk? Management ? :) -- View this message in context: http://openssl.6102.n7.nabble.com/openssl-users-Delete-a-post-to-openssl-user-mailing-list-tp57653p57670.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From chris.gray at kiffer.be Wed Apr 22 15:47:14 2015 From: chris.gray at kiffer.be (chris.gray at kiffer.be) Date: Wed, 22 Apr 2015 16:47:14 +0100 Subject: [openssl-users] Delete a post to openssl-user mailing list In-Reply-To: <1429713783002-57670.post@n7.nabble.com> References: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9D3E@APSWP0838.ms.ds.uhc.com> <20150422001326.GG25758@mournblade.imrryr.org> <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9FD5@APSWP0838.ms.ds.uhc.com> <5537AE24.1090708@opentrust.com> <1429713783002-57670.post@n7.nabble.com> Message-ID: >> What is the security risk? > > Management ? :) There could be a perceived problem that the world now knows that "company X has problems with OpenSSL", and a competitor could even try to make mischievous use of this "information" - it happened to me once (with another technology). Death of developer mailing lists predicted; film at 11. From jonetsu at teksavvy.com Wed Apr 22 18:30:32 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Wed, 22 Apr 2015 11:30:32 -0700 (MST) Subject: [openssl-users] Delete a post to openssl-user mailing list In-Reply-To: References: <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9D3E@APSWP0838.ms.ds.uhc.com> <20150422001326.GG25758@mournblade.imrryr.org> <14BFB9F1FC4A3B4AA76108325E1CEB760DDF9FD5@APSWP0838.ms.ds.uhc.com> <5537AE24.1090708@opentrust.com> <1429713783002-57670.post@n7.nabble.com> Message-ID: <1429727432227-57673.post@n7.nabble.com> It can be indeed easy to find out about companies in Hartford, CT but, I still do not see any threat to any existing product. 'Having problems with OpenSSL' is not good enough. In any case, when concerned, do like many people and use a pseudo from another mailing system. Employees will not gain promotion points anyways by having their real names in mailing lists. -- View this message in context: http://openssl.6102.n7.nabble.com/openssl-users-Delete-a-post-to-openssl-user-mailing-list-tp57653p57673.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From jb-openssl at wisemo.com Wed Apr 22 19:04:04 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 22 Apr 2015 21:04:04 +0200 Subject: [openssl-users] Building libcrypto/libssl without symbolic link In-Reply-To: <5537AF86.6080404@cisco.com> References: <20150422034718.GI25758@mournblade.imrryr.org> <1867949816.1979893.1429710083420.JavaMail.yahoo@mail.yahoo.com> <5537AF86.6080404@cisco.com> Message-ID: <5537F0A4.3080302@wisemo.com> (Top posting because some other posters did so). Please note the following problems with the so naming defaults in version 1.0.2a: 1. On Android, developers are (or were until recently) officially told *not* to rely on the system copy of OpenSSL, since it is not part of the official API. Thus packaging your own copy or relying on the botched version of Java JCE implemented on top of the system OpenSSL are the only officially supported options. 2. On many systems that install OpenSSL 1.0.1 (any patch level) as libcrypto.so.1.0.0, installing OpenSSL 1.0.2a as libcrypto.so.1.0.0 will instantly break system software linked against the 1.0.1 under the same ABI name. So much for binary compatibility. Thus for Android, you would want to link it as libcom_yourdomain_yourapp_crypto.so (file name must match lib*.so for theapk to unpack correctly), or as a static PIC library, making the system think it has nothing to do with any well-known or other app's copy of OpenSSL. Be sure to release new versions of your app whenever an OpenSSL security update affects something you actually use from the library. For parallel installation of OpenSSL 1.0.2a and the OS supplied OpenSSL 1.0.1 (with patches equivalent to the latest release), modify SHLIB_VERSION_NUMBER from 1.0.0 to 1.0.2 in the folliwing files from the tarball: crypto/opensslv.h Makefile Makefile.bak I have pasted the patch I use at the end of this mail (nothing cryptographic, soI think I can post that without extra red tape). On 22/04/2015 16:26, John Foley wrote: > Are you packaging libcrypto.so into the APK yourself? The Android OS > comes with it's own resident copy of libcrypto. You can leverage this > from your app without having to package libcrypto into your > application. This assumes the version of libcrypto that comes with > Android meets your needs. Given the various flavors of Android out in > the wild, this may limit what your application can do with libcrypto. > > If you're packaging libcrypto into your APK, one problem I've seen in > Android is the System.LoadLibrary() call will use the host resident copy > of libcrypto instead of the one packaged in the APK. One way to get > around this is to hack the linker step in the OpenSSL makefile to rename > libcrypto to something different. You'll need to make sure the -soname > option on the linker step is consistent with whatever you name the > library. For instance, you can name it libcryptoX.so, and pass in this > same name to the -soname option. Confirm that it works using objdump to > view the ELF header. The soname will be in the ELF header. Then > package libcryptoX.so into your APK and use this name with the > System.LoadLibrary() call. > > > > On 04/22/2015 09:41 AM, Shanku Roy wrote: >> Am cross compiling the FIPS enabled version for Android; In Android, some apps are having trouble loading their bundled libcrypto library when the binary is named as *.so.1.0.0 instead of libcrypto.so as platform library. >> >> >> ----- Original Message ----- >> From: Viktor Dukhovni >> To: openssl-users at openssl.org >> Cc: >> Sent: Tuesday, April 21, 2015 11:47 PM >> Subject: Re: [openssl-users] Building libcrypto/libssl without symbolic link >> >> On Wed, Apr 22, 2015 at 12:12:45AM +0000, Shanku Roy wrote: >>> lrw-r--r-- root root 2015-04-10 02:33 libcrypto.so -> libcrypto.so.1.0.0 >>> -rw-r--r-- root root 1988088 2015-04-10 02:27 libcrypto.so.1.0.0 >>> >>> Is there any configure option in OpenSSL build scripts to not generate >>> the symbolic links and rather generate actual binary as >>> libcrypto.so/libssl.so from the build process like following: >> The library "soname" is part of the ABI. What platform are you >> building for where it would not be appropriate to encode the ABI >> compatibility name into the library name? (Beware of long lines in this patch) =================== Cut here =================== diff -Naur openssl-1.0.2a.orig/crypto/opensslv.h openssl-1.0.2a/crypto/opensslv.h --- openssl-1.0.2a.orig/crypto/opensslv.h 2015-03-19 14:31:16.000000000 +0100 +++ openssl-1.0.2a/crypto/opensslv.h 2015-03-22 23:10:15.000000000 +0100 @@ -88,7 +88,7 @@ * should only keep the versions that are binary compatible with the current. */ # define SHLIB_VERSION_HISTORY "" -# define SHLIB_VERSION_NUMBER "1.0.0" +# define SHLIB_VERSION_NUMBER "1.0.2" #ifdef __cplusplus diff -Naur openssl-1.0.2a.orig/Makefile openssl-1.0.2a/Makefile --- openssl-1.0.2a.orig/Makefile 2015-03-19 14:31:16.000000000 +0100 +++ openssl-1.0.2a/Makefile 2015-03-22 23:06:50.000000000 +0100 @@ -7,10 +7,10 @@ VERSION=1.0.2a MAJOR=1 MINOR=0.2 -SHLIB_VERSION_NUMBER=1.0.0 +SHLIB_VERSION_NUMBER=1.0.2 SHLIB_VERSION_HISTORY= SHLIB_MAJOR=1 -SHLIB_MINOR=0.0 +SHLIB_MINOR=0.2 SHLIB_EXT= PLATFORM=dist OPTIONS= no-ec_nistp_64_gcc_128 no-gmp no-jpake no-krb5 no-libunbound no-md2 no-rc5 no-rfc3779 no-sctp no-shared no-ssl-trace no-store no-unit-test no-zlib no-zlib-dynamic static-engine diff -Naur openssl-1.0.2a.orig/Makefile.bak openssl-1.0.2a/Makefile.bak --- openssl-1.0.2a.orig/Makefile.bak 2015-03-19 14:30:59.000000000 +0100 +++ openssl-1.0.2a/Makefile.bak 2015-03-22 23:07:01.000000000 +0100 @@ -7,10 +7,10 @@ VERSION=1.0.2a-dev MAJOR=1 MINOR=0.2 -SHLIB_VERSION_NUMBER=1.0.0 +SHLIB_VERSION_NUMBER=1.0.2 SHLIB_VERSION_HISTORY= SHLIB_MAJOR=1 -SHLIB_MINOR=0.0 +SHLIB_MINOR=0.2 SHLIB_EXT= PLATFORM=gcc OPTIONS= no-ec_nistp_64_gcc_128 no-gmp no-jpake no-krb5 no-libunbound no-md2 no-rc5 no-rfc3779 no-sctp no-shared no-ssl-trace no-store no-unit-test no-zlib no-zlib-dynamic static-engine =================== Cut here =================== 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 From openssl-users at dukhovni.org Wed Apr 22 19:49:11 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 22 Apr 2015 19:49:11 +0000 Subject: [openssl-users] Building libcrypto/libssl without symbolic link In-Reply-To: <5537F0A4.3080302@wisemo.com> References: <20150422034718.GI25758@mournblade.imrryr.org> <1867949816.1979893.1429710083420.JavaMail.yahoo@mail.yahoo.com> <5537AF86.6080404@cisco.com> <5537F0A4.3080302@wisemo.com> Message-ID: <20150422194911.GP25758@mournblade.imrryr.org> On Wed, Apr 22, 2015 at 09:04:04PM +0200, Jakob Bohm wrote: > For parallel installation of OpenSSL 1.0.2a and the OS > supplied OpenSSL 1.0.1 (with patches equivalent to the > latest release), modify SHLIB_VERSION_NUMBER from 1.0.0 > to 1.0.2 in the folliwing files from the tarball: The ABI version really is 1.0.0. Symbol versioning is the right way to distinguish between 1.0.[012]. The Debian OpenSSL build does symbol versioning to avoid conflicts between multiple libraries that support the 1.0.0 ABI. Yes, the ABI compatibility is only backwards compatibility, so applications that link to a newer version of the library at compile time, need to use the same or newer library at run-time. Applications using a non-system library need to record a suitable RPATH (often using "$ORIGIN" is a good bet if the application ships a copy of the library). Ideally applications would use the system supplied library, otherwise patching becomes rather difficult... -- Viktor. From h15234 at mailas.com Wed Apr 22 20:03:02 2015 From: h15234 at mailas.com (h15234 at mailas.com) Date: Wed, 22 Apr 2015 13:03:02 -0700 Subject: [openssl-users] Building libcrypto/libssl without symbolic link In-Reply-To: <20150422194911.GP25758@mournblade.imrryr.org> References: <20150422034718.GI25758@mournblade.imrryr.org> <1867949816.1979893.1429710083420.JavaMail.yahoo@mail.yahoo.com> <5537AF86.6080404@cisco.com> <5537F0A4.3080302@wisemo.com> <20150422194911.GP25758@mournblade.imrryr.org> Message-ID: <1429732982.891193.257307317.3B95D9C9@webmail.messagingengine.com> On Wed, Apr 22, 2015, at 12:49 PM, Viktor Dukhovni wrote: > Applications using a non-system library need to record a suitable > RPATH (often using "$ORIGIN" is a good bet if the application ships > a copy of the library). Ideally applications would use the system > supplied library, otherwise patching becomes rather difficult... Along similar lines, it would be useful to get RPATH'ing *in* openssl straigthened out "openssl 1.0.2 shared build's linking is not consistent - bin and libs linked to different libcrypto.so's" https://marc.info/?l=openssl-users&m=142858615805070&w=2 From jb-openssl at wisemo.com Wed Apr 22 20:17:21 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 22 Apr 2015 22:17:21 +0200 Subject: [openssl-users] Building libcrypto/libssl without symbolic link In-Reply-To: <20150422194911.GP25758@mournblade.imrryr.org> References: <20150422034718.GI25758@mournblade.imrryr.org> <1867949816.1979893.1429710083420.JavaMail.yahoo@mail.yahoo.com> <5537AF86.6080404@cisco.com> <5537F0A4.3080302@wisemo.com> <20150422194911.GP25758@mournblade.imrryr.org> Message-ID: <553801D1.6090308@wisemo.com> On 22/04/2015 21:49, Viktor Dukhovni wrote: > On Wed, Apr 22, 2015 at 09:04:04PM +0200, Jakob Bohm wrote: > >> For parallel installation of OpenSSL 1.0.2a and the OS >> supplied OpenSSL 1.0.1 (with patches equivalent to the >> latest release), modify SHLIB_VERSION_NUMBER from 1.0.0 >> to 1.0.2 in the folliwing files from the tarball: > The ABI version really is 1.0.0. Symbol versioning is the right > way to distinguish between 1.0.[012]. The Debian OpenSSL build > does symbol versioning to avoid conflicts between multiple libraries > that support the 1.0.0 ABI. > > Yes, the ABI compatibility is only backwards compatibility, so > applications that link to a newer version of the library at compile > time, need to use the same or newer library at run-time. > > Applications using a non-system library need to record a suitable > RPATH (often using "$ORIGIN" is a good bet if the application ships > a copy of the library). Ideally applications would use the system > supplied library, otherwise patching becomes rather difficult... > My observations were actually made on Debian. And I seem to recall itwas the system daemons that failed, not my newly recompiled daemons,though I may of cause be mistaken. As for symbol versioning, if that is not in the upstream tarball, any suchthings added by vendor compiles is just going to break the ABI, in factthe absence of symbol versioning in my vanilla compile may be whatcaused the problems for all the installed packages. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pratyush.parimal at gmail.com Wed Apr 22 20:23:48 2015 From: pratyush.parimal at gmail.com (pratyush parimal) Date: Wed, 22 Apr 2015 16:23:48 -0400 Subject: [openssl-users] How to find patches for a particular OpenSSL version? Message-ID: Hi all, I am currently using openssl 1.0.1e (compiling from source), and I was wondering whether I needed to put in any patch files with it as well. Does anybody know? Let's assume I can't just use a later version's tarball. In general I wanted to know how I could reliably find out what patches I need to apply for a particular OpenSSL version. Thanks, Pratyush Parimal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Apr 22 23:27:34 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 22 Apr 2015 23:27:34 +0000 Subject: [openssl-users] How to find patches for a particular OpenSSL version? In-Reply-To: References: Message-ID: <8dcbd36a900346b1b2dc1f8a21f0ccdc@usma1ex-dag1mb2.msg.corp.akamai.com> > I am currently using openssl 1.0.1e (compiling from source), and I was wondering whether I needed to put in any patch files with it as well. Does anybody know? Let's assume I can't just use a later version's tarball. There are no patch files. Letter releases, 1.0.1f, 1.0.1g, etc., are only bugfixes. You could read through the commit log, find which changes fixed bugs that you care about, get those commits, and apply them by hand. Ugh. That's going to take a very long time. You should reconsider your assumption. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From jb-openssl at wisemo.com Thu Apr 23 19:16:38 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 23 Apr 2015 21:16:38 +0200 Subject: [openssl-users] How to find patches for a particular OpenSSL version? In-Reply-To: <8dcbd36a900346b1b2dc1f8a21f0ccdc@usma1ex-dag1mb2.msg.corp.akamai.com> References: <8dcbd36a900346b1b2dc1f8a21f0ccdc@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <55394516.6020906@wisemo.com> On 23/04/2015 01:27, Salz, Rich wrote: >> I am currently using openssl 1.0.1e (compiling from source), and I was wondering whether I needed to put in any patch files with it as well. Does anybody know? Let's assume I can't just use a later version's tarball. > There are no patch files. Letter releases, 1.0.1f, 1.0.1g, etc., are only bugfixes. You could read through the commit log, find which changes fixed bugs that you care about, get those commits, and apply them by hand. Ugh. That's going to take a very long time. > > You should reconsider your assumption. Note however, that the Debian project, as a matter of policy, does this for *all* the software they ship, including OpenSSL 1.0.1e in wheezy. And it is probably a lot of work, made infinitely more difficult by the "not my style" wholesale reformatting of the latest 1.0.1 tarball. On the bad side, the patch work Debian does is specific to their OS, and has on at least one occasion introduced a major security flaw not in the official project. On the good side, there is no particular reason to take Mr. Salz advise in these matters, as he seems to be the project member with the least understanding of what other people need from the project. 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 From bcall at apache.org Thu Apr 23 23:23:29 2015 From: bcall at apache.org (Bryan Call) Date: Thu, 23 Apr 2015 16:23:29 -0700 Subject: [openssl-users] Performance problems with OpenSSL and threading Message-ID: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org> I was running a benchmark on a 28 core (56 hyper-threaded) server that is running 84 threads in the process and I am seeing a lot of lock contention. I saw a lot of lock contention in the calls to SSL_get_error() ssl3_accept(). I am running RHEL 6.5 and openssl-1.0.1e-30.el6_6.7.x86_64. We have used SSL_locking_callback() to setup pthread mutex locks, but haven?t setup dynlocks yet. Would dynlocks help in this scenario? Output from perf: Samples: 1M of event 'cycles', Event count (approx.): 602783506611 - 48.04% [ET_NET 0] [kernel.kallsyms] [k] _spin_lock ? - _spin_lock ? + 48.05% futex_wait_setup ? + 47.79% futex_wake ? + 1.20% tcp_v4_rcv ? + 0.98% task_rq_lock ? + 0.64% double_lock_balance ? + 3.94% [ET_NET 0] libcrypto.so.1.0.1e [.] bn_mul_mont ? + 1.93% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_usub ? + 1.80% [ET_NET 0] libcrypto.so.1.0.1e [.] 0x00000000000e5200 ? + 1.49% [ET_NET 0] libcrypto.so.1.0.1e [.] sha256_block_data_order ? + 0.97% [ET_NET 0] libcrypto.so.1.0.1e [.] gcm_ghash_clmul ? + 0.85% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_lock ? + 0.84% [ET_NET 0] libcrypto.so.1.0.1e [.] aesni_ctr32_encrypt_blocks ? + 0.74% [ET_NET 0] libc-2.12.so [.] malloc ? + 0.72% [ET_NET 0] libc-2.12.so [.] memcpy ? + 0.57% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_mod_mul_montgomery ? + 0.51% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_unlock pstack of the process (only a couple of the interesting threads): Thread 1 (Thread 0x7f1fba151800 (LWP 1106)): #0 0x00007f1fbaaeb264 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f1fbaae6508 in _L_lock_854 () from /lib64/libpthread.so.0 #2 0x00007f1fbaae63d7 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x000000000072822f in SSL_locking_callback(int, int, char const*, int) () #4 0x00000031d2ae7f03 in ?? () from /usr/lib64/libcrypto.so.10 #5 0x00000031d2ae7d8c in ?? () from /usr/lib64/libcrypto.so.10 #6 0x00000031d2ae80ab in ERR_get_state () from /usr/lib64/libcrypto.so.10 #7 0x00000031d2ae8557 in ?? () from /usr/lib64/libcrypto.so.10 #8 0x00000031d2e424a9 in SSL_get_error () from /usr/lib64/libssl.so.10 #9 0x00000000007249ef in SSLNetVConnection::load_buffer_and_write(long, long&, long&, MIOBufferAccessor&, int&) () #10 0x00000000007389df in write_to_net_io(NetHandler*, UnixNetVConnection*, EThread*) () #11 0x0000000000738523 in write_to_net(NetHandler*, UnixNetVConnection*, EThread*) () #12 0x0000000000731922 in NetHandler::mainNetEvent(int, Event*) () #13 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () #14 0x000000000075877a in EThread::process_event(Event*, int) () #15 0x0000000000758c84 in EThread::ex Thread 56 (Thread 0x7f1fb0ecd700 (LWP 1172)): #0 0x00007f1fbaae77d9 in pthread_mutex_unlock () from /lib64/libpthread.so.0 #1 0x0000000000728265 in SSL_locking_callback(int, int, char const*, int) () #2 0x00000031d2b57402 in ?? () from /usr/lib64/libcrypto.so.10 #3 0x00000031d2b574bd in FIPS_selftest_failed () from /usr/lib64/libcrypto.so.10 #4 0x00000031d2ae9f1c in EVP_DigestInit_ex () from /usr/lib64/libcrypto.so.10 #5 0x00000031d2a7977e in HMAC_Init_ex () from /usr/lib64/libcrypto.so.10 #6 0x00000031d2a79c29 in ?? () from /usr/lib64/libcrypto.so.10 #7 0x00000031d2af7a42 in EVP_PKEY_CTX_ctrl () from /usr/lib64/libcrypto.so.10 #8 0x00000031d2ae9ffb in EVP_DigestInit_ex () from /usr/lib64/libcrypto.so.10 #9 0x00000031d2af952a in ?? () from /usr/lib64/libcrypto.so.10 #10 0x00000031d2e34cf2 in tls1_PRF () from /usr/lib64/libssl.so.10 #11 0x00000031d2e35796 in tls1_final_finish_mac () from /usr/lib64/libssl.so.10 #12 0x00000031d2e2db2e in ssl3_get_message () from /usr/lib64/libssl.so.10 #13 0x00000031d2e1dc3c in ssl3_get_cert_verify () from /usr/lib64/libssl.so.10 #14 0x00000031d2e220d6 in ssl3_accept () from /usr/lib64/libssl.so.10 #15 0x0000000000725287 in SSLNetVConnection::sslServerHandShakeEvent(int&) () #16 0x00000000007251b3 in SSLNetVConnection::sslStartHandShake(int, int&) () #17 0x0000000000723df3 in SSLNetVConnection::net_read_io(NetHandler*, EThread*) () #18 0x0000000000731852 in NetHandler::mainNetEvent(int, Event*) () #19 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () #20 0x000000000075877a in EThread::process_event(Event*, int) () #21 0x0000000000758c84 in EThread::execute() () #22 0x0000000000757cf8 in spawn_thread_internal(void*) () #23 0x00007f1fbaae49d1 in start_thread () from /lib64/libpthread.so.0 #24 0x00000030ff0e88fd in clone () from /lib64/libc.so.6 -Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From foleyj at cisco.com Thu Apr 23 23:46:23 2015 From: foleyj at cisco.com (John Foley) Date: Thu, 23 Apr 2015 19:46:23 -0400 Subject: [openssl-users] Performance problems with OpenSSL and threading In-Reply-To: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org> References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org> Message-ID: <5539844F.4090107@cisco.com> Looking at your call stack, it appears you're testing with FIPS mode enabled. There's a lock in FIPS_selftest_failed() that's used to ensure the crypto algorithms inside the FIPS boundary are not utilized until after the POST has completed and passed. Unfortunately this lock remains installed for the lifetime of the process. We've seen thread contention in this area when using OpenSSL. One work-around is to modify your handler that you pass to SSL_locking_callback() to not lock when the lock ID is CRYPTO_LOCK_FIPS. But you would only want to disable this particular lock ID after the POST has completed. If the above doesn't help, another item to check is whether you're instantiating an SSL_CTX for each thread. I've seen some developers use a single SSL_CTX for multiple threads. This results in a single instance of the server cert and private key being shared across all the threads. This results in thread contention on the asymmetric key operations associated with the cert and private key (e.g. RSA). Be sure that each thread instantiates it's own SSL_CTX and certificate/private key. Lastly, add some debugs to count the locks by lock ID in your lock handler. There are about 40 different lock IDs defined in crypto/crypto.h. You'll need to identify which lock is causing the thread contention. Once you know that, then you can look in the code to see where that lock is used and troubleshoot from there. On 04/23/2015 07:23 PM, Bryan Call wrote: > I was running a benchmark on a 28 core (56 hyper-threaded) server that > is running 84 threads in the process and I am seeing a lot of lock > contention. I saw a lot of lock contention in the calls to > SSL_get_error() ssl3_accept(). I am running RHEL 6.5 > and openssl-1.0.1e-30.el6_6.7.x86_64. We have > used SSL_locking_callback() to setup pthread mutex locks, but haven?t > setup dynlocks yet. Would dynlocks help in this scenario? > > > Output from perf: > Samples: 1M of event 'cycles', Event count (approx.): 602783506611 > - 48.04% [ET_NET 0] [kernel.kallsyms] [k] _spin_lock ? > - _spin_lock ? > > * + 48.05% futex_wait_setup ? > * + 47.79% futex_wake ? > * + 1.20% tcp_v4_rcv ? > * + 0.98% task_rq_lock ? > * + 0.64% double_lock_balance ? > > + 3.94% [ET_NET 0] libcrypto.so.1.0.1e [.] bn_mul_mont ? > + 1.93% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_usub ? > + 1.80% [ET_NET 0] libcrypto.so.1.0.1e [.] 0x00000000000e5200 ? > + 1.49% [ET_NET 0] libcrypto.so.1.0.1e [.] sha256_block_data_order ? > + 0.97% [ET_NET 0] libcrypto.so.1.0.1e [.] gcm_ghash_clmul ? > + 0.85% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_lock ? > + 0.84% [ET_NET 0] libcrypto.so.1.0.1e [.] aesni_ctr32_encrypt_blocks ? > + 0.74% [ET_NET 0] libc-2.12.so [.] malloc ? > + 0.72% [ET_NET 0] libc-2.12.so [.] memcpy ? > + 0.57% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_mod_mul_montgomery ? > + 0.51% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_unlock > > pstack of the process (only a couple of the interesting threads): > Thread 1 (Thread 0x7f1fba151800 (LWP 1106)): > #0 0x00007f1fbaaeb264 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x00007f1fbaae6508 in _L_lock_854 () from /lib64/libpthread.so.0 > #2 0x00007f1fbaae63d7 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x000000000072822f in SSL_locking_callback(int, int, char const*, > int) () > #4 0x00000031d2ae7f03 in ?? () from /usr/lib64/libcrypto.so.10 > #5 0x00000031d2ae7d8c in ?? () from /usr/lib64/libcrypto.so.10 > #6 0x00000031d2ae80ab in ERR_get_state () from /usr/lib64/libcrypto.so.10 > #7 0x00000031d2ae8557 in ?? () from /usr/lib64/libcrypto.so.10 > #8 0x00000031d2e424a9 in SSL_get_error () from /usr/lib64/libssl.so.10 > #9 0x00000000007249ef in > SSLNetVConnection::load_buffer_and_write(long, long&, long&, > MIOBufferAccessor&, int&) () > #10 0x00000000007389df in write_to_net_io(NetHandler*, > UnixNetVConnection*, EThread*) () > #11 0x0000000000738523 in write_to_net(NetHandler*, > UnixNetVConnection*, EThread*) () > #12 0x0000000000731922 in NetHandler::mainNetEvent(int, Event*) () > #13 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () > #14 0x000000000075877a in EThread::process_event(Event*, int) () > #15 0x0000000000758c84 in EThread::ex > > Thread 56 (Thread 0x7f1fb0ecd700 (LWP 1172)): > #0 0x00007f1fbaae77d9 in pthread_mutex_unlock () from > /lib64/libpthread.so.0 > #1 0x0000000000728265 in SSL_locking_callback(int, int, char const*, > int) () > #2 0x00000031d2b57402 in ?? () from /usr/lib64/libcrypto.so.10 > #3 0x00000031d2b574bd in FIPS_selftest_failed () from > /usr/lib64/libcrypto.so.10 > #4 0x00000031d2ae9f1c in EVP_DigestInit_ex () from > /usr/lib64/libcrypto.so.10 > #5 0x00000031d2a7977e in HMAC_Init_ex () from /usr/lib64/libcrypto.so.10 > #6 0x00000031d2a79c29 in ?? () from /usr/lib64/libcrypto.so.10 > #7 0x00000031d2af7a42 in EVP_PKEY_CTX_ctrl () from > /usr/lib64/libcrypto.so.10 > #8 0x00000031d2ae9ffb in EVP_DigestInit_ex () from > /usr/lib64/libcrypto.so.10 > #9 0x00000031d2af952a in ?? () from /usr/lib64/libcrypto.so.10 > #10 0x00000031d2e34cf2 in tls1_PRF () from /usr/lib64/libssl.so.10 > #11 0x00000031d2e35796 in tls1_final_finish_mac () from > /usr/lib64/libssl.so.10 > #12 0x00000031d2e2db2e in ssl3_get_message () from /usr/lib64/libssl.so.10 > #13 0x00000031d2e1dc3c in ssl3_get_cert_verify () from > /usr/lib64/libssl.so.10 > #14 0x00000031d2e220d6 in ssl3_accept () from /usr/lib64/libssl.so.10 > #15 0x0000000000725287 in > SSLNetVConnection::sslServerHandShakeEvent(int&) () > #16 0x00000000007251b3 in SSLNetVConnection::sslStartHandShake(int, > int&) () > #17 0x0000000000723df3 in SSLNetVConnection::net_read_io(NetHandler*, > EThread*) () > #18 0x0000000000731852 in NetHandler::mainNetEvent(int, Event*) () > #19 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () > #20 0x000000000075877a in EThread::process_event(Event*, int) () > #21 0x0000000000758c84 in EThread::execute() () > #22 0x0000000000757cf8 in spawn_thread_internal(void*) () > #23 0x00007f1fbaae49d1 in start_thread () from /lib64/libpthread.so.0 > #24 0x00000030ff0e88fd in clone () from /lib64/libc.so.6 > > -Bryan > > > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From raji.kotamraju at gmail.com Fri Apr 24 14:25:27 2015 From: raji.kotamraju at gmail.com (Rajeswari K) Date: Fri, 24 Apr 2015 19:55:27 +0530 Subject: [openssl-users] ECDSA digest configurations Message-ID: Hello openssl-users, I have an issue with update of ECDSA digests in our environment. We have our own digest functions for init, update and final where we registered with these functions for NID_sha1, NID_sha256, NID_sha384 and NID_sha512. These digests were updated at openssl, via ENGINE_set_digests() function. After update, i see that all RSA cerificate based ciphers are working fine with both TLS1.0 and TLS1.2. And, i added the ECDSA algorithm with openssl function EVP_add_digest(EVP_ecdsa()); But, for me ECDSA cert based cipher suites are not working. These are landing to following errors. digital envelope routines:EVP_SignFinal:wrong public key type : crypto/evp/p_sign .c:139: SSL routines:SSL3_SEND_SERVER_KEY_EXCHANGE:EVP lib: ssl/s3_srvr.c:2012 Then i tried following Tried to set only NID_ecdsa_with_SHA1 with our init, update and final function and tried to update to openssl via ENGINE_set_digests(). But, now seems to be since i updated NID_ecdsa_with_SHA1 with our sha1 functions, whole TLS1.0 handshakes stopped working with "decrypt error or bac mac record" errors. Based on this, seems to be there is a basic thing am missing while configuring ECDSA based digests. Can you please help me on this configuration? How can we differentiate between ECDSA digests to RSA digests? Because both usually lands on to same SHA1, SHA256 etc functions. I tried one more thing that, along with NID_sha1, NID_sha256, NID_sha384, NID_sha512 i tried to define NID_ecdsa_with_SHA1, NID_ecdsa_with_SHA256, NID_ecdsa_with_SHA384 and NID_ecdsa_with_SHA512 with respective settings. But, with this setting also landing to same above error of "wrong public key type". I need your inputs on this issue. Thanks, Rajeswari. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonetsu at teksavvy.com Fri Apr 24 14:13:51 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 24 Apr 2015 07:13:51 -0700 (MST) Subject: [openssl-users] FIPS: SSL 3.0 now forbidden in latest NDCPP update Message-ID: <1429884831419-57695.post@n7.nabble.com> Hi, ... Along with TLS 1.0 (which is absent from OpenSSL FIPS mode) https://www.niap-ccevs.org/pp/pp.cfm?id=CPP_ND_V1.0 Specifically: "FCS_TLSS_EXT.1.2 The TSF shall deny connections from clients requesting SSL 1.0, SSL 2.0, SSL 3.0, TLS 1.0" "FCS_TLSS_EXT.2.2 The TSF shall deny connections from clients requesting SSL 1.0, SSL 2.0, SSL 3.0, TLS 1.0" In this case, would it be possible to simply compile OpenSSL without support for SSL 3.0, while having FIPS mode taking care of the rest ? I do not remeber the exact option now, although I'm almost sure there's a compile option to exclude SSL 3.0. Am I right and would that work ? Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/FIPS-SSL-3-0-now-forbidden-in-latest-NDCPP-update-tp57695.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From Newcomer83 at web.de Fri Apr 24 14:43:05 2015 From: Newcomer83 at web.de (Newcomer83 at web.de) Date: Fri, 24 Apr 2015 16:43:05 +0200 Subject: [openssl-users] How do I uninitialize OpenSSL properly? Message-ID: Hello everyone, I am using OpenSSL sockets and I have the problem I described in the following thread, i.e. a bunch of memory-leaks that happen most likely because I don't uninitialize OpenSSL properly. I believe this to be the cause, because the errors appeared exactly at the moment when I switched from dynamic to static linking of libeay32 and ssleay32: http://stackoverflow.com/questions/29845527/how-to-properly-uninitialize-openssl I admit I am still a beginner, but please help me anyway. :-) I swear I have been googling and fumbling around with OpenSSL quite a bit by myself so far. Cheers Alex From cppcoder411 at gmail.com Fri Apr 24 15:10:47 2015 From: cppcoder411 at gmail.com (John Vollaro) Date: Fri, 24 Apr 2015 11:10:47 -0400 Subject: [openssl-users] =?utf-8?q?Web_Services_Security=3A_SOAP_Message_S?= =?utf-8?q?ecurity_1=2E0_=28WS-Security_2004=29=E2=80=9D_Signature_?= =?utf-8?q?Value?= Message-ID: What OpenSSL command is required to generate a proper ?Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)? Signature Value I have the following guidelines in generating the SignatureValue CERTIFICATE I have a self signed .p12 and/or .pem Certificate file to use in the encryption. I have the string that needs to be encrypted as the SignatureValue. I suspect that since the Value type is X509v3 that this is a clue on how to generate the Signature. I am trying to build a Web Service client within a C++ application which uses OpenSSL for encryption and gSOAP to implement the SOAP protocol. Any help would be appreciated. Thanks John Gerard -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Apr 24 15:55:18 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 24 Apr 2015 15:55:18 +0000 Subject: [openssl-users] =?utf-8?q?Web_Services_Security=3A_SOAP_Message_S?= =?utf-8?q?ecurity_1=2E0_=28WS-Security_2004=29=E2=80=9D_Signature_Value?= In-Reply-To: References: Message-ID: WS-Security? Blast from the past ? ? To fill in the BinarySecurityToken field, take the PEM version of the cert, strip off the leading and trailing marker lines ---BEGIN? and output that. To generate the signature look at the pkeyutl app. (Sorry, don?t remember any other details) -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Apr 24 16:15:45 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 24 Apr 2015 16:15:45 +0000 Subject: [openssl-users] Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)? Signature Value In-Reply-To: References: Message-ID: <20150424161545.GJ25758@mournblade.imrryr.org> On Fri, Apr 24, 2015 at 03:55:18PM +0000, Salz, Rich wrote: > To generate the signature look at the pkeyutl app. (Sorry, don?t > remember any other details) Typically, signatures are created with: openssl dgst -sha256 -sign key.pem ... See the dgst(1) manpage. -- Viktor. From steve at openssl.org Fri Apr 24 17:27:00 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 24 Apr 2015 17:27:00 +0000 Subject: [openssl-users] FIPS: SSL 3.0 now forbidden in latest NDCPP update In-Reply-To: <1429884831419-57695.post@n7.nabble.com> References: <1429884831419-57695.post@n7.nabble.com> Message-ID: <20150424172700.GA5240@openssl.org> On Fri, Apr 24, 2015, jonetsu wrote: > > ... Along with TLS 1.0 (which is absent from OpenSSL FIPS mode) > > https://www.niap-ccevs.org/pp/pp.cfm?id=CPP_ND_V1.0 > > Specifically: > > "FCS_TLSS_EXT.1.2 The TSF shall deny connections from clients requesting SSL > 1.0, SSL > 2.0, SSL 3.0, TLS 1.0" > > "FCS_TLSS_EXT.2.2 The TSF shall deny connections from clients requesting SSL > 1.0, SSL > 2.0, SSL 3.0, TLS 1.0" > > In this case, would it be possible to simply compile OpenSSL without support > for SSL 3.0, while having FIPS mode taking care of the rest ? I do not > remeber the exact option now, although I'm almost sure there's a compile > option to exclude SSL 3.0. Am I right and would that work ? > In FIPS mode SSL 3.0 is not allowed: that has always been the case. TLS 1.0 is currently permitted though. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Fri Apr 24 17:36:01 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 24 Apr 2015 17:36:01 +0000 Subject: [openssl-users] ECDSA digest configurations In-Reply-To: References: Message-ID: <20150424173601.GB5240@openssl.org> On Fri, Apr 24, 2015, Rajeswari K wrote: > Hello openssl-users, > > I have an issue with update of ECDSA digests in our environment. > > We have our own digest functions for init, update and final where we > registered with these functions for NID_sha1, NID_sha256, NID_sha384 and > NID_sha512. These digests were updated at openssl, via ENGINE_set_digests() > function. > > After update, i see that all RSA cerificate based ciphers are working fine > with both TLS1.0 and TLS1.2. > > And, i added the ECDSA algorithm with openssl function > EVP_add_digest(EVP_ecdsa()); > > But, for me ECDSA cert based cipher suites are not working. These are > landing to following errors. > > digital envelope routines:EVP_SignFinal:wrong public key type : > crypto/evp/p_sign .c:139: > > SSL routines:SSL3_SEND_SERVER_KEY_EXCHANGE:EVP lib: ssl/s3_srvr.c:2012 > > > Then i tried following > Tried to set only NID_ecdsa_with_SHA1 with our init, update and final > function and tried to update to openssl via ENGINE_set_digests(). > > But, now seems to be since i updated NID_ecdsa_with_SHA1 with our sha1 > functions, whole TLS1.0 handshakes stopped working with "decrypt error or > bac mac record" errors. > > Based on this, seems to be there is a basic thing am missing while > configuring ECDSA based digests. > > Can you please help me on this configuration? How can we differentiate > between ECDSA digests to RSA digests? > > Because both usually lands on to same SHA1, SHA256 etc functions. > > I tried one more thing that, along with NID_sha1, NID_sha256, NID_sha384, > NID_sha512 i tried to define NID_ecdsa_with_SHA1, NID_ecdsa_with_SHA256, > NID_ecdsa_with_SHA384 and NID_ecdsa_with_SHA512 with respective settings. > But, with this setting also landing to same above error of "wrong public > key type". > > I need your inputs on this issue. > So does your code just perform the digest operation and not signing? Which version was it working with before? There isn't really any difference between an ECDSA and RSA digest. Older versions of OpenSSL linked digests and signing algorithms. That link no longer exists and some algorithms are marked as being suitable for multiple public key algorithms. Are you setting the flag EVP_MD_FLAG_PKEY_METHOD_SIGNATURE in the EVP_MD structure? An ENGINE providing alternative implementations of built in digests shoudn't need to call EVP_add_digest. If everything is set up properly OpenSSL should just switch to the ENGINE implementation. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From bcall at apache.org Fri Apr 24 17:36:54 2015 From: bcall at apache.org (Bryan Call) Date: Fri, 24 Apr 2015 10:36:54 -0700 Subject: [openssl-users] Performance problems with OpenSSL and threading In-Reply-To: <5539844F.4090107@cisco.com> References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org> <5539844F.4090107@cisco.com> Message-ID: <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> We are using a single SSL_CTX across all the threads, so I will create multiple SSL_CTX per thread. I implemented dynlock callbacks yesterday, but I didn?t see them being used in the tests I did. I also added atomic counters to see what type of locks are having contention (see logs below): Most of the lock contention seems to be around type 2 and type 1 locks when calling our lock callback. In the FIPS/POST and SSL_CTX recommendations, in your previous email, what types of locks would those help with? Log output: [Apr 24 10:21:24.339] Server {0xb310000} ERROR: :178 (SSL_locking_callback)> contention for lock - total contention: 3938 waiting: 1 file: /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/ex_data.c line: 496 type: 2 [Apr 24 10:21:24.754] Server {0xb10a000} ERROR: :178 (SSL_locking_callback)> contention for lock - total contention: 1350 waiting: 1 file: /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/err/err_def.c line: 343 type: 1 -Bryan > On Apr 23, 2015, at 4:46 PM, John Foley > wrote: > > Looking at your call stack, it appears you're testing with FIPS mode enabled. There's a lock in FIPS_selftest_failed() that's used to ensure the crypto algorithms inside the FIPS boundary are not utilized until after the POST has completed and passed. Unfortunately this lock remains installed for the lifetime of the process. We've seen thread contention in this area when using OpenSSL. One work-around is to modify your handler that you pass to SSL_locking_callback() to not lock when the lock ID is CRYPTO_LOCK_FIPS. But you would only want to disable this particular lock ID after the POST has completed. > > If the above doesn't help, another item to check is whether you're instantiating an SSL_CTX for each thread. I've seen some developers use a single SSL_CTX for multiple threads. This results in a single instance of the server cert and private key being shared across all the threads. This results in thread contention on the asymmetric key operations associated with the cert and private key (e.g. RSA). Be sure that each thread instantiates it's own SSL_CTX and certificate/private key. > > Lastly, add some debugs to count the locks by lock ID in your lock handler. There are about 40 different lock IDs defined in crypto/crypto.h. You'll need to identify which lock is causing the thread contention. Once you know that, then you can look in the code to see where that lock is used and troubleshoot from there. > > > > On 04/23/2015 07:23 PM, Bryan Call wrote: >> I was running a benchmark on a 28 core (56 hyper-threaded) server that is running 84 threads in the process and I am seeing a lot of lock contention. I saw a lot of lock contention in the calls to SSL_get_error() ssl3_accept(). I am running RHEL 6.5 and openssl-1.0.1e-30.el6_6.7.x86_64. We have used SSL_locking_callback() to setup pthread mutex locks, but haven?t setup dynlocks yet. Would dynlocks help in this scenario? >> >> >> Output from perf: >> Samples: 1M of event 'cycles', Event count (approx.): 602783506611 >> - 48.04% [ET_NET 0] [kernel.kallsyms] [k] _spin_lock ? >> - _spin_lock ? >> + 48.05% futex_wait_setup ? >> + 47.79% futex_wake ? >> + 1.20% tcp_v4_rcv ? >> + 0.98% task_rq_lock ? >> + 0.64% double_lock_balance ? >> + 3.94% [ET_NET 0] libcrypto.so.1.0.1e [.] bn_mul_mont ? >> + 1.93% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_usub ? >> + 1.80% [ET_NET 0] libcrypto.so.1.0.1e [.] 0x00000000000e5200 ? >> + 1.49% [ET_NET 0] libcrypto.so.1.0.1e [.] sha256_block_data_order ? >> + 0.97% [ET_NET 0] libcrypto.so.1.0.1e [.] gcm_ghash_clmul ? >> + 0.85% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_lock ? >> + 0.84% [ET_NET 0] libcrypto.so.1.0.1e [.] aesni_ctr32_encrypt_blocks ? >> + 0.74% [ET_NET 0] libc-2.12.so [.] malloc ? >> + 0.72% [ET_NET 0] libc-2.12.so [.] memcpy ? >> + 0.57% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_mod_mul_montgomery ? >> + 0.51% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_unlock >> >> pstack of the process (only a couple of the interesting threads): >> Thread 1 (Thread 0x7f1fba151800 (LWP 1106)): >> #0 0x00007f1fbaaeb264 in __lll_lock_wait () from /lib64/libpthread.so.0 >> #1 0x00007f1fbaae6508 in _L_lock_854 () from /lib64/libpthread.so.0 >> #2 0x00007f1fbaae63d7 in pthread_mutex_lock () from /lib64/libpthread.so.0 >> #3 0x000000000072822f in SSL_locking_callback(int, int, char const*, int) () >> #4 0x00000031d2ae7f03 in ?? () from /usr/lib64/libcrypto.so.10 >> #5 0x00000031d2ae7d8c in ?? () from /usr/lib64/libcrypto.so.10 >> #6 0x00000031d2ae80ab in ERR_get_state () from /usr/lib64/libcrypto.so.10 >> #7 0x00000031d2ae8557 in ?? () from /usr/lib64/libcrypto.so.10 >> #8 0x00000031d2e424a9 in SSL_get_error () from /usr/lib64/libssl.so.10 >> #9 0x00000000007249ef in SSLNetVConnection::load_buffer_and_write(long, long&, long&, MIOBufferAccessor&, int&) () >> #10 0x00000000007389df in write_to_net_io(NetHandler*, UnixNetVConnection*, EThread*) () >> #11 0x0000000000738523 in write_to_net(NetHandler*, UnixNetVConnection*, EThread*) () >> #12 0x0000000000731922 in NetHandler::mainNetEvent(int, Event*) () >> #13 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >> #14 0x000000000075877a in EThread::process_event(Event*, int) () >> #15 0x0000000000758c84 in EThread::ex >> >> Thread 56 (Thread 0x7f1fb0ecd700 (LWP 1172)): >> #0 0x00007f1fbaae77d9 in pthread_mutex_unlock () from /lib64/libpthread.so.0 >> #1 0x0000000000728265 in SSL_locking_callback(int, int, char const*, int) () >> #2 0x00000031d2b57402 in ?? () from /usr/lib64/libcrypto.so.10 >> #3 0x00000031d2b574bd in FIPS_selftest_failed () from /usr/lib64/libcrypto.so.10 >> #4 0x00000031d2ae9f1c in EVP_DigestInit_ex () from /usr/lib64/libcrypto.so.10 >> #5 0x00000031d2a7977e in HMAC_Init_ex () from /usr/lib64/libcrypto.so.10 >> #6 0x00000031d2a79c29 in ?? () from /usr/lib64/libcrypto.so.10 >> #7 0x00000031d2af7a42 in EVP_PKEY_CTX_ctrl () from /usr/lib64/libcrypto.so.10 >> #8 0x00000031d2ae9ffb in EVP_DigestInit_ex () from /usr/lib64/libcrypto.so.10 >> #9 0x00000031d2af952a in ?? () from /usr/lib64/libcrypto.so.10 >> #10 0x00000031d2e34cf2 in tls1_PRF () from /usr/lib64/libssl.so.10 >> #11 0x00000031d2e35796 in tls1_final_finish_mac () from /usr/lib64/libssl.so.10 >> #12 0x00000031d2e2db2e in ssl3_get_message () from /usr/lib64/libssl.so.10 >> #13 0x00000031d2e1dc3c in ssl3_get_cert_verify () from /usr/lib64/libssl.so.10 >> #14 0x00000031d2e220d6 in ssl3_accept () from /usr/lib64/libssl.so.10 >> #15 0x0000000000725287 in SSLNetVConnection::sslServerHandShakeEvent(int&) () >> #16 0x00000000007251b3 in SSLNetVConnection::sslStartHandShake(int, int&) () >> #17 0x0000000000723df3 in SSLNetVConnection::net_read_io(NetHandler*, EThread*) () >> #18 0x0000000000731852 in NetHandler::mainNetEvent(int, Event*) () >> #19 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >> #20 0x000000000075877a in EThread::process_event(Event*, int) () >> #21 0x0000000000758c84 in EThread::execute() () >> #22 0x0000000000757cf8 in spawn_thread_internal(void*) () >> #23 0x00007f1fbaae49d1 in start_thread () from /lib64/libpthread.so.0 >> #24 0x00000030ff0e88fd in clone () from /lib64/libc.so.6 >> >> -Bryan >> >> >> >> >> >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From foleyj at cisco.com Fri Apr 24 17:56:34 2015 From: foleyj at cisco.com (John Foley) Date: Fri, 24 Apr 2015 13:56:34 -0400 Subject: [openssl-users] Performance problems with OpenSSL and threading In-Reply-To: <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org> <5539844F.4090107@cisco.com> <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> Message-ID: <553A83D2.80206@cisco.com> When you create the private key given to SSL_CTX, be sure to instantiate a private key for each thread as well. If you share the same key across all threads, this can introduce contention. Here are the type 1 & 2 locks: # define CRYPTO_LOCK_ERR 1 # define CRYPTO_LOCK_EX_DATA 2 Have you checked the OpenSSL error log to see what errors are being generated? Also, if you disable FIPS, does the thread contention still occur? On 04/24/2015 01:36 PM, Bryan Call wrote: > We are using a single SSL_CTX across all the threads, so I will create > multiple SSL_CTX per thread. I implemented dynlock callbacks > yesterday, but I didn?t see them being used in the tests I did. I > also added atomic counters to see what type of locks are having > contention (see logs below): > > Most of the lock contention seems to be around type 2 and type 1 locks > when calling our lock callback. In the FIPS/POST and SSL_CTX > recommendations, in your previous email, what types of locks would > those help with? > > Log output: > [Apr 24 10:21:24.339] Server {0xb310000} ERROR: :178 (SSL_locking_callback)> contention for lock - > total contention: 3938 waiting: 1 file: > /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/ex_data.c line: > 496 type: 2 > [Apr 24 10:21:24.754] Server {0xb10a000} ERROR: :178 (SSL_locking_callback)> contention for lock - > total contention: 1350 waiting: 1 file: > /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/err/err_def.c > line: 343 type: 1 > > > -Bryan > > > > >> On Apr 23, 2015, at 4:46 PM, John Foley > > wrote: >> >> Looking at your call stack, it appears you're testing with FIPS mode >> enabled. There's a lock in FIPS_selftest_failed() that's used to >> ensure the crypto algorithms inside the FIPS boundary are not >> utilized until after the POST has completed and passed. Unfortunately >> this lock remains installed for the lifetime of the process. We've >> seen thread contention in this area when using OpenSSL. One >> work-around is to modify your handler that you pass to >> SSL_locking_callback() to not lock when the lock ID is >> CRYPTO_LOCK_FIPS. But you would only want to disable this particular >> lock ID after the POST has completed. >> >> If the above doesn't help, another item to check is whether you're >> instantiating an SSL_CTX for each thread. I've seen some developers >> use a single SSL_CTX for multiple threads. This results in a single >> instance of the server cert and private key being shared across all >> the threads. This results in thread contention on the asymmetric key >> operations associated with the cert and private key (e.g. RSA). Be >> sure that each thread instantiates it's own SSL_CTX and >> certificate/private key. >> >> Lastly, add some debugs to count the locks by lock ID in your lock >> handler. There are about 40 different lock IDs defined in >> crypto/crypto.h. You'll need to identify which lock is causing the >> thread contention. Once you know that, then you can look in the code >> to see where that lock is used and troubleshoot from there. >> >> >> >> On 04/23/2015 07:23 PM, Bryan Call wrote: >>> I was running a benchmark on a 28 core (56 hyper-threaded) server >>> that is running 84 threads in the process and I am seeing a lot of >>> lock contention. I saw a lot of lock contention in the calls to >>> SSL_get_error() ssl3_accept(). I am running RHEL 6.5 >>> and openssl-1.0.1e-30.el6_6.7.x86_64. We have >>> used SSL_locking_callback() to setup pthread mutex locks, but >>> haven?t setup dynlocks yet. Would dynlocks help in this scenario? >>> >>> >>> Output from perf: >>> Samples: 1M of event 'cycles', Event count (approx.): 602783506611 >>> - 48.04% [ET_NET 0] [kernel.kallsyms] [k] _spin_lock ? >>> - _spin_lock ? >>> >>> * + 48.05% futex_wait_setup ? >>> * + 47.79% futex_wake ? >>> * + 1.20% tcp_v4_rcv ? >>> * + 0.98% task_rq_lock ? >>> * + 0.64% double_lock_balance ? >>> >>> + 3.94% [ET_NET 0] libcrypto.so.1.0.1e [.] bn_mul_mont ? >>> + 1.93% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_usub ? >>> + 1.80% [ET_NET 0] libcrypto.so.1.0.1e [.] 0x00000000000e5200 ? >>> + 1.49% [ET_NET 0] libcrypto.so.1.0.1e [.] sha256_block_data_order ? >>> + 0.97% [ET_NET 0] libcrypto.so.1.0.1e [.] gcm_ghash_clmul ? >>> + 0.85% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_lock ? >>> + 0.84% [ET_NET 0] libcrypto.so.1.0.1e [.] aesni_ctr32_encrypt_blocks ? >>> + 0.74% [ET_NET 0] libc-2.12.so [.] malloc ? >>> + 0.72% [ET_NET 0] libc-2.12.so [.] memcpy ? >>> + 0.57% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_mod_mul_montgomery ? >>> + 0.51% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_unlock >>> >>> pstack of the process (only a couple of the interesting threads): >>> Thread 1 (Thread 0x7f1fba151800 (LWP 1106)): >>> #0 0x00007f1fbaaeb264 in __lll_lock_wait () from /lib64/libpthread.so.0 >>> #1 0x00007f1fbaae6508 in _L_lock_854 () from /lib64/libpthread.so.0 >>> #2 0x00007f1fbaae63d7 in pthread_mutex_lock () from >>> /lib64/libpthread.so.0 >>> #3 0x000000000072822f in SSL_locking_callback(int, int, char const*, >>> int) () >>> #4 0x00000031d2ae7f03 in ?? () from /usr/lib64/libcrypto.so.10 >>> #5 0x00000031d2ae7d8c in ?? () from /usr/lib64/libcrypto.so.10 >>> #6 0x00000031d2ae80ab in ERR_get_state () from >>> /usr/lib64/libcrypto.so.10 >>> #7 0x00000031d2ae8557 in ?? () from /usr/lib64/libcrypto.so.10 >>> #8 0x00000031d2e424a9 in SSL_get_error () from /usr/lib64/libssl.so.10 >>> #9 0x00000000007249ef in >>> SSLNetVConnection::load_buffer_and_write(long, long&, long&, >>> MIOBufferAccessor&, int&) () >>> #10 0x00000000007389df in write_to_net_io(NetHandler*, >>> UnixNetVConnection*, EThread*) () >>> #11 0x0000000000738523 in write_to_net(NetHandler*, >>> UnixNetVConnection*, EThread*) () >>> #12 0x0000000000731922 in NetHandler::mainNetEvent(int, Event*) () >>> #13 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >>> #14 0x000000000075877a in EThread::process_event(Event*, int) () >>> #15 0x0000000000758c84 in EThread::ex >>> >>> Thread 56 (Thread 0x7f1fb0ecd700 (LWP 1172)): >>> #0 0x00007f1fbaae77d9 in pthread_mutex_unlock () from >>> /lib64/libpthread.so.0 >>> #1 0x0000000000728265 in SSL_locking_callback(int, int, char const*, >>> int) () >>> #2 0x00000031d2b57402 in ?? () from /usr/lib64/libcrypto.so.10 >>> #3 0x00000031d2b574bd in FIPS_selftest_failed () from >>> /usr/lib64/libcrypto.so.10 >>> #4 0x00000031d2ae9f1c in EVP_DigestInit_ex () from >>> /usr/lib64/libcrypto.so.10 >>> #5 0x00000031d2a7977e in HMAC_Init_ex () from /usr/lib64/libcrypto.so.10 >>> #6 0x00000031d2a79c29 in ?? () from /usr/lib64/libcrypto.so.10 >>> #7 0x00000031d2af7a42 in EVP_PKEY_CTX_ctrl () from >>> /usr/lib64/libcrypto.so.10 >>> #8 0x00000031d2ae9ffb in EVP_DigestInit_ex () from >>> /usr/lib64/libcrypto.so.10 >>> #9 0x00000031d2af952a in ?? () from /usr/lib64/libcrypto.so.10 >>> #10 0x00000031d2e34cf2 in tls1_PRF () from /usr/lib64/libssl.so.10 >>> #11 0x00000031d2e35796 in tls1_final_finish_mac () from >>> /usr/lib64/libssl.so.10 >>> #12 0x00000031d2e2db2e in ssl3_get_message () from >>> /usr/lib64/libssl.so.10 >>> #13 0x00000031d2e1dc3c in ssl3_get_cert_verify () from >>> /usr/lib64/libssl.so.10 >>> #14 0x00000031d2e220d6 in ssl3_accept () from /usr/lib64/libssl.so.10 >>> #15 0x0000000000725287 in >>> SSLNetVConnection::sslServerHandShakeEvent(int&) () >>> #16 0x00000000007251b3 in SSLNetVConnection::sslStartHandShake(int, >>> int&) () >>> #17 0x0000000000723df3 in >>> SSLNetVConnection::net_read_io(NetHandler*, EThread*) () >>> #18 0x0000000000731852 in NetHandler::mainNetEvent(int, Event*) () >>> #19 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >>> #20 0x000000000075877a in EThread::process_event(Event*, int) () >>> #21 0x0000000000758c84 in EThread::execute() () >>> #22 0x0000000000757cf8 in spawn_thread_internal(void*) () >>> #23 0x00007f1fbaae49d1 in start_thread () from /lib64/libpthread.so.0 >>> #24 0x00000030ff0e88fd in clone () from /lib64/libc.so.6 >>> >>> -Bryan >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonetsu at teksavvy.com Fri Apr 24 18:29:28 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 24 Apr 2015 11:29:28 -0700 (MST) Subject: [openssl-users] FIPS: SSL 3.0 now forbidden in latest NDCPP update In-Reply-To: <20150424172700.GA5240@openssl.org> References: <1429884831419-57695.post@n7.nabble.com> <20150424172700.GA5240@openssl.org> Message-ID: <1429900168810-57707.post@n7.nabble.com> Hello, > In FIPS mode SSL 3.0 is not allowed: that has always been the > case. % openssl version OpenSSL 1.0.1f 6 Jan 2014 % OPENSSL_FIPS=1 openssl ciphers -v | grep SSL ECDHE-RSA-AES256-SHA SSLv3 ECDHE-ECDSA-AES256-SHA SSLv3 DHE-RSA-AES256-SHA SSLv3 DHE-DSS-AES256-SHA SSLv3 [snipped] All of the others are TLSv1.2. Why is SSLv3.0 seen in FIPS mode on this install ? > TLS 1.0 is currently permitted though. As far as OpenSSL is concerned, will any action to remove TLSv.10 only be taken when put into a FIPS frame, eg. the recent NDCPPv1.0 is not enough ground to make a change ? Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/FIPS-SSL-3-0-now-forbidden-in-latest-NDCPP-update-tp57695p57707.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From bcall at apache.org Fri Apr 24 21:56:16 2015 From: bcall at apache.org (Bryan Call) Date: Fri, 24 Apr 2015 14:56:16 -0700 Subject: [openssl-users] Performance problems with OpenSSL and threading In-Reply-To: <553A83D2.80206@cisco.com> References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org> <5539844F.4090107@cisco.com> <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com> Message-ID: In my last email I ran the benchmark on Fedora 21 (big mistake). Here are the results when running it back on the 28/56 core RHEL 6.5 server showing contention in a different place (fips). Is there a reason it would be calling into the FIPS code to get a lock of FIPS is not enabled? Contention log: [Apr 24 21:35:09.731] Server {0x7f5529ccd700} ERROR: contention for lock - total contention: 70662 waiting: 16 file: fips.c line: 471 type: 40 [Apr 24 21:35:09.732] Server {0x7f55299ca700} ERROR: contention for lock - total contention: 71605 waiting: 2 file: fips.c line: 107 type: 39 Line in in fips that see the contention the most: [bcall at bm77 trafficserver]$ grep fips.c diags.log | cut -f 19 -d ' ' | sort | uniq -c | sort -rn 875379 471 288338 107 275472 127 Different lock types and their contention frequency (multiple benchmarks): 875379 40 < - in fips.c 563810 39 <- also in fips.c 440518 1 44145 18 17447 2 11356 10 1377 19 687 12 532 25 302 33 239 9 58 16 40 21 32 11 19 3 1 14 Code to diable FIPS and log: #ifdef OPENSSL_FIPS int mode = FIPS_mode(); Debug("ssl", "FIPS_mode: %d", mode); mode = FIPS_mode(); if (mode) { FIPS_mode_set(0); Debug("ssl", "FIPS_mode: %d", mode); } #endif [Apr 24 21:43:45.860] Server {0x7f7628146800} DEBUG: (ssl) FIPS_mode: 0 -Bryan > On Apr 24, 2015, at 10:56 AM, John Foley > wrote: > > When you create the private key given to SSL_CTX, be sure to instantiate a private key for each thread as well. If you share the same key across all threads, this can introduce contention. > > Here are the type 1 & 2 locks: > > # define CRYPTO_LOCK_ERR 1 > # define CRYPTO_LOCK_EX_DATA 2 > > Have you checked the OpenSSL error log to see what errors are being generated? > > Also, if you disable FIPS, does the thread contention still occur? > > > > On 04/24/2015 01:36 PM, Bryan Call wrote: >> We are using a single SSL_CTX across all the threads, so I will create multiple SSL_CTX per thread. I implemented dynlock callbacks yesterday, but I didn?t see them being used in the tests I did. I also added atomic counters to see what type of locks are having contention (see logs below): >> >> Most of the lock contention seems to be around type 2 and type 1 locks when calling our lock callback. In the FIPS/POST and SSL_CTX recommendations, in your previous email, what types of locks would those help with? >> >> Log output: >> [Apr 24 10:21:24.339] Server {0xb310000} ERROR: :178 (SSL_locking_callback)> contention for lock - total contention: 3938 waiting: 1 file: /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/ex_data.c line: 496 type: 2 >> [Apr 24 10:21:24.754] Server {0xb10a000} ERROR: :178 (SSL_locking_callback)> contention for lock - total contention: 1350 waiting: 1 file: /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/err/err_def.c line: 343 type: 1 >> >> >> -Bryan >> >> >> >> >>> On Apr 23, 2015, at 4:46 PM, John Foley > wrote: >>> >>> Looking at your call stack, it appears you're testing with FIPS mode enabled. There's a lock in FIPS_selftest_failed() that's used to ensure the crypto algorithms inside the FIPS boundary are not utilized until after the POST has completed and passed. Unfortunately this lock remains installed for the lifetime of the process. We've seen thread contention in this area when using OpenSSL. One work-around is to modify your handler that you pass to SSL_locking_callback() to not lock when the lock ID is CRYPTO_LOCK_FIPS. But you would only want to disable this particular lock ID after the POST has completed. >>> >>> If the above doesn't help, another item to check is whether you're instantiating an SSL_CTX for each thread. I've seen some developers use a single SSL_CTX for multiple threads. This results in a single instance of the server cert and private key being shared across all the threads. This results in thread contention on the asymmetric key operations associated with the cert and private key (e.g. RSA). Be sure that each thread instantiates it's own SSL_CTX and certificate/private key. >>> >>> Lastly, add some debugs to count the locks by lock ID in your lock handler. There are about 40 different lock IDs defined in crypto/crypto.h. You'll need to identify which lock is causing the thread contention. Once you know that, then you can look in the code to see where that lock is used and troubleshoot from there. >>> >>> >>> >>> On 04/23/2015 07:23 PM, Bryan Call wrote: >>>> I was running a benchmark on a 28 core (56 hyper-threaded) server that is running 84 threads in the process and I am seeing a lot of lock contention. I saw a lot of lock contention in the calls to SSL_get_error() ssl3_accept(). I am running RHEL 6.5 and openssl-1.0.1e-30.el6_6.7.x86_64. We have used SSL_locking_callback() to setup pthread mutex locks, but haven?t setup dynlocks yet. Would dynlocks help in this scenario? >>>> >>>> >>>> Output from perf: >>>> Samples: 1M of event 'cycles', Event count (approx.): 602783506611 >>>> - 48.04% [ET_NET 0] [kernel.kallsyms] [k] _spin_lock ? >>>> - _spin_lock ? >>>> + 48.05% futex_wait_setup ? >>>> + 47.79% futex_wake ? >>>> + 1.20% tcp_v4_rcv ? >>>> + 0.98% task_rq_lock ? >>>> + 0.64% double_lock_balance ? >>>> + 3.94% [ET_NET 0] libcrypto.so.1.0.1e [.] bn_mul_mont ? >>>> + 1.93% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_usub ? >>>> + 1.80% [ET_NET 0] libcrypto.so.1.0.1e [.] 0x00000000000e5200 ? >>>> + 1.49% [ET_NET 0] libcrypto.so.1.0.1e [.] sha256_block_data_order ? >>>> + 0.97% [ET_NET 0] libcrypto.so.1.0.1e [.] gcm_ghash_clmul ? >>>> + 0.85% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_lock ? >>>> + 0.84% [ET_NET 0] libcrypto.so.1.0.1e [.] aesni_ctr32_encrypt_blocks ? >>>> + 0.74% [ET_NET 0] libc-2.12.so [.] malloc ? >>>> + 0.72% [ET_NET 0] libc-2.12.so [.] memcpy ? >>>> + 0.57% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_mod_mul_montgomery ? >>>> + 0.51% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_unlock >>>> >>>> pstack of the process (only a couple of the interesting threads): >>>> Thread 1 (Thread 0x7f1fba151800 (LWP 1106)): >>>> #0 0x00007f1fbaaeb264 in __lll_lock_wait () from /lib64/libpthread.so.0 >>>> #1 0x00007f1fbaae6508 in _L_lock_854 () from /lib64/libpthread.so.0 >>>> #2 0x00007f1fbaae63d7 in pthread_mutex_lock () from /lib64/libpthread.so.0 >>>> #3 0x000000000072822f in SSL_locking_callback(int, int, char const*, int) () >>>> #4 0x00000031d2ae7f03 in ?? () from /usr/lib64/libcrypto.so.10 >>>> #5 0x00000031d2ae7d8c in ?? () from /usr/lib64/libcrypto.so.10 >>>> #6 0x00000031d2ae80ab in ERR_get_state () from /usr/lib64/libcrypto.so.10 >>>> #7 0x00000031d2ae8557 in ?? () from /usr/lib64/libcrypto.so.10 >>>> #8 0x00000031d2e424a9 in SSL_get_error () from /usr/lib64/libssl.so.10 >>>> #9 0x00000000007249ef in SSLNetVConnection::load_buffer_and_write(long, long&, long&, MIOBufferAccessor&, int&) () >>>> #10 0x00000000007389df in write_to_net_io(NetHandler*, UnixNetVConnection*, EThread*) () >>>> #11 0x0000000000738523 in write_to_net(NetHandler*, UnixNetVConnection*, EThread*) () >>>> #12 0x0000000000731922 in NetHandler::mainNetEvent(int, Event*) () >>>> #13 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >>>> #14 0x000000000075877a in EThread::process_event(Event*, int) () >>>> #15 0x0000000000758c84 in EThread::ex >>>> >>>> Thread 56 (Thread 0x7f1fb0ecd700 (LWP 1172)): >>>> #0 0x00007f1fbaae77d9 in pthread_mutex_unlock () from /lib64/libpthread.so.0 >>>> #1 0x0000000000728265 in SSL_locking_callback(int, int, char const*, int) () >>>> #2 0x00000031d2b57402 in ?? () from /usr/lib64/libcrypto.so.10 >>>> #3 0x00000031d2b574bd in FIPS_selftest_failed () from /usr/lib64/libcrypto.so.10 >>>> #4 0x00000031d2ae9f1c in EVP_DigestInit_ex () from /usr/lib64/libcrypto.so.10 >>>> #5 0x00000031d2a7977e in HMAC_Init_ex () from /usr/lib64/libcrypto.so.10 >>>> #6 0x00000031d2a79c29 in ?? () from /usr/lib64/libcrypto.so.10 >>>> #7 0x00000031d2af7a42 in EVP_PKEY_CTX_ctrl () from /usr/lib64/libcrypto.so.10 >>>> #8 0x00000031d2ae9ffb in EVP_DigestInit_ex () from /usr/lib64/libcrypto.so.10 >>>> #9 0x00000031d2af952a in ?? () from /usr/lib64/libcrypto.so.10 >>>> #10 0x00000031d2e34cf2 in tls1_PRF () from /usr/lib64/libssl.so.10 >>>> #11 0x00000031d2e35796 in tls1_final_finish_mac () from /usr/lib64/libssl.so.10 >>>> #12 0x00000031d2e2db2e in ssl3_get_message () from /usr/lib64/libssl.so.10 >>>> #13 0x00000031d2e1dc3c in ssl3_get_cert_verify () from /usr/lib64/libssl.so.10 >>>> #14 0x00000031d2e220d6 in ssl3_accept () from /usr/lib64/libssl.so.10 >>>> #15 0x0000000000725287 in SSLNetVConnection::sslServerHandShakeEvent(int&) () >>>> #16 0x00000000007251b3 in SSLNetVConnection::sslStartHandShake(int, int&) () >>>> #17 0x0000000000723df3 in SSLNetVConnection::net_read_io(NetHandler*, EThread*) () >>>> #18 0x0000000000731852 in NetHandler::mainNetEvent(int, Event*) () >>>> #19 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >>>> #20 0x000000000075877a in EThread::process_event(Event*, int) () >>>> #21 0x0000000000758c84 in EThread::execute() () >>>> #22 0x0000000000757cf8 in spawn_thread_internal(void*) () >>>> #23 0x00007f1fbaae49d1 in start_thread () from /lib64/libpthread.so.0 >>>> #24 0x00000030ff0e88fd in clone () from /lib64/libc.so.6 >>>> >>>> -Bryan >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> openssl-users mailing list >>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> >>> _______________________________________________ >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Fri Apr 24 21:56:57 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 24 Apr 2015 21:56:57 +0000 Subject: [openssl-users] FIPS: SSL 3.0 now forbidden in latest NDCPP update In-Reply-To: <1429900168810-57707.post@n7.nabble.com> References: <1429884831419-57695.post@n7.nabble.com> <20150424172700.GA5240@openssl.org> <1429900168810-57707.post@n7.nabble.com> Message-ID: <20150424215657.GA8995@openssl.org> On Fri, Apr 24, 2015, jonetsu wrote: > Hello, > > > In FIPS mode SSL 3.0 is not allowed: that has always been the > > case. > > % openssl version > OpenSSL 1.0.1f 6 Jan 2014 > > % OPENSSL_FIPS=1 openssl ciphers -v | grep SSL > > ECDHE-RSA-AES256-SHA SSLv3 > ECDHE-ECDSA-AES256-SHA SSLv3 > DHE-RSA-AES256-SHA SSLv3 > DHE-DSS-AES256-SHA SSLv3 > [snipped] > > All of the others are TLSv1.2. > > Why is SSLv3.0 seen in FIPS mode on this install ? > That refers to the minimum version of the ciphersuite: it doesn't imply that it will only be used in SSLv3 (which is disabled in FIPS mode). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From foleyj at cisco.com Fri Apr 24 23:17:13 2015 From: foleyj at cisco.com (John Foley) Date: Fri, 24 Apr 2015 19:17:13 -0400 Subject: [openssl-users] Performance problems with OpenSSL and threading In-Reply-To: References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org> <5539844F.4090107@cisco.com> <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com> Message-ID: <553ACEF9.4080702@cisco.com> Some of the algorithms still invoke the FIPS flavor of the algorithm even when FIPS is disabled. For example, this code is from EVP_DigestUpdate(). int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *data, size_t count) { #ifdef OPENSSL_FIPS return FIPS_digestupdate(ctx, data, count); #else return ctx->update(ctx, data, count); #endif } In 1.0.1, locks 39 and 40 are: # define CRYPTO_LOCK_FIPS 39 # define CRYPTO_LOCK_FIPS2 40 You should try adding some logic to skip the lock in your lock handler when the lock ID is 39 or 40. Again, it should be safe to not lock on these two as long as the FIPS POST has completed. On 04/24/2015 05:56 PM, Bryan Call wrote: > In my last email I ran the benchmark on Fedora 21 (big mistake). > Here are the results when running it back on the 28/56 core RHEL 6.5 > server showing contention in a different place (fips). Is there a > reason it would be calling into the FIPS code to get a lock of FIPS is > not enabled? > > Contention log: > [Apr 24 21:35:09.731] Server {0x7f5529ccd700} ERROR: contention for > lock - total contention: 70662 waiting: 16 file: fips.c line: 471 type: 40 > [Apr 24 21:35:09.732] Server {0x7f55299ca700} ERROR: contention for > lock - total contention: 71605 waiting: 2 file: fips.c line: 107 type: 39 > > > Line in in fips that see the contention the most: > [bcall at bm77 trafficserver]$ grep fips.c diags.log | cut -f 19 -d ' ' | > sort | uniq -c | sort -rn > 875379 471 > 288338 107 > 275472 127 > > > Different lock types and their contention frequency (multiple benchmarks): > 875379 40 < - in fips.c > 563810 39 <- also in fips.c > 440518 1 > 44145 18 > 17447 2 > 11356 10 > 1377 19 > 687 12 > 532 25 > 302 33 > 239 9 > 58 16 > 40 21 > 32 11 > 19 3 > 1 14 > > > Code to diable FIPS and log: > #ifdef OPENSSL_FIPS > int mode = FIPS_mode(); > Debug("ssl", "FIPS_mode: %d", mode); > mode = FIPS_mode(); > if (mode) { > FIPS_mode_set(0); > Debug("ssl", "FIPS_mode: %d", mode); > } > #endif > > [Apr 24 21:43:45.860] Server {0x7f7628146800} DEBUG: (ssl) FIPS_mode: 0 > > -Bryan > > > > >> On Apr 24, 2015, at 10:56 AM, John Foley > > wrote: >> >> When you create the private key given to SSL_CTX, be sure to >> instantiate a private key for each thread as well. If you share the >> same key across all threads, this can introduce contention. >> >> Here are the type 1 & 2 locks: >> >> # define CRYPTO_LOCK_ERR 1 >> # define CRYPTO_LOCK_EX_DATA 2 >> >> Have you checked the OpenSSL error log to see what errors are being >> generated? >> >> Also, if you disable FIPS, does the thread contention still occur? >> >> >> >> On 04/24/2015 01:36 PM, Bryan Call wrote: >>> We are using a single SSL_CTX across all the threads, so I will >>> create multiple SSL_CTX per thread. I implemented dynlock callbacks >>> yesterday, but I didn?t see them being used in the tests I did. I >>> also added atomic counters to see what type of locks are having >>> contention (see logs below): >>> >>> Most of the lock contention seems to be around type 2 and type 1 >>> locks when calling our lock callback. In the FIPS/POST and SSL_CTX >>> recommendations, in your previous email, what types of locks would >>> those help with? >>> >>> Log output: >>> [Apr 24 10:21:24.339] Server {0xb310000} ERROR: >> :178 (SSL_locking_callback)> contention for >>> lock - total contention: 3938 waiting: 1 file: >>> /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/ex_data.c >>> line: 496 type: 2 >>> [Apr 24 10:21:24.754] Server {0xb10a000} ERROR: >> :178 (SSL_locking_callback)> contention for >>> lock - total contention: 1350 waiting: 1 file: >>> /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/err/err_def.c >>> line: 343 type: 1 >>> >>> >>> -Bryan >>> >>> >>> >>> >>>> On Apr 23, 2015, at 4:46 PM, John Foley >>> > wrote: >>>> >>>> Looking at your call stack, it appears you're testing with FIPS >>>> mode enabled. There's a lock in FIPS_selftest_failed() that's used >>>> to ensure the crypto algorithms inside the FIPS boundary are not >>>> utilized until after the POST has completed and passed. >>>> Unfortunately this lock remains installed for the lifetime of the >>>> process. We've seen thread contention in this area when using >>>> OpenSSL. One work-around is to modify your handler that you pass >>>> to SSL_locking_callback() to not lock when the lock ID is >>>> CRYPTO_LOCK_FIPS. But you would only want to disable this >>>> particular lock ID after the POST has completed. >>>> >>>> If the above doesn't help, another item to check is whether you're >>>> instantiating an SSL_CTX for each thread. I've seen some >>>> developers use a single SSL_CTX for multiple threads. This results >>>> in a single instance of the server cert and private key being >>>> shared across all the threads. This results in thread contention >>>> on the asymmetric key operations associated with the cert and >>>> private key (e.g. RSA). Be sure that each thread instantiates it's >>>> own SSL_CTX and certificate/private key. >>>> >>>> Lastly, add some debugs to count the locks by lock ID in your lock >>>> handler. There are about 40 different lock IDs defined in >>>> crypto/crypto.h. You'll need to identify which lock is causing the >>>> thread contention. Once you know that, then you can look in the >>>> code to see where that lock is used and troubleshoot from there. >>>> >>>> >>>> >>>> On 04/23/2015 07:23 PM, Bryan Call wrote: >>>>> I was running a benchmark on a 28 core (56 hyper-threaded) server >>>>> that is running 84 threads in the process and I am seeing a lot of >>>>> lock contention. I saw a lot of lock contention in the calls to >>>>> SSL_get_error() ssl3_accept(). I am running RHEL 6.5 >>>>> and openssl-1.0.1e-30.el6_6.7.x86_64. We have >>>>> used SSL_locking_callback() to setup pthread mutex locks, but >>>>> haven?t setup dynlocks yet. Would dynlocks help in this scenario? >>>>> >>>>> >>>>> Output from perf: >>>>> Samples: 1M of event 'cycles', Event count (approx.): 602783506611 >>>>> - 48.04% [ET_NET 0] [kernel.kallsyms] [k] _spin_lock ? >>>>> - _spin_lock ? >>>>> >>>>> * + 48.05% futex_wait_setup ? >>>>> * + 47.79% futex_wake ? >>>>> * + 1.20% tcp_v4_rcv ? >>>>> * + 0.98% task_rq_lock ? >>>>> * + 0.64% double_lock_balance ? >>>>> >>>>> + 3.94% [ET_NET 0] libcrypto.so.1.0.1e [.] bn_mul_mont ? >>>>> + 1.93% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_usub ? >>>>> + 1.80% [ET_NET 0] libcrypto.so.1.0.1e [.] 0x00000000000e5200 ? >>>>> + 1.49% [ET_NET 0] libcrypto.so.1.0.1e [.] sha256_block_data_order ? >>>>> + 0.97% [ET_NET 0] libcrypto.so.1.0.1e [.] gcm_ghash_clmul ? >>>>> + 0.85% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_lock ? >>>>> + 0.84% [ET_NET 0] libcrypto.so.1.0.1e [.] >>>>> aesni_ctr32_encrypt_blocks ? >>>>> + 0.74% [ET_NET 0] libc-2.12.so [.] malloc ? >>>>> + 0.72% [ET_NET 0] libc-2.12.so [.] memcpy ? >>>>> + 0.57% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_mod_mul_montgomery ? >>>>> + 0.51% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_unlock >>>>> >>>>> pstack of the process (only a couple of the interesting threads): >>>>> Thread 1 (Thread 0x7f1fba151800 (LWP 1106)): >>>>> #0 0x00007f1fbaaeb264 in __lll_lock_wait () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x00007f1fbaae6508 in _L_lock_854 () from /lib64/libpthread.so.0 >>>>> #2 0x00007f1fbaae63d7 in pthread_mutex_lock () from >>>>> /lib64/libpthread.so.0 >>>>> #3 0x000000000072822f in SSL_locking_callback(int, int, char >>>>> const*, int) () >>>>> #4 0x00000031d2ae7f03 in ?? () from /usr/lib64/libcrypto.so.10 >>>>> #5 0x00000031d2ae7d8c in ?? () from /usr/lib64/libcrypto.so.10 >>>>> #6 0x00000031d2ae80ab in ERR_get_state () from >>>>> /usr/lib64/libcrypto.so.10 >>>>> #7 0x00000031d2ae8557 in ?? () from /usr/lib64/libcrypto.so.10 >>>>> #8 0x00000031d2e424a9 in SSL_get_error () from /usr/lib64/libssl.so.10 >>>>> #9 0x00000000007249ef in >>>>> SSLNetVConnection::load_buffer_and_write(long, long&, long&, >>>>> MIOBufferAccessor&, int&) () >>>>> #10 0x00000000007389df in write_to_net_io(NetHandler*, >>>>> UnixNetVConnection*, EThread*) () >>>>> #11 0x0000000000738523 in write_to_net(NetHandler*, >>>>> UnixNetVConnection*, EThread*) () >>>>> #12 0x0000000000731922 in NetHandler::mainNetEvent(int, Event*) () >>>>> #13 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >>>>> #14 0x000000000075877a in EThread::process_event(Event*, int) () >>>>> #15 0x0000000000758c84 in EThread::ex >>>>> >>>>> Thread 56 (Thread 0x7f1fb0ecd700 (LWP 1172)): >>>>> #0 0x00007f1fbaae77d9 in pthread_mutex_unlock () from >>>>> /lib64/libpthread.so.0 >>>>> #1 0x0000000000728265 in SSL_locking_callback(int, int, char >>>>> const*, int) () >>>>> #2 0x00000031d2b57402 in ?? () from /usr/lib64/libcrypto.so.10 >>>>> #3 0x00000031d2b574bd in FIPS_selftest_failed () from >>>>> /usr/lib64/libcrypto.so.10 >>>>> #4 0x00000031d2ae9f1c in EVP_DigestInit_ex () from >>>>> /usr/lib64/libcrypto.so.10 >>>>> #5 0x00000031d2a7977e in HMAC_Init_ex () from >>>>> /usr/lib64/libcrypto.so.10 >>>>> #6 0x00000031d2a79c29 in ?? () from /usr/lib64/libcrypto.so.10 >>>>> #7 0x00000031d2af7a42 in EVP_PKEY_CTX_ctrl () from >>>>> /usr/lib64/libcrypto.so.10 >>>>> #8 0x00000031d2ae9ffb in EVP_DigestInit_ex () from >>>>> /usr/lib64/libcrypto.so.10 >>>>> #9 0x00000031d2af952a in ?? () from /usr/lib64/libcrypto.so.10 >>>>> #10 0x00000031d2e34cf2 in tls1_PRF () from /usr/lib64/libssl.so.10 >>>>> #11 0x00000031d2e35796 in tls1_final_finish_mac () from >>>>> /usr/lib64/libssl.so.10 >>>>> #12 0x00000031d2e2db2e in ssl3_get_message () from >>>>> /usr/lib64/libssl.so.10 >>>>> #13 0x00000031d2e1dc3c in ssl3_get_cert_verify () from >>>>> /usr/lib64/libssl.so.10 >>>>> #14 0x00000031d2e220d6 in ssl3_accept () from /usr/lib64/libssl.so.10 >>>>> #15 0x0000000000725287 in >>>>> SSLNetVConnection::sslServerHandShakeEvent(int&) () >>>>> #16 0x00000000007251b3 in >>>>> SSLNetVConnection::sslStartHandShake(int, int&) () >>>>> #17 0x0000000000723df3 in >>>>> SSLNetVConnection::net_read_io(NetHandler*, EThread*) () >>>>> #18 0x0000000000731852 in NetHandler::mainNetEvent(int, Event*) () >>>>> #19 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >>>>> #20 0x000000000075877a in EThread::process_event(Event*, int) () >>>>> #21 0x0000000000758c84 in EThread::execute() () >>>>> #22 0x0000000000757cf8 in spawn_thread_internal(void*) () >>>>> #23 0x00007f1fbaae49d1 in start_thread () from /lib64/libpthread.so.0 >>>>> #24 0x00000030ff0e88fd in clone () from /lib64/libc.so.6 >>>>> >>>>> -Bryan >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> openssl-users mailing list >>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>> >>>> _______________________________________________ >>>> openssl-users mailing list >>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> >>> >>> >>> _______________________________________________ >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From graeme.perrow at sap.com Sat Apr 25 00:49:21 2015 From: graeme.perrow at sap.com (Perrow, Graeme) Date: Sat, 25 Apr 2015 00:49:21 +0000 Subject: [openssl-users] Can RSA_private_decrypt succeed with the wrong padding? Message-ID: <6378BFFB8601BD438AD9AF3CA610548E59B059FB@DEWDFEMB16B.global.corp.sap> Using OpenSSL 1.0.1m on 64-bit Windows and Linux. I have implemented RSA encryption using the RSA_public_encrypt and RSA_private_decrypt functions and various padding types. This is working fine except that in very rare cases, my test fails because decrypting succeeds when it should fail. I'm basically doing this (pseudocode): RSA_public_encrypt( "abc", encrypted_data, my_public_key, RSA_PKCS1_OAEP_PADDING ); RSA_private_decrypt( encrypted_data, decrypted_data, my_private_key, RSA_NO_PADDING ); Note that the padding types are different. The vast majority of the time, I get an error from the RSA_private_decrypt call but now and again, it succeeds. The output data is NOT "abc" however, it's seemingly random data. I've seen varying lengths for the output data as well, from 11 bytes to 115. I don't understand the underlying crypto well enough to know - is it possible for RSA_private_decrypt to be unable to tell that the wrong padding was used, or is this a bug in OpenSSL? Thanks Graeme Perrow -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sat Apr 25 05:41:04 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 25 Apr 2015 05:41:04 +0000 Subject: [openssl-users] Can RSA_private_decrypt succeed with the wrong padding? In-Reply-To: <6378BFFB8601BD438AD9AF3CA610548E59B059FB@DEWDFEMB16B.global.corp.sap> References: <6378BFFB8601BD438AD9AF3CA610548E59B059FB@DEWDFEMB16B.global.corp.sap> Message-ID: <20150425054104.GM25758@mournblade.imrryr.org> On Sat, Apr 25, 2015 at 12:49:21AM +0000, Perrow, Graeme wrote: > Using OpenSSL 1.0.1m on 64-bit Windows and Linux. > > I have implemented RSA encryption using the RSA_public_encrypt and > RSA_private_decrypt functions and various padding types. This is working > fine except that in very rare cases, my test fails because decrypting > succeeds when it should fail. I'm basically doing this (pseudocode): > > RSA_public_encrypt( "abc", encrypted_data, my_public_key, RSA_PKCS1_OAEP_PADDING ); > RSA_private_decrypt( encrypted_data, decrypted_data, my_private_key, RSA_NO_PADDING ); A real code fragment would be substantially more useful that "pseudo-code" here. This should *always* succeed, provided you pass the correct length to RSA_private_decrypt. From the manpage: flen must be ... and exactly RSA_size(rsa) for RSA_NO_PADDING. > Note that the padding types are different. The vast majority of the time, > I get an error from the RSA_private_decrypt call but now and again, it > succeeds. You're doing something wrong, it should always recover the OAEP padded data, which is basically random, you need to reverse the OAEP padding to recover the plaintext. > I don't understand the underlying crypto well enough to know - is it > possible for RSA_private_decrypt to be unable to tell that the wrong > padding was used, or is this a bug in OpenSSL? When not using padding, that's not "wrong" padding, you're just doing a raw RSA decrypt, and any input that is smaller than the modulus (but has the same bit length) should decrypt to something. -- Viktor. From de.techno at gmail.com Sat Apr 25 10:04:53 2015 From: de.techno at gmail.com (dE) Date: Sat, 25 Apr 2015 15:34:53 +0530 Subject: [openssl-users] CTX_free crash In-Reply-To: <55361DD1.4050304@gmail.com> References: <5533E5AB.9030109@gmail.com> <55361DD1.4050304@gmail.com> Message-ID: <553B66C5.5030506@gmail.com> On 04/21/15 15:22, dE wrote: > On 04/20/15 00:10, Salz, Rich wrote: >>> Sometimes, the program crashes when doing an SSL_CTX_free; before the >>> crash, ctx is an invalid pointer, that's why I can get a valid value >>> from >>> SSL_CTX_get_max_cert_list (ctx), so it's not a double free problem. >> You mean it's a VALID pointer? >> >> We'll need a more detailed backtrace. >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > Relevant parts of the BT > > #0 0x00007ffff54bde97 in raise () from /lib64/libc.so.6 > #1 0x00007ffff54bf208 in abort () from /lib64/libc.so.6 > #2 0x00007ffff54feea0 in ?? () from /lib64/libc.so.6 > #3 0x00007ffff55048be in ?? () from /lib64/libc.so.6 > #4 0x00007ffff55050ab in ?? () from /lib64/libc.so.6 > #5 0x00007ffff6827f7c in CRYPTO_free (str=0x8fbfe0) at mem.c:401 > #6 0x00007ffff67e99a0 in X509_VERIFY_PARAM_free (param=0x8fbfe0) at > x509_vpm.c:102 > #7 0x00007ffff6d5302a in SSL_CTX_free (a=0x8fe090) at ssl_lib.c:1944 libc BT needed also? From noloader at gmail.com Sat Apr 25 19:19:21 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sat, 25 Apr 2015 15:19:21 -0400 Subject: [openssl-users] How to invoke RPATH settings? Message-ID: OpenSSL has support for RPATHs. How do we invoke the support? Configure and --openssldir or --prefix does not do it. Should there be an --rpath option to Configure make this clear and easy? ***** ./Configure linux-x86_64 shared no-ssl2 no-ssl3 no-comp --openssldir=/usr/local/ssl --prefix=/usr/local/ssl make depend make ... $ ldd ./libssl.so linux-vdso.so.1 => (0x00007fffa14ef000) libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f9b17de5000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9b17a20000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9b1781b000) /lib64/ld-linux-x86-64.so.2 (0x00007f9b18448000) ***** $ grep -i rpath * grep: apps: Is a directory grep: bugs: Is a directory grep: certs: Is a directory CHANGES: *) Add full support for -rpath/-R, both in shared libraries and CHANGES: uses the RPATH feature, and is available through the special CHANGES: configuration target "alpha-cc-rpath", which will never be selected ... Makefile: SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \ Makefile.bak: SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \ Makefile.org: SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \ Makefile.shared:DO_GNU_APP=LDFLAGS="$(CFLAGS) -Wl,-rpath,$(LIBRPATH)" Makefile.shared: LDFLAGS="$(CFLAGS) -Wl,-rpath,$(LIBPATH)"; \ Makefile.shared: LDFLAGS="$(CFLAGS) -rpath $(LIBRPATH)"; \ Makefile.shared: LDFLAGS="$(CFLAGS) -R $(LIBRPATH)"; \ Makefile.shared: @LDFLAGS="$(CFLAGS) -Wl,-rpath,$(LIBRPATH)"; \ Makefile.shared: LDFLAGS="$(CFLAGS) -Wl,+s,+cdp,../:,+cdp,./:,+b,$(LIBRPATH)"; \ Makefile.shared: LDFLAGS="$(CFLAGS) -Wl,-brtl,-blibpath:$(LIBRPATH):$${LIBPATH:-/usr/lib:/lib}"; \ Makefile.shared:symlink.cygwin symlink.alpha-osf1 symlink.tru64 symlink.tru64-rpath symlink.beos: Makefile.shared:link_o.tru64-shared-rpath: link_o.tru64-rpath Makefile.shared:link_a.tru64-shared-rpath: link_a.tru64-rpath Makefile.shared:link_app.tru64-shared-rpath: link_app.tru64-rpath Makefile.shared:symlink.tru64-shared-rpath: symlink.tru64-rpath ... From de.techno at gmail.com Sat Apr 25 22:31:06 2015 From: de.techno at gmail.com (dE) Date: Sun, 26 Apr 2015 04:01:06 +0530 Subject: [openssl-users] CTX_free crash In-Reply-To: <553B66C5.5030506@gmail.com> References: <5533E5AB.9030109@gmail.com> <55361DD1.4050304@gmail.com> <553B66C5.5030506@gmail.com> Message-ID: <553C15AA.2030409@gmail.com> On 04/25/15 15:34, dE wrote: > On 04/21/15 15:22, dE wrote: >> On 04/20/15 00:10, Salz, Rich wrote: >>>> Sometimes, the program crashes when doing an SSL_CTX_free; before the >>>> crash, ctx is an invalid pointer, that's why I can get a valid >>>> value from >>>> SSL_CTX_get_max_cert_list (ctx), so it's not a double free problem. >>> You mean it's a VALID pointer? >>> >>> We'll need a more detailed backtrace. >>> _______________________________________________ >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> Relevant parts of the BT >> >> #0 0x00007ffff54bde97 in raise () from /lib64/libc.so.6 >> #1 0x00007ffff54bf208 in abort () from /lib64/libc.so.6 >> #2 0x00007ffff54feea0 in ?? () from /lib64/libc.so.6 >> #3 0x00007ffff55048be in ?? () from /lib64/libc.so.6 >> #4 0x00007ffff55050ab in ?? () from /lib64/libc.so.6 >> #5 0x00007ffff6827f7c in CRYPTO_free (str=0x8fbfe0) at mem.c:401 >> #6 0x00007ffff67e99a0 in X509_VERIFY_PARAM_free (param=0x8fbfe0) at >> x509_vpm.c:102 >> #7 0x00007ffff6d5302a in SSL_CTX_free (a=0x8fe090) at ssl_lib.c:1944 > > libc BT needed also? Ok, more detailed BT #0 0x00007ffff6d5270d in ssl_session_hash (a=0x0) at ssl_lib.c:1674 #1 0x00007ffff6d527db in ssl_session_LHASH_HASH (arg=0x0) at ssl_lib.c:1699 #2 0x00007ffff6795daf in getrn (lh=0x8fcd80, data=0x0, rhash=0x7fffd67eb908) at lhash.c:411 #3 0x00007ffff679571a in lh_delete (lh=0x8fcd80, data=0x0) at lhash.c:224 #4 0x00007ffff6d58d33 in timeout_doall_arg (s=0x0, p=0x7fffd67eba40) at ssl_sess.c:988 #5 0x00007ffff6d58dc6 in timeout_LHASH_DOALL_ARG (arg1=0x0, arg2=0x7fffd67eba40) at ssl_sess.c:997 #6 0x00007ffff6795942 in doall_util_fn (lh=0x8fcd80, use_arg=1, func=0x0, func_arg=0x7ffff6d58d93 , arg=0x7fffd67eba40) at lhash.c:292 #7 0x00007ffff67959d9 in lh_doall_arg (lh=0x8fcd80, func=0x7ffff6d58d93 , arg=0x7fffd67eba40) at lhash.c:307 #8 0x00007ffff6d58e56 in SSL_CTX_flush_sessions (s=0x8fcec0, t=0) at ssl_sess.c:1011 #9 0x00007ffff6d53048 in SSL_CTX_free (a=0x8fcec0) at ssl_lib.c:1956 From newcomer83 at web.de Sun Apr 26 14:48:00 2015 From: newcomer83 at web.de (Alexander) Date: Sun, 26 Apr 2015 16:48:00 +0200 Subject: [openssl-users] How do I uninitialize OpenSSL properly? In-Reply-To: References: Message-ID: <553CFAA0.6060201@web.de> Is there anyone out there who can help me? Please? Am 24.04.2015 um 16:43 schrieb Newcomer83 at web.de: > Hello everyone, > > I am using OpenSSL sockets and I have the problem I described in the following thread, i.e. a bunch of memory-leaks that happen most likely because I don't uninitialize OpenSSL properly. I believe this to be the cause, because the errors appeared exactly at the moment when I switched from dynamic to static linking of libeay32 and ssleay32: http://stackoverflow.com/questions/29845527/how-to-properly-uninitialize-openssl > > I admit I am still a beginner, but please help me anyway. :-) I swear I have been googling and fumbling around with OpenSSL quite a bit by myself so far. > > Cheers > Alex > From rsalz at akamai.com Sun Apr 26 16:33:07 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 26 Apr 2015 16:33:07 +0000 Subject: [openssl-users] How do I uninitialize OpenSSL properly? In-Reply-To: <553CFAA0.6060201@web.de> References: <553CFAA0.6060201@web.de> Message-ID: This isn't paid support; two days isn't a long time to wait :) Is this on process exit? If so, does it really matter? You might look at the apps_startup and apps_shutdown functions in apps/openssl.c on the master branch. /r$ -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From hubga1 at seznam.cz Sun Apr 26 17:05:11 2015 From: hubga1 at seznam.cz (hubga1 at seznam.cz) Date: Sun, 26 Apr 2015 19:05:11 +0200 Subject: [openssl-users] Can't connect to site, OpenSSL returns error Message-ID: <553D1AC7.4040205@seznam.cz> I tried this command openssl.exe s_client -connect ezfile.ch:443 And it returns this kind of error error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error The site uses TLS 1.1, AES_128_CBC_SHA1, ECDHE-ECDSA. Does anybody know where the problem is? Is this server misconfiguration or some problem in OpenSLL? Thanks From kurt at roeckx.be Sun Apr 26 17:23:26 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 26 Apr 2015 19:23:26 +0200 Subject: [openssl-users] Can't connect to site, OpenSSL returns error In-Reply-To: <553D1AC7.4040205@seznam.cz> References: <553D1AC7.4040205@seznam.cz> Message-ID: <20150426172326.GA25796@roeckx.be> On Sun, Apr 26, 2015 at 07:05:11PM +0200, hubga1 at seznam.cz wrote: > I tried this command > openssl.exe s_client -connect ezfile.ch:443 > > And it returns this kind of error > error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal > error I can not reproduce this. What version are you using? There is nothing wrong with that server, so it's most likely a problem with whatever you're using. Kurt From rsalz at akamai.com Sun Apr 26 17:25:06 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 26 Apr 2015 17:25:06 +0000 Subject: [openssl-users] Can't connect to site, OpenSSL returns error In-Reply-To: <553D1AC7.4040205@seznam.cz> References: <553D1AC7.4040205@seznam.cz> Message-ID: <1136afc3dcbf4b88b41ae40b437def22@usma1ex-dag1mb2.msg.corp.akamai.com> > And it returns this kind of error > error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal > error > > The site uses TLS 1.1, AES_128_CBC_SHA1, ECDHE-ECDSA. Perhaps there is a middlebox in the way that gets version negotiation wrong. Try adding the -tls1 flag. From hubga1 at seznam.cz Sun Apr 26 17:50:25 2015 From: hubga1 at seznam.cz (hubga1 at seznam.cz) Date: Sun, 26 Apr 2015 19:50:25 +0200 Subject: [openssl-users] Can't connect to site, OpenSSL returns error In-Reply-To: <1136afc3dcbf4b88b41ae40b437def22@usma1ex-dag1mb2.msg.corp.akamai.com> References: <553D1AC7.4040205@seznam.cz> <1136afc3dcbf4b88b41ae40b437def22@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <553D2561.8030904@seznam.cz> >> And it returns this kind of error >> error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal >> error >> >> The site uses TLS 1.1, AES_128_CBC_SHA1, ECDHE-ECDSA. > > Perhaps there is a middlebox in the way that gets version negotiation wrong. Try adding the -tls1 flag. It returns this with -tls1. I use latest precompiled version "openssl-1.0.2a-i386-win32". So you can't reproduce it? It is local then. CONNECTED(000002FC) 3564:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:.\ss l\s3_pkt.c:1461:SSL alert number 80 3564:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:.\ssl\s3 _pkt.c:645: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1430070431 Timeout : 7200 (sec) Verify return code: 0 (ok) From hubga1 at seznam.cz Sun Apr 26 17:54:14 2015 From: hubga1 at seznam.cz (hubga1 at seznam.cz) Date: Sun, 26 Apr 2015 19:54:14 +0200 Subject: [openssl-users] Can't connect to site, OpenSSL returns error In-Reply-To: <20150426172326.GA25796@roeckx.be> References: <553D1AC7.4040205@seznam.cz> <20150426172326.GA25796@roeckx.be> Message-ID: <553D2646.7040805@seznam.cz> >> On Sun, Apr 26, 2015 at 07:05:11PM +0200, hubga1 at seznam.cz wrote: >> I tried this command >> openssl.exe s_client -connect ezfile.ch:443 >> >> And it returns this kind of error >> error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal >> error > > I can not reproduce this. What version are you using? > > There is nothing wrong with that server, so it's most likely a > problem with whatever you're using. > > > > Kurt > I use latest precompiled "openssl-1.0.2a-i386-win32". Weird. I have to investigate more then. From newcomer83 at web.de Sun Apr 26 18:14:49 2015 From: newcomer83 at web.de (Alexander) Date: Sun, 26 Apr 2015 20:14:49 +0200 Subject: [openssl-users] How do I uninitialize OpenSSL properly? In-Reply-To: References: <553CFAA0.6060201@web.de> Message-ID: <553D2B19.1080405@web.de> Thanks for the quick reply! I'm sorry, I didn't mean to sound impatient. It's just that I read through the archives and so much has been happening that I was afraid that my thread would be swamped away unnoticed. My problem is most likely an on process exit thing, because I do the certificate stuff only once, no matter how long the application is running. Therefore it's probably not a big problem, but memory leaks look bad, because they imply that I am using OpenSSL improperly. Anyway, thanks for the advice on apps_startup and apps_shutdown. I will try them out as soon as I can. Those defines do look like salvation from all the problems I had finding the right methods to initialize/uninitialize OpenSSL properly. Have a happy rest of Sunday! Cheers Alex Am 26.04.2015 um 18:33 schrieb Salz, Rich: > This isn't paid support; two days isn't a long time to wait :) > > Is this on process exit? If so, does it really matter? > > You might look at the apps_startup and apps_shutdown functions in apps/openssl.c on the master branch. > > /r$ > > -- > Senior Architect, Akamai Technologies > IM: richsalz at jabber.at Twitter: RichSalz > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From bhat.jayalakshmi at gmail.com Mon Apr 27 04:54:43 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Sun, 26 Apr 2015 22:54:43 -0600 Subject: [openssl-users] Encryption and Decryption using ECC based certificate private/public key pair Message-ID: Hello All, I am working on a project where there is need to encrypt and decrypt certain data using certificate public/private key pair. So far we were using RSA based certificates. OpenSSL provides good number of API's for RSA based encryption/decryption operation. Now we are planning to support ECDSA based certificates also. I am not able to find any encryption/decryption API's in EC context. I wanted to know are there any encryption/decryption API's using ECDSA based public/private key pair. Or is there any sample code I can look into. Thanks and Regards Jayalakshmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Mon Apr 27 05:41:13 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 27 Apr 2015 01:41:13 -0400 Subject: [openssl-users] Encryption and Decryption using ECC based certificate private/public key pair In-Reply-To: References: Message-ID: On Mon, Apr 27, 2015 at 12:54 AM, Jayalakshmi bhat wrote: > Hello All, > > I am working on a project where there is need to encrypt and decrypt certain > data using certificate public/private key pair. So far we were using RSA > based certificates. OpenSSL provides good number of API's for RSA based > encryption/decryption operation. > > Now we are planning to support ECDSA based certificates also. I am not able > to find any encryption/decryption API's in EC context. > > I wanted to know are there any encryption/decryption API's using ECDSA based > public/private key pair. Or is there any sample code I can look into. ECDSA is a signing algorithm used for authentication. If you want to encrypt/decrypt, then you need something else. In the case of SSL/TLS, the something else is ECDHE. A shared secret drops out of the ECDHE key exchange, and that's used to key a channel for bulk encryption. The ECDSA signature authenticates ECDHE parameters so you know they are authentic (i.e., from the party who you expect, and not an adversary). In addition to ECDHE, another choice is the MQV family of key exchanges. Its a family now because MQV leaked some information about the private exponent, so Krawczyk provided "Hashed MQV" (HMWV). HMQV was later improved by Sarr, Elbaz?Vincent, and Bajard with "Fully Hashed MQV" (FHMQV). As far as encryption systems outside of SSL/TLS, check out Elliptic Curve Integrated Encryption Scheme (ECIES). You can do bulk encryption and decryption with it also. But it does not use an ECDSA key per se; rather, its just a ecPublicKey ASN.1 type. ECIES a Diffie-Hellman based integrated scheme that combines a Key Encapsulation Mechanism (KEM) with a Data Encapsulation Mechanism (DEM). The output is a 3-tuple {K,C,T}, where K is a "encrypted shared secret" (lots of hand waiving), C is the cipher text and T is an authentication tag. In ECIES, K is really half of a ECDHE exchange with an ephemeral key. To recover the "encrypted shared secret", the person doing the decryption uses their long term static key to perform the other half of the key exchange, and that's the shared secret. The shared secret is then digested with a KDF and used to key a stream cipher and a HMAC. Jeff From hubga1 at seznam.cz Mon Apr 27 06:12:14 2015 From: hubga1 at seznam.cz (hubga1 at seznam.cz) Date: Mon, 27 Apr 2015 08:12:14 +0200 Subject: [openssl-users] Can't connect to site, OpenSSL returns error In-Reply-To: <20150426172326.GA25796@roeckx.be> References: <553D1AC7.4040205@seznam.cz> <20150426172326.GA25796@roeckx.be> Message-ID: <553DD33E.4080807@seznam.cz> >> I tried this command >> openssl.exe s_client -connect ezfile.ch:443 >> >> And it returns this kind of error >> error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal >> error > > I can not reproduce this. What version are you using? > > There is nothing wrong with that server, so it's most likely a > problem with whatever you're using. > > > > Kurt It is weird that it worked for you. Anyway I found a way how to fix it (if I can call it "a fix"). The key is to provide a flag "-servername" to enable SNI (Server Name Indication). From hubga1 at seznam.cz Mon Apr 27 06:12:54 2015 From: hubga1 at seznam.cz (hubga1 at seznam.cz) Date: Mon, 27 Apr 2015 08:12:54 +0200 Subject: [openssl-users] Can't connect to site, OpenSSL returns error In-Reply-To: <1136afc3dcbf4b88b41ae40b437def22@usma1ex-dag1mb2.msg.corp.akamai.com> References: <553D1AC7.4040205@seznam.cz> <1136afc3dcbf4b88b41ae40b437def22@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <553DD366.2020503@seznam.cz> >> And it returns this kind of error >> error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal >> error >> >> The site uses TLS 1.1, AES_128_CBC_SHA1, ECDHE-ECDSA. > > Perhaps there is a middlebox in the way that gets version negotiation wrong. Try adding the -tls1 flag. Flag "-servername" helped. From oyljerry at gmail.com Mon Apr 27 09:20:00 2015 From: oyljerry at gmail.com (Jerry OELoo) Date: Mon, 27 Apr 2015 17:20:00 +0800 Subject: [openssl-users] [openss-users] How to correctly shutdown for connection to avoid memory leak Message-ID: Hi. I am using openssl 1.0.2 to do some ssl connection, now I am facing some memory leak issue. ssl = SSL_new(m_ctx); sbio = BIO_new_socket(server, BIO_NOCLOSE); SSL_set_bio(ssl,sbio,sbio); .... SSL_connect() ... //After handle, release resource if(ssl) SSL_shutdown(ssl); Now I have some questions about above code as I think there is some leak in it. 1) As I used BIO_NOCLOSE, should I free for BIO_new_socket 2) from SSL_shutdown. I found below, so Should I call SSL_shutdown twice? 0 The shutdown is not yet finished. Call SSL_shutdown() for a second time, if a bidirectional shutdown shall be performed. The output of SSL_get_error may be misleading, as an erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred. 3) It seems I missing SSL_free(), So when I do not need this ssl object, I should call SSL_free(), right? Thanks! -- Rejoice,I Desire! From rsalz at akamai.com Mon Apr 27 11:20:58 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 27 Apr 2015 11:20:58 +0000 Subject: [openssl-users] [openss-users] How to correctly shutdown for connection to avoid memory leak In-Reply-To: References: Message-ID: If you used BIO_NOCLOSE then you have to close the BIO. Yes, after shutdown is done, call SSL_free() From noloader at gmail.com Mon Apr 27 11:39:46 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 27 Apr 2015 07:39:46 -0400 Subject: [openssl-users] [openss-users] How to correctly shutdown for connection to avoid memory leak In-Reply-To: References: Message-ID: > I am using openssl 1.0.2 to do some ssl connection, now I am facing > some memory leak issue. > > ssl = SSL_new(m_ctx); > sbio = BIO_new_socket(server, BIO_NOCLOSE); > SSL_set_bio(ssl,sbio,sbio); > .... > > SSL_connect() > ... > > //After handle, release resource > if(ssl) > SSL_shutdown(ssl); > Also see Rescorla's An Introduction to OpenSSL Programming Part I (http://www.rtfm.com/openssl-examples/part1.pdf) and An Introduction to OpenSSL Programming Part II (http://www.rtfm.com/openssl-examples/part2.pdf). They also show you how to handle the return value from SSL_shutdown. Jeff From raji.kotamraju at gmail.com Mon Apr 27 12:29:21 2015 From: raji.kotamraju at gmail.com (Rajeswari K) Date: Mon, 27 Apr 2015 17:59:21 +0530 Subject: [openssl-users] ECDSA digest configurations In-Reply-To: <20150424173601.GB5240@openssl.org> References: <20150424173601.GB5240@openssl.org> Message-ID: Hi Steve, Thanks for the response. We are using openssl-1.0.1j. Following is how have configured NID_sha1 and NID_ecdsa_with_sha1. We use our own signature and digest methods. But, i see modification of digest has issue. If i dont set any digest method, then our signature functions are getting used and for digest openssl's sha1, sha256 etc functions are getting used. I see that configuraiton of NID_ecdsa_with_sha1 has some issue on my setup. Please take a look at these configurations and provide your inputs. ECDSA digest structure : static const EVP_MD ios_ecdsa_sha1 = { NID_ecdsa_with_SHA1, NID_ecdsa_with_SHA1, SHA_DIGEST_LENGTH, EVP_MD_FLAG_PKEY_METHOD_SIGNATURE, sha1init, sha1update, sha1final, NULL, NULL, EVP_PKEY_ECDSA_method, SHA_CBLOCK, sizeof(EVP_MD *)+sizeof(SHA1_CTX) }; RSA digest structure : static const EVP_MD ios_sha1_md = { NID_sha1, NID_sha1WithRSAEncryption, SHA_DIGEST_LENGTH, 0, sha1init, sha1update, sha1final, NULL, NULL, EVP_PKEY_RSA_method, SHA_CBLOCK, sizeof(EVP_MD *) + sizeof(SHA1_CTX) }; With this update, only RSA ciphers are working fine. But not ECDSA ciphers. Thanks, Rajeswari. On Fri, Apr 24, 2015 at 11:06 PM, Dr. Stephen Henson wrote: > On Fri, Apr 24, 2015, Rajeswari K wrote: > > > Hello openssl-users, > > > > I have an issue with update of ECDSA digests in our environment. > > > > We have our own digest functions for init, update and final where we > > registered with these functions for NID_sha1, NID_sha256, NID_sha384 and > > NID_sha512. These digests were updated at openssl, via > ENGINE_set_digests() > > function. > > > > After update, i see that all RSA cerificate based ciphers are working > fine > > with both TLS1.0 and TLS1.2. > > > > And, i added the ECDSA algorithm with openssl function > > EVP_add_digest(EVP_ecdsa()); > > > > But, for me ECDSA cert based cipher suites are not working. These are > > landing to following errors. > > > > digital envelope routines:EVP_SignFinal:wrong public key type : > > crypto/evp/p_sign .c:139: > > > > SSL routines:SSL3_SEND_SERVER_KEY_EXCHANGE:EVP lib: ssl/s3_srvr.c:2012 > > > > > > Then i tried following > > Tried to set only NID_ecdsa_with_SHA1 with our init, update and final > > function and tried to update to openssl via ENGINE_set_digests(). > > > > But, now seems to be since i updated NID_ecdsa_with_SHA1 with our sha1 > > functions, whole TLS1.0 handshakes stopped working with "decrypt error or > > bac mac record" errors. > > > > Based on this, seems to be there is a basic thing am missing while > > configuring ECDSA based digests. > > > > Can you please help me on this configuration? How can we differentiate > > between ECDSA digests to RSA digests? > > > > Because both usually lands on to same SHA1, SHA256 etc functions. > > > > I tried one more thing that, along with NID_sha1, NID_sha256, NID_sha384, > > NID_sha512 i tried to define NID_ecdsa_with_SHA1, NID_ecdsa_with_SHA256, > > NID_ecdsa_with_SHA384 and NID_ecdsa_with_SHA512 with respective settings. > > But, with this setting also landing to same above error of "wrong public > > key type". > > > > I need your inputs on this issue. > > > > So does your code just perform the digest operation and not signing? > > Which version was it working with before? > > There isn't really any difference between an ECDSA and RSA digest. Older > versions of OpenSSL linked digests and signing algorithms. That link no > longer > exists and some algorithms are marked as being suitable for multiple public > key algorithms. > > Are you setting the flag EVP_MD_FLAG_PKEY_METHOD_SIGNATURE in the EVP_MD > structure? > > An ENGINE providing alternative implementations of built in digests > shoudn't > need to call EVP_add_digest. If everything is set up properly OpenSSL > should > just switch to the ENGINE implementation. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Apr 27 14:39:08 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 27 Apr 2015 14:39:08 +0000 Subject: [openssl-users] Can't connect to site, OpenSSL returns error In-Reply-To: <553DD33E.4080807@seznam.cz> References: <553D1AC7.4040205@seznam.cz> <20150426172326.GA25796@roeckx.be> <553DD33E.4080807@seznam.cz> Message-ID: > It is weird that it worked for you. Anyway I found a way how to fix it (if I can > call it "a fix"). The key is to provide a flag "-servername" > to enable SNI (Server Name Indication). It's not wrong to call it a fix. The server you are talking to is configured to require SNI, apparently. This is not an openssl issue/bug. From kurt at roeckx.be Mon Apr 27 18:37:39 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Mon, 27 Apr 2015 20:37:39 +0200 Subject: [openssl-users] Can't connect to site, OpenSSL returns error In-Reply-To: References: <553D1AC7.4040205@seznam.cz> <20150426172326.GA25796@roeckx.be> <553DD33E.4080807@seznam.cz> Message-ID: <20150427183739.GA7228@roeckx.be> On Mon, Apr 27, 2015 at 02:39:08PM +0000, Salz, Rich wrote: > > It is weird that it worked for you. Anyway I found a way how to fix it (if I can > > call it "a fix"). The key is to provide a flag "-servername" > > to enable SNI (Server Name Indication). > > It's not wrong to call it a fix. The server you are talking to is configured to require SNI, apparently. So why does it work for me? > This is not an openssl issue/bug. Right, the other end is sending that it has an internal error. There is little we can do about that. Kurt From rsalz at akamai.com Mon Apr 27 19:39:23 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 27 Apr 2015 19:39:23 +0000 Subject: [openssl-users] Can't connect to site, OpenSSL returns error In-Reply-To: <20150427183739.GA7228@roeckx.be> References: <553D1AC7.4040205@seznam.cz> <20150426172326.GA25796@roeckx.be> <553DD33E.4080807@seznam.cz> <20150427183739.GA7228@roeckx.be> Message-ID: <07a6606630f24294b621a0d3d98852ac@usma1ex-dag1mb4.msg.corp.akamai.com> > So why does it work for me? Well, who knows when the remote server wants to see SNI? It could be based on url, ipaddress, etc. From zjedev at gmail.com Mon Apr 27 19:59:07 2015 From: zjedev at gmail.com (Zeke Evans) Date: Mon, 27 Apr 2015 13:59:07 -0600 Subject: [openssl-users] fingerprint mismatch issue with fips build on Win32 Message-ID: Hi, Our win32 applications will sometimes fail to start due to a fingerprint mismatch in the fips module. It appears this is caused by the fixed baseaddr used to verify the checksum. We are building with the /FIXED and /DYNAMICBASE:NO options. The User Guide states: "The standard OpenSSL build with the fips option will use a base address for libeay32.dll of 0xFB00000 by default. This value was chosen because it is unlikely to conflict with other dynamically loaded libraries. In the event of a clash with another dynamically loaded library which will trigger runtime relocation of libeay32.dll, the integrity check will fail with the error FIPS_R_FINGERPRINT_DOES_NOT_MATCH_NONPIC_RELOCATED A base address conflict can be resolved by shuffling the other DLLs or re-compiling OpenSSL with an alternative base address specified with the --with-baseaddr= option." How is 0xFB00000 unlikely to conflict with other DLLs? How would an application select a base address that is less likely to have a conflict? Or, how can an application realistically shuffle the other DLLs? FWIW, the applications load many other DLLs and some are .NET applications. One train of thought is to load the OpenSSL DLL early on, but in some cases that is not practical such as a .NET application. As a side note, the issue appears more frequently when the application is loaded through Visual Studio (not a real world scenario). Thanks, Zeke From Andy.Franks at sath.nhs.uk Mon Apr 27 22:52:33 2015 From: Andy.Franks at sath.nhs.uk (Franks Andy (IT Technical Architecture Manager)) Date: Mon, 27 Apr 2015 23:52:33 +0100 Subject: [openssl-users] Certificate template information Message-ID: <20150427225234.89CE9448031@nhs-pd1e-esg104.ad1.nhs.net> Hi All, First time post, be gentle :-) I know this has come up before, but not recently, and there aren't any answers that seem conclusive. I have need to identify a Microsoft generated certificate's template name, I believe as part of oid 1.3.6.1.4.1.311.21.7 Can anybody shed any light on how to do this with openssl? Thanks Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Apr 28 00:59:25 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 28 Apr 2015 00:59:25 +0000 Subject: [openssl-users] Certificate template information In-Reply-To: <20150427225234.89CE9448031@nhs-pd1e-esg104.ad1.nhs.net> References: <20150427225234.89CE9448031@nhs-pd1e-esg104.ad1.nhs.net> Message-ID: > I have need to identify a Microsoft generated certificate's template name, I believe as part of oid 1.3.6.1.4.1.311.21.7 Where, in a cert OtherName field? From jb-openssl at wisemo.com Tue Apr 28 03:17:17 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 28 Apr 2015 05:17:17 +0200 Subject: [openssl-users] Certificate template information In-Reply-To: References: <20150427225234.89CE9448031@nhs-pd1e-esg104.ad1.nhs.net> Message-ID: <553EFBBD.6070306@wisemo.com> On 28/04/2015 02:59, Salz, Rich wrote: >> I have need to identify a Microsoft generated certificate's template name, I believe as part of oid 1.3.6.1.4.1.311.21.7 > Where, in a cert OtherName field? It is an extension. Microsoft certificate server (their bundled CA software) puts the name of the "certificate template" (analogous to an openssl.cnf section) in a certificate extension, and a few other Microsoft tools unfortunately check this name in addition to more relevant conditions such as EKU values etc. The form I know of can be implemented as follows in openssl.cnf (in the [sometemplatename_cert] section of the file): # enrollCerttypeExtension (1 3 6 1 4 1 311 20 2) # OCTET STRING, encapsulates { # BMPString 'SomeTemplateName' # } # } 1.3.6.1.4.1.311.20.2 = ASN1:BMP:SomeTemplateName I am not sure about the 1.3.6.1.4.1.311.21.7 OID, but it might be similar. 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 From Andy.Franks at sath.nhs.uk Tue Apr 28 08:08:48 2015 From: Andy.Franks at sath.nhs.uk (Franks Andy (IT Technical Architecture Manager)) Date: Tue, 28 Apr 2015 09:08:48 +0100 Subject: [openssl-users] Certificate template information References: <20150427225234.89CE9448031@nhs-pd1e-esg104.ad1.nhs.net> <20150428031913.7700F449673@nhs-pd1e-esg003.ad1.nhs.net> Message-ID: <20150428080849.E293D449C52@nhs-pd1e-esg105.ad1.nhs.net> Thanks Rich, Jakob. So, can I use openssl as it is to query the values of the extension on an existing certificate do you think? The usual issue seems that people want to use openssl to form a request and insert the ms CA template name in there otherwise it complains. I don't want to do that, I want to take a presented certificate (to freeradius) and perform something in the shell that will check against acceptable template names (and that the certificate chains properly, but that's not a problem). I can't find anything on google citing that someone has achieved it so far. Thanks again. Andy -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jakob Bohm Sent: 28 April 2015 04:17 To: openssl-users at openssl.org Subject: Re: [openssl-users] Certificate template information On 28/04/2015 02:59, Salz, Rich wrote: >> I have need to identify a Microsoft generated certificate's template name, I believe as part of oid 1.3.6.1.4.1.311.21.7 > Where, in a cert OtherName field? It is an extension. Microsoft certificate server (their bundled CA software) puts the name of the "certificate template" (analogous to an openssl.cnf section) in a certificate extension, and a few other Microsoft tools unfortunately check this name in addition to more relevant conditions such as EKU values etc. The form I know of can be implemented as follows in openssl.cnf (in the [sometemplatename_cert] section of the file): # enrollCerttypeExtension (1 3 6 1 4 1 311 20 2) # OCTET STRING, encapsulates { # BMPString 'SomeTemplateName' # } # } 1.3.6.1.4.1.311.20.2 = ASN1:BMP:SomeTemplateName I am not sure about the 1.3.6.1.4.1.311.21.7 OID, but it might be similar. 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 From jb-openssl at wisemo.com Tue Apr 28 08:27:05 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 28 Apr 2015 10:27:05 +0200 Subject: [openssl-users] Certificate template information In-Reply-To: <20150428080849.E293D449C52@nhs-pd1e-esg105.ad1.nhs.net> References: <20150427225234.89CE9448031@nhs-pd1e-esg104.ad1.nhs.net> <20150428031913.7700F449673@nhs-pd1e-esg003.ad1.nhs.net> <20150428080849.E293D449C52@nhs-pd1e-esg105.ad1.nhs.net> Message-ID: <553F4459.6040008@wisemo.com> (top posting because OP did so) Note that as I already said, checking the template name is usually a mistake, unless you happen to know that some other software will reject certificates without specific template names. It is much more relevant (and should be done even if the template name is also checked) to check all the specific certificate properties (extensions, basic settings, name forms etc.) against the requirements. Tests such as: Does it include the required set of key usages and extended key usages? Does it include any neither required nor optional (and thus unwanted) key usages or extended key usages? Does the Subject Name have the required form and the required fields? Does it include any required "Subject Alternate Names". Does it include any unwanted "Subject Alternate Names". Is the key of the required type and size? Is the signature on the certificate of the required type and size? Etc. Etc. Basically, look at valid certificates and create a test for each of the fields/attributes. This way, unless some other broken software tests the template name, the testing will be correct even if at some later stage a "variant" template is created for some subset of the certificates used for this purpose. For example, a special template for servers in the HR department. On 28/04/2015 10:08, Franks Andy (IT Technical Architecture Manager) wrote: > Thanks Rich, Jakob. > So, can I use openssl as it is to query the values of the extension on an existing certificate do you think? The usual issue seems that people want to use openssl to form a request and insert the ms CA template name in there otherwise it complains. I don't want to do that, I want to take a presented certificate (to freeradius) and perform something in the shell that will check against acceptable template names (and that the certificate chains properly, but that's not a problem). > I can't find anything on google citing that someone has achieved it so far. > Thanks again. > Andy > > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jakob Bohm > Sent: 28 April 2015 04:17 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Certificate template information > > On 28/04/2015 02:59, Salz, Rich wrote: >>> I have need to identify a Microsoft generated certificate's template name, I believe as part of oid 1.3.6.1.4.1.311.21.7 >> Where, in a cert OtherName field? > It is an extension. Microsoft certificate server (their > bundled CA software) puts the name of the "certificate > template" (analogous to an openssl.cnf section) in a > certificate extension, and a few other Microsoft tools > unfortunately check this name in addition to more > relevant conditions such as EKU values etc. > > The form I know of can be implemented as follows in > openssl.cnf (in the [sometemplatename_cert] section of > the file): > > # enrollCerttypeExtension (1 3 6 1 4 1 311 20 2) > # OCTET STRING, encapsulates { > # BMPString 'SomeTemplateName' > # } > # } > 1.3.6.1.4.1.311.20.2 = ASN1:BMP:SomeTemplateName > > I am not sure about the 1.3.6.1.4.1.311.21.7 OID, but it > might be similar. > > Enjoy > > Jakob 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andy.Franks at sath.nhs.uk Tue Apr 28 08:34:02 2015 From: Andy.Franks at sath.nhs.uk (Franks Andy (IT Technical Architecture Manager)) Date: Tue, 28 Apr 2015 09:34:02 +0100 Subject: [openssl-users] Certificate template information References: <20150427225234.89CE9448031@nhs-pd1e-esg104.ad1.nhs.net> <20150428031913.7700F449673@nhs-pd1e-esg003.ad1.nhs.net> <20150428080849.E293D449C52@nhs-pd1e-esg105.ad1.nhs.net> <20150428082857.A5CA14787C4@nhs-pd1e-esg002.ad1.nhs.net> Message-ID: <20150428083404.1FED844951C@nhs-pd1e-esg104.ad1.nhs.net> Hi Jakob, Thanks for the feedback, what you say makes sense, so I'll try and avoid the non-standard Microsoft thing. Apologies for the top - posting, I get so used to pressing reply. Kinds regards, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhat.jayalakshmi at gmail.com Tue Apr 28 10:03:54 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Tue, 28 Apr 2015 04:03:54 -0600 Subject: [openssl-users] Encryption and Decryption using ECC based certificate private/public key pair In-Reply-To: References: Message-ID: Hi Jeff, Thanks a lot for the detailed explanation. Since I have a requirement to use the certificate public/private keys for encryption/decryption I believe I should be able to use ECDHE based approach. Regards Jayalakshmi On Sun, Apr 26, 2015 at 11:41 PM, Jeffrey Walton wrote: > On Mon, Apr 27, 2015 at 12:54 AM, Jayalakshmi bhat > wrote: > > Hello All, > > > > I am working on a project where there is need to encrypt and decrypt > certain > > data using certificate public/private key pair. So far we were using RSA > > based certificates. OpenSSL provides good number of API's for RSA based > > encryption/decryption operation. > > > > Now we are planning to support ECDSA based certificates also. I am not > able > > to find any encryption/decryption API's in EC context. > > > > I wanted to know are there any encryption/decryption API's using ECDSA > based > > public/private key pair. Or is there any sample code I can look into. > ECDSA is a signing algorithm used for authentication. If you want to > encrypt/decrypt, then you need something else. > > In the case of SSL/TLS, the something else is ECDHE. A shared secret > drops out of the ECDHE key exchange, and that's used to key a channel > for bulk encryption. The ECDSA signature authenticates ECDHE > parameters so you know they are authentic (i.e., from the party who > you expect, and not an adversary). > > In addition to ECDHE, another choice is the MQV family of key > exchanges. Its a family now because MQV leaked some information about > the private exponent, so Krawczyk provided "Hashed MQV" (HMWV). HMQV > was later improved by Sarr, Elbaz?Vincent, and Bajard with "Fully > Hashed MQV" (FHMQV). > > As far as encryption systems outside of SSL/TLS, check out Elliptic > Curve Integrated Encryption Scheme (ECIES). You can do bulk encryption > and decryption with it also. But it does not use an ECDSA key per se; > rather, its just a ecPublicKey ASN.1 type. > > ECIES a Diffie-Hellman based integrated scheme that combines a Key > Encapsulation Mechanism (KEM) with a Data Encapsulation Mechanism > (DEM). The output is a 3-tuple {K,C,T}, where K is a "encrypted shared > secret" (lots of hand waiving), C is the cipher text and T is an > authentication tag. In ECIES, K is really half of a ECDHE exchange > with an ephemeral key. To recover the "encrypted shared secret", the > person doing the decryption uses their long term static key to perform > the other half of the key exchange, and that's the shared secret. The > shared secret is then digested with a KDF and used to key a stream > cipher and a HMAC. > > Jeff > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Tue Apr 28 11:13:18 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 28 Apr 2015 11:13:18 +0000 Subject: [openssl-users] ECDSA digest configurations In-Reply-To: References: <20150424173601.GB5240@openssl.org> Message-ID: <20150428111318.GA17596@openssl.org> On Mon, Apr 27, 2015, Rajeswari K wrote: > Hi Steve, > > Thanks for the response. > > We are using openssl-1.0.1j. > > Following is how have configured NID_sha1 and NID_ecdsa_with_sha1. > > We use our own signature and digest methods. But, i see modification of > digest has issue. If i dont set any digest method, then our signature > functions are getting used and for digest openssl's sha1, sha256 etc > functions are getting used. > > I see that configuraiton of NID_ecdsa_with_sha1 has some issue on my setup. > Please take a look at these configurations and provide your inputs. > > > ECDSA digest structure : > > static const EVP_MD ios_ecdsa_sha1 = > { > NID_ecdsa_with_SHA1, > NID_ecdsa_with_SHA1, > SHA_DIGEST_LENGTH, > EVP_MD_FLAG_PKEY_METHOD_SIGNATURE, > sha1init, > sha1update, > sha1final, > NULL, > NULL, > EVP_PKEY_ECDSA_method, > SHA_CBLOCK, > sizeof(EVP_MD *)+sizeof(SHA1_CTX) > }; > > RSA digest structure : > static const EVP_MD ios_sha1_md = > { > NID_sha1, > NID_sha1WithRSAEncryption, > SHA_DIGEST_LENGTH, > 0, > sha1init, > sha1update, > sha1final, > NULL, > NULL, > EVP_PKEY_RSA_method, > SHA_CBLOCK, > sizeof(EVP_MD *) + sizeof(SHA1_CTX) > }; > > With this update, only RSA ciphers are working fine. But not ECDSA ciphers. > As I said for OpenSSL 1.0.0 and later there is no need for an "ECDSA digest" the SHA1 digest (which is the one you call "RSA digest") can be used to sign any appropriate algorithm if you set EVP_MD_FLAG_PKEY_METHOD_SIGNATURE: but in your example you've set it to 0. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From jonetsu at teksavvy.com Tue Apr 28 12:31:58 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Tue, 28 Apr 2015 05:31:58 -0700 (MST) Subject: [openssl-users] FIPS: SSL 3.0 now forbidden in latest NDCPP update In-Reply-To: <20150424215657.GA8995@openssl.org> References: <1429884831419-57695.post@n7.nabble.com> <20150424172700.GA5240@openssl.org> <1429900168810-57707.post@n7.nabble.com> <20150424215657.GA8995@openssl.org> Message-ID: <1430224318535-57762.post@n7.nabble.com> > That refers to the minimum version of the ciphersuite: it > doesn't imply that it will only be used in SSLv3 (which is > disabled in FIPS mode). Hmmm... I'm sorry but I do not really understand this. Since openssl is run in FIPS mode, and since SSLv3 is disabled, then why would the SSLv3 ciphers show up ? If they have counterparts in TLS that could be used, why wouldn't the TLS version show up instead ? Thanks. -- View this message in context: http://openssl.6102.n7.nabble.com/FIPS-SSL-3-0-now-forbidden-in-latest-NDCPP-update-tp57695p57762.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From matt at openssl.org Tue Apr 28 12:58:35 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 28 Apr 2015 13:58:35 +0100 Subject: [openssl-users] FIPS: SSL 3.0 now forbidden in latest NDCPP update In-Reply-To: <1430224318535-57762.post@n7.nabble.com> References: <1429884831419-57695.post@n7.nabble.com> <20150424172700.GA5240@openssl.org> <1429900168810-57707.post@n7.nabble.com> <20150424215657.GA8995@openssl.org> <1430224318535-57762.post@n7.nabble.com> Message-ID: <553F83FB.3000100@openssl.org> On 28/04/15 13:31, jonetsu wrote: >> That refers to the minimum version of the ciphersuite: it >> doesn't imply that it will only be used in SSLv3 (which is >> disabled in FIPS mode). > > Hmmm... I'm sorry but I do not really understand this. Since openssl is > run in FIPS mode, and since SSLv3 is disabled, then why would the SSLv3 > ciphers show up ? If they have counterparts in TLS that could be used, why > wouldn't the TLS version show up instead ? SSLv3 in the ciphersuite definition means it can be used in SSLv3 *and later*. A ciphersuite isn't defined once for SSLv3, and then again for TLS1.0, and again for TLS1.1 etc - its just defined once and is reused across multiple protocol versions. Matt From jonetsu at teksavvy.com Tue Apr 28 13:23:14 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Tue, 28 Apr 2015 06:23:14 -0700 (MST) Subject: [openssl-users] FIPS: SSL 3.0 now forbidden in latest NDCPP update In-Reply-To: <553F83FB.3000100@openssl.org> References: <1429884831419-57695.post@n7.nabble.com> <20150424172700.GA5240@openssl.org> <1429900168810-57707.post@n7.nabble.com> <20150424215657.GA8995@openssl.org> <1430224318535-57762.post@n7.nabble.com> <553F83FB.3000100@openssl.org> Message-ID: <1430227394773-57764.post@n7.nabble.com> > SSLv3 in the ciphersuite definition means it can be used in > SSLv3 *and later*. A ciphersuite isn't defined once for SSLv3, > and then again for TLS1.0, and again for TLS1.1 etc - its just > defined once and is reused across multiple protocol versions. Yes, this is what I basically understood. What was lacking then in my undestanding, is that : % OPENSSL_FIPS=1 openssl ciphers -v Will not output strictly according to FIPS. Maybe there's no easy way to do that when the definition of a cipher states otherwise. Thanks. -- View this message in context: http://openssl.6102.n7.nabble.com/FIPS-SSL-3-0-now-forbidden-in-latest-NDCPP-update-tp57695p57764.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From rsalz at akamai.com Tue Apr 28 14:25:57 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 28 Apr 2015 14:25:57 +0000 Subject: [openssl-users] FIPS: SSL 3.0 now forbidden in latest NDCPP update In-Reply-To: <1430224318535-57762.post@n7.nabble.com> References: <1429884831419-57695.post@n7.nabble.com> <20150424172700.GA5240@openssl.org> <1429900168810-57707.post@n7.nabble.com> <20150424215657.GA8995@openssl.org> <1430224318535-57762.post@n7.nabble.com> Message-ID: > If they have counterparts in TLS that could be used, why wouldn't > the TLS version show up instead ? Because they are *the same* TLS did not take old ciphers and renumber or rename them. From bird_112 at hotmail.com Tue Apr 28 14:26:25 2015 From: bird_112 at hotmail.com (jack seth) Date: Tue, 28 Apr 2015 09:26:25 -0500 Subject: [openssl-users] Working with large DH parameters Message-ID: Ok I have been doing some experiments with OpenVPN and I can connect using 10000 bit DH parameters.? Any bigger than that up to at least 13824 I get the following 'modulus too large' error on the client log: TLS_ERROR: BIO read tls_read_plaintext error: error:05066067:Diffie-Hellman routines:COMPUTE_KEY:modulus too large: error:14098005:SSL routines:SSL3_SEND_CLIENT_KEY_EXCHANGE:DH lib Wed Apr 22 07:08:58 2015 TLS Error: TLS object -> incoming plaintext read error Wed Apr 22 07:08:58 2015 TLS Error: TLS handshake failed Something interesting/weird also happened.? I tried to test 10001, 10002, and 10004 bit DH to find the exact place I would get the 'modulus too large' error.? But the server log reported the DH parameters being 10008 instead.? I did a test at 15104 that gave the same error but then I tried two more times and the client just sat at the 'initial packet point' like it does with the 16384 bit parameters.? So somewhere between 13824 and 16384 it switches between the error above and just sitting there 'frozen'. Questions: 1. Can the modulus error be cured?? 2. Do you think the same modulus error is going on when the client appears to freeze with parameters larger than 13824 or is something else going (i.e. why does it freeze instead of giving the 'modulus error')?? 3. Why does the server log report 10001, 10002, 10004 bit DH as 10008? From naynjain at in.ibm.com Tue Apr 28 14:39:25 2015 From: naynjain at in.ibm.com (Nayna Jain) Date: Tue, 28 Apr 2015 20:09:25 +0530 Subject: [openssl-users] Generating RSA PrivateKey and PublicKey programmaticallly Message-ID: Hi all, I want to generate public and private key pair programmatically. However, I have some basic questions. The key generated using RSA_generate_key_ex is actually a key pair , having both private and public key. NOw, if I want to extract the public and private keys separately from this and want to store it in different privatekey.pem and publickey.pem file, how can I do that programmatically. Also, when openssl genrsa commandline generates the privatekey.pem, does it has only private key or also publickey Thanks & Regards, Nayna Jain -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Apr 28 14:49:03 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 28 Apr 2015 14:49:03 +0000 Subject: [openssl-users] Generating RSA PrivateKey and PublicKey programmaticallly In-Reply-To: References: Message-ID: A pair means two. An RSA keypair is two keys, the public key and the private key. You cannot have one without the other, and you cannot generate them separately. You can, of course, store and use them separately, and must do so. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Apr 28 14:59:06 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 28 Apr 2015 15:59:06 +0100 Subject: [openssl-users] Generating RSA PrivateKey and PublicKey programmaticallly In-Reply-To: References: Message-ID: <553FA03A.8020502@openssl.org> On 28/04/15 15:39, Nayna Jain wrote: > Hi all, > > I want to generate public and private key pair programmatically. > > However, I have some basic questions. > > The key generated using RSA_generate_key_ex is actually a key pair , > having both private and public key. > NOw, if I want to extract the public and private keys separately from > this and want to store it in different privatekey.pem and publickey.pem > file, how can I do that programmatically. > > Also, when openssl genrsa commandline generates the privatekey.pem, does > it has only private key or also publickey Take a look at the various PEM_write*PUBKEY() and PEM_write*PrivateKey() functions here: https://www.openssl.org/docs/crypto/pem.html Matt From bcall at apache.org Tue Apr 28 16:43:33 2015 From: bcall at apache.org (Bryan Call) Date: Tue, 28 Apr 2015 09:43:33 -0700 Subject: [openssl-users] Performance problems with OpenSSL and threading In-Reply-To: <553ACEF9.4080702@cisco.com> References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org> <5539844F.4090107@cisco.com> <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com> <553ACEF9.4080702@cisco.com> Message-ID: <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org> What do you mean by ?FIPS POST has completed?? -Bryan > On Apr 24, 2015, at 4:17 PM, John Foley wrote: > > Some of the algorithms still invoke the FIPS flavor of the algorithm even when FIPS is disabled. For example, this code is from EVP_DigestUpdate(). > > int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *data, size_t count) > { > #ifdef OPENSSL_FIPS > return FIPS_digestupdate(ctx, data, count); > #else > return ctx->update(ctx, data, count); > #endif > } > > In 1.0.1, locks 39 and 40 are: > > # define CRYPTO_LOCK_FIPS 39 > # define CRYPTO_LOCK_FIPS2 40 > > You should try adding some logic to skip the lock in your lock handler when the lock ID is 39 or 40. Again, it should be safe to not lock on these two as long as the FIPS POST has completed. > > > > On 04/24/2015 05:56 PM, Bryan Call wrote: >> In my last email I ran the benchmark on Fedora 21 (big mistake). Here are the results when running it back on the 28/56 core RHEL 6.5 server showing contention in a different place (fips). Is there a reason it would be calling into the FIPS code to get a lock of FIPS is not enabled? >> >> Contention log: >> [Apr 24 21:35:09.731] Server {0x7f5529ccd700} ERROR: contention for lock - total contention: 70662 waiting: 16 file: fips.c line: 471 type: 40 >> [Apr 24 21:35:09.732] Server {0x7f55299ca700} ERROR: contention for lock - total contention: 71605 waiting: 2 file: fips.c line: 107 type: 39 >> >> >> Line in in fips that see the contention the most: >> [bcall at bm77 trafficserver]$ grep fips.c diags.log | cut -f 19 -d ' ' | sort | uniq -c | sort -rn >> 875379 471 >> 288338 107 >> 275472 127 >> >> >> Different lock types and their contention frequency (multiple benchmarks): >> 875379 40 < - in fips.c >> 563810 39 <- also in fips.c >> 440518 1 >> 44145 18 >> 17447 2 >> 11356 10 >> 1377 19 >> 687 12 >> 532 25 >> 302 33 >> 239 9 >> 58 16 >> 40 21 >> 32 11 >> 19 3 >> 1 14 >> >> >> Code to diable FIPS and log: >> #ifdef OPENSSL_FIPS >> int mode = FIPS_mode(); >> Debug("ssl", "FIPS_mode: %d", mode); >> mode = FIPS_mode(); >> if (mode) { >> FIPS_mode_set(0); >> Debug("ssl", "FIPS_mode: %d", mode); >> } >> #endif >> >> [Apr 24 21:43:45.860] Server {0x7f7628146800} DEBUG: (ssl) FIPS_mode: 0 >> >> -Bryan >> >> >> >> >>> On Apr 24, 2015, at 10:56 AM, John Foley > wrote: >>> >>> When you create the private key given to SSL_CTX, be sure to instantiate a private key for each thread as well. If you share the same key across all threads, this can introduce contention. >>> >>> Here are the type 1 & 2 locks: >>> >>> # define CRYPTO_LOCK_ERR 1 >>> # define CRYPTO_LOCK_EX_DATA 2 >>> >>> Have you checked the OpenSSL error log to see what errors are being generated? >>> >>> Also, if you disable FIPS, does the thread contention still occur? >>> >>> >>> >>> On 04/24/2015 01:36 PM, Bryan Call wrote: >>>> We are using a single SSL_CTX across all the threads, so I will create multiple SSL_CTX per thread. I implemented dynlock callbacks yesterday, but I didn?t see them being used in the tests I did. I also added atomic counters to see what type of locks are having contention (see logs below): >>>> >>>> Most of the lock contention seems to be around type 2 and type 1 locks when calling our lock callback. In the FIPS/POST and SSL_CTX recommendations, in your previous email, what types of locks would those help with? >>>> >>>> Log output: >>>> [Apr 24 10:21:24.339] Server {0xb310000} ERROR: :178 (SSL_locking_callback)> contention for lock - total contention: 3938 waiting: 1 file: /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/ex_data.c line: 496 type: 2 >>>> [Apr 24 10:21:24.754] Server {0xb10a000} ERROR: :178 (SSL_locking_callback)> contention for lock - total contention: 1350 waiting: 1 file: /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/err/err_def.c line: 343 type: 1 >>>> >>>> >>>> -Bryan >>>> >>>> >>>> >>>> >>>>> On Apr 23, 2015, at 4:46 PM, John Foley > wrote: >>>>> >>>>> Looking at your call stack, it appears you're testing with FIPS mode enabled. There's a lock in FIPS_selftest_failed() that's used to ensure the crypto algorithms inside the FIPS boundary are not utilized until after the POST has completed and passed. Unfortunately this lock remains installed for the lifetime of the process. We've seen thread contention in this area when using OpenSSL. One work-around is to modify your handler that you pass to SSL_locking_callback() to not lock when the lock ID is CRYPTO_LOCK_FIPS. But you would only want to disable this particular lock ID after the POST has completed. >>>>> >>>>> If the above doesn't help, another item to check is whether you're instantiating an SSL_CTX for each thread. I've seen some developers use a single SSL_CTX for multiple threads. This results in a single instance of the server cert and private key being shared across all the threads. This results in thread contention on the asymmetric key operations associated with the cert and private key (e.g. RSA). Be sure that each thread instantiates it's own SSL_CTX and certificate/private key. >>>>> >>>>> Lastly, add some debugs to count the locks by lock ID in your lock handler. There are about 40 different lock IDs defined in crypto/crypto.h. You'll need to identify which lock is causing the thread contention. Once you know that, then you can look in the code to see where that lock is used and troubleshoot from there. >>>>> >>>>> >>>>> >>>>> On 04/23/2015 07:23 PM, Bryan Call wrote: >>>>>> I was running a benchmark on a 28 core (56 hyper-threaded) server that is running 84 threads in the process and I am seeing a lot of lock contention. I saw a lot of lock contention in the calls to SSL_get_error() ssl3_accept(). I am running RHEL 6.5 and openssl-1.0.1e-30.el6_6.7.x86_64. We have used SSL_locking_callback() to setup pthread mutex locks, but haven?t setup dynlocks yet. Would dynlocks help in this scenario? >>>>>> >>>>>> >>>>>> Output from perf: >>>>>> Samples: 1M of event 'cycles', Event count (approx.): 602783506611 >>>>>> - 48.04% [ET_NET 0] [kernel.kallsyms] [k] _spin_lock ? >>>>>> - _spin_lock ? >>>>>> + 48.05% futex_wait_setup ? >>>>>> + 47.79% futex_wake ? >>>>>> + 1.20% tcp_v4_rcv ? >>>>>> + 0.98% task_rq_lock ? >>>>>> + 0.64% double_lock_balance ? >>>>>> + 3.94% [ET_NET 0] libcrypto.so.1.0.1e [.] bn_mul_mont ? >>>>>> + 1.93% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_usub ? >>>>>> + 1.80% [ET_NET 0] libcrypto.so.1.0.1e [.] 0x00000000000e5200 ? >>>>>> + 1.49% [ET_NET 0] libcrypto.so.1.0.1e [.] sha256_block_data_order ? >>>>>> + 0.97% [ET_NET 0] libcrypto.so.1.0.1e [.] gcm_ghash_clmul ? >>>>>> + 0.85% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_lock ? >>>>>> + 0.84% [ET_NET 0] libcrypto.so.1.0.1e [.] aesni_ctr32_encrypt_blocks ? >>>>>> + 0.74% [ET_NET 0] libc-2.12.so [.] malloc ? >>>>>> + 0.72% [ET_NET 0] libc-2.12.so [.] memcpy ? >>>>>> + 0.57% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_mod_mul_montgomery ? >>>>>> + 0.51% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_unlock >>>>>> >>>>>> pstack of the process (only a couple of the interesting threads): >>>>>> Thread 1 (Thread 0x7f1fba151800 (LWP 1106)): >>>>>> #0 0x00007f1fbaaeb264 in __lll_lock_wait () from /lib64/libpthread.so.0 >>>>>> #1 0x00007f1fbaae6508 in _L_lock_854 () from /lib64/libpthread.so.0 >>>>>> #2 0x00007f1fbaae63d7 in pthread_mutex_lock () from /lib64/libpthread.so.0 >>>>>> #3 0x000000000072822f in SSL_locking_callback(int, int, char const*, int) () >>>>>> #4 0x00000031d2ae7f03 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>> #5 0x00000031d2ae7d8c in ?? () from /usr/lib64/libcrypto.so.10 >>>>>> #6 0x00000031d2ae80ab in ERR_get_state () from /usr/lib64/libcrypto.so.10 >>>>>> #7 0x00000031d2ae8557 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>> #8 0x00000031d2e424a9 in SSL_get_error () from /usr/lib64/libssl.so.10 >>>>>> #9 0x00000000007249ef in SSLNetVConnection::load_buffer_and_write(long, long&, long&, MIOBufferAccessor&, int&) () >>>>>> #10 0x00000000007389df in write_to_net_io(NetHandler*, UnixNetVConnection*, EThread*) () >>>>>> #11 0x0000000000738523 in write_to_net(NetHandler*, UnixNetVConnection*, EThread*) () >>>>>> #12 0x0000000000731922 in NetHandler::mainNetEvent(int, Event*) () >>>>>> #13 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >>>>>> #14 0x000000000075877a in EThread::process_event(Event*, int) () >>>>>> #15 0x0000000000758c84 in EThread::ex >>>>>> >>>>>> Thread 56 (Thread 0x7f1fb0ecd700 (LWP 1172)): >>>>>> #0 0x00007f1fbaae77d9 in pthread_mutex_unlock () from /lib64/libpthread.so.0 >>>>>> #1 0x0000000000728265 in SSL_locking_callback(int, int, char const*, int) () >>>>>> #2 0x00000031d2b57402 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>> #3 0x00000031d2b574bd in FIPS_selftest_failed () from /usr/lib64/libcrypto.so.10 >>>>>> #4 0x00000031d2ae9f1c in EVP_DigestInit_ex () from /usr/lib64/libcrypto.so.10 >>>>>> #5 0x00000031d2a7977e in HMAC_Init_ex () from /usr/lib64/libcrypto.so.10 >>>>>> #6 0x00000031d2a79c29 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>> #7 0x00000031d2af7a42 in EVP_PKEY_CTX_ctrl () from /usr/lib64/libcrypto.so.10 >>>>>> #8 0x00000031d2ae9ffb in EVP_DigestInit_ex () from /usr/lib64/libcrypto.so.10 >>>>>> #9 0x00000031d2af952a in ?? () from /usr/lib64/libcrypto.so.10 >>>>>> #10 0x00000031d2e34cf2 in tls1_PRF () from /usr/lib64/libssl.so.10 >>>>>> #11 0x00000031d2e35796 in tls1_final_finish_mac () from /usr/lib64/libssl.so.10 >>>>>> #12 0x00000031d2e2db2e in ssl3_get_message () from /usr/lib64/libssl.so.10 >>>>>> #13 0x00000031d2e1dc3c in ssl3_get_cert_verify () from /usr/lib64/libssl.so.10 >>>>>> #14 0x00000031d2e220d6 in ssl3_accept () from /usr/lib64/libssl.so.10 >>>>>> #15 0x0000000000725287 in SSLNetVConnection::sslServerHandShakeEvent(int&) () >>>>>> #16 0x00000000007251b3 in SSLNetVConnection::sslStartHandShake(int, int&) () >>>>>> #17 0x0000000000723df3 in SSLNetVConnection::net_read_io(NetHandler*, EThread*) () >>>>>> #18 0x0000000000731852 in NetHandler::mainNetEvent(int, Event*) () >>>>>> #19 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >>>>>> #20 0x000000000075877a in EThread::process_event(Event*, int) () >>>>>> #21 0x0000000000758c84 in EThread::execute() () >>>>>> #22 0x0000000000757cf8 in spawn_thread_internal(void*) () >>>>>> #23 0x00007f1fbaae49d1 in start_thread () from /lib64/libpthread.so.0 >>>>>> #24 0x00000030ff0e88fd in clone () from /lib64/libc.so.6 >>>>>> >>>>>> -Bryan >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> openssl-users mailing list >>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>>> >>>>> _______________________________________________ >>>>> openssl-users mailing list >>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>> >>>> >>>> >>>> _______________________________________________ >>>> openssl-users mailing list >>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> >>> _______________________________________________ >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From foleyj at cisco.com Tue Apr 28 17:22:24 2015 From: foleyj at cisco.com (John Foley) Date: Tue, 28 Apr 2015 13:22:24 -0400 Subject: [openssl-users] Performance problems with OpenSSL and threading In-Reply-To: <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org> References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org> <5539844F.4090107@cisco.com> <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com> <553ACEF9.4080702@cisco.com> <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org> Message-ID: <553FC1D0.9090302@cisco.com> In the context of OpenSSL 1.0.1 or 1.0.2, this means FIPS_mode_set(1) has returned with a successful return value. In the future, this may change if/when OpenSSL does another FIPS validation. CMVP has changed the implementation guidance that requires the POST to run automatically without user intervention. Any future FIPS validations would be subject to the new rules. Hence, the behavior of FIPS_mode_set() may change in the future if OpenSSL decides to pursue another validation. On 04/28/2015 12:43 PM, Bryan Call wrote: > What do you mean by ?FIPS POST has completed?? > > -Bryan > > > > >> On Apr 24, 2015, at 4:17 PM, John Foley > > wrote: >> >> Some of the algorithms still invoke the FIPS flavor of the algorithm >> even when FIPS is disabled. For example, this code is from >> EVP_DigestUpdate(). >> >> int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *data, size_t count) >> { >> #ifdef OPENSSL_FIPS >> return FIPS_digestupdate(ctx, data, count); >> #else >> return ctx->update(ctx, data, count); >> #endif >> } >> >> In 1.0.1, locks 39 and 40 are: >> >> # define CRYPTO_LOCK_FIPS 39 >> # define CRYPTO_LOCK_FIPS2 40 >> >> You should try adding some logic to skip the lock in your lock >> handler when the lock ID is 39 or 40. Again, it should be safe to not >> lock on these two as long as the FIPS POST has completed. >> >> >> >> On 04/24/2015 05:56 PM, Bryan Call wrote: >>> In my last email I ran the benchmark on Fedora 21 (big mistake). >>> Here are the results when running it back on the 28/56 core RHEL 6.5 >>> server showing contention in a different place (fips). Is there a >>> reason it would be calling into the FIPS code to get a lock of FIPS >>> is not enabled? >>> >>> Contention log: >>> [Apr 24 21:35:09.731] Server {0x7f5529ccd700} ERROR: contention for >>> lock - total contention: 70662 waiting: 16 file: fips.c line: 471 >>> type: 40 >>> [Apr 24 21:35:09.732] Server {0x7f55299ca700} ERROR: contention for >>> lock - total contention: 71605 waiting: 2 file: fips.c line: 107 >>> type: 39 >>> >>> >>> Line in in fips that see the contention the most: >>> [bcall at bm77 trafficserver]$ grep fips.c diags.log | cut -f 19 -d ' ' >>> | sort | uniq -c | sort -rn >>> 875379 471 >>> 288338 107 >>> 275472 127 >>> >>> >>> Different lock types and their contention frequency (multiple >>> benchmarks): >>> 875379 40 < - in fips.c >>> 563810 39 <- also in fips.c >>> 440518 1 >>> 44145 18 >>> 17447 2 >>> 11356 10 >>> 1377 19 >>> 687 12 >>> 532 25 >>> 302 33 >>> 239 9 >>> 58 16 >>> 40 21 >>> 32 11 >>> 19 3 >>> 1 14 >>> >>> >>> Code to diable FIPS and log: >>> #ifdef OPENSSL_FIPS >>> int mode = FIPS_mode(); >>> Debug("ssl", "FIPS_mode: %d", mode); >>> mode = FIPS_mode(); >>> if (mode) { >>> FIPS_mode_set(0); >>> Debug("ssl", "FIPS_mode: %d", mode); >>> } >>> #endif >>> >>> [Apr 24 21:43:45.860] Server {0x7f7628146800} DEBUG: (ssl) FIPS_mode: 0 >>> >>> -Bryan >>> >>> >>> >>> >>>> On Apr 24, 2015, at 10:56 AM, John Foley >>> > wrote: >>>> >>>> When you create the private key given to SSL_CTX, be sure to >>>> instantiate a private key for each thread as well. If you share >>>> the same key across all threads, this can introduce contention. >>>> >>>> Here are the type 1 & 2 locks: >>>> >>>> # define CRYPTO_LOCK_ERR 1 >>>> # define CRYPTO_LOCK_EX_DATA 2 >>>> >>>> Have you checked the OpenSSL error log to see what errors are being >>>> generated? >>>> >>>> Also, if you disable FIPS, does the thread contention still occur? >>>> >>>> >>>> >>>> On 04/24/2015 01:36 PM, Bryan Call wrote: >>>>> We are using a single SSL_CTX across all the threads, so I will >>>>> create multiple SSL_CTX per thread. I implemented dynlock >>>>> callbacks yesterday, but I didn?t see them being used in the tests >>>>> I did. I also added atomic counters to see what type of locks are >>>>> having contention (see logs below): >>>>> >>>>> Most of the lock contention seems to be around type 2 and type 1 >>>>> locks when calling our lock callback. In the FIPS/POST and >>>>> SSL_CTX recommendations, in your previous email, what types of >>>>> locks would those help with? >>>>> >>>>> Log output: >>>>> [Apr 24 10:21:24.339] Server {0xb310000} ERROR: >>>> :178 (SSL_locking_callback)> contention for >>>>> lock - total contention: 3938 waiting: 1 file: >>>>> /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/ex_data.c >>>>> line: 496 type: 2 >>>>> [Apr 24 10:21:24.754] Server {0xb10a000} ERROR: >>>> :178 (SSL_locking_callback)> contention for >>>>> lock - total contention: 1350 waiting: 1 file: >>>>> /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/err/err_def.c line: >>>>> 343 type: 1 >>>>> >>>>> >>>>> -Bryan >>>>> >>>>> >>>>> >>>>> >>>>>> On Apr 23, 2015, at 4:46 PM, John Foley >>>>> > wrote: >>>>>> >>>>>> Looking at your call stack, it appears you're testing with FIPS >>>>>> mode enabled. There's a lock in FIPS_selftest_failed() that's >>>>>> used to ensure the crypto algorithms inside the FIPS boundary are >>>>>> not utilized until after the POST has completed and passed. >>>>>> Unfortunately this lock remains installed for the lifetime of the >>>>>> process. We've seen thread contention in this area when using >>>>>> OpenSSL. One work-around is to modify your handler that you pass >>>>>> to SSL_locking_callback() to not lock when the lock ID is >>>>>> CRYPTO_LOCK_FIPS. But you would only want to disable this >>>>>> particular lock ID after the POST has completed. >>>>>> >>>>>> If the above doesn't help, another item to check is whether >>>>>> you're instantiating an SSL_CTX for each thread. I've seen some >>>>>> developers use a single SSL_CTX for multiple threads. This >>>>>> results in a single instance of the server cert and private key >>>>>> being shared across all the threads. This results in thread >>>>>> contention on the asymmetric key operations associated with the >>>>>> cert and private key (e.g. RSA). Be sure that each thread >>>>>> instantiates it's own SSL_CTX and certificate/private key. >>>>>> >>>>>> Lastly, add some debugs to count the locks by lock ID in your >>>>>> lock handler. There are about 40 different lock IDs defined in >>>>>> crypto/crypto.h. You'll need to identify which lock is causing >>>>>> the thread contention. Once you know that, then you can look in >>>>>> the code to see where that lock is used and troubleshoot from there. >>>>>> >>>>>> >>>>>> >>>>>> On 04/23/2015 07:23 PM, Bryan Call wrote: >>>>>>> I was running a benchmark on a 28 core (56 hyper-threaded) >>>>>>> server that is running 84 threads in the process and I am seeing >>>>>>> a lot of lock contention. I saw a lot of lock contention in the >>>>>>> calls to SSL_get_error() ssl3_accept(). I am running RHEL 6.5 >>>>>>> and openssl-1.0.1e-30.el6_6.7.x86_64. We have >>>>>>> used SSL_locking_callback() to setup pthread mutex locks, but >>>>>>> haven?t setup dynlocks yet. Would dynlocks help in this scenario? >>>>>>> >>>>>>> >>>>>>> Output from perf: >>>>>>> Samples: 1M of event 'cycles', Event count (approx.): 602783506611 >>>>>>> - 48.04% [ET_NET 0] [kernel.kallsyms] [k] _spin_lock ? >>>>>>> - _spin_lock ? >>>>>>> >>>>>>> * + 48.05% futex_wait_setup ? >>>>>>> * + 47.79% futex_wake ? >>>>>>> * + 1.20% tcp_v4_rcv ? >>>>>>> * + 0.98% task_rq_lock ? >>>>>>> * + 0.64% double_lock_balance ? >>>>>>> >>>>>>> + 3.94% [ET_NET 0] libcrypto.so.1.0.1e [.] bn_mul_mont ? >>>>>>> + 1.93% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_usub ? >>>>>>> + 1.80% [ET_NET 0] libcrypto.so.1.0.1e [.] 0x00000000000e5200 ? >>>>>>> + 1.49% [ET_NET 0] libcrypto.so.1.0.1e [.] sha256_block_data_order ? >>>>>>> + 0.97% [ET_NET 0] libcrypto.so.1.0.1e [.] gcm_ghash_clmul ? >>>>>>> + 0.85% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_lock ? >>>>>>> + 0.84% [ET_NET 0] libcrypto.so.1.0.1e [.] >>>>>>> aesni_ctr32_encrypt_blocks ? >>>>>>> + 0.74% [ET_NET 0] libc-2.12.so [.] malloc ? >>>>>>> + 0.72% [ET_NET 0] libc-2.12.so [.] memcpy ? >>>>>>> + 0.57% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_mod_mul_montgomery ? >>>>>>> + 0.51% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_unlock >>>>>>> >>>>>>> pstack of the process (only a couple of the interesting threads): >>>>>>> Thread 1 (Thread 0x7f1fba151800 (LWP 1106)): >>>>>>> #0 0x00007f1fbaaeb264 in __lll_lock_wait () from >>>>>>> /lib64/libpthread.so.0 >>>>>>> #1 0x00007f1fbaae6508 in _L_lock_854 () from /lib64/libpthread.so.0 >>>>>>> #2 0x00007f1fbaae63d7 in pthread_mutex_lock () from >>>>>>> /lib64/libpthread.so.0 >>>>>>> #3 0x000000000072822f in SSL_locking_callback(int, int, char >>>>>>> const*, int) () >>>>>>> #4 0x00000031d2ae7f03 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>> #5 0x00000031d2ae7d8c in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>> #6 0x00000031d2ae80ab in ERR_get_state () from >>>>>>> /usr/lib64/libcrypto.so.10 >>>>>>> #7 0x00000031d2ae8557 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>> #8 0x00000031d2e424a9 in SSL_get_error () from >>>>>>> /usr/lib64/libssl.so.10 >>>>>>> #9 0x00000000007249ef in >>>>>>> SSLNetVConnection::load_buffer_and_write(long, long&, long&, >>>>>>> MIOBufferAccessor&, int&) () >>>>>>> #10 0x00000000007389df in write_to_net_io(NetHandler*, >>>>>>> UnixNetVConnection*, EThread*) () >>>>>>> #11 0x0000000000738523 in write_to_net(NetHandler*, >>>>>>> UnixNetVConnection*, EThread*) () >>>>>>> #12 0x0000000000731922 in NetHandler::mainNetEvent(int, Event*) () >>>>>>> #13 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >>>>>>> #14 0x000000000075877a in EThread::process_event(Event*, int) () >>>>>>> #15 0x0000000000758c84 in EThread::ex >>>>>>> >>>>>>> Thread 56 (Thread 0x7f1fb0ecd700 (LWP 1172)): >>>>>>> #0 0x00007f1fbaae77d9 in pthread_mutex_unlock () from >>>>>>> /lib64/libpthread.so.0 >>>>>>> #1 0x0000000000728265 in SSL_locking_callback(int, int, char >>>>>>> const*, int) () >>>>>>> #2 0x00000031d2b57402 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>> #3 0x00000031d2b574bd in FIPS_selftest_failed () from >>>>>>> /usr/lib64/libcrypto.so.10 >>>>>>> #4 0x00000031d2ae9f1c in EVP_DigestInit_ex () from >>>>>>> /usr/lib64/libcrypto.so.10 >>>>>>> #5 0x00000031d2a7977e in HMAC_Init_ex () from >>>>>>> /usr/lib64/libcrypto.so.10 >>>>>>> #6 0x00000031d2a79c29 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>> #7 0x00000031d2af7a42 in EVP_PKEY_CTX_ctrl () from >>>>>>> /usr/lib64/libcrypto.so.10 >>>>>>> #8 0x00000031d2ae9ffb in EVP_DigestInit_ex () from >>>>>>> /usr/lib64/libcrypto.so.10 >>>>>>> #9 0x00000031d2af952a in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>> #10 0x00000031d2e34cf2 in tls1_PRF () from /usr/lib64/libssl.so.10 >>>>>>> #11 0x00000031d2e35796 in tls1_final_finish_mac () from >>>>>>> /usr/lib64/libssl.so.10 >>>>>>> #12 0x00000031d2e2db2e in ssl3_get_message () from >>>>>>> /usr/lib64/libssl.so.10 >>>>>>> #13 0x00000031d2e1dc3c in ssl3_get_cert_verify () from >>>>>>> /usr/lib64/libssl.so.10 >>>>>>> #14 0x00000031d2e220d6 in ssl3_accept () from >>>>>>> /usr/lib64/libssl.so.10 >>>>>>> #15 0x0000000000725287 in >>>>>>> SSLNetVConnection::sslServerHandShakeEvent(int&) () >>>>>>> #16 0x00000000007251b3 in >>>>>>> SSLNetVConnection::sslStartHandShake(int, int&) () >>>>>>> #17 0x0000000000723df3 in >>>>>>> SSLNetVConnection::net_read_io(NetHandler*, EThread*) () >>>>>>> #18 0x0000000000731852 in NetHandler::mainNetEvent(int, Event*) () >>>>>>> #19 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >>>>>>> #20 0x000000000075877a in EThread::process_event(Event*, int) () >>>>>>> #21 0x0000000000758c84 in EThread::execute() () >>>>>>> #22 0x0000000000757cf8 in spawn_thread_internal(void*) () >>>>>>> #23 0x00007f1fbaae49d1 in start_thread () from >>>>>>> /lib64/libpthread.so.0 >>>>>>> #24 0x00000030ff0e88fd in clone () from /lib64/libc.so.6 >>>>>>> >>>>>>> -Bryan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> openssl-users mailing list >>>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>>>> >>>>>> _______________________________________________ >>>>>> openssl-users mailing list >>>>>> To unsubscribe: >>>>>> https://mta.openssl.org/mailman/listinfo/openssl-users >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> openssl-users mailing list >>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>> >>>> _______________________________________________ >>>> openssl-users mailing list >>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> >>> >>> >>> _______________________________________________ >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From newcomer83 at web.de Tue Apr 28 17:49:51 2015 From: newcomer83 at web.de (Alexander) Date: Tue, 28 Apr 2015 19:49:51 +0200 Subject: [openssl-users] How do I uninitialize OpenSSL properly? In-Reply-To: <553D2B19.1080405@web.de> References: <553CFAA0.6060201@web.de> <553D2B19.1080405@web.de> Message-ID: <553FC83F.9010206@web.de> Unfortunately this didn't solve my problem, but at least I narrowed it down. The leaks are caused by my call to "SSL_CTX_load_verify_locations", which is essentially "X509_STORE_load_locations". I found that function in x509_d2.c and I find it suspicious that this function invokes exactly 4 function calls and leads to 4 memory leaks. Therefore I assume that I need to undo all of these function calls when exiting, which are: - 2x X509_STORE_add_lookup - 1x X509_LOOKUP_load_file - 1x X509_LOOKUP_add_dir How can I clean up everything those 4 functions allocate? Cheers Alex Am 26.04.2015 um 20:14 schrieb Alexander: > Thanks for the quick reply! I'm sorry, I didn't mean to sound impatient. > It's just that I read through the archives and so much has been > happening that I was afraid that my thread would be swamped away unnoticed. > > My problem is most likely an on process exit thing, because I do the > certificate stuff only once, no matter how long the application is > running. Therefore it's probably not a big problem, but memory leaks > look bad, because they imply that I am using OpenSSL improperly. > > Anyway, thanks for the advice on apps_startup and apps_shutdown. I will > try them out as soon as I can. Those defines do look like salvation from > all the problems I had finding the right methods to > initialize/uninitialize OpenSSL properly. > > Have a happy rest of Sunday! > > Cheers > Alex > > Am 26.04.2015 um 18:33 schrieb Salz, Rich: >> This isn't paid support; two days isn't a long time to wait :) >> >> Is this on process exit? If so, does it really matter? >> >> You might look at the apps_startup and apps_shutdown functions in apps/openssl.c on the master branch. >> >> /r$ >> >> -- >> Senior Architect, Akamai Technologies >> IM: richsalz at jabber.at Twitter: RichSalz >> >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From rsalz at akamai.com Tue Apr 28 18:06:37 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 28 Apr 2015 18:06:37 +0000 Subject: [openssl-users] How do I uninitialize OpenSSL properly? In-Reply-To: <553FC83F.9010206@web.de> References: <553CFAA0.6060201@web.de> <553D2B19.1080405@web.de> <553FC83F.9010206@web.de> Message-ID: <054704bd6a5a4a8a991e802dd8102e7c@usma1ex-dag1mb4.msg.corp.akamai.com> > Unfortunately this didn't solve my problem, but at least I narrowed it down. > The leaks are caused by my call to "SSL_CTX_load_verify_locations", which is > essentially "X509_STORE_load_locations". Doesn't freeing the SSL_CTX_free release that data? If not, please file an RT ticket. From jonetsu at teksavvy.com Tue Apr 28 17:53:01 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Tue, 28 Apr 2015 10:53:01 -0700 (MST) Subject: [openssl-users] SHA256() to EVP_* ? Message-ID: <1430243581216-57774.post@n7.nabble.com> Hello, What would be the equivalent of the SHA256() function in the EVP class of methods ? EVP_sha256() could be it, although from the short description in manual page it does not seemingly fit in, returning a EVP_MD which is, if not mistaken, a env_md_st structure. The code I'm adapting to EVP has a first pass of shortening the key if too long: /* Change key if longer than 64 bytes */ if (klen > HMAC_INT_LEN) { SHA256(key, klen, nkey); key = nkey; klen = SHA256_DIGEST_LENGTH; } Before proceeding with the usual SHA256_Init(), SHA256_Update() (twice), and SHA256_Final. All of which I have tested with the corresponding EVP_* methods. For the use of SHA256() above, though, I'm puzzled regarding its EVP_* counterpart. Suggestions, comments appreciated. Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/SHA256-to-EVP-tp57774.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From newcomer83 at web.de Tue Apr 28 18:18:10 2015 From: newcomer83 at web.de (Alexander) Date: Tue, 28 Apr 2015 20:18:10 +0200 Subject: [openssl-users] How do I uninitialize OpenSSL properly? In-Reply-To: <054704bd6a5a4a8a991e802dd8102e7c@usma1ex-dag1mb4.msg.corp.akamai.com> References: <553CFAA0.6060201@web.de> <553D2B19.1080405@web.de> <553FC83F.9010206@web.de> <054704bd6a5a4a8a991e802dd8102e7c@usma1ex-dag1mb4.msg.corp.akamai.com> Message-ID: <553FCEE2.6050003@web.de> Am 28.04.2015 um 20:06 schrieb Salz, Rich: >> Unfortunately this didn't solve my problem, but at least I narrowed it down. >> The leaks are caused by my call to "SSL_CTX_load_verify_locations", which is >> essentially "X509_STORE_load_locations". > > Doesn't freeing the SSL_CTX_free release that data? If not, please file an RT ticket. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > I am using that command to free my ctx pointer. I think I don't have the rights to file a ticket (but I could be wrong, because I have never been to https://rt.openssl.org/ before, much less filed a ticket). I basically just clicked the button for creating a new ticket and it told me that this area couldn't be loaded. From secaficionado at gmail.com Tue Apr 28 19:44:40 2015 From: secaficionado at gmail.com (Sec_Aficionado) Date: Tue, 28 Apr 2015 15:44:40 -0400 Subject: [openssl-users] FIPS 140-2 on iOS Message-ID: <53D633FE-3DCA-4C7B-ACF7-031F9B8C0116@gmail.com> Hi there, Total n00b question here. I recently ran across a question on an iOS forum where someone was building an app with FIPS 140-2 compliant communications. Now, from reading here (mailing lists) about FIPS certification, it involves both the bits and the platform. So it would not be possible to create an app that is compliant on a platform that hasn't been certified. Is that a correct assumption? Or can I build a compliant app with just certified libraries? Thanks! Sent from my mobile I may have missed some "autocorrections" From quentin.gouchet at gmail.com Tue Apr 28 20:16:24 2015 From: quentin.gouchet at gmail.com (Q Gct) Date: Tue, 28 Apr 2015 20:16:24 +0000 Subject: [openssl-users] FIPS 140-2 on iOS In-Reply-To: <53D633FE-3DCA-4C7B-ACF7-031F9B8C0116@gmail.com> References: <53D633FE-3DCA-4C7B-ACF7-031F9B8C0116@gmail.com> Message-ID: Hi, I believe you can make an app that is FIPS compliant: since OpenSSL can be made FIPS compliant on a non-validated OS, why not an app on iOS? But it will be FIPS compliant, not FIPS validated app. Le mar. 28 avr. 2015 21:45, Sec_Aficionado a ?crit : > Hi there, > > Total n00b question here. I recently ran across a question on an iOS forum > where someone was building an app with FIPS 140-2 compliant communications. > > Now, from reading here (mailing lists) about FIPS certification, it > involves both the bits and the platform. So it would not be possible to > create an app that is compliant on a platform that hasn't been certified. > Is that a correct assumption? Or can I build a compliant app with just > certified libraries? > > Thanks! > > Sent from my mobile > I may have missed some "autocorrections" > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Tue Apr 28 20:31:41 2015 From: marquess at openssl.com (Steve Marquess) Date: Tue, 28 Apr 2015 16:31:41 -0400 Subject: [openssl-users] FIPS 140-2 on iOS In-Reply-To: <53D633FE-3DCA-4C7B-ACF7-031F9B8C0116@gmail.com> References: <53D633FE-3DCA-4C7B-ACF7-031F9B8C0116@gmail.com> Message-ID: <553FEE2D.70509@openssl.com> On 04/28/2015 03:44 PM, Sec_Aficionado wrote: > Hi there, > > Total n00b question here. I recently ran across a question on an iOS > forum where someone was building an app with FIPS 140-2 compliant > communications. Note there really is no such thing as "FIPS 140-2 compliant" (though you see that terms bandied around a lot and I'm guilty of doing so myself). The term of interest is "FISP 140-2 validated" (n.b.: that's "validated" not "certified"). > Now, from reading here (mailing lists) about FIPS certification, it > involves both the bits and the platform. So it would not be possible > to create an app that is compliant on a platform that hasn't been > certified. Is that a correct assumption? Or can I build a compliant > app with just certified libraries? A Level 1 FIPS 140-2 validation (Level 1 being the most common and the "easiest") applies to a thing called a "cryptographic module" in the context of one of more "OEs" or "Operational Environments" (loosely speaking, "platforms"). Note at Level 1 products are not validated, operating systems are not validated, only "cryptographic modules" are validated. Translated from FIPSspeak, for a software "module" that means a very specific chunk of executable code running on a specific platform (operating system and OS version and processor "architecture"). Move that same code to another platform and it is no longer validated; the validation is relative to the OEs or platforms. The only valid reason to use a FIPS 140-2 validated module is that you must in order to sell your cryptography-using product to the USG or DoD. For that market you (typically, if the procurement officer is paying attention) have to use a validated cryptographic module on one of the OEs specifically listed for that module validation. So for a software product there is no such thing as validation of the product independent of the platform (OE) it runs on. A partial exception to that rule is "user affirmation" per I.G. G.5, but while technically a legitimate means of satisfying FISP 140-2 validation requirements that has limited practical value in the USG/DoD market. Note I'm only discussing Level 1 validations here; Levels 2 and up are different. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From naynjain at in.ibm.com Tue Apr 28 21:10:50 2015 From: naynjain at in.ibm.com (Nayna Jain) Date: Wed, 29 Apr 2015 02:40:50 +0530 Subject: [openssl-users] Generating RSA PrivateKey and PublicKey programmaticallly In-Reply-To: <553FA03A.8020502@openssl.org> References: <553FA03A.8020502@openssl.org> Message-ID: Is there any other way to store private key and public key rather than in PEM format in file ? I mean API to store public and private key separately in memory. Thanks & Regards, Nayna Jain From: Matt Caswell To: openssl-users at openssl.org Date: 04/28/2015 08:29 PM Subject: Re: [openssl-users] Generating RSA PrivateKey and PublicKey programmaticallly Sent by: "openssl-users" On 28/04/15 15:39, Nayna Jain wrote: > Hi all, > > I want to generate public and private key pair programmatically. > > However, I have some basic questions. > > The key generated using RSA_generate_key_ex is actually a key pair , > having both private and public key. > NOw, if I want to extract the public and private keys separately from > this and want to store it in different privatekey.pem and publickey.pem > file, how can I do that programmatically. > > Also, when openssl genrsa commandline generates the privatekey.pem, does > it has only private key or also publickey Take a look at the various PEM_write*PUBKEY() and PEM_write*PrivateKey() functions here: https://www.openssl.org/docs/crypto/pem.html Matt _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From matt at openssl.org Tue Apr 28 21:40:27 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 28 Apr 2015 22:40:27 +0100 Subject: [openssl-users] Generating RSA PrivateKey and PublicKey programmaticallly In-Reply-To: References: <553FA03A.8020502@openssl.org> Message-ID: <553FFE4B.9020402@openssl.org> On 28/04/15 22:10, Nayna Jain wrote: > Is there any other way to store private key and public key rather than > in PEM format in file ? > > I mean API to store public and private key separately in memory. You mean like this: https://www.openssl.org/docs/crypto/d2i_RSAPublicKey Matt From noloader at gmail.com Tue Apr 28 23:57:55 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 28 Apr 2015 19:57:55 -0400 Subject: [openssl-users] Performance problems with OpenSSL and threading In-Reply-To: <553FC1D0.9090302@cisco.com> References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org> <5539844F.4090107@cisco.com> <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com> <553ACEF9.4080702@cisco.com> <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org> <553FC1D0.9090302@cisco.com> Message-ID: > In the future, this may change if/when OpenSSL does another FIPS validation. > CMVP has changed the implementation guidance that requires the POST to run > automatically without user intervention. Any future FIPS validations would > be subject to the new rules. Hence, the behavior of FIPS_mode_set() may > change in the future if OpenSSL decides to pursue another validation. > Ouch! It was bad enough when they pounded the square hardware peg into a round software hole. I see they lack practical experience in software development, so now they are forcing folks into doing things that can be questionable (and even ill-advised on a platform). From dthompson at prinpay.com Wed Apr 29 00:29:44 2015 From: dthompson at prinpay.com (Dave Thompson) Date: Tue, 28 Apr 2015 20:29:44 -0400 Subject: [openssl-users] SHA256() to EVP_* ? In-Reply-To: <1430243581216-57774.post@n7.nabble.com> References: <1430243581216-57774.post@n7.nabble.com> Message-ID: <006001d08213$99561750$cc0245f0$@prinpay.com> > From: openssl-users On Behalf Of jonetsu > Sent: Tuesday, April 28, 2015 13:53 > What would be the equivalent of the SHA256() function in the EVP > class of methods ? EVP_sha256() could be it, although from the > short description in manual page it does not seemingly fit in, > returning a EVP_MD which is, if not mistaken, a env_md_st > structure. > The LOWLEVEL modules use separate routines. There are routines for SHA1, and *separate* routines for SHA256, and separate routines for SHA384, and separate routines for MD5, and separate routines for RIPEMD160. There are routines for AES, and separate routines for RC4, and separate routines for Blowfish, and routines for DES and "tripleDES" aka DESede that overlap *some* because of the very close relationship but separate from all other symmetric ciphers. There are routines for RSA, and separate routines for DSA, and separate routines for DH, and separate routines for ECDSA, and separate routines for ECDH. EVP DOES NOT. EVP has *one* set of digest routines used for ALL digest algorithms, but with a data object specifying *which* digest. EVP has *one* set of Cipher routines used for all symmetric ciphers, with a data object specifying which. EVP has due to history *two* sets of asymmetric signature routines, which apply to three (and possibly more) asymmetric algorithms specified by data objects. Thus the EVP equivalent to the SHA256*() lowlevel calls is to call the EVP_Digest* routines with a data object specifying SHA256, which is exactly what the value of EVP_sha256() is. The man page named for EVP_DigestInit which also covers EVP_DigestInit_ex, EVP_DigestUpdate, EVP_DigestFinal, EVP_DigestFinal_ex, and some related routines (although the link for EVP_DigestFinal original seems to be missing) tells you how to do digests with EVP in general. Apparently it wasn't updated to list SHA2 digests, but that variation should be obvious from documented pattern. > The code I'm adapting to EVP has a first pass of shortening the > key if too long: > > /* Change key if longer than 64 bytes */ > if (klen > HMAC_INT_LEN) { > SHA256(key, klen, nkey); > key = nkey; > klen = SHA256_DIGEST_LENGTH; > } > > Before proceeding with the usual SHA256_Init(), > SHA256_Update() (twice), and SHA256_Final. All of which I have > tested with the corresponding EVP_* methods. For the use of > SHA256() above, though, I'm puzzled regarding its EVP_* > counterpart. > If you are implementing HMAC, perhaps for PBKDF2 (which does that prehash-if-too-long), I hope you mean the code does one hash of ipad+data, which can consist of Init, 2 Updates, and Finial (although there are other ways) and then a SECOND ENTIRE HASH of opad+innerhash, similarly. If that's not what you're doing, you're not doing standard HMAC, so it definitely won't be interoperable and may well not be secure, because HMAC was defined the way it is precisely because it was found the na?ve way merely hashing key+data is not reliably secure. Although if what you want is PBKDF2-HMAC, there is already two OpenSSL routines for that (again due to history). From formailerlist at gmail.com Wed Apr 29 05:19:51 2015 From: formailerlist at gmail.com (Mailer Mailer) Date: Tue, 28 Apr 2015 22:19:51 -0700 Subject: [openssl-users] NID_Name equivalent in a certificate Message-ID: Hi, Can some one let me know what is the equivalent field in a certifcate that maps to NID_Name? Thank you, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From erwann.abalea at opentrust.com Wed Apr 29 08:05:52 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Wed, 29 Apr 2015 10:05:52 +0200 Subject: [openssl-users] NID_Name equivalent in a certificate In-Reply-To: References: Message-ID: <554090E0.1000301@opentrust.com> Bonjour, NID_name correspond to the OID id-at-name. There's no "equivalent field in a certificate" that maps to an OID. The OID id-at-name designs the attribute supertype "name", which shouldn't be present in a certificate, but can nevertheless be present. Anywhere. -- Erwann ABALEA Le 29/04/2015 07:19, Mailer Mailer a ?crit : > Hi, > > Can some one let me know what is the equivalent field in a certifcate > that maps to NID_Name? > > Thank you, > Tom > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonetsu at teksavvy.com Wed Apr 29 14:07:17 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Wed, 29 Apr 2015 07:07:17 -0700 (MST) Subject: [openssl-users] SHA256() to EVP_* ? In-Reply-To: <006001d08213$99561750$cc0245f0$@prinpay.com> References: <1430243581216-57774.post@n7.nabble.com> <006001d08213$99561750$cc0245f0$@prinpay.com> Message-ID: <1430316437144-57791.post@n7.nabble.com> Thanks for the comments. > If you are implementing HMAC, perhaps for PBKDF2 (which does > that prehash-if-too-long), I hope you mean the code does... Yes it does. The man page (the one online from OpenSSL project - SHA256.html) gives a description using SHA1() which computes a message digest. Being generally new to OpenSSL at that level, what is then the difference between using, say, SHA1() vs. using SHA1_Init, SHA1_Update and SHA1_Final ? Is it only that the latter allows for continuously add data until _Final is called ? -- View this message in context: http://openssl.6102.n7.nabble.com/SHA256-to-EVP-tp57774p57791.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From secaficionado at gmail.com Wed Apr 29 14:30:23 2015 From: secaficionado at gmail.com (Sec_Aficionado) Date: Wed, 29 Apr 2015 10:30:23 -0400 Subject: [openssl-users] FIPS 140-2 on iOS In-Reply-To: <553FEE2D.70509@openssl.com> References: <53D633FE-3DCA-4C7B-ACF7-031F9B8C0116@gmail.com> <553FEE2D.70509@openssl.com> Message-ID: This is an excellent explanation in plain English. Thank you! > On Apr 28, 2015, at 4:31 PM, Steve Marquess wrote: > >> On 04/28/2015 03:44 PM, Sec_Aficionado wrote: >> Hi there, >> >> Total n00b question here. I recently ran across a question on an iOS >> forum where someone was building an app with FIPS 140-2 compliant >> communications. > > Note there really is no such thing as "FIPS 140-2 compliant" (though you > see that terms bandied around a lot and I'm guilty of doing so myself). > > The term of interest is "FISP 140-2 validated" (n.b.: that's "validated" > not "certified"). > >> Now, from reading here (mailing lists) about FIPS certification, it >> involves both the bits and the platform. So it would not be possible >> to create an app that is compliant on a platform that hasn't been >> certified. Is that a correct assumption? Or can I build a compliant >> app with just certified libraries? > > A Level 1 FIPS 140-2 validation (Level 1 being the most common and the > "easiest") applies to a thing called a "cryptographic module" in the > context of one of more "OEs" or "Operational Environments" (loosely > speaking, "platforms"). Note at Level 1 products are not validated, > operating systems are not validated, only "cryptographic modules" are > validated. > > Translated from FIPSspeak, for a software "module" that means a very > specific chunk of executable code running on a specific platform > (operating system and OS version and processor "architecture"). Move > that same code to another platform and it is no longer validated; the > validation is relative to the OEs or platforms. > > The only valid reason to use a FIPS 140-2 validated module is that you > must in order to sell your cryptography-using product to the USG or DoD. > For that market you (typically, if the procurement officer is paying > attention) have to use a validated cryptographic module on one of the > OEs specifically listed for that module validation. > > So for a software product there is no such thing as validation of the > product independent of the platform (OE) it runs on. > > A partial exception to that rule is "user affirmation" per I.G. G.5, but > while technically a legitimate means of satisfying FISP 140-2 validation > requirements that has limited practical value in the USG/DoD market. > > Note I'm only discussing Level 1 validations here; Levels 2 and up are > different. > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation, Inc. > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at opensslfoundation.com > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From graeme.perrow at sap.com Wed Apr 29 15:42:40 2015 From: graeme.perrow at sap.com (Perrow, Graeme) Date: Wed, 29 Apr 2015 15:42:40 +0000 Subject: [openssl-users] Can RSA_private_decrypt succeed with the wrong padding? In-Reply-To: <20150425054104.GM25758@mournblade.imrryr.org> References: <6378BFFB8601BD438AD9AF3CA610548E59B059FB@DEWDFEMB16B.global.corp.sap> <20150425054104.GM25758@mournblade.imrryr.org> Message-ID: <6378BFFB8601BD438AD9AF3CA610548E59B06C66@DEWDFEMB16B.global.corp.sap> Apologies for the top-post; Outlook makes it hard to do anything else. Here is a small C++ reproducible. I am generating a key pair, encrypting a small string using OAEP and decrypting using PKCS1 and expecting the decryption to fail. If I run this (on 64-bit Red Hat 6) repeatedly, the program will eventually fail because RSA_private_decrypt doesn't fail. I can run it hundreds of times successfully before it fails. I have also seen it fail on Windows 7. Graeme #include #include int main( int, char ** ) /**********************/ { BIGNUM *exponent = BN_new(); RSA *rsa_key = RSA_new(); BN_set_word( exponent, RSA_F4 ); int rc = RSA_generate_key_ex( rsa_key, 1024, exponent, NULL ); if( rc == 0 ) { printf( "RSA key generation failed\n" ); return 1; } int input_pad = RSA_PKCS1_OAEP_PADDING; const char *input = "abcd"; size_t input_len = strlen( input ); unsigned char encrypted[1000]; unsigned char decrypted[1000]; size_t enc_len = RSA_public_encrypt( (int)input_len, (const unsigned char *)input, encrypted, rsa_key, input_pad ); int output_pad = RSA_PKCS1_PADDING; memset( decrypted, 0, sizeof(decrypted) ); size_t dec_len = RSA_private_decrypt( (int)enc_len, encrypted, decrypted, rsa_key, output_pad ); if( dec_len == -1 ) { return 0; // expected outcome } printf( "RSA_private_decrypt succeeded, len=%ld bytes\n", dec_len ); return 1; } -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Saturday, April 25, 2015 1:41 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Can RSA_private_decrypt succeed with the wrong padding? On Sat, Apr 25, 2015 at 12:49:21AM +0000, Perrow, Graeme wrote: > Using OpenSSL 1.0.1m on 64-bit Windows and Linux. > > I have implemented RSA encryption using the RSA_public_encrypt and > RSA_private_decrypt functions and various padding types. This is working > fine except that in very rare cases, my test fails because decrypting > succeeds when it should fail. I'm basically doing this (pseudocode): > > RSA_public_encrypt( "abc", encrypted_data, my_public_key, RSA_PKCS1_OAEP_PADDING ); > RSA_private_decrypt( encrypted_data, decrypted_data, my_private_key, RSA_NO_PADDING ); A real code fragment would be substantially more useful that "pseudo-code" here. This should *always* succeed, provided you pass the correct length to RSA_private_decrypt. From the manpage: flen must be ... and exactly RSA_size(rsa) for RSA_NO_PADDING. > Note that the padding types are different. The vast majority of the time, > I get an error from the RSA_private_decrypt call but now and again, it > succeeds. You're doing something wrong, it should always recover the OAEP padded data, which is basically random, you need to reverse the OAEP padding to recover the plaintext. > I don't understand the underlying crypto well enough to know - is it > possible for RSA_private_decrypt to be unable to tell that the wrong > padding was used, or is this a bug in OpenSSL? When not using padding, that's not "wrong" padding, you're just doing a raw RSA decrypt, and any input that is smaller than the modulus (but has the same bit length) should decrypt to something. -- Viktor. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From openssl-users at dukhovni.org Wed Apr 29 17:34:23 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 29 Apr 2015 17:34:23 +0000 Subject: [openssl-users] Can RSA_private_decrypt succeed with the wrong padding? In-Reply-To: <6378BFFB8601BD438AD9AF3CA610548E59B06C66@DEWDFEMB16B.global.corp.sap> References: <6378BFFB8601BD438AD9AF3CA610548E59B059FB@DEWDFEMB16B.global.corp.sap> <20150425054104.GM25758@mournblade.imrryr.org> <6378BFFB8601BD438AD9AF3CA610548E59B06C66@DEWDFEMB16B.global.corp.sap> Message-ID: <20150429173423.GR20186@mournblade.imrryr.org> On Wed, Apr 29, 2015 at 03:42:40PM +0000, Perrow, Graeme wrote: > Apologies for the top-post; Outlook makes it hard to do anything else. > > Here is a small C++ reproducible. I am generating a key pair, encrypting > a small string using OAEP and decrypting using PKCS1 and expecting the > decryption to fail. > > If I run this (on 64-bit Red Hat 6) repeatedly, the program will eventually > fail because RSA_private_decrypt doesn't fail. I can run it hundreds of > times successfully before it fails. I have also seen it fail on Windows > 7. Originally, you said the decryption used "RSA_NO_PADDING", the code below decrypts with "RSA_PKCS1_PADDING". > int output_pad = RSA_PKCS1_PADDING; > memset( decrypted, 0, sizeof(decrypted) ); > size_t dec_len = RSA_private_decrypt( (int)enc_len, encrypted, decrypted, > rsa_key, output_pad ); If you generate enough OAEP samples, some of them will look like PKCS1 padding. Padding is *NOT* integrity protection. Per: https://tools.ietf.org/html/rfc2313#section-8.1 an input block that resembles PKCS1 padding for encryption with a public key looks like: 00 02 * 00 So, all you need is for the first two octets to be "00 02" (a 00 has an ~40% chance to follow somewhere in a sample of ~126 random octets). So this will happen from time to time (somewhat south of once every 64k tries). Encryption and decryption alone do not provide integrity protection. -- Viktor. From bcall at apache.org Wed Apr 29 17:53:50 2015 From: bcall at apache.org (Bryan Call) Date: Wed, 29 Apr 2015 10:53:50 -0700 Subject: [openssl-users] Performance problems with OpenSSL and threading In-Reply-To: <553FC1D0.9090302@cisco.com> References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org> <5539844F.4090107@cisco.com> <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com> <553ACEF9.4080702@cisco.com> <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org> <553FC1D0.9090302@cisco.com> Message-ID: Can I safely assume that if I call FIPS_mode_set(0) and get a successful return value then I don?t need to lock when there are callbacks for type 39 and 40 locks (for OpenSSL 1.0.1 and 1.0.2)? -Bryan > On Apr 28, 2015, at 10:22 AM, John Foley wrote: > > In the context of OpenSSL 1.0.1 or 1.0.2, this means FIPS_mode_set(1) has returned with a successful return value. > > In the future, this may change if/when OpenSSL does another FIPS validation. CMVP has changed the implementation guidance that requires the POST to run automatically without user intervention. Any future FIPS validations would be subject to the new rules. Hence, the behavior of FIPS_mode_set() may change in the future if OpenSSL decides to pursue another validation. > > > > On 04/28/2015 12:43 PM, Bryan Call wrote: >> What do you mean by ?FIPS POST has completed?? >> >> -Bryan >> >> >> >> >>> On Apr 24, 2015, at 4:17 PM, John Foley > wrote: >>> >>> Some of the algorithms still invoke the FIPS flavor of the algorithm even when FIPS is disabled. For example, this code is from EVP_DigestUpdate(). >>> >>> int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *data, size_t count) >>> { >>> #ifdef OPENSSL_FIPS >>> return FIPS_digestupdate(ctx, data, count); >>> #else >>> return ctx->update(ctx, data, count); >>> #endif >>> } >>> >>> In 1.0.1, locks 39 and 40 are: >>> >>> # define CRYPTO_LOCK_FIPS 39 >>> # define CRYPTO_LOCK_FIPS2 40 >>> >>> You should try adding some logic to skip the lock in your lock handler when the lock ID is 39 or 40. Again, it should be safe to not lock on these two as long as the FIPS POST has completed. >>> >>> >>> >>> On 04/24/2015 05:56 PM, Bryan Call wrote: >>>> In my last email I ran the benchmark on Fedora 21 (big mistake). Here are the results when running it back on the 28/56 core RHEL 6.5 server showing contention in a different place (fips). Is there a reason it would be calling into the FIPS code to get a lock of FIPS is not enabled? >>>> >>>> Contention log: >>>> [Apr 24 21:35:09.731] Server {0x7f5529ccd700} ERROR: contention for lock - total contention: 70662 waiting: 16 file: fips.c line: 471 type: 40 >>>> [Apr 24 21:35:09.732] Server {0x7f55299ca700} ERROR: contention for lock - total contention: 71605 waiting: 2 file: fips.c line: 107 type: 39 >>>> >>>> >>>> Line in in fips that see the contention the most: >>>> [bcall at bm77 trafficserver]$ grep fips.c diags.log | cut -f 19 -d ' ' | sort | uniq -c | sort -rn >>>> 875379 471 >>>> 288338 107 >>>> 275472 127 >>>> >>>> >>>> Different lock types and their contention frequency (multiple benchmarks): >>>> 875379 40 < - in fips.c >>>> 563810 39 <- also in fips.c >>>> 440518 1 >>>> 44145 18 >>>> 17447 2 >>>> 11356 10 >>>> 1377 19 >>>> 687 12 >>>> 532 25 >>>> 302 33 >>>> 239 9 >>>> 58 16 >>>> 40 21 >>>> 32 11 >>>> 19 3 >>>> 1 14 >>>> >>>> >>>> Code to diable FIPS and log: >>>> #ifdef OPENSSL_FIPS >>>> int mode = FIPS_mode(); >>>> Debug("ssl", "FIPS_mode: %d", mode); >>>> mode = FIPS_mode(); >>>> if (mode) { >>>> FIPS_mode_set(0); >>>> Debug("ssl", "FIPS_mode: %d", mode); >>>> } >>>> #endif >>>> >>>> [Apr 24 21:43:45.860] Server {0x7f7628146800} DEBUG: (ssl) FIPS_mode: 0 >>>> >>>> -Bryan >>>> >>>> >>>> >>>> >>>>> On Apr 24, 2015, at 10:56 AM, John Foley > wrote: >>>>> >>>>> When you create the private key given to SSL_CTX, be sure to instantiate a private key for each thread as well. If you share the same key across all threads, this can introduce contention. >>>>> >>>>> Here are the type 1 & 2 locks: >>>>> >>>>> # define CRYPTO_LOCK_ERR 1 >>>>> # define CRYPTO_LOCK_EX_DATA 2 >>>>> >>>>> Have you checked the OpenSSL error log to see what errors are being generated? >>>>> >>>>> Also, if you disable FIPS, does the thread contention still occur? >>>>> >>>>> >>>>> >>>>> On 04/24/2015 01:36 PM, Bryan Call wrote: >>>>>> We are using a single SSL_CTX across all the threads, so I will create multiple SSL_CTX per thread. I implemented dynlock callbacks yesterday, but I didn?t see them being used in the tests I did. I also added atomic counters to see what type of locks are having contention (see logs below): >>>>>> >>>>>> Most of the lock contention seems to be around type 2 and type 1 locks when calling our lock callback. In the FIPS/POST and SSL_CTX recommendations, in your previous email, what types of locks would those help with? >>>>>> >>>>>> Log output: >>>>>> [Apr 24 10:21:24.339] Server {0xb310000} ERROR: :178 (SSL_locking_callback)> contention for lock - total contention: 3938 waiting: 1 file: /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/ex_data.c line: 496 type: 2 >>>>>> [Apr 24 10:21:24.754] Server {0xb10a000} ERROR: :178 (SSL_locking_callback)> contention for lock - total contention: 1350 waiting: 1 file: /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/err/err_def.c line: 343 type: 1 >>>>>> >>>>>> >>>>>> -Bryan >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Apr 23, 2015, at 4:46 PM, John Foley > wrote: >>>>>>> >>>>>>> Looking at your call stack, it appears you're testing with FIPS mode enabled. There's a lock in FIPS_selftest_failed() that's used to ensure the crypto algorithms inside the FIPS boundary are not utilized until after the POST has completed and passed. Unfortunately this lock remains installed for the lifetime of the process. We've seen thread contention in this area when using OpenSSL. One work-around is to modify your handler that you pass to SSL_locking_callback() to not lock when the lock ID is CRYPTO_LOCK_FIPS. But you would only want to disable this particular lock ID after the POST has completed. >>>>>>> >>>>>>> If the above doesn't help, another item to check is whether you're instantiating an SSL_CTX for each thread. I've seen some developers use a single SSL_CTX for multiple threads. This results in a single instance of the server cert and private key being shared across all the threads. This results in thread contention on the asymmetric key operations associated with the cert and private key (e.g. RSA). Be sure that each thread instantiates it's own SSL_CTX and certificate/private key. >>>>>>> >>>>>>> Lastly, add some debugs to count the locks by lock ID in your lock handler. There are about 40 different lock IDs defined in crypto/crypto.h. You'll need to identify which lock is causing the thread contention. Once you know that, then you can look in the code to see where that lock is used and troubleshoot from there. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 04/23/2015 07:23 PM, Bryan Call wrote: >>>>>>>> I was running a benchmark on a 28 core (56 hyper-threaded) server that is running 84 threads in the process and I am seeing a lot of lock contention. I saw a lot of lock contention in the calls to SSL_get_error() ssl3_accept(). I am running RHEL 6.5 and openssl-1.0.1e-30.el6_6.7.x86_64. We have used SSL_locking_callback() to setup pthread mutex locks, but haven?t setup dynlocks yet. Would dynlocks help in this scenario? >>>>>>>> >>>>>>>> >>>>>>>> Output from perf: >>>>>>>> Samples: 1M of event 'cycles', Event count (approx.): 602783506611 >>>>>>>> - 48.04% [ET_NET 0] [kernel.kallsyms] [k] _spin_lock ? >>>>>>>> - _spin_lock ? >>>>>>>> + 48.05% futex_wait_setup ? >>>>>>>> + 47.79% futex_wake ? >>>>>>>> + 1.20% tcp_v4_rcv ? >>>>>>>> + 0.98% task_rq_lock ? >>>>>>>> + 0.64% double_lock_balance ? >>>>>>>> + 3.94% [ET_NET 0] libcrypto.so.1.0.1e [.] bn_mul_mont ? >>>>>>>> + 1.93% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_usub ? >>>>>>>> + 1.80% [ET_NET 0] libcrypto.so.1.0.1e [.] 0x00000000000e5200 ? >>>>>>>> + 1.49% [ET_NET 0] libcrypto.so.1.0.1e [.] sha256_block_data_order ? >>>>>>>> + 0.97% [ET_NET 0] libcrypto.so.1.0.1e [.] gcm_ghash_clmul ? >>>>>>>> + 0.85% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_lock ? >>>>>>>> + 0.84% [ET_NET 0] libcrypto.so.1.0.1e [.] aesni_ctr32_encrypt_blocks ? >>>>>>>> + 0.74% [ET_NET 0] libc-2.12.so [.] malloc ? >>>>>>>> + 0.72% [ET_NET 0] libc-2.12.so [.] memcpy ? >>>>>>>> + 0.57% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_mod_mul_montgomery ? >>>>>>>> + 0.51% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_unlock >>>>>>>> >>>>>>>> pstack of the process (only a couple of the interesting threads): >>>>>>>> Thread 1 (Thread 0x7f1fba151800 (LWP 1106)): >>>>>>>> #0 0x00007f1fbaaeb264 in __lll_lock_wait () from /lib64/libpthread.so.0 >>>>>>>> #1 0x00007f1fbaae6508 in _L_lock_854 () from /lib64/libpthread.so.0 >>>>>>>> #2 0x00007f1fbaae63d7 in pthread_mutex_lock () from /lib64/libpthread.so.0 >>>>>>>> #3 0x000000000072822f in SSL_locking_callback(int, int, char const*, int) () >>>>>>>> #4 0x00000031d2ae7f03 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>> #5 0x00000031d2ae7d8c in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>> #6 0x00000031d2ae80ab in ERR_get_state () from /usr/lib64/libcrypto.so.10 >>>>>>>> #7 0x00000031d2ae8557 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>> #8 0x00000031d2e424a9 in SSL_get_error () from /usr/lib64/libssl.so.10 >>>>>>>> #9 0x00000000007249ef in SSLNetVConnection::load_buffer_and_write(long, long&, long&, MIOBufferAccessor&, int&) () >>>>>>>> #10 0x00000000007389df in write_to_net_io(NetHandler*, UnixNetVConnection*, EThread*) () >>>>>>>> #11 0x0000000000738523 in write_to_net(NetHandler*, UnixNetVConnection*, EThread*) () >>>>>>>> #12 0x0000000000731922 in NetHandler::mainNetEvent(int, Event*) () >>>>>>>> #13 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >>>>>>>> #14 0x000000000075877a in EThread::process_event(Event*, int) () >>>>>>>> #15 0x0000000000758c84 in EThread::ex >>>>>>>> >>>>>>>> Thread 56 (Thread 0x7f1fb0ecd700 (LWP 1172)): >>>>>>>> #0 0x00007f1fbaae77d9 in pthread_mutex_unlock () from /lib64/libpthread.so.0 >>>>>>>> #1 0x0000000000728265 in SSL_locking_callback(int, int, char const*, int) () >>>>>>>> #2 0x00000031d2b57402 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>> #3 0x00000031d2b574bd in FIPS_selftest_failed () from /usr/lib64/libcrypto.so.10 >>>>>>>> #4 0x00000031d2ae9f1c in EVP_DigestInit_ex () from /usr/lib64/libcrypto.so.10 >>>>>>>> #5 0x00000031d2a7977e in HMAC_Init_ex () from /usr/lib64/libcrypto.so.10 >>>>>>>> #6 0x00000031d2a79c29 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>> #7 0x00000031d2af7a42 in EVP_PKEY_CTX_ctrl () from /usr/lib64/libcrypto.so.10 >>>>>>>> #8 0x00000031d2ae9ffb in EVP_DigestInit_ex () from /usr/lib64/libcrypto.so.10 >>>>>>>> #9 0x00000031d2af952a in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>> #10 0x00000031d2e34cf2 in tls1_PRF () from /usr/lib64/libssl.so.10 >>>>>>>> #11 0x00000031d2e35796 in tls1_final_finish_mac () from /usr/lib64/libssl.so.10 >>>>>>>> #12 0x00000031d2e2db2e in ssl3_get_message () from /usr/lib64/libssl.so.10 >>>>>>>> #13 0x00000031d2e1dc3c in ssl3_get_cert_verify () from /usr/lib64/libssl.so.10 >>>>>>>> #14 0x00000031d2e220d6 in ssl3_accept () from /usr/lib64/libssl.so.10 >>>>>>>> #15 0x0000000000725287 in SSLNetVConnection::sslServerHandShakeEvent(int&) () >>>>>>>> #16 0x00000000007251b3 in SSLNetVConnection::sslStartHandShake(int, int&) () >>>>>>>> #17 0x0000000000723df3 in SSLNetVConnection::net_read_io(NetHandler*, EThread*) () >>>>>>>> #18 0x0000000000731852 in NetHandler::mainNetEvent(int, Event*) () >>>>>>>> #19 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >>>>>>>> #20 0x000000000075877a in EThread::process_event(Event*, int) () >>>>>>>> #21 0x0000000000758c84 in EThread::execute() () >>>>>>>> #22 0x0000000000757cf8 in spawn_thread_internal(void*) () >>>>>>>> #23 0x00007f1fbaae49d1 in start_thread () from /lib64/libpthread.so.0 >>>>>>>> #24 0x00000030ff0e88fd in clone () from /lib64/libc.so.6 >>>>>>>> >>>>>>>> -Bryan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> openssl-users mailing list >>>>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>>>>> >>>>>>> _______________________________________________ >>>>>>> openssl-users mailing list >>>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> openssl-users mailing list >>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>>> >>>>> _______________________________________________ >>>>> openssl-users mailing list >>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>> >>>> >>>> >>>> _______________________________________________ >>>> openssl-users mailing list >>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> >>> _______________________________________________ >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From graeme.perrow at sap.com Wed Apr 29 17:57:57 2015 From: graeme.perrow at sap.com (Perrow, Graeme) Date: Wed, 29 Apr 2015 17:57:57 +0000 Subject: [openssl-users] Can RSA_private_decrypt succeed with the wrong padding? In-Reply-To: <20150429173423.GR20186@mournblade.imrryr.org> References: <6378BFFB8601BD438AD9AF3CA610548E59B059FB@DEWDFEMB16B.global.corp.sap> <20150425054104.GM25758@mournblade.imrryr.org> <6378BFFB8601BD438AD9AF3CA610548E59B06C66@DEWDFEMB16B.global.corp.sap> <20150429173423.GR20186@mournblade.imrryr.org> Message-ID: <6378BFFB8601BD438AD9AF3CA610548E59B06D1C@DEWDFEMB16B.global.corp.sap> Excellent, this is exactly the kind of information I was looking for. Thanks very much Viktor for your help Graeme -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Wednesday, April 29, 2015 1:34 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Can RSA_private_decrypt succeed with the wrong padding? On Wed, Apr 29, 2015 at 03:42:40PM +0000, Perrow, Graeme wrote: > Apologies for the top-post; Outlook makes it hard to do anything else. > > Here is a small C++ reproducible. I am generating a key pair, encrypting > a small string using OAEP and decrypting using PKCS1 and expecting the > decryption to fail. > > If I run this (on 64-bit Red Hat 6) repeatedly, the program will eventually > fail because RSA_private_decrypt doesn't fail. I can run it hundreds of > times successfully before it fails. I have also seen it fail on Windows > 7. Originally, you said the decryption used "RSA_NO_PADDING", the code below decrypts with "RSA_PKCS1_PADDING". > int output_pad = RSA_PKCS1_PADDING; > memset( decrypted, 0, sizeof(decrypted) ); > size_t dec_len = RSA_private_decrypt( (int)enc_len, encrypted, decrypted, > rsa_key, output_pad ); If you generate enough OAEP samples, some of them will look like PKCS1 padding. Padding is *NOT* integrity protection. Per: https://tools.ietf.org/html/rfc2313#section-8.1 an input block that resembles PKCS1 padding for encryption with a public key looks like: 00 02 * 00 So, all you need is for the first two octets to be "00 02" (a 00 has an ~40% chance to follow somewhere in a sample of ~126 random octets). So this will happen from time to time (somewhat south of once every 64k tries). Encryption and decryption alone do not provide integrity protection. -- Viktor. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From foleyj at cisco.com Wed Apr 29 18:37:29 2015 From: foleyj at cisco.com (John Foley) Date: Wed, 29 Apr 2015 14:37:29 -0400 Subject: [openssl-users] Performance problems with OpenSSL and threading In-Reply-To: References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org> <5539844F.4090107@cisco.com> <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com> <553ACEF9.4080702@cisco.com> <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org> <553FC1D0.9090302@cisco.com> Message-ID: <554124E9.9060405@cisco.com> Correct. Locks 39/40 are only useful while the POST is running. Once the POST completes, the POST status never changes again unless the POST runs again. The only way to run the POST is by invoking FIPS_mode_set(1). But there should be no reason to invoke FIPS_mode_set(1) more than once unless you want to provide some sort of run-time FIPS mode toggle capability. You're asking in the context of Apache, right? Apache just has a global FIPS on/off knob in the config. If set, FIPS is enabled for the lifetime of the process and never disabled/re-enabled. You would invoke FIPS_mode_set(1) once prior to spinning up the worker threads. Therefore, the POST would be finished prior to any multi-threaded processing. On 04/29/2015 01:53 PM, Bryan Call wrote: > Can I safely assume that if I call FIPS_mode_set(0) and get a > successful return value then I don?t need to lock when there are > callbacks for type 39 and 40 locks (for OpenSSL 1.0.1 and 1.0.2)? > > -Bryan > > > > >> On Apr 28, 2015, at 10:22 AM, John Foley > > wrote: >> >> In the context of OpenSSL 1.0.1 or 1.0.2, this means FIPS_mode_set(1) >> has returned with a successful return value. >> >> In the future, this may change if/when OpenSSL does another FIPS >> validation. CMVP has changed the implementation guidance that >> requires the POST to run automatically without user intervention. >> Any future FIPS validations would be subject to the new rules. >> Hence, the behavior of FIPS_mode_set() may change in the future if >> OpenSSL decides to pursue another validation. >> >> >> >> On 04/28/2015 12:43 PM, Bryan Call wrote: >>> What do you mean by ?FIPS POST has completed?? >>> >>> -Bryan >>> >>> >>> >>> >>>> On Apr 24, 2015, at 4:17 PM, John Foley >>> > wrote: >>>> >>>> Some of the algorithms still invoke the FIPS flavor of the >>>> algorithm even when FIPS is disabled. For example, this code is >>>> from EVP_DigestUpdate(). >>>> >>>> int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *data, size_t count) >>>> { >>>> #ifdef OPENSSL_FIPS >>>> return FIPS_digestupdate(ctx, data, count); >>>> #else >>>> return ctx->update(ctx, data, count); >>>> #endif >>>> } >>>> >>>> In 1.0.1, locks 39 and 40 are: >>>> >>>> # define CRYPTO_LOCK_FIPS 39 >>>> # define CRYPTO_LOCK_FIPS2 40 >>>> >>>> You should try adding some logic to skip the lock in your lock >>>> handler when the lock ID is 39 or 40. Again, it should be safe to >>>> not lock on these two as long as the FIPS POST has completed. >>>> >>>> >>>> >>>> On 04/24/2015 05:56 PM, Bryan Call wrote: >>>>> In my last email I ran the benchmark on Fedora 21 (big mistake). >>>>> Here are the results when running it back on the 28/56 core RHEL >>>>> 6.5 server showing contention in a different place (fips). Is >>>>> there a reason it would be calling into the FIPS code to get a >>>>> lock of FIPS is not enabled? >>>>> >>>>> Contention log: >>>>> [Apr 24 21:35:09.731] Server {0x7f5529ccd700} ERROR: contention >>>>> for lock - total contention: 70662 waiting: 16 file: fips.c line: >>>>> 471 type: 40 >>>>> [Apr 24 21:35:09.732] Server {0x7f55299ca700} ERROR: contention >>>>> for lock - total contention: 71605 waiting: 2 file: fips.c line: >>>>> 107 type: 39 >>>>> >>>>> >>>>> Line in in fips that see the contention the most: >>>>> [bcall at bm77 trafficserver]$ grep fips.c diags.log | cut -f 19 -d ' >>>>> ' | sort | uniq -c | sort -rn >>>>> 875379 471 >>>>> 288338 107 >>>>> 275472 127 >>>>> >>>>> >>>>> Different lock types and their contention frequency (multiple >>>>> benchmarks): >>>>> 875379 40 < - in fips.c >>>>> 563810 39 <- also in fips.c >>>>> 440518 1 >>>>> 44145 18 >>>>> 17447 2 >>>>> 11356 10 >>>>> 1377 19 >>>>> 687 12 >>>>> 532 25 >>>>> 302 33 >>>>> 239 9 >>>>> 58 16 >>>>> 40 21 >>>>> 32 11 >>>>> 19 3 >>>>> 1 14 >>>>> >>>>> >>>>> Code to diable FIPS and log: >>>>> #ifdef OPENSSL_FIPS >>>>> int mode = FIPS_mode(); >>>>> Debug("ssl", "FIPS_mode: %d", mode); >>>>> mode = FIPS_mode(); >>>>> if (mode) { >>>>> FIPS_mode_set(0); >>>>> Debug("ssl", "FIPS_mode: %d", mode); >>>>> } >>>>> #endif >>>>> >>>>> [Apr 24 21:43:45.860] Server {0x7f7628146800} DEBUG: (ssl) >>>>> FIPS_mode: 0 >>>>> >>>>> -Bryan >>>>> >>>>> >>>>> >>>>> >>>>>> On Apr 24, 2015, at 10:56 AM, John Foley >>>>> > wrote: >>>>>> >>>>>> When you create the private key given to SSL_CTX, be sure to >>>>>> instantiate a private key for each thread as well. If you share >>>>>> the same key across all threads, this can introduce contention. >>>>>> >>>>>> Here are the type 1 & 2 locks: >>>>>> >>>>>> # define CRYPTO_LOCK_ERR 1 >>>>>> # define CRYPTO_LOCK_EX_DATA 2 >>>>>> >>>>>> Have you checked the OpenSSL error log to see what errors are >>>>>> being generated? >>>>>> >>>>>> Also, if you disable FIPS, does the thread contention still occur? >>>>>> >>>>>> >>>>>> >>>>>> On 04/24/2015 01:36 PM, Bryan Call wrote: >>>>>>> We are using a single SSL_CTX across all the threads, so I will >>>>>>> create multiple SSL_CTX per thread. I implemented dynlock >>>>>>> callbacks yesterday, but I didn?t see them being used in the >>>>>>> tests I did. I also added atomic counters to see what type of >>>>>>> locks are having contention (see logs below): >>>>>>> >>>>>>> Most of the lock contention seems to be around type 2 and type 1 >>>>>>> locks when calling our lock callback. In the FIPS/POST and >>>>>>> SSL_CTX recommendations, in your previous email, what types of >>>>>>> locks would those help with? >>>>>>> >>>>>>> Log output: >>>>>>> [Apr 24 10:21:24.339] Server {0xb310000} ERROR: >>>>>> :178 (SSL_locking_callback)> contention for >>>>>>> lock - total contention: 3938 waiting: 1 file: >>>>>>> /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/ex_data.c >>>>>>> line: 496 type: 2 >>>>>>> [Apr 24 10:21:24.754] Server {0xb10a000} ERROR: >>>>>> :178 (SSL_locking_callback)> contention for >>>>>>> lock - total contention: 1350 waiting: 1 file: >>>>>>> /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/err/err_def.c >>>>>>> line: 343 type: 1 >>>>>>> >>>>>>> >>>>>>> -Bryan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Apr 23, 2015, at 4:46 PM, John Foley >>>>>>> > wrote: >>>>>>>> >>>>>>>> Looking at your call stack, it appears you're testing with FIPS >>>>>>>> mode enabled. There's a lock in FIPS_selftest_failed() that's >>>>>>>> used to ensure the crypto algorithms inside the FIPS boundary >>>>>>>> are not utilized until after the POST has completed and passed. >>>>>>>> Unfortunately this lock remains installed for the lifetime of >>>>>>>> the process. We've seen thread contention in this area when >>>>>>>> using OpenSSL. One work-around is to modify your handler that >>>>>>>> you pass to SSL_locking_callback() to not lock when the lock ID >>>>>>>> is CRYPTO_LOCK_FIPS. But you would only want to disable this >>>>>>>> particular lock ID after the POST has completed. >>>>>>>> >>>>>>>> If the above doesn't help, another item to check is whether >>>>>>>> you're instantiating an SSL_CTX for each thread. I've seen >>>>>>>> some developers use a single SSL_CTX for multiple threads. >>>>>>>> This results in a single instance of the server cert and >>>>>>>> private key being shared across all the threads. This results >>>>>>>> in thread contention on the asymmetric key operations >>>>>>>> associated with the cert and private key (e.g. RSA). Be sure >>>>>>>> that each thread instantiates it's own SSL_CTX and >>>>>>>> certificate/private key. >>>>>>>> >>>>>>>> Lastly, add some debugs to count the locks by lock ID in your >>>>>>>> lock handler. There are about 40 different lock IDs defined in >>>>>>>> crypto/crypto.h. You'll need to identify which lock is causing >>>>>>>> the thread contention. Once you know that, then you can look >>>>>>>> in the code to see where that lock is used and troubleshoot >>>>>>>> from there. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 04/23/2015 07:23 PM, Bryan Call wrote: >>>>>>>>> I was running a benchmark on a 28 core (56 hyper-threaded) >>>>>>>>> server that is running 84 threads in the process and I am >>>>>>>>> seeing a lot of lock contention. I saw a lot of lock >>>>>>>>> contention in the calls to SSL_get_error() ssl3_accept(). I >>>>>>>>> am running RHEL 6.5 and openssl-1.0.1e-30.el6_6.7.x86_64. We >>>>>>>>> have used SSL_locking_callback() to setup pthread mutex locks, >>>>>>>>> but haven?t setup dynlocks yet. Would dynlocks help in this >>>>>>>>> scenario? >>>>>>>>> >>>>>>>>> >>>>>>>>> Output from perf: >>>>>>>>> Samples: 1M of event 'cycles', Event count (approx.): 602783506611 >>>>>>>>> - 48.04% [ET_NET 0] [kernel.kallsyms] [k] _spin_lock ? >>>>>>>>> - _spin_lock ? >>>>>>>>> >>>>>>>>> * + 48.05% futex_wait_setup ? >>>>>>>>> * + 47.79% futex_wake ? >>>>>>>>> * + 1.20% tcp_v4_rcv ? >>>>>>>>> * + 0.98% task_rq_lock ? >>>>>>>>> * + 0.64% double_lock_balance ? >>>>>>>>> >>>>>>>>> + 3.94% [ET_NET 0] libcrypto.so.1.0.1e [.] bn_mul_mont ? >>>>>>>>> + 1.93% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_usub ? >>>>>>>>> + 1.80% [ET_NET 0] libcrypto.so.1.0.1e [.] 0x00000000000e5200 ? >>>>>>>>> + 1.49% [ET_NET 0] libcrypto.so.1.0.1e [.] >>>>>>>>> sha256_block_data_order ? >>>>>>>>> + 0.97% [ET_NET 0] libcrypto.so.1.0.1e [.] gcm_ghash_clmul ? >>>>>>>>> + 0.85% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_lock ? >>>>>>>>> + 0.84% [ET_NET 0] libcrypto.so.1.0.1e [.] >>>>>>>>> aesni_ctr32_encrypt_blocks ? >>>>>>>>> + 0.74% [ET_NET 0] libc-2.12.so [.] malloc ? >>>>>>>>> + 0.72% [ET_NET 0] libc-2.12.so [.] memcpy ? >>>>>>>>> + 0.57% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_mod_mul_montgomery ? >>>>>>>>> + 0.51% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_unlock >>>>>>>>> >>>>>>>>> pstack of the process (only a couple of the interesting threads): >>>>>>>>> Thread 1 (Thread 0x7f1fba151800 (LWP 1106)): >>>>>>>>> #0 0x00007f1fbaaeb264 in __lll_lock_wait () from >>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>> #1 0x00007f1fbaae6508 in _L_lock_854 () from >>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>> #2 0x00007f1fbaae63d7 in pthread_mutex_lock () from >>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>> #3 0x000000000072822f in SSL_locking_callback(int, int, char >>>>>>>>> const*, int) () >>>>>>>>> #4 0x00000031d2ae7f03 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>>> #5 0x00000031d2ae7d8c in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>>> #6 0x00000031d2ae80ab in ERR_get_state () from >>>>>>>>> /usr/lib64/libcrypto.so.10 >>>>>>>>> #7 0x00000031d2ae8557 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>>> #8 0x00000031d2e424a9 in SSL_get_error () from >>>>>>>>> /usr/lib64/libssl.so.10 >>>>>>>>> #9 0x00000000007249ef in >>>>>>>>> SSLNetVConnection::load_buffer_and_write(long, long&, long&, >>>>>>>>> MIOBufferAccessor&, int&) () >>>>>>>>> #10 0x00000000007389df in write_to_net_io(NetHandler*, >>>>>>>>> UnixNetVConnection*, EThread*) () >>>>>>>>> #11 0x0000000000738523 in write_to_net(NetHandler*, >>>>>>>>> UnixNetVConnection*, EThread*) () >>>>>>>>> #12 0x0000000000731922 in NetHandler::mainNetEvent(int, Event*) () >>>>>>>>> #13 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >>>>>>>>> #14 0x000000000075877a in EThread::process_event(Event*, int) () >>>>>>>>> #15 0x0000000000758c84 in EThread::ex >>>>>>>>> >>>>>>>>> Thread 56 (Thread 0x7f1fb0ecd700 (LWP 1172)): >>>>>>>>> #0 0x00007f1fbaae77d9 in pthread_mutex_unlock () from >>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>> #1 0x0000000000728265 in SSL_locking_callback(int, int, char >>>>>>>>> const*, int) () >>>>>>>>> #2 0x00000031d2b57402 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>>> #3 0x00000031d2b574bd in FIPS_selftest_failed () from >>>>>>>>> /usr/lib64/libcrypto.so.10 >>>>>>>>> #4 0x00000031d2ae9f1c in EVP_DigestInit_ex () from >>>>>>>>> /usr/lib64/libcrypto.so.10 >>>>>>>>> #5 0x00000031d2a7977e in HMAC_Init_ex () from >>>>>>>>> /usr/lib64/libcrypto.so.10 >>>>>>>>> #6 0x00000031d2a79c29 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>>> #7 0x00000031d2af7a42 in EVP_PKEY_CTX_ctrl () from >>>>>>>>> /usr/lib64/libcrypto.so.10 >>>>>>>>> #8 0x00000031d2ae9ffb in EVP_DigestInit_ex () from >>>>>>>>> /usr/lib64/libcrypto.so.10 >>>>>>>>> #9 0x00000031d2af952a in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>>> #10 0x00000031d2e34cf2 in tls1_PRF () from /usr/lib64/libssl.so.10 >>>>>>>>> #11 0x00000031d2e35796 in tls1_final_finish_mac () from >>>>>>>>> /usr/lib64/libssl.so.10 >>>>>>>>> #12 0x00000031d2e2db2e in ssl3_get_message () from >>>>>>>>> /usr/lib64/libssl.so.10 >>>>>>>>> #13 0x00000031d2e1dc3c in ssl3_get_cert_verify () from >>>>>>>>> /usr/lib64/libssl.so.10 >>>>>>>>> #14 0x00000031d2e220d6 in ssl3_accept () from >>>>>>>>> /usr/lib64/libssl.so.10 >>>>>>>>> #15 0x0000000000725287 in >>>>>>>>> SSLNetVConnection::sslServerHandShakeEvent(int&) () >>>>>>>>> #16 0x00000000007251b3 in >>>>>>>>> SSLNetVConnection::sslStartHandShake(int, int&) () >>>>>>>>> #17 0x0000000000723df3 in >>>>>>>>> SSLNetVConnection::net_read_io(NetHandler*, EThread*) () >>>>>>>>> #18 0x0000000000731852 in NetHandler::mainNetEvent(int, Event*) () >>>>>>>>> #19 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >>>>>>>>> #20 0x000000000075877a in EThread::process_event(Event*, int) () >>>>>>>>> #21 0x0000000000758c84 in EThread::execute() () >>>>>>>>> #22 0x0000000000757cf8 in spawn_thread_internal(void*) () >>>>>>>>> #23 0x00007f1fbaae49d1 in start_thread () from >>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>> #24 0x00000030ff0e88fd in clone () from /lib64/libc.so.6 >>>>>>>>> >>>>>>>>> -Bryan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> openssl-users mailing list >>>>>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> openssl-users mailing list >>>>>>>> To unsubscribe: >>>>>>>> https://mta.openssl.org/mailman/listinfo/openssl-users >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> openssl-users mailing list >>>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>>>> >>>>>> _______________________________________________ >>>>>> openssl-users mailing list >>>>>> To unsubscribe: >>>>>> https://mta.openssl.org/mailman/listinfo/openssl-users >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> openssl-users mailing list >>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>> >>>> _______________________________________________ >>>> openssl-users mailing list >>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> >>> >>> >>> _______________________________________________ >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajarantes at yahoo.ca Wed Apr 29 19:05:01 2015 From: ajarantes at yahoo.ca (Alexandre Arantes) Date: Wed, 29 Apr 2015 19:05:01 +0000 (UTC) Subject: [openssl-users] Is it possible to add a Client Hostname to an SSL Client Certificate? In-Reply-To: <247969672.666904.1430323303679.JavaMail.yahoo@mail.yahoo.com> References: <247969672.666904.1430323303679.JavaMail.yahoo@mail.yahoo.com> Message-ID: <2077012501.840274.1430334301442.JavaMail.yahoo@mail.yahoo.com> Hello, I recently implemented a secured communication between two sites in which one acts as the server and the other as the client. To accomplish this, I used openssl to generate self-signed CA, Server and Client certificates (the calls are made using cURL). It all works beautifully and, testing my "proof-of-concept" has shown that if one of the pieces is missing from the equation (CA, Server, Client certificates), the communication ceases. But once I showed my work to people in my company, one of them asked me why did I choose not to add the client hostname to the Client Certificate, thus making it usable only by that specific client. And so I started searching online for ways to do it, but found nothing. I also looked into the openssl site and documentation and found nothing there either. The truth is that I don't even know if this is possible or even if this is the right question to ask.? But can it be done? And if so, could you show me how, or where should I go to get more information on how to accomplish this? If you need more information on how I setup this communication, please let me know and I will be glad to share it here. Thanks,Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Apr 29 19:35:46 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 29 Apr 2015 19:35:46 +0000 Subject: [openssl-users] Is it possible to add a Client Hostname to an SSL Client Certificate? In-Reply-To: <2077012501.840274.1430334301442.JavaMail.yahoo@mail.yahoo.com> References: <247969672.666904.1430323303679.JavaMail.yahoo@mail.yahoo.com> <2077012501.840274.1430334301442.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1f35763dfbc743a7bab22a830ee6cfa8@usma1ex-dag1mb4.msg.corp.akamai.com> > But once I showed my work to people in my company, one of them asked me why did I choose not to add the client hostname to the Client Certificate, thus making it usable only by that specific client. You put to put the client name or ipaddr in the subjectAltName extension field. Then you'd have to put code on your server to verify that. From jonetsu at teksavvy.com Wed Apr 29 20:39:16 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Wed, 29 Apr 2015 13:39:16 -0700 (MST) Subject: [openssl-users] Porting to EVP methods: AES_set_encrypt_key() Message-ID: <1430339956810-57801.post@n7.nabble.com> Hello, The context is migrating an application to use EVP only methods. AES_set_encrypt_key(...) AES_cfb128_encrypt(...) The AES_cfb128_encrypt() is pretty clear to migrate to EVP_*, what about the AES_set_encrypt_key() ? I haven't found yet any correlation to the EVP methods, let alone an actal description of AES_set_encrypt_key() purpose. How is this translted to EVP ? Thanks. -- View this message in context: http://openssl.6102.n7.nabble.com/Porting-to-EVP-methods-AES-set-encrypt-key-tp57801.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From matt at openssl.org Wed Apr 29 21:55:36 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 29 Apr 2015 22:55:36 +0100 Subject: [openssl-users] Porting to EVP methods: AES_set_encrypt_key() In-Reply-To: <1430339956810-57801.post@n7.nabble.com> References: <1430339956810-57801.post@n7.nabble.com> Message-ID: <55415358.8070405@openssl.org> On 29/04/15 21:39, jonetsu wrote: > Hello, > > The context is migrating an application to use EVP only methods. > > AES_set_encrypt_key(...) > > AES_cfb128_encrypt(...) > > The AES_cfb128_encrypt() is pretty clear to migrate to EVP_*, > what about the AES_set_encrypt_key() ? I haven't found yet any > correlation to the EVP methods, let alone an actal description of > AES_set_encrypt_key() purpose. How is this translted to EVP ? There isn't a one-for-one correlation. The key is supplied in the call to EVP_EncryptInit_ex(). See the following for some sample code: https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption Matt From Newcomer83 at web.de Thu Apr 30 09:48:10 2015 From: Newcomer83 at web.de (Newcomer83 at web.de) Date: Thu, 30 Apr 2015 11:48:10 +0200 Subject: [openssl-users] How do I uninitialize OpenSSL properly? In-Reply-To: <054704bd6a5a4a8a991e802dd8102e7c@usma1ex-dag1mb4.msg.corp.akamai.com> References: <553CFAA0.6060201@web.de> <553D2B19.1080405@web.de> <553FC83F.9010206@web.de>, <054704bd6a5a4a8a991e802dd8102e7c@usma1ex-dag1mb4.msg.corp.akamai.com> Message-ID: An HTML attachment was scrubbed... URL: From beldmit at gmail.com Thu Apr 30 10:06:30 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 30 Apr 2015 13:06:30 +0300 Subject: [openssl-users] Implementing the rsa_sign callback Message-ID: Hello all! I'm implementing a custom engine providing its own RSA method. I need to provide the rsa_sign callback, which is required to call my own code in case when ex_data is set and call a default callback otherwise. For other callbacks I use the appropriate callbacks from the rsa_pkcs1_eay_meth, as other engines do. But the rsa_pkcs1_eay_meth does not provide a rsa_sign callback. What is the correct way to implement the rsa_sign callback? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From tch at virtall.com Thu Apr 30 17:44:30 2015 From: tch at virtall.com (Tomasz Chmielewski) Date: Fri, 01 May 2015 02:44:30 +0900 Subject: [openssl-users] OCSP: ocsp.omniroot.com/baltimore/... - what is it exactly? Message-ID: <5fdafa9b45f85f3ec58773c96dd225a2@admin.virtall.com> This might not be very relevant to OpenSSL, but I'm not sure if there is any better list for this question... My webserver is getting flooded with queries like: ocsp.omniroot.com 124.205.254.7 - - [30/Apr/2015:19:24:30 +0200] "GET /baltimoreroot/MEowSKADAgEAMEEwPzA9MAkGBSsOAwIaBQAEFMEvRXbtFVnssF26ib%2BdgHjlI9QTBBTlnVkwgkdYzKz6CFQ2hns6tQRN8AIEByekag%3D%3D HTTP/1.1" 301 184 "-" "ocspd/1.0.3" ocsp.omniroot.com 222.161.249.75 - - [30/Apr/2015:19:24:33 +0200] "GET /baltimoreroot/MEUwQzBBMD8wPTAJBgUrDgMCGgUABBTBL0V27RVZ7LBduom%2FnYB45SPUEwQU5Z1ZMIJHWMys%2BghUNoZ7OrUETfACBAcnqkc%3D HTTP/1.1" 301 184 "-" "Microsoft-CryptoAPI/6.1" If I understand it right, because the query was sent to my server (China's Great Firewall DNS poisoning at works), and not to "original" ocsp.omniroot.com, somebody's browser or device was not able to verify if the certificate is still valid or not - am I correct here? Is it possible to say what "Common name / fqdn / certificate" is queried in such requests? Tomasz Chmielewski From michael at stroeder.com Thu Apr 30 18:02:53 2015 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Thu, 30 Apr 2015 20:02:53 +0200 Subject: [openssl-users] Is it possible to add a Client Hostname to an SSL Client Certificate? In-Reply-To: <2077012501.840274.1430334301442.JavaMail.yahoo@mail.yahoo.com> References: <247969672.666904.1430323303679.JavaMail.yahoo@mail.yahoo.com> <2077012501.840274.1430334301442.JavaMail.yahoo@mail.yahoo.com> Message-ID: <55426E4D.8030605@stroeder.com> Alexandre Arantes wrote: > one of them asked me why did I choose not to add the client hostname to the > Client Certificate, thus making it usable only by that specific client. There are no standardized naming rules for client certs like the TLS server hostname check implemented at the client side. You have to define and implement your own naming/mapping rules at the server side. > And so I started searching online for ways to do it, but found nothing. No wonder because there's no standard way. Several possibilites for client cert "names": - subject DN - issuer-DN + serial no. - cert fingerprint - Any naming convention stuffed into subjectAltName extension Some inspiration in various server software: FakeBasicAuth in Apache's mod_ssl: http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#ssloptions Certificate Mappers in OpenDJ: http://docs.forgerock.org/en/opendj/2.6.0/configref/certificate-mapper.html Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4272 bytes Desc: S/MIME Cryptographic Signature URL: From erwann.abalea at opentrust.com Thu Apr 30 18:19:34 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Thu, 30 Apr 2015 20:19:34 +0200 Subject: [openssl-users] OCSP: ocsp.omniroot.com/baltimore/... - what is it exactly? In-Reply-To: <5fdafa9b45f85f3ec58773c96dd225a2@admin.virtall.com> References: <5fdafa9b45f85f3ec58773c96dd225a2@admin.virtall.com> Message-ID: <55427236.5090101@opentrust.com> Bonjour, Le 30/04/2015 19:44, Tomasz Chmielewski a ?crit : > This might not be very relevant to OpenSSL, but I'm not sure if there > is any better list for this question... > > My webserver is getting flooded with queries like: > > ocsp.omniroot.com 124.205.254.7 - - [30/Apr/2015:19:24:30 +0200] "GET > /baltimoreroot/MEowSKADAgEAMEEwPzA9MAkGBSsOAwIaBQAEFMEvRXbtFVnssF26ib%2BdgHjlI9QTBBTlnVkwgkdYzKz6CFQ2hns6tQRN8AIEByekag%3D%3D > HTTP/1.1" 301 184 "-" "ocspd/1.0.3" > > ocsp.omniroot.com 222.161.249.75 - - [30/Apr/2015:19:24:33 +0200] "GET > /baltimoreroot/MEUwQzBBMD8wPTAJBgUrDgMCGgUABBTBL0V27RVZ7LBduom%2FnYB45SPUEwQU5Z1ZMIJHWMys%2BghUNoZ7OrUETfACBAcnqkc%3D > HTTP/1.1" 301 184 "-" "Microsoft-CryptoAPI/6.1" > > > If I understand it right, because the query was sent to my server > (China's Great Firewall DNS poisoning at works), and not to "original" > ocsp.omniroot.com, somebody's browser or device was not able to verify > if the certificate is still valid or not - am I correct here? I don't remember the exact behaviour of the first client (I guess it's an Apple machine) on receiving this answer. For the Microsoft one, the client will try to get the CRL, and should also try a POST request to the OCSP responder, but I don't remember which one is tried first. > Is it possible to say what "Common name / fqdn / certificate" is > queried in such requests? Not directly. The first request asks for the status of certificate whose serial number is 0x0727A46A, the second for the certificate with serial number 0x0727AA47, both certificates are issued under the same CA, this CA is the root "C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root". If you can crawl a certificates database (there are several out there), you can probably find the exact requested certificate (it should be a CA, too). From m.de.groot at dmdg.nl Thu Apr 30 18:46:11 2015 From: m.de.groot at dmdg.nl (m.de.groot) Date: Thu, 30 Apr 2015 20:46:11 +0200 Subject: [openssl-users] Error signing document Message-ID: Dear Openssl, I have the following case: I am trying to sign a file with a private key from an CA. I converted the pfx file to a pem file using the following command openssl pkcs12 -in CustKeyIcBD001.pfx -out CustKeyIcBD001.pem -nodes After this I trying to sign a file using this key with the following command openssl cms -sign -in TestfileIN.txt -out TestfileSign.tmp -outform DER -binary -nodetach -md SHA1 ?signer CustKeyIcBD001.pem However I keep getting the message No signer certificate specified I have put all files in the same directory and don't see why this is going wrong. Can anybody help me out on this? Regards, Mark From rsalz at akamai.com Thu Apr 30 20:11:33 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 30 Apr 2015 20:11:33 +0000 Subject: [openssl-users] OCSP: ocsp.omniroot.com/baltimore/... - what is it exactly? In-Reply-To: <5fdafa9b45f85f3ec58773c96dd225a2@admin.virtall.com> References: <5fdafa9b45f85f3ec58773c96dd225a2@admin.virtall.com> Message-ID: <5e50191ba0bc4ec590f628c85a342989@usma1ex-dag1mb4.msg.corp.akamai.com> > My webserver is getting flooded with queries like: > > ocsp.omniroot.com 124.205.254.7 - - [30/Apr/2015:19:24:30 +0200] "GET > /baltimoreroot/MEowSKADAgEAMEEwPzA9MAkGBSsOAwIaBQAEFMEvRXbt > FVnssF26ib%2BdgHjlI9QTBBTlnVkwgkdYzKz6CFQ2hns6tQRN8AIEByekag%3D > %3D > HTTP/1.1" 301 184 "-" "ocspd/1.0.3" Well, that stinks. url-decoding (%2b is + and %3d is =), and then base64 decoding it can give you the OCSP request: ; ./openssl ocsp -text -reqin x.der OCSP Request Data: Version: 1 (0x0) Requestor List: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: C12F4576ED1559ECB05DBA89BF9D8078E523D413 Issuer Key Hash: E59D5930824758CCACFA085436867B3AB5044DF0 Serial Number: 0727A46A > Is it possible to say what "Common name / fqdn / certificate" is queried in > such requests? Not really. The protocol assumes that the requestor has the cert, and the server has the serial#, so the protocol sends the minimal information. Sorry. From rwelty at nwtime.org Thu Apr 30 22:32:33 2015 From: rwelty at nwtime.org (Richard Welty) Date: Thu, 30 Apr 2015 18:32:33 -0400 Subject: [openssl-users] CMS questions In-Reply-To: <20150224151022.GA12696@openssl.org> References: <54EB3E92.7060106@averillpark.net> <20150224142106.GA1228@openssl.org> <54EC8AF6.70407@averillpark.net> <20150224151022.GA12696@openssl.org> Message-ID: <5542AD81.90301@nwtime.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/24/15 10:10 AM, Dr. Stephen Henson wrote: > On Tue, Feb 24, 2015, Richard Welty wrote: > >> On 2/24/15 9:21 AM, Dr. Stephen Henson wrote: >>> >>> Typically you'd write the signed content to a memory BIO and then decrypt >>> that. Precisely how you decrypt the enveloped data depends on the format. It >>> might be in MIME format in which case you'd pass it through the MIME parser. >>> Alternatively it could be enveloped data content type in which case you'd >>> decode it as BER form. >>> >>> There are shortcuts you can make if, for example, you know the signed content >>> is not detached and in BER form. >>> >> it will not be detached, and will be in BER form. shortcuts (as long as >> they're >> in a documented API) are welcome as this is in a path that should be fast. >> > > So the embedded content type will be enveloped data? > > If so first you can check that type using CMS_get0_eContentType(). > > Then you can use CMS_get0_content() to retrieve the embedded content as a > pointer to an OCTET STRING pointer. You should check that content is not NULL > and then retrieve the encoding of the content using ASN1_STRING_data and > ASN1_STRING_length. > > Once you have those you can decode using d2i_CMS_ContentInfo(). > > A couple of those functions are currently undocumented (that will be fixed) but > nothing in that involves using structure internals. > coming back to this after a bit of time; the project is finally getting fired up. there are two questions in front of me right now: 1) the documentation on d2i_CMS_ContentInfo() is a bit light on details about the parameters. what should the first parameter be, a certificate as with d2i_X509? 2) is there something roughly analogous for encryption? i need a fast-but-documented path for encrypting and signing data using BER on the server that will be decrypted client (and vice versa). thanks, richard -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVQq2BAAoJEBg+LdNh/YEc/xwQAL2QH/aH1LUATeAmGmt2h7tk n4K5ghhrIwCOlrgqXNbSS7qEmrXdRgKPhTZkJVx/Y236hqJt/AqjyB0geCmDIuMi uOXzPXlWInj6jg9kjGq+jEMeG9Czu1i/DfSJjB01N6asEx8YKvNZUVnNqKj8fkBi iit0a5/61B26bd8oGVAFfM6gMJMBZRWqbPSFhjPyB2tMWMOfnZ7N08N66qz29/Xk vKiG1EEj6SRAPTFhzqzLzZphtShWDXeQP6pfrSRJ6AGiTfX2Gvn/7iwUiPUF3sLX 8ULskp3XyWeA/L71vLUNvo49XVdx/7lCj4o8nbCrI+/fgIREPAdI+AzvsxYv8wFH K/pSYZOL5ag+YiMBt9pfPCxhUebjz4KS9InoT4g15x8DuhosiB/6JWOFsKpHENxX 5TO/tRteopWmQ0PBCbrrBG58Gdg0t7OW6tBM0e13cYLTfUc93eOb7lJhuMOzzkqJ i6VF99Cosj8WcjZuh4hASVHe7h9pBOlabl8xHlSocbn91Q68RnwpQ12HoQMhjqze 1Za4yaQagcd8OnBoRc8gXCWUGNfLRYjEXdXaKt1AlFWQHa6h2ZcGwgoMukg+Fu1Z AyY7vaxIPa3wBR1eNhv15hrgwBmoWPzTgoupTbbiP4e5HnmcdWUcjnKvOd+kamQG SHhG4PeipRKHtJ1OzA5Q =vlyk -----END PGP SIGNATURE----- From rwelty at nwtime.org Thu Apr 30 22:57:17 2015 From: rwelty at nwtime.org (Richard Welty) Date: Thu, 30 Apr 2015 18:57:17 -0400 Subject: [openssl-users] CMS questions In-Reply-To: <5542AD81.90301@nwtime.org> References: <54EB3E92.7060106@averillpark.net> <20150224142106.GA1228@openssl.org> <54EC8AF6.70407@averillpark.net> <20150224151022.GA12696@openssl.org> <5542AD81.90301@nwtime.org> Message-ID: <5542B34D.4040807@nwtime.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 4/30/15 6:32 PM, Richard Welty wrote: > 1) the documentation on d2i_CMS_ContentInfo() is a bit light on > details about the parameters. what should the first parameter be, a > certificate as with d2i_X509? ok, figured this one out for myself, should have read the d2i_X509 documentation more carefully. richard -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVQrNNAAoJEBg+LdNh/YEcDggQALFImQPZ/MlvBbOnMvELkFxM eCwZxE+BnwVpMgRnsVaTM0z2r9hY44V1jGZrw+Xfj4YXkaAXs6iIarptdg+IL9dX bNi4haTy4QMF8Uu5mvWCSLcsIO/1obXnH5FE9Ri2QMK6Jysp4vPiC379sBQyGGRm o+gF3cnpYF0+VKQX858KjE8sChJMCHgfdDU3Z79S9iEdeUeZ0ILESLRQcy8OEywp iToW6FRQuaCK36bn+23ApxUUuQIkPGcqoDDvOPSXVuTMjYLSzfFzsTXfu42yY56G Rmxg9TFfPL6WdLJb/BQoBvA6u4HWo7pZdpFUymShhezTlM5jvVAHXeHq6PZjJx8J g7bpPH6mu17ILdJMQqVo3kWhGnQVZMuR12BY6qHaBvOWxJ7lAEYjjlu+pVtgWlp3 vRbWwGfApC36UziRJpmZIYgz1e7hUrB8Mqg78f3SPK1fcWKSYV1IkRnxM7Py+PnT ISXAi6VTRmg1rNc0cnfrhegcTcwUFJVyCTCKWR4i7NlUDSHSThcmMKW5muasjL11 cr4OPfDStI7okM4GpPADL09ZnRK7J+D+UYXZYq37XnokekqAZ1/Bjs5VDKKzlfv0 7lTMxLaZ5jeIwBM4KdTn4ThFVg5Huz1lsI7yP4J2kwkdA9RIcz2jmkhvS/8N5V/F HLbQJyfjWnFX5PlAUL5u =UfG4 -----END PGP SIGNATURE----- From bcall at apache.org Thu Apr 30 22:52:10 2015 From: bcall at apache.org (Bryan Call) Date: Thu, 30 Apr 2015 15:52:10 -0700 Subject: [openssl-users] Performance problems with OpenSSL and threading In-Reply-To: <554124E9.9060405@cisco.com> References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org> <5539844F.4090107@cisco.com> <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com> <553ACEF9.4080702@cisco.com> <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org> <553FC1D0.9090302@cisco.com> <554124E9.9060405@cisco.com> Message-ID: <91F453BC-3CA5-4031-9F07-09222EE7716B@apache.org> This is for Apache Traffic Server and we have no knobs for turning on/off FIPS. I am thinking about always disabling FIPS right now and that would happen before we create the threads. I was able to get rid of all the FIPS lock connection with the changes you recommend (Big Thanks!). The big one now is type 1. I am printing out the log every time the contention total is mod 1M. Are there any tricks I can do for type 1 locks? [Apr 30 22:46:49.549] Server {0x7f1e4531d700} ERROR: contention for lock - total contention: 4000000 waiting: 1 file: pmeth_lib.c line: 185 type: 10 [Apr 30 22:46:49.688] Server {0x7f1e45822700} ERROR: contention for lock - total contention: 11000000 waiting: 2 file: err.c line: 469 type: 1 [Apr 30 22:46:50.406] Server {0x7f1e45c26700} ERROR: contention for lock - total contention: 4000000 waiting: 0 file: ex_data.c line: 304 type: 2 [Apr 30 22:46:50.932] Server {0x7f1e45b25700} ERROR: contention for lock - total contention: 12000000 waiting: 5 file: err.c line: 446 type: 1 [Apr 30 22:46:52.001] Server {0x7f1e45721700} ERROR: contention for lock - total contention: 1000000 waiting: 0 file: rand_lib.c line: 212 type: 19 -Bryan > On Apr 29, 2015, at 11:37 AM, John Foley wrote: > > Correct. Locks 39/40 are only useful while the POST is running. Once the POST completes, the POST status never changes again unless the POST runs again. The only way to run the POST is by invoking FIPS_mode_set(1). But there should be no reason to invoke FIPS_mode_set(1) more than once unless you want to provide some sort of run-time FIPS mode toggle capability. > > You're asking in the context of Apache, right? Apache just has a global FIPS on/off knob in the config. If set, FIPS is enabled for the lifetime of the process and never disabled/re-enabled. You would invoke FIPS_mode_set(1) once prior to spinning up the worker threads. Therefore, the POST would be finished prior to any multi-threaded processing. > > > > On 04/29/2015 01:53 PM, Bryan Call wrote: >> Can I safely assume that if I call FIPS_mode_set(0) and get a successful return value then I don?t need to lock when there are callbacks for type 39 and 40 locks (for OpenSSL 1.0.1 and 1.0.2)? >> >> -Bryan >> >> >> >> >>> On Apr 28, 2015, at 10:22 AM, John Foley > wrote: >>> >>> In the context of OpenSSL 1.0.1 or 1.0.2, this means FIPS_mode_set(1) has returned with a successful return value. >>> >>> In the future, this may change if/when OpenSSL does another FIPS validation. CMVP has changed the implementation guidance that requires the POST to run automatically without user intervention. Any future FIPS validations would be subject to the new rules. Hence, the behavior of FIPS_mode_set() may change in the future if OpenSSL decides to pursue another validation. >>> >>> >>> >>> On 04/28/2015 12:43 PM, Bryan Call wrote: >>>> What do you mean by ?FIPS POST has completed?? >>>> >>>> -Bryan >>>> >>>> >>>> >>>> >>>>> On Apr 24, 2015, at 4:17 PM, John Foley > wrote: >>>>> >>>>> Some of the algorithms still invoke the FIPS flavor of the algorithm even when FIPS is disabled. For example, this code is from EVP_DigestUpdate(). >>>>> >>>>> int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *data, size_t count) >>>>> { >>>>> #ifdef OPENSSL_FIPS >>>>> return FIPS_digestupdate(ctx, data, count); >>>>> #else >>>>> return ctx->update(ctx, data, count); >>>>> #endif >>>>> } >>>>> >>>>> In 1.0.1, locks 39 and 40 are: >>>>> >>>>> # define CRYPTO_LOCK_FIPS 39 >>>>> # define CRYPTO_LOCK_FIPS2 40 >>>>> >>>>> You should try adding some logic to skip the lock in your lock handler when the lock ID is 39 or 40. Again, it should be safe to not lock on these two as long as the FIPS POST has completed. >>>>> >>>>> >>>>> >>>>> On 04/24/2015 05:56 PM, Bryan Call wrote: >>>>>> In my last email I ran the benchmark on Fedora 21 (big mistake). Here are the results when running it back on the 28/56 core RHEL 6.5 server showing contention in a different place (fips). Is there a reason it would be calling into the FIPS code to get a lock of FIPS is not enabled? >>>>>> >>>>>> Contention log: >>>>>> [Apr 24 21:35:09.731] Server {0x7f5529ccd700} ERROR: contention for lock - total contention: 70662 waiting: 16 file: fips.c line: 471 type: 40 >>>>>> [Apr 24 21:35:09.732] Server {0x7f55299ca700} ERROR: contention for lock - total contention: 71605 waiting: 2 file: fips.c line: 107 type: 39 >>>>>> >>>>>> >>>>>> Line in in fips that see the contention the most: >>>>>> [bcall at bm77 trafficserver]$ grep fips.c diags.log | cut -f 19 -d ' ' | sort | uniq -c | sort -rn >>>>>> 875379 471 >>>>>> 288338 107 >>>>>> 275472 127 >>>>>> >>>>>> >>>>>> Different lock types and their contention frequency (multiple benchmarks): >>>>>> 875379 40 < - in fips.c >>>>>> 563810 39 <- also in fips.c >>>>>> 440518 1 >>>>>> 44145 18 >>>>>> 17447 2 >>>>>> 11356 10 >>>>>> 1377 19 >>>>>> 687 12 >>>>>> 532 25 >>>>>> 302 33 >>>>>> 239 9 >>>>>> 58 16 >>>>>> 40 21 >>>>>> 32 11 >>>>>> 19 3 >>>>>> 1 14 >>>>>> >>>>>> >>>>>> Code to diable FIPS and log: >>>>>> #ifdef OPENSSL_FIPS >>>>>> int mode = FIPS_mode(); >>>>>> Debug("ssl", "FIPS_mode: %d", mode); >>>>>> mode = FIPS_mode(); >>>>>> if (mode) { >>>>>> FIPS_mode_set(0); >>>>>> Debug("ssl", "FIPS_mode: %d", mode); >>>>>> } >>>>>> #endif >>>>>> >>>>>> [Apr 24 21:43:45.860] Server {0x7f7628146800} DEBUG: (ssl) FIPS_mode: 0 >>>>>> >>>>>> -Bryan >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Apr 24, 2015, at 10:56 AM, John Foley > wrote: >>>>>>> >>>>>>> When you create the private key given to SSL_CTX, be sure to instantiate a private key for each thread as well. If you share the same key across all threads, this can introduce contention. >>>>>>> >>>>>>> Here are the type 1 & 2 locks: >>>>>>> >>>>>>> # define CRYPTO_LOCK_ERR 1 >>>>>>> # define CRYPTO_LOCK_EX_DATA 2 >>>>>>> >>>>>>> Have you checked the OpenSSL error log to see what errors are being generated? >>>>>>> >>>>>>> Also, if you disable FIPS, does the thread contention still occur? >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 04/24/2015 01:36 PM, Bryan Call wrote: >>>>>>>> We are using a single SSL_CTX across all the threads, so I will create multiple SSL_CTX per thread. I implemented dynlock callbacks yesterday, but I didn?t see them being used in the tests I did. I also added atomic counters to see what type of locks are having contention (see logs below): >>>>>>>> >>>>>>>> Most of the lock contention seems to be around type 2 and type 1 locks when calling our lock callback. In the FIPS/POST and SSL_CTX recommendations, in your previous email, what types of locks would those help with? >>>>>>>> >>>>>>>> Log output: >>>>>>>> [Apr 24 10:21:24.339] Server {0xb310000} ERROR: :178 (SSL_locking_callback)> contention for lock - total contention: 3938 waiting: 1 file: /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/ex_data.c line: 496 type: 2 >>>>>>>> [Apr 24 10:21:24.754] Server {0xb10a000} ERROR: :178 (SSL_locking_callback)> contention for lock - total contention: 1350 waiting: 1 file: /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/err/err_def.c line: 343 type: 1 >>>>>>>> >>>>>>>> >>>>>>>> -Bryan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Apr 23, 2015, at 4:46 PM, John Foley > wrote: >>>>>>>>> >>>>>>>>> Looking at your call stack, it appears you're testing with FIPS mode enabled. There's a lock in FIPS_selftest_failed() that's used to ensure the crypto algorithms inside the FIPS boundary are not utilized until after the POST has completed and passed. Unfortunately this lock remains installed for the lifetime of the process. We've seen thread contention in this area when using OpenSSL. One work-around is to modify your handler that you pass to SSL_locking_callback() to not lock when the lock ID is CRYPTO_LOCK_FIPS. But you would only want to disable this particular lock ID after the POST has completed. >>>>>>>>> >>>>>>>>> If the above doesn't help, another item to check is whether you're instantiating an SSL_CTX for each thread. I've seen some developers use a single SSL_CTX for multiple threads. This results in a single instance of the server cert and private key being shared across all the threads. This results in thread contention on the asymmetric key operations associated with the cert and private key (e.g. RSA). Be sure that each thread instantiates it's own SSL_CTX and certificate/private key. >>>>>>>>> >>>>>>>>> Lastly, add some debugs to count the locks by lock ID in your lock handler. There are about 40 different lock IDs defined in crypto/crypto.h. You'll need to identify which lock is causing the thread contention. Once you know that, then you can look in the code to see where that lock is used and troubleshoot from there. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 04/23/2015 07:23 PM, Bryan Call wrote: >>>>>>>>>> I was running a benchmark on a 28 core (56 hyper-threaded) server that is running 84 threads in the process and I am seeing a lot of lock contention. I saw a lot of lock contention in the calls to SSL_get_error() ssl3_accept(). I am running RHEL 6.5 and openssl-1.0.1e-30.el6_6.7.x86_64. We have used SSL_locking_callback() to setup pthread mutex locks, but haven?t setup dynlocks yet. Would dynlocks help in this scenario? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Output from perf: >>>>>>>>>> Samples: 1M of event 'cycles', Event count (approx.): 602783506611 >>>>>>>>>> - 48.04% [ET_NET 0] [kernel.kallsyms] [k] _spin_lock ? >>>>>>>>>> - _spin_lock ? >>>>>>>>>> + 48.05% futex_wait_setup ? >>>>>>>>>> + 47.79% futex_wake ? >>>>>>>>>> + 1.20% tcp_v4_rcv ? >>>>>>>>>> + 0.98% task_rq_lock ? >>>>>>>>>> + 0.64% double_lock_balance ? >>>>>>>>>> + 3.94% [ET_NET 0] libcrypto.so.1.0.1e [.] bn_mul_mont ? >>>>>>>>>> + 1.93% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_usub ? >>>>>>>>>> + 1.80% [ET_NET 0] libcrypto.so.1.0.1e [.] 0x00000000000e5200 ? >>>>>>>>>> + 1.49% [ET_NET 0] libcrypto.so.1.0.1e [.] sha256_block_data_order ? >>>>>>>>>> + 0.97% [ET_NET 0] libcrypto.so.1.0.1e [.] gcm_ghash_clmul ? >>>>>>>>>> + 0.85% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_lock ? >>>>>>>>>> + 0.84% [ET_NET 0] libcrypto.so.1.0.1e [.] aesni_ctr32_encrypt_blocks ? >>>>>>>>>> + 0.74% [ET_NET 0] libc-2.12.so [.] malloc ? >>>>>>>>>> + 0.72% [ET_NET 0] libc-2.12.so [.] memcpy ? >>>>>>>>>> + 0.57% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_mod_mul_montgomery ? >>>>>>>>>> + 0.51% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_unlock >>>>>>>>>> >>>>>>>>>> pstack of the process (only a couple of the interesting threads): >>>>>>>>>> Thread 1 (Thread 0x7f1fba151800 (LWP 1106)): >>>>>>>>>> #0 0x00007f1fbaaeb264 in __lll_lock_wait () from /lib64/libpthread.so.0 >>>>>>>>>> #1 0x00007f1fbaae6508 in _L_lock_854 () from /lib64/libpthread.so.0 >>>>>>>>>> #2 0x00007f1fbaae63d7 in pthread_mutex_lock () from /lib64/libpthread.so.0 >>>>>>>>>> #3 0x000000000072822f in SSL_locking_callback(int, int, char const*, int) () >>>>>>>>>> #4 0x00000031d2ae7f03 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>>>> #5 0x00000031d2ae7d8c in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>>>> #6 0x00000031d2ae80ab in ERR_get_state () from /usr/lib64/libcrypto.so.10 >>>>>>>>>> #7 0x00000031d2ae8557 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>>>> #8 0x00000031d2e424a9 in SSL_get_error () from /usr/lib64/libssl.so.10 >>>>>>>>>> #9 0x00000000007249ef in SSLNetVConnection::load_buffer_and_write(long, long&, long&, MIOBufferAccessor&, int&) () >>>>>>>>>> #10 0x00000000007389df in write_to_net_io(NetHandler*, UnixNetVConnection*, EThread*) () >>>>>>>>>> #11 0x0000000000738523 in write_to_net(NetHandler*, UnixNetVConnection*, EThread*) () >>>>>>>>>> #12 0x0000000000731922 in NetHandler::mainNetEvent(int, Event*) () >>>>>>>>>> #13 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >>>>>>>>>> #14 0x000000000075877a in EThread::process_event(Event*, int) () >>>>>>>>>> #15 0x0000000000758c84 in EThread::ex >>>>>>>>>> >>>>>>>>>> Thread 56 (Thread 0x7f1fb0ecd700 (LWP 1172)): >>>>>>>>>> #0 0x00007f1fbaae77d9 in pthread_mutex_unlock () from /lib64/libpthread.so.0 >>>>>>>>>> #1 0x0000000000728265 in SSL_locking_callback(int, int, char const*, int) () >>>>>>>>>> #2 0x00000031d2b57402 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>>>> #3 0x00000031d2b574bd in FIPS_selftest_failed () from /usr/lib64/libcrypto.so.10 >>>>>>>>>> #4 0x00000031d2ae9f1c in EVP_DigestInit_ex () from /usr/lib64/libcrypto.so.10 >>>>>>>>>> #5 0x00000031d2a7977e in HMAC_Init_ex () from /usr/lib64/libcrypto.so.10 >>>>>>>>>> #6 0x00000031d2a79c29 in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>>>> #7 0x00000031d2af7a42 in EVP_PKEY_CTX_ctrl () from /usr/lib64/libcrypto.so.10 >>>>>>>>>> #8 0x00000031d2ae9ffb in EVP_DigestInit_ex () from /usr/lib64/libcrypto.so.10 >>>>>>>>>> #9 0x00000031d2af952a in ?? () from /usr/lib64/libcrypto.so.10 >>>>>>>>>> #10 0x00000031d2e34cf2 in tls1_PRF () from /usr/lib64/libssl.so.10 >>>>>>>>>> #11 0x00000031d2e35796 in tls1_final_finish_mac () from /usr/lib64/libssl.so.10 >>>>>>>>>> #12 0x00000031d2e2db2e in ssl3_get_message () from /usr/lib64/libssl.so.10 >>>>>>>>>> #13 0x00000031d2e1dc3c in ssl3_get_cert_verify () from /usr/lib64/libssl.so.10 >>>>>>>>>> #14 0x00000031d2e220d6 in ssl3_accept () from /usr/lib64/libssl.so.10 >>>>>>>>>> #15 0x0000000000725287 in SSLNetVConnection::sslServerHandShakeEvent(int&) () >>>>>>>>>> #16 0x00000000007251b3 in SSLNetVConnection::sslStartHandShake(int, int&) () >>>>>>>>>> #17 0x0000000000723df3 in SSLNetVConnection::net_read_io(NetHandler*, EThread*) () >>>>>>>>>> #18 0x0000000000731852 in NetHandler::mainNetEvent(int, Event*) () >>>>>>>>>> #19 0x00000000004f6d48 in Continuation::handleEvent(int, void*) () >>>>>>>>>> #20 0x000000000075877a in EThread::process_event(Event*, int) () >>>>>>>>>> #21 0x0000000000758c84 in EThread::execute() () >>>>>>>>>> #22 0x0000000000757cf8 in spawn_thread_internal(void*) () >>>>>>>>>> #23 0x00007f1fbaae49d1 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>> #24 0x00000030ff0e88fd in clone () from /lib64/libc.so.6 >>>>>>>>>> >>>>>>>>>> -Bryan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> openssl-users mailing list >>>>>>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> openssl-users mailing list >>>>>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> openssl-users mailing list >>>>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>>>>> >>>>>>> _______________________________________________ >>>>>>> openssl-users mailing list >>>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> openssl-users mailing list >>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>>> >>>>> _______________________________________________ >>>>> openssl-users mailing list >>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>>> >>>> >>>> >>>> _______________________________________________ >>>> openssl-users mailing list >>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> >>> _______________________________________________ >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: