From uri at ll.mit.edu Mon Jul 1 18:07:34 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 1 Jul 2019 18:07:34 +0000 Subject: Current master breaks EC tests Message-ID: <3ABED96A-F9E8-46A0-9139-364D72C7CFE6@ll.mit.edu> You probably noticed, but the current master keeps breaking EC tests for the last week or so. This is on Mac: ../test/recipes/15-test_ec.t ....................... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/5 subtests Test Summary Report ------------------- ../test/recipes/15-test_ec.t (Wstat: 256 Tests: 5 Failed: 1) Failed test: 2 Non-zero exit status: 1 Files=172, Tests=1656, 156 wallclock secs ( 1.28 usr 0.36 sys + 118.03 cusr 31.74 csys = 151.41 CPU) Result: FAIL This is the config string, and the build command: CFLAGS="-Os -Ofast -g -std=gnu17 -march=native" make distclean || true ./config --prefix=$HOME/openssl-1.1 --debug --openssldir=$HOME/openssl-1.1/etc --with-rand-seed=rdcpu enable-aria enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-weak-ssl-ciphers enable-zlib-dynamic enable-ssl-trace Make depend && make clean && make -j 2 all && make test -- Regards, Uri -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: From kgoldman at us.ibm.com Mon Jul 1 20:27:30 2019 From: kgoldman at us.ibm.com (Ken Goldman) Date: Mon, 1 Jul 2019 16:27:30 -0400 Subject: Building a DER sequence In-Reply-To: <9881273A-830E-4EAD-B0A9-E0299919B7CE@akamai.com> References: <9881273A-830E-4EAD-B0A9-E0299919B7CE@akamai.com> Message-ID: On 6/26/2019 11:34 AM, Salz, Rich via openssl-users wrote: > Do I construct a sequence and add items to it - top down? > > No, because then you have to go back and patch the sequence length and perhaps slide everything up or down a copule of bytes. > > I would look at an existing simple sequence and start writing your own based on that; look for ASN1_SEQUENCE macros in crypto/x509/x*.c files. Another set of macros will declare the i2d/d2i and PEM functions if needed. I see those macros, but ... is there any documentation? What partially worked was create an X509 item use i2d to serialize it ASN1_STRING_SET using the DER built an ASN1_TYPE from the ASN1_STRING with ASN1_TYPE_set sk_ASN1_TYPE_push and then i2d_ASN1_SEQUENCE_ANY to get the DER result. The items are _X509_NAME and X509_VAL. Is there a shorter way? From kgoldman at us.ibm.com Mon Jul 1 20:45:36 2019 From: kgoldman at us.ibm.com (Ken Goldman) Date: Mon, 1 Jul 2019 16:45:36 -0400 Subject: Building a DER sequence In-Reply-To: <9881273A-830E-4EAD-B0A9-E0299919B7CE@akamai.com> References: <9881273A-830E-4EAD-B0A9-E0299919B7CE@akamai.com> Message-ID: On 6/26/2019 11:34 AM, Salz, Rich via openssl-users wrote: > Do I construct a sequence and add items to it - top down? > > No, because then you have to go back and patch the sequence length and perhaps slide everything up or down a copule of bytes. > > I would look at an existing simple sequence and start writing your own based on that; look for ASN1_SEQUENCE macros in crypto/x509/x*.c files. Another set of macros will declare the i2d/d2i and PEM functions if needed. [I'm happy to read if someone can point me to an article, but I haven't found anything.] I am stuck on the X509 extensions. I.e., with sample certificates, dumpasn1 shows: [snip] 453 448: . . [3] { 457 444: . . . SEQUENCE { 461 74: . . . . SEQUENCE { 463 3: . . . . . OBJECT IDENTIFIER subjectAltName (2 5 29 17) : . . . . . . (X.509 extension) [snip] What's that [3]? Perhaps it means x509v3? With openssl, it dumps as X509v3 extensions: X509v3 Subject Alternative Name: critical How do I build the x509v3 extensions item (and convert it to an ASN1_TYPE that I can push on the stack. That is, I have the sequence using X509V3_EXT_conf_nid i2d_X509_EXTENSION ASN1_STRING_set but how do I encapsulate that in a [3] and then to an ASN1_TYPE that I can push on the STACK_OF(ASN1_TYPE) stack? ~~ A separate question: I can build an X509_EXTENSION using X509V3_EXT_conf_nid. How would I connect several of them. Would I use STACK_OF(X509_EXTENSION), push the extensions, and then use i2d_something? What's the 'something'. From openssl-users at dukhovni.org Mon Jul 1 21:19:57 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 1 Jul 2019 17:19:57 -0400 Subject: Building a DER sequence In-Reply-To: References: Message-ID: > On Jun 25, 2019, at 10:59 AM, Ken Goldman wrote: > > I have to build a DER byte stream for a sequence containing: > > algorithm ID > issuer > validity > subject name > extensions > > What is the general approach? See for example: https://github.com/openssl/openssl/blob/bc42bd6298702a1abf70aa6383d36886dd5af4b3/crypto/x509/x_x509.c#L18-L31 -- -- Viktor. From rsalz at akamai.com Mon Jul 1 21:40:25 2019 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 1 Jul 2019 21:40:25 +0000 Subject: Building a DER sequence In-Reply-To: References: <9881273A-830E-4EAD-B0A9-E0299919B7CE@akamai.com> Message-ID: > I see those macros, but ... is there any documentation? No. From openssl-users at dukhovni.org Mon Jul 1 22:03:12 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 1 Jul 2019 18:03:12 -0400 Subject: Building a DER sequence In-Reply-To: References: <9881273A-830E-4EAD-B0A9-E0299919B7CE@akamai.com> Message-ID: <20190701220312.GI84864@straasha.imrryr.org> On Mon, Jul 01, 2019 at 09:40:25PM +0000, Salz, Rich via openssl-users wrote: > > I see those macros, but ... is there any documentation? > > No. There's a high-level overview at: https://www.openssl.org/docs/manmaster/man3/X509_dup.html -- Viktor. From icare_kevin at live.nl Tue Jul 2 16:12:12 2019 From: icare_kevin at live.nl (Karel de Henks) Date: Tue, 2 Jul 2019 16:12:12 +0000 Subject: OpenSSL 1.1.1 RPM for CentOS 7 In-Reply-To: References: Message-ID: Hi, I'm searching on the internet for an OpenSSL version 1.1.1. RPM package for CentOS 7. However, I cannot find this. Perhaps one of the users in the mailing list has this package already available. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From lj at acronisscs.com Tue Jul 2 20:13:23 2019 From: lj at acronisscs.com (Larry Jordan) Date: Tue, 2 Jul 2019 20:13:23 +0000 Subject: openssl-fips configure parameters to force IANA cipher suite compliance Message-ID: I want to build an openssl-fips canister to force IANA cipher suite compliance. With the help of an openssl-iana mapping (https://testssl.sh/openssl-iana.mapping.html) I can identify the corresponding OpenSSL cipher suites. IANA OpenSSL TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5246 [0x2f] AES128-SHA TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 [0x3c] AES128-SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246 [0x3d] AES256-SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 [0x9d] AES256-GCM-SHA384 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 [0x67] DHE-RSA-AES128-SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246 [0x6b] DHE-RSA-AES256-SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 [0x9f] DHE-RSA-AES256-GCM-SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 [0xc023] ECDHE-ECDSA-AES128-SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 [0xc02b] ECDHE-ECDSA-AES128-GCM-SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 [0xc024] ECDHE-ECDSA-AES256-SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 [0xc02c] ECDHE-ECDSA-AES256-GCM-SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 [0xc027] ECDHE-RSA-AES128-SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 [0xc02f] ECDHE-RSA-AES128-GCM-SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 [0xc028] ECDHE-RSA-AES256-SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 [0xc030] ECDHE-RSA-AES256-GCM-SHA384 How would I configure openssl-fips to force this precise compliance, eliminating all other cipher suites? Thank you. --Larry C++ Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From dclarke at blastwave.org Tue Jul 2 21:52:34 2019 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 2 Jul 2019 17:52:34 -0400 Subject: OpenSSL 1.1.1 RPM for CentOS 7 In-Reply-To: References: Message-ID: <4004e70e-cf88-ec8f-4121-75221b950d78@blastwave.org> On 7/2/19 12:12 PM, Karel de Henks wrote: > Hi, > > I'm searching on the internet for an OpenSSL version 1.1.1. RPM package > for CentOS 7. > However, I cannot find this. Perhaps one of the users in the mailing > list has this package already available. > On CentOS or RHEL 7 it should be totally trivial to just build it from the sources and install into /usr/local. Why do you ( and others ) feel you *need* a package from some mystery person ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From manjuprasadgm at gmail.com Wed Jul 3 03:44:13 2019 From: manjuprasadgm at gmail.com (manju prasad) Date: Wed, 3 Jul 2019 09:14:13 +0530 Subject: query regarding openssl and FIPS Message-ID: Hi I have two queries. I am new to FIPS validation. The first query is 1. We have a system which is using Arm Cortex-A9 on ThreadX. If I cross compile FIPS module 2.0.16 for Threadx ( Arm Cortex-A9 ) and use openssl 1.0.2s. Can we claim that our product is FIPS compliant ? The second query is 2. One of our client wants to use FIPS module 2.0.5 on a system which is using Arm Cortex-A9 on VxWorks 6.9. If I cross compile FIPS module 2.0.5 for VxWorks 6.9 ( Arm Cortex-A9 ) and use openssl 1.0.2s. Can we claim that our product is FIPS compliant ? Regards Manju -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Jul 3 07:34:10 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 3 Jul 2019 09:34:10 +0200 Subject: openssl-fips configure parameters to force IANA cipher suite compliance In-Reply-To: References: Message-ID: <9996aff3-12df-26a5-ac83-197c6b286799@wisemo.com> On 02/07/2019 22:13, Larry Jordan via openssl-users wrote: > > I want to build an openssl-fips canister to force IANA cipher suite > compliance. > > With the help of an openssl-iana mapping > (https://testssl.sh/openssl-iana.mapping.html) I can identify the > corresponding OpenSSL cipher suites. > Not sure what you mean?? To my knowledge IANA doesn't (and has no authority to) define TLS compliance requirements.? They merely keep a database of various numbers and names assigned in Internet standards ("Internet Assigned Numbers Authority"). And the openssl-fips canister is a very specific, legally defined exact binary that has gone through expensive US-government tests to allow use by said US government, with absolutely no changes permitted, even to fix security bugs! Now it so happens that since long before there were any Internet standards for SSL/TLS, the OpenSSL/SSLeay family of libraries have used slightly different names for the numbered cipher suites, especially the ones that existed before official IETF standards were established. The key spelling differences obviously being: 1. OpenSSL doesn't put TLS_ in front and _WITH_ in the middle of all the ? names, because that just gets in the way when administrators type in ? configuration changes on their servers. 2. OpenSSL uses dash, not underscore. 3. Because it was the historic default, OpenSSL lets you omit the "RSA_" and ? CBC_ in those cipher suite names. 4. OpenSSL omits the _ or - between AES and the bit count, just like IETF ? already does with SHA. 5. For triple-DES (once the strongest common algorithm, and thus still ? needed to talk to older systems), OpenSSL historically considered it a ? variant of the CBC mode for DES, not a variant of DES for CBC mode. ?? Thus the oldest 3DES_CBC cipher suites use DES-CBC3 in their names, ? while the new ones follow IETF naming.? Similarly, DHE_ is spelled EDH- ? in older suites. 6. Whatever user interface a program runs on top of OpenSSL can display the ? names however it wants. 7. If a program wants to map the IETF names to the OpenSSL names, it can ? probably start by doing the string substitutions in differences 1 to 4 ? above, then add some special cases for things like ???? TLS_DHE_RSA_WITH_3DES_CBC_SHA maps via rules to ? ?? DHE-RSA-3DES-CBC-SHA which maps via special case lookup to ???? EDH-RSA-DES-CBC3-SHA 8. To be absolutely sure you handle all known cases, you have to find the ? OpenSSL source file that defines the names and check it against the IANA ? database of cipher suite numbers from IETF standards and non-IETF extensions ? (Such as Camelia and GOST cipher suites). > IANA OpenSSL > > TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5246 [0x2f] AES128-SHA > > TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 [0x3c] > AES128-SHA256 > > TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246 [0x3d] > AES256-SHA256 > > TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 [0x9d] > AES256-GCM-SHA384 > > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 [0x67] > DHE-RSA-AES128-SHA256 > > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246 [0x6b] > DHE-RSA-AES256-SHA256 > > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 [0x9f] > DHE-RSA-AES256-GCM-SHA384 > > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC > 5289?????????????????????????????? [0xc023] ECDHE-ECDSA-AES128-SHA256 > > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC > 5289???????????????????????????? [0xc02b] ECDHE-ECDSA-AES128-GCM-SHA256 > > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC > 5289?????????????????????????????? [0xc024] ECDHE-ECDSA-AES256-SHA384 > > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC > 5289???????????????????????????? [0xc02c] ECDHE-ECDSA-AES256-GCM-SHA384 > > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 [0xc027] > ECDHE-RSA-AES128-SHA256 > > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC > 5289????????????????????????????????? [0xc02f] ECDHE-RSA-AES128-GCM-SHA256 > > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 [0xc028] > ECDHE-RSA-AES256-SHA384 > > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC > 5289????????????????????????????????? [0xc030] ECDHE-RSA-AES256-GCM-SHA384 > > How would I configure openssl-fips to force this precise compliance, > eliminating all other cipher suites? > > Thank you. > > --Larry > > C++ Developer > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 sapoliakaran at gmail.com Wed Jul 3 09:24:20 2019 From: sapoliakaran at gmail.com (Karan) Date: Wed, 3 Jul 2019 14:54:20 +0530 Subject: How to do a clean uninstall of openssl source? Message-ID: I installed openssl from source following the guidelines in https://github.com/openssl/openssl/blob/master/INSTALL . Now I need to remove this source installed version and use the openssl-devel package instead, provided by my distro, Fedora. How do I do a clean uninstall, such that even the headers of the source installation are completely removed and do not interfere with the package I will install next? I am facing this issue wherein the headers are pointing to the source version of openssl and I am unable to use softwares that depend on the package version. (Reference: https://github.com/mozilla/fxa/issues/1569#issuecomment-507651523 ) Help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From janjust at nikhef.nl Wed Jul 3 09:45:34 2019 From: janjust at nikhef.nl (Jan Just Keijser) Date: Wed, 3 Jul 2019 11:45:34 +0200 Subject: OpenSSL 1.1.1 RPM for CentOS 7 In-Reply-To: <4004e70e-cf88-ec8f-4121-75221b950d78@blastwave.org> References: <4004e70e-cf88-ec8f-4121-75221b950d78@blastwave.org> Message-ID: <35a13877-8f5a-9679-a569-a9dc6254ee31@nikhef.nl> On 02/07/19 23:52, Dennis Clarke wrote: > On 7/2/19 12:12 PM, Karel de Henks wrote: >> Hi, >> >> I'm searching on the internet for an OpenSSL version 1.1.1. RPM package for CentOS 7. >> However, I cannot find this. Perhaps one of the users in the mailing list has this package already available. >> > > > On CentOS or RHEL 7 it should be totally trivial to just build it from > the sources and install into /usr/local.? Why do you ( and others ) feel > you *need* a package from some mystery person ? > > added to that : it is not possible (or at the least not worth the effort) to replace the system openssl package (1.0.2k) with a v1.1.1 package, as you would break almost *every* RPM that depends on it. JM2CW, JJK From deepak.redmi2 at gmail.com Wed Jul 3 16:54:49 2019 From: deepak.redmi2 at gmail.com (Dipak B) Date: Wed, 3 Jul 2019 22:24:49 +0530 Subject: Will my application be FIPS 140-2 Certified under following conditions? Message-ID: Dear Experts, Can you please help me with the following question? My win32 desktop application uses 'libcurl' to interact with web service, in order to get my application FIPS 140-2 certified, following is the plan which I arrived at after going through the 'User Guide' and 'Security Policy' pdfs. Plan: a. After verifying HMAC-SHA1 of openssl-fips-2.0.16.tar.gz, build it to generate fipscanister.lib (FOM) as windows static library. b. Build libcurl as windows static library using above fipscanister.lib c. Link my desktop application with above libcurl.lib after adding FIPS_mode_set() Questions: a. On following points a, b,c, can I confirm that my application is FIPS 140-2 certified? b. fipscanister.lib is always static library and it can be substituted for libssl.lib / ssleay.lib? Thank you, Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepak.redmi2 at gmail.com Wed Jul 3 17:04:45 2019 From: deepak.redmi2 at gmail.com (Dipak B) Date: Wed, 3 Jul 2019 22:34:45 +0530 Subject: Can applications built with 'FIPS Capable OpenSSL' be called as 'FIPS 140-2' certified? Message-ID: Dear Experts, Can you please help with the following questions? All inputs are appreciated. a) Can we call an Win32 application built with FIPS Capable OpenSSL as FIPS 140-2 Certified in strict sense? where FIPS Capable OpenSSL is OpenSSL built using the FOM (fipscanister.lib) I am seeking clarity although read through both Users Guide and Security Policy. Thank you, Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jul 3 17:07:45 2019 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 3 Jul 2019 17:07:45 +0000 Subject: Can applications built with 'FIPS Capable OpenSSL' be called as 'FIPS 140-2' certified? In-Reply-To: References: Message-ID: Didn?t you just ask this question? :) If you followed the Win32 build instructions *exactly* and you build your application to turn on FIPS mode and link against the canister, then yes. If you made changes to the process, then no. -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepak.redmi2 at gmail.com Wed Jul 3 17:35:12 2019 From: deepak.redmi2 at gmail.com (Dipak B) Date: Wed, 3 Jul 2019 23:05:12 +0530 Subject: Can applications built with 'FIPS Capable OpenSSL' be called as 'FIPS 140-2' certified? In-Reply-To: References: Message-ID: Hi, Thank you for the quick answer. Both the questions have subtle difference. My apology they appear almost same. So, to clear my doubts, following is my understanding a) An application is FIPS 140-2 certified if and only if it links directly to 'fipscanister.lib'. b) Application which links to 'libcurl.lib' and has no direct called to OpenSSL can be called as FIPS 140-2 certified if and only if the libcurl.lib used is generated using 'fipscanister.lib' Not To be said / just repetition Application linking with ssleay.lib from FIPS capable OpenSSL is not FIPS 140-2 certified. Regards, Deepak On Wed, Jul 3, 2019 at 10:37 PM Salz, Rich wrote: > Didn?t you just ask this question? :) > > > > If you followed the Win32 build instructions **exactly** and you build > your application to turn on FIPS mode and link against the canister, then > yes. > > > > If you made changes to the process, then no. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at jacksch.com Wed Jul 3 17:36:10 2019 From: eric at jacksch.com (Eric Jacksch) Date: Wed, 3 Jul 2019 13:36:10 -0400 Subject: Can applications built with 'FIPS Capable OpenSSL' be called as 'FIPS 140-2' certified? In-Reply-To: References: Message-ID: No, strictly speaking, you cannot. Just because you use a FIPS 140-2 certified cryptographic module doesn't mean that your application is FIPS 140-2 certified. It means that your application includes (or uses) a FIPS 140-2 certified cryptographic module. Or, as it is sometimes called, "FIPS Inside". Any organization that cares will ask for the CMVP certificate number and look it up. The certificate will identify the validated configuration. On Wed, 3 Jul 2019 at 13:05, Dipak B wrote: > > Dear Experts, > > Can you please help with the following questions? > All inputs are appreciated. > > a) Can we call an Win32 application built with FIPS Capable OpenSSL as FIPS 140-2 Certified in strict sense? > where FIPS Capable OpenSSL is OpenSSL built using the FOM (fipscanister.lib) > > I am seeking clarity although read through both Users Guide and Security Policy. > > Thank you, > Deepak -- Eric Jacksch, CPP, CISM, CISSP eric at jacksch.com Twitter: @EricJacksch https://SecurityShelf.com From eric at jacksch.com Wed Jul 3 17:41:25 2019 From: eric at jacksch.com (Eric Jacksch) Date: Wed, 3 Jul 2019 13:41:25 -0400 Subject: Can applications built with 'FIPS Capable OpenSSL' be called as 'FIPS 140-2' certified? In-Reply-To: References: Message-ID: Unless your product (application) is listed on the certificate, it is not FIPS 140-2 certified. Similarly, if you build your own car and drop in an OEM Ford engine, your car does not become a Ford. On Wed, 3 Jul 2019 at 13:35, Dipak B wrote: > > Hi, > > Thank you for the quick answer. > Both the questions have subtle difference. My apology they appear almost same. > > So, to clear my doubts, following is my understanding > > a) An application is FIPS 140-2 certified if and only if it links directly to 'fipscanister.lib'. > > b) Application which links to 'libcurl.lib' and has no direct called to OpenSSL can be called as FIPS 140-2 certified if and only if the > libcurl.lib used is generated using 'fipscanister.lib' > > > Not To be said / just repetition > Application linking with ssleay.lib from FIPS capable OpenSSL is not FIPS 140-2 certified. > > Regards, > Deepak > > On Wed, Jul 3, 2019 at 10:37 PM Salz, Rich wrote: >> >> Didn?t you just ask this question? :) >> >> >> >> If you followed the Win32 build instructions *exactly* and you build your application to turn on FIPS mode and link against the canister, then yes. >> >> >> >> If you made changes to the process, then no. >> >> -- Eric Jacksch, CPP, CISM, CISSP eric at jacksch.com Twitter: @EricJacksch https://SecurityShelf.com From kgoldman at us.ibm.com Wed Jul 3 18:37:35 2019 From: kgoldman at us.ibm.com (Ken Goldman) Date: Wed, 3 Jul 2019 14:37:35 -0400 Subject: Building a DER sequence In-Reply-To: References: Message-ID: On 7/1/2019 5:19 PM, Viktor Dukhovni wrote: > >> On Jun 25, 2019, at 10:59 AM, Ken Goldman wrote: >> >> I have to build a DER byte stream for a sequence containing: >> >> algorithm ID >> issuer >> validity >> subject name >> extensions >> >> What is the general approach? > > See for example: > > https://github.com/openssl/openssl/blob/bc42bd6298702a1abf70aa6383d36886dd5af4b3/crypto/x509/x_x509.c#L18-L31 > Does link just point to array of macros? If so, they don't help without any explanation. From kgoldman at us.ibm.com Wed Jul 3 18:41:10 2019 From: kgoldman at us.ibm.com (Ken Goldman) Date: Wed, 3 Jul 2019 14:41:10 -0400 Subject: Building a DER sequence In-Reply-To: <20190701220312.GI84864@straasha.imrryr.org> References: <9881273A-830E-4EAD-B0A9-E0299919B7CE@akamai.com> <20190701220312.GI84864@straasha.imrryr.org> Message-ID: On 7/1/2019 6:03 PM, Viktor Dukhovni wrote: > On Mon, Jul 01, 2019 at 09:40:25PM +0000, Salz, Rich via openssl-users wrote: >>> I see those macros, but ... is there any documentation? >> >> No. > > There's a high-level overview at: > > https://www.openssl.org/docs/manmaster/man3/X509_dup.html That link points to the X509_dup page. It doesn't explain how to build a DER sequence, does it? From openssl-users at dukhovni.org Wed Jul 3 20:30:11 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 3 Jul 2019 16:30:11 -0400 Subject: Building a DER sequence In-Reply-To: References: <9881273A-830E-4EAD-B0A9-E0299919B7CE@akamai.com> <20190701220312.GI84864@straasha.imrryr.org> Message-ID: <1EB504A8-2BC0-4485-9723-A018B507F2C6@dukhovni.org> On Jul 3, 2019, at 2:41 PM, Ken Goldman wrote: > That link points to the X509_dup page. It doesn't explain how to > build a DER sequence, does it? The documentation is incomplete, and much RTFS is required, but it and code pointers should get you started. -- Viktor. From aerowolf at gmail.com Thu Jul 4 02:06:35 2019 From: aerowolf at gmail.com (Kyle Hamilton) Date: Wed, 3 Jul 2019 21:06:35 -0500 Subject: Will my application be FIPS 140-2 Certified under following conditions? In-Reply-To: References: Message-ID: Step a. needs to verified the digest with an existing FIPS 140-2 validated cryptography implementation. Otherwise, to my understanding, this is the correct sequence of events. Do note that after building the fipscanister.lib, you will want to digest it and print it on a certification letter that it was built as specified in the Security Policy, signed and dated by the person who built it (preferably also with details of the build chain). Also, when you build anything that links that library, you will want to verify the digest against that letter before linking, and write a new letter specifying the product name and version, the digest of the output, and that it was also built in accordance with the Security Policy. This should also be signed and dated. (these letters will help establish for FIPS-requiring procurement agencies that FIPS 140-2 conformance is achieved in,what they are procuring from you.) -Kyle H On Wed, Jul 3, 2019, 11:55 Dipak B wrote: > Dear Experts, > > Can you please help me with the following question? > > My win32 desktop application uses 'libcurl' to interact with web service, > in order to get my application FIPS 140-2 certified, following is the plan > which I arrived at after going through the 'User Guide' and 'Security > Policy' pdfs. > > Plan: > a. After verifying HMAC-SHA1 of openssl-fips-2.0.16.tar.gz, build it to > generate fipscanister.lib (FOM) as windows static library. > b. Build libcurl as windows static library using above fipscanister.lib > c. Link my desktop application with above libcurl.lib after adding > FIPS_mode_set() > > Questions: > a. On following points a, b,c, can I confirm that my application is FIPS > 140-2 certified? > b. fipscanister.lib is always static library and it can be substituted > for libssl.lib / ssleay.lib? > > Thank you, > Deepak > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aerowolf at gmail.com Thu Jul 4 02:09:08 2019 From: aerowolf at gmail.com (Kyle Hamilton) Date: Wed, 3 Jul 2019 21:09:08 -0500 Subject: Will my application be FIPS 140-2 Certified under following conditions? In-Reply-To: References: Message-ID: Also, on question b: No. You need to build a compatible version of openssl as specified in the User Guide, and link that version. FIPS_mode_set() tells the library to always and only use the implementations in the FIPS canister; the canister does not replace the library entirely. -Kyle H On Wed, Jul 3, 2019, 11:55 Dipak B wrote: > Dear Experts, > > Can you please help me with the following question? > > My win32 desktop application uses 'libcurl' to interact with web service, > in order to get my application FIPS 140-2 certified, following is the plan > which I arrived at after going through the 'User Guide' and 'Security > Policy' pdfs. > > Plan: > a. After verifying HMAC-SHA1 of openssl-fips-2.0.16.tar.gz, build it to > generate fipscanister.lib (FOM) as windows static library. > b. Build libcurl as windows static library using above fipscanister.lib > c. Link my desktop application with above libcurl.lib after adding > FIPS_mode_set() > > Questions: > a. On following points a, b,c, can I confirm that my application is FIPS > 140-2 certified? > b. fipscanister.lib is always static library and it can be substituted > for libssl.lib / ssleay.lib? > > Thank you, > Deepak > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at foocrypt.net Thu Jul 4 03:09:39 2019 From: openssl at foocrypt.net (openssl at foocrypt.net) Date: Thu, 4 Jul 2019 13:09:39 +1000 Subject: Will my application be FIPS 140-2 Certified under following conditions? In-Reply-To: References: Message-ID: Deepak Just take note of the FIPS 140-2 sunset, and rise of FIPS 140-3 140-3 Takes Effect: 9/22/19 140-3 New Testing Begins: 9/22/20 140-2 Sunset: 9/21/21 140-3 Mandated: 9/22/21 And best of luck ;) https://www.federalregister.gov/documents/2019/05/01/2019-08817/announcing-issuance-of-federal-information-processing-standard-fips-140-3-security-requirements-for -- Regards, Mark A. Lane ? Mark A. Lane 1980 - 2019, All Rights Reserved. ? FooCrypt 1980 - 2019, All Rights Reserved. ? FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2019, All Rights Reserved. ? Cryptopocalypse 1980 - 2019, All Rights Reserved. > On 4 Jul 2019, at 12:09, Kyle Hamilton wrote: > > Also, on question b: No. You need to build a compatible version of openssl as specified in the User Guide, and link that version. FIPS_mode_set() tells the library to always and only use the implementations in the FIPS canister; the canister does not replace the library entirely. > > -Kyle H > > On Wed, Jul 3, 2019, 11:55 Dipak B > wrote: > Dear Experts, > > Can you please help me with the following question? > > My win32 desktop application uses 'libcurl' to interact with web service, in order to get my application FIPS 140-2 certified, following is the plan which I arrived at after going through the 'User Guide' and 'Security Policy' pdfs. > > Plan: > a. After verifying HMAC-SHA1 of openssl-fips-2.0.16.tar.gz, build it to generate fipscanister.lib (FOM) as windows static library. > b. Build libcurl as windows static library using above fipscanister.lib > c. Link my desktop application with above libcurl.lib after adding FIPS_mode_set() > > Questions: > a. On following points a, b,c, can I confirm that my application is FIPS 140-2 certified? > b. fipscanister.lib is always static library and it can be substituted for libssl.lib / ssleay.lib? > > Thank you, > Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From syedmoulana at yahoo.com Thu Jul 4 08:09:38 2019 From: syedmoulana at yahoo.com (syed moulana) Date: Thu, 4 Jul 2019 08:09:38 +0000 (UTC) Subject: configuring openssl-1.1.1b with -DOPENSSL_TLS_SECURITY_LEVEL=0 References: <849071529.1823892.1562227778383.ref@mail.yahoo.com> Message-ID: <849071529.1823892.1562227778383@mail.yahoo.com> Hi Are we expect to loose the TLS_1.3 security capability if we configure the openssl-1.1.1b security level to?-DOPENSSL_TLS_SECURITY_LEVEL=0 ?orin other words, does it makes TLS_1.3 backwards compatible ?orwe are not using TLS_1.3? if we configure like this. ThanksSyed -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Thu Jul 4 09:21:53 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 4 Jul 2019 11:21:53 +0200 Subject: Will my application be FIPS 140-2 Certified under following conditions? In-Reply-To: References: Message-ID: Is the use of OpenSSL an actual legal requirement of the certification of the FIPS object module, or just the easiest way to use it? Difference would be particularly significant in case someone created code to use the validated FOM 2.0 module with the OpenSSL 1.1.x feature enhancements (as the project itself has indicated no desire to do so). On 04/07/2019 04:09, Kyle Hamilton wrote: > Also, on question b: No.? You need to build a compatible version of > openssl as specified in the User Guide, and link that version.? > FIPS_mode_set() tells the library to always and only use the > implementations in the FIPS canister; the canister does not replace > the library entirely. > > -Kyle H > > On Wed, Jul 3, 2019, 11:55 Dipak B > wrote: > > Dear Experts, > > Can you please help me with the following question? > > My win32 desktop application uses 'libcurl' to interact with web > service, in order to get my application FIPS 140-2 certified, > following is the plan which I arrived at after going through the > 'User Guide' and 'Security Policy' pdfs. > > Plan: > a. After verifying HMAC-SHA1 of openssl-fips-2.0.16.tar.gz, build > it to generate fipscanister.lib (FOM) as windows static library. > b. Build libcurl as windows static library using above > fipscanister.lib > c. Link my desktop application with above libcurl.lib after adding > FIPS_mode_set() > > Questions: > a. On following points a, b,c, can I confirm that my application > is FIPS 140-2 certified? > b.? fipscanister.lib is always static library and it can be > substituted for libssl.lib / ssleay.lib? > From matt at openssl.org Thu Jul 4 09:52:17 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 4 Jul 2019 10:52:17 +0100 Subject: configuring openssl-1.1.1b with -DOPENSSL_TLS_SECURITY_LEVEL=0 In-Reply-To: <849071529.1823892.1562227778383@mail.yahoo.com> References: <849071529.1823892.1562227778383.ref@mail.yahoo.com> <849071529.1823892.1562227778383@mail.yahoo.com> Message-ID: <11f321df-c2d1-e7c9-58b1-18c1e200791a@openssl.org> On 04/07/2019 09:09, syed moulana via openssl-users wrote: > Are we expect to loose the TLS_1.3 security capability if we configure the > openssl-1.1.1b security level to?-DOPENSSL_TLS_SECURITY_LEVEL=0 ? > or > in other words, does it makes TLS_1.3 backwards compatible ? > or > we are not using TLS_1.3? if we configure like this. That define should have no impact at all on whether TLSv1.3 is available or not. Setting the default security level to 0 (instead of the default which is 1), will mean that parameters offering less that 80 "security bits" are allowed. For example DH keys shorter than 1024 bits would be accepted, as would ECC keys shorter than 160 bits. TLSv1.3 imposes its own limits irrespective of the security level. So for DH and ECC you are only allowed to use specific parameters which would always give you keys that are greater than the above anyway. Where TLSv1.3 is more restrictive than the specified security level, then the TLSv1.3 restrictions still apply. Having said all of that I would advise against setting this define at all. The default is 1 for a reason. Allowing weaker security than that is usually a bad idea. Matt From paul.dale at oracle.com Thu Jul 4 10:03:17 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Thu, 4 Jul 2019 20:03:17 +1000 Subject: Will my application be FIPS 140-2 Certified under following conditions? In-Reply-To: References: Message-ID: The FOM is stand alone in theory. I.e. it isn?t mandatory to use OpenSSL 1.0 but the two are designed to work together and are very closely intertwined. Moving the FIPS canister forward to 1.1 would be a lot of effort. Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 4 Jul 2019, at 7:21 pm, Jakob Bohm via openssl-users wrote: > > Is the use of OpenSSL an actual legal requirement of the certification of > the FIPS object module, or just the easiest way to use it? > > Difference would be particularly significant in case someone created code > to use the validated FOM 2.0 module with the OpenSSL 1.1.x feature > enhancements (as the project itself has indicated no desire to do so). > > On 04/07/2019 04:09, Kyle Hamilton wrote: >> Also, on question b: No. You need to build a compatible version of openssl as specified in the User Guide, and link that version. FIPS_mode_set() tells the library to always and only use the implementations in the FIPS canister; the canister does not replace the library entirely. >> >> -Kyle H >> >> On Wed, Jul 3, 2019, 11:55 Dipak B > wrote: >> >> Dear Experts, >> >> Can you please help me with the following question? >> >> My win32 desktop application uses 'libcurl' to interact with web >> service, in order to get my application FIPS 140-2 certified, >> following is the plan which I arrived at after going through the >> 'User Guide' and 'Security Policy' pdfs. >> >> Plan: >> a. After verifying HMAC-SHA1 of openssl-fips-2.0.16.tar.gz, build >> it to generate fipscanister.lib (FOM) as windows static library. >> b. Build libcurl as windows static library using above >> fipscanister.lib >> c. Link my desktop application with above libcurl.lib after adding >> FIPS_mode_set() >> >> Questions: >> a. On following points a, b,c, can I confirm that my application >> is FIPS 140-2 certified? >> b. fipscanister.lib is always static library and it can be >> substituted for libssl.lib / ssleay.lib? >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhyri.k at gmail.com Thu Jul 4 14:37:37 2019 From: bhyri.k at gmail.com (bhyri kalyan) Date: Thu, 4 Jul 2019 20:07:37 +0530 Subject: The SWEET32 Issue, CVE-2016-2183 on Openssl package. In-Reply-To: References: Message-ID: Hi All, Please respond to my below query. Currently we are using openssl_1_0_2r version and we ran the Nessus tool on this openssl version code found The SWEET32 ( https://www.openssl.org/blog/blog/2016/08/24/sweet32/) Issue. So to resolve that issue I am trying to disable the ?3des? ciphers or to use only HIGH ciphers instead. Can you please providing some inputs for making openssl package to use only HIGH ciphers or let me know how to disable ?3des? cipher in openssl ( I already tried by keeping ?no-3des? but it doesn?t work). Thanks & Regards kalyan On Thu, 4 Jul 2019 at 15:06, Matt Caswell wrote: > > > On 04/07/2019 05:36, bhyri kalyan wrote: > > Hi Team, > > > > I already subscribed to mailing list still getting this notice.so can > you please > > respond to my below query. > > I couldn't see your name in the subscriber list, so it looks like your > subscription request did not work for some reason. Anyway I have manually > subscribed you now. > > Please resend your email to openssl-users at openssl.org, and hopefully it > should > go through this time. > > Matt > > > > > > Thanks, > > kalyan > > > > > > On Thu, 4 Jul 2019 at 09:22, > > wrote: > > > > In order to post a message to this mailing list, you must be > > subscribed to it. > > > > Please visit https://mta.openssl.org/mailman/listinfo to join any > > openssl mailing lists. > > > > If you are subscribed, but still get this notice, you can send email > > to openssl-users-owner at openssl.org openssl-users-owner at openssl.org>. > > > > > > > > > > ---------- Forwarded message ---------- > > From: bhyri kalyan > > > To: openssl-users at openssl.org > > Cc: > > Bcc: > > Date: Thu, 4 Jul 2019 09:21:53 +0530 > > Subject: The SWEET32 Issue, CVE-2016-2183 on Openssl package. > > > > Hi All, > > > > > > Currently we are using openssl_1_0_2r version and we ran the Nessus > tool on > > this openssl version code found The SWEET32 > > Issue. > > > > So to resolve that issue I am trying to disable the ?3des? ciphers > or to > > use only HIGH ciphers instead. > > > > Can you please providing some inputs for making openssl package to > use only > > HIGH ciphers or let me know how to disable ?3des? cipher in openssl > ( I > > already tried by keeping ?no-3des? but it doesn?t work). > > > > > > Thanks, > > > > kalyan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Jul 4 14:44:01 2019 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 4 Jul 2019 14:44:01 +0000 Subject: Will my application be FIPS 140-2 Certified under following conditions? In-Reply-To: References: Message-ID: <089D62A1-AF13-4AF2-9FA5-0BD4EE7D4B68@akamai.com> > Is the use of OpenSSL an actual legal requirement of the certification of the FIPS object module, or just the easiest way to use it? I'm not sure who you are asking this. The exiting FIPS validations for OpenSSL only cover the 1.0.2 based source code. > Difference would be particularly significant in case someone created code to use the validated FOM 2.0 module with the OpenSSL 1.1.x feature enhancements (as the project itself has indicated no desire to do so). They would have to get their own validation, their own lab to verify, etc., etc. From jb-openssl at wisemo.com Fri Jul 5 10:19:53 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 5 Jul 2019 12:19:53 +0200 Subject: Will my application be FIPS 140-2 Certified under following conditions? In-Reply-To: <089D62A1-AF13-4AF2-9FA5-0BD4EE7D4B68@akamai.com> References: <089D62A1-AF13-4AF2-9FA5-0BD4EE7D4B68@akamai.com> Message-ID: On 04/07/2019 16:44, Salz, Rich wrote: >> Is the use of OpenSSL an actual legal requirement of the certification of > the FIPS object module, or just the easiest way to use it? > > I'm not sure who you are asking this. > > The exiting FIPS validations for OpenSSL only cover the 1.0.2 based source code. > >> Difference would be particularly significant in case someone created code > to use the validated FOM 2.0 module with the OpenSSL 1.1.x feature > enhancements (as the project itself has indicated no desire to do so). > > They would have to get their own validation, their own lab to verify, etc., etc. > > That seems to contradict the other answer, which is that legally, the FIPS cannister (properly built) can be used with any software outside the cryptographic boundary, the soon-to-be-deprecated OpenSSL 1.0.2 library just being the normal default. If the other answer is correct, it should be perfectly OK (legally) for someone to modify OpenSSL 1.1.1 source code to call the FIPS canister for everything, and the result should be an application that is as FIPS "compliant" as an application that runs something unrelated (such as Apache mod_ssl) on top of OpenSSL-1.0.2 on top of FOM 2.x , thus no new validation required. The point is that some people may soon be in a desperate need to find a FIPS-capable replacement for OpenSSL 1.0.x. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 rsalz at akamai.com Sat Jul 6 14:30:04 2019 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 6 Jul 2019 14:30:04 +0000 Subject: Will my application be FIPS 140-2 Certified under following conditions? In-Reply-To: References: <089D62A1-AF13-4AF2-9FA5-0BD4EE7D4B68@akamai.com> Message-ID: <587C57E2-BA53-47F1-BC69-0C90970A2A2A@akamai.com> >> They would have to get their own validation, their own lab to verify, etc., etc. > That seems to contradict the other answer, which is that legally, the > FIPS cannister (properly built) can be used with any software outside > the cryptographic boundary, the soon-to-be-deprecated OpenSSL 1.0.2 > library just being the normal default. You are correct. My statement, which was technically incorrect, is more likely to be realistic :) > The point is that some people may soon be in a desperate need to find a FIPS-capable replacement for OpenSSL 1.0.x. It seems to me that the easiest thing to do is maintain that release of OpenSSL by themselves. If someone is thinking of fitting OpenSSL 1.1.x to become a user of the existing FOM, then they will probably find it easier to, well, just maintain what currently works. Just because something is past "end of life" does not mean that anyone's ability to use it is revoked. It just means that keeping it working is their responsibility. Anyone can use the FOM until it expires (sunsets is the term used), which lasts one year beyond 1.0.2 as I recall. See https://www.openssl.org/blog/blog/2018/05/18/new-lts/ for some more information on this. From jb-openssl at wisemo.com Mon Jul 8 04:30:37 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 8 Jul 2019 06:30:37 +0200 Subject: Will my application be FIPS 140-2 Certified under following conditions? In-Reply-To: <587C57E2-BA53-47F1-BC69-0C90970A2A2A@akamai.com> References: <089D62A1-AF13-4AF2-9FA5-0BD4EE7D4B68@akamai.com> <587C57E2-BA53-47F1-BC69-0C90970A2A2A@akamai.com> Message-ID: <189b9538-cafd-5e91-629e-66113b506455@wisemo.com> On 06/07/2019 16:30, Salz, Rich wrote: > > >> They would have to get their own validation, their own lab to verify, etc., etc. >> That seems to contradict the other answer, which is that legally, the >> FIPS cannister (properly built) can be used with any software outside >> the cryptographic boundary, the soon-to-be-deprecated OpenSSL 1.0.2 >> library just being the normal default. > > You are correct. My statement, which was technically incorrect, is more likely to be realistic :) > >> The point is that some people may soon be in a desperate need to find a > FIPS-capable replacement for OpenSSL 1.0.x. > > It seems to me that the easiest thing to do is maintain that release of OpenSSL by themselves. Which would be another variation of such unofficial work. > > If someone is thinking of fitting OpenSSL 1.1.x to become a user of the existing FOM, then they will probably find it easier to, well, just maintain what currently works. > > Just because something is past "end of life" does not mean that anyone's ability to use it is revoked. It just means that keeping it working is their responsibility. Anyone can use the FOM until it expires (sunsets is the term used), which lasts one year beyond 1.0.2 as I recall. See https://www.openssl.org/blog/blog/2018/05/18/new-lts/ for some more information on this. > > That policy page is half the problem, the other half being the decision not to make a FIPS module for the current 1.1.x series. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 paul.dale at oracle.com Mon Jul 8 08:12:24 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Mon, 8 Jul 2019 18:12:24 +1000 Subject: Will my application be FIPS 140-2 Certified under following conditions? In-Reply-To: <189b9538-cafd-5e91-629e-66113b506455@wisemo.com> References: <089D62A1-AF13-4AF2-9FA5-0BD4EE7D4B68@akamai.com> <587C57E2-BA53-47F1-BC69-0C90970A2A2A@akamai.com> <189b9538-cafd-5e91-629e-66113b506455@wisemo.com> Message-ID: <83574669-C0C3-4BB0-81F3-946E2F2AE508@oracle.com> I have to disagree with the ?decision not to make a FIPS module for the current 1.1.x series? comment. Technically, this is true. More practically, 3.0 is intended to be source compatible with 1.1.x. Thus far, nothing should be broken in this respect. If support for 1.0.2 is required beyond the end of this year, it is available: https://www.openssl.org/support/contracts.html I?d also be interested to know what is wrong with the policy page? Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 8 Jul 2019, at 2:30 pm, Jakob Bohm via openssl-users wrote: > > On 06/07/2019 16:30, Salz, Rich wrote: >> >> They would have to get their own validation, their own lab to verify, etc., etc. >>> That seems to contradict the other answer, which is that legally, the >>> FIPS cannister (properly built) can be used with any software outside >>> the cryptographic boundary, the soon-to-be-deprecated OpenSSL 1.0.2 >>> library just being the normal default. >> You are correct. My statement, which was technically incorrect, is more likely to be realistic :) >> >>> The point is that some people may soon be in a desperate need to find a >> FIPS-capable replacement for OpenSSL 1.0.x. >> It seems to me that the easiest thing to do is maintain that release of OpenSSL by themselves. > > Which would be another variation of such unofficial work. > >> If someone is thinking of fitting OpenSSL 1.1.x to become a user of the existing FOM, then they will probably find it easier to, well, just maintain what currently works. >> Just because something is past "end of life" does not mean that anyone's ability to use it is revoked. It just means that keeping it working is their responsibility. Anyone can use the FOM until it expires (sunsets is the term used), which lasts one year beyond 1.0.2 as I recall. See https://www.openssl.org/blog/blog/2018/05/18/new-lts/ for some more information on this. > > That policy page is half the problem, the other half being the decision > not to make a FIPS module for the current 1.1.x series. > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 Mon Jul 8 09:18:35 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 8 Jul 2019 11:18:35 +0200 Subject: Will my application be FIPS 140-2 Certified under following conditions? In-Reply-To: <83574669-C0C3-4BB0-81F3-946E2F2AE508@oracle.com> References: <089D62A1-AF13-4AF2-9FA5-0BD4EE7D4B68@akamai.com> <587C57E2-BA53-47F1-BC69-0C90970A2A2A@akamai.com> <189b9538-cafd-5e91-629e-66113b506455@wisemo.com> <83574669-C0C3-4BB0-81F3-946E2F2AE508@oracle.com> Message-ID: On 08/07/2019 10:12, Dr Paul Dale wrote: > I have to disagree with the ?decision not to make a FIPS module for > the current 1.1.x series? comment. ?Technically, this is true. ?More > practically, 3.0 is intended to be source compatible with 1.1.x. ?Thus > far, nothing should be broken in this respect. > The key word is "intended". > If support for 1.0.2 is required beyond the end of this year, it is > available: https://www.openssl.org/support/contracts.html > I am unsure if this is an affordable route for all affected users and distributions (especially non-profit OS distributions). > > I?d also be interested to know what is wrong with the policy page? > Only that it states the policy of stopping 1.0.2 support at end of 2019, which would be fine if a FIPS-capable replacement had been ready by now (as is fortunately the case for non-FIPS). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 paul.dale at oracle.com Mon Jul 8 10:30:58 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Mon, 8 Jul 2019 20:30:58 +1000 Subject: Will my application be FIPS 140-2 Certified under following conditions? In-Reply-To: References: <089D62A1-AF13-4AF2-9FA5-0BD4EE7D4B68@akamai.com> <587C57E2-BA53-47F1-BC69-0C90970A2A2A@akamai.com> <189b9538-cafd-5e91-629e-66113b506455@wisemo.com> <83574669-C0C3-4BB0-81F3-946E2F2AE508@oracle.com> Message-ID: <950E9AA0-0B51-446B-A35A-D2EE21CA26F2@oracle.com> I think it?s worth pointing out that OpenSSL is itself a non-profit and that FIPS validations cost a significant amount of money. Until about a year ago, there was also a notable absence of FIPS sponsors. Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 8 Jul 2019, at 7:18 pm, Jakob Bohm via openssl-users wrote: > > On 08/07/2019 10:12, Dr Paul Dale wrote: >> I have to disagree with the ?decision not to make a FIPS module for the current 1.1.x series? comment. Technically, this is true. More practically, 3.0 is intended to be source compatible with 1.1.x. Thus far, nothing should be broken in this respect. >> > The key word is "intended". > >> If support for 1.0.2 is required beyond the end of this year, it is available: https://www.openssl.org/support/contracts.html >> > I am unsure if this is an affordable route for all affected users > and distributions (especially non-profit OS distributions). > >> >> I?d also be interested to know what is wrong with the policy page? >> > > Only that it states the policy of stopping 1.0.2 support at end of > 2019, which would be fine if a FIPS-capable replacement had been > ready by now (as is fortunately the case for non-FIPS). > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 rsalz at akamai.com Mon Jul 8 12:29:47 2019 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 8 Jul 2019 12:29:47 +0000 Subject: Will my application be FIPS 140-2 Certified under following conditions? In-Reply-To: <189b9538-cafd-5e91-629e-66113b506455@wisemo.com> References: <089D62A1-AF13-4AF2-9FA5-0BD4EE7D4B68@akamai.com> <587C57E2-BA53-47F1-BC69-0C90970A2A2A@akamai.com> <189b9538-cafd-5e91-629e-66113b506455@wisemo.com> Message-ID: > It seems to me that the easiest thing to do is maintain that release of OpenSSL by themselves. > Which would be another variation of such unofficial work. You could look at things like that. I consider it to be more like "your free FIPS ride is done, time to pay up" > That policy page is half the problem, the other half being the decision not to make a FIPS module for the current 1.1.x series. There are many problems with the current FOM. One notable example, is that you cannot have a single executable that handles both FIPS and non-FIPS TLS connections at the same time. Another is the way the whole integrity check is done. I could go on and on, but won't. The project spent a long time discussing and considering alternatives and decided a new start was the best way to move forwards. It was a carefully-considered decision. The fact that it "left a coverage gap" in FIPS/1.0.2 was also discussed. It's too bad not everyone is pleased. Probably those who didn't plan well, and/or who just got "FIPS for free" and expected that to last forever seem to be among those particular unhappy. Speaking for myself, AND NOT THE PROJECT, too bad. From shivakumar2696 at gmail.com Wed Jul 10 05:10:32 2019 From: shivakumar2696 at gmail.com (shiva kumar) Date: Wed, 10 Jul 2019 10:40:32 +0530 Subject: How to list ssl3 ciphers Message-ID: Hi, How to List the ssl3 ciphers in openssl1.1.1 The command "openssl ciphers -ssl3" is not working. Please help me Thanks and Regards Shivakumar -- *With Best Regards* *Shivakumar S* -------------- next part -------------- An HTML attachment was scrubbed... URL: From shiva.lear at gmail.com Wed Jul 10 05:57:51 2019 From: shiva.lear at gmail.com (shiva kumar) Date: Wed, 10 Jul 2019 11:27:51 +0530 Subject: RFC 6347 : 4.2.8. Establishing New Associations with Existing Parameters Message-ID: Hi, Does openSSL implement the section "4.2.8. Establishing New Associations with Existing Parameters" in RFC 6347 I tried to test the feature with "openssl-1.1.1c" but couldn't simulate the same. Some details about my sample test: Client: 1. Initiate a connection request for DTLS 1.2(target on a particular IP/port) 2. Then close the DTLS connection(abruptly and not sending SSL shutdown message) 3. Try to initiate a second connection request to same target on the same initial IP/port Server: 1. Accept the DTLS connection request (cookie exchange mechanism enabled) 2. Then call SSL_read to read the application data over DTLS 3. But it will get a connection request from client side(Basically client hello) Observation: 1. The client hangs in second handshake just retransmitting client hellos 2. The server just hangs in SSL_read(probably dropping the client hello messages) Thanks in advance for the help! -------------- next part -------------- An HTML attachment was scrubbed... URL: From swamy.j-s at in.abb.com Wed Jul 10 09:51:01 2019 From: swamy.j-s at in.abb.com (Swamy J-S) Date: Wed, 10 Jul 2019 09:51:01 +0000 Subject: How to set "e" in RSA structure ? Message-ID: Recently i upgraded openssl from 1.0.2 to 1.1.0. As RSA structure is opaque in new opnessl i made some modifications in my code as follows : Old Code RSA* rsa = EVP_PKEY_get1_RSA(PKey); if(NULL != rsa) { if(!BN_set_word(rsa->e, 65537) || !EVP_PKEY_set1_RSA(PKey, rsa)) -------------------------------------------------------------------------------------------------- New Code RSA* rsa = EVP_PKEY_get1_RSA(PKey); BIGNUM *e_new = BN_new(); if(NULL != rsa) { if(!BN_set_word(e_new, 65537) || !EVP_PKEY_set1_RSA(PKey, rsa)) But Now "e" variable is not set in 'rsa', So how to set "e" inside rsa? Pls suggest me corresponding API Thanks and Regards, SWAMY J S -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Jul 10 11:18:30 2019 From: levitte at openssl.org (Richard Levitte) Date: Wed, 10 Jul 2019 13:18:30 +0200 Subject: How to set "e" in RSA structure ? In-Reply-To: References: Message-ID: <87d0iixhmh.wl-levitte@openssl.org> RSA_set0_key() is the function you should use. For more information, do 'man RSA_set0_key', or have a look here: https://www.openssl.org/docs/man1.1.0/man3/RSA_set0_key.html Cheers, Richard On Wed, 10 Jul 2019 11:51:01 +0200, Swamy J-S wrote: > > > Recently i upgraded openssl from 1.0.2 to 1.1.0. As RSA structure is opaque in new opnessl i made > some modifications in my code as follows : > > Old Code > > RSA* rsa = EVP_PKEY_get1_RSA(PKey); > > if(NULL != rsa) > > { > > if(!BN_set_word(rsa->e, 65537) || !EVP_PKEY_set1_RSA(PKey, rsa)) > > -------------------------------------------------------------------------------------------------- > > New Code > > RSA* rsa = EVP_PKEY_get1_RSA(PKey); > > BIGNUM *e_new = BN_new(); > > if(NULL != rsa) > > { > > if(!BN_set_word(e_new, 65537) || !EVP_PKEY_set1_RSA(PKey, rsa)) > > But Now "e" variable is not set in 'rsa', So how to set "e" inside rsa? Pls suggest me > corresponding API > > Thanks and Regards, > > SWAMY J S > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kgoldman at us.ibm.com Wed Jul 10 17:40:25 2019 From: kgoldman at us.ibm.com (Ken Goldman) Date: Wed, 10 Jul 2019 13:40:25 -0400 Subject: Building a DER sequence In-Reply-To: <1EB504A8-2BC0-4485-9723-A018B507F2C6@dukhovni.org> References: <9881273A-830E-4EAD-B0A9-E0299919B7CE@akamai.com> <20190701220312.GI84864@straasha.imrryr.org> <1EB504A8-2BC0-4485-9723-A018B507F2C6@dukhovni.org> Message-ID: <17de75b0-51aa-a456-e1c7-478a7daab003@us.ibm.com> On 7/3/2019 4:30 PM, Viktor Dukhovni wrote: > On Jul 3, 2019, at 2:41 PM, Ken Goldman wrote: > >> That link points to the X509_dup page. It doesn't explain how to >> build a DER sequence, does it? > > The documentation is incomplete, and much RTFS is required, but it > and code pointers should get you started. Here's what I have today. I have a STACK_OF(ASN1_TYPE) to which I have added the issuer, validity, and subject. I can get the DER with i2d_ASN1_SEQUENCE_ANY. I have a STACK_OF(X509_EXTENSION) to which I have added several extensions. Questions: 1 - Is the an API sequence to add the extension STACK to the asn1_type STACK? 2 - If not, is there an API sequence to get the DER for the extension STACK. If so, I can append it and adjust the overall length. 3 - Is there a way to get the extension DER from a standard x509 certificate. If so, I can create it and pull out what I need. 4 - I'm trying to create DER that includes only issuer, validity, subject, and extensions. It's not a standard X509 certificate. Is there a better way? From kerry-fly at 163.com Thu Jul 11 07:05:50 2019 From: kerry-fly at 163.com (anyegongjue) Date: Thu, 11 Jul 2019 00:05:50 -0700 (MST) Subject: How to use openssl smine sign the email body only Message-ID: <1562828750886-0.post@n7.nabble.com> Hi there, I created a script to use "openssl smine" to sign emails in Postfix. The script is running the command below. openssl smime -sign -signer /etc/letsencrypt/live/mail.xxx.xxx/cert.pem -inkey /etc/letsencrypt/live/mail.xxx.xxx/privkey.pem -in $MESSAGEFILE -out $OUTFILE || { echo Problem signing message; exit $EX_UNAVAILABLE; } The $MESSAGEFILE is email content and $OUTFILE stores the output signed email file. The script is running without any problem and email can be sent to mail box. But the problem is smine signed the whole email included the existing headers. So is there a way to let smine only sign the email body? Here is the email signed by smine. *Received: from mail.xxx.xxx (unknown [xxx.xxx.xxx.xxx]) by mx21 (Coremail) with SMTP id R8CowACXTp+M2CZdostiCQ--.63511S3; Thu, 11 Jul 2019 14:34:56 +0800 (CST) Received: from mail.xxx.xxx (localhost [127.0.0.1]) by mail.xxx.xxx (Postfix) with ESMTP id A0C2AC149A0 for ; Thu, 11 Jul 2019 16:34:48 +1000 (AEST) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha-256"; boundary="----B0D2B6501759DF22E6B9827580C1C8D1" X-CM-TRANSID:R8CowACXTp+M2CZdostiCQ--.63511S3 Message-Id:<5D26D898.876B91.32184 at m12-71.email.com> Authentication-Results: mx21; spf=pass smtp.mail=sender at email.com soft.com.au; X-Coremail-Antispam: 1Uf129KBjvJXoWxWr47KFW7ArW5JF4UurW8Crg_yoW5Ar1kpF W2g3sFkr1kZF1Iyas7ArW8WrySvrn8Kr48Gw1DK3yUAws8uryjkF1rtw4UKa9rGFWxX3yY ga1jqasruFZ0qrJanT9S1TB71UUUUUDqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jmc_fUUUUU= Date: Thu, 11 Jul 2019 14:35:04 +0800 (CST) From: email_marketing at xxx.xxx This is an S/MIME signed message ------B0D2B6501759DF22E6B9827580C1C8D1* Received: from localhost (localhost [127.0.0.1]) by mail.xxx.xxx (Postfix) with ESMTP for ; Thu, 11 Jul 2019 16:34:48 +1000 (AEST) X-Virus-Scanned: amavisd-new at xxx.xxx Received: from mail.xxx.xxx ([127.0.0.1]) by localhost (mail.xxx.xxx [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HpBOnD__tFYe for ; Thu, 11 Jul 2019 16:34:47 +1000 (AEST) Received: from XXXMail (unknown [52.65.226.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: email_marketing at xxx.xxx) by mail.xxx.xxx (Postfix) with ESMTPSA id 2A4DBC149A2 for ; Thu, 11 Jul 2019 16:34:47 +1000 (AEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.xxx.xxx 2A4DBC149A2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xxx.xxx; s=default; t=1562826887; bh=zEHSRite2Oj6+gkb5XLOEibTqoyx4wfkxFvtHbrgboU=; h=Date:To:From:Reply-To:Subject:List-Unsubscribe:List-Owner:From; b=Zo7Rkn89Oe8ekeFfgvtJa/KHdIyI1NeZzyL7XQ8g7c4VIWTVOJC813l44rwAUje08 XSnf9HLzrJy4I4suANkrmXNIF6w/UEZ/S1+qoydQE2kmlDql3p9hWDN4t4roGcCrrB wDgdcY4vgvld1kjh6a/sggmr4BiKG4LY0g5OfeqjxX22g1anWCY5fBB6LHrJrmR48V N2eQE+CRJED2ZHjC+rhf83aD4h81jt6OhVNwuIMR2nlMBBdcegibfqCw6lMd3eZrLE iGgHZ6dX/TrU/TZP7rC0B9IvXKcGbfIrw1KZ71McSiVw5U+JtZqa77YT9PErWj5KnS t+J4FVB37jpMA== Received: from localhost [127.0.0.1] by with HTTP; Thu, 11 Jul 2019 16:34:47 +1000 Date: Thu, 11 Jul 2019 16:34:47 +1000 To: Kerry Fly From: email_marketing at xxx.xxx Reply-To: email_marketing at xxx.xxx Subject: New T-shirt arrived Message-ID: X-Mailer: XXXMailer X-MessageID: ABsLBhQBCAA X-ListMember: receiver at email.com Precedence: bulk List-Unsubscribe: List-Owner: Error-To: email_marketing_bounce at xxx.xxx Bounces-To: email_marketing_bounce at xxx.xxx MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_ORDt9z28HeX7Kjig9mfHqz3QrAshMFkHNSeHdTELDY" This is a multi-part message in MIME format. --b1_ORDt9z28HeX7Kjig9mfHqz3QrAshMFkHNSeHdTELDY Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable View in browser ConfigurationSession configuration is stored in=C2=A0Configur= e=C2=A0under the top level=C2=A0Session=C2=A0key, and a number of options a= re available:Session.cookie=C2=A0- Change the name of the session cookie.Se= ssion.timeout=C2=A0- The number of=C2=A0minutes=C2=A0before CakePHP= =E2=80=99s session handler expires the session. ... For more information about and how to integrate it inside your applications= MADE BY ARTUR ARSENIEVClick here to unsubscribe. --b1_ORDt9z28HeX7Kjig9mfHqz3QrAshMFkHNSeHdTELDY Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09 ... --b1_ORDt9z28HeX7Kjig9mfHqz3QrAshMFkHNSeHdTELDY-- ------B0D2B6501759DF22E6B9827580C1C8D1 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIIFAYJKoZIhvcNAQcCoIIIBTCCCAECAQExDzANBglghkgBZQMEAgEFADALBgkq hkiG9w0BBwGgggVmMIIFYjCCBEqgAwIBAgISA2D+gfTao7ImMR5FeJceYRQOMA0G CSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNy ... DXxa77+7AlgOHRJnW0wnk4kUCKTkH74vD8s0TpPsrc7qKZlHLjQO/tkoa/Ea1ogD kzryl95Vwls= *------B0D2B6501759DF22E6B9827580C1C8D1--* -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From numamaheswari at pulsesecure.net Thu Jul 11 09:56:47 2019 From: numamaheswari at pulsesecure.net (Umamaheswari Nagarajan) Date: Thu, 11 Jul 2019 09:56:47 +0000 Subject: OpenSSL Upgrade to 1.1.1c from very old version Message-ID: Hi, In couple of modules in our product, we use very older version of OpenSSL (0.97e) which are statically linked. We wanted to upgrade it to the latest version (1.1.1c) and also remove the static linking. Query- Can we upgrade from OpenSSL 0.97e to OpenSSL 1.1.1c directly or we have to move to some other lower version first and then proceed with 1.1.1c Please advise us. Thanks, Uma -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tobias.Wolf at t-systems.com Thu Jul 11 10:00:27 2019 From: Tobias.Wolf at t-systems.com (Tobias.Wolf at t-systems.com) Date: Thu, 11 Jul 2019 10:00:27 +0000 Subject: RAND_seed buffer freeing Message-ID: I`ve one question regarding RAND_seed, the first parameter refers to a buffer, who is freeing that buffer afterwards? Can I free it after the call to RAND_seed or is this done by openssl? -------------- next part -------------- An HTML attachment was scrubbed... URL: From shiva.lear at gmail.com Thu Jul 11 10:08:10 2019 From: shiva.lear at gmail.com (shiva kumar) Date: Thu, 11 Jul 2019 15:38:10 +0530 Subject: looks like the support for Heart beat extension is removed from openssl Message-ID: Hi , Why the support for Heart beat extension is removed from openssl. I am referring latest version of openssl(openssl-1.1.1c) How to handle abnormal disconnection in DTLS? Thanks! Shiva -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Thu Jul 11 10:08:28 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 11 Jul 2019 13:08:28 +0300 Subject: OpenSSL Upgrade to 1.1.1c from very old version In-Reply-To: References: Message-ID: Hello, On Thu, Jul 11, 2019 at 12:58 PM Umamaheswari Nagarajan < numamaheswari at pulsesecure.net> wrote: > Hi, > > > > In couple of modules in our product, we use very older version of OpenSSL > (0.97e) which are statically linked. > > > > We wanted to upgrade it to the latest version (1.1.1c) and also remove the > static linking. > > > > Query- Can we upgrade from OpenSSL 0.97e to OpenSSL 1.1.1c directly or we > have to move to some other lower version first and then proceed with 1.1.1c > > > > Please advise us. > > > 99,9% you'll have to fix your openssl calls. Most of data structures became opaque and you'll need to fix access to separate fields if any. If you used algorithm-specific methods instead of EVP, you probably have to rewrite this calls. It's only a part of the changes happened since 0.9.7. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From shivakumar2696 at gmail.com Thu Jul 11 11:00:07 2019 From: shivakumar2696 at gmail.com (shiva kumar) Date: Thu, 11 Jul 2019 16:30:07 +0530 Subject: How to list ssl3 ciphers In-Reply-To: References: Message-ID: HI, In OpenSSL 1.1.1 documentation it is mentioned as -ssl3 option is there as follows, *openssl* *ciphers* [*-help*] [*-s*] [*-v*] [*-V*] [*-ssl3*] [*-tls1*] [ *-tls1_1*] [*-tls1_2*] [*-tls1_3*] [*-s*] [*-psk*] [*-srp*] [*-stdname*] [*-convert name*] [*-ciphersuites val*] [*cipherlist*] but, in the command line when I list the options with help command, it is not showing ssl3 option as follows *$openssl ciphers -helpUsage: ciphers [options]Valid options are: -help Display this summary -v Verbose listing of the SSL/TLS ciphers -V Even more verbose -s Only supported ciphers -tls1 TLS1 mode -tls1_1 TLS1.1 mode -tls1_2 TLS1.2 mode -tls1_3 TLS1.3 mode -stdname Show standard cipher names -psk include ciphersuites requiring PSK -srp include ciphersuites requiring SRP -convert val Convert standard name into OpenSSL name -ciphersuites val Configure the TLSv1.3 ciphersuites to use* why it is not displaying the ssl3 option? please answer me. Thanks and Regards Shivakumar On Wed, Jul 10, 2019 at 10:40 AM shiva kumar wrote: > Hi, > How to List the ssl3 ciphers in openssl1.1.1 > The command "openssl ciphers -ssl3" is not working. Please help me > > Thanks and Regards > Shivakumar > -- > *With Best Regards* > *Shivakumar S* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xpahos at gmail.com Thu Jul 11 11:41:56 2019 From: xpahos at gmail.com (Alexander Gryanko) Date: Thu, 11 Jul 2019 14:41:56 +0300 Subject: How to list ssl3 ciphers In-Reply-To: References: Message-ID: <276F8E00-1C42-4820-9174-1CD853F922D2@gmail.com> Hi, Ssl3 is deprecated and disabled by default. Rebuild your OpenSSL with enable-ssl3 enable-ssl3-method options. Sent from my iPhone > On 11 Jul 2019, at 14:00, shiva kumar wrote: > > HI, > In OpenSSL 1.1.1 documentation it is mentioned as -ssl3 option is there as follows, > openssl ciphers [-help] [-s] [-v] [-V] [-ssl3] [-tls1] [-tls1_1] [-tls1_2] [-tls1_3] [-s] [-psk] [-srp] [-stdname] [-convert name] [-ciphersuites val] [cipherlist] > > but, in the command line when I list the options with help command, it is not showing ssl3 option as follows > > $openssl ciphers -help > Usage: ciphers [options] > Valid options are: > -help Display this summary > -v Verbose listing of the SSL/TLS ciphers > -V Even more verbose > -s Only supported ciphers > -tls1 TLS1 mode > -tls1_1 TLS1.1 mode > -tls1_2 TLS1.2 mode > -tls1_3 TLS1.3 mode > -stdname Show standard cipher names > -psk include ciphersuites requiring PSK > -srp include ciphersuites requiring SRP > -convert val Convert standard name into OpenSSL name > -ciphersuites val Configure the TLSv1.3 ciphersuites to use > > why it is not displaying the ssl3 option? please answer me. > > Thanks and Regards > Shivakumar > > >> On Wed, Jul 10, 2019 at 10:40 AM shiva kumar wrote: >> Hi, >> How to List the ssl3 ciphers in openssl1.1.1 >> The command "openssl ciphers -ssl3" is not working. Please help me >> >> Thanks and Regards >> Shivakumar >> -- >> With Best Regards >> Shivakumar S > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Thu Jul 11 12:31:31 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Thu, 11 Jul 2019 14:31:31 +0200 Subject: RAND_seed buffer freeing In-Reply-To: References: Message-ID: On 11.07.19 12:00, Tobias.Wolf at t-systems.com wrote: > > I`ve one question regarding RAND_seed, the first parameter refers to a buffer, who is freeing that buffer afterwards? Can I free it after the call to RAND_seed or is this done by openssl? > You own the buffer, OpenSSL only reads its contents. So you can free it immediately after the call. Note that before freeing it, you should erase the buffer contents for security reasons. Actually, since OpenSSL 1.1.1. most applications don't need to worry about manual seeding anymore, because the OpenSSL CSPRNG does it automatically. For more details, see https://www.openssl.org/docs/man1.1.1/man7/RAND.html and https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html HTH, Matthias From rsalz at akamai.com Thu Jul 11 12:41:15 2019 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 11 Jul 2019 12:41:15 +0000 Subject: looks like the support for Heart beat extension is removed from openssl In-Reply-To: References: Message-ID: <4198C549-44AE-4A06-BDF8-B09E71125828@akamai.com> * Why the support for Heart beat extension is removed from openssl. It?s intended use was to check MTU along the path. That is not very useful any more. * How to handle abnormal disconnection in DTLS? You should be able to detect time-outs and ?failure to close? in your application. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Jul 11 18:55:05 2019 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 11 Jul 2019 18:55:05 +0000 Subject: What's up with ectest? Message-ID: Ectest has been broken for quite some time. What are the plans to get it fixed? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dclarke at blastwave.org Thu Jul 11 23:09:38 2019 From: dclarke at blastwave.org (Dennis Clarke) Date: Thu, 11 Jul 2019 19:09:38 -0400 Subject: How to list ssl3 ciphers In-Reply-To: References: Message-ID: On 7/10/19 1:10 AM, shiva kumar wrote: > Hi, > How to List the ssl3 ciphers in openssl1.1.1 > The command "openssl ciphers -ssl3" is not working. Please help me jupiter # /usr/local/bin/openssl version OpenSSL 1.1.1c 28 May 2019 jupiter # /usr/local/bin/openssl ciphers -help Usage: ciphers [options] Valid options are: -help Display this summary -v Verbose listing of the SSL/TLS ciphers -V Even more verbose -s Only supported ciphers -tls1 TLS1 mode -tls1_1 TLS1.1 mode -tls1_2 TLS1.2 mode -tls1_3 TLS1.3 mode -stdname Show standard cipher names -psk include ciphersuites requiring PSK -srp include ciphersuites requiring SRP -convert val Convert standard name into OpenSSL name -ciphersuites val Configure the TLSv1.3 ciphersuites to use jupiter # jupiter # /usr/local/bin/openssl ciphers -v -s -tls1_3 TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD jupiter # However I seem to recall six of them really. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From kerry-fly at 163.com Fri Jul 12 01:58:12 2019 From: kerry-fly at 163.com (anyegongjue) Date: Thu, 11 Jul 2019 18:58:12 -0700 (MST) Subject: How to use openssl smine sign the email body only In-Reply-To: <1562828750886-0.post@n7.nabble.com> References: <1562828750886-0.post@n7.nabble.com> Message-ID: <1562896692578-0.post@n7.nabble.com> Maybe I posted too many stuff. What my problem is "openssl smime" command signed everything fed to it. For example, I wanted to sign the following email body. /*Hi there, This is an test email.* / And after signed, the email became something like below, /Received: from localhost [127.0.0.1] by with HTTP; Thu, 11 Jul 2019 16:24:33 +1000 Date: Thu, 11 Jul 2019 16:24:33 +1000 To: Kerry Fly MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha-256"; boundary="----5D53D58F876671D7CA85A8CD28305ABB" This is an S/MIME signed message ------5D53D58F876671D7CA85A8CD28305ABB *Hi there, This is an test email.* ------5D53D58F876671D7CA85A8CD28305ABB Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIIFAYJKoZIhvcNAQcCoIIIBTCCCAECAQExDzANBglghkgBZQMEAgEFADALBgkq hkiG9w0BBwGgggVmMIIFYjCCBEqgAwIBAgISA2D+gfTao7ImMR5FeJceYRQOMA0G ... Y/5+MrMjklc= ------5D53D58F876671D7CA85A8CD28305ABB--/ And if I pass the email content with some headers, smime will wrap the header inside, too. Like below /Received: from localhost [127.0.0.1] by with HTTP; Thu, 11 Jul 2019 16:24:33 +1000 Date: Thu, 11 Jul 2019 16:24:33 +1000 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha-256"; boundary="----5D53D58F876671D7CA85A8CD28305ABB" This is an S/MIME signed message ------5D53D58F876671D7CA85A8CD28305ABB *Received: from localhost [127.0.0.1] by with HTTP; Thu, 11 Jul 2019 16:24:33 +1000 Date: Thu, 11 Jul 2019 16:24:33 +1000 To: Kerry Fly From: email_marketing at xxx.com Reply-To: email_marketing at xxx.com Subject: New T-shirt arrived Message-ID: X-Mailer: xxx.com X-MessageID: ABsLBhQBCA4 X-ListMember: kerry-fly at xxx.com Precedence: bulk List-Unsubscribe: List-Owner: Error-To: email_marketing_bounce at xxx.com Bounces-To: email_marketing_bounce at xxx.com Hi there, This is an test email.* ------5D53D58F876671D7CA85A8CD28305ABB Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIIFAYJKoZIhvcNAQcCoIIIBTCCCAECAQExDzANBglghkgBZQMEAgEFADALBgkq hkiG9w0BBwGgggVmMIIFYjCCBEqgAwIBAgISA2D+gfTao7ImMR5FeJceYRQOMA0G ... Y/5+MrMjklc= ------5D53D58F876671D7CA85A8CD28305ABB--/ Then the header inside smime cannot be seen by receiver, like gmail. And in this way, I cannot send emails. So my question is that is there a way to use "openssl smime" to sign some email with headers? Thank you in advance. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From mann.patidar at gmail.com Fri Jul 12 05:12:01 2019 From: mann.patidar at gmail.com (Manish Patidar) Date: Fri, 12 Jul 2019 10:42:01 +0530 Subject: Drbg kat test data: Openssl-fips 2.0.16 Message-ID: Hi There is DRBG kat test data in fips_drbg_selftest.h. (Openssl-fips-2.0.16) Can anyone let me know, What is the source of this constant arrays. NIST link or any other source will be helpful? Regards Manish -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Jul 12 11:41:46 2019 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 12 Jul 2019 11:41:46 +0000 Subject: How to use openssl smine sign the email body only In-Reply-To: <1562896692578-0.post@n7.nabble.com> References: <1562828750886-0.post@n7.nabble.com> <1562896692578-0.post@n7.nabble.com> Message-ID: > Maybe I posted too many stuff. What my problem is "openssl smime" command signed everything fed to it. For example, I wanted to sign the following email body. Yes, it signs whatever you give it. You will have to feed it just the message body and set the headers yourself. From rsalz at akamai.com Fri Jul 12 11:43:30 2019 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 12 Jul 2019 11:43:30 +0000 Subject: looks like the support for Heart beat extension is removed from openssl In-Reply-To: References: <4198C549-44AE-4A06-BDF8-B09E71125828@akamai.com> Message-ID: * would the below method be advisable to handle the "failure to close" conditions Sorry, no comment. Maybe others will. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shiva.lear at gmail.com Mon Jul 15 05:01:10 2019 From: shiva.lear at gmail.com (shiva kumar) Date: Mon, 15 Jul 2019 10:31:10 +0530 Subject: looks like the support for Heart beat extension is removed from openssl In-Reply-To: References: <4198C549-44AE-4A06-BDF8-B09E71125828@akamai.com> Message-ID: Hi, If someone can have a look at my query and provide suggestions(which would be much helpful for me). Thanks for your help Thanks! Shiva On Fri, Jul 12, 2019 at 5:13 PM Salz, Rich wrote: > > - would the below method be advisable to handle the "failure to close" > conditions > > > > Sorry, no comment. Maybe others will. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From AThorath at corsec.com Mon Jul 15 14:48:06 2019 From: AThorath at corsec.com (Amritha Thorath) Date: Mon, 15 Jul 2019 14:48:06 +0000 Subject: FW: BN_mod_exp() issue In-Reply-To: <995320e3f07d47a7afc2ec179e9a61f6@MBX082-E4-VA-3.EXCH082.serverpod.net> References: <995320e3f07d47a7afc2ec179e9a61f6@MBX082-E4-VA-3.EXCH082.serverpod.net> Message-ID: <6bf552951bba4e9cb3cf3eb02d3a5cb3@MBX082-E4-VA-3.EXCH082.serverpod.net> Thanks, [cid:image005.png at 01D01EBC.D4993640] Amritha Thorath Cryptographic Software Developer O: 703-267-6050 x 119 E: athorath at corsec.com Website | Blog | Facebook | Twitter | LinkedIn Opening Markets Through Security Certifications From: Amritha Thorath Sent: Monday, July 15, 2019 10:34 AM To: 'openssl-users at openssl.org' Subject: BN_mod_exp() issue Hi, I'm trying to implement RSA decryption primitive (Refer https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf; section 7.1.2.1) using OpenSSL. I've tried to implement in the same manner shown in some testcases (https://github.com/openssl/openssl/blob/master/test/bntest.c). >From the documentation, it is evident that message m can be generated with the below equation: m = (c^d) mod n I use BN_mod_exp() to do this. My values for N, D and C are shown below: N : bff722714050aebb23a9bd018c3e9ba26a47f53816eeac7e10543958702d9265c8d67784fe03c07bfceac05e7f2a434971dfa2a5ea461893450ced52fcb3f143a85fb3a9194417ff220258840a3359a104079ccd201afec091bab6587d4cfe0b95bba34ef74a70b392a92a93f026c9bed41eb4ec80452492a2ad524e6b0333c5787b34ee941829020bb75ee5dd216b3734823ddd547d50f8a7e711f8a24fd7dbc0bd2f062ccaba98cdbf62c15d2521b39ce44c53125604493e482ae35f945c4efff1d01414b0aad33de77b020ea4aedf3d88171fe51b22881bc70c639f8b6f1b5a70ed39aa121a8f44887dcbbfce29e1e508d1b0f0666693b476d81faa6a18bd D : a13aec8eba3a09c7dc18404b0083c52c10a00771e8b0e5e7abc751b2d9e52cc4987ea93be62d3889eacf306b2ddb4d506e782a9fb7b8d0034147ae3cb94a59253e51c3100fcc856b2021603ee66262b13e3536998291a9ce0b980a7720267e693485b890265b3b75578505e1e31e70ebfa3520385333bf97f9522183039658efd9b09fc0bd67a7d3c32e23adada71320ada2135f1d06a9144033ff9e0037a3b7ed1f5729b6db5f02470ecdde9eb2d97c759c73d13889bae550ab97205b67ce2f91eefb487f18c19bc6dd8831a43b0d699c771e1a9c55a1d5d2ae975691789b5c0a814c4f5e3d6a8e9e5f75419194b2d7dfe06700f6891cae8b712b3af1f9ec71 C : 534d1f57d948cac580b88b922bc47bc3d64c8cd1262bbf0944b99833ec94d072c1a1496be44d47a9c419dc403855a4b1cb2bb30e56e0cc5fd557d34373d785dbe70d67e30355fc228a353b05432a40874ba84253af5cc52d3ab4118e8ca1e28e6c9c610760e753f87a15912774ccb80b00ca21e85926143c1ed8385a607c4e55fa531f1f208bb3f23bc0c4eff4c272068f9939157bc61f5427cc32f017ef31f6363c8a736ec984da763ebea5eb94d83fa31d70223ec5503cfd97e598d883f43aca5e884b702a2f76d298659181cb5180e25faf56c9aa0ebe49413b9acbbefde95ec102ee4e351a8ff8d5a3fbdcee448ff466dffb45fdc0a0b3d31b3d192bb5cb I keep getting a seg fault and I'm not sure why. My code and the error are shown below: Code: BIGNUM *m = NULL, *n = NULL, *d = NULL, *c = NULL; int isValid = -1; n = BN_bin2bn(N, 256, n); d = BN_bin2bn(D, 256, d); c = BN_bin2bn(ciphertext, 256, d); if (c == NULL || n == NULL || d == NULL) printf("\n\nC,N,D is NULL, BN_bin2bn() failed!!\n\n"); isValid = BN_mod_exp(m, c, d, n, NULL); BN_free(n); BN_free(d); BN_free(c); BN_free(m); The error is : Program received signal SIGSEGV, Segmentation fault. 0x00007ffff792fd39 in fips_bn_ctx_start (ctx=0x0) at bn_ctx.c:261 261 if(ctx->err_stack || ctx->too_many) (gdb) bt #0 0x00007ffff792fd39 in fips_bn_ctx_start (ctx=0x0) at bn_ctx.c:261 #1 0x00007ffff7932a55 in fips_bn_mod_exp_mont (rr=0x0, a=0x6a9b30, p=0x6a9b30, m=0x6a99c0, ctx=0x0, in_mont=0x0) at bn_exp.c:417 #2 0x00007ffff79320f0 in fips_bn_mod_exp (r=0x0, a=0x6a9b30, p=0x6a9b30, m=0x6a99c0, ctx=0x0) at bn_exp.c:237 Thanks, [cid:image005.png at 01D01EBC.D4993640] Amritha Thorath Cryptographic Software Developer O: 703-267-6050 x 119 E: athorath at corsec.com Website | Blog | Facebook | Twitter | LinkedIn Opening Markets Through Security Certifications -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5110 bytes Desc: image001.png URL: From venkata.sandeep.m at gmail.com Mon Jul 15 17:55:51 2019 From: venkata.sandeep.m at gmail.com (sandeep m.v) Date: Mon, 15 Jul 2019 23:25:51 +0530 Subject: OpenSSL 1.1.1b - TLS server handshake fails when using CAPI engine - capi_rsa_priv_enc() - capi engine: function not supported In-Reply-To: References: Message-ID: Hi, This is regarding an issue reported here in this link - https://github.com/openssl/openssl/issues/8872 - This is blocking my development progress. I'm seeing this issue - capi_rsa_priv_enc() - capi engine: function not supported, when I tried to upgrade my application from using OpenSSL version 1.0.2r to 1.1.1b. This is causing TLS handshake to fail. In my case, I'm creating a self signed certificate that is used by Server application loading CAPI engine. Certificate is created by calling CertCreateSelfSignCertificate(--) - wincrypt.h - using szOID_RSA_SHA256RSA signature algorithm and "Microsoft Enhanced RSA and AES Cryptographic Provider". This failure doesn't look like it's because of TLS1.3 as turning off TLS1.3 while configure with "no-tls1_3" also caused the same problem. Here is the call stack that is causing the reported problem when SSL_accept() is called. capi.dll!capi_rsa_priv_enc(int flen, const unsigned char * from, unsigned char * to, rsa_st * rsa, int padding) libcrypto-1_1.dll!RSA_private_encrypt(int flen, const unsigned char * from, unsigned char * to, rsa_st * rsa, int padding) libcrypto-1_1.dll!pkey_rsa_sign(evp_pkey_ctx_st * ctx, unsigned char * sig, unsigned int * siglen, const unsigned char * tbs, unsigned int tbslen) libcrypto-1_1.dll!EVP_PKEY_sign(evp_pkey_ctx_st * ctx, unsigned char * sig, unsigned int * siglen, const unsigned char * tbs, unsigned int tbslen) libcrypto-1_1.dll!EVP_DigestSignFinal(evp_md_ctx_st * ctx, unsigned char * sigret, unsigned int * siglen) libcrypto-1_1.dll!EVP_DigestSign(evp_md_ctx_st * ctx, unsigned char * sigret, unsigned int * siglen, const unsigned char * tbs, unsigned int tbslen) libssl-1_1.dll!tls_construct_cert_verify(ssl_st * s, wpacket_st * pkt) libssl-1_1.dll!write_state_machine(ssl_st * s) libssl-1_1.dll!state_machine(ssl_st * s, int server) libssl-1_1.dll!ossl_statem_accept(ssl_st * s) libssl-1_1.dll!SSL_do_handshake(ssl_st * s) libssl-1_1.dll!SSL_accept(ssl_st * s) Is there a solution for this? Or Do I need to switch to some other Signature algorithm like ECDSA? Can I use this or anything else instead of RSA? If I should switch to ECDSA, should I use "szOID_ECDSA_SHA256" (wincrypt.h) as signature algorithm, use "PROV_EC_ECDSA_SIG" while calling CryptAcquireContext() and call ENGINE_set_default() with ENGINE_METHOD_EC to support ECDSA using capi.dll? Thank you in advance. -- Regards, Sandeep -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Mon Jul 15 19:11:07 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 15 Jul 2019 19:11:07 +0000 Subject: OpenSSL 1.1.1b - TLS server handshake fails when using CAPI engine - capi_rsa_priv_enc() - capi engine: function not supported In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of sandeep m.v > Sent: Monday, July 15, 2019 11:56 > I'm seeing this issue - capi_rsa_priv_enc() - capi engine: function not supported, > when I tried to upgrade my application from using OpenSSL version 1.0.2r to 1.1.1b. > This is causing TLS handshake to fail. > In my case, I'm creating a self signed certificate that is used by Server application > loading CAPI engine. > Certificate is created by calling CertCreateSelfSignCertificate(--) - wincrypt.h - > using szOID_RSA_SHA256RSA signature algorithm and "Microsoft Enhanced RSA and > AES Cryptographic Provider". It's been some years since I worked with OpenSSL CAPI support, and in particular I haven't done anything with the CAPI engine for 1.1. For 1.0.2, though, I ended up forking the OpenSSL CAPI engine support and enhancing it in a number of places. I changed capi_load_privkey and the functions it calls (capi_find_key and capi_get_pkey) to silently determine if the provider type in the context was wrong, and if so correct it. CAPI is a fairly horrible API (CNG is somewhat better), and in particular is very fragile when there's a mismatch between the provider type in the CAPI context and the provider type specified for the key. It may be that your CAPI context specifies a provider other than the Enhanced RSA and AES one. The CAPI engine for 1.0.2 (at least the version I forked from) also had a shortcoming which Steve Henson had suggested a fix for, but which wasn't in the code. That's down in capi_get_key where it calls CryptGetUserKey. If CryptGetUserKey fails with NTE_NO_KEY (you have to call GetLastError to check), then try again with the other key type, by XORing keyspec with 3: if (!CryptGetUserKey(key->hprov, keyspec, &key->key)) { success = FALSE; errcode = GetLastError(); if (errcode == NTE_NO_KEY) { keyspec ^= 3; success = CryptGetUserKey(key->hprov, keyspec, &key->key); } ... } This handles the case where you have an RSA key marked as a key-exchange key and you need a signing key, or vice versa. All of that may be fixed already in the 1.1 CAPI engine, or be irrelevant to your problem, of course. But those are potential issues when using RSA keys with CAPI. -- Michael Wojcik Distinguished Engineer, Micro Focus From mark at keypair.us Mon Jul 15 21:28:26 2019 From: mark at keypair.us (Mark Minnoch) Date: Mon, 15 Jul 2019 14:28:26 -0700 Subject: Drbg kat test data: Openssl-fips 2.0.16 Message-ID: Manish asked: > There is DRBG kat test data in fips_drbg_selftest.h. (Openssl-fips-2.0.16) > Can anyone let me know, What is the source of this constant arrays. NIST > link or any other source will be helpful? I'm pretty sure that the test data for the DRBG KAT (known answer test) came from the NIST algorithm test tool when the OpenSSL team tested all of the algorithm implementations. The CAVP also posts sample test vectors if you are looking for that sort of thing: https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/random-number-generators#DRBG Mark J. Minnoch Co-Founder, CISSP KeyPair Consulting +1 (805) 550-3231 <(805)%20550-3231> mobile https://KeyPair.us https://www.linkedin.com/in/minnoch *We expertly guide technology companies in achieving their FIPS 140 goals* *Blog post: You Have Your FIPS Certificate. Now What? * -------------- next part -------------- An HTML attachment was scrubbed... URL: From smadwin at adobe.com Mon Jul 15 23:37:55 2019 From: smadwin at adobe.com (Steven Madwin) Date: Mon, 15 Jul 2019 23:37:55 +0000 Subject: s_server configuration Message-ID: Hi All, I?m trying to get an OCSP server operating in an SSL (really TLS1.2) environment. It works fine in the HTTP world, but I?m having issues with getting s_server to handle the communication in the Secure HTTPS world. If anyone has any suggestions to get the connection to persist I?d be VERY appreciative! This is what I?m seeing: --- Using OpenSSL v1.1.1c to enable TLS on Port 8902 --- C:\OpenSSL-Win64\bin>openssl s_server -port 8902 -4 -certform PEM -cert "C:\OpenSSL-Win64\bin\PEM\test.cer" -cert_chain C:\OpenSSL-Win64\bin\PEM\DigiCertTrustChain.cer -keyform PEM -pass pass:password -key "C:\OpenSSL-Win64\bin\PEM\test_key.pem" -status_verbose Using default temp DH parameters ACCEPT cert_status: callback called cert_status: AIA URL: http://ocsp.digicert.com cert_status: Can't retrieve issuer certificate. -----BEGIN SSL SESSION PARAMETERS----- MFoCAQECAgMDBALAMAQABDBt6uS6sCfohxxHvmv7hPIXRbjKzDqNJqoCpymZR1qc CpGHf1mBjQ5/B32R7/aXl8mhBgIEXS0L6KIEAgIcIKQGBAQBAAAArQMCAQE= -----END SSL SESSION PARAMETERS----- Shared ciphers:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA Signature Algorithms: RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512 Shared Signature Algorithms: RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512 Supported Elliptic Curve Point Formats: uncompressed Supported Elliptic Groups: X25519:P-256:P-384 Shared Elliptic groups: X25519:P-256:P-384 --- No server certificate CA names sent CIPHER is ECDHE-RSA-AES256-GCM-SHA384 Secure Renegotiation IS supported POST / HTTP/1.1 Accept: */* Content-Type: application/ocsp-request Content-Length: 143 Character-Encoding: binary User-Agent: PPKHandler Host: gemma.adobe.com:8902 Connection: Keep-Alive Cache-Control: no-cache Cookie: AAMC_adobe_0=REGION%7C9; s_nr=1562971576381-Repeat; adcloud={%22_les_v%22:%22y%2Cadobe.com%2C1564005807%22}; AMCV_9E1005A551ED61CA0A490D45%40AdobeOrg=-1303530583%7CMCAID%7C2D05BCDE05032D0E-40001185A003F0F0%7CMCMID%7C06088709957453939181689303953590820094%7CMCAAMLH-1563576332%7C9%7CMCAAMB-1563576332%7Cj8Odv6LonN4r3an7LhD3WZrU1bUpAkFkkiY1ncBR96t2PTI%7CMCOPTOUT-1562978727s%7CNONE%7CvVersion%7C3.3.0%7CMCIDTS%7C18072%7CMCSYNCSOP%7C411-18079%7CMCCIDH%7C1521286796; mbox=PC#ddd404f9c1d0418ba9692aaf983e9e03.28_36#1626216329|session#7b3f3fbfb1504526acdb639358290766#1562973437; s_vi=[CS]v1|2D05BCDE05032D0E-40001185A003F0F0[CE]; _fbp=fb.1.1561413807767.1078876052 0  +00? +0[1] _____  _____ ????g???Z Steven.Madwin at adobe.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1200 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5468 bytes Desc: not available URL: From chabboud at gmail.com Tue Jul 16 20:56:08 2019 From: chabboud at gmail.com (chabboud) Date: Tue, 16 Jul 2019 13:56:08 -0700 (MST) Subject: Server Binary Mode: open files requested by the client in binary mode Message-ID: <1563310568874-0.post@n7.nabble.com> I am trying to set up a server from which I can download binary files. However, I can only download text files. If I try to download binary files, I only receive the first few hundred bytes. Using options: openssl s_server -key key.pem -cert cert.pem -accept 4443 -WWW The master Manual lists option: -http_server_binmode /"When acting as web-server (using option -WWW or -HTTP) open files requested by the client in binary mode."/ This option sounds like exactly what I need but it is not available in the latest release. How can I make the server open files in binary mode? I am running OpenSSL 1.1.1c for Windows. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From mrichter at solarflare.com Tue Jul 16 21:23:32 2019 From: mrichter at solarflare.com (Mark Richter) Date: Tue, 16 Jul 2019 21:23:32 +0000 Subject: Errors building 1.1.1 on RHEL 7 Message-ID: <1563312212518.62805@solarflare.com> After I built version 1.1.1 on RHEL 7, I got these errors at the end of the 'make test.' What do they mean? Test Summary Report ------------------- ../test/recipes/15-test_dsa.t (Wstat: 768 Tests: 6 Failed: 3) Failed tests: 4-6 Non-zero exit status: 3 ../test/recipes/15-test_ec.t (Wstat: 768 Tests: 5 Failed: 3) Failed tests: 3-5 Non-zero exit status: 3 ../test/recipes/15-test_genrsa.t (Wstat: 1024 Tests: 5 Failed: 4) Failed tests: 2-5 Non-zero exit status: 4 ../test/recipes/15-test_mp_rsa.t (Wstat: 7680 Tests: 31 Failed: 30) Failed tests: 2-31 Non-zero exit status: 30 ../test/recipes/15-test_out_option.t (Wstat: 256 Tests: 4 Failed: 1) Failed test: 2 Non-zero exit status: 1 ../test/recipes/15-test_rsa.t (Wstat: 768 Tests: 6 Failed: 3) Failed tests: 4-6 Non-zero exit status: 3 ../test/recipes/15-test_rsapss.t (Wstat: 512 Tests: 5 Failed: 2) Failed tests: 1, 5 Non-zero exit status: 2 ../test/recipes/20-test_enc.t (Wstat: 256 Tests: 87 Failed: 1) Failed test: 2 Non-zero exit status: 1 Parse errors: Bad plan. You planned 172 tests but ran 87. ../test/recipes/20-test_enc_more.t (Wstat: 256 Tests: 137 Failed: 1) Failed test: 2 Non-zero exit status: 1 ../test/recipes/25-test_crl.t (Wstat: 768 Tests: 7 Failed: 3) Failed tests: 2, 6-7 Non-zero exit status: 3 ../test/recipes/25-test_pkcs7.t (Wstat: 512 Tests: 3 Failed: 2) Failed tests: 2-3 Non-zero exit status: 2 ../test/recipes/25-test_req.t (Wstat: 1024 Tests: 9 Failed: 4) Failed tests: 2, 7-9 Non-zero exit status: 4 ../test/recipes/25-test_sid.t (Wstat: 256 Tests: 2 Failed: 1) Failed test: 2 Non-zero exit status: 1 ../test/recipes/25-test_x509.t (Wstat: 1792 Tests: 9 Failed: 7) Failed tests: 2-8 Non-zero exit status: 7 ../test/recipes/40-test_rehash.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 4 tests but ran 0. ../test/recipes/60-test_x509_store.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 3 tests but ran 0. ../test/recipes/80-test_ca.t (Wstat: 256 Tests: 5 Failed: 1) Failed test: 1 Non-zero exit status: 1 ../test/recipes/80-test_cms.t (Wstat: 1024 Tests: 4 Failed: 4) Failed tests: 1-4 Non-zero exit status: 4 ../test/recipes/80-test_ocsp.t (Wstat: 512 Tests: 11 Failed: 2) Failed tests: 1, 10 Non-zero exit status: 2 ../test/recipes/80-test_ssl_new.t (Wstat: 6912 Tests: 27 Failed: 27) Failed tests: 1-27 Non-zero exit status: 27 ../test/recipes/80-test_ssl_old.t (Wstat: 1536 Tests: 6 Failed: 6) Failed tests: 1-6 Non-zero exit status: 6 ../test/recipes/80-test_tsa.t (Wstat: 3328 Tests: 0 Failed: 0) Non-zero exit status: 13 Parse errors: Bad plan. You planned 20 tests but ran 0. ../test/recipes/90-test_store.t (Wstat: 3328 Tests: 0 Failed: 0) Non-zero exit status: 13 Parse errors: Bad plan. You planned 209 tests but ran 0. Files=152, Tests=850, 30 wallclock secs ( 0.38 usr 0.10 sys + 31.02 cusr 4.55 csys = 36.05 CPU) Result: FAIL make[1]: *** [_tests] Error 1 make[1]: Leaving directory `/home/mrichter/bin/openssl-1.1.1' make: *** [tests] Error 2 ? Mark Richter | Senior Staff Engineer SolarFlare Communications, Inc. | www.Solarflare.com 9444 Waples Street, #170, San Diego, CA 92121 Mobile: +1 949-632-8403 [Description: Description: cid:EC628FDE-ACA6-4F34-A8AE-E1F672D4E395] The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. From openssl-users at dukhovni.org Tue Jul 16 22:06:50 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Jul 2019 18:06:50 -0400 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: <1563312212518.62805@solarflare.com> References: <1563312212518.62805@solarflare.com> Message-ID: <20190716220650.GK84864@straasha.imrryr.org> On Tue, Jul 16, 2019 at 09:23:32PM +0000, Mark Richter wrote: > After I built version 1.1.1 on RHEL 7, I got these errors at the end of the 'make test.' What do they mean? The test scripts exited with non-zero exit codes. > Test Summary Report > ------------------- > ../test/recipes/15-test_dsa.t (Wstat: 768 Tests: 6 Failed: 3) > Failed tests: 4-6 > Non-zero exit status: 3 > ../test/recipes/20-test_enc.t (Wstat: 256 Tests: 87 Failed: 1) > Failed test: 2 > Non-zero exit status: 1 > Parse errors: Bad plan. You planned 172 tests but ran 87. Something looks wrong with your build. > Files=152, Tests=850, 30 wallclock secs ( 0.38 usr 0.10 sys + 31.02 cusr 4.55 csys = 36.05 CPU) > Result: FAIL Insufficient detail, but make sure the directory is "clean" before you do the build. And post the build options in future problem reports. IIRC, you can use "make V=1 ..." to get more verbose test output. -- Viktor. From matt at openssl.org Tue Jul 16 22:20:40 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 16 Jul 2019 23:20:40 +0100 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: <1563312212518.62805@solarflare.com> References: <1563312212518.62805@solarflare.com> Message-ID: <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> On 16/07/2019 22:23, Mark Richter wrote: > After I built version 1.1.1 on RHEL 7, I got these errors at the end of the 'make test.' What do they mean? > > > Test Summary Report > ------------------- > ../test/recipes/15-test_dsa.t (Wstat: 768 Tests: 6 Failed: 3) > Failed tests: 4-6 > Non-zero exit status: 3 Looks like something fundamentally wrong to get this many errors (guess: perl version is too low?) Please run: make TESTS=test_dsa V=1 test Also lets see the output from: perl -v Matt > ../test/recipes/15-test_ec.t (Wstat: 768 Tests: 5 Failed: 3) > Failed tests: 3-5 > Non-zero exit status: 3 > ../test/recipes/15-test_genrsa.t (Wstat: 1024 Tests: 5 Failed: 4) > Failed tests: 2-5 > Non-zero exit status: 4 > ../test/recipes/15-test_mp_rsa.t (Wstat: 7680 Tests: 31 Failed: 30) > Failed tests: 2-31 > Non-zero exit status: 30 > ../test/recipes/15-test_out_option.t (Wstat: 256 Tests: 4 Failed: 1) > Failed test: 2 > Non-zero exit status: 1 > ../test/recipes/15-test_rsa.t (Wstat: 768 Tests: 6 Failed: 3) > Failed tests: 4-6 > Non-zero exit status: 3 > ../test/recipes/15-test_rsapss.t (Wstat: 512 Tests: 5 Failed: 2) > Failed tests: 1, 5 > Non-zero exit status: 2 > ../test/recipes/20-test_enc.t (Wstat: 256 Tests: 87 Failed: 1) > Failed test: 2 > Non-zero exit status: 1 > Parse errors: Bad plan. You planned 172 tests but ran 87. > ../test/recipes/20-test_enc_more.t (Wstat: 256 Tests: 137 Failed: 1) > Failed test: 2 > Non-zero exit status: 1 > ../test/recipes/25-test_crl.t (Wstat: 768 Tests: 7 Failed: 3) > Failed tests: 2, 6-7 > Non-zero exit status: 3 > ../test/recipes/25-test_pkcs7.t (Wstat: 512 Tests: 3 Failed: 2) > Failed tests: 2-3 > Non-zero exit status: 2 > ../test/recipes/25-test_req.t (Wstat: 1024 Tests: 9 Failed: 4) > Failed tests: 2, 7-9 > Non-zero exit status: 4 > ../test/recipes/25-test_sid.t (Wstat: 256 Tests: 2 Failed: 1) > Failed test: 2 > Non-zero exit status: 1 > ../test/recipes/25-test_x509.t (Wstat: 1792 Tests: 9 Failed: 7) > Failed tests: 2-8 > Non-zero exit status: 7 > ../test/recipes/40-test_rehash.t (Wstat: 65280 Tests: 0 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 4 tests but ran 0. > ../test/recipes/60-test_x509_store.t (Wstat: 65280 Tests: 0 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 3 tests but ran 0. > ../test/recipes/80-test_ca.t (Wstat: 256 Tests: 5 Failed: 1) > Failed test: 1 > Non-zero exit status: 1 > ../test/recipes/80-test_cms.t (Wstat: 1024 Tests: 4 Failed: 4) > Failed tests: 1-4 > Non-zero exit status: 4 > ../test/recipes/80-test_ocsp.t (Wstat: 512 Tests: 11 Failed: 2) > Failed tests: 1, 10 > Non-zero exit status: 2 > ../test/recipes/80-test_ssl_new.t (Wstat: 6912 Tests: 27 Failed: 27) > Failed tests: 1-27 > Non-zero exit status: 27 > ../test/recipes/80-test_ssl_old.t (Wstat: 1536 Tests: 6 Failed: 6) > Failed tests: 1-6 > Non-zero exit status: 6 > ../test/recipes/80-test_tsa.t (Wstat: 3328 Tests: 0 Failed: 0) > Non-zero exit status: 13 > Parse errors: Bad plan. You planned 20 tests but ran 0. > ../test/recipes/90-test_store.t (Wstat: 3328 Tests: 0 Failed: 0) > Non-zero exit status: 13 > Parse errors: Bad plan. You planned 209 tests but ran 0. > Files=152, Tests=850, 30 wallclock secs ( 0.38 usr 0.10 sys + 31.02 cusr 4.55 csys = 36.05 CPU) > Result: FAIL > make[1]: *** [_tests] Error 1 > make[1]: Leaving directory `/home/mrichter/bin/openssl-1.1.1' > make: *** [tests] Error 2 > > ? > > > Mark Richter | Senior Staff Engineer > SolarFlare Communications, Inc. | www.Solarflare.com > 9444 Waples Street, #170, San Diego, CA 92121 > Mobile: +1 949-632-8403 > [Description: Description: cid:EC628FDE-ACA6-4F34-A8AE-E1F672D4E395] > The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. > From mrichter at solarflare.com Tue Jul 16 22:27:05 2019 From: mrichter at solarflare.com (Mark Richter) Date: Tue, 16 Jul 2019 22:27:05 +0000 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> References: <1563312212518.62805@solarflare.com>, <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> Message-ID: <1563316027592.81632@solarflare.com> I removed the directory, re-untarred the source, ran 'make clean', then 'make', then 'make TESTS=test_dsa V=1 test': [root at sfsdr220d openssl-1.1.1]# make TESTS=test_dsa V=1 test make depend && make _tests make[1]: Entering directory `/tmp/openssl-1.1.1' make[1]: Leaving directory `/tmp/openssl-1.1.1' make[1]: Entering directory `/tmp/openssl-1.1.1' ( cd test; \ mkdir -p test-runs; \ SRCTOP=../. \ BLDTOP=../. \ RESULT_D=test-runs \ PERL="/usr/bin/perl" \ EXE_EXT= \ OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ OPENSSL_DEBUG_MEMORY=on \ /usr/bin/perl .././test/run_tests.pl test_dsa ) /tmp/openssl-1.1.1/test ../test/recipes/15-test_dsa.t .. 1..6 ok 1 - require '../../test/recipes/tconversion.pl'; # Subtest: ../../test/dsatest 1..1 ok 1 - dsa_test ../../util/shlib_wrap.sh ../../test/dsatest => 0 ok 2 - running dsatest # Subtest: ../../test/dsa_no_digest_size_test 1..3 ok 1 - dsa_exact_size_test ok 2 - dsa_small_digest_test ok 3 - dsa_large_digest_test ../../util/shlib_wrap.sh ../../test/dsa_no_digest_size_test => 0 ok 3 - running dsa_no_digest_size_test 1..10 ok 1 - initializing read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-fff.p -inform p -out dsa-f.d -outform d => 0 ok 2 - p -> d read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-fff.p -inform p -out dsa-f.p -outform p => 0 ok 3 - p -> p read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-f.d -inform d -out dsa-ff.dd -outform d => 0 ok 4 - d -> d read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-f.p -inform p -out dsa-ff.pd -outform d => 0 ok 5 - p -> d read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-f.d -inform d -out dsa-ff.dp -outform p => 0 ok 6 - d -> p read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-f.p -inform p -out dsa-ff.pp -outform p => 0 ok 7 - p -> p ok 8 - comparing orig to p ok 9 - comparing p to dp ok 10 - comparing p to pp ok 4 - dsa conversions -- private key 1..10 ../../util/shlib_wrap.sh ../../apps/openssl pkey -in ../../test/testdsa.pem -out dsa-fff.p => 0 ok 1 - initializing ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-fff.p -inform p -out dsa-f.d -outform d => 0 ok 2 - p -> d ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-fff.p -inform p -out dsa-f.p -outform p => 0 ok 3 - p -> p ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-f.d -inform d -out dsa-ff.dd -outform d => 0 ok 4 - d -> d ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-f.p -inform p -out dsa-ff.pd -outform d => 0 ok 5 - p -> d ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-f.d -inform d -out dsa-ff.dp -outform p => 0 ok 6 - d -> p ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-f.p -inform p -out dsa-ff.pp -outform p => 0 ok 7 - p -> p ok 8 - comparing orig to p ok 9 - comparing p to dp ok 10 - comparing p to pp ok 5 - dsa conversions -- private key PKCS\#8 1..20 ok 1 - initializing read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-fff.p -inform p -out msb-f.d -outform d => 0 ok 2 - p -> d read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-fff.p -inform p -out msb-f.p -outform p => 0 ok 3 - p -> p read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-fff.p -inform p -out msb-f.msblob -outform msblob => 0 ok 4 - p -> msblob read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.d -inform d -out msb-ff.dd -outform d => 0 ok 5 - d -> d read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.p -inform p -out msb-ff.pd -outform d => 0 ok 6 - p -> d read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.msblob -inform msblob -out msb-ff.msblobd -outform d => 0 ok 7 - msblob -> d read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.d -inform d -out msb-ff.dp -outform p => 0 ok 8 - d -> p read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.p -inform p -out msb-ff.pp -outform p => 0 ok 9 - p -> p read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.msblob -inform msblob -out msb-ff.msblobp -outform p => 0 ok 10 - msblob -> p read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.d -inform d -out msb-ff.dmsblob -outform msblob => 0 ok 11 - d -> msblob read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.p -inform p -out msb-ff.pmsblob -outform msblob => 0 ok 12 - p -> msblob read DSA key writing DSA key ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.msblob -inform msblob -out msb-ff.msblobmsblob -outform msblob => 0 ok 13 - msblob -> msblob ok 14 - comparing orig to p ok 15 - comparing p to dp ok 16 - comparing p to pp ok 17 - comparing p to msblobp ok 18 - comparing msblob to dmsblob ok 19 - comparing msblob to pmsblob ok 20 - comparing msblob to msblobmsblob ok 6 - dsa conversions -- public key ok All tests successful. Files=1, Tests=6, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.23 cusr 0.08 csys = 0.33 CPU) Result: PASS make[1]: Leaving directory `/tmp/openssl-1.1.1' [root at sfsdr220d openssl-1.1.1]# perl -v This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi (with 33 registered patches, see perl -V for more detail) Copyright 1987-2012, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. Mark Richter | Senior Staff Engineer SolarFlare Communications, Inc. | www.Solarflare.com 9444 Waples Street, #170, San Diego, CA 92121 Mobile: +1 949-632-8403 ________________________________________ From: openssl-users on behalf of Matt Caswell Sent: Tuesday, July 16, 2019 3:20 PM To: openssl-users at openssl.org Subject: Re: Errors building 1.1.1 on RHEL 7 On 16/07/2019 22:23, Mark Richter wrote: > After I built version 1.1.1 on RHEL 7, I got these errors at the end of the 'make test.' What do they mean? > > > Test Summary Report > ------------------- > ../test/recipes/15-test_dsa.t (Wstat: 768 Tests: 6 Failed: 3) > Failed tests: 4-6 > Non-zero exit status: 3 Looks like something fundamentally wrong to get this many errors (guess: perl version is too low?) Please run: make TESTS=test_dsa V=1 test Also lets see the output from: perl -v Matt > ../test/recipes/15-test_ec.t (Wstat: 768 Tests: 5 Failed: 3) > Failed tests: 3-5 > Non-zero exit status: 3 > ../test/recipes/15-test_genrsa.t (Wstat: 1024 Tests: 5 Failed: 4) > Failed tests: 2-5 > Non-zero exit status: 4 > ../test/recipes/15-test_mp_rsa.t (Wstat: 7680 Tests: 31 Failed: 30) > Failed tests: 2-31 > Non-zero exit status: 30 > ../test/recipes/15-test_out_option.t (Wstat: 256 Tests: 4 Failed: 1) > Failed test: 2 > Non-zero exit status: 1 > ../test/recipes/15-test_rsa.t (Wstat: 768 Tests: 6 Failed: 3) > Failed tests: 4-6 > Non-zero exit status: 3 > ../test/recipes/15-test_rsapss.t (Wstat: 512 Tests: 5 Failed: 2) > Failed tests: 1, 5 > Non-zero exit status: 2 > ../test/recipes/20-test_enc.t (Wstat: 256 Tests: 87 Failed: 1) > Failed test: 2 > Non-zero exit status: 1 > Parse errors: Bad plan. You planned 172 tests but ran 87. > ../test/recipes/20-test_enc_more.t (Wstat: 256 Tests: 137 Failed: 1) > Failed test: 2 > Non-zero exit status: 1 > ../test/recipes/25-test_crl.t (Wstat: 768 Tests: 7 Failed: 3) > Failed tests: 2, 6-7 > Non-zero exit status: 3 > ../test/recipes/25-test_pkcs7.t (Wstat: 512 Tests: 3 Failed: 2) > Failed tests: 2-3 > Non-zero exit status: 2 > ../test/recipes/25-test_req.t (Wstat: 1024 Tests: 9 Failed: 4) > Failed tests: 2, 7-9 > Non-zero exit status: 4 > ../test/recipes/25-test_sid.t (Wstat: 256 Tests: 2 Failed: 1) > Failed test: 2 > Non-zero exit status: 1 > ../test/recipes/25-test_x509.t (Wstat: 1792 Tests: 9 Failed: 7) > Failed tests: 2-8 > Non-zero exit status: 7 > ../test/recipes/40-test_rehash.t (Wstat: 65280 Tests: 0 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 4 tests but ran 0. > ../test/recipes/60-test_x509_store.t (Wstat: 65280 Tests: 0 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 3 tests but ran 0. > ../test/recipes/80-test_ca.t (Wstat: 256 Tests: 5 Failed: 1) > Failed test: 1 > Non-zero exit status: 1 > ../test/recipes/80-test_cms.t (Wstat: 1024 Tests: 4 Failed: 4) > Failed tests: 1-4 > Non-zero exit status: 4 > ../test/recipes/80-test_ocsp.t (Wstat: 512 Tests: 11 Failed: 2) > Failed tests: 1, 10 > Non-zero exit status: 2 > ../test/recipes/80-test_ssl_new.t (Wstat: 6912 Tests: 27 Failed: 27) > Failed tests: 1-27 > Non-zero exit status: 27 > ../test/recipes/80-test_ssl_old.t (Wstat: 1536 Tests: 6 Failed: 6) > Failed tests: 1-6 > Non-zero exit status: 6 > ../test/recipes/80-test_tsa.t (Wstat: 3328 Tests: 0 Failed: 0) > Non-zero exit status: 13 > Parse errors: Bad plan. You planned 20 tests but ran 0. > ../test/recipes/90-test_store.t (Wstat: 3328 Tests: 0 Failed: 0) > Non-zero exit status: 13 > Parse errors: Bad plan. You planned 209 tests but ran 0. > Files=152, Tests=850, 30 wallclock secs ( 0.38 usr 0.10 sys + 31.02 cusr 4.55 csys = 36.05 CPU) > Result: FAIL > make[1]: *** [_tests] Error 1 > make[1]: Leaving directory `/home/mrichter/bin/openssl-1.1.1' > make: *** [tests] Error 2 > > ? > > > Mark Richter | Senior Staff Engineer > SolarFlare Communications, Inc. | www.Solarflare.com > 9444 Waples Street, #170, San Diego, CA 92121 > Mobile: +1 949-632-8403 > [Description: Description: cid:EC628FDE-ACA6-4F34-A8AE-E1F672D4E395] > The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. > The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. From ydong at astri.org Wed Jul 17 03:29:51 2019 From: ydong at astri.org (Ying) Date: Tue, 16 Jul 2019 20:29:51 -0700 (MST) Subject: RSA digital signature verification failure with openssl 1.1.0j Message-ID: <1563334191660-0.post@n7.nabble.com> I am working on the upgrade my program written 4 years before with updated openssl version 1.1.0j from 1.0.1e. There are so many changes between the two versions. I updated my code with 1.1.0 API, but it failed and I cannot figure out the reason. The RSA key pair and message signature are generated with openssl command line as follows, key generation and cert generation $openssl req -new -keyout private/userkey.pem -out usercert-req.pem -config ./openssl.cnf $openssl ca -in usercert-req.pem -out newcerts/usercert.pem -days 180 -config ./openssl.cnf Sign. openssl dgst -sha256 -sign userkey.pem -out signature.binary msg openssl dgst -hex -sha256 -sign userkey.pem -out signature.hex msg //get public key from cert openssl x509 -pubkey -noout -in usercert.pem > pubkey.pem Verify openssl dgst -sha256 -verify pubkey.pem -signature signature.binary msg The result is verification OK But I have to use the API to verify the signature in hex format, and the result is verification failure. Can anyone help me to figure out the problem. The code first loads the certification and retrieve the public key from certificate into EVP_PKEY, and then translate the hex digest (messasge) to binary format, and use EVP_DigestVerifyInitial/EVP_DigestVerifyUpdate/EVP_DigestVerifyFinal to verify the signature. It works in openssl 1.01e, and I tried to update the related functions in the 1.1.0version, it still fails. Am I missing something in the new version? This is the C code I am using: #include #include #include #include #include #include #include #include #include #include #include #include #include #include int hex_to_bin(char ch) { if ((ch >= '0') && (ch <= '9')) return ch - '0'; if ((ch >= 'a') && (ch <= 'f')) return ch - 'a' + 0x0A; if ((ch >= 'A') && (ch <= 'F')) return ch - 'A' + 0x0A; return -1; } int hex2bin(unsigned char *dst, const char *src, unsigned count) { while (count--) { int hi = hex_to_bin(*src++); int lo = hex_to_bin(*src++); if ((hi < 0) || (lo < 0)) return -1; *dst++ = (hi << 4) | lo; } return 0; } int main() { FILE *fp; X509 *x509 = NULL; EVP_PKEY *pkey = NULL; unsigned char *sigbuf = NULL; unsigned char md[32]; unsigned char *digest = NULL; unsigned int i, siglen = 0; siglen = 128; char line[siglen * 2 + 3]; char *buf; int num = 0; //number of license const char cert_filestr[] = "./cert.pem"; const char license_filename_str[] = "./signature"; const char digest_filename_str[] = "./digest"; //**************************************** //load certificate and get pub key //******************************************* //OpenSSL_add_all_algorithms(); //ERR_load_crypto_strings(); fp = fopen(cert_filestr, "r"); if (!fp) { printf("Error opening certificate file \n"); return -1; } x509 = PEM_read_X509(fp, NULL, NULL, NULL); fclose(fp); pkey = X509_get_pubkey(x509); if(!pkey){ printf("Fail to create pkey!"); return -1; } //***************************************************** // //load license.info (digest) // //**************************************************** fp =fopen(digest_filename_str, "r"); if(!fp) { printf("Error opening digest file\n"); return -1; } digest = (unsigned char*)malloc(64+10); digest = fgets(line, sizeof(line), fp); fclose(fp); //************************************************* // //load license.key (signature) // // //******************************************** fp = fopen(license_filename_str, "r"); if (!fp) { printf("Error opening license file \n"); return -1; } //********************************** //change the sigature format from Hex to Binary //**************************************** fp = fopen(license_filename_str, "r"); unsigned int len = siglen ; sigbuf = (unsigned char*)malloc(len); if((buf = fgets(line, sizeof(line), fp)) != NULL) { printf("*************Retrieved line of length %d :\n", (int)strlen(buf)); printf("*************signature**********\n%s", buf); hex2bin(sigbuf , buf, siglen); } fclose(fp); //************************************************** // //verify signature // // //****************************************************** EVP_MD_CTX *ctx = EVP_MD_CTX_create(); i=0; if (!EVP_DigestVerifyInit(ctx, NULL, EVP_sha256(), NULL, pkey)) { printf("Error setting context\n"); ERR_print_errors_fp(stderr); return -1; } if (!EVP_DigestVerifyUpdate(ctx, digest,67)) { ERR_print_errors_fp(stderr); return -1; } i = EVP_DigestVerifyFinal(ctx, sigbuf, 128); if (i <= 0) { printf("Verification Failure!\n"); ERR_print_errors_fp(stderr); return -1; } X509_free(x509); free(sigbuf); return 0; } -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From ydong at astri.org Wed Jul 17 03:33:08 2019 From: ydong at astri.org (Ying) Date: Tue, 16 Jul 2019 20:33:08 -0700 (MST) Subject: RSA digital signature verification failure with openssl 1.1.0j In-Reply-To: <1563334191660-0.post@n7.nabble.com> References: <1563334191660-0.post@n7.nabble.com> Message-ID: <1563334388187-0.post@n7.nabble.com> I found that if the signing and verification are all done by command line or all done by API, the verification will pass. But if cross, then failed. Any default configuration are different? -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From matt at openssl.org Wed Jul 17 08:15:51 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 17 Jul 2019 09:15:51 +0100 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: <1563316027592.81632@solarflare.com> References: <1563312212518.62805@solarflare.com> <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> <1563316027592.81632@solarflare.com> Message-ID: <259a2ac6-c357-6a06-c649-b38442e20c9c@openssl.org> On 16/07/2019 23:27, Mark Richter wrote: > Result: PASS Well that's quite odd because this test was failing for you before. I assume that after you had done the "make clean" that "make test" is still failing? Is it failing with the same set of tests that were failing before or different ones? Matt > make[1]: Leaving directory `/tmp/openssl-1.1.1' > [root at sfsdr220d openssl-1.1.1]# perl -v > > This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi > (with 33 registered patches, see perl -V for more detail) > > Copyright 1987-2012, Larry Wall > > Perl may be copied only under the terms of either the Artistic License or the > GNU General Public License, which may be found in the Perl 5 source kit. > > Complete documentation for Perl, including FAQ lists, should be found on > this system using "man perl" or "perldoc perl". If you have access to the > Internet, point your browser at http://www.perl.org/, the Perl Home Page. > > > Mark Richter | Senior Staff Engineer > SolarFlare Communications, Inc. | www.Solarflare.com > 9444 Waples Street, #170, San Diego, CA 92121 > Mobile: +1 949-632-8403 > > > ________________________________________ > From: openssl-users on behalf of Matt Caswell > Sent: Tuesday, July 16, 2019 3:20 PM > To: openssl-users at openssl.org > Subject: Re: Errors building 1.1.1 on RHEL 7 > > On 16/07/2019 22:23, Mark Richter wrote: >> After I built version 1.1.1 on RHEL 7, I got these errors at the end of the 'make test.' What do they mean? >> >> >> Test Summary Report >> ------------------- >> ../test/recipes/15-test_dsa.t (Wstat: 768 Tests: 6 Failed: 3) >> Failed tests: 4-6 >> Non-zero exit status: 3 > > Looks like something fundamentally wrong to get this many errors (guess: perl > version is too low?) > > Please run: > > make TESTS=test_dsa V=1 test > > Also lets see the output from: > > perl -v > > Matt > > >> ../test/recipes/15-test_ec.t (Wstat: 768 Tests: 5 Failed: 3) >> Failed tests: 3-5 >> Non-zero exit status: 3 >> ../test/recipes/15-test_genrsa.t (Wstat: 1024 Tests: 5 Failed: 4) >> Failed tests: 2-5 >> Non-zero exit status: 4 >> ../test/recipes/15-test_mp_rsa.t (Wstat: 7680 Tests: 31 Failed: 30) >> Failed tests: 2-31 >> Non-zero exit status: 30 >> ../test/recipes/15-test_out_option.t (Wstat: 256 Tests: 4 Failed: 1) >> Failed test: 2 >> Non-zero exit status: 1 >> ../test/recipes/15-test_rsa.t (Wstat: 768 Tests: 6 Failed: 3) >> Failed tests: 4-6 >> Non-zero exit status: 3 >> ../test/recipes/15-test_rsapss.t (Wstat: 512 Tests: 5 Failed: 2) >> Failed tests: 1, 5 >> Non-zero exit status: 2 >> ../test/recipes/20-test_enc.t (Wstat: 256 Tests: 87 Failed: 1) >> Failed test: 2 >> Non-zero exit status: 1 >> Parse errors: Bad plan. You planned 172 tests but ran 87. >> ../test/recipes/20-test_enc_more.t (Wstat: 256 Tests: 137 Failed: 1) >> Failed test: 2 >> Non-zero exit status: 1 >> ../test/recipes/25-test_crl.t (Wstat: 768 Tests: 7 Failed: 3) >> Failed tests: 2, 6-7 >> Non-zero exit status: 3 >> ../test/recipes/25-test_pkcs7.t (Wstat: 512 Tests: 3 Failed: 2) >> Failed tests: 2-3 >> Non-zero exit status: 2 >> ../test/recipes/25-test_req.t (Wstat: 1024 Tests: 9 Failed: 4) >> Failed tests: 2, 7-9 >> Non-zero exit status: 4 >> ../test/recipes/25-test_sid.t (Wstat: 256 Tests: 2 Failed: 1) >> Failed test: 2 >> Non-zero exit status: 1 >> ../test/recipes/25-test_x509.t (Wstat: 1792 Tests: 9 Failed: 7) >> Failed tests: 2-8 >> Non-zero exit status: 7 >> ../test/recipes/40-test_rehash.t (Wstat: 65280 Tests: 0 Failed: 0) >> Non-zero exit status: 255 >> Parse errors: Bad plan. You planned 4 tests but ran 0. >> ../test/recipes/60-test_x509_store.t (Wstat: 65280 Tests: 0 Failed: 0) >> Non-zero exit status: 255 >> Parse errors: Bad plan. You planned 3 tests but ran 0. >> ../test/recipes/80-test_ca.t (Wstat: 256 Tests: 5 Failed: 1) >> Failed test: 1 >> Non-zero exit status: 1 >> ../test/recipes/80-test_cms.t (Wstat: 1024 Tests: 4 Failed: 4) >> Failed tests: 1-4 >> Non-zero exit status: 4 >> ../test/recipes/80-test_ocsp.t (Wstat: 512 Tests: 11 Failed: 2) >> Failed tests: 1, 10 >> Non-zero exit status: 2 >> ../test/recipes/80-test_ssl_new.t (Wstat: 6912 Tests: 27 Failed: 27) >> Failed tests: 1-27 >> Non-zero exit status: 27 >> ../test/recipes/80-test_ssl_old.t (Wstat: 1536 Tests: 6 Failed: 6) >> Failed tests: 1-6 >> Non-zero exit status: 6 >> ../test/recipes/80-test_tsa.t (Wstat: 3328 Tests: 0 Failed: 0) >> Non-zero exit status: 13 >> Parse errors: Bad plan. You planned 20 tests but ran 0. >> ../test/recipes/90-test_store.t (Wstat: 3328 Tests: 0 Failed: 0) >> Non-zero exit status: 13 >> Parse errors: Bad plan. You planned 209 tests but ran 0. >> Files=152, Tests=850, 30 wallclock secs ( 0.38 usr 0.10 sys + 31.02 cusr 4.55 csys = 36.05 CPU) >> Result: FAIL >> make[1]: *** [_tests] Error 1 >> make[1]: Leaving directory `/home/mrichter/bin/openssl-1.1.1' >> make: *** [tests] Error 2 >> >> ? >> >> >> Mark Richter | Senior Staff Engineer >> SolarFlare Communications, Inc. | www.Solarflare.com >> 9444 Waples Street, #170, San Diego, CA 92121 >> Mobile: +1 949-632-8403 >> [Description: Description: cid:EC628FDE-ACA6-4F34-A8AE-E1F672D4E395] >> The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. >> > The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. > From janjust at nikhef.nl Wed Jul 17 09:53:26 2019 From: janjust at nikhef.nl (Jan Just Keijser) Date: Wed, 17 Jul 2019 11:53:26 +0200 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: <1563316027592.81632@solarflare.com> References: <1563312212518.62805@solarflare.com> <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> <1563316027592.81632@solarflare.com> Message-ID: FWIW: I just downloaded openssl 1.1.1c, untarred it on my CentOS 7 box, then ran ? ./config ? make ? make test The tests passed with the following output (the "ok" tests stripped out): ... ../test/recipes/05-test_md2.t ...................... skipped: md2 is not supported by this OpenSSL build ... ../test/recipes/05-test_rc5.t ...................... skipped: rc5 is not supported by this OpenSSL build ... ../test/recipes/30-test_afalg.t .................... skipped: test_afalg not supported for this build ... ../test/recipes/90-test_gost.t ..................... skipped: No test GOST engine found ... ../test/recipes/90-test_overhead.t ................. skipped: Only supported in no-shared builds ... ../test/recipes/95-test_external_boringssl.t ....... skipped: No external tests in this configuration ../test/recipes/95-test_external_krb5.t ............ skipped: No external tests in this configuration ../test/recipes/95-test_external_pyca.t ............ skipped: No external tests in this configuration ... All tests successful. Files=155, Tests=1452, 66 wallclock secs ( 1.44 usr? 0.11 sys + 62.90 cusr 13.51 csys = 77.96 CPU) Result: PASS make[1]: Leaving directory `/home/janjust/src/openssl-1.1.1c' Share and enjoy, JJK On 17/07/19 00:27, Mark Richter wrote: > I removed the directory, re-untarred the source, ran 'make clean', then 'make', then 'make TESTS=test_dsa V=1 test': > > [root at sfsdr220d openssl-1.1.1]# make TESTS=test_dsa V=1 test > make depend && make _tests > make[1]: Entering directory `/tmp/openssl-1.1.1' > make[1]: Leaving directory `/tmp/openssl-1.1.1' > make[1]: Entering directory `/tmp/openssl-1.1.1' > ( cd test; \ > mkdir -p test-runs; \ > SRCTOP=../. \ > BLDTOP=../. \ > RESULT_D=test-runs \ > PERL="/usr/bin/perl" \ > EXE_EXT= \ > OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ > OPENSSL_DEBUG_MEMORY=on \ > /usr/bin/perl .././test/run_tests.pl test_dsa ) > /tmp/openssl-1.1.1/test > ../test/recipes/15-test_dsa.t .. > 1..6 > ok 1 - require '../../test/recipes/tconversion.pl'; > # Subtest: ../../test/dsatest > 1..1 > ok 1 - dsa_test > ../../util/shlib_wrap.sh ../../test/dsatest => 0 > ok 2 - running dsatest > # Subtest: ../../test/dsa_no_digest_size_test > 1..3 > ok 1 - dsa_exact_size_test > ok 2 - dsa_small_digest_test > ok 3 - dsa_large_digest_test > ../../util/shlib_wrap.sh ../../test/dsa_no_digest_size_test => 0 > ok 3 - running dsa_no_digest_size_test > 1..10 > ok 1 - initializing > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-fff.p -inform p -out dsa-f.d -outform d => 0 > ok 2 - p -> d > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-fff.p -inform p -out dsa-f.p -outform p => 0 > ok 3 - p -> p > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-f.d -inform d -out dsa-ff.dd -outform d => 0 > ok 4 - d -> d > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-f.p -inform p -out dsa-ff.pd -outform d => 0 > ok 5 - p -> d > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-f.d -inform d -out dsa-ff.dp -outform p => 0 > ok 6 - d -> p > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-f.p -inform p -out dsa-ff.pp -outform p => 0 > ok 7 - p -> p > ok 8 - comparing orig to p > ok 9 - comparing p to dp > ok 10 - comparing p to pp > ok 4 - dsa conversions -- private key > 1..10 > ../../util/shlib_wrap.sh ../../apps/openssl pkey -in ../../test/testdsa.pem -out dsa-fff.p => 0 > ok 1 - initializing > ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-fff.p -inform p -out dsa-f.d -outform d => 0 > ok 2 - p -> d > ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-fff.p -inform p -out dsa-f.p -outform p => 0 > ok 3 - p -> p > ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-f.d -inform d -out dsa-ff.dd -outform d => 0 > ok 4 - d -> d > ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-f.p -inform p -out dsa-ff.pd -outform d => 0 > ok 5 - p -> d > ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-f.d -inform d -out dsa-ff.dp -outform p => 0 > ok 6 - d -> p > ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-f.p -inform p -out dsa-ff.pp -outform p => 0 > ok 7 - p -> p > ok 8 - comparing orig to p > ok 9 - comparing p to dp > ok 10 - comparing p to pp > ok 5 - dsa conversions -- private key PKCS\#8 > 1..20 > ok 1 - initializing > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-fff.p -inform p -out msb-f.d -outform d => 0 > ok 2 - p -> d > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-fff.p -inform p -out msb-f.p -outform p => 0 > ok 3 - p -> p > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-fff.p -inform p -out msb-f.msblob -outform msblob => 0 > ok 4 - p -> msblob > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.d -inform d -out msb-ff.dd -outform d => 0 > ok 5 - d -> d > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.p -inform p -out msb-ff.pd -outform d => 0 > ok 6 - p -> d > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.msblob -inform msblob -out msb-ff.msblobd -outform d => 0 > ok 7 - msblob -> d > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.d -inform d -out msb-ff.dp -outform p => 0 > ok 8 - d -> p > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.p -inform p -out msb-ff.pp -outform p => 0 > ok 9 - p -> p > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.msblob -inform msblob -out msb-ff.msblobp -outform p => 0 > ok 10 - msblob -> p > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.d -inform d -out msb-ff.dmsblob -outform msblob => 0 > ok 11 - d -> msblob > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.p -inform p -out msb-ff.pmsblob -outform msblob => 0 > ok 12 - p -> msblob > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.msblob -inform msblob -out msb-ff.msblobmsblob -outform msblob => 0 > ok 13 - msblob -> msblob > ok 14 - comparing orig to p > ok 15 - comparing p to dp > ok 16 - comparing p to pp > ok 17 - comparing p to msblobp > ok 18 - comparing msblob to dmsblob > ok 19 - comparing msblob to pmsblob > ok 20 - comparing msblob to msblobmsblob > ok 6 - dsa conversions -- public key > ok > All tests successful. > Files=1, Tests=6, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.23 cusr 0.08 csys = 0.33 CPU) > Result: PASS > make[1]: Leaving directory `/tmp/openssl-1.1.1' > [root at sfsdr220d openssl-1.1.1]# perl -v > > This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi > (with 33 registered patches, see perl -V for more detail) > > Copyright 1987-2012, Larry Wall > > Perl may be copied only under the terms of either the Artistic License or the > GNU General Public License, which may be found in the Perl 5 source kit. > > Complete documentation for Perl, including FAQ lists, should be found on > this system using "man perl" or "perldoc perl". If you have access to the > Internet, point your browser at http://www.perl.org/, the Perl Home Page. > > > Mark Richter | Senior Staff Engineer > SolarFlare Communications, Inc. | www.Solarflare.com > 9444 Waples Street, #170, San Diego, CA 92121 > Mobile: +1 949-632-8403 > > > ________________________________________ > From: openssl-users on behalf of Matt Caswell > Sent: Tuesday, July 16, 2019 3:20 PM > To: openssl-users at openssl.org > Subject: Re: Errors building 1.1.1 on RHEL 7 > > On 16/07/2019 22:23, Mark Richter wrote: >> After I built version 1.1.1 on RHEL 7, I got these errors at the end of the 'make test.' What do they mean? >> >> >> Test Summary Report >> ------------------- >> ../test/recipes/15-test_dsa.t (Wstat: 768 Tests: 6 Failed: 3) >> Failed tests: 4-6 >> Non-zero exit status: 3 > Looks like something fundamentally wrong to get this many errors (guess: perl > version is too low?) > > Please run: > > make TESTS=test_dsa V=1 test > > Also lets see the output from: > > perl -v > > Matt > > >> ../test/recipes/15-test_ec.t (Wstat: 768 Tests: 5 Failed: 3) >> Failed tests: 3-5 >> Non-zero exit status: 3 >> ../test/recipes/15-test_genrsa.t (Wstat: 1024 Tests: 5 Failed: 4) >> Failed tests: 2-5 >> Non-zero exit status: 4 >> ../test/recipes/15-test_mp_rsa.t (Wstat: 7680 Tests: 31 Failed: 30) >> Failed tests: 2-31 >> Non-zero exit status: 30 >> ../test/recipes/15-test_out_option.t (Wstat: 256 Tests: 4 Failed: 1) >> Failed test: 2 >> Non-zero exit status: 1 >> ../test/recipes/15-test_rsa.t (Wstat: 768 Tests: 6 Failed: 3) >> Failed tests: 4-6 >> Non-zero exit status: 3 >> ../test/recipes/15-test_rsapss.t (Wstat: 512 Tests: 5 Failed: 2) >> Failed tests: 1, 5 >> Non-zero exit status: 2 >> ../test/recipes/20-test_enc.t (Wstat: 256 Tests: 87 Failed: 1) >> Failed test: 2 >> Non-zero exit status: 1 >> Parse errors: Bad plan. You planned 172 tests but ran 87. >> ../test/recipes/20-test_enc_more.t (Wstat: 256 Tests: 137 Failed: 1) >> Failed test: 2 >> Non-zero exit status: 1 >> ../test/recipes/25-test_crl.t (Wstat: 768 Tests: 7 Failed: 3) >> Failed tests: 2, 6-7 >> Non-zero exit status: 3 >> ../test/recipes/25-test_pkcs7.t (Wstat: 512 Tests: 3 Failed: 2) >> Failed tests: 2-3 >> Non-zero exit status: 2 >> ../test/recipes/25-test_req.t (Wstat: 1024 Tests: 9 Failed: 4) >> Failed tests: 2, 7-9 >> Non-zero exit status: 4 >> ../test/recipes/25-test_sid.t (Wstat: 256 Tests: 2 Failed: 1) >> Failed test: 2 >> Non-zero exit status: 1 >> ../test/recipes/25-test_x509.t (Wstat: 1792 Tests: 9 Failed: 7) >> Failed tests: 2-8 >> Non-zero exit status: 7 >> ../test/recipes/40-test_rehash.t (Wstat: 65280 Tests: 0 Failed: 0) >> Non-zero exit status: 255 >> Parse errors: Bad plan. You planned 4 tests but ran 0. >> ../test/recipes/60-test_x509_store.t (Wstat: 65280 Tests: 0 Failed: 0) >> Non-zero exit status: 255 >> Parse errors: Bad plan. You planned 3 tests but ran 0. >> ../test/recipes/80-test_ca.t (Wstat: 256 Tests: 5 Failed: 1) >> Failed test: 1 >> Non-zero exit status: 1 >> ../test/recipes/80-test_cms.t (Wstat: 1024 Tests: 4 Failed: 4) >> Failed tests: 1-4 >> Non-zero exit status: 4 >> ../test/recipes/80-test_ocsp.t (Wstat: 512 Tests: 11 Failed: 2) >> Failed tests: 1, 10 >> Non-zero exit status: 2 >> ../test/recipes/80-test_ssl_new.t (Wstat: 6912 Tests: 27 Failed: 27) >> Failed tests: 1-27 >> Non-zero exit status: 27 >> ../test/recipes/80-test_ssl_old.t (Wstat: 1536 Tests: 6 Failed: 6) >> Failed tests: 1-6 >> Non-zero exit status: 6 >> ../test/recipes/80-test_tsa.t (Wstat: 3328 Tests: 0 Failed: 0) >> Non-zero exit status: 13 >> Parse errors: Bad plan. You planned 20 tests but ran 0. >> ../test/recipes/90-test_store.t (Wstat: 3328 Tests: 0 Failed: 0) >> Non-zero exit status: 13 >> Parse errors: Bad plan. You planned 209 tests but ran 0. >> Files=152, Tests=850, 30 wallclock secs ( 0.38 usr 0.10 sys + 31.02 cusr 4.55 csys = 36.05 CPU) >> Result: FAIL >> make[1]: *** [_tests] Error 1 >> make[1]: Leaving directory `/home/mrichter/bin/openssl-1.1.1' >> make: *** [tests] Error 2 >> >> ? >> >> >> Mark Richter | Senior Staff Engineer >> SolarFlare Communications, Inc. | www.Solarflare.com >> 9444 Waples Street, #170, San Diego, CA 92121 >> Mobile: +1 949-632-8403 >> [Description: Description: cid:EC628FDE-ACA6-4F34-A8AE-E1F672D4E395] >> The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. >> > The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. From Chethan.Kumar at toshiba-tsip.com Wed Jul 17 15:47:24 2019 From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar) Date: Wed, 17 Jul 2019 15:47:24 +0000 Subject: SSL_get_fd Message-ID: <447C096A3E2889439233CDD6DAB29F95D386BC1D@TOSBLRMBX03.TOSHIBA-TSIP.COM> Hi all, Need an help. I am trying to print IP address of destination host by doing getpeername() on fd got using SSL_get_fd() in both SSL_accept() and SSL_connect(). Doing SSL_get_fd() fails in SSL_accept() with return value as -1 but its working in SSL_connect(). Can you please help me out in knowing what is the issue. Thanks in advance, With Regards, Chethan Kumar The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrichter at solarflare.com Wed Jul 17 18:22:19 2019 From: mrichter at solarflare.com (Mark Richter) Date: Wed, 17 Jul 2019 18:22:19 +0000 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: References: <1563312212518.62805@solarflare.com> <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> <1563316027592.81632@solarflare.com> Message-ID: <32a535ec4406454ca5f9f5d29306868e@ocex03.SolarFlarecom.com> Hi Jan, Thanks for that. I got 1.1.1c and it built properly. I configured it to use /usr/local/openssl for the target per the instructions on https://blacksaildivision.com/how-to-install-openssl-on-centos, and everything seemed to go well. I get this: 11:02 [mrichter at sfsdr220d:~] $ openssl version OpenSSL 1.1.1c 28 May 2019 After I log out and back in. However, although I modified our make file to use '-I/usr/local/openssl/include' and '-L/usr/local/openssl/lib', I now see this warning: cc -DLOG_LEVEL=LOG_INFO -Wall -Werror -D__ci_driver__ -D__ci_ul_driver__ -D_GNU_SOURCE -DWITH_MCDI_V2 -DWITH_TLS12=0 -DSOLAR_SECURE_VERSION="1.0.3.1020 (3bf2875895d5+ Wed Jul 17 11:14:55 PDT 2019)" -Isrc/include -I/usr/local/openssl/include -Isrc/tools/mc-comms -Isrc/tools/mc-comms/include -Isrc/emulators/mbedtls/include -I/usr/include/json-c -g3 -fno-omit-frame-pointer build/src/tools/sfslc.o -o build/bin/sfslc -Lbuild/lib -L/usr/local/openssl/lib -lsfsl_api -lsf_core -lcm -lss -lcrypto -lpci -lcurl -lpthread -lrt -lssl -luuid -ljson-c /usr/bin/ld: warning: libssl.so.10, needed by /usr/lib64/libssh2.so.1, may conflict with libssl.so.1.1 /usr/bin/ld: warning: libcrypto.so.10, needed by /usr/lib64/libssh2.so.1, may conflict with libcrypto.so.1.1 I tried googling this and get lots of suggestion for similar errors with libcurl, but not this one. What am I missing? -----Original Message----- From: Jan Just Keijser Sent: Wednesday, July 17, 2019 2:53 AM To: Mark Richter ; Matt Caswell ; openssl-users at openssl.org Subject: Re: Errors building 1.1.1 on RHEL 7 FWIW: I just downloaded openssl 1.1.1c, untarred it on my CentOS 7 box, then ran ./config make make test The tests passed with the following output (the "ok" tests stripped out): ... ../test/recipes/05-test_md2.t ...................... skipped: md2 is not supported by this OpenSSL build ... ../test/recipes/05-test_rc5.t ...................... skipped: rc5 is not supported by this OpenSSL build ... ../test/recipes/30-test_afalg.t .................... skipped: test_afalg not supported for this build ... ../test/recipes/90-test_gost.t ..................... skipped: No test GOST engine found ... ../test/recipes/90-test_overhead.t ................. skipped: Only supported in no-shared builds ... ../test/recipes/95-test_external_boringssl.t ....... skipped: No external tests in this configuration ../test/recipes/95-test_external_krb5.t ............ skipped: No external tests in this configuration ../test/recipes/95-test_external_pyca.t ............ skipped: No external tests in this configuration ... All tests successful. Files=155, Tests=1452, 66 wallclock secs ( 1.44 usr 0.11 sys + 62.90 cusr 13.51 csys = 77.96 CPU) Result: PASS make[1]: Leaving directory `/home/janjust/src/openssl-1.1.1c' Share and enjoy, JJK On 17/07/19 00:27, Mark Richter wrote: > I removed the directory, re-untarred the source, ran 'make clean', then 'make', then 'make TESTS=test_dsa V=1 test': > > [root at sfsdr220d openssl-1.1.1]# make TESTS=test_dsa V=1 test make > depend && make _tests > make[1]: Entering directory `/tmp/openssl-1.1.1' > make[1]: Leaving directory `/tmp/openssl-1.1.1' > make[1]: Entering directory `/tmp/openssl-1.1.1' > ( cd test; \ > mkdir -p test-runs; \ > SRCTOP=../. \ > BLDTOP=../. \ > RESULT_D=test-runs \ > PERL="/usr/bin/perl" \ > EXE_EXT= \ > OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ > OPENSSL_DEBUG_MEMORY=on \ > /usr/bin/perl .././test/run_tests.pl test_dsa ) > /tmp/openssl-1.1.1/test ../test/recipes/15-test_dsa.t .. > 1..6 > ok 1 - require '../../test/recipes/tconversion.pl'; > # Subtest: ../../test/dsatest > 1..1 > ok 1 - dsa_test > ../../util/shlib_wrap.sh ../../test/dsatest => 0 ok 2 - running > dsatest > # Subtest: ../../test/dsa_no_digest_size_test > 1..3 > ok 1 - dsa_exact_size_test > ok 2 - dsa_small_digest_test > ok 3 - dsa_large_digest_test > ../../util/shlib_wrap.sh ../../test/dsa_no_digest_size_test => 0 ok 3 > - running dsa_no_digest_size_test > 1..10 > ok 1 - initializing > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-fff.p -inform p -out dsa-f.d -outform d => 0 > ok 2 - p -> d > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-fff.p -inform p -out dsa-f.p -outform p => 0 > ok 3 - p -> p > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-f.d -inform d -out dsa-ff.dd -outform d => 0 > ok 4 - d -> d > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-f.p -inform p -out dsa-ff.pd -outform d => 0 > ok 5 - p -> d > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-f.d -inform d -out dsa-ff.dp -outform p => 0 > ok 6 - d -> p > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-f.p -inform p -out dsa-ff.pp -outform p => 0 > ok 7 - p -> p > ok 8 - comparing orig to p > ok 9 - comparing p to dp > ok 10 - comparing p to pp > ok 4 - dsa conversions -- private key > 1..10 > ../../util/shlib_wrap.sh ../../apps/openssl pkey -in ../../test/testdsa.pem -out dsa-fff.p => 0 > ok 1 - initializing > ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-fff.p -inform p -out dsa-f.d -outform d => 0 > ok 2 - p -> d > ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-fff.p -inform p -out dsa-f.p -outform p => 0 > ok 3 - p -> p > ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-f.d -inform d -out dsa-ff.dd -outform d => 0 > ok 4 - d -> d > ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-f.p -inform p -out dsa-ff.pd -outform d => 0 > ok 5 - p -> d > ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-f.d -inform d -out dsa-ff.dp -outform p => 0 > ok 6 - d -> p > ../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-f.p -inform p -out dsa-ff.pp -outform p => 0 > ok 7 - p -> p > ok 8 - comparing orig to p > ok 9 - comparing p to dp > ok 10 - comparing p to pp > ok 5 - dsa conversions -- private key PKCS\#8 > 1..20 > ok 1 - initializing > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-fff.p -inform p -out msb-f.d -outform d => 0 > ok 2 - p -> d > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-fff.p -inform p -out msb-f.p -outform p => 0 > ok 3 - p -> p > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-fff.p -inform p -out msb-f.msblob -outform msblob => 0 > ok 4 - p -> msblob > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.d -inform d -out msb-ff.dd -outform d => 0 > ok 5 - d -> d > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.p -inform p -out msb-ff.pd -outform d => 0 > ok 6 - p -> d > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.msblob -inform msblob -out msb-ff.msblobd -outform d => 0 > ok 7 - msblob -> d > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.d -inform d -out msb-ff.dp -outform p => 0 > ok 8 - d -> p > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.p -inform p -out msb-ff.pp -outform p => 0 > ok 9 - p -> p > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.msblob -inform msblob -out msb-ff.msblobp -outform p => 0 > ok 10 - msblob -> p > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.d -inform d -out msb-ff.dmsblob -outform msblob => 0 > ok 11 - d -> msblob > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.p -inform p -out msb-ff.pmsblob -outform msblob => 0 > ok 12 - p -> msblob > read DSA key > writing DSA key > ../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-f.msblob -inform msblob -out msb-ff.msblobmsblob -outform msblob => 0 > ok 13 - msblob -> msblob > ok 14 - comparing orig to p > ok 15 - comparing p to dp > ok 16 - comparing p to pp > ok 17 - comparing p to msblobp > ok 18 - comparing msblob to dmsblob > ok 19 - comparing msblob to pmsblob > ok 20 - comparing msblob to msblobmsblob ok 6 - dsa conversions > -- public key ok All tests successful. > Files=1, Tests=6, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.23 cusr > 0.08 csys = 0.33 CPU) > Result: PASS > make[1]: Leaving directory `/tmp/openssl-1.1.1' > [root at sfsdr220d openssl-1.1.1]# perl -v > > This is perl 5, version 16, subversion 3 (v5.16.3) built for > x86_64-linux-thread-multi (with 33 registered patches, see perl -V for > more detail) > > Copyright 1987-2012, Larry Wall > > Perl may be copied only under the terms of either the Artistic License > or the GNU General Public License, which may be found in the Perl 5 source kit. > > Complete documentation for Perl, including FAQ lists, should be found > on this system using "man perl" or "perldoc perl". If you have access > to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. > > > Mark Richter | Senior Staff Engineer > SolarFlare Communications, Inc. | www.Solarflare.com > 9444 Waples Street, #170, San Diego, CA 92121 > Mobile: +1 949-632-8403 > > > ________________________________________ > From: openssl-users on behalf of > Matt Caswell > Sent: Tuesday, July 16, 2019 3:20 PM > To: openssl-users at openssl.org > Subject: Re: Errors building 1.1.1 on RHEL 7 > > On 16/07/2019 22:23, Mark Richter wrote: >> After I built version 1.1.1 on RHEL 7, I got these errors at the end of the 'make test.' What do they mean? >> >> >> Test Summary Report >> ------------------- >> ../test/recipes/15-test_dsa.t (Wstat: 768 Tests: 6 Failed: 3) >> Failed tests: 4-6 >> Non-zero exit status: 3 > Looks like something fundamentally wrong to get this many errors > (guess: perl version is too low?) > > Please run: > > make TESTS=test_dsa V=1 test > > Also lets see the output from: > > perl -v > > Matt > > >> ../test/recipes/15-test_ec.t (Wstat: 768 Tests: 5 Failed: 3) >> Failed tests: 3-5 >> Non-zero exit status: 3 >> ../test/recipes/15-test_genrsa.t (Wstat: 1024 Tests: 5 Failed: 4) >> Failed tests: 2-5 >> Non-zero exit status: 4 >> ../test/recipes/15-test_mp_rsa.t (Wstat: 7680 Tests: 31 Failed: 30) >> Failed tests: 2-31 >> Non-zero exit status: 30 >> ../test/recipes/15-test_out_option.t (Wstat: 256 Tests: 4 Failed: 1) >> Failed test: 2 >> Non-zero exit status: 1 >> ../test/recipes/15-test_rsa.t (Wstat: 768 Tests: 6 Failed: 3) >> Failed tests: 4-6 >> Non-zero exit status: 3 >> ../test/recipes/15-test_rsapss.t (Wstat: 512 Tests: 5 Failed: 2) >> Failed tests: 1, 5 >> Non-zero exit status: 2 >> ../test/recipes/20-test_enc.t (Wstat: 256 Tests: 87 Failed: 1) >> Failed test: 2 >> Non-zero exit status: 1 >> Parse errors: Bad plan. You planned 172 tests but ran 87. >> ../test/recipes/20-test_enc_more.t (Wstat: 256 Tests: 137 Failed: 1) >> Failed test: 2 >> Non-zero exit status: 1 >> ../test/recipes/25-test_crl.t (Wstat: 768 Tests: 7 Failed: 3) >> Failed tests: 2, 6-7 >> Non-zero exit status: 3 >> ../test/recipes/25-test_pkcs7.t (Wstat: 512 Tests: 3 Failed: 2) >> Failed tests: 2-3 >> Non-zero exit status: 2 >> ../test/recipes/25-test_req.t (Wstat: 1024 Tests: 9 Failed: 4) >> Failed tests: 2, 7-9 >> Non-zero exit status: 4 >> ../test/recipes/25-test_sid.t (Wstat: 256 Tests: 2 Failed: 1) >> Failed test: 2 >> Non-zero exit status: 1 >> ../test/recipes/25-test_x509.t (Wstat: 1792 Tests: 9 Failed: 7) >> Failed tests: 2-8 >> Non-zero exit status: 7 >> ../test/recipes/40-test_rehash.t (Wstat: 65280 Tests: 0 Failed: 0) >> Non-zero exit status: 255 >> Parse errors: Bad plan. You planned 4 tests but ran 0. >> ../test/recipes/60-test_x509_store.t (Wstat: 65280 Tests: 0 Failed: 0) >> Non-zero exit status: 255 >> Parse errors: Bad plan. You planned 3 tests but ran 0. >> ../test/recipes/80-test_ca.t (Wstat: 256 Tests: 5 Failed: 1) >> Failed test: 1 >> Non-zero exit status: 1 >> ../test/recipes/80-test_cms.t (Wstat: 1024 Tests: 4 Failed: 4) >> Failed tests: 1-4 >> Non-zero exit status: 4 >> ../test/recipes/80-test_ocsp.t (Wstat: 512 Tests: 11 Failed: 2) >> Failed tests: 1, 10 >> Non-zero exit status: 2 >> ../test/recipes/80-test_ssl_new.t (Wstat: 6912 Tests: 27 Failed: 27) >> Failed tests: 1-27 >> Non-zero exit status: 27 >> ../test/recipes/80-test_ssl_old.t (Wstat: 1536 Tests: 6 Failed: 6) >> Failed tests: 1-6 >> Non-zero exit status: 6 >> ../test/recipes/80-test_tsa.t (Wstat: 3328 Tests: 0 Failed: 0) >> Non-zero exit status: 13 >> Parse errors: Bad plan. You planned 20 tests but ran 0. >> ../test/recipes/90-test_store.t (Wstat: 3328 Tests: 0 Failed: 0) >> Non-zero exit status: 13 >> Parse errors: Bad plan. You planned 209 tests but ran 0. >> Files=152, Tests=850, 30 wallclock secs ( 0.38 usr 0.10 sys + 31.02 >> cusr 4.55 csys = 36.05 CPU) >> Result: FAIL >> make[1]: *** [_tests] Error 1 >> make[1]: Leaving directory `/home/mrichter/bin/openssl-1.1.1' >> make: *** [tests] Error 2 >> >> ? >> >> >> Mark Richter | Senior Staff Engineer >> SolarFlare Communications, Inc. | >> www.Solarflare.com >> 9444 Waples Street, #170, San Diego, CA 92121 >> Mobile: +1 949-632-8403 >> [Description: Description: cid:EC628FDE-ACA6-4F34-A8AE-E1F672D4E395] >> The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. >> > The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. From mrichter at solarflare.com Wed Jul 17 18:22:45 2019 From: mrichter at solarflare.com (Mark Richter) Date: Wed, 17 Jul 2019 18:22:45 +0000 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: <259a2ac6-c357-6a06-c649-b38442e20c9c@openssl.org> References: <1563312212518.62805@solarflare.com> <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> <1563316027592.81632@solarflare.com> <259a2ac6-c357-6a06-c649-b38442e20c9c@openssl.org> Message-ID: <4b90396869124f8181d67ebdc1cf2689@ocex03.SolarFlarecom.com> It works better with 1.1.1c. Thank you. -----Original Message----- From: Matt Caswell Sent: Wednesday, July 17, 2019 1:16 AM To: Mark Richter ; openssl-users at openssl.org Subject: Re: Errors building 1.1.1 on RHEL 7 On 16/07/2019 23:27, Mark Richter wrote: > Result: PASS Well that's quite odd because this test was failing for you before. I assume that after you had done the "make clean" that "make test" is still failing? Is it failing with the same set of tests that were failing before or different ones? Matt > make[1]: Leaving directory `/tmp/openssl-1.1.1' > [root at sfsdr220d openssl-1.1.1]# perl -v > > This is perl 5, version 16, subversion 3 (v5.16.3) built for > x86_64-linux-thread-multi (with 33 registered patches, see perl -V for > more detail) > > Copyright 1987-2012, Larry Wall > > Perl may be copied only under the terms of either the Artistic License > or the GNU General Public License, which may be found in the Perl 5 source kit. > > Complete documentation for Perl, including FAQ lists, should be found > on this system using "man perl" or "perldoc perl". If you have access > to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. > > > Mark Richter | Senior Staff Engineer > SolarFlare Communications, Inc. | www.Solarflare.com > 9444 Waples Street, #170, San Diego, CA 92121 > Mobile: +1 949-632-8403 > > > ________________________________________ > From: openssl-users on behalf of > Matt Caswell > Sent: Tuesday, July 16, 2019 3:20 PM > To: openssl-users at openssl.org > Subject: Re: Errors building 1.1.1 on RHEL 7 > > On 16/07/2019 22:23, Mark Richter wrote: >> After I built version 1.1.1 on RHEL 7, I got these errors at the end of the 'make test.' What do they mean? >> >> >> Test Summary Report >> ------------------- >> ../test/recipes/15-test_dsa.t (Wstat: 768 Tests: 6 Failed: 3) >> Failed tests: 4-6 >> Non-zero exit status: 3 > > Looks like something fundamentally wrong to get this many errors > (guess: perl version is too low?) > > Please run: > > make TESTS=test_dsa V=1 test > > Also lets see the output from: > > perl -v > > Matt > > >> ../test/recipes/15-test_ec.t (Wstat: 768 Tests: 5 Failed: 3) >> Failed tests: 3-5 >> Non-zero exit status: 3 >> ../test/recipes/15-test_genrsa.t (Wstat: 1024 Tests: 5 Failed: 4) >> Failed tests: 2-5 >> Non-zero exit status: 4 >> ../test/recipes/15-test_mp_rsa.t (Wstat: 7680 Tests: 31 Failed: 30) >> Failed tests: 2-31 >> Non-zero exit status: 30 >> ../test/recipes/15-test_out_option.t (Wstat: 256 Tests: 4 Failed: 1) >> Failed test: 2 >> Non-zero exit status: 1 >> ../test/recipes/15-test_rsa.t (Wstat: 768 Tests: 6 Failed: 3) >> Failed tests: 4-6 >> Non-zero exit status: 3 >> ../test/recipes/15-test_rsapss.t (Wstat: 512 Tests: 5 Failed: 2) >> Failed tests: 1, 5 >> Non-zero exit status: 2 >> ../test/recipes/20-test_enc.t (Wstat: 256 Tests: 87 Failed: 1) >> Failed test: 2 >> Non-zero exit status: 1 >> Parse errors: Bad plan. You planned 172 tests but ran 87. >> ../test/recipes/20-test_enc_more.t (Wstat: 256 Tests: 137 Failed: 1) >> Failed test: 2 >> Non-zero exit status: 1 >> ../test/recipes/25-test_crl.t (Wstat: 768 Tests: 7 Failed: 3) >> Failed tests: 2, 6-7 >> Non-zero exit status: 3 >> ../test/recipes/25-test_pkcs7.t (Wstat: 512 Tests: 3 Failed: 2) >> Failed tests: 2-3 >> Non-zero exit status: 2 >> ../test/recipes/25-test_req.t (Wstat: 1024 Tests: 9 Failed: 4) >> Failed tests: 2, 7-9 >> Non-zero exit status: 4 >> ../test/recipes/25-test_sid.t (Wstat: 256 Tests: 2 Failed: 1) >> Failed test: 2 >> Non-zero exit status: 1 >> ../test/recipes/25-test_x509.t (Wstat: 1792 Tests: 9 Failed: 7) >> Failed tests: 2-8 >> Non-zero exit status: 7 >> ../test/recipes/40-test_rehash.t (Wstat: 65280 Tests: 0 Failed: 0) >> Non-zero exit status: 255 >> Parse errors: Bad plan. You planned 4 tests but ran 0. >> ../test/recipes/60-test_x509_store.t (Wstat: 65280 Tests: 0 Failed: 0) >> Non-zero exit status: 255 >> Parse errors: Bad plan. You planned 3 tests but ran 0. >> ../test/recipes/80-test_ca.t (Wstat: 256 Tests: 5 Failed: 1) >> Failed test: 1 >> Non-zero exit status: 1 >> ../test/recipes/80-test_cms.t (Wstat: 1024 Tests: 4 Failed: 4) >> Failed tests: 1-4 >> Non-zero exit status: 4 >> ../test/recipes/80-test_ocsp.t (Wstat: 512 Tests: 11 Failed: 2) >> Failed tests: 1, 10 >> Non-zero exit status: 2 >> ../test/recipes/80-test_ssl_new.t (Wstat: 6912 Tests: 27 Failed: 27) >> Failed tests: 1-27 >> Non-zero exit status: 27 >> ../test/recipes/80-test_ssl_old.t (Wstat: 1536 Tests: 6 Failed: 6) >> Failed tests: 1-6 >> Non-zero exit status: 6 >> ../test/recipes/80-test_tsa.t (Wstat: 3328 Tests: 0 Failed: 0) >> Non-zero exit status: 13 >> Parse errors: Bad plan. You planned 20 tests but ran 0. >> ../test/recipes/90-test_store.t (Wstat: 3328 Tests: 0 Failed: 0) >> Non-zero exit status: 13 >> Parse errors: Bad plan. You planned 209 tests but ran 0. >> Files=152, Tests=850, 30 wallclock secs ( 0.38 usr 0.10 sys + 31.02 >> cusr 4.55 csys = 36.05 CPU) >> Result: FAIL >> make[1]: *** [_tests] Error 1 >> make[1]: Leaving directory `/home/mrichter/bin/openssl-1.1.1' >> make: *** [tests] Error 2 >> >> ? >> >> >> Mark Richter | Senior Staff Engineer >> SolarFlare Communications, Inc. | >> www.Solarflare.com >> 9444 Waples Street, #170, San Diego, CA 92121 >> Mobile: +1 949-632-8403 >> [Description: Description: cid:EC628FDE-ACA6-4F34-A8AE-E1F672D4E395] >> The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. >> > The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. > The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. From abaci.mjm at gmail.com Wed Jul 17 19:19:03 2019 From: abaci.mjm at gmail.com (Michael Mueller) Date: Wed, 17 Jul 2019 15:19:03 -0400 Subject: 1.1.1c build on z/OS, OS 390 Message-ID: (apologies if this email is redundant, but my first send originated from email account not registered on this list) We need to compile openssl 1.1.1c for z/OS, OS 390 Has anyone been down this path? This link provided hope: https://github.com/openssl/openssl/issues/7441 We use static libs so the shared lib issue is not an immediate concern. Some older emails helped generate possible config targets. dev at turmeric:~/wrk/openssl_build/1.1.1c/openssl-1.1.1c> perl ./Configure LIST | grep "390" linux32-s390x linux64-s390x Is Perl on z/OS required? Might be a hurdle for us. Thanks Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jul 17 19:41:40 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 17 Jul 2019 15:41:40 -0400 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: <32a535ec4406454ca5f9f5d29306868e@ocex03.SolarFlarecom.com> References: <1563312212518.62805@solarflare.com> <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> <1563316027592.81632@solarflare.com> <32a535ec4406454ca5f9f5d29306868e@ocex03.SolarFlarecom.com> Message-ID: On a system with OpenSSL 1.0.2 or OpenSSL 1.1.0 in /usr/lib (on the default search path), and especially when you're linking with other libraries that in turn were linked against the OpenSSL version in /usr/lib, using OpenSSL 1.1.1 in your application requires care... > On Jul 17, 2019, at 2:22 PM, Mark Richter wrote: > > However, although I modified our make file to use '-I/usr/local/openssl/include' and '-L/usr/local/openssl/lib', I now see this warning: > > cc -DLOG_LEVEL=LOG_INFO -Wall -Werror -D__ci_driver__ -D__ci_ul_driver__ -D_GNU_SOURCE -DWITH_MCDI_V2 -DWITH_TLS12=0 -DSOLAR_SECURE_VERSION="1.0.3.1020 (3bf2875895d5+ Wed Jul 17 11:14:55 PDT 2019)" -Isrc/include -I/usr/local/openssl/include -Isrc/tools/mc-comms -Isrc/tools/mc-comms/include -Isrc/emulators/mbedtls/include -I/usr/include/json-c -g3 -fno-omit-frame-pointer build/src/tools/sfslc.o -o build/bin/sfslc -Lbuild/lib -L/usr/local/openssl/lib -lsfsl_api -lsf_core -lcm -lss -lcrypto -lpci -lcurl -lpthread -lrt -lssl -luuid -ljson-c > /usr/bin/ld: warning: libssl.so.10, needed by /usr/lib64/libssh2.so.1, may conflict with libssl.so.1.1 > /usr/bin/ld: warning: libcrypto.so.10, needed by /usr/lib64/libssh2.so.1, may conflict with libcrypto.so.1.1 Specifically: 1. Choose some location that is not on the default library search path to install the 1.1.1 custom libraries. I use /opt/openssl/1.1/lib 2. Configure your OpenSSL build to use the corresponding "rpath": -Wl,-rpath,/opt/openssl/1.1/lib 3. Add a custom target platform to the "targets" array in Configurations/.conf. This can inherit from the configuration you're using now, but add a setting for "shlib_variant" as described in Configurations/README ... inherit_from => "", shlib_variant => "-opt", ... 4. Build and install OpenSSL 1.1.1c with "--prefix=/opt/openssl/1.1" or similar for the custom target platorm. Make sure that the SONAME and symbol versions contain the "-opt" or "_OPT" tweak. 5. Link your application against this library: -I/opt/openssl/1.1/include -L/opt/openssl/1.1/lib -Wl,-rpath,/opt/openssl/1.1/lib 6. Check with "readelf -d" that the application records the expected SONAME for the OpenSSL library (libcrypto and/or libssl) dependencies. You can now have your code using OpenSSL 1.1.1 and other libraries you use, using whichever OpenSSL they were compiled with. However, you cannot pass OpenSSL objects you create into such libraries, their use of OpenSSL must be self-contained. -- Viktor. From stanermetin at gmail.com Wed Jul 17 20:45:23 2019 From: stanermetin at gmail.com (Taner) Date: Wed, 17 Jul 2019 22:45:23 +0200 Subject: Compiling for Android Message-ID: Hi, I've been working with 1.1.1c or 1.1.1 for Android. Inside my module's CMake I refer to libssl as SHARED and IMPORTED and linking it with module's own library. When STATIC lib is used it gets "undefined reference to stdin, stderr" Maybe I am building lib with wrong options? For now, I chose dynamic and compiling is O.K but I got following error on runtime as: "java.lang.UnsatisfiedLinkError: dlopen failed: library "libssl.so" not found." The object is' there and has related function definitions indeed. Using this for building. Target Android level 26 and using NDK version 19. Have been stuck for several days and would deeply appreciate if anyone faced this issue and has an advice. -- Best wishes, Taner -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jul 17 22:58:16 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 17 Jul 2019 18:58:16 -0400 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: References: <1563312212518.62805@solarflare.com> <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> <1563316027592.81632@solarflare.com> <32a535ec4406454ca5f9f5d29306868e@ocex03.SolarFlarecom.com> Message-ID: > On Jul 17, 2019, at 3:41 PM, Viktor Dukhovni wrote: > > On a system with OpenSSL 1.0.2 or OpenSSL 1.1.0 in /usr/lib (on the default > search path), and especially when you're linking with other libraries that > in turn were linked against the OpenSSL version in /usr/lib, using OpenSSL > 1.1.1 in your application requires care... By the way, today I'm uneventfully running an SSH server and client that are linked against OpenSSL 1.0.2 for crypto in OpenSSH, but also Heimdal Kerberos for GSSAPI, which in turn is linked against OpenSSL 1.1.1 for its crypto. The two libraries co?xist (ships in the night) in the same process with no conflict. They are built with version-specific "shlib_variant" values, so that the symbol versions and SONAMEs are distinct. It all works. Perhaps there should be a blog-post or other document somewhere that explains this with a more detailed walk-through of the required steps. Anyone care to contribute? -- Viktor. From mrichter at solarflare.com Thu Jul 18 00:54:51 2019 From: mrichter at solarflare.com (Mark Richter) Date: Thu, 18 Jul 2019 00:54:51 +0000 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: References: <1563312212518.62805@solarflare.com> <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> <1563316027592.81632@solarflare.com> <32a535ec4406454ca5f9f5d29306868e@ocex03.SolarFlarecom.com> Message-ID: I'm still really new at this - a few questions: -----Original Message----- From: openssl-users On Behalf Of Viktor Dukhovni Sent: Wednesday, July 17, 2019 12:42 PM To: openssl-users at openssl.org Subject: Re: Errors building 1.1.1 on RHEL 7 On a system with OpenSSL 1.0.2 or OpenSSL 1.1.0 in /usr/lib (on the default search path), and especially when you're linking with other libraries that in turn were linked against the OpenSSL version in /usr/lib, using OpenSSL 1.1.1 in your application requires care... Specifically: 1. Choose some location that is not on the default library search path to install the 1.1.1 custom libraries. I use /opt/openssl/1.1/lib > How do I specify that? A config parameter (and which one)? 2. Configure your OpenSSL build to use the corresponding "rpath": -Wl,-rpath,/opt/openssl/1.1/lib > Again, how do I specify that? 3. Add a custom target platform to the "targets" array in Configurations/.conf. This can inherit from the configuration you're using now, but add a setting for "shlib_variant" as described in Configurations/README ... inherit_from => "", shlib_variant => "-opt", ... > I can find that... 4. Build and install OpenSSL 1.1.1c with "--prefix=/opt/openssl/1.1" or similar for the custom target platorm. Make sure that the SONAME and symbol versions contain the "-opt" or "_OPT" tweak. > Not familiar with that tweak. 5. Link your application against this library: -I/opt/openssl/1.1/include -L/opt/openssl/1.1/lib -Wl,-rpath,/opt/openssl/1.1/lib > Can do. 6. Check with "readelf -d" that the application records the expected SONAME for the OpenSSL library (libcrypto and/or libssl) dependencies. > Can do. You can now have your code using OpenSSL 1.1.1 and other libraries you use, using whichever OpenSSL they were compiled with. However, you cannot pass OpenSSL objects you create into such libraries, their use of OpenSSL must be self-contained. -- Viktor. The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. From openssl-users at dukhovni.org Thu Jul 18 01:16:48 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 17 Jul 2019 21:16:48 -0400 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: References: <1563312212518.62805@solarflare.com> <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> <1563316027592.81632@solarflare.com> <32a535ec4406454ca5f9f5d29306868e@ocex03.SolarFlarecom.com> Message-ID: <20190718011648.GN84864@straasha.imrryr.org> On Thu, Jul 18, 2019 at 12:54:51AM +0000, Mark Richter wrote: > I'm still really new at this - a few questions: Understood. > 1. Choose some location that is not on the default library search path > to install the 1.1.1 custom libraries. I use /opt/openssl/1.1/lib > > > How do I specify that? A config parameter (and which one)? --prefix=/opt/openssl/1.1 > 2. Configure your OpenSSL build to use the corresponding "rpath": > -Wl,-rpath,/opt/openssl/1.1/lib > > > Again, how do I specify that? Command-line argument to "Configure" or custom platform template. > 3. Add a custom target platform to the "targets" array in > Configurations/.conf. This can inherit from > the configuration you're using now, but add a setting > for "shlib_variant" as described in Configurations/README > > ... > inherit_from => "", > shlib_variant => "-opt", > ... > > I can find that... You'll to read the existing files in the "Configurations" directory, and cargo-cult a new target definition that meets your needs and also adds "shlib_variant". > 4. Build and install OpenSSL 1.1.1c with "--prefix=/opt/openssl/1.1" > or similar for the custom target platorm. Make sure that the > SONAME and symbol versions contain the "-opt" or "_OPT" tweak. > > > Not familiar with that tweak. Setting "shlib_variant" correctly is all it takes. The results can be verified via "readelf -d". I've not had the opportunity to write up the process in more step-by-step detail, perhaps if you get this working, you can write it as a contribution to the Wiki, or blog it, ... -- Viktor. From pgnet.dev at gmail.com Thu Jul 18 03:48:09 2019 From: pgnet.dev at gmail.com (PGNet Dev) Date: Wed, 17 Jul 2019 20:48:09 -0700 Subject: webserver+openssl 1.1.1c failing to use CHACHA20 ciphers, and fails to launch at all if just TLSv1.3 cipherlist is specified? Message-ID: I run nginx 1.17.1 + openssl 1.1.1c on linux. I typically configure recommended defaults for SSL usage, and it "just works", with ssllabs reporting my sites as healthy with an "A+", fwiw. Now, I'm currently working setting up a local-only server, attempting to get it to use TLSv1.3/CHACHA20 only. So I'm trying to tighten down restrictions in config. With my attempted restrictions in place, I've found that I'm apparently NOT using TLSv1.3/CHACHA20. The current test setup follows; I'm not clear where the problem is -- in nginx, openssl, or my config of either/both. I'm _guessing_ it's my usage/config ... I've installed which openssl /usr/local/openssl/bin/openssl openssl version OpenSSL 1.1.1c 28 May 2019 nginx is built with/linked to this version nginx -v nginx version: nginx/1.17.1 ldd `which nginx` | grep ssl libssl.so.1.1 => /usr/local/openssl/lib64/libssl.so.1.1 (0x00007f95bdc09000) libcrypto.so.1.1 => /usr/local/openssl/lib64/libcrypto.so.1.1 (0x00007f95bd6f9000) With this nginx config server { listen 10.0.1.20:443 ssl http2; server_name test.dev.lan; root /data/webapps/nulldir; index index.html; rewrite_log on; access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log info; ssl_protocols TLSv1.3 TLSv1.2; ssl_ciphers "TLS13-CHACHA20-POLY1305-SHA256 TLS13-AES-256-GCM-SHA384 TLS13-AES-128-GCM-SHA256 ECDHE-ECDSA-CHACHA20-POLY1305"; ssl_ecdh_curve X25519:prime256v1:secp384r1; ssl_prefer_server_ciphers on; ssl_trusted_certificate "/usr/local/etc/ssl/myCA/myCA.chain.crt.pem"; ssl_certificate "/usr/local/etc/ssl/test/test.ec.crt.pem"; ssl_certificate_key "/usr/local/etc/ssl/test/test.ec.key.pem"; location / { } } config check is ok, nginxconfcheck nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful and I see a TLS 1.3 handshake, openssl s_client -connect 10.0.1.20:443 -CAfile /usr/local/etc/ssl/myCA/myCA.chain.crt.pem CONNECTED(00000003) Can't use SSL_get_servername depth=2 O = dev.lan, OU = myCA, L = NewYork, ST = NY, C = US, emailAddress = admin at dev.lan, CN = myCA_ROOT verify return:1 depth=1 C = US, ST = NY, O = dev.lan, OU = myCA, CN = myCA_INT, emailAddress = admin at dev.lan verify return:1 depth=0 C = US, ST = NY, L = NewYork, O = dev.lan, OU = myCA, CN = test.dev.lan, emailAddress = admin at dev.lan verify return:1 --- Certificate chain 0 s:C = US, ST = NY, L = NewYork, O = dev.lan, OU = myCA, CN = test.dev.lan, emailAddress = admin at dev.lan i:C = US, ST = NY, O = dev.lan, OU = myCA, CN = myCA_INT, emailAddress = admin at dev.lan --- Server certificate -----BEGIN CERTIFICATE----- MIIEhjCCBAygAwIBAgICELAwCgYIKoZIzj0EAwIwgbAxCzAJBgNVBAYTAlVTMQsw ... VHldKgTNpiGuFA== -----END CERTIFICATE----- subject=C = US, ST = NY, L = NewYork, O = dev.lan, OU = myCA, CN = test.dev.lan, emailAddress = admin at dev.lan issuer=C = US, ST = NY, O = dev.lan, OU = myCA, CN = myCA_INT, emailAddress = admin at dev.lan --- No client certificate CA names sent Peer signing digest: SHA384 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 1565 bytes and written 373 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 384 bit Secure Renegotiation IS NOT supported No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: CA79B0596A2CCF19BBA9A49E086F99E7F811FAC8349888E37531E46B17FE35A9 Session-ID-ctx: Resumption PSK: 9966170E5086490D231260B15CDA6852D0CCDED661D1C075BF0DE3334C89472B158F2524282DD5F1175381B4317D8DC9 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 1e 49 9a 75 97 46 90 9c-8a ec 1b 8d ac 90 5a a6 .I.u.F........Z. ... 00d0 - 49 e4 e0 50 62 3b 45 a5-10 f9 9e 2e 43 09 41 40 I..Pb;E.....C.A@ Start Time: 1563419052 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- read R BLOCK --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: 1B65B9377224E89FA226C7DC8103E3A57C13798F9FAA0B909BC36E436EE95DC9 Session-ID-ctx: Resumption PSK: FEDFC913674474BC83DBE17F4290CA744C92E0763B450C6C489724442E2B2C6F14849A6910356B7ADFFEA3D03D2E7931 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 1e 49 9a 75 97 46 90 9c-8a ec 1b 8d ac 90 5a a6 .I.u.F........Z. ... 00d0 - c9 d0 19 a1 00 6d 72 37-f7 f4 39 6b dd 48 4d cf .....mr7..9k.HM. Start Time: 1563419052 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- read R BLOCK closed but the cipher used is TLS_AES_256_GCM_SHA384 NOT either of the CHACHA20 options, TLS-CHACHA20-POLY1305-SHA256 ECDHE-ECDSA-CHACHA20-POLY130 And, if I change nginx to be 'TLSv1.3-only', - ssl_protocols TLSv1.3 TLSv1.2; - ssl_ciphers "TLS13-CHACHA20-POLY1305-SHA256 TLS13-AES-256-GCM-SHA384 TLS13-AES-128-GCM-SHA256 ECDHE-ECDSA-CHACHA20-POLY1305"; + ssl_protocols TLSv1.3; + ssl_ciphers "TLS13-CHACHA20-POLY1305-SHA256 TLS13-AES-256-GCM-SHA384 TLS13-AES-128-GCM-SHA256"; even the webserver config check FAILs, nginxconfcheck TLS13-AES-128-GCM-SHA256") failed (SSL: error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match) nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed and the server fails to start. So I _see_ two issues, (1) when the webserver config passes, with not-just-TLS1.3 ciphers enabled in the config, I get an SSL connection, using TLS1.3, but NOT the hoped-for CHACHA20 ciphers. (2) when I list ONLY TLS1.3 ciphers, the config check fails, and the server won't start. What's preventing the use of a just TLSv1.3 cipherlist? & specifically the usage of CHACHA20 ciphers in connection? My config? My cert? other? I can certainly provide more detail; just not clear what to gather, atm. From Chethan.Kumar at toshiba-tsip.com Thu Jul 18 14:01:06 2019 From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar) Date: Thu, 18 Jul 2019 14:01:06 +0000 Subject: SSL_get_fd In-Reply-To: <447C096A3E2889439233CDD6DAB29F95D386BC1D@TOSBLRMBX03.TOSHIBA-TSIP.COM> References: <447C096A3E2889439233CDD6DAB29F95D386BC1D@TOSBLRMBX03.TOSHIBA-TSIP.COM> Message-ID: <447C096A3E2889439233CDD6DAB29F95D386C031@TOSBLRMBX03.TOSHIBA-TSIP.COM> Any help would be much appreciated. What I want to know is whether SSL_get_fd() can be used to get fd which in turn can be used with getpeername() to know the other host communicating. Thanks in advance, Chethan Kumar From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Chethan Kumar Sent: Wednesday, July 17, 2019 9:17 PM To: openssl-users at openssl.org Cc: chethu.kumar88 at gmail.com Subject: SSL_get_fd Hi all, Need an help. I am trying to print IP address of destination host by doing getpeername() on fd got using SSL_get_fd() in both SSL_accept() and SSL_connect(). Doing SSL_get_fd() fails in SSL_accept() with return value as -1 but its working in SSL_connect(). Can you please help me out in knowing what is the issue. Thanks in advance, With Regards, Chethan Kumar The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way from its use. The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use. -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Thu Jul 18 16:27:04 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 18 Jul 2019 16:27:04 +0000 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: <20190718011648.GN84864@straasha.imrryr.org> References: <1563312212518.62805@solarflare.com> <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> <1563316027592.81632@solarflare.com> <32a535ec4406454ca5f9f5d29306868e@ocex03.SolarFlarecom.com> <20190718011648.GN84864@straasha.imrryr.org> Message-ID: <6BEBBE4F-52E2-49BC-AFAD-A8CF996BD864@ll.mit.edu> I'm getting a somewhat different error trying to build OpenSSL_1_1_1-stable on CentOS 7 (similar to RHEL 7). Configuration: ./config --prefix=$HOME/openssl-1.1 --debug --openssldir=$HOME/openssl-1.1/etc --with-rand-seed=rdcpu enable-aria enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-weak-ssl-ciphers enable-zlib-dynamic shared threads enable-rfc3779 enable-ssl-trace Followed by make depend && make clean && make -j 2 all && make test && make install I'm appending the output of "perl configdata.pm -d" at the end. Here's the problem: . . . . . gcc -I. -Icrypto/include -Iinclude -fPIC -pthread -m64 -Wa,--noexecstack -std=gnu11 -O3 -march=native -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/home/ur20980/openssl-1.1/etc\"" -DENGINESDIR="\"/home/ur20980/openssl-1.1/lib/engines-1.1\"" -DZLIB -DZLIB_SHARED -MMD -MF crypto/asn1/a_strex.d.tmp -MT crypto/asn1/a_strex.o -c -o crypto/asn1/a_strex.o crypto/asn1/a_strex.c In file included from crypto/include/internal/evp_int.h:11:0, from crypto/asn1/a_sign.c:22: include/internal/refcount.h:21:25: fatal error: stdatomic.h: No such file or directory # include ^ compilation terminated. make[1]: *** [crypto/asn1/a_sign.o] Error 1 make[1]: *** Waiting for unfinished jobs.... This is the compiler used: $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) $ External flags: $ env | grep FLAGS CXXFLAGS=-std=gnu++11 -O3 -march=native CFLAGS=-std=gnu11 -O3 -march=native $ Finally, output of "perl configdata.pm -d": Command line (with current working directory = .): /usr/bin/perl ./Configure linux-x86_64 --prefix=/home/ur20980/openssl-1.1 --debug --openssldir=/home/ur20980/openssl-1.1/etc --with-rand-seed=rdcpu enable-aria enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-weak-ssl-ciphers enable-zlib-dynamic shared threads enable-rfc3779 enable-ssl-trace Perl information: /usr/bin/perl 5.16.3 for x86_64-linux-thread-multi Enabled features: aria asm async autoalginit autoerrinit autoload-config bf blake2 buildtest-c\+\+ camellia capieng cast chacha cmac cms comp ct deprecated des dgram dh dsa dtls dynamic-engine ec ec2m ecdh ecdsa ec_nistp_64_gcc_128 engine err filenames gost hw(-.+)? idea makedepend md2 md4 mdc2 multiblock nextprotoneg pinshared ocb ocsp pic poly1305 posix-io psk rc2 rc4 rc5 rdrand rfc3779 rmd160 scrypt seed shared siphash sm2 sm3 sm4 sock srp srtp sse2 ssl ssl-trace static-engine stdio tests threads tls ts ui-console whirlpool weak-ssl-ciphers zlib zlib-dynamic tls1 tls1-method tls1_1 tls1_1-method tls1_2 tls1_2-method tls1_3 dtls1 dtls1-method dtls1_2 dtls1_2-method Disabled features: afalgeng [too-old-kernel] asan [default] OPENSSL_NO_ASAN crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG crypto-mdebug-backtrace [default] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE devcryptoeng [default] OPENSSL_NO_DEVCRYPTOENG egd [default] OPENSSL_NO_EGD external-tests [default] OPENSSL_NO_EXTERNAL_TESTS fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER fuzz-afl [default] OPENSSL_NO_FUZZ_AFL heartbeats [default] OPENSSL_NO_HEARTBEATS msan [default] OPENSSL_NO_MSAN sctp [default] OPENSSL_NO_SCTP ubsan [default] OPENSSL_NO_UBSAN unit-test [default] OPENSSL_NO_UNIT_TEST ssl3 [default] OPENSSL_NO_SSL3 ssl3-method [default] OPENSSL_NO_SSL3_METHOD Config target attributes: AR => "ar", ARFLAGS => "r", CC => "gcc", CFLAGS => "-Wall -O0 -g", CXX => "g++", CXXFLAGS => "-Wall -O0 -g", HASHBANGPERL => "/usr/bin/env perl", RANLIB => "ranlib", RC => "windres", aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s aesni-mb-x86_64.s", aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o", apps_aux_src => "", apps_init_src => "", apps_obj => "", bf_asm_src => "bf_enc.c", bf_obj => "bf_enc.o", bn_asm_src => "asm/x86_64-gcc.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s", bn_obj => "asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o", bn_ops => "SIXTY_FOUR_BIT_LONG", build_file => "Makefile", build_scheme => [ "unified", "unix" ], cast_asm_src => "c_enc.c", cast_obj => "c_enc.o", cflags => "-pthread -m64", chacha_asm_src => "chacha-x86_64.s", chacha_obj => "chacha-x86_64.o", cmll_asm_src => "cmll-x86_64.s cmll_misc.c", cmll_obj => "cmll-x86_64.o cmll_misc.o", cppflags => "", cpuid_asm_src => "x86_64cpuid.s", cpuid_obj => "x86_64cpuid.o", cxxflags => "-std=c++11 -pthread -m64", defines => [ "ZLIB", "ZLIB_SHARED" ], des_asm_src => "des_enc.c fcrypt_b.c", des_obj => "des_enc.o fcrypt_b.o", disable => [ ], dso_extension => ".so", dso_scheme => "dlfcn", ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s", ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o", enable => [ "afalgeng" ], ex_libs => "-ldl -pthread", exe_extension => "", includes => [ ], keccak1600_asm_src => "keccak1600-x86_64.s", keccak1600_obj => "keccak1600-x86_64.o", lflags => "", lib_cflags => "", lib_cppflags => "-DOPENSSL_USE_NODELETE -DL_ENDIAN", lib_defines => [ ], md5_asm_src => "md5-x86_64.s", md5_obj => "md5-x86_64.o", modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s", modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o", module_cflags => "-fPIC", module_cxxflags => "", module_ldflags => "-Wl,-znodelete -shared -Wl,-Bsymbolic", multilib => "64", padlock_asm_src => "e_padlock-x86_64.s", padlock_obj => "e_padlock-x86_64.o", perlasm_scheme => "elf", poly1305_asm_src => "poly1305-x86_64.s", poly1305_obj => "poly1305-x86_64.o", rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s", rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o", rc5_asm_src => "rc5_enc.c", rc5_obj => "rc5_enc.o", rmd160_asm_src => "", rmd160_obj => "", sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s sha1-mb-x86_64.s sha256-mb-x86_64.s", sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o", shared_cflag => "-fPIC", shared_defflag => "-Wl,--version-script=", shared_defines => [ ], shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)", shared_extension_simple => ".so", shared_ldflag => "-Wl,-znodelete -shared -Wl,-Bsymbolic", shared_rcflag => "", shared_sonameflag => "-Wl,-soname=", shared_target => "linux-shared", thread_defines => [ ], thread_scheme => "pthreads", unistd => "", uplink_aux_src => "", uplink_obj => "", wp_asm_src => "wp-x86_64.s", wp_obj => "wp-x86_64.o", Recorded environment: AR = ARFLAGS = AS = ASFLAGS = BUILDFILE = CC = CFLAGS = -std=gnu11 -O3 -march=native CPP = CPPDEFINES = CPPFLAGS = CPPINCLUDES = CROSS_COMPILE = CXX = CXXFLAGS = -std=gnu++11 -O3 -march=native HASHBANGPERL = LD = LDFLAGS = LDLIBS = MT = MTFLAGS = OPENSSL_LOCAL_CONFIG_DIR = PERL = RANLIB = RC = RCFLAGS = RM = WINDRES = __CNF_CFLAGS = __CNF_CPPDEFINES = __CNF_CPPFLAGS = __CNF_CPPINCLUDES = __CNF_CXXFLAGS = __CNF_LDFLAGS = __CNF_LDLIBS = Makevars: AR = ar ARFLAGS = r CC = gcc CFLAGS = -std=gnu11 -O3 -march=native CPPDEFINES = CPPFLAGS = CPPINCLUDES = CXX = g++ CXXFLAGS = -std=gnu++11 -O3 -march=native HASHBANGPERL = /usr/bin/env perl LDFLAGS = LDLIBS = PERL = /usr/bin/perl RANLIB = ranlib RC = windres RCFLAGS = NOTE: These variables only represent the configuration view. The build file template may have processed these variables further, please have a look at the build file for more exact data: Makefile build file: Makefile build file templates: Configurations/common0.tmpl Configurations/unix-Makefile.tmpl Configurations/common.tmpl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: From uri at ll.mit.edu Thu Jul 18 16:48:16 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 18 Jul 2019 16:48:16 +0000 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: <6BEBBE4F-52E2-49BC-AFAD-A8CF996BD864@ll.mit.edu> References: <1563312212518.62805@solarflare.com> <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> <1563316027592.81632@solarflare.com> <32a535ec4406454ca5f9f5d29306868e@ocex03.SolarFlarecom.com> <20190718011648.GN84864@straasha.imrryr.org> <6BEBBE4F-52E2-49BC-AFAD-A8CF996BD864@ll.mit.edu> Message-ID: Probably, disregard: the problem seems to be related to the incomplete support for ISO C11 in GCC on CentOS (and I'm willing to bet - on RHEL). Changing the standard to "-std=gnu99" lead to a successful build with all the tests passing. ?On 7/18/19, 12:28 PM, "openssl-users on behalf of Blumenthal, Uri - 0553 - MITLL" wrote: I'm getting a somewhat different error trying to build OpenSSL_1_1_1-stable on CentOS 7 (similar to RHEL 7). Configuration: ./config --prefix=$HOME/openssl-1.1 --debug --openssldir=$HOME/openssl-1.1/etc --with-rand-seed=rdcpu enable-aria enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-weak-ssl-ciphers enable-zlib-dynamic shared threads enable-rfc3779 enable-ssl-trace Followed by make depend && make clean && make -j 2 all && make test && make install I'm appending the output of "perl configdata.pm -d" at the end. Here's the problem: . . . . . gcc -I. -Icrypto/include -Iinclude -fPIC -pthread -m64 -Wa,--noexecstack -std=gnu11 -O3 -march=native -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/home/ur20980/openssl-1.1/etc\"" -DENGINESDIR="\"/home/ur20980/openssl-1.1/lib/engines-1.1\"" -DZLIB -DZLIB_SHARED -MMD -MF crypto/asn1/a_strex.d.tmp -MT crypto/asn1/a_strex.o -c -o crypto/asn1/a_strex.o crypto/asn1/a_strex.c In file included from crypto/include/internal/evp_int.h:11:0, from crypto/asn1/a_sign.c:22: include/internal/refcount.h:21:25: fatal error: stdatomic.h: No such file or directory # include ^ compilation terminated. make[1]: *** [crypto/asn1/a_sign.o] Error 1 make[1]: *** Waiting for unfinished jobs.... This is the compiler used: $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) $ External flags: $ env | grep FLAGS CXXFLAGS=-std=gnu++11 -O3 -march=native CFLAGS=-std=gnu11 -O3 -march=native $ Finally, output of "perl configdata.pm -d": Command line (with current working directory = .): /usr/bin/perl ./Configure linux-x86_64 --prefix=/home/ur20980/openssl-1.1 --debug --openssldir=/home/ur20980/openssl-1.1/etc --with-rand-seed=rdcpu enable-aria enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-weak-ssl-ciphers enable-zlib-dynamic shared threads enable-rfc3779 enable-ssl-trace Perl information: /usr/bin/perl 5.16.3 for x86_64-linux-thread-multi Enabled features: aria asm async autoalginit autoerrinit autoload-config bf blake2 buildtest-c\+\+ camellia capieng cast chacha cmac cms comp ct deprecated des dgram dh dsa dtls dynamic-engine ec ec2m ecdh ecdsa ec_nistp_64_gcc_128 engine err filenames gost hw(-.+)? idea makedepend md2 md4 mdc2 multiblock nextprotoneg pinshared ocb ocsp pic poly1305 posix-io psk rc2 rc4 rc5 rdrand rfc3779 rmd160 scrypt seed shared siphash sm2 sm3 sm4 sock srp srtp sse2 ssl ssl-trace static-engine stdio tests threads tls ts ui-console whirlpool weak-ssl-ciphers zlib zlib-dynamic tls1 tls1-method tls1_1 tls1_1-method tls1_2 tls1_2-method tls1_3 dtls1 dtls1-method dtls1_2 dtls1_2-method Disabled features: afalgeng [too-old-kernel] asan [default] OPENSSL_NO_ASAN crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG crypto-mdebug-backtrace [default] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE devcryptoeng [default] OPENSSL_NO_DEVCRYPTOENG egd [default] OPENSSL_NO_EGD external-tests [default] OPENSSL_NO_EXTERNAL_TESTS fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER fuzz-afl [default] OPENSSL_NO_FUZZ_AFL heartbeats [default] OPENSSL_NO_HEARTBEATS msan [default] OPENSSL_NO_MSAN sctp [default] OPENSSL_NO_SCTP ubsan [default] OPENSSL_NO_UBSAN unit-test [default] OPENSSL_NO_UNIT_TEST ssl3 [default] OPENSSL_NO_SSL3 ssl3-method [default] OPENSSL_NO_SSL3_METHOD Config target attributes: AR => "ar", ARFLAGS => "r", CC => "gcc", CFLAGS => "-Wall -O0 -g", CXX => "g++", CXXFLAGS => "-Wall -O0 -g", HASHBANGPERL => "/usr/bin/env perl", RANLIB => "ranlib", RC => "windres", aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s aesni-mb-x86_64.s", aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o", apps_aux_src => "", apps_init_src => "", apps_obj => "", bf_asm_src => "bf_enc.c", bf_obj => "bf_enc.o", bn_asm_src => "asm/x86_64-gcc.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s", bn_obj => "asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o", bn_ops => "SIXTY_FOUR_BIT_LONG", build_file => "Makefile", build_scheme => [ "unified", "unix" ], cast_asm_src => "c_enc.c", cast_obj => "c_enc.o", cflags => "-pthread -m64", chacha_asm_src => "chacha-x86_64.s", chacha_obj => "chacha-x86_64.o", cmll_asm_src => "cmll-x86_64.s cmll_misc.c", cmll_obj => "cmll-x86_64.o cmll_misc.o", cppflags => "", cpuid_asm_src => "x86_64cpuid.s", cpuid_obj => "x86_64cpuid.o", cxxflags => "-std=c++11 -pthread -m64", defines => [ "ZLIB", "ZLIB_SHARED" ], des_asm_src => "des_enc.c fcrypt_b.c", des_obj => "des_enc.o fcrypt_b.o", disable => [ ], dso_extension => ".so", dso_scheme => "dlfcn", ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s", ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o", enable => [ "afalgeng" ], ex_libs => "-ldl -pthread", exe_extension => "", includes => [ ], keccak1600_asm_src => "keccak1600-x86_64.s", keccak1600_obj => "keccak1600-x86_64.o", lflags => "", lib_cflags => "", lib_cppflags => "-DOPENSSL_USE_NODELETE -DL_ENDIAN", lib_defines => [ ], md5_asm_src => "md5-x86_64.s", md5_obj => "md5-x86_64.o", modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s", modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o", module_cflags => "-fPIC", module_cxxflags => "", module_ldflags => "-Wl,-znodelete -shared -Wl,-Bsymbolic", multilib => "64", padlock_asm_src => "e_padlock-x86_64.s", padlock_obj => "e_padlock-x86_64.o", perlasm_scheme => "elf", poly1305_asm_src => "poly1305-x86_64.s", poly1305_obj => "poly1305-x86_64.o", rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s", rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o", rc5_asm_src => "rc5_enc.c", rc5_obj => "rc5_enc.o", rmd160_asm_src => "", rmd160_obj => "", sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s sha1-mb-x86_64.s sha256-mb-x86_64.s", sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o", shared_cflag => "-fPIC", shared_defflag => "-Wl,--version-script=", shared_defines => [ ], shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)", shared_extension_simple => ".so", shared_ldflag => "-Wl,-znodelete -shared -Wl,-Bsymbolic", shared_rcflag => "", shared_sonameflag => "-Wl,-soname=", shared_target => "linux-shared", thread_defines => [ ], thread_scheme => "pthreads", unistd => "", uplink_aux_src => "", uplink_obj => "", wp_asm_src => "wp-x86_64.s", wp_obj => "wp-x86_64.o", Recorded environment: AR = ARFLAGS = AS = ASFLAGS = BUILDFILE = CC = CFLAGS = -std=gnu11 -O3 -march=native CPP = CPPDEFINES = CPPFLAGS = CPPINCLUDES = CROSS_COMPILE = CXX = CXXFLAGS = -std=gnu++11 -O3 -march=native HASHBANGPERL = LD = LDFLAGS = LDLIBS = MT = MTFLAGS = OPENSSL_LOCAL_CONFIG_DIR = PERL = RANLIB = RC = RCFLAGS = RM = WINDRES = __CNF_CFLAGS = __CNF_CPPDEFINES = __CNF_CPPFLAGS = __CNF_CPPINCLUDES = __CNF_CXXFLAGS = __CNF_LDFLAGS = __CNF_LDLIBS = Makevars: AR = ar ARFLAGS = r CC = gcc CFLAGS = -std=gnu11 -O3 -march=native CPPDEFINES = CPPFLAGS = CPPINCLUDES = CXX = g++ CXXFLAGS = -std=gnu++11 -O3 -march=native HASHBANGPERL = /usr/bin/env perl LDFLAGS = LDLIBS = PERL = /usr/bin/perl RANLIB = ranlib RC = windres RCFLAGS = NOTE: These variables only represent the configuration view. The build file template may have processed these variables further, please have a look at the build file for more exact data: Makefile build file: Makefile build file templates: Configurations/common0.tmpl Configurations/unix-Makefile.tmpl Configurations/common.tmpl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: From chabboud at gmail.com Thu Jul 18 18:37:13 2019 From: chabboud at gmail.com (chabboud) Date: Thu, 18 Jul 2019 11:37:13 -0700 (MST) Subject: Server Binary Mode: open files requested by the client in binary mode In-Reply-To: <1563310568874-0.post@n7.nabble.com> References: <1563310568874-0.post@n7.nabble.com> Message-ID: <1563475033555-0.post@n7.nabble.com> For context: the binary file is for wireless firmware updates of an ARM Cortex-M4 MCU. If opening files in binary mode is not possible, I will need to implement a base64 text encoding, which unfortunately increases my image size. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From mrichter at solarflare.com Thu Jul 18 18:57:16 2019 From: mrichter at solarflare.com (Mark Richter) Date: Thu, 18 Jul 2019 18:57:16 +0000 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: <20190718011648.GN84864@straasha.imrryr.org> References: <1563312212518.62805@solarflare.com> <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> <1563316027592.81632@solarflare.com> <32a535ec4406454ca5f9f5d29306868e@ocex03.SolarFlarecom.com> <20190718011648.GN84864@straasha.imrryr.org> Message-ID: -----Original Message----- [edited] From: openssl-users On Behalf Of Viktor Dukhovni Sent: Wednesday, July 17, 2019 6:17 PM To: openssl-users at openssl.org Subject: Re: Errors building 1.1.1 on RHEL 7 >>> 2. Configure your OpenSSL build to use the corresponding "rpath": >>> -Wl,-rpath,/opt/openssl/1.1/lib >>> > > Again, how do I specify that? > > Command-line argument to "Configure" or custom platform template. Is Linux considered to be the same as (or similar enough to) Unix w.r.t. the building instructions? I'm reading the INSTALL file and it doesn't mention Linux (nor are there templates for, etc.). Also, once I figure out the build issues, how can I statically link the ssl libraries into my app? (That way we don't require our customers to build and install OpenSSL 1.1.1 pon their RHEL 7 hosts.) Are there any gotchas to doing this? E.g., our app also uses the curl library, which I believe uses the default openssl on the host. Thanks. Mark The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. From mrichter at solarflare.com Thu Jul 18 19:13:18 2019 From: mrichter at solarflare.com (Mark Richter) Date: Thu, 18 Jul 2019 19:13:18 +0000 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: References: <1563312212518.62805@solarflare.com> <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> <1563316027592.81632@solarflare.com> <32a535ec4406454ca5f9f5d29306868e@ocex03.SolarFlarecom.com> Message-ID: <2fa8b08c799a4a7b8efb25dbeed34cba@ocex03.SolarFlarecom.com> > -----Original Message----- > From: openssl-users On Behalf Of Viktor Dukhovni > Sent: Wednesday, July 17, 2019 12:42 PM > To: openssl-users at openssl.org > Subject: Re: Errors building 1.1.1 on RHEL 7 >: > 4. Build and install OpenSSL 1.1.1c with "--prefix=/opt/openssl/1.1" > or similar for the custom target platorm. Make sure that the > SONAME and symbol versions contain the "-opt" or "_OPT" tweak. In reading the various README and INSTALL files, I'm not entirely clear on what this means. I'm guessing: 1. During the build, the makefile ld flags have to include the variant -opt to get the right libraries to link. 2. Not at all clear on what the "_OPT" part means - do I need to change my source code to use this for accessors or ??? Thanks. The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. From Michael.Wojcik at microfocus.com Thu Jul 18 19:18:40 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 18 Jul 2019 19:18:40 +0000 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: References: <1563312212518.62805@solarflare.com> <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> <1563316027592.81632@solarflare.com> <32a535ec4406454ca5f9f5d29306868e@ocex03.SolarFlarecom.com> <20190718011648.GN84864@straasha.imrryr.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of > Mark Richter > Sent: Thursday, July 18, 2019 12:57 > > Is Linux considered to be the same as (or similar enough to) Unix w.r.t. the > building instructions? I'm reading the INSTALL file and it doesn't mention > Linux (nor are there templates for, etc.). Yes. Note there are a couple of references to Linux in NOTES.UNIX (and in NOTES.PERL). There are Linux-relevant stanzas in config, and so on. We build on a number of Linux platforms and distributions, including some obscure ones, generally without issues. > Also, once I figure out the build issues, how can I statically link the ssl > libraries into my app? You can Configure it for static linkage before building it, but per NOTES.UNIX you should get a set of static (archive) libraries as well as the dynamic ones even if you don't. I recommend building OpenSSL as loadable - e.g. as PIC (position-independent code) on ELF platforms such as Linux - even if you intend to link it statically. Then you have the option of statically linking it into a shared object. That's what we do: build OpenSSL as loadable, and link it statically into our own wrapper library, which is a shared object (or DLL on Windows). > Are there any gotchas to > doing this? E.g., our app also uses the curl library, which I believe uses > the default openssl on the host. As Viktor explained in some recent messages to the list, you may need to build OpenSSL with munged symbol names, to ensure each OpenSSL library resolves symbols to itself. However, if you're linking it statically that probably won't be an issue. Aside from that it shouldn't be a problem, as long as you don't try to share OpenSSL objects between the OpenSSL binaries. -- Michael Wojcik Distinguished Engineer, Micro Focus From mrichter at solarflare.com Thu Jul 18 20:34:53 2019 From: mrichter at solarflare.com (Mark Richter) Date: Thu, 18 Jul 2019 20:34:53 +0000 Subject: Error building app on RHEL 7 with openssl 1.1.1 Message-ID: This is probably along the same lines as other questions I have hasked. I built the 1.1.1 libraries and installed them in /opt/openssl1.1, then modified the Makefile to include the right -I and -L flags, but I get this error: cc -DLOG_LEVEL=LOG_INFO -Wall -Werror -D__ci_driver__ -D__ci_ul_driver__ -D_GNU_SOURCE -DWITH_MCDI_V2 -DWITH_TLS12=0 -DSOLAR_SECURE_VERSION="1.0.3.1020 (3bf2875895d5+ Thu Jul 18 13:27:17 PDT 2019)" -Isrc/include -I/opt/openssl1.1/include -Isrc/tools/mc-comms -Isrc/tools/mc-comms/include -Isrc/emulators/mbedtls/include -I/usr/include/json-c -g3 -fno-omit-frame-pointer -Isrc/cntlr build/src/cntlr/cntlr.o -o build/bin/cntlr -Lbuild/lib -L/opt/openssl1.1/lib -Wl,-rpath,/opt/openssl1.1/lib -lsf_core -lcm -lss -lcrypto -lpci -lcurl -lpthread -lrt -lssl -luuid -ljson-c /usr/bin/ld: /opt/openssl1.1/lib/libcrypto.a(dso_dlfcn.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5' /usr/lib64/libdl.so.2: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make: *** [build/bin/cntlr] Error 1 What am I missing? Mark Richter | Senior Staff Engineer SolarFlare Communications, Inc. | www.Solarflare.com 9444 Waples Street, #170, San Diego, CA 92121 Mobile: +1 949-632-8403 [Description: Description: cid:EC628FDE-ACA6-4F34-A8AE-E1F672D4E395] The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 8360 bytes Desc: image001.png URL: From pgnet.dev at gmail.com Thu Jul 18 20:50:28 2019 From: pgnet.dev at gmail.com (PGNet Dev) Date: Thu, 18 Jul 2019 13:50:28 -0700 Subject: Error building app on RHEL 7 with openssl 1.1.1 In-Reply-To: References: Message-ID: <7f848e95-886d-9d74-6cc4-816033fa978f@gmail.com> On 7/18/19 1:34 PM, Mark Richter wrote: > This is probably along the same lines as other questions I have hasked. > > I built the 1.1.1 libraries and installed them in /opt/openssl1.1, then > modified the Makefile to include the right ?I and -L flags, but I get > this error: haven't backtracked through the entire thread, but some of the errors were familiar, and noticed your comment re: "modified the Makefile" ... Are you (already) using 'config', & including the options: ./config \ --prefix=/usr/local/openssl \ --openssldir=/usr/local/openssl \ --libdir=lib64 \ -Wl,-rpath=/usr/local/openssl/lib64 \ ... Here, that configure & builds nicely without having to directly mod Makefile. From pgnet.dev at gmail.com Thu Jul 18 23:18:32 2019 From: pgnet.dev at gmail.com (PGNet Dev) Date: Thu, 18 Jul 2019 16:18:32 -0700 Subject: Error building app on RHEL 7 with openssl 1.1.1 In-Reply-To: <0c6ce2da59364ca7988a7d93123b29e2@ocex03.SolarFlarecom.com> References: <7f848e95-886d-9d74-6cc4-816033fa978f@gmail.com> <0c6ce2da59364ca7988a7d93123b29e2@ocex03.SolarFlarecom.com> Message-ID: <21458dab-c164-46f1-79af-d2c381037cd7@gmail.com> On 7/18/19 3:37 PM, Mark Richter wrote:> I use: > > ./config --prefix=/opt/openssl1.1 --openssldir=/opt/openssl1.1 --libdir=lib no-shared zlib-dynamic just fyi, the options were simply referring to the linking issue, not an inclusive list; hence the ellipsis > I'm pretty sure I can't just use the defaults you provide because the app also includes libcurl, among others, which itself uses the "normal" OpenSSL on RHEL 7, which is 1.0.2 and not compatible with 1.1.1. sounds like your distribution needs drive your build choices. fwiw, I build local curl, as well as those 'others', with openssl 1.1.1c, in order to similarly deal with dependencies. the goal is a consistent openssl1.1.1c-using stack. I haven't found depending on the distros for that to be a winning proposition. i understand it's a deep, dark, rabbit-hole; YMMV. > My app needs to use 1.1.1 without interfering with other (shared) libraries it uses that were built with 1.0.2. It also needs to have 1.1.1 statically linked because we want to ship to customers that don't have 1.1.1 installed. I suppose we could include 1.1.1 in its own directory as part of our rpm, but I'd rather not. > > These errors appeared when I tried to link with the static 1.1.1 libraries. understood. here, I build nothing statically, and build & include all the pieces-n-parts of the 1.1.1c-consistent stack for any given app in a local repo. as above, you can soon start feeling like you're building your own distro. which we do, as well ... usually necessarily, but grudgingly. From openssl-users at dukhovni.org Fri Jul 19 02:54:13 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 18 Jul 2019 22:54:13 -0400 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: References: <1563312212518.62805@solarflare.com> <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> <1563316027592.81632@solarflare.com> <32a535ec4406454ca5f9f5d29306868e@ocex03.SolarFlarecom.com> <20190718011648.GN84864@straasha.imrryr.org> Message-ID: > On Jul 18, 2019, at 2:57 PM, Mark Richter wrote: > > Also, once I figure out the build issues, how can I statically link the ssl libraries into my app? (That way we don't require our customers to build and install OpenSSL 1.1.1 pon their RHEL 7 hosts.) Are there any gotchas to doing this? E.g., our app also uses the curl library, which I believe uses the default openssl on the host. Static linking has much worse library version conflicts than dynamic linking if you're delivering a library, or if your application will run on systems where the C-library (perhaps through nsswitch modules) also loads the default OpenSSL. You lose the isolation made possible by symbol versioning with dynamic libraries. If you want to ship code to users to deploy on their own systems you should generally use whichever OpenSSL is in the base platform. To deliver a custom OpenSSL, for your application only, you'll need to build a shlib_variant shared library and perhaps make its location flexible using $ORIGIN in the dependent's run path. -- Viktor. From openssl-users at dukhovni.org Fri Jul 19 02:58:42 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 18 Jul 2019 22:58:42 -0400 Subject: Errors building 1.1.1 on RHEL 7 In-Reply-To: <2fa8b08c799a4a7b8efb25dbeed34cba@ocex03.SolarFlarecom.com> References: <1563312212518.62805@solarflare.com> <77d736a4-7457-0c97-d193-929031a2121b@openssl.org> <1563316027592.81632@solarflare.com> <32a535ec4406454ca5f9f5d29306868e@ocex03.SolarFlarecom.com> <2fa8b08c799a4a7b8efb25dbeed34cba@ocex03.SolarFlarecom.com> Message-ID: <9C4DB729-A295-4174-A45C-9F4E9F79BF59@dukhovni.org> > On Jul 18, 2019, at 3:13 PM, Mark Richter wrote: > > 2. Not at all clear on what the "_OPT" part means - do I need to change my source code to use this for accessors or ??? Just try it and see. The "_OPT" in the symbol version is internally generated from "-opt" in the shlib_variant SONAME. To support multiple shlib_variants now or in the future, add the major.minor (ABI version) to the variant tag: shlib_variant => "-opt1.1" shlib_variant => "-opt1.2" shlib_variant => "-somevendor-3.0" ... The non-alnum characters in the shlib_variant map to "_" in the symbol version, and the letters are mapped to upper case (IIRC). -- Viktor. From openssl-users at dukhovni.org Fri Jul 19 05:18:58 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 19 Jul 2019 01:18:58 -0400 Subject: Error building app on RHEL 7 with openssl 1.1.1 In-Reply-To: References: Message-ID: > On Jul 18, 2019, at 4:34 PM, Mark Richter wrote: > > cc -DLOG_LEVEL=LOG_INFO -Wall -Werror -D__ci_driver__ -D__ci_ul_driver__ -D_GNU_SOURCE -DWITH_MCDI_V2 -DWITH_TLS12=0 -DSOLAR_SECURE_VERSION="1.0.3.1020 (3bf2875895d5+ Thu Jul 18 13:27:17 PDT 2019)" -Isrc/include -I/opt/openssl1.1/include -Isrc/tools/mc-comms -Isrc/tools/mc-comms/include -Isrc/emulators/mbedtls/include -I/usr/include/json-c -g3 -fno-omit-frame-pointer -Isrc/cntlr build/src/cntlr/cntlr.o -o build/bin/cntlr -Lbuild/lib -L/opt/openssl1.1/lib -Wl,-rpath,/opt/openssl1.1/lib -lsf_core -lcm -lss -lcrypto -lpci -lcurl -lpthread -lrt -lssl -luuid -ljson-c > /usr/bin/ld: /opt/openssl1.1/lib/libcrypto.a(dso_dlfcn.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5' > /usr/lib64/libdl.so.2: error adding symbols: DSO missing from command line > collect2: error: ld returned 1 exit status > make: *** [build/bin/cntlr] Error 1 While dlopen issue can be resolved by including "-ldl" in your linker options. If you have not managed to get "shlib_variant" working, the above can't possibly work because the libcurl you're linking with likely expects the OpenSSL 1.0.2 ABI. If the same symbols are found in your the 1.1.1 library in /opt, libcurl will likely crash. If however, the /opt/openssl1.1/lib/lib{ssl,crypto} have the shlib_variant SONAMEs and symbol variants, it should work. In that case libcurl will find its symbols in something like: /usr/lib/libssl.1.0.so While your application can directly use the OpenSSL 1.1.1 API. If your use of OpenSSL is entirely via libcurl, then the custom OpenSSL will do you no good, unless you also built a custom libcurl linked against the custom OpenSSL. Perhaps you're looking for "Nix", or similar where multiple versions of dependents and dependencies co?xist more broadly on the same system (though still likely not multiple versions of the same library in the same address spaces as with the shlib_variant approach), but that's really not RHEL anymore. -- Viktor. From pgnet.dev at gmail.com Fri Jul 19 17:38:19 2019 From: pgnet.dev at gmail.com (PGNet Dev) Date: Fri, 19 Jul 2019 10:38:19 -0700 Subject: cipherlist with only tlsv1.3 ciphers reports error? Message-ID: <2fa48355-3cae-d0f2-9d7f-e6bed2170920@gmail.com> I suspect I've misunderstood usage of TLSv1.3 @ https://www.openssl.org/blog/blog/2018/02/08/tlsv1.3/ Checking cipherlist for just TLSv1.3 ciphers FAILs here, openssl ciphers -stdname -s -V 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' Error in cipher list but works if I add, e.g., 'ECDHE' group to the list openssl ciphers -stdname -s -V 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:ECDHE' 0x13,0x02 - TLS_AES_256_GCM_SHA384 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD 0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD 0x13,0x01 - TLS_AES_128_GCM_SHA256 - TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD ... Why doesn't the 1st attempt, without the group added, work? From mrichter at solarflare.com Fri Jul 19 18:03:39 2019 From: mrichter at solarflare.com (Mark Richter) Date: Fri, 19 Jul 2019 18:03:39 +0000 Subject: Error building app on RHEL 7 with openssl 1.1.1 In-Reply-To: References: Message-ID: <0a10629ce275405eb0ff24cb6f9f25f0@ocex03.SolarFlarecom.com> I've been poking around in the Configurations/* and all the README* files, and on the web, and it is not at all clear to me how/where to specify the inherit_from and shlib_variant options (probably not the right term, but...) or how the resulting libraries are distinguished from the system defaults from the app Makefile and resulting application's point of view, particularly w.r.t. how our app can use 1.1.1 while libraries we also link will use the system default (1.0.2). Do I copy an existing .conf file to a new name and edit that? If so, what am I editing from/to? What's the best way to choose the name for the new file? How do I get config (or Configure) to use the new conf file, or is that automatic? If it is automatic, how does that work for "my" platform? Assuming I use both, do I need to change my source to make use of the new libraries or just my Makefile (and how)? Our app links to both crypto/ssl and other shared libraries that use the system default. How do I tell my Makefile which one to use for both our app and the other libraries which need to use the system default openssl crypto/ssl libs? Do I tack the variant at the front or back end of the -L/-l spec lines? What about our -I specs (I guess that a -I for the custom 1.1.1 build is all our app needs since we don't care what the other libraries use for compiling)? As I mentioned, this is all quite new to me. My apologies if this is as painful for you as it has been for me. Many, many thanks in advance. I deeply appreciate all your assistance. Mark -----Original Message----- From: openssl-users On Behalf Of Viktor Dukhovni Sent: Thursday, July 18, 2019 10:19 PM To: openssl-users at openssl.org Subject: Re: Error building app on RHEL 7 with openssl 1.1.1 > On Jul 18, 2019, at 4:34 PM, Mark Richter wrote: > > cc -DLOG_LEVEL=LOG_INFO -Wall -Werror -D__ci_driver__ -D__ci_ul_driver__ -D_GNU_SOURCE -DWITH_MCDI_V2 -DWITH_TLS12=0 -DSOLAR_SECURE_VERSION="1.0.3.1020 (3bf2875895d5+ Thu Jul 18 13:27:17 PDT 2019)" -Isrc/include -I/opt/openssl1.1/include -Isrc/tools/mc-comms -Isrc/tools/mc-comms/include -Isrc/emulators/mbedtls/include -I/usr/include/json-c -g3 -fno-omit-frame-pointer -Isrc/cntlr build/src/cntlr/cntlr.o -o build/bin/cntlr -Lbuild/lib -L/opt/openssl1.1/lib -Wl,-rpath,/opt/openssl1.1/lib -lsf_core -lcm -lss -lcrypto -lpci -lcurl -lpthread -lrt -lssl -luuid -ljson-c > /usr/bin/ld: /opt/openssl1.1/lib/libcrypto.a(dso_dlfcn.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5' > /usr/lib64/libdl.so.2: error adding symbols: DSO missing from command > line > collect2: error: ld returned 1 exit status > make: *** [build/bin/cntlr] Error 1 While dlopen issue can be resolved by including "-ldl" in your linker options. If you have not managed to get "shlib_variant" working, the above can't possibly work because the libcurl you're linking with likely expects the OpenSSL 1.0.2 ABI. If the same symbols are found in your the 1.1.1 library in /opt, libcurl will likely crash. If however, the /opt/openssl1.1/lib/lib{ssl,crypto} have the shlib_variant SONAMEs and symbol variants, it should work. In that case libcurl will find its symbols in something like: /usr/lib/libssl.1.0.so While your application can directly use the OpenSSL 1.1.1 API. If your use of OpenSSL is entirely via libcurl, then the custom OpenSSL will do you no good, unless you also built a custom libcurl linked against the custom OpenSSL. Perhaps you're looking for "Nix", or similar where multiple versions of dependents and dependencies co?xist more broadly on the same system (though still likely not multiple versions of the same library in the same address spaces as with the shlib_variant approach), but that's really not RHEL anymore. -- Viktor. The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. From uri at ll.mit.edu Fri Jul 19 18:09:02 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 19 Jul 2019 18:09:02 +0000 Subject: Ciphers provided by engine not accessible...? Message-ID: <41BD7750-3570-471E-83D7-D0BA77D28FDC@ll.mit.edu> MacOS Mojave 10.14.5, OpenSSL-1.1.1c (Macports-installed). Engines defined in the openssl.cnf file: ############# [engine_section] pkcs11 = pkcs11_section gost = gost_section [pkcs11_section] engine_id = pkcs11 dynamic_path = /opt/local/lib/engines-1.1/libpkcs11.so MODULE_PATH = /Library/OpenSC/lib/opensc-pkcs11.so init = 0 [gost_section] engine_id = gost dynamic_path = /opt/local/lib/engines-1.1/gost.dylib default_algorithms = ALL CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet init = 1 ############# Note, whether the above has "init = 1" or not, does not alter the outcome. Engine in question is "gost". First, the engine does not load automatically/dynamically. For "openssl dgst" I have to specify it explicitly, otherwise the algorithms it provides, are not available: $ openssl dgst -md_gost94 ~/LastTest.log dgst: Unrecognized flag md_gost94 dgst: Use -help for summary. $ openssl dgst -engine gost -md_gost94 ~/LastTest.log engine "gost" set. md_gost94(/Users/ur20980/LastTest.log)= e82e6e515c86851498eac606722b50b724b1f95952d4edb7202029f127751816 $ Second - even when I explicitly specify the engine, "openssl speed" refuses to recognize the ciphers provided by it, though "openssl enc" shows that it can access them: $ openssl speed -engine gost -evp gost89-cbc speed: gost89-cbc is an unknown cipher or digest $ openssl enc -engine gost -ciphers engine "gost" set. Supported ciphers: -aes-128-cbc -aes-128-cfb -aes-128-cfb1 -aes-128-cfb8 -aes-128-ctr -aes-128-ecb . . . . . -des3-wrap -desx -desx-cbc -gost89 -gost89-cbc -gost89-cnt -gost89-cnt-12 -grasshopper-cbc -grasshopper-cfb -grasshopper-ctr -grasshopper-ecb -grasshopper-ofb -id-aes128-wrap -id-aes128-wrap-pad -id-aes192-wrap Seems like a bug...? -- Regards, Uri -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: From Michael.Wojcik at microfocus.com Fri Jul 19 19:25:52 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 19 Jul 2019 19:25:52 +0000 Subject: cipherlist with only tlsv1.3 ciphers reports error? In-Reply-To: <2fa48355-3cae-d0f2-9d7f-e6bed2170920@gmail.com> References: <2fa48355-3cae-d0f2-9d7f-e6bed2170920@gmail.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of > PGNet Dev > Sent: Friday, July 19, 2019 11:38 > > Checking cipherlist for just TLSv1.3 ciphers FAILs here, > > openssl ciphers -stdname -s -V 'TTLS13-CHACHA20-POLY1305- > SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' > Error in cipher list Works for me: ----- $ openssl ciphers -stdname -s -V 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' 0x13,0x02 - TLS_AES_256_GCM_SHA384 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD 0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD 0x13,0x01 - TLS_AES_128_GCM_SHA256 - TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD $ openssl version -f -p OpenSSL 1.1.1 11 Sep 2018 platform: VC-WIN64A compiler: cl /Zi /Fdossl_static.pdb /MT /Zl /Gs0 /GF /Gy /W3 /wd4090 /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSL_NO_AUTOLOAD_CONFIG ----- Different OpenSSL release? (This particular openssl.exe executable is a bit old, obviously; I haven't bothered to update the one on this machine in a while.) Difference in build configuration? Configuration file difference? -- Michael Wojcik Distinguished Engineer, Micro Focus From pgnet.dev at gmail.com Fri Jul 19 19:48:31 2019 From: pgnet.dev at gmail.com (PGNet Dev) Date: Fri, 19 Jul 2019 12:48:31 -0700 Subject: cipherlist with only tlsv1.3 ciphers reports error? In-Reply-To: References: <2fa48355-3cae-d0f2-9d7f-e6bed2170920@gmail.com> Message-ID: <91481e1e-cc5a-5d29-f759-090213a31144@gmail.com> > Works for me: heh. of COURSE it does! sanity check here, openssl ciphers -stdname -s -V 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' Error in cipher list 140042399306176:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl/ssl_lib.c:2549: > Different OpenSSL release? yes openssl version OpenSSL 1.1.1c 28 May 2019 > Difference in build configuration? yes openssl version -f -p platform: linux-x86_64 compiler: /usr/bin/gcc-9 -fPIC -pthread -m64 -Wa,--noexecstack -O3 -Wall -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fmessage-length=0 -grecord-gcc-switches -march=native -mtune=native -fno-common -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -D_GNU_SOURCE -DOPENSSL_NO_BUF_FREELISTS -DOPENSSL_NO_HEARTBEATS -DPURIFY -DSSL_FORBID_ENULL -DTERMIO -O3 -Wall -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fmessage-length=0 -grecord-gcc-switches -march=native -mtune=native -D_FORTIFY_SOURCE=2 which is quite different than yours. the config which I start with ./config -v \ --prefix=/usr/local/openssl11 \ --openssldir=/usr/local/openssl11 \ --libdir=lib64 \ -D_GNU_SOURCE \ -DOPENSSL_NO_BUF_FREELISTS \ -DOPENSSL_NO_HEARTBEATS \ -DPURIFY \ -DSSL_FORBID_ENULL \ -DTERMIO \ -Wa,--noexecstack \ -Wl,-z,relro,-z,now \ -Wall \ -Wl,-rpath=/usr/local/openssl11 \ -fno-common \ threads shared \ no-comp no-zlib no-zlib-dynaemic \ enable-ec_nistp_64_gcc_128 \ no-sctp \ no-idea \ no-mdc2 \ no-rc2 \ no-rc5 \ no-ssl3 \ no-weak-ssl-ciphers \ no-nextprotoneg That, too, is 'old' (been in use for a loooong time ...), and probably can benefit from some clean-up. As to what of that^ is causing my fail ... ? not immediately clear what the culprit is. Before I start decomposing the config difference, anything obvious leap out at you? > Configuration file difference? which config file are you referring to? From Michael.Wojcik at microfocus.com Fri Jul 19 21:08:56 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 19 Jul 2019 21:08:56 +0000 Subject: cipherlist with only tlsv1.3 ciphers reports error? In-Reply-To: <91481e1e-cc5a-5d29-f759-090213a31144@gmail.com> References: <2fa48355-3cae-d0f2-9d7f-e6bed2170920@gmail.com> , <91481e1e-cc5a-5d29-f759-090213a31144@gmail.com> Message-ID: [Apologies if the formatting here is a little screwy. For the moment I have to use Outlook Web Interface, which is even more problematic than the standalone Outlook client.] > > Different OpenSSL release? > yes > openssl version > ??????? OpenSSL 1.1.1c? 28 May 2019 Eh, that's probably it. I have the 1.1.1c sources here but haven't built it yet, on this machine. I'll give it a try over the weekend if I get a chance. > > Difference in build configuration? > yes Nothing in your config stands out to me. I think it's some change introduced in 1.1.1c. If no one else on the list chimes in, I'll try debugging it once I have a chance. > > Configuration file difference? > which config file are you referring to? The default OpenSSL configuration file. openssl.cnf, in the directory displayed by "openssl version -d". But I can't think offhand of anything in the configuration file that I'd expect to have this sort of effect. I don't think even engines would normally have any effect on cipher-list processing this way. -- Michael Wojcik From pgnet.dev at gmail.com Fri Jul 19 21:16:30 2019 From: pgnet.dev at gmail.com (PGNet Dev) Date: Fri, 19 Jul 2019 14:16:30 -0700 Subject: cipherlist with only tlsv1.3 ciphers reports error? In-Reply-To: <91481e1e-cc5a-5d29-f759-090213a31144@gmail.com> References: <2fa48355-3cae-d0f2-9d7f-e6bed2170920@gmail.com> <91481e1e-cc5a-5d29-f759-090213a31144@gmail.com> Message-ID: <718d89d9-b007-c22e-fee1-b26ecbc9d4d9@gmail.com> > Works for me: > $ openssl ciphers -stdname -s -V 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' simplifying to build defaults ./config -v \ --prefix=/usr/local/ssl-test \ --openssldir=/usr/local/ssl-test \ --libdir=lib64 \ -Wl,-rpath=/usr/local/ssl-test/lib64 make depend make builds with no apparent errors. tests pass make test ... All tests successful. Files=155, Tests=1410, 187 wallclock secs ( 7.50 usr 1.48 sys + 159.26 cusr 37.30 csys = 205.54 CPU) Result: PASS make[1]: Leaving directory '/usr/local/src/openssl11/openssl-1.1.1c' and after install make install_sw reports /usr/local/ssl-test/bin/openssl version OpenSSL 1.1.1c 28 May 2019 /usr/local/ssl-test/bin/openssl version -f -p platform: linux-x86_64 compiler: /usr/bin/gcc-9 -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG ldd /usr/local/ssl-test/bin/openssl linux-vdso.so.1 (0x00007ffe91be9000) libssl.so.1.1 => /usr/local/ssl-test/lib64/libssl.so.1.1 (0x00007f5e52c96000) libcrypto.so.1.1 => /usr/local/ssl-test/lib64/libcrypto.so.1.1 (0x00007f5e527b0000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f5e525ac000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5e5238e000) libc.so.6 => /lib64/libc.so.6 (0x00007f5e51fd4000) /lib64/ld-linux-x86-64.so.2 (0x00007f5e531df000) still fails as above, /usr/local/ssl-test/bin/openssl ciphers -v 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' Error in cipher list 139704422536256:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl/ssl_lib.c:2549: /usr/local/ssl-test/bin/openssl ciphers -v ECDHE-ECDSA-AES256-GCM-SHA384 TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD also, checking the DISTRO-build, /usr/bin/openssl version OpenSSL 1.1.0i-fips 14 Aug 2018 fails too, /usr/bin/openssl ciphers -v 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' Error in cipher list 140437655795520:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl/ssl_lib.c:2193: From pgnet.dev at gmail.com Fri Jul 19 21:31:11 2019 From: pgnet.dev at gmail.com (PGNet Dev) Date: Fri, 19 Jul 2019 14:31:11 -0700 Subject: cipherlist with only tlsv1.3 ciphers reports error? In-Reply-To: <718d89d9-b007-c22e-fee1-b26ecbc9d4d9@gmail.com> References: <2fa48355-3cae-d0f2-9d7f-e6bed2170920@gmail.com> <91481e1e-cc5a-5d29-f759-090213a31144@gmail.com> <718d89d9-b007-c22e-fee1-b26ecbc9d4d9@gmail.com> Message-ID: >>> Configuration file difference? > >> which config file are you referring to? > > The default OpenSSL configuration file. openssl.cnf, in the directory displayed by "openssl version -d". But I can't think offhand of anything in the configuration file that I'd expect to have this sort of effect. I don't think even engines would normally have any effect on cipher-list processing this way. fyi, here /usr/bin/openssl version -v OpenSSL 1.1.0i-fips 14 Aug 2018 /usr/bin/openssl version -d OPENSSLDIR: "/etc/ssl" find /etc/ssl -type f | grep cnf /etc/ssl/openssl.cnf /usr/local/ssl-test/bin/openssl version -v OpenSSL 1.1.1c 28 May 2019 /usr/local/ssl-test/bin/openssl version -d OPENSSLDIR: "/usr/local/ssl-test" find /usr/local/ssl-test -type f | grep cnf (empty) From mrichter at solarflare.com Fri Jul 19 22:13:26 2019 From: mrichter at solarflare.com (Mark Richter) Date: Fri, 19 Jul 2019 22:13:26 +0000 Subject: Error building app on RHEL 7 with openssl 1.1.1 References: <0a10629ce275405eb0ff24cb6f9f25f0@ocex03.SolarFlarecom.com> Message-ID: <9cbf7009847e4266b0ed9e20ea9fc950@ocex03.SolarFlarecom.com> I figured out the variant issue and built, but the tests are failing - see https://gist.github.com/sf-mrichter/2c5c653b3800708c1a67ba41e4992129. Still not sure how to link an app to the new ssl that uses libraries that were built with the default. -----Original Message----- From: openssl-users On Behalf Of Mark Richter Sent: Friday, July 19, 2019 11:04 AM To: openssl-users at openssl.org Subject: RE: Error building app on RHEL 7 with openssl 1.1.1 I've been poking around in the Configurations/* and all the README* files, and on the web, and it is not at all clear to me how/where to specify the inherit_from and shlib_variant options (probably not the right term, but...) or how the resulting libraries are distinguished from the system defaults from the app Makefile and resulting application's point of view, particularly w.r.t. how our app can use 1.1.1 while libraries we also link will use the system default (1.0.2). Do I copy an existing .conf file to a new name and edit that? If so, what am I editing from/to? What's the best way to choose the name for the new file? How do I get config (or Configure) to use the new conf file, or is that automatic? If it is automatic, how does that work for "my" platform? Assuming I use both, do I need to change my source to make use of the new libraries or just my Makefile (and how)? Our app links to both crypto/ssl and other shared libraries that use the system default. How do I tell my Makefile which one to use for both our app and the other libraries which need to use the system default openssl crypto/ssl libs? Do I tack the variant at the front or back end of the -L/-l spec lines? What about our -I specs (I guess that a -I for the custom 1.1.1 build is all our app needs since we don't care what the other libraries use for compiling)? As I mentioned, this is all quite new to me. My apologies if this is as painful for you as it has been for me. Many, many thanks in advance. I deeply appreciate all your assistance. Mark -----Original Message----- From: openssl-users On Behalf Of Viktor Dukhovni Sent: Thursday, July 18, 2019 10:19 PM To: openssl-users at openssl.org Subject: Re: Error building app on RHEL 7 with openssl 1.1.1 > On Jul 18, 2019, at 4:34 PM, Mark Richter wrote: > > cc -DLOG_LEVEL=LOG_INFO -Wall -Werror -D__ci_driver__ -D__ci_ul_driver__ -D_GNU_SOURCE -DWITH_MCDI_V2 -DWITH_TLS12=0 -DSOLAR_SECURE_VERSION="1.0.3.1020 (3bf2875895d5+ Thu Jul 18 13:27:17 PDT 2019)" -Isrc/include -I/opt/openssl1.1/include -Isrc/tools/mc-comms -Isrc/tools/mc-comms/include -Isrc/emulators/mbedtls/include -I/usr/include/json-c -g3 -fno-omit-frame-pointer -Isrc/cntlr build/src/cntlr/cntlr.o -o build/bin/cntlr -Lbuild/lib -L/opt/openssl1.1/lib -Wl,-rpath,/opt/openssl1.1/lib -lsf_core -lcm -lss -lcrypto -lpci -lcurl -lpthread -lrt -lssl -luuid -ljson-c > /usr/bin/ld: /opt/openssl1.1/lib/libcrypto.a(dso_dlfcn.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5' > /usr/lib64/libdl.so.2: error adding symbols: DSO missing from command > line > collect2: error: ld returned 1 exit status > make: *** [build/bin/cntlr] Error 1 While dlopen issue can be resolved by including "-ldl" in your linker options. If you have not managed to get "shlib_variant" working, the above can't possibly work because the libcurl you're linking with likely expects the OpenSSL 1.0.2 ABI. If the same symbols are found in your the 1.1.1 library in /opt, libcurl will likely crash. If however, the /opt/openssl1.1/lib/lib{ssl,crypto} have the shlib_variant SONAMEs and symbol variants, it should work. In that case libcurl will find its symbols in something like: /usr/lib/libssl.1.0.so While your application can directly use the OpenSSL 1.1.1 API. If your use of OpenSSL is entirely via libcurl, then the custom OpenSSL will do you no good, unless you also built a custom libcurl linked against the custom OpenSSL. Perhaps you're looking for "Nix", or similar where multiple versions of dependents and dependencies co?xist more broadly on the same system (though still likely not multiple versions of the same library in the same address spaces as with the shlib_variant approach), but that's really not RHEL anymore. -- Viktor. The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. From openssl-users at dukhovni.org Sat Jul 20 14:28:54 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 20 Jul 2019 10:28:54 -0400 Subject: cipherlist with only tlsv1.3 ciphers reports error? In-Reply-To: <2fa48355-3cae-d0f2-9d7f-e6bed2170920@gmail.com> References: <2fa48355-3cae-d0f2-9d7f-e6bed2170920@gmail.com> Message-ID: <20190720142854.GQ84864@straasha.imrryr.org> On Fri, Jul 19, 2019 at 10:38:19AM -0700, PGNet Dev wrote: > I suspect I've misunderstood usage of TLSv1.3 @ > > https://www.openssl.org/blog/blog/2018/02/08/tlsv1.3/ > > Checking cipherlist for just TLSv1.3 ciphers FAILs here, > > openssl ciphers -stdname -s -V 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' > Error in cipher list This is expected. Try: openssl ciphers -tls1_3 -stdname -s -V -ciphersuites 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256' 'aNULL' -- Viktor. From pgnet.dev at gmail.com Sat Jul 20 14:35:49 2019 From: pgnet.dev at gmail.com (PGNet Dev) Date: Sat, 20 Jul 2019 07:35:49 -0700 Subject: cipherlist with only tlsv1.3 ciphers reports error? In-Reply-To: <20190720142854.GQ84864@straasha.imrryr.org> References: <2fa48355-3cae-d0f2-9d7f-e6bed2170920@gmail.com> <20190720142854.GQ84864@straasha.imrryr.org> Message-ID: <17b2ecf4-c214-5feb-f892-c59870e3c056@gmail.com> Hi, On 7/20/19 7:28 AM, Viktor Dukhovni wrote: > On Fri, Jul 19, 2019 at 10:38:19AM -0700, PGNet Dev wrote: > >> I suspect I've misunderstood usage of TLSv1.3 @ >> >> https://www.openssl.org/blog/blog/2018/02/08/tlsv1.3/ >> >> Checking cipherlist for just TLSv1.3 ciphers FAILs here, >> >> openssl ciphers -stdname -s -V 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' >> Error in cipher list > > This is expected. Try: > > openssl ciphers -tls1_3 -stdname -s -V -ciphersuites 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256' 'aNULL' > That works here, openssl ciphers -tls1_3 -stdname -s -V -ciphersuites 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256' 'aNULL' 0x13,0x02 - TLS_AES_256_GCM_SHA384 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD 0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD Can you clarify WHY that's expected? Atm, it's inclear why it's working for Michael Wojcik ... different version? something's changed? And, in webserver ssl_cipher configs, specifying ONLY the tls13 ciphersuites fires a config error. Until I add a group, e.g. ECDHE, as well, to the spec. If this^^ is 'expected', is that, then, actually an error? From openssl-users at dukhovni.org Sat Jul 20 15:17:45 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 20 Jul 2019 11:17:45 -0400 Subject: cipherlist with only tlsv1.3 ciphers reports error? In-Reply-To: <17b2ecf4-c214-5feb-f892-c59870e3c056@gmail.com> References: <2fa48355-3cae-d0f2-9d7f-e6bed2170920@gmail.com> <20190720142854.GQ84864@straasha.imrryr.org> <17b2ecf4-c214-5feb-f892-c59870e3c056@gmail.com> Message-ID: <20190720151745.GR84864@straasha.imrryr.org> On Sat, Jul 20, 2019 at 07:35:49AM -0700, PGNet Dev wrote: > >> Checking cipherlist for just TLSv1.3 ciphers FAILs here, > >> > >> openssl ciphers -stdname -s -V 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' > >> Error in cipher list > > > > This is expected. Try: > > > > openssl ciphers -tls1_3 -stdname -s -V -ciphersuites 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256' 'aNULL' TLS 1.3 cipher code points are fundamentally different from TLS 1.0?1.2 cipher codepoints. You can't use any of the former in TLS 1.2 nor any of the latter in TLS 1.3. Many users specify a restricted set of TLS 1.2 ciphers, and if there was only one global cipherlist, they would as a result disable TLS 1.3 entirely. For the above and related reasons, in OpenSSL 1.1.1 the TLS 1.3 ciphersuite codepoints are managed separately from the TLS 1.0?1.2 cipher codepoints. In the ciphers(1) command, the final argument is the desired TLS 1.0?1.2 ciphers, while the "-ciphersuites" option selects the TLS 1.3 code points. > Can you clarify WHY that's expected? What's expected is that listing the TLS 1.3 ciphersuite names in the final argument that specifies TLS 1.2 ciphers will produce an error (empty set of ciphers). > Atm, it's inclear why it's working for Michael Wojcik ... different version? > something's changed? I am discounting his report of success. The full set of TLS 1.3 ciphers is enabled by default. If he did not use the -ciphersuites option, he was overriding just the 1.2 code points, and somehow managed to ultimately list just the TLS 1.3 code points. He also had a typo in the command he posted. It is not pertinent. > And, in webserver ssl_cipher configs, specifying ONLY the tls13 ciphersuites > fires a config error. Until I add a group, e.g. ECDHE, as well, to the > spec. This is expected. That "ssl_cipher" setting controls ONLY the TLS 1.2 cipherlist. To enable only the TLS 1.3 *protocol*, change the settings that control the protocol versions, not the ciphers. > If this^^ is 'expected', is that, then, actually an error? No. You've just not read the documentation carefully. -- Viktor. From pgnet.dev at gmail.com Sat Jul 20 16:09:29 2019 From: pgnet.dev at gmail.com (PGNet Dev) Date: Sat, 20 Jul 2019 09:09:29 -0700 Subject: cipherlist with only tlsv1.3 ciphers reports error? In-Reply-To: <20190720151745.GR84864@straasha.imrryr.org> References: <2fa48355-3cae-d0f2-9d7f-e6bed2170920@gmail.com> <20190720142854.GQ84864@straasha.imrryr.org> <17b2ecf4-c214-5feb-f892-c59870e3c056@gmail.com> <20190720151745.GR84864@straasha.imrryr.org> Message-ID: <8c020635-e7eb-53d2-e3f4-a49158e88ad5@gmail.com> On 7/20/19 8:17 AM, Viktor Dukhovni wrote: > On Sat, Jul 20, 2019 at 07:35:49AM -0700, PGNet Dev wrote: > >>>> Checking cipherlist for just TLSv1.3 ciphers FAILs here, >>>> >>>> openssl ciphers -stdname -s -V 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384' >>>> Error in cipher list >>> >>> This is expected. Try: >>> >>> openssl ciphers -tls1_3 -stdname -s -V -ciphersuites 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256' 'aNULL' > > TLS 1.3 cipher code points are fundamentally different from TLS 1.0?1.2 Thanks, mostly clear now. > You've just not read the documentation carefully. You're possibly making some not-necessarily valid assumptions about who's read what, with what level of 'care', and the clarity of the written documents ... From Michael.Wojcik at microfocus.com Sat Jul 20 16:57:04 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Sat, 20 Jul 2019 16:57:04 +0000 Subject: cipherlist with only tlsv1.3 ciphers reports error? In-Reply-To: <20190720151745.GR84864@straasha.imrryr.org> References: <2fa48355-3cae-d0f2-9d7f-e6bed2170920@gmail.com> <20190720142854.GQ84864@straasha.imrryr.org> <17b2ecf4-c214-5feb-f892-c59870e3c056@gmail.com> <20190720151745.GR84864@straasha.imrryr.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of > Viktor Dukhovni > Sent: Saturday, July 20, 2019 09:18 > > > Atm, it's inclear why it's working for Michael Wojcik ... different > version? > > something's changed? > > I am discounting his report of success. The full set of TLS 1.3 > ciphers is enabled by default. If he did not use the -ciphersuites > option, he was overriding just the 1.2 code points, and somehow > managed to ultimately list just the TLS 1.3 code points. He > also had a typo in the command he posted. It is not pertinent. Shrug. I copied and pasted the command from PGNet Dev's email, and copied and pasted the result into my email. (I thought "TTLS" was a typo, but when the command worked as presented in the original email, didn't investigate further.) What I posted is nothing more or less than what the openssl executable currently on my system returns for that command. Clearly that build of 1.1.1 does not work the way you expect. That said, I'm no longer interested in *why* it doesn't. That's not the OpenSSL build we're shipping in any current product, and the configuration mechanism for the products I'm responsible for works as expected; that is, our tests confirm that the product is enabling both the configured TLSv1.3 suites and the configured pre-1.3 suites, on both client and server sides. I will, of course, save copies of Viktor's notes, since they contain important information about the operation of the ciphers command. -- Michael Wojcik Distinguished Engineer, Micro Focus From beldmit at gmail.com Mon Jul 22 08:33:34 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 22 Jul 2019 11:33:34 +0300 Subject: Ciphers provided by engine not accessible...? In-Reply-To: <41BD7750-3570-471E-83D7-D0BA77D28FDC@ll.mit.edu> References: <41BD7750-3570-471E-83D7-D0BA77D28FDC@ll.mit.edu> Message-ID: Dear Uri, Is this a full configuration file? ??, 19 ???? 2019 ?., 21:09 Blumenthal, Uri - 0553 - MITLL : > MacOS Mojave 10.14.5, OpenSSL-1.1.1c (Macports-installed). > > Engines defined in the openssl.cnf file: > > ############# > [engine_section] > pkcs11 = pkcs11_section > gost = gost_section > > [pkcs11_section] > engine_id = pkcs11 > dynamic_path = /opt/local/lib/engines-1.1/libpkcs11.so > MODULE_PATH = /Library/OpenSC/lib/opensc-pkcs11.so > init = 0 > > [gost_section] > engine_id = gost > dynamic_path = /opt/local/lib/engines-1.1/gost.dylib > default_algorithms = ALL > CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet > init = 1 > ############# > > Note, whether the above has "init = 1" or not, does not alter the outcome. > > Engine in question is "gost". > > First, the engine does not load automatically/dynamically. For "openssl > dgst" I have to specify it explicitly, otherwise the algorithms it > provides, are not available: > > $ openssl dgst -md_gost94 ~/LastTest.log > dgst: Unrecognized flag md_gost94 > dgst: Use -help for summary. > $ openssl dgst -engine gost -md_gost94 ~/LastTest.log > engine "gost" set. > md_gost94(/Users/ur20980/LastTest.log)= > e82e6e515c86851498eac606722b50b724b1f95952d4edb7202029f127751816 > $ > > Second - even when I explicitly specify the engine, "openssl speed" > refuses to recognize the ciphers provided by it, though "openssl enc" shows > that it can access them: > > $ openssl speed -engine gost -evp gost89-cbc > speed: gost89-cbc is an unknown cipher or digest > $ openssl enc -engine gost -ciphers > engine "gost" set. > Supported ciphers: > -aes-128-cbc -aes-128-cfb -aes-128-cfb1 > > -aes-128-cfb8 -aes-128-ctr -aes-128-ecb > . . . . . > -des3-wrap -desx -desx-cbc > > -gost89 -gost89-cbc -gost89-cnt > > -gost89-cnt-12 -grasshopper-cbc -grasshopper-cfb > > -grasshopper-ctr -grasshopper-ecb -grasshopper-ofb > > -id-aes128-wrap -id-aes128-wrap-pad -id-aes192-wrap > > > Seems like a bug...? > -- > Regards, > Uri > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrichter at solarflare.com Mon Jul 22 16:48:19 2019 From: mrichter at solarflare.com (Mark Richter) Date: Mon, 22 Jul 2019 16:48:19 +0000 Subject: Error building app on RHEL 7 with openssl 1.1.1 In-Reply-To: <9cbf7009847e4266b0ed9e20ea9fc950@ocex03.SolarFlarecom.com> References: <0a10629ce275405eb0ff24cb6f9f25f0@ocex03.SolarFlarecom.com> ,<9cbf7009847e4266b0ed9e20ea9fc950@ocex03.SolarFlarecom.com> Message-ID: <1563814095874.26312@solarflare.com> I forgot to mention that this round was on CentOS 7, and the tests fail with or without the variant changes. Mark Richter | Senior Staff Engineer SolarFlare Communications, Inc. | www.Solarflare.com 9444 Waples Street, #170, San Diego, CA 92121 Mobile: +1 949-632-8403 ________________________________________ From: openssl-users on behalf of Mark Richter Sent: Friday, July 19, 2019 3:13 PM To: openssl-users at openssl.org Subject: RE: Error building app on RHEL 7 with openssl 1.1.1 I figured out the variant issue and built, but the tests are failing - see https://gist.github.com/sf-mrichter/2c5c653b3800708c1a67ba41e4992129. Still not sure how to link an app to the new ssl that uses libraries that were built with the default. -----Original Message----- From: openssl-users On Behalf Of Mark Richter Sent: Friday, July 19, 2019 11:04 AM To: openssl-users at openssl.org Subject: RE: Error building app on RHEL 7 with openssl 1.1.1 I've been poking around in the Configurations/* and all the README* files, and on the web, and it is not at all clear to me how/where to specify the inherit_from and shlib_variant options (probably not the right term, but...) or how the resulting libraries are distinguished from the system defaults from the app Makefile and resulting application's point of view, particularly w.r.t. how our app can use 1.1.1 while libraries we also link will use the system default (1.0.2). Do I copy an existing .conf file to a new name and edit that? If so, what am I editing from/to? What's the best way to choose the name for the new file? How do I get config (or Configure) to use the new conf file, or is that automatic? If it is automatic, how does that work for "my" platform? Assuming I use both, do I need to change my source to make use of the new libraries or just my Makefile (and how)? Our app links to both crypto/ssl and other shared libraries that use the system default. How do I tell my Makefile which one to use for both our app and the other libraries which need to use the system default openssl crypto/ssl libs? Do I tack the variant at the front or back end of the -L/-l spec lines? What about our -I specs (I guess that a -I for the custom 1.1.1 build is all our app needs since we don't care what the other libraries use for compiling)? As I mentioned, this is all quite new to me. My apologies if this is as painful for you as it has been for me. Many, many thanks in advance. I deeply appreciate all your assistance. Mark -----Original Message----- From: openssl-users On Behalf Of Viktor Dukhovni Sent: Thursday, July 18, 2019 10:19 PM To: openssl-users at openssl.org Subject: Re: Error building app on RHEL 7 with openssl 1.1.1 > On Jul 18, 2019, at 4:34 PM, Mark Richter wrote: > > cc -DLOG_LEVEL=LOG_INFO -Wall -Werror -D__ci_driver__ -D__ci_ul_driver__ -D_GNU_SOURCE -DWITH_MCDI_V2 -DWITH_TLS12=0 -DSOLAR_SECURE_VERSION="1.0.3.1020 (3bf2875895d5+ Thu Jul 18 13:27:17 PDT 2019)" -Isrc/include -I/opt/openssl1.1/include -Isrc/tools/mc-comms -Isrc/tools/mc-comms/include -Isrc/emulators/mbedtls/include -I/usr/include/json-c -g3 -fno-omit-frame-pointer -Isrc/cntlr build/src/cntlr/cntlr.o -o build/bin/cntlr -Lbuild/lib -L/opt/openssl1.1/lib -Wl,-rpath,/opt/openssl1.1/lib -lsf_core -lcm -lss -lcrypto -lpci -lcurl -lpthread -lrt -lssl -luuid -ljson-c > /usr/bin/ld: /opt/openssl1.1/lib/libcrypto.a(dso_dlfcn.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5' > /usr/lib64/libdl.so.2: error adding symbols: DSO missing from command > line > collect2: error: ld returned 1 exit status > make: *** [build/bin/cntlr] Error 1 While dlopen issue can be resolved by including "-ldl" in your linker options. If you have not managed to get "shlib_variant" working, the above can't possibly work because the libcurl you're linking with likely expects the OpenSSL 1.0.2 ABI. If the same symbols are found in your the 1.1.1 library in /opt, libcurl will likely crash. If however, the /opt/openssl1.1/lib/lib{ssl,crypto} have the shlib_variant SONAMEs and symbol variants, it should work. In that case libcurl will find its symbols in something like: /usr/lib/libssl.1.0.so While your application can directly use the OpenSSL 1.1.1 API. If your use of OpenSSL is entirely via libcurl, then the custom OpenSSL will do you no good, unless you also built a custom libcurl linked against the custom OpenSSL. Perhaps you're looking for "Nix", or similar where multiple versions of dependents and dependencies co?xist more broadly on the same system (though still likely not multiple versions of the same library in the same address spaces as with the shlib_variant approach), but that's really not RHEL anymore. -- Viktor. The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. From mrichter at solarflare.com Mon Jul 22 16:50:46 2019 From: mrichter at solarflare.com (Mark Richter) Date: Mon, 22 Jul 2019 16:50:46 +0000 Subject: How do I build an app with 1.1.1 that uses libraries built against 1.0.2? Message-ID: <1563814233970.61046@solarflare.com> I thought I'd start a new thread for this as it may have been buried in my other thread. We have a RHEL 7 app that links to (at least) libcurl that uses OpenSSL 1.0.2, but our app needs 1.1.1. I'm not at all sure how to set up our Makefile to handle this. Thanks. Mark Richter | Senior Staff Engineer SolarFlare Communications, Inc. | www.Solarflare.com 9444 Waples Street, #170, San Diego, CA 92121 Mobile: +1 949-632-8403 [Description: Description: cid:EC628FDE-ACA6-4F34-A8AE-E1F672D4E395] The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. From andrew.lynch at atos.net Mon Jul 22 16:44:42 2019 From: andrew.lynch at atos.net (Lynch, Andrew) Date: Mon, 22 Jul 2019 16:44:42 +0000 Subject: Engine updating a key's ex data in sign/encrypt method? Message-ID: <04b04d9c58af4c21aa6d339a330ce408@atos.net> Hi, I am wondering whether it is ok to update a key's ex data from within an engine method that is using the key. This is with both OpenSSL 1.1.1a and 1.0.2j. In my engine's load_privkey() method I connect to the HSM and obtain handles for a session and the key object. Both handles are then stored in the key's ex data using RSA_set_ex_data() or EC_KEY_set_ex_data(). They will later be released by the registered free_func. The sign and/or encrypt methods use these handles when making their calls to the HSM API. This works fine for single operations like an openssl x509 command line, but not for long running applications such as stunnel. It appears that stunnel loads all configured keys and certs at startup and then waits for clients to connect. If there is no activity for a while the HSM will time out my session handle and the next sign operation using that session fails. I can catch the error and reconnect, but this results in a new session handle. The next time a client calls the same service, that key's ex data still contains the old outdated session handle resulting in the same error all over again. So whenever I renew a session handle in the sign method I need to update the ex data of the affected key with the new value. This appears to work fine for EC keys by calling EC_KEY_set_ex_data() from within the engine's ecdsa_do_sign() method. The same goes for RSA keys in rsa_private_decrypt() and rsa_private_encrypt(), but with rsa_sign() I have a problem in that the key parameter is const RSA *. Is the lack of const in rsa_private_encrypt() and ecdsa_do_sign() an oversight and I should not be manipulating ex data of the provided key in this way? Or is the const in rsa_sign() too strict and it is actually ok to modify the ex data of the key? Regards, Andrew. From uri at ll.mit.edu Mon Jul 22 16:58:23 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 22 Jul 2019 16:58:23 +0000 Subject: Ciphers provided by engine not accessible...? In-Reply-To: References: <41BD7750-3570-471E-83D7-D0BA77D28FDC@ll.mit.edu> Message-ID: <9626169A-7C7C-4AB5-AA47-4801CE30D514@ll.mit.edu> Is this a full configuration file? It certainly isn?t ? but I figured I?d post only the relevant part of it, rather than ?crowding? the mailing list with something unnecessary. Are there any other parts of the openssl.cnf that could be related to this issue, or help diagnose it?s cause? ??, 19 ???? 2019 ?., 21:09 Blumenthal, Uri - 0553 - MITLL : MacOS Mojave 10.14.5, OpenSSL-1.1.1c (Macports-installed). Engines defined in the openssl.cnf file: ############# [engine_section] pkcs11 = pkcs11_section gost = gost_section [pkcs11_section] engine_id = pkcs11 dynamic_path = /opt/local/lib/engines-1.1/libpkcs11.so MODULE_PATH = /Library/OpenSC/lib/opensc-pkcs11.so init = 0 [gost_section] engine_id = gost dynamic_path = /opt/local/lib/engines-1.1/gost.dylib default_algorithms = ALL CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet init = 1 ############# Note, whether the above has "init = 1" or not, does not alter the outcome. Engine in question is "gost". First, the engine does not load automatically/dynamically. For "openssl dgst" I have to specify it explicitly, otherwise the algorithms it provides, are not available: $ openssl dgst -md_gost94 ~/LastTest.log dgst: Unrecognized flag md_gost94 dgst: Use -help for summary. $ openssl dgst -engine gost -md_gost94 ~/LastTest.log engine "gost" set. md_gost94(/Users/ur20980/LastTest.log)= e82e6e515c86851498eac606722b50b724b1f95952d4edb7202029f127751816 $ Second - even when I explicitly specify the engine, "openssl speed" refuses to recognize the ciphers provided by it, though "openssl enc" shows that it can access them: $ openssl speed -engine gost -evp gost89-cbc speed: gost89-cbc is an unknown cipher or digest $ openssl enc -engine gost -ciphers engine "gost" set. Supported ciphers: -aes-128-cbc -aes-128-cfb -aes-128-cfb1 -aes-128-cfb8 -aes-128-ctr -aes-128-ecb . . . . . -des3-wrap -desx -desx-cbc -gost89 -gost89-cbc -gost89-cnt -gost89-cnt-12 -grasshopper-cbc -grasshopper-cfb -grasshopper-ctr -grasshopper-ecb -grasshopper-ofb -id-aes128-wrap -id-aes128-wrap-pad -id-aes192-wrap Seems like a bug...? -- Regards, Uri -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: From openssl-users at dukhovni.org Mon Jul 22 17:46:27 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 22 Jul 2019 13:46:27 -0400 Subject: How do I build an app with 1.1.1 that uses libraries built against 1.0.2? In-Reply-To: <1563814233970.61046@solarflare.com> References: <1563814233970.61046@solarflare.com> Message-ID: <20190722174627.GS84864@straasha.imrryr.org> On Mon, Jul 22, 2019 at 04:50:46PM +0000, Mark Richter wrote: > We have a RHEL 7 app that links to (at least) libcurl that uses OpenSSL 1.0.2, but our app needs 1.1.1. > > I'm not at all sure how to set up our Makefile to handle this. The libcurl shared library will be looking for "libssl.so.1.0.0" and "libcrypto.so.1.0.0" with associated symbol versions, assuming the RHEL 7 OpenSSL libraries in /usr/lib employ symbol versioning. Under the above assumptions, once you have the "shlib_variant" OpenSSL built, you can just link: cc -o application application.o \ -L/opt/openssl1.1 -Wl,-rpath,/opt/openssl1.1/lib -lssl -lcrypto \ -lcurl \ ... With the OpenSSL libraries listed before libcurl, just in case your linker automatically searches nested dependencies first and ends up linking application.o against libcurl's choice of OpenSSL libraries. This works on Debian systems where base system's libssl and libcrypto have symbol versions. If, however, the system libssl and libcrypto lack symbol versions, (do they on RHEL 7?) then libcurl will not be explicitly bound to the base-system OpenSSL API, and depending on the order in which libraries are loaded may inadvertently end up with the 1.1.1 symbol bindings (and then fail). In that case it may be helpful to list libcurl first, hoping that it will be loaded first, and resolved against the system OpenSSL, with the variant OpenSSL for your application loaded second, assuming that the "dependents of dependents" issue is not a problem. But at the end of the day, that is probably too fragile, you might also load more libraries at runtime, and those could end up with the wrong symbols. So if your base system's libssl and libcrypto have no symbol versions, you just have to accept the fact that you're stuck with the system OpenSSL libraries for better or worse. -- Viktor. From beldmit at gmail.com Mon Jul 22 18:05:13 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 22 Jul 2019 21:05:13 +0300 Subject: Ciphers provided by engine not accessible...? In-Reply-To: <9626169A-7C7C-4AB5-AA47-4801CE30D514@ll.mit.edu> References: <41BD7750-3570-471E-83D7-D0BA77D28FDC@ll.mit.edu> <9626169A-7C7C-4AB5-AA47-4801CE30D514@ll.mit.edu> Message-ID: Hello, ??, 22 ???? 2019 ?., 19:58 Blumenthal, Uri - 0553 - MITLL : > Is this a full configuration file? > > > > It certainly isn?t ? but I figured I?d post only the relevant part of it, > rather than ?crowding? the mailing list with something unnecessary. > > > > Are there any other parts of the openssl.cnf that could be related to this > issue, or help diagnose it?s cause? > > > Does your configuration file contain a header similar to described in the Gost engine documentation? If no, the gost section is not processed. I don't remember any significant changes in 1.1.1 engine processing, and it works with 1.0.2 Sorry for brevity, I'll be able to look in more details only at the beginning of August. > > > > > ??, 19 ???? 2019 ?., 21:09 Blumenthal, Uri - 0553 - MITLL >: > > MacOS Mojave 10.14.5, OpenSSL-1.1.1c (Macports-installed). > > Engines defined in the openssl.cnf file: > > ############# > [engine_section] > pkcs11 = pkcs11_section > gost = gost_section > > [pkcs11_section] > engine_id = pkcs11 > dynamic_path = /opt/local/lib/engines-1.1/libpkcs11.so > MODULE_PATH = /Library/OpenSC/lib/opensc-pkcs11.so > init = 0 > > [gost_section] > engine_id = gost > dynamic_path = /opt/local/lib/engines-1.1/gost.dylib > default_algorithms = ALL > CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet > init = 1 > ############# > > Note, whether the above has "init = 1" or not, does not alter the outcome. > > Engine in question is "gost". > > First, the engine does not load automatically/dynamically. For "openssl > dgst" I have to specify it explicitly, otherwise the algorithms it > provides, are not available: > > $ openssl dgst -md_gost94 ~/LastTest.log > dgst: Unrecognized flag md_gost94 > dgst: Use -help for summary. > $ openssl dgst -engine gost -md_gost94 ~/LastTest.log > engine "gost" set. > md_gost94(/Users/ur20980/LastTest.log)= > e82e6e515c86851498eac606722b50b724b1f95952d4edb7202029f127751816 > $ > > Second - even when I explicitly specify the engine, "openssl speed" > refuses to recognize the ciphers provided by it, though "openssl enc" shows > that it can access them: > > $ openssl speed -engine gost -evp gost89-cbc > speed: gost89-cbc is an unknown cipher or digest > $ openssl enc -engine gost -ciphers > engine "gost" set. > Supported ciphers: > -aes-128-cbc -aes-128-cfb -aes-128-cfb1 > > -aes-128-cfb8 -aes-128-ctr -aes-128-ecb > . . . . . > -des3-wrap -desx -desx-cbc > > -gost89 -gost89-cbc -gost89-cnt > > -gost89-cnt-12 -grasshopper-cbc -grasshopper-cfb > > -grasshopper-ctr -grasshopper-ecb -grasshopper-ofb > > -id-aes128-wrap -id-aes128-wrap-pad -id-aes192-wrap > > > Seems like a bug...? > -- > Regards, > Uri > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Mon Jul 22 18:16:20 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 22 Jul 2019 18:16:20 +0000 Subject: Ciphers provided by engine not accessible...? In-Reply-To: References: <41BD7750-3570-471E-83D7-D0BA77D28FDC@ll.mit.edu> <9626169A-7C7C-4AB5-AA47-4801CE30D514@ll.mit.edu> Message-ID: Are there any other parts of the openssl.cnf that could be related to this issue, or help diagnose it?s cause? Does your configuration file contain a header similar to described in the Gost engine documentation? If no, the gost section is not processed.? I don't remember any significant changes in 1.1.1 engine processing, and it works with 1.0.2 Sorry for brevity, I'll be able to look in more details only at the beginning of August.? Darn? You were right ? that header (openssl_conf = openssl_def) was NOT present. Adding it resulted in success (with some error messages): $ openssl speed -engine gost -evp gost89-cbc engine "gost" set. Doing gost89-cbc for 3s on 16 size blocks: 13107440 gost89-cbc's in 2.99s Doing gost89-cbc for 3s on 64 size blocks: 3383428 gost89-cbc's in 3.00s Doing gost89-cbc for 3s on 256 size blocks: 849765 gost89-cbc's in 3.00s Doing gost89-cbc for 3s on 1024 size blocks: 211166 gost89-cbc's in 3.00s Doing gost89-cbc for 3s on 8192 size blocks: 26167 gost89-cbc's in 3.01s Doing gost89-cbc for 3s on 16384 size blocks: 13338 gost89-cbc's in 3.00s 4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng error:/Users/ur20980/src/engine/gost_crypt.c:671: 4571538880:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl operation not implemented:crypto/evp/evp_enc.c:628: 4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng error:/Users/ur20980/src/engine/gost_crypt.c:671: 4571538880:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl operation not implemented:crypto/evp/evp_enc.c:628: 4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng error:/Users/ur20980/src/engine/gost_crypt.c:671: 4571538880:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl operation not implemented:crypto/evp/evp_enc.c:628: 4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng error:/Users/ur20980/src/engine/gost_crypt.c:671: 4571538880:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl operation not implemented:crypto/evp/evp_enc.c:628: 4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng error:/Users/ur20980/src/engine/gost_crypt.c:671: 4571538880:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl operation not implemented:crypto/evp/evp_enc.c:628: 4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng error:/Users/ur20980/src/engine/gost_crypt.c:671: 4571538880:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl operation not implemented:crypto/evp/evp_enc.c:628: $?openssl speed -engine gost -evp grasshopper-cfb engine "gost" set. Doing grasshopper-cfb for 3s on 16 size blocks: 19210088 grasshopper-cfb's in 3.00s Doing grasshopper-cfb for 3s on 64 size blocks: 5210373 grasshopper-cfb's in 3.00s Doing grasshopper-cfb for 3s on 256 size blocks: 1320249 grasshopper-cfb's in 3.00s Doing grasshopper-cfb for 3s on 1024 size blocks: 328343 grasshopper-cfb's in 3.00s Doing grasshopper-cfb for 3s on 8192 size blocks: 41459 grasshopper-cfb's in 3.00s Doing grasshopper-cfb for 3s on 16384 size blocks: 20488 grasshopper-cfb's in 3.00s 4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558: 4541392320:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl operation not implemented:crypto/evp/evp_enc.c:628: 4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558: 4541392320:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl operation not implemented:crypto/evp/evp_enc.c:628: 4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558: 4541392320:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl operation not implemented:crypto/evp/evp_enc.c:628: 4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558: 4541392320:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl operation not implemented:crypto/evp/evp_enc.c:628: 4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558: 4541392320:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl operation not implemented:crypto/evp/evp_enc.c:628: 4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558: 4541392320:error:0607C085:digital envelope routines:EVP_CIPHER_CTX_ctrl:ctrl operation not implemented:crypto/evp/evp_enc.c:628: $ ??, 19 ???? 2019 ?., 21:09 Blumenthal, Uri - 0553 - MITLL : MacOS Mojave 10.14.5, OpenSSL-1.1.1c (Macports-installed). Engines defined in the openssl.cnf file: ############# [engine_section] pkcs11 = pkcs11_section gost? ?= gost_section [pkcs11_section] engine_id = pkcs11 dynamic_path = /opt/local/lib/engines-1.1/libpkcs11.so MODULE_PATH? = /Library/OpenSC/lib/opensc-pkcs11.so init = 0 [gost_section] engine_id = gost dynamic_path = /opt/local/lib/engines-1.1/gost.dylib default_algorithms = ALL CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet init = 1 ############# Note, whether the above has "init = 1" or not, does not alter the outcome. Engine in question is "gost". First, the engine does not load automatically/dynamically. For "openssl dgst" I have to specify it explicitly, otherwise the algorithms it provides, are not available: $ openssl dgst -md_gost94 ~/LastTest.log dgst: Unrecognized flag md_gost94 dgst: Use -help for summary. $ openssl dgst -engine gost -md_gost94 ~/LastTest.log engine "gost" set. md_gost94(/Users/ur20980/LastTest.log)= e82e6e515c86851498eac606722b50b724b1f95952d4edb7202029f127751816 $ Second - even when I explicitly specify the engine, "openssl speed" refuses to recognize the ciphers provided by it, though "openssl enc" shows that it can access them: $ openssl speed -engine gost -evp gost89-cbc speed: gost89-cbc is an unknown cipher or digest $ openssl enc -engine gost -ciphers engine "gost" set. Supported ciphers: -aes-128-cbc? ? ? ? ? ? ? ?-aes-128-cfb? ? ? ? ? ? ? ?-aes-128-cfb1? ? ? ? ? ? ? -aes-128-cfb8? ? ? ? ? ? ? -aes-128-ctr? ? ? ? ? ? ? ?-aes-128-ecb? ? ? ? . . . . . -des3-wrap? ? ? ? ? ? ? ? ?-desx? ? ? ? ? ? ? ? ? ? ? -desx-cbc? ? ? ? ? ? ? ? ? -gost89? ? ? ? ? ? ? ? ? ? -gost89-cbc? ? ? ? ? ? ? ? -gost89-cnt? ? ? ? ? ? ? ? -gost89-cnt-12? ? ? ? ? ? ?-grasshopper-cbc? ? ? ? ? ?-grasshopper-cfb? ? ? ? ? -grasshopper-ctr? ? ? ? ? ?-grasshopper-ecb? ? ? ? ? ?-grasshopper-ofb? ? ? ? ? -id-aes128-wrap? ? ? ? ? ? -id-aes128-wrap-pad? ? ? ? -id-aes192-wrap Seems like a bug...? -- Regards, Uri -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: From beldmit at gmail.com Mon Jul 22 18:22:12 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 22 Jul 2019 21:22:12 +0300 Subject: Ciphers provided by engine not accessible...? In-Reply-To: References: <41BD7750-3570-471E-83D7-D0BA77D28FDC@ll.mit.edu> <9626169A-7C7C-4AB5-AA47-4801CE30D514@ll.mit.edu> Message-ID: Great! The CBC implementation was rather limited. If you have any specific requirements, fill free to fill a bug report in the engine repo. ??, 22 ???? 2019 ?., 21:16 Blumenthal, Uri - 0553 - MITLL : > Are there any other parts of the openssl.cnf that could be related to this > issue, or help diagnose it?s cause? > Does your configuration file contain a header similar to described in the > Gost engine documentation? If no, the gost section is not processed. > > I don't remember any significant changes in 1.1.1 engine processing, and > it works with 1.0.2 > > Sorry for brevity, I'll be able to look in more details only at the > beginning of August. > > Darn? You were right ? that header (openssl_conf = openssl_def) was NOT > present. Adding it resulted in success (with some error messages): > > $ openssl speed -engine gost -evp gost89-cbc > engine "gost" set. > Doing gost89-cbc for 3s on 16 size blocks: 13107440 gost89-cbc's in 2.99s > Doing gost89-cbc for 3s on 64 size blocks: 3383428 gost89-cbc's in 3.00s > Doing gost89-cbc for 3s on 256 size blocks: 849765 gost89-cbc's in 3.00s > Doing gost89-cbc for 3s on 1024 size blocks: 211166 gost89-cbc's in 3.00s > Doing gost89-cbc for 3s on 8192 size blocks: 26167 gost89-cbc's in 3.01s > Doing gost89-cbc for 3s on 16384 size blocks: 13338 gost89-cbc's in 3.00s > 4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng > error:/Users/ur20980/src/engine/gost_crypt.c:671: > 4571538880:error:0607C085:digital envelope > routines:EVP_CIPHER_CTX_ctrl:ctrl operation not > implemented:crypto/evp/evp_enc.c:628: > 4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng > error:/Users/ur20980/src/engine/gost_crypt.c:671: > 4571538880:error:0607C085:digital envelope > routines:EVP_CIPHER_CTX_ctrl:ctrl operation not > implemented:crypto/evp/evp_enc.c:628: > 4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng > error:/Users/ur20980/src/engine/gost_crypt.c:671: > 4571538880:error:0607C085:digital envelope > routines:EVP_CIPHER_CTX_ctrl:ctrl operation not > implemented:crypto/evp/evp_enc.c:628: > 4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng > error:/Users/ur20980/src/engine/gost_crypt.c:671: > 4571538880:error:0607C085:digital envelope > routines:EVP_CIPHER_CTX_ctrl:ctrl operation not > implemented:crypto/evp/evp_enc.c:628: > 4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng > error:/Users/ur20980/src/engine/gost_crypt.c:671: > 4571538880:error:0607C085:digital envelope > routines:EVP_CIPHER_CTX_ctrl:ctrl operation not > implemented:crypto/evp/evp_enc.c:628: > 4571538880:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng > error:/Users/ur20980/src/engine/gost_crypt.c:671: > 4571538880:error:0607C085:digital envelope > routines:EVP_CIPHER_CTX_ctrl:ctrl operation not > implemented:crypto/evp/evp_enc.c:628: > $ openssl speed -engine gost -evp grasshopper-cfb > engine "gost" set. > Doing grasshopper-cfb for 3s on 16 size blocks: 19210088 grasshopper-cfb's > in 3.00s > Doing grasshopper-cfb for 3s on 64 size blocks: 5210373 grasshopper-cfb's > in 3.00s > Doing grasshopper-cfb for 3s on 256 size blocks: 1320249 grasshopper-cfb's > in 3.00s > Doing grasshopper-cfb for 3s on 1024 size blocks: 328343 grasshopper-cfb's > in 3.00s > Doing grasshopper-cfb for 3s on 8192 size blocks: 41459 grasshopper-cfb's > in 3.00s > Doing grasshopper-cfb for 3s on 16384 size blocks: 20488 grasshopper-cfb's > in 3.00s > 4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng > error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558: > 4541392320:error:0607C085:digital envelope > routines:EVP_CIPHER_CTX_ctrl:ctrl operation not > implemented:crypto/evp/evp_enc.c:628: > 4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng > error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558: > 4541392320:error:0607C085:digital envelope > routines:EVP_CIPHER_CTX_ctrl:ctrl operation not > implemented:crypto/evp/evp_enc.c:628: > 4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng > error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558: > 4541392320:error:0607C085:digital envelope > routines:EVP_CIPHER_CTX_ctrl:ctrl operation not > implemented:crypto/evp/evp_enc.c:628: > 4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng > error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558: > 4541392320:error:0607C085:digital envelope > routines:EVP_CIPHER_CTX_ctrl:ctrl operation not > implemented:crypto/evp/evp_enc.c:628: > 4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng > error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558: > 4541392320:error:0607C085:digital envelope > routines:EVP_CIPHER_CTX_ctrl:ctrl operation not > implemented:crypto/evp/evp_enc.c:628: > 4541392320:error:8106A07A:lib(129):GOST_CIPHER_CTL:rng > error:/Users/ur20980/src/engine/gost_grasshopper_cipher.c:558: > 4541392320:error:0607C085:digital envelope > routines:EVP_CIPHER_CTX_ctrl:ctrl operation not > implemented:crypto/evp/evp_enc.c:628: > $ > > > > > ??, 19 ???? 2019 ?., 21:09 Blumenthal, Uri - 0553 - MITLL uri at ll.mit.edu>: > MacOS Mojave 10.14.5, OpenSSL-1.1.1c (Macports-installed). > > Engines defined in the openssl.cnf file: > > ############# > [engine_section] > pkcs11 = pkcs11_section > gost = gost_section > > [pkcs11_section] > engine_id = pkcs11 > dynamic_path = /opt/local/lib/engines-1.1/libpkcs11.so > MODULE_PATH = /Library/OpenSC/lib/opensc-pkcs11.so > init = 0 > > [gost_section] > engine_id = gost > dynamic_path = /opt/local/lib/engines-1.1/gost.dylib > default_algorithms = ALL > CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet > init = 1 > ############# > > Note, whether the above has "init = 1" or not, does not alter the outcome. > > Engine in question is "gost". > > First, the engine does not load automatically/dynamically. For "openssl > dgst" I have to specify it explicitly, otherwise the algorithms it > provides, are not available: > > $ openssl dgst -md_gost94 ~/LastTest.log > dgst: Unrecognized flag md_gost94 > dgst: Use -help for summary. > $ openssl dgst -engine gost -md_gost94 ~/LastTest.log > engine "gost" set. > md_gost94(/Users/ur20980/LastTest.log)= > e82e6e515c86851498eac606722b50b724b1f95952d4edb7202029f127751816 > $ > > Second - even when I explicitly specify the engine, "openssl speed" > refuses to recognize the ciphers provided by it, though "openssl enc" shows > that it can access them: > > $ openssl speed -engine gost -evp gost89-cbc > speed: gost89-cbc is an unknown cipher or digest > $ openssl enc -engine gost -ciphers > engine "gost" set. > Supported ciphers: > -aes-128-cbc -aes-128-cfb -aes-128-cfb1 > > -aes-128-cfb8 -aes-128-ctr -aes-128-ecb > . . . . . > -des3-wrap -desx -desx-cbc > > -gost89 -gost89-cbc -gost89-cnt > > -gost89-cnt-12 -grasshopper-cbc -grasshopper-cfb > > -grasshopper-ctr -grasshopper-ecb -grasshopper-ofb > > -id-aes128-wrap -id-aes128-wrap-pad -id-aes192-wrap > > > Seems like a bug...? > -- > Regards, > Uri > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrichter at solarflare.com Mon Jul 22 18:44:47 2019 From: mrichter at solarflare.com (Mark Richter) Date: Mon, 22 Jul 2019 18:44:47 +0000 Subject: How do I build an app with 1.1.1 that uses libraries built against 1.0.2? In-Reply-To: <20190722174627.GS84864@straasha.imrryr.org> References: <1563814233970.61046@solarflare.com>, <20190722174627.GS84864@straasha.imrryr.org> Message-ID: <1563821087501.39753@solarflare.com> nm says there are no symbols in libssl or libcrypto. It also says that libcurl has no symbols. Does that imply that all libcurl's symbols are already resolved? Mark Richter | Senior Staff Engineer SolarFlare Communications, Inc. | www.Solarflare.com 9444 Waples Street, #170, San Diego, CA 92121 Mobile: +1 949-632-8403 ________________________________________ From: openssl-users on behalf of Viktor Dukhovni Sent: Monday, July 22, 2019 10:46 AM To: openssl-users at openssl.org Subject: Re: How do I build an app with 1.1.1 that uses libraries built against 1.0.2? On Mon, Jul 22, 2019 at 04:50:46PM +0000, Mark Richter wrote: > We have a RHEL 7 app that links to (at least) libcurl that uses OpenSSL 1.0.2, but our app needs 1.1.1. > > I'm not at all sure how to set up our Makefile to handle this. The libcurl shared library will be looking for "libssl.so.1.0.0" and "libcrypto.so.1.0.0" with associated symbol versions, assuming the RHEL 7 OpenSSL libraries in /usr/lib employ symbol versioning. Under the above assumptions, once you have the "shlib_variant" OpenSSL built, you can just link: cc -o application application.o \ -L/opt/openssl1.1 -Wl,-rpath,/opt/openssl1.1/lib -lssl -lcrypto \ -lcurl \ ... With the OpenSSL libraries listed before libcurl, just in case your linker automatically searches nested dependencies first and ends up linking application.o against libcurl's choice of OpenSSL libraries. This works on Debian systems where base system's libssl and libcrypto have symbol versions. If, however, the system libssl and libcrypto lack symbol versions, (do they on RHEL 7?) then libcurl will not be explicitly bound to the base-system OpenSSL API, and depending on the order in which libraries are loaded may inadvertently end up with the 1.1.1 symbol bindings (and then fail). In that case it may be helpful to list libcurl first, hoping that it will be loaded first, and resolved against the system OpenSSL, with the variant OpenSSL for your application loaded second, assuming that the "dependents of dependents" issue is not a problem. But at the end of the day, that is probably too fragile, you might also load more libraries at runtime, and those could end up with the wrong symbols. So if your base system's libssl and libcrypto have no symbol versions, you just have to accept the fact that you're stuck with the system OpenSSL libraries for better or worse. -- Viktor. The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. From uri at ll.mit.edu Mon Jul 22 19:17:01 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 22 Jul 2019 19:17:01 +0000 Subject: Ciphers provided by engine not accessible...? In-Reply-To: <41BD7750-3570-471E-83D7-D0BA77D28FDC@ll.mit.edu> References: <41BD7750-3570-471E-83D7-D0BA77D28FDC@ll.mit.edu> Message-ID: Turned out the failure was my misconfiguration - but the "config" man page doesn't seem to describe the *exact* order of the statements/sections. What I found experimentally, was: 1. "openssl_conf = openssl_init" line must be the first non-comment line in the openssl.cnf file, otherwise engines won't be loaded. 2. "[openssl_init]\n engines = engine_section" lines must *both* be at the end of the openssl.cnf file, just before the "[engine_section]" section. These are the errors I get if the above order is violated: $ openssl engine -t gost pkcs11 rdrand (gost) Reference implementation of GOST engine [ available ] (pkcs11) pkcs11 engine [ available ] (rdrand) Intel RDRAND engine [ available ] 4566365632:error:25066067:DSO support routines:dlfcn_load:could not load the shared library:crypto/dso/dso_dlfcn.c:119:filename(libHOME.dylib): dlopen(libHOME.dylib, 2): image not found 4566365632:error:25070067:DSO support routines:DSO_load:could not load the shared library:crypto/dso/dso_lib.c:162: 4566365632:error:0E07506E:configuration file routines:module_load_dso:error loading dso:crypto/conf/conf_mod.c:224:module=HOME, path=HOME 4566365632:error:0E076071:configuration file routines:module_run:unknown module name:crypto/conf/conf_mod.c:165:module=HOME $ ll /opt/local/lib/engines-1.1/pkcs11.dylib -rwxr-xr-x 1 root admin 79952 Jun 12 09:37 /opt/local/lib/engines-1.1/pkcs11.dylib* $ /Library/OpenSC/lib/opensc-pkcs11.so -bash: /Library/OpenSC/lib/opensc-pkcs11.so: cannot execute binary file $ ll /Library/OpenSC/lib/opensc-pkcs11.so -rwxr-xr-x 1 root wheel 1666552 Jul 22 12:35 /Library/OpenSC/lib/opensc-pkcs11.so* $ Here's the *current* openssl.cnf (I removed the middle part that deals with the certificate parameters, as it seems irrelevant to this issue) - your comments are welcome: # Note that you can include other files from the main configuration # file using the .include directive. #.include filename openssl_conf = openssl_init # This definition stops the following lines choking if HOME isn't # defined. HOME = . # Extra OBJECT IDENTIFIER info: #oid_file = $ENV::HOME/.oid oid_section = new_oids # 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 ] . . . . . [openssl_init] engines = engine_section ################################# [engine_section] pkcs11 = pkcs11_section gost = gost_section [pkcs11_section] engine_id = pkcs11 dynamic_path = /opt/local/lib/engines-1.1/pkcs11.dylib MODULE_PATH = /Library/OpenSC/lib/opensc-pkcs11.so init = 0 [gost_section] engine_id = gost dynamic_path = /opt/local/lib/engines-1.1/gost.dylib default_algorithms = ALL CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet ################################# ?On 7/19/19, 2:10 PM, "openssl-users on behalf of Blumenthal, Uri - 0553 - MITLL" wrote: MacOS Mojave 10.14.5, OpenSSL-1.1.1c (Macports-installed). Engines defined in the openssl.cnf file: ############# [engine_section] pkcs11 = pkcs11_section gost = gost_section [pkcs11_section] engine_id = pkcs11 dynamic_path = /opt/local/lib/engines-1.1/libpkcs11.so MODULE_PATH = /Library/OpenSC/lib/opensc-pkcs11.so init = 0 [gost_section] engine_id = gost dynamic_path = /opt/local/lib/engines-1.1/gost.dylib default_algorithms = ALL CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet init = 1 ############# Note, whether the above has "init = 1" or not, does not alter the outcome. Engine in question is "gost". First, the engine does not load automatically/dynamically. For "openssl dgst" I have to specify it explicitly, otherwise the algorithms it provides, are not available: $ openssl dgst -md_gost94 ~/LastTest.log dgst: Unrecognized flag md_gost94 dgst: Use -help for summary. $ openssl dgst -engine gost -md_gost94 ~/LastTest.log engine "gost" set. md_gost94(/Users/ur20980/LastTest.log)= e82e6e515c86851498eac606722b50b724b1f95952d4edb7202029f127751816 $ Second - even when I explicitly specify the engine, "openssl speed" refuses to recognize the ciphers provided by it, though "openssl enc" shows that it can access them: $ openssl speed -engine gost -evp gost89-cbc speed: gost89-cbc is an unknown cipher or digest $ openssl enc -engine gost -ciphers engine "gost" set. Supported ciphers: -aes-128-cbc -aes-128-cfb -aes-128-cfb1 -aes-128-cfb8 -aes-128-ctr -aes-128-ecb . . . . . -des3-wrap -desx -desx-cbc -gost89 -gost89-cbc -gost89-cnt -gost89-cnt-12 -grasshopper-cbc -grasshopper-cfb -grasshopper-ctr -grasshopper-ecb -grasshopper-ofb -id-aes128-wrap -id-aes128-wrap-pad -id-aes192-wrap Seems like a bug...? -- Regards, Uri -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: From openssl-users at dukhovni.org Mon Jul 22 19:28:59 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 22 Jul 2019 15:28:59 -0400 Subject: How do I build an app with 1.1.1 that uses libraries built against 1.0.2? In-Reply-To: <1563821087501.39753@solarflare.com> References: <1563814233970.61046@solarflare.com> <20190722174627.GS84864@straasha.imrryr.org> <1563821087501.39753@solarflare.com> Message-ID: <5388D858-C4E0-4CE5-BD43-29F2308EB037@dukhovni.org> > On Jul 22, 2019, at 2:44 PM, Mark Richter wrote: > > nm says there are no symbols in libssl or libcrypto. > > It also says that libcurl has no symbols. Does that imply that all libcurl's symbols are already resolved? On stripped libraries you may need to use "objdump -T" rather than nm. -- Viktor. From levitte at openssl.org Mon Jul 22 19:38:11 2019 From: levitte at openssl.org (Richard Levitte) Date: Mon, 22 Jul 2019 21:38:11 +0200 Subject: Ciphers provided by engine not accessible...? In-Reply-To: References: <41BD7750-3570-471E-83D7-D0BA77D28FDC@ll.mit.edu> Message-ID: <87wog9vp0c.wl-levitte@openssl.org> On Mon, 22 Jul 2019 21:17:01 +0200, Blumenthal, Uri - 0553 - MITLL wrote: > > Turned out the failure was my misconfiguration - but the "config" > man page doesn't seem to describe the *exact* order of the > statements/sections. It does, but perhaps not in a way you expected. Here's a paragraph from config(5), about the so called default section: The first section of a configuration file is special and is referred to as the default section. This section is usually unnamed and spans from the start of file until the first named section. When a name is being looked up it is first looked up in a named section (if any) and then the default section. "start of the file until the first section" is key. This is found fairly early in the description. And then, early in "OPENSSL_LIBRARY CONFIGURATION": To enable library configuration the default section needs to contain an appropriate line which points to the main configuration section. The default name is openssl_conf which is used by the openssl utility. Other applications may use an alternative name such as myapplication_conf. All library configuration lines appear in the default section at the start of the configuration file. "the default section" is key. So the "openssl_conf = openssl_init" line must be early in the config file. The order of the different named sections doesn't (or shouldn't) really matter. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From uri at ll.mit.edu Mon Jul 22 19:49:20 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 22 Jul 2019 19:49:20 +0000 Subject: Ciphers provided by engine not accessible...? In-Reply-To: <87wog9vp0c.wl-levitte@openssl.org> References: <41BD7750-3570-471E-83D7-D0BA77D28FDC@ll.mit.edu> <87wog9vp0c.wl-levitte@openssl.org> Message-ID: <14011D5B-A310-41BE-8778-215237585429@ll.mit.edu> On 7/22/19, 3:38 PM, "Richard Levitte" wrote: > > Turned out the failure was my misconfiguration - but the "config" > > man page doesn't seem to describe the *exact* order of the > > statements/sections. > > It does, but perhaps not in a way you expected. :-) > So the "openssl_conf = openssl_init" line must be early in the config > file. Yep, as proven by my experience. > The order of the different named sections doesn't (or > shouldn't) really matter. I agree with the "shouldn't", but in my experience it did. I had to move [openssl_init] engines = engine_section to just above the [engine_section] itself - placing it in *any* other location in the file, including just after the "openssl_conf = " line, caused problems. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: From AThorath at corsec.com Mon Jul 22 19:51:07 2019 From: AThorath at corsec.com (Amritha Thorath) Date: Mon, 22 Jul 2019 19:51:07 +0000 Subject: help Message-ID: <8e49407be9614cf4b45445eb0a8e6b40@MBX082-E4-VA-3.EXCH082.serverpod.net> help Thanks, [cid:image005.png at 01D01EBC.D4993640] Amritha Thorath Cryptographic Software Developer O: 703-267-6050 x 119 E: athorath at corsec.com Website | Blog | Facebook | Twitter | LinkedIn Opening Markets Through Security Certifications -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5110 bytes Desc: image001.png URL: From chris.fahlin at tee2.org Mon Jul 22 21:08:22 2019 From: chris.fahlin at tee2.org (chrisfahlin) Date: Mon, 22 Jul 2019 14:08:22 -0700 (MST) Subject: help - building OpenSSL fips for 64 bit Android Message-ID: <1563829702416-0.post@n7.nabble.com> I am trying to build openssl-1.0.2s with the fips module openssl-fips-ecp-2.0.16 to support 64 bit android devices, I have tried following the steps on the wiki and noticed that the setenv-android.sh script doesn't account for 64 bit architectures. I have tried finding an updated version of the script online but none of them seem to be working. I also tried using a script found on GitHub that combines the building of the fips module and openssl, I seem to be having issues with this as well. Any pointers in building a fips compliant openssl for 64 bit android would be appreciated -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From chris.fahlin at tee2.org Mon Jul 22 21:11:38 2019 From: chris.fahlin at tee2.org (chrisfahlin) Date: Mon, 22 Jul 2019 14:11:38 -0700 (MST) Subject: help - building OpenSSL fips for 64 bit Android In-Reply-To: <1563829702416-0.post@n7.nabble.com> References: <1563829702416-0.post@n7.nabble.com> Message-ID: <1563829898728-0.post@n7.nabble.com> Forgot to mention I am trying to cross compile on a MacBook Pro (15-inch, 2017) running MacOS 10.14.5 -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From rsalz at akamai.com Mon Jul 22 21:24:33 2019 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 22 Jul 2019 21:24:33 +0000 Subject: help - building OpenSSL fips for 64 bit Android In-Reply-To: <1563829702416-0.post@n7.nabble.com> References: <1563829702416-0.post@n7.nabble.com> Message-ID: <658FC6F2-288E-4570-B49D-E92C2E5CDF4A@akamai.com> > that the setenv-android.sh script doesn't account for 64 bit architectures. Correct. The current FIPS module has not been modified for quite some time, and your platform is not supported. If you cannot follow the steps *exactly* you cannot claim FIPS validation. The OpenSSL project is working on a new FIPS validation for the next release, but it will only support a few platforms (those of the sponsors funding the work, mainly). Whichever release you use, you will have to hire a lab to get your own validation, or hope that a vendor provides one. From matt at openssl.org Tue Jul 23 08:28:09 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 23 Jul 2019 09:28:09 +0100 Subject: Engine updating a key's ex data in sign/encrypt method? In-Reply-To: <04b04d9c58af4c21aa6d339a330ce408@atos.net> References: <04b04d9c58af4c21aa6d339a330ce408@atos.net> Message-ID: On 22/07/2019 17:44, Lynch, Andrew wrote: > Hi, > > I am wondering whether it is ok to update a key's ex data from within an engine method that is using the key. This is with both OpenSSL 1.1.1a and 1.0.2j. > > In my engine's load_privkey() method I connect to the HSM and obtain handles for a session and the key object. Both handles are then stored in the key's ex data using RSA_set_ex_data() or EC_KEY_set_ex_data(). They will later be released by the registered free_func. The sign and/or encrypt methods use these handles when making their calls to the HSM API. > > This works fine for single operations like an openssl x509 command line, but not for long running applications such as stunnel. It appears that stunnel loads all configured keys and certs at startup and then waits for clients to connect. If there is no activity for a while the HSM will time out my session handle and the next sign operation using that session fails. I can catch the error and reconnect, but this results in a new session handle. The next time a client calls the same service, that key's ex data still contains the old outdated session handle resulting in the same error all over again. > > So whenever I renew a session handle in the sign method I need to update the ex data of the affected key with the new value. > > This appears to work fine for EC keys by calling EC_KEY_set_ex_data() from within the engine's ecdsa_do_sign() method. The same goes for RSA keys in rsa_private_decrypt() and rsa_private_encrypt(), but with rsa_sign() I have a problem in that the key parameter is const RSA *. > > Is the lack of const in rsa_private_encrypt() and ecdsa_do_sign() an oversight and I should not be manipulating ex data of the provided key in this way? > Or is the const in rsa_sign() too strict and it is actually ok to modify the ex data of the key? I can't see a problem with modifying the ex_data like that. Matt From kevin.lengauer at adnovum.ch Tue Jul 23 09:02:30 2019 From: kevin.lengauer at adnovum.ch (K Lengauer) Date: Tue, 23 Jul 2019 02:02:30 -0700 (MST) Subject: Openssl binary with statically linked libssl and libcrypto Message-ID: <1563872550512-0.post@n7.nabble.com> Hi all, I am trying to build the 'openssl' binary with libssl and libcrypto linked statically because the end product may be used on a system where they are not available. I recently upgraded to OpenSSL v1.1.1c and previously used 1.0.2s which allowed me to get the 'openssl' binary with statically linked libssl and libcrypto. I went through several questions and boards already and tried different things: 1) Using "no-shared" and "-static" for that matter with ./config is not an option as I still require the libcrypto.so and libssl.so for some other tests that are part of the whole component to which OpenSSL belongs in my use-case. 2) My "solution" so far is to change the "build.info" in /openssl/apps in the following way: source: DEPEND[openssl]=libapps.a ../libssl changed to: DEPEND[openssl]=libapps.a ../libssl.a ../libcrypto.a This way I am able to build both the openssl binary with statically linked libraries as well as keep building the shared libraries. However, here comes the catch. In doing so I break several of the OpenSSL unit tests (notably all 70-* recipe tests such as 70-test_comp.t, etc.) and they encounter a segmentation fault. I could provide a backtrace of the core for such a segfault. If I dont link the libraries statically and instead use the config to point it to the built .so files the tests run just fine. Is there a (better) way to achieve my goal to build the 'openssl' binary with statically linked libcrypto and libssl? I read in a recent question that statically linking is not recommended but still ask you kindly for any advice you can give me on this matter. I am sorry for this lengthy question but I tried to offer some insight in my thought process so far. Furhter, I apologize if my error is obvious as I am still learning the topics related to OpenSSL and especially the changes that occured since OpenSSL v1.1.0. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From janjust at nikhef.nl Tue Jul 23 15:26:55 2019 From: janjust at nikhef.nl (Jan Just Keijser) Date: Tue, 23 Jul 2019 17:26:55 +0200 Subject: Error building app on RHEL 7 with openssl 1.1.1 In-Reply-To: <9cbf7009847e4266b0ed9e20ea9fc950@ocex03.SolarFlarecom.com> References: <0a10629ce275405eb0ff24cb6f9f25f0@ocex03.SolarFlarecom.com> <9cbf7009847e4266b0ed9e20ea9fc950@ocex03.SolarFlarecom.com> Message-ID: <34b85e1d-effe-22fd-fe77-de57c450b885@nikhef.nl> Hi Mark, On 20/07/19 00:13, Mark Richter wrote: > I figured out the variant issue and built, but the tests are failing - see https://gist.github.com/sf-mrichter/2c5c653b3800708c1a67ba41e4992129. > > Still not sure how to link an app to the new ssl that uses libraries that were built with the default. this is not an OpenSSL, but a Curl issue; I just downloaded curl 7.53.6? (the latest) and tried compiling and linking it against OpenSSL 1.1.1 ; that took quite some effort, as the curl 'configure' script incorrectly detects the availability of RAND_egd *and* it assumes that the libraries are always present in a library /lib However, after fixing those errors , I was able to compile & link libcurl and curl against OpenSSL 1.1.1 and I was able to verify that that curl-build can now do TLS 1.3 Also, note that the default built of curl on RHEL/CentOS 7 uses nss, not openssl. You can contact me for further details. HTH, JJK PS as for the libcurl symbols: as Viktor said, use? 'objdump T libcurl.so.4' > -----Original Message----- > From: openssl-users On Behalf Of Mark Richter > Sent: Friday, July 19, 2019 11:04 AM > To: openssl-users at openssl.org > Subject: RE: Error building app on RHEL 7 with openssl 1.1.1 > > I've been poking around in the Configurations/* and all the README* files, and on the web, and it is not at all clear to me how/where to specify the inherit_from and shlib_variant options (probably not the right term, but...) or how the resulting libraries are distinguished from the system defaults from the app Makefile and resulting application's point of view, particularly w.r.t. how our app can use 1.1.1 while libraries we also link will use the system default (1.0.2). > > Do I copy an existing .conf file to a new name and edit that? If so, what am I editing from/to? What's the best way to choose the name for the new file? > > How do I get config (or Configure) to use the new conf file, or is that automatic? If it is automatic, how does that work for "my" platform? > > Assuming I use both, do I need to change my source to make use of the new libraries or just my Makefile (and how)? > > Our app links to both crypto/ssl and other shared libraries that use the system default. How do I tell my Makefile which one to use for both our app and the other libraries which need to use the system default openssl crypto/ssl libs? Do I tack the variant at the front or back end of the -L/-l spec lines? What about our -I specs (I guess that a -I for the custom 1.1.1 build is all our app needs since we don't care what the other libraries use for compiling)? > > As I mentioned, this is all quite new to me. > > My apologies if this is as painful for you as it has been for me. > > Many, many thanks in advance. I deeply appreciate all your assistance. > > Mark > > -----Original Message----- > From: openssl-users On Behalf Of Viktor Dukhovni > Sent: Thursday, July 18, 2019 10:19 PM > To: openssl-users at openssl.org > Subject: Re: Error building app on RHEL 7 with openssl 1.1.1 > >> On Jul 18, 2019, at 4:34 PM, Mark Richter wrote: >> >> cc -DLOG_LEVEL=LOG_INFO -Wall -Werror -D__ci_driver__ -D__ci_ul_driver__ -D_GNU_SOURCE -DWITH_MCDI_V2 -DWITH_TLS12=0 -DSOLAR_SECURE_VERSION="1.0.3.1020 (3bf2875895d5+ Thu Jul 18 13:27:17 PDT 2019)" -Isrc/include -I/opt/openssl1.1/include -Isrc/tools/mc-comms -Isrc/tools/mc-comms/include -Isrc/emulators/mbedtls/include -I/usr/include/json-c -g3 -fno-omit-frame-pointer -Isrc/cntlr build/src/cntlr/cntlr.o -o build/bin/cntlr -Lbuild/lib -L/opt/openssl1.1/lib -Wl,-rpath,/opt/openssl1.1/lib -lsf_core -lcm -lss -lcrypto -lpci -lcurl -lpthread -lrt -lssl -luuid -ljson-c >> /usr/bin/ld: /opt/openssl1.1/lib/libcrypto.a(dso_dlfcn.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5' >> /usr/lib64/libdl.so.2: error adding symbols: DSO missing from command >> line >> collect2: error: ld returned 1 exit status >> make: *** [build/bin/cntlr] Error 1 > While dlopen issue can be resolved by including "-ldl" in your linker options. > > If you have not managed to get "shlib_variant" working, the above can't possibly work because the libcurl you're linking with likely expects the OpenSSL 1.0.2 ABI. If the same symbols are found in your the 1.1.1 library in /opt, libcurl will likely crash. > > If however, the /opt/openssl1.1/lib/lib{ssl,crypto} have the shlib_variant SONAMEs and symbol variants, it should work. In that case libcurl will find its symbols in something like: > > /usr/lib/libssl.1.0.so > > While your application can directly use the OpenSSL 1.1.1 API. > If your use of OpenSSL is entirely via libcurl, then the custom OpenSSL will do you no good, unless you also built a custom libcurl linked against the custom OpenSSL. > > Perhaps you're looking for "Nix", or similar where multiple versions of dependents and dependencies co?xist more broadly on the same system (though still likely not multiple versions of the same library in the same address spaces as with the shlib_variant approach), but that's really not RHEL anymore. > > -- > Viktor. > > The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. > The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. From abaci.mjm at gmail.com Tue Jul 23 19:50:22 2019 From: abaci.mjm at gmail.com (Michael Mueller) Date: Tue, 23 Jul 2019 15:50:22 -0400 Subject: Openssl binary with statically linked libssl and libcrypto In-Reply-To: <1563872550512-0.post@n7.nabble.com> References: <1563872550512-0.post@n7.nabble.com> Message-ID: We are doing this for Linux. See below. Don't recall changing anything related to static build in transition from 1.0.2 to 1.1.1. For Windows we use the dlls. Noticed that new windows compile creates static libs, so we might convert to using the static libs. dev at turmeric:/NAS/dev/projectx/OPENSSL/bin/SUSE-Linux> ldd openssl linux-vdso.so.1 (0x00007ffe023e4000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f551e24e000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f551e031000) libc.so.6 => /lib64/libc.so.6 (0x00007f551dc8a000) /lib64/ld-linux-x86-64.so.2 (0x00007f551e452000) dev at turmeric:/NAS/dev/projectx/OPENSSL/bin/SUSE-Linux> ./openssl version OpenSSL 1.1.1c 28 May 2019 On Tue, Jul 23, 2019, 5:02 AM K Lengauer wrote: > Hi all, > > I am trying to build the 'openssl' binary with libssl and libcrypto linked > statically because the end product may be used on a system where they are > not available. I recently upgraded to OpenSSL v1.1.1c and previously used > 1.0.2s which allowed me to get the 'openssl' binary with statically linked > libssl and libcrypto. > > I went through several questions and boards already and tried different > things: > 1) Using "no-shared" and "-static" for that matter with ./config is not an > option as I still require the libcrypto.so and libssl.so for some other > tests that are part of the whole component to which OpenSSL belongs in my > use-case. > 2) My "solution" so far is to change the "build.info" in /openssl/apps in > the following way: > > source: DEPEND[openssl]=libapps.a ../libssl > changed to: DEPEND[openssl]=libapps.a ../libssl.a ../libcrypto.a > > This way I am able to build both the openssl binary with statically linked > libraries as well as keep building the shared libraries. > > However, here comes the catch. In doing so I break several of the OpenSSL > unit tests (notably all 70-* recipe tests such as 70-test_comp.t, etc.) and > they encounter a segmentation fault. I could provide a backtrace of the > core > for such a segfault. > If I dont link the libraries statically and instead use the config to point > it to the built .so files the tests run just fine. > > Is there a (better) way to achieve my goal to build the 'openssl' binary > with statically linked libcrypto and libssl? I read in a recent question > that statically linking is not recommended but still ask you kindly for any > advice you can give me on this matter. > > I am sorry for this lengthy question but I tried to offer some insight in > my > thought process so far. Furhter, I apologize if my error is obvious as I am > still learning the topics related to OpenSSL and especially the changes > that > occured since OpenSSL v1.1.0. > > > > > > > -- > Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Tue Jul 23 22:36:17 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 23 Jul 2019 22:36:17 +0000 Subject: Apps hang when openssl.cnf defines PKCS#11 engine Message-ID: <299A561C-7533-4042-BE6E-836B21231319@ll.mit.edu> It is weird. MacOS 10.14.6, Xcode-10.3, OpenSSL-1.1.1c (Macports-installed), current master of libp11. Symptoms: when PKCS#11 engine is defined, git hangs upon HTTPS retrieval. If I comment the engine out in openssl.cnf, or tell git to not load openssl.cnf - it works fine: $ openssl version -d OPENSSLDIR: "/opt/local/etc/openssl" $ openssl version OpenSSL 1.1.1c 28 May 2019 $ openssl engine -t pkcs11 (pkcs11) pkcs11 engine [ available ] $ echo $OPENSSL_CONF /opt/local/etc/openssl/openssl.cnf $ git pull ^C [hangs until killed] $ OPENSSL_CONF=/dev/null git pull Already up to date. $ git pull ^C [hangs until killed] $ Here's the openssl.cnf file with the middle cut off (to save space and make reading easier): # OpenSSL example configuration file. # This is mostly being used for generation of certificate requests. # # Note that you can include other files from the main configuration # file using the .include directive. #.include filename openssl_conf = openssl_init # This definition stops the following lines choking if HOME isn't # defined. HOME = . # Extra OBJECT IDENTIFIER info: #oid_file = $ENV::HOME/.oid oid_section = new_oids . . . . . [openssl_init] engines = engine_section [engine_section] pkcs11 = pkcs11_section gost = gost_section [pkcs11_section] engine_id = pkcs11 dynamic_path = /opt/local/lib/engines-1.1/libpkcs11.so MODULE_PATH = /Library/OpenSC/lib/opensc-pkcs11.so init = 0 [gost_section] engine_id = gost dynamic_path = /opt/local/lib/engines-1.1/gost.dylib default_algorithms = ALL CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet PBE_PARAMS = "gost12_512" Note: commenting out "gost" engine had no effect. Commenting out "pkcs11" engine completely resolved this problem, but caused a different problem with an app that uses OpenSSL and libp11 to access smartcards. Here's the hanging process snap, in case it can help figuring what's wrong: Sampling process 31833 for 3 seconds with 1 millisecond of run time between samples Sampling completed, processing symbols... Analysis of sampling git-remote-https (pid 31833) every 1 millisecond Process: git-remote-https [31833] Path: /opt/local/libexec/*/git-remote-https Load Address: 0x103bb3000 Identifier: git-remote-https Version: 0 Code Type: X86-64 Parent Process: git [31832] Date/Time: 2019-07-23 18:28:11.777 -0400 Launch Time: 2019-07-23 18:27:35.376 -0400 OS Version: Mac OS X 10.14.6 (18G84) Report Version: 7 Analysis Tool: /usr/bin/sample Physical footprint: 1640K Physical footprint (peak): 1648K ---- Call graph: 2889 Thread_367826 DispatchQueue_1: com.apple.main-thread (serial) 2889 start (in libdyld.dylib) + 1 [0x7fff707a53d5] 2889 main (in git-remote-https) + 131 [0x103bbd983] 2889 cmd_main (in git-remote-https) + 2241 [0x103bb4bc1] 2889 discover_refs (in git-remote-https) + 762 [0x103bb635a] 2889 http_request_reauth (in git-remote-https) + 34 [0x103bb9dd2] 2889 http_request (in git-remote-https) + 1225 [0x103bbc109] 2889 run_one_slot (in git-remote-https) + 147 [0x103bb9c33] 2889 run_active_slot (in git-remote-https) + 69 [0x103bb9875] 2889 step_active_slots (in git-remote-https) + 31 [0x103bb977f] 2889 curl_multi_perform (in libcurl.4.dylib) + 133 [0x103dbcfb1] 2889 multi_runsingle (in libcurl.4.dylib) + 889 [0x103dbd430] 2889 Curl_http_connect (in libcurl.4.dylib) + 365 [0x103da2742] 2889 https_connecting (in libcurl.4.dylib) + 23 [0x103da2793] 2889 Curl_ssl_connect_nonblocking (in libcurl.4.dylib) + 105 [0x103de24f0] 2889 ossl_connect_common (in libcurl.4.dylib) + 1829 [0x103dddfbe] 2874 Curl_ossl_seed (in libcurl.4.dylib) + 174 [0x103ddd75b] + 2873 Curl_wait_ms (in libcurl.4.dylib) + 98 [0x103dc0c87] + ! 2873 __select (in libsystem_kernel.dylib) + 10 [0x7fff708e161a] + 1 Curl_wait_ms (in libcurl.4.dylib) + 36 [0x103dc0c49] + 1 Curl_now (in libcurl.4.dylib) + 23 [0x103d9b90f] + 1 clock_gettime (in libsystem_c.dylib) + 184 [0x7fff707f01b2] + 1 _mach_boottime_usec (in libsystem_c.dylib) + 51 [0x7fff707f00cf] + 1 gettimeofday (in libsystem_c.dylib) + 45 [0x7fff707fedcd] + 1 __commpage_gettimeofday_internal (in libsystem_kernel.dylib) + 36 [0x7fff708db23c] + 1 mach_absolute_time (in libsystem_kernel.dylib) + 26 [0x7fff708dac23] 10 Curl_ossl_seed (in libcurl.4.dylib) + 186,326 [0x103ddd767,0x103ddd7f3] 3 Curl_ossl_seed (in libcurl.4.dylib) + 215 [0x103ddd784] + 3 Curl_now (in libcurl.4.dylib) + 23 [0x103d9b90f] + 3 clock_gettime (in libsystem_c.dylib) + 184 [0x7fff707f01b2] + 2 _mach_boottime_usec (in libsystem_c.dylib) + 22 [0x7fff707f00b2] + ! 2 mach_boottime_usec (in libsystem_kernel.dylib) + 0 [0x7fff708f27c8] + 1 DYLD-STUB$$mach_boottime_usec (in libsystem_c.dylib) + 0 [0x7fff7086f59a] 1 Curl_ossl_seed (in libcurl.4.dylib) + 253 [0x103ddd7aa] + 1 Curl_now (in libcurl.4.dylib) + 23 [0x103d9b90f] + 1 clock_gettime (in libsystem_c.dylib) + 184 [0x7fff707f01b2] + 1 DYLD-STUB$$mach_boottime_usec (in libsystem_c.dylib) + 0 [0x7fff7086f59a] 1 Curl_ossl_seed (in libcurl.4.dylib) + 339 [0x103ddd800] 1 RAND_add (in libcrypto.1.1.dylib) + 27 [0x10417e40f] 1 RAND_get_rand_method (in libcrypto.1.1.dylib) + 54 [0x10417e223] 1 CRYPTO_THREAD_write_lock (in libcrypto.1.1.dylib) + 9 [0x1041a9614] 1 pthread_rwlock_wrlock (in libsystem_pthread.dylib) + 0 [0x7fff70998e02] Total number in stack (recursive counted multiple, when >=5): Sort by top of stack, same collapsed (when >= 5): __select (in libsystem_kernel.dylib) 2873 Curl_ossl_seed (in libcurl.4.dylib) 10 Binary Images: 0x103bb3000 - 0x103d20ff7 +git-remote-https (0) <8A09FC94-FA6E-33E1-9805-A3ABD1D9A327> /opt/local/libexec/*/git-remote-https 0x103d98000 - 0x103dedff7 +libcurl.4.dylib (0) <55E295D3-2B43-3206-8B4C-A19C2E9C6173> /opt/local/lib/libcurl.4.dylib 0x103e00000 - 0x103e19ff3 +libexpat.1.dylib (0) /opt/local/lib/libexpat.1.dylib 0x103e21000 - 0x103e9aff7 +libpcre2-8.0.dylib (0) /opt/local/lib/libpcre2-8.0.dylib 0x103ea5000 - 0x103eb5ffb +libz.1.dylib (0) <36B1ED83-DE21-3D70-875B-55C2E2DA1D8E> /opt/local/lib/libz.1.dylib 0x103ebf000 - 0x103fb3ff3 +libiconv.2.dylib (0) <4C522CA5-5A0C-3028-96B5-824E03D7ABE7> /opt/local/lib/libiconv.2.dylib 0x103fc4000 - 0x103fccff7 +libintl.8.dylib (0) <9FE2A5C0-399B-3E88-A1B0-45932549E276> /opt/local/lib/libintl.8.dylib 0x103fd5000 - 0x103ff1ffb +libidn2.0.dylib (0) <59C3B8F6-155F-39BE-9E95-01AAA0268023> /opt/local/lib/libidn2.0.dylib 0x103ff5000 - 0x104004ffb +libpsl.5.dylib (0) /opt/local/lib/libpsl.5.dylib 0x104008000 - 0x104057ffb +libssl.1.1.dylib (0) <9DB54188-D6FE-3C25-8680-2B6A00A4C3F3> /opt/local/lib/libssl.1.1.dylib 0x104085000 - 0x10421485f +libcrypto.1.1.dylib (0) /opt/local/lib/libcrypto.1.1.dylib 0x1042ab000 - 0x10440fff7 +libunistring.2.dylib (0) <44BE87F3-0068-3DC8-B886-178B748F1944> /opt/local/lib/libunistring.2.dylib 0x104452000 - 0x10445eff3 +libpkcs11.so (0) <750BDB96-43CE-3BD1-8CC2-2F3822D8C9D2> /opt/local/lib/*/libpkcs11.so 0x104466000 - 0x1044aeff3 +gost.dylib (0) <7DECD3AE-F748-35B4-9679-4AE7D7192A7C> /opt/local/lib/*/gost.dylib 0x108743000 - 0x1087ad6ef dyld (655.1.1) /usr/lib/dyld 0x7fff40bf8000 - 0x7fff40bf8fff com.apple.Accelerate (1.11 - Accelerate 1.11) <762942CB-CFC9-3A0C-9645-A56523A06426> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 0x7fff40c10000 - 0x7fff412a9fef com.apple.vImage (8.1 - ???) <53FA3611-894E-3158-A654-FBD2F70998FE> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage 0x7fff412aa000 - 0x7fff41523ff3 libBLAS.dylib (1243.200.4) <417CA0FC-B6CB-3FB3-ACBC-8914E3F62D20> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 0x7fff41524000 - 0x7fff41596ffb libBNNS.dylib (38.250.1) <538D12A2-9B9D-3E22-9896-F90F6E69C06E> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib 0x7fff41597000 - 0x7fff41940ff3 libLAPACK.dylib (1243.200.4) <92175DF4-863A-3780-909A-A3E5C410F2E9> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib 0x7fff41941000 - 0x7fff41956feb libLinearAlgebra.dylib (1243.200.4) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib 0x7fff41957000 - 0x7fff4195cff3 libQuadrature.dylib (3.200.2) <1BAE7E22-2862-379F-B334-A3756067730F> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libQuadrature.dylib 0x7fff4195d000 - 0x7fff419d9ff3 libSparse.dylib (79.200.5) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparse.dylib 0x7fff419da000 - 0x7fff419edfe3 libSparseBLAS.dylib (1243.200.4) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparseBLAS.dylib 0x7fff419ee000 - 0x7fff41bd5ff7 libvDSP.dylib (671.250.4) <7B110627-A9C1-3FB7-A077-0C7741BA25D8> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib 0x7fff41bd6000 - 0x7fff41c89ff7 libvMisc.dylib (671.250.4) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib 0x7fff41c8a000 - 0x7fff41c8afff com.apple.Accelerate.vecLib (3.11 - vecLib 3.11) <74288115-EF61-30B6-843F-0593B31D4929> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib 0x7fff42c33000 - 0x7fff42c33fff com.apple.ApplicationServices (50.1 - 50.1) <84097DEB-E2FC-3901-8DD7-A670EA2274E0> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices 0x7fff42c34000 - 0x7fff42c9ffff com.apple.ApplicationServices.ATS (377 - 453.11.2.2) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS 0x7fff42d38000 - 0x7fff42e4ffff libFontParser.dylib (228.6.2.3) <3602D55B-3B9E-3B3A-A814-08C1244A8AE4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib 0x7fff42e50000 - 0x7fff42e92fff libFontRegistry.dylib (228.12.2.3) <2A56347B-2809-3407-A8B4-2AB88E484062> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib 0x7fff42f83000 - 0x7fff42f87ff3 com.apple.ColorSyncLegacy (4.13.0 - 1) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSyncLegacy.framework/Versions/A/ColorSyncLegacy 0x7fff43022000 - 0x7fff43074ff7 com.apple.HIServices (1.22 - 628) <2BE461FF-80B9-30D3-A574-AED5724B1C1B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x7fff43075000 - 0x7fff43084fff com.apple.LangAnalysis (1.7.0 - 1.7.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis 0x7fff43085000 - 0x7fff430ceff7 com.apple.print.framework.PrintCore (14.2 - 503.8) <57C2FE32-0E74-3079-B626-C2D52F2D2717> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x7fff430cf000 - 0x7fff43108ff7 com.apple.QD (3.12 - 407.2) <28C7D39F-59C9-3314-BECC-67045487229C> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD 0x7fff43109000 - 0x7fff43115fff com.apple.speech.synthesis.framework (8.1.3 - 8.1.3) <5E7B9BD4-122B-3012-A044-3259C97E7509> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x7fff43116000 - 0x7fff4338dff7 com.apple.audio.toolbox.AudioToolbox (1.14 - 1.14) <04F482F1-E1C1-3955-8A6C-8AA152AA06F3> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 0x7fff436e8000 - 0x7fff43a89fff com.apple.CFNetwork (978.0.7 - 978.0.7) /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 0x7fff43fae000 - 0x7fff440fdff7 com.apple.ColorSync (4.13.0 - 3345.6) <31648BB6-7239-3D0E-81B1-BCF51FEF557F> /System/Library/Frameworks/ColorSync.framework/Versions/A/ColorSync 0x7fff44289000 - 0x7fff4430ffff com.apple.audio.CoreAudio (4.3.0 - 4.3.0) <1E8E64E6-0E58-375A-97F7-07CB4EE181AC> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 0x7fff4439e000 - 0x7fff44723fef com.apple.CoreData (120 - 866.6) <132CB39B-8D58-30FA-B8AD-49BFFF34B293> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData 0x7fff44724000 - 0x7fff44814ff7 com.apple.CoreDisplay (101.3 - 110.18) <0EB2A997-FCAD-3D17-B140-9829961E5327> /System/Library/Frameworks/CoreDisplay.framework/Versions/A/CoreDisplay 0x7fff44815000 - 0x7fff44c59fe7 com.apple.CoreFoundation (6.9 - 1575.17) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff44c5b000 - 0x7fff452eafff com.apple.CoreGraphics (2.0 - 1265.9) /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x7fff452ec000 - 0x7fff4560cfff com.apple.CoreImage (14.4.0 - 750.0.140) <11026E39-D2FF-3CF6-8ACE-7BA293F9853E> /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage 0x7fff45a6a000 - 0x7fff45a6afff com.apple.CoreServices (946 - 946) <455AB7C9-ECB1-3B5C-8D07-AC68810A90B1> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x7fff45a6b000 - 0x7fff45ae7ff7 com.apple.AE (773 - 773) <55AE7C9E-27C3-30E9-A047-3B92A6FD53B4> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE 0x7fff45ae8000 - 0x7fff45dbffff com.apple.CoreServices.CarbonCore (1178.33 - 1178.33) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x7fff45dc0000 - 0x7fff45e08ff7 com.apple.DictionaryServices (1.2 - 284.16.4) <746EB200-DC51-30AE-9CBC-608A7B4CC8DA> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices 0x7fff45e09000 - 0x7fff45e11ffb com.apple.CoreServices.FSEvents (1239.200.12 - 1239.200.12) <8406D379-8D33-3611-861B-7ABD26DB50D2> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/FSEvents 0x7fff45e12000 - 0x7fff45fc3ff7 com.apple.LaunchServices (946 - 946) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices 0x7fff45fc4000 - 0x7fff46062ff7 com.apple.Metadata (10.7.0 - 1191.57) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata 0x7fff46063000 - 0x7fff460adff7 com.apple.CoreServices.OSServices (946 - 946) <20C4EEF8-D5AC-39A0-9B4A-78F88E3EFBCC> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices 0x7fff460ae000 - 0x7fff46115ff7 com.apple.SearchKit (1.4.0 - 1.4.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit 0x7fff46116000 - 0x7fff46137ff3 com.apple.coreservices.SharedFileList (71.28 - 71.28) <487A8464-729E-305A-B5D1-E3FE8EB9CFC5> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList 0x7fff46442000 - 0x7fff465a4ff3 com.apple.CoreText (352.0 - 584.26.3.2) <59919B0C-CBD5-3877-8D6F-D6048F1E5F42> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText 0x7fff465a5000 - 0x7fff465e5ff3 com.apple.CoreVideo (1.8 - 281.4) <10CF8E52-07E3-382B-8091-2CEEEFFA69B4> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo 0x7fff468cc000 - 0x7fff468d1ffb com.apple.DiskArbitration (2.7 - 2.7) /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x7fff46a97000 - 0x7fff46e44fff com.apple.Foundation (6.9 - 1575.17) <20150BA3-74D6-3991-AD22-52735FAD0E24> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x7fff46eb3000 - 0x7fff46ee2ffb com.apple.GSS (4.0 - 2.0) /System/Library/Frameworks/GSS.framework/Versions/A/GSS 0x7fff4714f000 - 0x7fff471defff com.apple.framework.IOKit (2.0.2 - 1483.260.4) <8A90F547-86EF-3DFB-92FE-0E2C0376DD84> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x7fff471e0000 - 0x7fff471efffb com.apple.IOSurface (255.6.1 - 255.6.1) <85F85EBB-EA59-3A8B-B3EB-7C20F3CC77AE> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface 0x7fff47243000 - 0x7fff473cefef com.apple.ImageIO.framework (3.3.0 - 1850.2) <75E46A31-D87D-35CE-86A4-96A50971FDB2> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x7fff473cf000 - 0x7fff473d3ffb libGIF.dylib (1850.2) <4774EBDF-583B-3DDD-A0E1-9F427CB6A074> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib 0x7fff473d4000 - 0x7fff474b0fef libJP2.dylib (1850.2) <697BB77F-A682-339F-8659-35432962432D> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib 0x7fff474b1000 - 0x7fff474d6feb libJPEG.dylib (1850.2) <171A8AC4-AADA-376F-9F2C-B9C978DB1007> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib 0x7fff47799000 - 0x7fff477bffeb libPng.dylib (1850.2) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib 0x7fff477c0000 - 0x7fff477c2ffb libRadiance.dylib (1850.2) <56907025-D5CE-3A9E-ACCB-A376C2599853> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib 0x7fff477c3000 - 0x7fff47810fe7 libTIFF.dylib (1850.2) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib 0x7fff48983000 - 0x7fff4899cfff com.apple.Kerberos (3.0 - 1) /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos 0x7fff493b8000 - 0x7fff49460ff7 com.apple.Metal (162.2 - 162.2) /System/Library/Frameworks/Metal.framework/Versions/A/Metal 0x7fff4947c000 - 0x7fff4949bff7 com.apple.MetalPerformanceShaders.MPSCore (1.0 - 1) <44CE8362-E972-3697-AD6F-15BC863BAEB8> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSCore.framework/Versions/A/MPSCore 0x7fff4949c000 - 0x7fff49518fe7 com.apple.MetalPerformanceShaders.MPSImage (1.0 - 1) /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSImage.framework/Versions/A/MPSImage 0x7fff49519000 - 0x7fff49540fff com.apple.MetalPerformanceShaders.MPSMatrix (1.0 - 1) /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSMatrix.framework/Versions/A/MPSMatrix 0x7fff49541000 - 0x7fff4966cff7 com.apple.MetalPerformanceShaders.MPSNeuralNetwork (1.0 - 1) /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSNeuralNetwork.framework/Versions/A/MPSNeuralNetwork 0x7fff4966d000 - 0x7fff49687fff com.apple.MetalPerformanceShaders.MPSRayIntersector (1.0 - 1) /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSRayIntersector.framework/Versions/A/MPSRayIntersector 0x7fff49688000 - 0x7fff49689ff7 com.apple.MetalPerformanceShaders.MetalPerformanceShaders (1.0 - 1) <69F14BCF-C5C5-3BF8-9C31-8F87D2D6130A> /System/Library/Frameworks/MetalPerformanceShaders.framework/Versions/A/MetalPerformanceShaders 0x7fff4a480000 - 0x7fff4a48cff7 com.apple.NetFS (6.0 - 4.0) /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS 0x7fff4cf2a000 - 0x7fff4cf81ff7 com.apple.opencl (2.15.3 - 2.15.3) <056BAD8A-23BC-3F74-9E2C-3AC81E7DEA5A> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL 0x7fff4cf82000 - 0x7fff4cf9dff7 com.apple.CFOpenDirectory (10.14 - 207.200.4) /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory 0x7fff4cf9e000 - 0x7fff4cfa9ffb com.apple.OpenDirectory (10.14 - 207.200.4) /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory 0x7fff4d8f9000 - 0x7fff4d8fbfff libCVMSPluginSupport.dylib (17.7.3) <8E051EA7-55B6-3DF1-9821-72C391DE953B> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib 0x7fff4d8fc000 - 0x7fff4d901ff3 libCoreFSCache.dylib (166.2) <222C2A4F-7E32-30F6-8459-2FAB98073A3D> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib 0x7fff4d902000 - 0x7fff4d906fff libCoreVMClient.dylib (166.2) <6789ECD4-91DD-32EF-A1FD-F27D2344CD8B> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib 0x7fff4d907000 - 0x7fff4d90fff7 libGFXShared.dylib (17.7.3) <8C50BF27-B525-3B23-B86C-F444ADF97851> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib 0x7fff4d910000 - 0x7fff4d91bfff libGL.dylib (17.7.3) <2AC457EA-1BD3-3C8E-AFAB-7EA6234EB749> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib 0x7fff4d91c000 - 0x7fff4d956fef libGLImage.dylib (17.7.3) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib 0x7fff4daca000 - 0x7fff4db08fff libGLU.dylib (17.7.3) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib 0x7fff4e4a5000 - 0x7fff4e4b4ffb com.apple.opengl (17.7.3 - 17.7.3) <94B5CF34-5BD6-3652-9A8C-E9C56E0A9FB4> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 0x7fff4f2b7000 - 0x7fff4f50eff7 com.apple.QuartzCore (1.11 - 701.14) <33E846BE-1794-3186-9BF2-6ADF62C782A3> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore 0x7fff4fd43000 - 0x7fff50043fff com.apple.security (7.0 - 58286.270.3.0.1) /System/Library/Frameworks/Security.framework/Versions/A/Security 0x7fff50044000 - 0x7fff500d0fff com.apple.securityfoundation (6.0 - 55185.260.1) <1EE899E6-222A-3526-B505-B0D0B6FA042A> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation 0x7fff50102000 - 0x7fff50106fff com.apple.xpc.ServiceManagement (1.0 - 1) /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement 0x7fff5049f000 - 0x7fff5050cfff com.apple.SystemConfiguration (1.17 - 1.17) <30C8327F-3EFF-3520-9C50-016F8B6B954F> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration 0x7fff53748000 - 0x7fff537edfeb com.apple.APFS (1.0 - 1) <2D22485D-552D-3CB6-9FE1-38547597918F> /System/Library/PrivateFrameworks/APFS.framework/Versions/A/APFS 0x7fff54201000 - 0x7fff54202ff7 com.apple.AggregateDictionary (1.0 - 1) /System/Library/PrivateFrameworks/AggregateDictionary.framework/Versions/A/AggregateDictionary 0x7fff54957000 - 0x7fff54966fc7 com.apple.AppleFSCompression (96.200.3 - 1.0) <3CF60CE8-976E-3CB8-959D-DD0948C1C2DE> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression 0x7fff54aae000 - 0x7fff54af7ff3 com.apple.AppleJPEG (1.0 - 1) <4C1F426B-7D77-3980-9633-7DBD8C666B9A> /System/Library/PrivateFrameworks/AppleJPEG.framework/Versions/A/AppleJPEG 0x7fff54d4b000 - 0x7fff54d6dfff com.apple.applesauce (1.0 - ???) /System/Library/PrivateFrameworks/AppleSauce.framework/Versions/A/AppleSauce 0x7fff54ecc000 - 0x7fff54ee0ffb com.apple.AssertionServices (1.0 - 1) <456E507A-4561-3628-9FBE-173ACE7429D8> /System/Library/PrivateFrameworks/AssertionServices.framework/Versions/A/AssertionServices 0x7fff5555d000 - 0x7fff55565fff com.apple.coreservices.BackgroundTaskManagement (1.0 - 57.1) <2A396FC0-7B79-3088-9A82-FB93C1181A57> /System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Versions/A/BackgroundTaskManagement 0x7fff555fc000 - 0x7fff55669ff3 com.apple.BaseBoard (360.28 - 360.28) <68FA8044-F3CD-3BC6-9DAB-27DACF52BFC0> /System/Library/PrivateFrameworks/BaseBoard.framework/Versions/A/BaseBoard 0x7fff572d4000 - 0x7fff572ddffb com.apple.CommonAuth (4.0 - 2.0) <93335CB6-ABEB-3EC7-A040-8A667F40D5F3> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth 0x7fff57fb6000 - 0x7fff57fc7ff7 com.apple.CoreEmoji (1.0 - 69.19.9) <228457B3-E191-356E-9A5B-3C0438D05FBA> /System/Library/PrivateFrameworks/CoreEmoji.framework/Versions/A/CoreEmoji 0x7fff58571000 - 0x7fff585d7ff7 com.apple.CoreNLP (1.0 - 130.15.22) <27877820-17D0-3B02-8557-4014E876CCC7> /System/Library/PrivateFrameworks/CoreNLP.framework/Versions/A/CoreNLP 0x7fff59349000 - 0x7fff5934dff7 com.apple.DSExternalDisplay (3.1 - 380) <787B9748-B120-3453-B8FE-61D9E363A9E0> /System/Library/PrivateFrameworks/DSExternalDisplay.framework/Versions/A/DSExternalDisplay 0x7fff5a54f000 - 0x7fff5a96afff com.apple.vision.FaceCore (3.3.4 - 3.3.4) /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore 0x7fff5f8bf000 - 0x7fff5f8c4fff com.apple.GPUWrangler (3.50.12 - 3.50.12) <6C820ED9-F306-3978-B5B8-432AD97BBDAF> /System/Library/PrivateFrameworks/GPUWrangler.framework/Versions/A/GPUWrangler 0x7fff606d0000 - 0x7fff606dffff com.apple.GraphVisualizer (1.0 - 5) <48D020B7-5938-3FAE-B468-E291AEE2C06F> /System/Library/PrivateFrameworks/GraphVisualizer.framework/Versions/A/GraphVisualizer 0x7fff60845000 - 0x7fff608b9ffb com.apple.Heimdal (4.0 - 2.0) /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal 0x7fff61bbd000 - 0x7fff61bc4ffb com.apple.IOAccelerator (404.14 - 404.14) <11A50171-C8AE-3BBC-9FB9-2A3313FFBD31> /System/Library/PrivateFrameworks/IOAccelerator.framework/Versions/A/IOAccelerator 0x7fff61bc8000 - 0x7fff61be0fff com.apple.IOPresentment (1.0 - 42.6) <6DFD9A6E-BF95-3A27-89E7-ACAA9E30D90A> /System/Library/PrivateFrameworks/IOPresentment.framework/Versions/A/IOPresentment 0x7fff62275000 - 0x7fff62350ff7 com.apple.LanguageModeling (1.0 - 159.15.15) <3DE3CE61-542B-37B7-883E-4B9717CAC65F> /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling 0x7fff62351000 - 0x7fff6238dff7 com.apple.Lexicon-framework (1.0 - 33.15.10) <4B5E843E-2809-3E70-9560-9254E2656419> /System/Library/PrivateFrameworks/Lexicon.framework/Versions/A/Lexicon 0x7fff62394000 - 0x7fff62399fff com.apple.LinguisticData (1.0 - 238.25) /System/Library/PrivateFrameworks/LinguisticData.framework/Versions/A/LinguisticData 0x7fff6308e000 - 0x7fff630b6ff7 com.apple.spotlight.metadata.utilities (1.0 - 1191.57) <38BB1FB7-3336-384C-B71F-4D0D402EB606> /System/Library/PrivateFrameworks/MetadataUtilities.framework/Versions/A/MetadataUtilities 0x7fff630b7000 - 0x7fff63144ff7 com.apple.gpusw.MetalTools (1.0 - 1) /System/Library/PrivateFrameworks/MetalTools.framework/Versions/A/MetalTools 0x7fff63393000 - 0x7fff633bdffb com.apple.MultitouchSupport.framework (2450.1 - 2450.1) <42A23EC9-64A7-31C7-BF33-DF4412ED8A3F> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport 0x7fff635f9000 - 0x7fff63603fff com.apple.NetAuth (6.2 - 6.2) <0D01BBE5-0269-310D-B148-D19DAE143DEB> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth 0x7fff63e64000 - 0x7fff63eb5ff3 com.apple.OTSVG (1.0 - ???) <5BF1A9EB-2694-3267-9514-A4EB3BEF4081> /System/Library/PrivateFrameworks/OTSVG.framework/Versions/A/OTSVG 0x7fff699b0000 - 0x7fff69c5ffff com.apple.SkyLight (1.600.0 - 340.54) <90EB1C2E-B264-3EC4-AF7F-CDE7E7585746> /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/SkyLight 0x7fff6b0d2000 - 0x7fff6b0deffb com.apple.TCC (1.0 - 1) <73CF6FA9-44CE-30C9-887F-235940976585> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC 0x7fff6cfb1000 - 0x7fff6cfb3ffb com.apple.loginsupport (1.0 - 1) <3F8D6334-BCD6-36C1-BA20-CC8503A84375> /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport 0x7fff6d27d000 - 0x7fff6d2b1fff libCRFSuite.dylib (41.15.4) <406DAC06-0C77-3F90-878B-4D38F11F0256> /usr/lib/libCRFSuite.dylib 0x7fff6d2b4000 - 0x7fff6d2beff7 libChineseTokenizer.dylib (28.15.3) <9B7F6109-3A5D-3641-9A7E-31D2239D73EE> /usr/lib/libChineseTokenizer.dylib 0x7fff6d34c000 - 0x7fff6d34dffb libDiagnosticMessagesClient.dylib (107) /usr/lib/libDiagnosticMessagesClient.dylib 0x7fff6d384000 - 0x7fff6d5dbff3 libFosl_dynamic.dylib (18.3.4) <1B5DD4E2-8AE0-315E-829E-D5BFCD264EA8> /usr/lib/libFosl_dynamic.dylib 0x7fff6d62c000 - 0x7fff6d64bfff libMobileGestalt.dylib (645.270.1) <99A06C8A-97D6-383D-862C-F453BABB48A4> /usr/lib/libMobileGestalt.dylib 0x7fff6d64c000 - 0x7fff6d64cfff libOpenScriptingUtil.dylib (179.1) <4D603146-EDA5-3A74-9FF8-4F75D8BB9BC6> /usr/lib/libOpenScriptingUtil.dylib 0x7fff6d78c000 - 0x7fff6d78dffb libSystem.B.dylib (1252.250.1) /usr/lib/libSystem.B.dylib 0x7fff6d809000 - 0x7fff6d80afff libThaiTokenizer.dylib (2.15.1) /usr/lib/libThaiTokenizer.dylib 0x7fff6d81c000 - 0x7fff6d832ffb libapple_nghttp2.dylib (1.24.1) <6F04250A-6686-3FDC-9A8D-290C64B06502> /usr/lib/libapple_nghttp2.dylib 0x7fff6d833000 - 0x7fff6d85cffb libarchive.2.dylib (54.250.1) <47289946-8504-3966-9127-6CE39993DC2C> /usr/lib/libarchive.2.dylib 0x7fff6d8e0000 - 0x7fff6d8e0ff3 libauto.dylib (187) <3E3780E1-96F3-3A22-91C5-92F9A5805518> /usr/lib/libauto.dylib 0x7fff6d9b0000 - 0x7fff6d9c0ffb libbsm.0.dylib (39.200.18) /usr/lib/libbsm.0.dylib 0x7fff6d9c1000 - 0x7fff6d9cefff libbz2.1.0.dylib (38.200.3) <272953A1-8D36-329B-BDDB-E887B347710F> /usr/lib/libbz2.1.0.dylib 0x7fff6d9cf000 - 0x7fff6da22ff7 libc++.1.dylib (400.9.4) <9A60A190-6C34-339F-BB3D-AACE942009A4> /usr/lib/libc++.1.dylib 0x7fff6da23000 - 0x7fff6da38ff7 libc++abi.dylib (400.17) <38C09CED-9090-3719-90F3-04A2749F5428> /usr/lib/libc++abi.dylib 0x7fff6da39000 - 0x7fff6da39ff3 libcharset.1.dylib (51.200.6) <2A27E064-314C-359C-93FC-8A9B06206174> /usr/lib/libcharset.1.dylib 0x7fff6da3a000 - 0x7fff6da4affb libcmph.dylib (6.15.1) <9C52B2FE-179F-32AC-B87E-2AFC49ABF817> /usr/lib/libcmph.dylib 0x7fff6da4b000 - 0x7fff6da63ffb libcompression.dylib (52.250.2) <7F4BB18C-1FB4-3825-8D8B-6E6B168774C6> /usr/lib/libcompression.dylib 0x7fff6dcd8000 - 0x7fff6dceefff libcoretls.dylib (155.220.1) <4C64BE3E-41E3-3020-8BB7-07E90C0C861C> /usr/lib/libcoretls.dylib 0x7fff6dcef000 - 0x7fff6dcf0ff3 libcoretls_cfhelpers.dylib (155.220.1) <0959B3E9-6643-3589-8BB3-21D52CDF0EF1> /usr/lib/libcoretls_cfhelpers.dylib 0x7fff6e19c000 - 0x7fff6e1f2ff3 libcups.2.dylib (462.12) <095619DC-9233-3937-9E50-5F10D917A40D> /usr/lib/libcups.2.dylib 0x7fff6e326000 - 0x7fff6e326fff libenergytrace.dylib (17.200.1) <80BB567A-FD18-3497-BF97-353F57D98CDD> /usr/lib/libenergytrace.dylib 0x7fff6e358000 - 0x7fff6e35dff7 libgermantok.dylib (17.15.2) /usr/lib/libgermantok.dylib 0x7fff6e35e000 - 0x7fff6e363ff7 libheimdal-asn1.dylib (520.270.1) <73F60D6F-76F8-35EF-9C86-9A81225EE4BE> /usr/lib/libheimdal-asn1.dylib 0x7fff6e38e000 - 0x7fff6e47efff libiconv.2.dylib (51.200.6) <2047C9B7-3F74-3A95-810D-2ED8F0475A99> /usr/lib/libiconv.2.dylib 0x7fff6e47f000 - 0x7fff6e6e0ffb libicucore.A.dylib (62141.0.1) /usr/lib/libicucore.A.dylib 0x7fff6e72d000 - 0x7fff6e72efff liblangid.dylib (128.15.1) <22D05C4F-769B-3075-ABCF-44A0EBACE028> /usr/lib/liblangid.dylib 0x7fff6e72f000 - 0x7fff6e747ff3 liblzma.5.dylib (10.200.3) /usr/lib/liblzma.5.dylib 0x7fff6e75f000 - 0x7fff6e803ff7 libmecab.1.0.0.dylib (779.24.1) /usr/lib/libmecab.1.0.0.dylib 0x7fff6e804000 - 0x7fff6ea08fff libmecabra.dylib (779.24.1) /usr/lib/libmecabra.dylib 0x7fff6ebe0000 - 0x7fff6ef31ff7 libnetwork.dylib (1229.250.15) <72C7E9E3-B2BE-3300-BE1B-64606222022C> /usr/lib/libnetwork.dylib 0x7fff6efc3000 - 0x7fff6f748fdf libobjc.A.dylib (756.2) <7C312627-43CB-3234-9324-4DEA92D59F50> /usr/lib/libobjc.A.dylib 0x7fff6f75a000 - 0x7fff6f75effb libpam.2.dylib (22.200.1) <586CF87F-349C-393D-AEEB-FB75F94A5EB7> /usr/lib/libpam.2.dylib 0x7fff6f761000 - 0x7fff6f796fff libpcap.A.dylib (79.250.1) /usr/lib/libpcap.A.dylib 0x7fff6f8af000 - 0x7fff6f8c7ffb libresolv.9.dylib (65.200.2) <893142A5-F153-3437-A22D-407EE542B5C5> /usr/lib/libresolv.9.dylib 0x7fff6f91a000 - 0x7fff6faf7fff libsqlite3.dylib (274.26) <6404BA3B-BCA4-301F-B2FE-8776105A2AA3> /usr/lib/libsqlite3.dylib 0x7fff6fd10000 - 0x7fff6fd13ff7 libutil.dylib (51.200.4) /usr/lib/libutil.dylib 0x7fff6fd14000 - 0x7fff6fd21fff libxar.1.dylib (417.1) <39CCF46B-C81A-34B1-92A1-58C4E5DA846E> /usr/lib/libxar.1.dylib 0x7fff6fd26000 - 0x7fff6fe08ff3 libxml2.2.dylib (32.10) /usr/lib/libxml2.2.dylib 0x7fff6fe09000 - 0x7fff6fe31ff3 libxslt.1.dylib (16.5) /usr/lib/libxslt.1.dylib 0x7fff6fe32000 - 0x7fff6fe44ff7 libz.1.dylib (70.200.4) /usr/lib/libz.1.dylib 0x7fff70628000 - 0x7fff7062cff3 libcache.dylib (81) <1987D1E1-DB11-3291-B12A-EBD55848E02D> /usr/lib/system/libcache.dylib 0x7fff7062d000 - 0x7fff70637ff3 libcommonCrypto.dylib (60118.250.2) <1765BB6E-6784-3653-B16B-CB839721DC9A> /usr/lib/system/libcommonCrypto.dylib 0x7fff70638000 - 0x7fff7063fff7 libcompiler_rt.dylib (63.4) <5212BA7B-B7EA-37B4-AF6E-AC4F507EDFB8> /usr/lib/system/libcompiler_rt.dylib 0x7fff70640000 - 0x7fff70649ff7 libcopyfile.dylib (146.250.1) <98CD00CD-9B91-3B5C-A9DB-842638050FA8> /usr/lib/system/libcopyfile.dylib 0x7fff7064a000 - 0x7fff706cefc3 libcorecrypto.dylib (602.260.2) <01464D24-570C-3B83-9D18-467769E0FCDD> /usr/lib/system/libcorecrypto.dylib 0x7fff70755000 - 0x7fff7078eff7 libdispatch.dylib (1008.270.1) <97273678-E94C-3C8C-89F6-2E2020F4B43B> /usr/lib/system/libdispatch.dylib 0x7fff7078f000 - 0x7fff707bbff7 libdyld.dylib (655.1.1) <002418CC-AD11-3D10-865B-015591D24E6C> /usr/lib/system/libdyld.dylib 0x7fff707bc000 - 0x7fff707bcffb libkeymgr.dylib (30) <0D0F9CA2-8D5A-3273-8723-59987B5827F2> /usr/lib/system/libkeymgr.dylib 0x7fff707bd000 - 0x7fff707c9ff3 libkxld.dylib (4903.270.47) /usr/lib/system/libkxld.dylib 0x7fff707ca000 - 0x7fff707caff7 liblaunch.dylib (1336.261.2) <2B07E27E-D404-3E98-9D28-BCA641E5C479> /usr/lib/system/liblaunch.dylib 0x7fff707cb000 - 0x7fff707d0fff libmacho.dylib (927.0.3) /usr/lib/system/libmacho.dylib 0x7fff707d1000 - 0x7fff707d3ffb libquarantine.dylib (86.220.1) <6D0BC770-7348-3608-9254-F7FFBD347634> /usr/lib/system/libquarantine.dylib 0x7fff707d4000 - 0x7fff707d5ff7 libremovefile.dylib (45.200.2) <9FBEB2FF-EEBE-31BC-BCFC-C71F8D0E99B6> /usr/lib/system/libremovefile.dylib 0x7fff707d6000 - 0x7fff707edff3 libsystem_asl.dylib (356.200.4) /usr/lib/system/libsystem_asl.dylib 0x7fff707ee000 - 0x7fff707eeff7 libsystem_blocks.dylib (73) /usr/lib/system/libsystem_blocks.dylib 0x7fff707ef000 - 0x7fff70876fff libsystem_c.dylib (1272.250.1) <7EDACF78-2FA3-35B8-B051-D70475A35117> /usr/lib/system/libsystem_c.dylib 0x7fff70877000 - 0x7fff7087affb libsystem_configuration.dylib (963.270.3) <2B4A836D-68A4-33E6-8D48-CD4486B03387> /usr/lib/system/libsystem_configuration.dylib 0x7fff7087b000 - 0x7fff7087eff7 libsystem_coreservices.dylib (66) <719F75A4-74C5-3BA6-A09E-0C5A3E5889D7> /usr/lib/system/libsystem_coreservices.dylib 0x7fff7087f000 - 0x7fff70885fff libsystem_darwin.dylib (1272.250.1) /usr/lib/system/libsystem_darwin.dylib 0x7fff70886000 - 0x7fff7088cff7 libsystem_dnssd.dylib (878.270.2) /usr/lib/system/libsystem_dnssd.dylib 0x7fff7088d000 - 0x7fff708d8ffb libsystem_info.dylib (517.200.9) /usr/lib/system/libsystem_info.dylib 0x7fff708d9000 - 0x7fff70901ff7 libsystem_kernel.dylib (4903.270.47) <4195838C-EFEF-3CC9-B459-75032AF7EA1A> /usr/lib/system/libsystem_kernel.dylib 0x7fff70902000 - 0x7fff7094dff7 libsystem_m.dylib (3158.200.7) /usr/lib/system/libsystem_m.dylib 0x7fff7094e000 - 0x7fff70978fff libsystem_malloc.dylib (166.270.1) <011F3AD0-8E6A-3A89-AE64-6E5F6840F30A> /usr/lib/system/libsystem_malloc.dylib 0x7fff70979000 - 0x7fff70983ff7 libsystem_networkextension.dylib (767.250.2) /usr/lib/system/libsystem_networkextension.dylib 0x7fff70984000 - 0x7fff7098bfff libsystem_notify.dylib (172.200.21) <145B5CFC-CF73-33CE-BD3D-E8DDE268FFDE> /usr/lib/system/libsystem_notify.dylib 0x7fff7098c000 - 0x7fff70995fef libsystem_platform.dylib (177.270.1) <9D1FE5E4-EB7D-3B3F-A8D1-A96D9CF1348C> /usr/lib/system/libsystem_platform.dylib 0x7fff70996000 - 0x7fff709a0ff7 libsystem_pthread.dylib (330.250.2) <2D5C08FF-484F-3D59-9132-CE1DCB3F76D7> /usr/lib/system/libsystem_pthread.dylib 0x7fff709a1000 - 0x7fff709a4ff7 libsystem_sandbox.dylib (851.270.1) <9494594B-5199-3186-82AB-5FF8BED6EE16> /usr/lib/system/libsystem_sandbox.dylib 0x7fff709a5000 - 0x7fff709a7ff3 libsystem_secinit.dylib (30.260.2) /usr/lib/system/libsystem_secinit.dylib 0x7fff709a8000 - 0x7fff709afff3 libsystem_symptoms.dylib (820.267.1) <03F1C2DD-0F5A-3D9D-88F6-B26C0F94EB52> /usr/lib/system/libsystem_symptoms.dylib 0x7fff709b0000 - 0x7fff709c5fff libsystem_trace.dylib (906.260.1) /usr/lib/system/libsystem_trace.dylib 0x7fff709c7000 - 0x7fff709ccffb libunwind.dylib (35.4) <24A97A67-F017-3CFC-B0D0-6BD0224B1336> /usr/lib/system/libunwind.dylib 0x7fff709cd000 - 0x7fff709fcfff libxpc.dylib (1336.261.2) <7DEE2300-6D8E-3C00-9C63-E3E80D56B0C4> /usr/lib/system/libxpc.dylib Sample analysis of process 31833 written to file /dev/stdout -- Regards, Uri -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: From andrew.lynch at atos.net Wed Jul 24 07:02:56 2019 From: andrew.lynch at atos.net (Lynch, Andrew) Date: Wed, 24 Jul 2019 07:02:56 +0000 Subject: Engine updating a key's ex data in sign/encrypt method? In-Reply-To: References: <04b04d9c58af4c21aa6d339a330ce408@atos.net> Message-ID: <5a4518b9fb264e1e9faf434edf6ebd95@atos.net> Hi Matt, Thanks for the thumbs-up. I can confirm that it works as expected. If I cast away the const and call RSA_set_ex_data() then the session handle is updated and available the next time stunnel uses that same key. Now I just need to figure out how to document this so that a potential code review doesn't freak out... Regards, Andrew. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Tuesday, July 23, 2019 10:28 AM To: openssl-users at openssl.org Subject: Re: Engine updating a key's ex data in sign/encrypt method? On 22/07/2019 17:44, Lynch, Andrew wrote: > Hi, > > I am wondering whether it is ok to update a key's ex data from within an engine method that is using the key. This is with both OpenSSL 1.1.1a and 1.0.2j. > > In my engine's load_privkey() method I connect to the HSM and obtain handles for a session and the key object. Both handles are then stored in the key's ex data using RSA_set_ex_data() or EC_KEY_set_ex_data(). They will later be released by the registered free_func. The sign and/or encrypt methods use these handles when making their calls to the HSM API. > > This works fine for single operations like an openssl x509 command line, but not for long running applications such as stunnel. It appears that stunnel loads all configured keys and certs at startup and then waits for clients to connect. If there is no activity for a while the HSM will time out my session handle and the next sign operation using that session fails. I can catch the error and reconnect, but this results in a new session handle. The next time a client calls the same service, that key's ex data still contains the old outdated session handle resulting in the same error all over again. > > So whenever I renew a session handle in the sign method I need to update the ex data of the affected key with the new value. > > This appears to work fine for EC keys by calling EC_KEY_set_ex_data() from within the engine's ecdsa_do_sign() method. The same goes for RSA keys in rsa_private_decrypt() and rsa_private_encrypt(), but with rsa_sign() I have a problem in that the key parameter is const RSA *. > > Is the lack of const in rsa_private_encrypt() and ecdsa_do_sign() an oversight and I should not be manipulating ex data of the provided key in this way? > Or is the const in rsa_sign() too strict and it is actually ok to modify the ex data of the key? I can't see a problem with modifying the ex_data like that. Matt From kevin.lengauer at adnovum.ch Wed Jul 24 11:00:11 2019 From: kevin.lengauer at adnovum.ch (K Lengauer) Date: Wed, 24 Jul 2019 04:00:11 -0700 (MST) Subject: Openssl binary with statically linked libssl and libcrypto In-Reply-To: References: <1563872550512-0.post@n7.nabble.com> Message-ID: <1563966011889-0.post@n7.nabble.com> Hi Michael Mueller Thank you for answering. So if I understand you correctly you also use the "build.info" file to specify the static libraries as dependencies for the 'openssl' binary. Do you encounter any segmentation faults when running the tests provided by OpenSSL in the openssl/test/recipes, i.e. when running "make test"? The segfaults occur during the category "70" tests, so during ssl/tls tests for example when testing server - client connections. I only encounter these segmentation faults when using the static libraries instead of the default case with shared libs which confuses me a bit. If you do not encounter these segfaults I guess the error is in my code extensions (patches, added files). Or can there be another reason? Regards, Kevin -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From nniklas at mail.uni-paderborn.de Wed Jul 24 16:22:15 2019 From: nniklas at mail.uni-paderborn.de (Niklas Niere) Date: Wed, 24 Jul 2019 18:22:15 +0200 Subject: logarithm in OpenSSL Message-ID: <134469df-fbe6-0f34-d735-ee23f5a78eaf@mail.uni-paderborn.de> Hello, we are implementing a TLS 1.3 feature into OpenSSL to get an idea of how well our feature performs in a concrete server library. In the feature, we want to use the log function. When we try to use the log function from the math.h header, OpenSSL won't compile with the statement that 'log' is a reference to an undefined function. The BigNum library from OpenSSL does also not seem to offer a log function. We suspect that the compile error comes from the fact that OpenSSL is C90 compatible but are unsure. Does anyone know how to compute the logarithm of a number in OpenSSL? Thanks, Niklas From guidovranken at gmail.com Wed Jul 24 16:51:22 2019 From: guidovranken at gmail.com (Guido Vranken) Date: Wed, 24 Jul 2019 18:51:22 +0200 Subject: logarithm in OpenSSL In-Reply-To: <134469df-fbe6-0f34-d735-ee23f5a78eaf@mail.uni-paderborn.de> References: <134469df-fbe6-0f34-d735-ee23f5a78eaf@mail.uni-paderborn.de> Message-ID: If you want to use the log() from math.h, then you must compile with -lm, eg.: clang source.c -lm The log() in math.h only supports floating point numbers. If you require computing logarithms of bignums, try https://www.mpfr.org/ On Wed, Jul 24, 2019 at 6:39 PM Niklas Niere wrote: > Hello, > > we are implementing a TLS 1.3 feature into OpenSSL to get an idea of how > well our feature performs in a concrete server library. In the feature, > we want to use the log function. > > When we try to use the log function from the math.h header, OpenSSL > won't compile with the statement that 'log' is a reference to an > undefined function. The BigNum library from OpenSSL does also not seem > to offer a log function. > > We suspect that the compile error comes from the fact that OpenSSL is > C90 compatible but are unsure. Does anyone know how to compute the > logarithm of a number in OpenSSL? > > Thanks, > Niklas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nniklas at mail.uni-paderborn.de Wed Jul 24 17:02:10 2019 From: nniklas at mail.uni-paderborn.de (Niklas Niere) Date: Wed, 24 Jul 2019 19:02:10 +0200 Subject: logarithm in OpenSSL In-Reply-To: References: <134469df-fbe6-0f34-d735-ee23f5a78eaf@mail.uni-paderborn.de> Message-ID: <83b724dc-51c1-749c-ff66-9888b7653df9@mail.uni-paderborn.de> Thank you for the answer. We are using the Makefile from OpenSSL to compile our feature as it changes OpenSSL directly. As I understood it, we would have to import another number library to compile our code with the standard OpenSSL settings and using the logarithm, correct? On 2019-07-24 6:51 p.m., Guido Vranken wrote: > If you want to use the log() from math.h, then you must compile with > -lm, eg.: clang source.c -lm > > The log() in math.h only supports floating point numbers. If you > require computing logarithms of bignums, try https://www.mpfr.org/ > > On Wed, Jul 24, 2019 at 6:39 PM Niklas Niere > > > wrote: > > Hello, > > we are implementing a TLS 1.3 feature into OpenSSL to get an idea > of how > well our feature performs in a concrete server library. In the > feature, > we want to use the log function. > > When we try to use the log function from the math.h header, OpenSSL > won't compile with the statement that 'log' is a reference to an > undefined function. The BigNum library from OpenSSL does also not > seem > to offer a log function. > > We suspect that the compile error comes from the fact that OpenSSL is > C90 compatible but are unsure. Does anyone know how to compute the > logarithm of a number in OpenSSL? > > Thanks, > Niklas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guidovranken at gmail.com Wed Jul 24 17:17:14 2019 From: guidovranken at gmail.com (Guido Vranken) Date: Wed, 24 Jul 2019 19:17:14 +0200 Subject: logarithm in OpenSSL In-Reply-To: <83b724dc-51c1-749c-ff66-9888b7653df9@mail.uni-paderborn.de> References: <134469df-fbe6-0f34-d735-ee23f5a78eaf@mail.uni-paderborn.de> <83b724dc-51c1-749c-ff66-9888b7653df9@mail.uni-paderborn.de> Message-ID: log() in math.h only supports float or double type. float and double are limited in the range of numbers they can express. For example, these types cannot hold large numbers like "99999999999999999999999999999999999999999". Depending on your purpose, float and double may be sufficient, and you can use log() from math.h and link with -lm. If you require logarithms of large numbers, you'll have to resort to a library that supports this, like the one I linked to. Alternatively, you can implement a logarithm extension to OpenSSL's bignum library using existing bignum functions. On Wed, Jul 24, 2019 at 7:02 PM Niklas Niere wrote: > Thank you for the answer. We are using the Makefile from OpenSSL to > compile our feature as it changes OpenSSL directly. As I understood it, we > would have to import another number library to compile our code with the > standard OpenSSL settings and using the logarithm, correct? > On 2019-07-24 6:51 p.m., Guido Vranken wrote: > > If you want to use the log() from math.h, then you must compile with -lm, > eg.: clang source.c -lm > > The log() in math.h only supports floating point numbers. If you require > computing logarithms of bignums, try https://www.mpfr.org/ > > On Wed, Jul 24, 2019 at 6:39 PM Niklas Niere < > nniklas at mail.uni-paderborn.de> wrote: > >> Hello, >> >> we are implementing a TLS 1.3 feature into OpenSSL to get an idea of how >> well our feature performs in a concrete server library. In the feature, >> we want to use the log function. >> >> When we try to use the log function from the math.h header, OpenSSL >> won't compile with the statement that 'log' is a reference to an >> undefined function. The BigNum library from OpenSSL does also not seem >> to offer a log function. >> >> We suspect that the compile error comes from the fact that OpenSSL is >> C90 compatible but are unsure. Does anyone know how to compute the >> logarithm of a number in OpenSSL? >> >> Thanks, >> Niklas >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From abaci.mjm at gmail.com Wed Jul 24 17:49:11 2019 From: abaci.mjm at gmail.com (Michael Mueller) Date: Wed, 24 Jul 2019 13:49:11 -0400 Subject: Openssl binary with statically linked libssl and libcrypto In-Reply-To: <1563966011889-0.post@n7.nabble.com> References: <1563872550512-0.post@n7.nabble.com> <1563966011889-0.post@n7.nabble.com> Message-ID: On Wed, Jul 24, 2019, 7:00 AM K Lengauer wrote: > So if I understand you correctly you also use the > "build.info" file to specify the static libraries as dependencies for the > 'openssl' binary. > Negative. We use the following method: ./config \ no-hw \ no-zlib \ no-shared \ no-ssl2 \ no-ssl3 \ --prefix=$INSTALL_D \ --openssldir=$INSTALL_D > Do you encounter any segmentation faults when running the tests provided by > OpenSSL in the openssl/test/recipes, i.e. when running "make test"? Tests run cleanly. Some tests are skipped. > > -- > Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hmurray at megapathdsl.net Wed Jul 24 19:55:33 2019 From: hmurray at megapathdsl.net (Hal Murray) Date: Wed, 24 Jul 2019 12:55:33 -0700 Subject: logarithm in OpenSSL In-Reply-To: Message from Guido Vranken of "Wed, 24 Jul 2019 19:17:14 +0200." Message-ID: <20190724195533.E277040605C@ip-64-139-1-69.sjc.megapath.net> guidovranken at gmail.com said: > If you require logarithms of large numbers, you'll have to resort to a > library that supports this, like the one I linked to. Or scale the large number so it fits and add the log of the scale factor which you can compute by hand from the scale factor. For example, log10(1234) is log10(1.234)+3*log10(10). -- These are my opinions. I hate spam. From paul.dale at oracle.com Wed Jul 24 21:59:09 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Thu, 25 Jul 2019 07:59:09 +1000 Subject: logarithm in OpenSSL In-Reply-To: <134469df-fbe6-0f34-d735-ee23f5a78eaf@mail.uni-paderborn.de> References: <134469df-fbe6-0f34-d735-ee23f5a78eaf@mail.uni-paderborn.de> Message-ID: <332B2677-C0BC-49F3-80F2-F3671AB7E916@oracle.com> I?m wondering why you need the log function? If you?re measuring performance, could the analysis tool perform the logarithm? A first order approximation to log_2(n) where n is a BIGNUM would be BN_num_bits(n). Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 25 Jul 2019, at 2:22 am, Niklas Niere wrote: > > Hello, > > we are implementing a TLS 1.3 feature into OpenSSL to get an idea of how well our feature performs in a concrete server library. In the feature, we want to use the log function. > > When we try to use the log function from the math.h header, OpenSSL won't compile with the statement that 'log' is a reference to an undefined function. The BigNum library from OpenSSL does also not seem to offer a log function. > > We suspect that the compile error comes from the fact that OpenSSL is C90 compatible but are unsure. Does anyone know how to compute the logarithm of a number in OpenSSL? > > Thanks, > Niklas > From Johannes.Heinz at telekom.de Thu Jul 25 09:01:06 2019 From: Johannes.Heinz at telekom.de (Johannes.Heinz at telekom.de) Date: Thu, 25 Jul 2019 09:01:06 +0000 Subject: EVP_KEY_cmp and -_parameters issues Message-ID: I have a question to following situation with RSA and DH structures: I'm testing these in separated unit tests. Both test cases (each one for RSA and DH) are doing the same: I'm creating a new DH or RSA structure, filling it with my params (pqg ...) and convert it to an EVP_PKEY (for example: EVP_PKEY_assign_DH => pkey1) Next step, I'm writing and reading this structure with these functions: PEM_write_bio_PrivateKey() (not PEM_write_bio_PrivateKey_traditional() ) (with password) EVP_PKEY* pkey2 = PEM_read_bio_PrivateKey() (with same password) (or even without a password) Now I want to compare these two EVP_PKEY* variables (pkey1 and pkey2) and for that I can use these two functions: EVP_PKEY_cmp(pkey1, pkey2) (compares components and params) EVP_PKEY_cmp_parameters(pkey1, pkey2) (compares params) Now the Problem: Even the tests work the same way, the one with RSA only accept the compare-function "EVP_PKEY_cmp" and not the other one. The one with DH is only with the "EVP_PKEY_cmp_parameters" successful. Question: Why can the first compare function find the components and params of the RSA structure (and even after the PEM_write_bio...) and not of the DH? Also, why it's with the second compare function (only params) the other way around (keys match in DH unit test and not in RSA unit test)? Greetings Johannes -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.lengauer at adnovum.ch Thu Jul 25 13:27:52 2019 From: kevin.lengauer at adnovum.ch (K Lengauer) Date: Thu, 25 Jul 2019 06:27:52 -0700 (MST) Subject: Openssl binary with statically linked libssl and libcrypto In-Reply-To: References: <1563872550512-0.post@n7.nabble.com> <1563966011889-0.post@n7.nabble.com> Message-ID: <1564061272717-0.post@n7.nabble.com> I see. Thank you again for answering and for the example ./config arguments. Sadly, I can not make use of the "no-shared" option as I still need the shared libraries to be built. But I wonder if there even is a way to achieve both at the same time. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From rsalz at akamai.com Thu Jul 25 13:31:07 2019 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 25 Jul 2019 13:31:07 +0000 Subject: Openssl binary with statically linked libssl and libcrypto In-Reply-To: <1564061272717-0.post@n7.nabble.com> References: <1563872550512-0.post@n7.nabble.com> <1563966011889-0.post@n7.nabble.com> <1564061272717-0.post@n7.nabble.com> Message-ID: <0845A886-6BD7-4B82-AA20-601E15F4619A@akamai.com> > Sadly, I can not make use of the "no-shared" option as I still need the shared libraries to be built. Statically linking against files built for shared libraries is possible on many platforms (link against the .a even though .so exists), but not all platforms. You can always build twice. From nniklas at mail.uni-paderborn.de Thu Jul 25 18:03:08 2019 From: nniklas at mail.uni-paderborn.de (Niklas Niere) Date: Thu, 25 Jul 2019 20:03:08 +0200 Subject: logarithm in OpenSSL In-Reply-To: <332B2677-C0BC-49F3-80F2-F3671AB7E916@oracle.com> References: <134469df-fbe6-0f34-d735-ee23f5a78eaf@mail.uni-paderborn.de> <332B2677-C0BC-49F3-80F2-F3671AB7E916@oracle.com> Message-ID: The BN_num_bits() approximation is exactly what we need. We need it to compute the depth of a node in a binary tree of which we only have a sub tree available. Thank you, Niklas On 24.07.2019 23:59, Dr Paul Dale wrote: > I?m wondering why you need the log function? > If you?re measuring performance, could the analysis tool perform the logarithm? > > A first order approximation to log_2(n) where n is a BIGNUM would be BN_num_bits(n). > > > Pauli From kevin.lengauer at adnovum.ch Fri Jul 26 06:36:56 2019 From: kevin.lengauer at adnovum.ch (K Lengauer) Date: Thu, 25 Jul 2019 23:36:56 -0700 (MST) Subject: Openssl binary with statically linked libssl and libcrypto In-Reply-To: <0845A886-6BD7-4B82-AA20-601E15F4619A@akamai.com> References: <1563872550512-0.post@n7.nabble.com> <1563966011889-0.post@n7.nabble.com> <1564061272717-0.post@n7.nabble.com> <0845A886-6BD7-4B82-AA20-601E15F4619A@akamai.com> Message-ID: <1564123016126-0.post@n7.nabble.com> Hi Rich Salz Thank you very much for responding and also for the indirect help through all your posts and comments in posts I read so far when looking for help with OpenSSL. Right, that is a good idea. I will try to achieve it by building it twice such that I can hopefully avoid the errors in the tests. Currently, I am working on RHEL7 which has not been that picky but I expect on other platforms it will not be as easy. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From upadhyay.manoj at live.com Fri Jul 26 09:43:59 2019 From: upadhyay.manoj at live.com (manoj upadhyay) Date: Fri, 26 Jul 2019 09:43:59 +0000 Subject: Issue Building OpenSSL version 1.1.1b using batch files Missing do_win64a/nt.mak/nt-dbg.mak Message-ID: Hi All, I need help in building the OpenSSL 1.1.1b using the batch files. I have existing batch files to build OpenSSL "1.0.2p". It uses following files to build OpenSSL. 1. ms\do_win64a 2. nt.mak 3. nt-dbg.mak But above files are missing from 1.1.1b. For reference I am adding code snippet from my batch file. Code snippet from Batch file. set VERSION=openssl-1.1.1b cd %VERSION% perl Configure VC-WIN64A no-asm call ms\do_win64a sed -e s/out32/out64/g ms\nt.mak | sed -e s/tmp32/tmp64/g | sed -e s/inc32/inc64/g > ms\nt-64.mak nmake -f ms\nt-64.mak clean nmake -f ms\nt-64.mak ............ ............. ........... cd %VERSION% perl util\mk1mf.pl debug no-asm VC-WIN64A >ms\nt-dbg.mak sed -e s/out32/out64/g ms\nt-dbg.mak | sed -e s/tmp32/tmp64/g | sed -e s/inc32/inc64/g > ms\nt-dbg-64.mak nmake -f ms\nt-dbg-64.mak clean nmake -f ms\nt-dbg-64.mak Errors during running Batch scripts: (File Not Found) Configuring OpenSSL version 1.1.1b (0x1010102fL) for VC-WIN64A Using os-specific seed configuration It looks like you don't have either nmake.exe or dmake.exe on your PATH, so you will not be able to execute the commands from a Makefile. You can install dmake.exe with the Perl Package Manager by running: ppm install dmake Creating configdata.pm Creating makefile ********************************************************************** *** *** *** OpenSSL has been successfully configured *** *** *** *** If you encounter a problem while building, please open an *** *** issue on GitHub *** *** and include the output from the following command: *** *** *** *** perl configdata.pm --dump *** *** *** *** (If you are new to OpenSSL, you might want to consult the *** *** 'Troubleshooting' section in the INSTALL file first) *** *** *** ********************************************************************** 'ms\do_win64a' is not recognized as an internal or external command, operable program or batch file. Configuring OpenSSL version 1.1.1b (0x1010102fL) for VC-WIN64A sed: can't read ms\nt.mak: No such file or directory Microsoft (R) Program Maintenance Utility Version 14.16.27031.1 Copyright (C) Microsoft Corporation. All rights reserved. NMAKE : fatal error U1073: don't know how to make 'clean' Stop. Can't open perl script "util\mk1mf.pl": No such file or directory Please help me in getting these files generated and build the code using the batch-files. P.S: I am able to build the code using the standard method below. perl Configure VC-WIN64A nmake nmake test nmake install -------------- next part -------------- An HTML attachment was scrubbed... URL: From astauber at horizont-it.com Fri Jul 26 09:44:01 2019 From: astauber at horizont-it.com (HORIZONT, Armin Stauber) Date: Fri, 26 Jul 2019 11:44:01 +0200 Subject: Cryptography API: Next Generation (CNG) Engine Message-ID: <003101d54396$a7f60010$f7e20030$@horizont-it.com> Hi, is there any plan or any current work to provide an engine for Cryptography API: Next Generation (CNG) e.g. by porting the existing capi engine? Regards, Armin -------------- next part -------------- An HTML attachment was scrubbed... URL: From abaci.mjm at gmail.com Fri Jul 26 10:09:52 2019 From: abaci.mjm at gmail.com (Michael Mueller) Date: Fri, 26 Jul 2019 06:09:52 -0400 Subject: Issue Building OpenSSL version 1.1.1b using batch files Missing do_win64a/nt.mak/nt-dbg.mak In-Reply-To: References: Message-ID: Found similar issues with our Windows 1.0.2 to 1.1.1c upgrade. Had to change our build process per INSTALL doc. The dll files are named differently which impacted our package and install process. Th On Fri, Jul 26, 2019, 5:44 AM manoj upadhyay wrote: > Hi All, > > I need help in building the OpenSSL 1.1.1b using the batch files. > I have existing batch files to build OpenSSL "1.0.2p". It uses following > files to build OpenSSL. > > 1. ms\do_win64a > 2. nt.mak > 3. nt-dbg.mak > > But above files are missing from 1.1.1b. For reference I am adding code > snippet from my batch file. > > Code snippet from Batch file. > > set VERSION=openssl-1.1.1b > > cd %VERSION% > > perl Configure VC-WIN64A no-asm > > call ms\do_win64a > > sed -e s/out32/out64/g ms\nt.mak | sed -e s/tmp32/tmp64/g | sed -e > s/inc32/inc64/g > ms\nt-64.mak > > nmake -f ms\nt-64.mak clean > > nmake -f ms\nt-64.mak > > ............ > > ............. > > ........... > > cd %VERSION% > > perl util\mk1mf.pl debug no-asm VC-WIN64A >ms\nt-dbg.mak > > sed -e s/out32/out64/g ms\nt-dbg.mak | sed -e s/tmp32/tmp64/g | sed -e > s/inc32/inc64/g > ms\nt-dbg-64.mak > > nmake -f ms\nt-dbg-64.mak clean > > nmake -f ms\nt-dbg-64.mak > > > Errors during running Batch scripts: (File Not Found) > > Configuring OpenSSL version 1.1.1b (0x1010102fL) for VC-WIN64A > > Using os-specific seed configuration > > > It looks like you don't have either nmake.exe or dmake.exe on your PATH, > > so you will not be able to execute the commands from a Makefile. You can > > install dmake.exe with the Perl Package Manager by running: > > > ppm install dmake > > > Creating configdata.pm > > Creating makefile > > > ********************************************************************** > > *** *** > > *** OpenSSL has been successfully configured *** > > *** *** > > *** If you encounter a problem while building, please open an *** > > *** issue on GitHub *** > > *** and include the output from the following command: *** > > *** *** > > *** perl configdata.pm --dump *** > > *** *** > > *** (If you are new to OpenSSL, you might want to consult the *** > > *** 'Troubleshooting' section in the INSTALL file first) *** > > *** *** > > ********************************************************************** > > 'ms\do_win64a' is not recognized as an internal or external command, > > operable program or batch file. > > > > Configuring OpenSSL version 1.1.1b (0x1010102fL) for VC-WIN64A > > sed: can't read ms\nt.mak: No such file or directory > > > > Microsoft (R) Program Maintenance Utility Version 14.16.27031.1 > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > NMAKE : fatal error U1073: don't know how to make 'clean' > > Stop. > > > Can't open perl script "util\mk1mf.pl": No such file or directory > > > > Please help me in getting these files generated and build the code using > the batch-files. > > P.S: I am able to build the code using the standard method below. > perl Configure VC-WIN64A > nmake > nmake test > nmake install > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abaci.mjm at gmail.com Fri Jul 26 10:13:46 2019 From: abaci.mjm at gmail.com (Michael Mueller) Date: Fri, 26 Jul 2019 06:13:46 -0400 Subject: Issue Building OpenSSL version 1.1.1b using batch files Missing do_win64a/nt.mak/nt-dbg.mak In-Reply-To: References: Message-ID: On Fri, Jul 26, 2019, 5:44 AM manoj upadhyay wrote: > This what we changed to. Will this method not work for you? > > > P.S: I am able to build the code using the standard method below. > perl Configure VC-WIN64A > nmake > nmake test > nmake install > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doctor at doctor.nl2k.ab.ca Fri Jul 26 10:23:15 2019 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 26 Jul 2019 04:23:15 -0600 Subject: 20190726 snapshots Message-ID: <20190726102315.GD68011@doctor.nl2k.ab.ca> What happened? I do not see any. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism Rather than love, than money, than fame, give me truth. -Henry David Thoreau From levitte at openssl.org Fri Jul 26 10:36:29 2019 From: levitte at openssl.org (Richard Levitte) Date: Fri, 26 Jul 2019 12:36:29 +0200 Subject: 20190726 snapshots In-Reply-To: <20190726102315.GD68011@doctor.nl2k.ab.ca> References: <20190726102315.GD68011@doctor.nl2k.ab.ca> Message-ID: I did some server maintenance this morning, and that may have interrupted today's snapshot production. I don't intend to fix it. A new snapshot should appear tomorrow. Cheers Richard The Doctor skrev: (26 juli 2019 12:23:15 CEST) >What happened? I do not see any. -- Richard by mobile From levitte at openssl.org Sat Jul 27 07:13:03 2019 From: levitte at openssl.org (Richard Levitte) Date: Sat, 27 Jul 2019 09:13:03 +0200 Subject: Cryptography API: Next Generation (CNG) Engine In-Reply-To: <003101d54396$a7f60010$f7e20030$@horizont-it.com> References: <003101d54396$a7f60010$f7e20030$@horizont-it.com> Message-ID: <877e84uf0g.wl-levitte@openssl.org> I have a branch where I've worked on such a thing. It's still work in progress, and I haven't looked at it for a while due to other things having priority, but I intend to get back to it. It won't be a straight port, as there are bits in there that are... ugly, especially the ad-hoc controls to fetch stuff that the ENGINE API doesn't have specific support for (certs and list of certs and whatever other stuff I forget). I'm replacing with support for the OSSL_STORE API, so those things can be fetched in a better supported manner. Cheers, Richard ( https://github.com/openssl/openssl/pull/3481 ) On Fri, 26 Jul 2019 11:44:01 +0200, HORIZONT, Armin Stauber wrote: > > > Hi, > > is there any plan or any current work to provide an engine for Cryptography API: Next Generation > (CNG) e.g. by porting the existing capi engine? > > Regards, > > Armin > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl at openssl.org Tue Jul 30 14:27:56 2019 From: openssl at openssl.org (OpenSSL) Date: Tue, 30 Jul 2019 14:27:56 +0000 Subject: OpenSSL Security Advisory Message-ID: <20190730142756.GA5502@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL Security Advisory [30 July 2019] ======================================== Windows builds with insecure path defaults (CVE-2019-1552) ========================================================== Severity: Low OpenSSL has internal defaults for a directory tree where it can find a configuration file as well as certificates used for verification in TLS. This directory is most commonly referred to as OPENSSLDIR, and is configurable with the --prefix / --openssldir configuration options. For OpenSSL versions 1.1.0 and 1.1.1, the mingw configuration targets assume that resulting programs and libraries are installed in a Unix-like environment and the default prefix for program installation as well as for OPENSSLDIR should be '/usr/local'. However, mingw programs are Windows programs, and as such, find themselves looking at sub-directories of 'C:/usr/local', which may be world writable, which enables untrusted users to modify OpenSSL's default configuration, insert CA certificates, modify (or even replace) existing engine modules, etc. For OpenSSL 1.0.2, '/usr/local/ssl' is used as default for OPENSSLDIR on all Unix and Windows targets, including Visual C builds. However, some build instructions for the diverse Windows targets on 1.0.2 encourage you to specify your own --prefix. OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time. The mitigations are found in these commits: - - For 1.1.1, commit 54aa9d51b09d67e90db443f682cface795f5af9e - - For 1.1.0, commit e32bc855a81a2d48d215c506bdeb4f598045f7e9 and b15a19c148384e73338aa7c5b12652138e35ed28 - - For 1.0.2, commit d333ebaf9c77332754a9d5e111e2f53e1de54fdd The 1.1.1 and 1.1.0 mitigation set more appropriate defaults for mingw, while the 1.0.2 mitigation documents the issue and provides enhanced examples. This issue was reported by Rich Mirth. The fix was developed by Richard Levitte from the OpenSSL development team. It was reported to OpenSSL on 9th Jun 2019. Note ===== OpenSSL 1.0.2 and 1.1.0 are currently only receiving security updates. Support for 1.0.2 will end on 31st December 2019. Support for 1.1.0 will end on 11th September 2019. Users of these versions should upgrade to OpenSSL 1.1.1. Referenses ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20190730.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAl1AU3sACgkQ1enkP335 7oxnEw//ebb9FK16oXpvW6nifNgSHUBYRaq+3ApvSfGG8Er1M0Zn80iD/WY8wzM7 ZabUUNlOdnOs0iQivMYzy+8QzP9NRaqX2WZk/Q1koNT5WAt9+VDCw6hhbp6FN8B9 9aeRvdawNME9JPysl3KOR6DnYJQnpJgV0yQ2pJM2yMKNuDFkvy6E9ieMoWAGx5Ya 8JZ4KGFubA1vDPj5xowkRDxZo+SLdAaEMQw0YG8DWSK5BViZV+3d4OMAAL1RjnZy s4OSghqi7wUbgo8XO38/roN4y4BEgmEXU0IpSRNf1xrwCoFM82hEgOO3xWxPtbZk EtDcMUTtMYa1g5IMdGIkVvS4wnNr2j2BAi8WECkPf5QCzCoaX/Xc9jutslTw20M/ UoZnyGgVoOQCsO6ECwLUnSEp772mhS1056c4OKb62kfhlIcGkWi5vk5wjWVZFxEx rXJC7xabp29e051mnrJtLr85UWUv5B/ywREPyvbdjWg6lJBxB0dOYXMQLpJi6B5i /bDX7czP/1EeOg+FDSGOR174JGIyMYmPqpyzGpdds72GfOQqtGHC2z41FlvHMglB 9VobSZnF97MIan4/9H4ge+gUUq0PeIZ+invvgCHzuW4oYBOngwwVD5QXfSQUjA9a etYHkJx+3t4hPrPKAT/J0jHA7AbWtYK7dL6qTxSwli2Gl/D4ipk= =gxli -----END PGP SIGNATURE----- From ben at benburrows.com Tue Jul 30 15:03:26 2019 From: ben at benburrows.com (Ben Burrows) Date: Tue, 30 Jul 2019 16:03:26 +0100 Subject: openssl hash value - how to generate ? Message-ID: <4576A48D-2461-406A-B07B-2544F850B68F@benburrows.com> Hi, I am trying to (independantly of openssl) generate the hash for a certificate (the short string that would be used as the symlink name in the openssl/certs directory). eg, this command openssl x509 -in CERT.pem -noout -hash I am trying to do this because I wanted to know how openssl was calculating this. At the bottom of the man page for x509 it states the following: The hash algorithm used in the -subject_hash and -issuer_hash options before OpenSSL 1.0.0 was based on the deprecated MD5 algorithm and the encoding of the distinguished name. In OpenSSL 1.0.0 and later it is based on a canonical version of the DN using SHA1. Thats a great start but not enough detail to let me generate this myself. Since I know the hash uses sha1 I should be able to generate the hash with "shasum" passing in the correct data. And there is the issue. All the conbinations of data I have passed in give me a different hash to what openssl generates. Its much longer but I beleive that is because openssl just chops everything past 8 chars off. Since the man page says its a hash of the DN (subject) I tried passing in the subject (in the various formats available from openssl) openssl x509 -noout -in CERT.pem -text | grep Subject: Subject: C=GB, O=My Company, OU=My Department, CN=MyName openssl x509 -in CERT.pem -noout -subject subject= /C=GB/O=My Company/OU=My Department/CN=MyName openssl x509 -in CERT.pem -noout -subject -nameopt RFC2253 subject= CN=MyName,OU=My Department,O=My Company,C=GB I then feed that into shasum like so (showing just one of the 6 combinations. I tried the subject for the three variations with and without the "subject= " or "Subject: " prefix) printf "CN=MyName,OU=My Department,O=My Company,C=GB" | shasum 6a73b8417b2f51195e1d0bcee3c2adbc1fb73124 - I tried looking at the code but I am not really a coder and definately not a C/C++ one and I was getting rather out of my depth trying to follow it. What I THINK my problem is is that the string that openssl is using as the input for the has is different to what I am using. Is there some way I can see what its using or am I going in the wrong direction here? Regards Ben From quanah at symas.com Tue Jul 30 15:49:53 2019 From: quanah at symas.com (Quanah Gibson-Mount) Date: Tue, 30 Jul 2019 08:49:53 -0700 Subject: CVE-2019-1552 clarification Message-ID: <08978ACE15B6B94EB4AC64B2@[192.168.1.39]> As someone who does build OpenSSL on windows, my gist is that if I use a non-default OPENSSLDIR I'm ok? Can someone confirm? Thanks! I.e., I use --openssldir=/opt/symas/ssl Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From matt at openssl.org Tue Jul 30 16:00:20 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 30 Jul 2019 17:00:20 +0100 Subject: CVE-2019-1552 clarification In-Reply-To: <08978ACE15B6B94EB4AC64B2@[192.168.1.39]> References: <08978ACE15B6B94EB4AC64B2@[192.168.1.39]> Message-ID: <07673a7c-33f9-a2f0-0034-42227f0ec718@openssl.org> On 30/07/2019 16:49, Quanah Gibson-Mount wrote: > As someone who does build OpenSSL on windows, my gist is that if I use a > non-default OPENSSLDIR I'm ok?? Can someone confirm?? Thanks! > > I.e., I use --openssldir=/opt/symas/ssl As long as your non-default location is suitably protected to stop untrusted users from making changes to config files/default engines etc, then you are fine. Matt From jb-openssl at wisemo.com Tue Jul 30 16:54:30 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 30 Jul 2019 18:54:30 +0200 Subject: OpenSSL Security Advisory In-Reply-To: <20190730142756.GA5502@openssl.org> References: <20190730142756.GA5502@openssl.org> Message-ID: <1c9162d5-9fdf-b3ba-4ef9-d72b1b4e9734@wisemo.com> Having reviewed the git commit for 1.1.1 I notice the following issue: The environment variables that usually point to the secure administrator directories (such as "Program Files") are not themselves secured, and not intended as a secure means of obtaining these directory locations, which are (by definition) subject to change via system configuration (initial or later!). There are official system library calls to obtain the actual locations as follows: 1. If looking for the location where a program is itself installed, use ? the GetModuleFilenameW(own-hinstance) call to obtain the path to once ? own DLL or EXE.? This automatically adapts to wherever the DLL or EXE ? is copied or moved.?? This is a kernel32.dll API and returns a location ? with security very close to that of the binary itself.The name ? returned is from the in-process instance of the dynamic linker. 2. If looking for the location where the running program's top level file ? (such as openssl.exe or some-program-loading-an-openssl-using-plugin.exe), ? use that same call but pass NULL for the hinstance parameter. 3. If looking for the system-wide secured "/etc" directory, use the ? GetSystemDirectoryW() call and append the fixed string "\\Drivers\\etc" . ? This location is permanently restricted to the system administrators and ? already contains a few traditional unix files such as "hosts". This too ? is a kernel32.dll API.? The name returned is from a system internal value ? set during OS boot. 4. If looking for the directory intended to hold system-wide configuration ? and data files, use the SHGetFolderPathW(CSIDL_COMMON_APPDATA) API from ? shfolder.dll or shell32.dll (fallback) to ask for the "all-users data ? directory", append a company/project name (such as "\\OpenSSL") and ? specify an appropriate ACL in the security argument to CreateDirectoryW() ? (if the directory doesn't already exist with a user-modified ACL, ? CreateDirectoryW will atomically detect this and return a specific error ? code in the per thread GetLastError() variable).Note that mkdir() ? only creates one level of directories per invocation and you may want ? different ACLs when creating missing parent directories.? The values ? returned by SHGetFolderPathW() are typically from one or more Administrator ? controlled registry keys. Some of the above APIs may require their return value to be canonicalized via the GetFullPathNameW() API in corner cases, retaining the result in a global variable is advisable. On 30/07/2019 16:27, OpenSSL wrote: > OpenSSL Security Advisory [30 July 2019] > ======================================== > > Windows builds with insecure path defaults (CVE-2019-1552) > ========================================================== > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 rsalz at akamai.com Tue Jul 30 17:12:44 2019 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 30 Jul 2019 17:12:44 +0000 Subject: openssl hash value - how to generate ? In-Reply-To: <4576A48D-2461-406A-B07B-2544F850B68F@benburrows.com> References: <4576A48D-2461-406A-B07B-2544F850B68F@benburrows.com> Message-ID: <70199809-0742-4CAA-8A93-3A20EE37C640@akamai.com> > At the bottom of the man page for x509 it states the following: The hash algorithm used in the -subject_hash and -issuer_hash options before OpenSSL 1.0.0 was based on the deprecated MD5 algorithm and the encoding of the distinguished name. In OpenSSL 1.0.0 and later it is based on a canonical version of the DN using SHA1. The text isn't great. In both cases the printed form is not what is used. Instead, by "canonical form" is meant the X.509 ASN1/DER encoding. Your guess -- "I think I'm using a different string" -- is correct. From kgoldman at us.ibm.com Wed Jul 31 20:47:54 2019 From: kgoldman at us.ibm.com (Ken Goldman) Date: Wed, 31 Jul 2019 16:47:54 -0400 Subject: Adding signature items to X509 certificate structure Message-ID: This use case is that I have an HSM that internally forms an X509 certificate and returns the signature. I have to reconstruct the X509 structure externally. I have everything but the signature and its algorithm. How can I programmatically set these values? What I do now is: - X509_ALGOR_set0() to set the x509->cert_info->signature and x509->sigalg members with OBJ_nid2obj(NID_sha256WithRSAEncryption) - free the x509->signature->data, malloc one of the right size, set x509->signature->length and memcpy the signature Is there a better way? It feels like this requires a lot peering inside structures, and I suspect it will need a rework for openssl 1.1.