From grace.priscilla at gmail.com Thu Feb 1 11:02:04 2018 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Thu, 1 Feb 2018 16:32:04 +0530 Subject: [openssl-users] DTLS multiple peer issue on shutdown Message-ID: Hi All, We are having a issue during ssl_shutdown using multiple clients. We have a 2 SSL associated with a socket via 2 BIO's for 2 peers on the server. When oen of the peer issues a ssl_shutdown, the alert is lost as the SSL_read or the SSL_peek operating during that time for the other peer does not return 0. Is there a way to resolve this issue? Thanks, Grace -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Feb 1 13:13:15 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 1 Feb 2018 13:13:15 +0000 Subject: [openssl-users] DTLS multiple peer issue on shutdown In-Reply-To: References: Message-ID: <18022718-AE9E-41DC-BC5E-9CE77C1F4CC5@akamai.com> Two SSL objects sharing the same socket? That doesn?t work. Or did you mean something else? -------------- next part -------------- An HTML attachment was scrubbed... URL: From grace.priscilla at gmail.com Thu Feb 1 14:16:30 2018 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Thu, 1 Feb 2018 19:46:30 +0530 Subject: [openssl-users] DTLS multiple peer issue on shutdown In-Reply-To: <18022718-AE9E-41DC-BC5E-9CE77C1F4CC5@akamai.com> References: <18022718-AE9E-41DC-BC5E-9CE77C1F4CC5@akamai.com> Message-ID: Hi Rich, We are using DTLS over UDP and are using different SSL(different peer) for the same server socket. It is successfully able to receive the message from both peers without any issue with the different SSL. We have used the peer ports as the identifier for the peers. But during shutdown we are facing issue as the alert is being issued is not processed at server as the SSL_peek or SSL_read does not return zero. Thanks, Grace On Thu, Feb 1, 2018 at 6:43 PM, Salz, Rich via openssl-users < openssl-users at openssl.org> wrote: > Two SSL objects sharing the same socket? That doesn?t work. Or did you > mean something else? > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Feb 1 15:35:05 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 1 Feb 2018 15:35:05 +0000 Subject: [openssl-users] DTLS multiple peer issue on shutdown In-Reply-To: References: <18022718-AE9E-41DC-BC5E-9CE77C1F4CC5@akamai.com> Message-ID: Doesn?t shutdown close the socket? -------------- next part -------------- An HTML attachment was scrubbed... URL: From grace.priscilla at gmail.com Thu Feb 1 18:34:35 2018 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Fri, 2 Feb 2018 00:04:35 +0530 Subject: [openssl-users] DTLS multiple peer issue on shutdown In-Reply-To: References: <18022718-AE9E-41DC-BC5E-9CE77C1F4CC5@akamai.com> Message-ID: The shutdown does not close the socket. The peer close is not intimated to server when there are 2 peers to the server and the server is serving the other peer. Thanks, Grace On Thu, Feb 1, 2018 at 9:05 PM, Salz, Rich wrote: > Doesn?t shutdown close the socket? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Feb 1 18:35:24 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 1 Feb 2018 18:35:24 +0000 Subject: [openssl-users] DTLS multiple peer issue on shutdown In-Reply-To: References: <18022718-AE9E-41DC-BC5E-9CE77C1F4CC5@akamai.com> Message-ID: Sorry, then, I?ve exhausted my knowledge-base. Hopefully others will have more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roushan.ara at skanray.com Fri Feb 2 04:42:10 2018 From: roushan.ara at skanray.com (Roushan Ara) Date: Fri, 2 Feb 2018 10:12:10 +0530 Subject: [openssl-users] usage of SSL_read() and SSL_write() for file transfer Message-ID: Hi All, currently i am using openssl for client and server communication for file transfer. i am facing some issue regarding the writing the content of file.my requirement is i have to send the whole content of some specified file to server for that i am using SSL_write(). i can achieve this using SSL_write() in a while loop but my requirement is i have to use single SSL_write() for sending whole content of file and single SSL_read at the server to receive the whole content of the file.because in that message itself we have to specify some id so that it can be identified at the server to indicate that it is file reading. so i need to send single message with full content of file in a buffer. because of the maximum limitation of SSL_write() we are not able to send more than 16384 bytes. Could somebody suggest s how can i use SSL_write() for the writing the whole content of text file in a single message without using any while loop. Thanks in Advance. Thanks & Regards, Roushan Ara -- -- *Please consider the Environment before printing this e-mail.* The information contained in this message (including any attachments) is confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately by return e-mail and permanently delete this message and any attachments from your system. Any dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. *SKANRAY* *(including its group of companies) shall not be liable for any omission or error in the message, improper or incomplete transmission of the information contained in this communication or for any delay in its receipt or damage to your system. * *SKANRAY* *(or its group of companies) does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interference.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Feb 2 04:56:37 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 1 Feb 2018 23:56:37 -0500 Subject: [openssl-users] usage of SSL_read() and SSL_write() for file transfer In-Reply-To: References: Message-ID: <02B15DAF-D23D-4F1E-8595-EE7A5BC7D9B7@dukhovni.org> > On Feb 1, 2018, at 11:42 PM, Roushan Ara wrote: > > currently i am using openssl for client and server communication for file transfer. i am facing some issue regarding the writing the content of file.my requirement is i have to send the whole content of some specified file to server for that i am using SSL_write(). i can achieve this using SSL_write() in a while loop but my requirement is i have to use single SSL_write() for sending whole content of file and single SSL_read at the server to receive the whole content of the file.because in that message itself we have to specify some id so that it can be identified at the server to indicate that it is file reading. so i need to send single message with full content of file in a buffer. because of the maximum limitation of SSL_write() we are not able to send more than 16384 bytes. > Could somebody suggest s how can i use SSL_write() for the writing the whole content of text file in a single message without using any while loop. Your simplest solution is to use HTTP POST over SSL to create the illusion of a single message layered over a underlying reliable bytestream. Don't write your own code, consider using libcurl or an HTTPS library that best meets your needs. -- Viktor. From roushan.ara at skanray.com Fri Feb 2 06:40:45 2018 From: roushan.ara at skanray.com (Roushan Ara) Date: Fri, 2 Feb 2018 12:10:45 +0530 Subject: [openssl-users] openssl-users Digest, Vol 39, Issue 2 In-Reply-To: References: Message-ID: currently i am using socket for this implementation in c++ programming. can i use HTTPS post over SSL in c++. need suggestion Thanks & Regards, Roushan Ara On Fri, Feb 2, 2018 at 10:26 AM, wrote: > Send openssl-users mailing list submissions to > openssl-users at openssl.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mta.openssl.org/mailman/listinfo/openssl-users > or, via email, send a message with subject or body 'help' to > openssl-users-request at openssl.org > > You can reach the person managing the list at > openssl-users-owner at openssl.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openssl-users digest..." > > > Today's Topics: > > 1. Re: DTLS multiple peer issue on shutdown (Salz, Rich) > 2. Re: DTLS multiple peer issue on shutdown (Grace Priscilla Jero) > 3. Re: DTLS multiple peer issue on shutdown (Salz, Rich) > 4. usage of SSL_read() and SSL_write() for file transfer > (Roushan Ara) > 5. Re: usage of SSL_read() and SSL_write() for file transfer > (Viktor Dukhovni) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 1 Feb 2018 15:35:05 +0000 > From: "Salz, Rich" > To: Grace Priscilla Jero , > "openssl-users at openssl.org" > Subject: Re: [openssl-users] DTLS multiple peer issue on shutdown > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Doesn?t shutdown close the socket? > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20180201/ef74f6f7/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Fri, 2 Feb 2018 00:04:35 +0530 > From: Grace Priscilla Jero > To: "Salz, Rich" > Cc: "openssl-users at openssl.org" > Subject: Re: [openssl-users] DTLS multiple peer issue on shutdown > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > The shutdown does not close the socket. The peer close is not intimated to > server when there are 2 peers to the server and the server is serving the > other peer. > > Thanks, > Grace > On Thu, Feb 1, 2018 at 9:05 PM, Salz, Rich wrote: > > > Doesn?t shutdown close the socket? > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20180202/6098fe2d/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Thu, 1 Feb 2018 18:35:24 +0000 > From: "Salz, Rich" > To: Grace Priscilla Jero > Cc: "openssl-users at openssl.org" > Subject: Re: [openssl-users] DTLS multiple peer issue on shutdown > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Sorry, then, I?ve exhausted my knowledge-base. Hopefully others will have > more. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20180201/b9fc857d/attachment-0001.html> > > ------------------------------ > > Message: 4 > Date: Fri, 2 Feb 2018 10:12:10 +0530 > From: Roushan Ara > To: openssl-users at openssl.org > Subject: [openssl-users] usage of SSL_read() and SSL_write() for file > transfer > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi All, > currently i am using openssl for client and server communication for file > transfer. i am facing some issue regarding the writing the content of > file.my requirement is i have to send the whole content of some specified > file to server for that i am using SSL_write(). i can achieve this using > SSL_write() in a while loop but my requirement is i have to use single > SSL_write() for sending whole content of file and single SSL_read at the > server to receive the whole content of the file.because in that message > itself we have to specify some id so that it can be identified at the > server to indicate that it is file reading. so i need to send single > message with full content of file in a buffer. because of the maximum > limitation of SSL_write() we are not able to send more than 16384 bytes. > Could somebody suggest s how can i use SSL_write() for the writing the > whole content of text file in a single message without using any while > loop. > > Thanks in Advance. > > > Thanks & Regards, > Roushan Ara > > -- > > > -- > *Please consider the Environment before printing this e-mail.* > > The information contained in this message (including any attachments) is > confidential and may be privileged or otherwise protected from disclosure. > If you are not the intended recipient, you must not copy this message or > attachment or disclose the contents to any other person. If you have > received this transmission in error, please notify the sender immediately > by return e-mail and permanently delete this message and any attachments > from your system. Any dissemination, use, review, distribution, printing > or copying of this message in whole or in part is strictly prohibited. > Please note that e-mails are susceptible to change. > > *SKANRAY* *(including its group of companies) > shall > not be liable for any omission or error in the message, improper or > incomplete transmission of the information contained in this communication > or for any delay in its receipt or damage to your system. * *SKANRAY* > *(or its group of companies) does not guarantee > that the integrity of this communication has been maintained or that this > communication is free of viruses, interceptions or interference.* > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20180202/5c885cfa/attachment-0001.html> > > ------------------------------ > > Message: 5 > Date: Thu, 1 Feb 2018 23:56:37 -0500 > From: Viktor Dukhovni > To: "openssl-users at openssl.org" > Subject: Re: [openssl-users] usage of SSL_read() and SSL_write() for > file transfer > Message-ID: <02B15DAF-D23D-4F1E-8595-EE7A5BC7D9B7 at dukhovni.org> > Content-Type: text/plain; charset=us-ascii > > > > > On Feb 1, 2018, at 11:42 PM, Roushan Ara > wrote: > > > > currently i am using openssl for client and server communication for > file transfer. i am facing some issue regarding the writing the content of > file.my requirement is i have to send the whole content of some specified > file to server for that i am using SSL_write(). i can achieve this using > SSL_write() in a while loop but my requirement is i have to use single > SSL_write() for sending whole content of file and single SSL_read at the > server to receive the whole content of the file.because in that message > itself we have to specify some id so that it can be identified at the > server to indicate that it is file reading. so i need to send single > message with full content of file in a buffer. because of the maximum > limitation of SSL_write() we are not able to send more than 16384 bytes. > > Could somebody suggest s how can i use SSL_write() for the writing the > whole content of text file in a single message without using any while loop. > > Your simplest solution is to use HTTP POST over SSL to create the > illusion of a single message layered over a underlying reliable > bytestream. Don't write your own code, consider using libcurl > or an HTTPS library that best meets your needs. > > -- > Viktor. > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openssl-users mailing list > openssl-users at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-users > > > ------------------------------ > > End of openssl-users Digest, Vol 39, Issue 2 > ******************************************** > -- -- *Please consider the Environment before printing this e-mail.* The information contained in this message (including any attachments) is confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately by return e-mail and permanently delete this message and any attachments from your system. Any dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. *SKANRAY* *(including its group of companies) shall not be liable for any omission or error in the message, improper or incomplete transmission of the information contained in this communication or for any delay in its receipt or damage to your system. * *SKANRAY* *(or its group of companies) does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interference.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ManWag at FastMail.FM Fri Feb 2 09:12:18 2018 From: ManWag at FastMail.FM (Manuel Wagesreither) Date: Fri, 02 Feb 2018 10:12:18 +0100 Subject: [openssl-users] Certificate gets verified OK over SSL-CLI, but not when using SSL-API In-Reply-To: <51C83EC8-391D-4E6D-95A9-EC4AAB897F25@dukhovni.org> References: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com> <753F1A56-7CB1-46B5-A2CE-91FE21D564B4@dukhovni.org> <1514454882.736235.1217696856.0B3122EB@webmail.messagingengine.com> <51C83EC8-391D-4E6D-95A9-EC4AAB897F25@dukhovni.org> Message-ID: <1517562738.937222.1256975488.50CA9697@webmail.messagingengine.com> Dear Viktor, that's quite an detailed elaboration. I have learned something from what you posted, but as far as this problem is concerned, we we're able to get rid of your problems by upgrading to OpenSSL 1.1.0g. I'm sure what you conveyed will be of help when diagnosing future OpenSSL problems, which, I have no doubt, will arise sooner or later. Thank you for your help! Manuel From ManWag at FastMail.FM Fri Feb 2 09:02:55 2018 From: ManWag at FastMail.FM (Manuel Wagesreither) Date: Fri, 02 Feb 2018 10:02:55 +0100 Subject: [openssl-users] [EXTERNAL] Certificate gets verified OK over SSL-CLI, but not when using SSL-API In-Reply-To: References: <1513856572.130619.1212239248.420C2206@webmail.messagingengine.com> <1513880829.15053.34.camel@sandia.gov> <1513937675.1354421.1213293648.5213F617@webmail.messagingengine.com> <1513971095.15053.36.camel@sandia.gov> <1514456342.741665.1217709496.408EB4A2@webmail.messagingengine.com> Message-ID: <1517562175.934259.1256957712.1032F4F2@webmail.messagingengine.com> > > Hence, if at all, verification requirements must have been lowered in the new OpenSSL version. > > No, it is also the case that the new version now more correctly accepts > some chains as valid that because of bugs, the old version did not. Understood! My reply was related to message only, as I was afraid he might have mistook the problem description. Hence, I wanted to clarify this. I have taken your advice to upgrade to OpenSSL 1.1.0 seriously and did accordingly. We are now using OpenSSL 1.1.0g and everything seems to be doing fine so far. This matter can thus be regarded as solved. Thanks to everyone who contributed! Best regards, Manuel From rsalz at akamai.com Fri Feb 2 13:33:56 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 2 Feb 2018 13:33:56 +0000 Subject: [openssl-users] usage of SSL_read() and SSL_write() for file transfer In-Reply-To: References: Message-ID: <3A3CEA4F-4C1B-4DB7-98C4-CA5455428FB0@akamai.com> The TLS protocol puts limits on how much application data can appear in a single record. Without knowing all the details, that seems like a very silly requirement. There is no security reason for it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Zeke.Evans at microfocus.com Fri Feb 2 22:07:07 2018 From: Zeke.Evans at microfocus.com (Zeke Evans) Date: Fri, 2 Feb 2018 22:07:07 +0000 Subject: [openssl-users] FIPS 140-2 key wrapping transition Message-ID: Hi, NIST recently gave notice of Symmetric Key Wrapping Transition, details are found here https://csrc.nist.gov/projects/cryptographic-module-validation-program/notices. It is not clear to me whether the FIPS 2.0 module is affected by this. I am mostly curious about this part: All validations on the Active Validation List that implement the previously allowed AES or TDEA key wrapping: * Entries will be moved to the Historical List. Can someone verify whether the FIPS 2.0 validation is affected by this? Thanks, Zeke Evans Senior Software Engineer Micro Focus -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sat Feb 3 00:25:35 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 3 Feb 2018 00:25:35 +0000 Subject: [openssl-users] FIPS 140-2 key wrapping transition Message-ID: The OpenSSL FIPS Validation #1747 is affected by the key wrapping transition and will therefore be moved to Historical at some point. As we?ve said, FIPS will be the focus of our next feature release after 1.1.1 (TLS 1.3). -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at activecrypt.com Sat Feb 3 08:13:58 2018 From: alex at activecrypt.com (Alex Dankow) Date: Sat, 3 Feb 2018 15:13:58 +0700 Subject: [openssl-users] Low level AES alternative in FIPS-140 OpenSSL Message-ID: <144-1724575826.20180203151358@activecrypt.com> Greetings! You probably know that low level AES function AES_set_encrypt_key is disabled in FIPS 140-2 module. Instead it is offered to use EVP_ set of functions. We develop transparent database encryption for SQL Server and performance is very important issue. AES CTR requires very frequent changes of IV and I can't find a way to set it other than EVP_CipherInit. Initialization, however, relatively high time-consuming operation. Question: Is there a way to set IV for CTX after its initialization for FIPS version of OpenSSL? -- Best regards, Alex Dankow alex at activecrypt.com ActiveCrypt Software From sja at brightstareng.com Sat Feb 3 13:19:11 2018 From: sja at brightstareng.com (Stuart Adams) Date: Sat, 3 Feb 2018 08:19:11 -0500 Subject: [openssl-users] Bug in ECDSA_verify / i2d_ECDSA_SIG ?? Message-ID: ECDSA_verify fails if one of the signature components is negative because i2d_ECDSA_SIG returns the incorrect size; problem is in ecs_vrf.c: derlen = i2d_ECDSA_SIG(s, &der); if (derlen != sig_len || memcmp(sigbuf, der, derlen)) goto err; If signature component is negative derlen is computed as 71 instead of 70. So I get "Public Key operation error" ... but if I comment out the length check I get "Signature Verified Successfully" Here is the parse of the signature file. openssl asn1parse -i -inform DER -in file -in pub.sig 0:d=0 hl=2 l= 68 cons: SEQUENCE 2:d=1 hl=2 l= 32 prim: INTEGER : 4C5A2B4F5DF1540481A1B07A7A6007284AD69C654AA12863A4B9728B1179D0CB 36:d=1 hl=2 l= 32 prim: INTEGER :- 37D6425BDFF8E68263205D4DD798AE816B127B439AE29161662B23D15D773C7D od -t x1 pub.sig 0000000 30 44 02 20 4c 5a 2b 4f 5d f1 54 04 81 a1 b0 7a 0000020 7a 60 07 28 4a d6 9c 65 4a a1 28 63 a4 b9 72 8b 0000040 11 79 d0 cb 02 20 c8 29 bd a4 20 07 19 7d 9c df 0000060 a2 b2 28 67 51 7e 94 ed 84 bc 65 1d 6e 9e 99 d4 0000100 dc 2e a2 88 c3 83 0000106 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sat Feb 3 14:19:04 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 3 Feb 2018 14:19:04 +0000 Subject: [openssl-users] Low level AES alternative in FIPS-140 OpenSSL In-Reply-To: <144-1724575826.20180203151358@activecrypt.com> References: <144-1724575826.20180203151358@activecrypt.com> Message-ID: <2F0424B3-90FA-47D3-87A3-977576469E20@akamai.com> ? Question: Is there a way to set IV for CTX after its initialization for FIPS version of OpenSSL? No, sorry. From indunil.uom at gmail.com Mon Feb 5 02:22:17 2018 From: indunil.uom at gmail.com (Indunil Rathnayake) Date: Mon, 5 Feb 2018 07:52:17 +0530 Subject: [openssl-users] Key Usage and Extended Key Usage certificate extension values should be required in client authentication Message-ID: Hi all, Anyone knows in client authentication, what are the Key Usage and Extended Key Usage purposes we should validate? As per the specification in [1]: - "Extended Key Usage" is not necessary and which is configured in addition to or in place of the basic purposes indicated in the key usage extension. - "clientAuth" which can be configure as "Extended Key Usage", and Key usage bits that may be consistent for that is "digitalSignature" and/or "keyAgreement" But when validating, what are the key usage purposes that should be allowed and disallowed for client authentication? [1] https://tools.ietf.org/html/rfc5280#section-4.2.1.12 Thanks and Regards -- *Indunil Rathnayake * *Faculty of Information Technology* *University of Moratuwa.* Email : *indunil.uom at gmail.com * | Skype: indu.upeksha | Mobile : (+94)713695179 | Twitter @indunilUR | LinkedIn: http://lk.linkedin.com/in/indunil | Facebook : https://www.facebook.com/indunilrathnayake80 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at splintermail.com Mon Feb 5 04:01:59 2018 From: ryan at splintermail.com (Ryan Beethe) Date: Sun, 4 Feb 2018 22:01:59 -0600 Subject: [openssl-users] BIO_do_connect memory leak in Arch Linux Message-ID: <20180205041009.2F7F8E7AEB@mta.openssl.org> Hi openssl-users, I found a memory leak in my program that arises from the use of the BIO_do_connect() function. It seems to be related to how openssl is interacting with other packages on my system. I observe this behavior on my Arch Linux machine but not on my Debian Stretch machine. I wrote a minimal program that demonstrates the issue and attached the output of valgrind of the same program. The leak goes away if I comment out the BIO_do_connect() line, and based on the output of valgrind the issue seems to have something to do with the DNS resolving step. I noticed using strace that on Arch Linux the same binary running on Arch Linux loads two libraries that don't get loaded when running on Debian Stretch: "libnss_mymachines.so.2" and "libnss_resolve.so.2". Am I doing something wrong or is this a memory leak in openssl? Thanks, Ryan ------- leak.c: a minimal example program leak.c // # compile with gcc 7.2.1: // gcc -Wall -g -std=c99 -pedantic leak.c -lssl -lcrypto -o leak #include #include int main(){ // unencrypted connection BIO* bio = BIO_new_connect("smtp.gmail.com:587"); // connect BIO BIO_do_connect(bio); // read some stuff char buffer[1024]; int ret = BIO_read(bio, buffer, 1024 - 1); printf("read %d bytes:\n",ret); fwrite(buffer, 1, ret, stdout); BIO_free_all(bio); printf("exiting\n"); return 0; } ---------- output of: valgrind --show-leak-kinds=all --leak-check=full ./leak ==6700== Memcheck, a memory error detector ==6700== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==6700== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==6700== Command: ./leak ==6700== read 52 bytes: 220 smtp.gmail.com ESMTP d26sm175472lja.54 - gsmtp exiting ==6700== ==6700== HEAP SUMMARY: ==6700== in use at exit: 7,365 bytes in 10 blocks ==6700== total heap usage: 148 allocs, 138 frees, 118,960 bytes allocated ==6700== ==6700== 48 bytes in 1 blocks are still reachable in loss record 1 of 6 ==6700== at 0x4C2CEDF: malloc (vg_replace_malloc.c:299) ==6700== by 0x4011D85: tls_get_addr_tail (in /usr/lib/ld-2.26.so) ==6700== by 0x4017447: __tls_get_addr (in /usr/lib/ld-2.26.so) ==6700== by 0x65BBD1D: ??? (in /usr/lib/libnss_resolve.so.2) ==6700== by 0x65D7711: ??? (in /usr/lib/libnss_resolve.so.2) ==6700== by 0x65CE60C: _nss_resolve_gethostbyname4_r (in /usr/lib/libnss_resolve.so.2) ==6700== by 0x566DFD8: gaih_inet.constprop.7 (in /usr/lib/libc-2.26.so) ==6700== by 0x566EF03: getaddrinfo (in /usr/lib/libc-2.26.so) ==6700== by 0x517160D: BIO_lookup_ex (b_addr.c:691) ==6700== by 0x51716CD: BIO_lookup (b_addr.c:614) ==6700== by 0x517C8BD: conn_state (bss_conn.c:123) ==6700== by 0x517C8BD: conn_ctrl (bss_conn.c:360) ==6700== by 0x5178F73: BIO_ctrl (bio_lib.c:529) ==6700== ==6700== 61 bytes in 2 blocks are still reachable in loss record 2 of 6 ==6700== at 0x4C2CEDF: malloc (vg_replace_malloc.c:299) ==6700== by 0x401AB9A: strdup (in /usr/lib/ld-2.26.so) ==6700== by 0x40162EF: _dl_load_cache_lookup (in /usr/lib/ld-2.26.so) ==6700== by 0x40089D1: _dl_map_object (in /usr/lib/ld-2.26.so) ==6700== by 0x401377D: dl_open_worker (in /usr/lib/ld-2.26.so) ==6700== by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so) ==6700== by 0x4013279: _dl_open (in /usr/lib/ld-2.26.so) ==6700== by 0x56BF10C: do_dlopen (in /usr/lib/libc-2.26.so) ==6700== by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so) ==6700== by 0x56BF1A6: dlerror_run (in /usr/lib/libc-2.26.so) ==6700== by 0x56BF240: __libc_dlopen_mode (in /usr/lib/libc-2.26.so) ==6700== by 0x56A6978: nss_load_library (in /usr/lib/libc-2.26.so) ==6700== ==6700== 61 bytes in 2 blocks are still reachable in loss record 3 of 6 ==6700== at 0x4C2CEDF: malloc (vg_replace_malloc.c:299) ==6700== by 0x400B468: _dl_new_object (in /usr/lib/ld-2.26.so) ==6700== by 0x4005984: _dl_map_object_from_fd (in /usr/lib/ld-2.26.so) ==6700== by 0x40086B0: _dl_map_object (in /usr/lib/ld-2.26.so) ==6700== by 0x401377D: dl_open_worker (in /usr/lib/ld-2.26.so) ==6700== by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so) ==6700== by 0x4013279: _dl_open (in /usr/lib/ld-2.26.so) ==6700== by 0x56BF10C: do_dlopen (in /usr/lib/libc-2.26.so) ==6700== by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so) ==6700== by 0x56BF1A6: dlerror_run (in /usr/lib/libc-2.26.so) ==6700== by 0x56BF240: __libc_dlopen_mode (in /usr/lib/libc-2.26.so) ==6700== by 0x56A6978: nss_load_library (in /usr/lib/libc-2.26.so) ==6700== ==6700== 720 bytes in 2 blocks are still reachable in loss record 4 of 6 ==6700== at 0x4C2EEF5: calloc (vg_replace_malloc.c:711) ==6700== by 0x4010F03: _dl_check_map_versions (in /usr/lib/ld-2.26.so) ==6700== by 0x4013822: dl_open_worker (in /usr/lib/ld-2.26.so) ==6700== by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so) ==6700== by 0x4013279: _dl_open (in /usr/lib/ld-2.26.so) ==6700== by 0x56BF10C: do_dlopen (in /usr/lib/libc-2.26.so) ==6700== by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so) ==6700== by 0x56BF1A6: dlerror_run (in /usr/lib/libc-2.26.so) ==6700== by 0x56BF240: __libc_dlopen_mode (in /usr/lib/libc-2.26.so) ==6700== by 0x56A6978: nss_load_library (in /usr/lib/libc-2.26.so) ==6700== by 0x56A71E8: __nss_lookup_function (in /usr/lib/libc-2.26.so) ==6700== by 0x566DF76: gaih_inet.constprop.7 (in /usr/lib/libc-2.26.so) ==6700== ==6700== 2,379 bytes in 2 blocks are still reachable in loss record 5 of 6 ==6700== at 0x4C2EEF5: calloc (vg_replace_malloc.c:711) ==6700== by 0x400B181: _dl_new_object (in /usr/lib/ld-2.26.so) ==6700== by 0x4005984: _dl_map_object_from_fd (in /usr/lib/ld-2.26.so) ==6700== by 0x40086B0: _dl_map_object (in /usr/lib/ld-2.26.so) ==6700== by 0x401377D: dl_open_worker (in /usr/lib/ld-2.26.so) ==6700== by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so) ==6700== by 0x4013279: _dl_open (in /usr/lib/ld-2.26.so) ==6700== by 0x56BF10C: do_dlopen (in /usr/lib/libc-2.26.so) ==6700== by 0x56BFB63: _dl_catch_error (in /usr/lib/libc-2.26.so) ==6700== by 0x56BF1A6: dlerror_run (in /usr/lib/libc-2.26.so) ==6700== by 0x56BF240: __libc_dlopen_mode (in /usr/lib/libc-2.26.so) ==6700== by 0x56A6978: nss_load_library (in /usr/lib/libc-2.26.so) ==6700== ==6700== 4,096 bytes in 1 blocks are still reachable in loss record 6 of 6 ==6700== at 0x4C2CEDF: malloc (vg_replace_malloc.c:299) ==6700== by 0x65BBF48: ??? (in /usr/lib/libnss_resolve.so.2) ==6700== by 0x65D7711: ??? (in /usr/lib/libnss_resolve.so.2) ==6700== by 0x65CE60C: _nss_resolve_gethostbyname4_r (in /usr/lib/libnss_resolve.so.2) ==6700== by 0x566DFD8: gaih_inet.constprop.7 (in /usr/lib/libc-2.26.so) ==6700== by 0x566EF03: getaddrinfo (in /usr/lib/libc-2.26.so) ==6700== by 0x517160D: BIO_lookup_ex (b_addr.c:691) ==6700== by 0x51716CD: BIO_lookup (b_addr.c:614) ==6700== by 0x517C8BD: conn_state (bss_conn.c:123) ==6700== by 0x517C8BD: conn_ctrl (bss_conn.c:360) ==6700== by 0x5178F73: BIO_ctrl (bio_lib.c:529) ==6700== by 0x108954: main (leak.c:17) ==6700== ==6700== LEAK SUMMARY: ==6700== definitely lost: 0 bytes in 0 blocks ==6700== indirectly lost: 0 bytes in 0 blocks ==6700== possibly lost: 0 bytes in 0 blocks ==6700== still reachable: 7,365 bytes in 10 blocks ==6700== suppressed: 0 bytes in 0 blocks ==6700== ==6700== For counts of detected and suppressed errors, rerun with: -v ==6700== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) From rsalz at akamai.com Mon Feb 5 04:17:31 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 5 Feb 2018 04:17:31 +0000 Subject: [openssl-users] BIO_do_connect memory leak in Arch Linux In-Reply-To: <20180205041009.2F7F8E7AEB@mta.openssl.org> References: <20180205041009.2F7F8E7AEB@mta.openssl.org> Message-ID: <60E10E38-C129-4CCB-B25E-83A34EEA0660@akamai.com> It appears to be a memory leak in the DNS libraries. From matt at openssl.org Mon Feb 5 11:03:25 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 5 Feb 2018 11:03:25 +0000 Subject: [openssl-users] Low level AES alternative in FIPS-140 OpenSSL In-Reply-To: <144-1724575826.20180203151358@activecrypt.com> References: <144-1724575826.20180203151358@activecrypt.com> Message-ID: <2579d87b-a58e-1d46-b7e4-2bfb568c2197@openssl.org> On 03/02/18 08:13, Alex Dankow via openssl-users wrote: > Greetings! > > You probably know that low level AES function AES_set_encrypt_key is > disabled in FIPS 140-2 module. Instead it is offered to use EVP_ > set of functions. > > We develop transparent database encryption for SQL Server and > performance is very important issue. AES CTR requires very frequent > changes of IV and I can't find a way to set it other than > EVP_CipherInit. Initialization, however, relatively high time-consuming operation. You can call EVP_CipherInit again but with a NULL key parameter to only update the IV and not the key. Hopefully this should be less time-consuming. Matt From knoulis.tuc at gmail.com Mon Feb 5 13:51:12 2018 From: knoulis.tuc at gmail.com (=?UTF-8?B?zprPic69z4PPhM6xzr3PhM6vzr3Ov8+CIM6dzr/Pjc67zrfPgg==?=) Date: Mon, 5 Feb 2018 15:51:12 +0200 Subject: [openssl-users] Build OpenSSL for Android in MAC Message-ID: Hello all, I would like to compile openssl (libcrypto and libssl) and use it within my android app as an external library with NDK. My development machine is a MAC. I have read the instructions in the wiki, but apparently they are for an older version of openssl and linux systems. Is there a newer version of instructions i can follow? Thanks in advance, Kostas -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcr at sandelman.ca Mon Feb 5 17:34:58 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 05 Feb 2018 12:34:58 -0500 Subject: [openssl-users] OPENSSL_USE_IPV6 -- bio_dgram, vs travis-ci In-Reply-To: References: Message-ID: <11282.1517852098@obiwan.sandelman.ca> bio_dgram has a bunch of #if on: OPENSSL_USE_IPV6, and I thought that this might be a common #ifdef, but actually it only occurs in that file. I looked through Configurations, and I didn't see it at all. Other usage is #ifdef AF_INET6, but IPv6 code is available, but I want to build without it. Fundamentally, I want to turn off IPv6 testing off on travis builds, because travis has IPv6 turned off, see: https://github.com/travis-ci/travis-ci/issues/4964 https://github.com/travis-ci/travis-ci/issues/3302 You can't even bind ::1 on travis. I hate this jurassic stuff. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From grace.priscilla at gmail.com Wed Feb 7 09:06:38 2018 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Wed, 7 Feb 2018 14:36:38 +0530 Subject: [openssl-users] DTLS multiple peer issue on shutdown In-Reply-To: References: <18022718-AE9E-41DC-BC5E-9CE77C1F4CC5@akamai.com> Message-ID: Hi All, Can someone assist from openssl on this issue. To be more elaborate: We are using SSL_peek followed by BIO_dgram_get_peer to get the peer port infomation. When we pass incorrect ssl value to SSL_peek it gives the correct peer information while using BIO_dgram_get_peer but any operation after this on SSL_peek always returns -1 with errno 11 set. Even though the right SSL is given in the subsequent call. Any help is appreciated. Thanks, Grace On Fri, Feb 2, 2018 at 12:05 AM, Salz, Rich wrote: > Sorry, then, I?ve exhausted my knowledge-base. Hopefully others will have > more. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From myang2012 at gmail.com Wed Feb 7 23:43:50 2018 From: myang2012 at gmail.com (Mingtao Yang) Date: Wed, 7 Feb 2018 15:43:50 -0800 Subject: [openssl-users] Custom X509_LOOKUP_METHOD in OpenSSL 1.1 Message-ID: OpenSSL 1.1 made the X509_LOOKUP_METHOD structure opaque. I am currently working on migrating an application to use OpenSSL 1.1 APIs, but the application implements a custom get_by_subject method, which I cannot implement in 1.1.0 because there is no mechanism for creating custom X509_LOOKUP_METHODs. Would OpenSSL be opposed to having public APIs for setting these function pointers in X509_LOOKUP_METHOD? (Similar to how BIO methods have public setter APIs: https://www.openssl.org/docs/man1.1.0/crypto/BIO_meth_new.html) Thanks! -Ming -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Feb 7 23:59:34 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 7 Feb 2018 23:59:34 +0000 Subject: [openssl-users] Custom X509_LOOKUP_METHOD in OpenSSL 1.1 In-Reply-To: References: Message-ID: <8F810AB3-E86A-400A-980D-A35EDE90560F@akamai.com> Yes, if there?s something that was made impossible to do because of things being made opaque, adding the missing API?s would be a bugfix and go into 1.1.0 and beyond. It woud be great if you could create a PR. -------------- next part -------------- An HTML attachment was scrubbed... URL: From BYan at visa.com Thu Feb 8 00:43:22 2018 From: BYan at visa.com (Yan, Bob) Date: Thu, 8 Feb 2018 00:43:22 +0000 Subject: [openssl-users] Lock for SSL_accept method Message-ID: Hi All, I used a mutex lock to prevent the SSL_accept() method being called by multiple thread concurrently since it may get coredump if there is no lock on SSL_accept() method. I am just wondering is the lock is still needed for openssl 1.0.2e version? mutex.lock(); int rt = SSL_accept(SslSessionObject); mutex.unlock(); Thank you very much! Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From remy at lebeausoftware.org Thu Feb 8 02:06:50 2018 From: remy at lebeausoftware.org (Remy Lebeau) Date: Wed, 7 Feb 2018 18:06:50 -0800 Subject: [openssl-users] Custom X509_LOOKUP_METHOD in OpenSSL 1.1 In-Reply-To: <8F810AB3-E86A-400A-980D-A35EDE90560F@akamai.com> References: <8F810AB3-E86A-400A-980D-A35EDE90560F@akamai.com> Message-ID: <0ed28184-d14a-5455-1958-640350b8192f@lebeausoftware.org> I would definitely need something like this.? I have some library code that uses OpenSSL 1.0.2 (can't upgrade to 1.1.x yet because of all the interface changes), and it currently has to use a custom X509_LOOKUP_METHOD to handle Unicode filenames on Windows (in fact, this library had to completely replace several OpenSSL functions in order to work with Unicode filenames for things like certificate files, key files, etc). It would be REALLY REALLY nice if OpenSSL worked with Unicode filenames/paths consistently on Windows!? BIO functions like BIO_new_file(), BIO_read_filename(), etc do support UTF-8 encoded filenames on Windows, but not all SSL functions use BIOs to access files/directories, so UTF-8 filenames/paths are only supported consistently on POSIX platforms whose file/directory APIs accept UTF-8 encoded strings.? Windows does not support that, filenames/paths must be encoded in ANSI or UTF-16 only. What is OpenSSL's current status regarding this? Remy Lebeau Lebeau Software On 2/7/2018 3:59 PM, Salz, Rich via openssl-users wrote: > > Yes, if there?s something that was made impossible to do because of > things being made opaque, adding the missing API?s would be a bugfix > and go into 1.1.0 and beyond.? It woud be great if you could create a PR. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Feb 8 02:18:37 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 8 Feb 2018 02:18:37 +0000 Subject: [openssl-users] Custom X509_LOOKUP_METHOD in OpenSSL 1.1 In-Reply-To: <0ed28184-d14a-5455-1958-640350b8192f@lebeausoftware.org> References: <8F810AB3-E86A-400A-980D-A35EDE90560F@akamai.com> <0ed28184-d14a-5455-1958-640350b8192f@lebeausoftware.org> Message-ID: <26590A1D-9B5F-4E1B-83AC-93E260B90FDB@akamai.com> * What is OpenSSL's current status regarding this? I don?t recall it being raised before, and I don?t think anyone one the team has expressed interest in this. It would probably have to start by someone contributing a pull request. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu Feb 8 04:44:33 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 08 Feb 2018 05:44:33 +0100 (CET) Subject: [openssl-users] OPENSSL_USE_IPV6 -- bio_dgram, vs travis-ci In-Reply-To: <11282.1517852098@obiwan.sandelman.ca> References: <11282.1517852098@obiwan.sandelman.ca> Message-ID: <20180208.054433.1362979799432604254.levitte@openssl.org> In message <11282.1517852098 at obiwan.sandelman.ca> on Mon, 05 Feb 2018 12:34:58 -0500, Michael Richardson said: mcr> bio_dgram has a bunch of #if on: OPENSSL_USE_IPV6, and I thought that this mcr> might be a common #ifdef, but actually it only occurs in that file. mcr> mcr> I looked through Configurations, and I didn't see it at all. I assume we're talking about OpenSSL 1.1.0 and newer. It's defined to be 0 or 1 in include/internal/sockets.h, here are the relevant lines: # if !defined(OPENSSL_USE_IPV6) # if defined(AF_INET6) # define OPENSSL_USE_IPV6 1 # else # define OPENSSL_USE_IPV6 0 # endif # endif You're right, though, that we're sloppy in using this... and quite frankly, I'd argue that OPENSSL_USE_IPV6 should be removed entirely, as it's an artifact from longago, when IPv6 support wasn't the best. mcr> Other usage is #ifdef AF_INET6, but IPv6 code is available, but I mcr> want to build without it. I'm not sure I understand why... more below. mcr> Fundamentally, I want to turn off IPv6 testing off on travis builds, because mcr> travis has IPv6 turned off, see: mcr> https://github.com/travis-ci/travis-ci/issues/4964 mcr> https://github.com/travis-ci/travis-ci/issues/3302 mcr> mcr> You can't even bind ::1 on travis. I hate this jurassic stuff. OK, so here's another possibility... if you don't want to use IPv6, then don't use it! From an OpenSSL perspective, there are many possibilities to get IPv4 only even if it's built to allow IPv6 as well. When creating a socket, regardless of if you use socket() or BIO_socket(), you can use AF_UNSPEC, AF_INET or AF_INET6 at your leasure. When looking up an address with BIO_lookup_ex, you can specify the address family the same way. 'openssl s_client' and 'openssl s_server' both take options -4 and -6 to say which address family should be used. Now, this ties back to your request on building. Why should you disable the building of IPv6 code, just because you don't want to use it? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Thu Feb 8 10:50:53 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Feb 2018 10:50:53 +0000 Subject: [openssl-users] Lock for SSL_accept method In-Reply-To: References: Message-ID: <467af948-8c83-a590-4aba-f8cbde716847@openssl.org> On 08/02/18 00:43, Yan, Bob via openssl-users wrote: > I used a mutex lock to prevent the SSL_accept() method being called by > multiple thread concurrently since it may get coredump if there is no > lock on SSL_accept() method. I am just wondering is the lock is still > needed for openssl 1.0.2e version? > > ? > > ??????? mutex.lock(); > > ??????? int rt = SSL_accept(SslSessionObject); > > ??????? mutex.unlock(); Hmmm. Well it depends what you mean exactly. The first question is: have you set up the thread locking callbacks? https://www.openssl.org/docs/faq.html#PROG1 As long as you have done the above then SSL_accept() is thread safe in as much as it can be called concurrently with different SSL objects passed as a parameter. It is never safe to call SSL_accept() concurrently with the *same* SSL object passed as a parameter. If you want to call SSL_accept() from multiple threads with the same SSL object then you would have to arrange your own locking. Matt From mcr at sandelman.ca Thu Feb 8 16:25:00 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 08 Feb 2018 11:25:00 -0500 Subject: [openssl-users] OPENSSL_USE_IPV6 -- bio_dgram, vs travis-ci In-Reply-To: <20180208.054433.1362979799432604254.levitte@openssl.org> References: <11282.1517852098@obiwan.sandelman.ca> <20180208.054433.1362979799432604254.levitte@openssl.org> Message-ID: <14698.1518107100@obiwan.sandelman.ca> Richard Levitte wrote: > It's defined to be 0 or 1 in include/internal/sockets.h, here are the > relevant lines: yeah, my eyes missed that in the grep output. I saw no place in Configurations/ where it was either set or not set. mcr> https://github.com/travis-ci/travis-ci/issues/3302 mcr> mcr> You can't even bind ::1 on travis. I hate this jurassic stuff. > OK, so here's another possibility... if you don't want to use IPv6, > then don't use it! From an OpenSSL perspective, there are many Uhm. The point is that my regression test will fail on travis-ci if I try to test the IPv6 pathways, because you can't bind even ::1 on Travis-ci. I've done a different hack which is probably equally stupid, which is to put - TRAVISCI_NO_IPV6=true into .travis.yml and test for it in the regression test. At least that means that travis will *compile* the code, and we'll know if the IPv6 code fails to compile at some point, even if we can't run it on travis. {I should probably have made this a github issue... but... web browsers...} -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From matt at openssl.org Thu Feb 8 17:10:15 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Feb 2018 17:10:15 +0000 Subject: [openssl-users] TLSv1.3 blog post Message-ID: FYI, I reposted my TLSv1.3 blog post from last year, but updated with the latest information. You can read it here: https://www.openssl.org/blog/blog/2018/02/08/tlsv1.3/ Matt From mcepl at cepl.eu Thu Feb 8 17:51:02 2018 From: mcepl at cepl.eu (=?UTF-8?Q?Mat=C4=9Bj?= Cepl) Date: Thu, 08 Feb 2018 18:51:02 +0100 Subject: [openssl-users] [ANN] M2Crypto 0.28.1 ... now PYTHON 3 compatible!!!! Message-ID: <1518112262.15302.6.camel@cepl.eu> Hi, everybody, after a way too long time I have finally version of M2Crypto working BOTH with Python 2.6 and 2.7 and with versions of Python from 3.3 up. Certainly the biggest feature of this release that we are finally compatible both with py2k (Python 2.6 and 2.7) and py3k (from Python 3.3 up). YAY!!! Let us celebrate!!! There were also some other improvements: * building on Mac OS X should be now more reliable and automagic * Fix licence in metadata: it is MIT, not BSD * Fix and add tests for SWIG/_aes.i module (the module was non- functional since its creation in 2004!) * Bundle-in unittest2 for Python 2.6 (dealing with the need for specific version of unittest2 package was too complicated) * Remove all PGP modules (nobody used them, and they were very complicated and brittle). I have also created special email list for development of M2Crypto. Its web page is http://redcrew.org/mailman/listinfo/m2c rypto and it is mailman with the posting address m2crypto at lists.r edcrew.org so all email commands work. All complaints, support requests, and bug reports are welcome in the email list or on the issue tracker https://gitlab.com/m2crypt o/m2crypto/issues Happy security hacking! Mat?j -- https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Don't anthropomorphize computers. They don't like it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From angus at magsys.co.uk Thu Feb 8 18:17:00 2018 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Thu, 8 Feb 2018 18:17 +0000 (GMT Standard Time) Subject: [openssl-users] Creating a Json Web Key Message-ID: I need to create a Jose JWK from the public part of a private key in a PEVP_PKEY, with 1.1.0. I've done it using the old struct rsa_st from 1.0.2 and EVP_PKEY_get1_RSA, and then converting the n and e BIGNUMs to binary (and then to Base64Url). This still works in 1.1.0 although rsa_st has more stuff after n and e, but obviously is not ideal. I've not yet found any helpers for getting n and e any other way. Is there a better way to build a JWK? Now need to handle elliptic curve keys as well. Angus From matt at openssl.org Thu Feb 8 19:32:28 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Feb 2018 19:32:28 +0000 Subject: [openssl-users] Creating a Json Web Key In-Reply-To: References: Message-ID: <4cebbf00-eeca-9b38-d811-a47eedcc1926@openssl.org> On 08/02/18 18:17, Angus Robertson - Magenta Systems Ltd wrote: > I need to create a Jose JWK from the public part of a private key in a > PEVP_PKEY, with 1.1.0. > > I've done it using the old struct rsa_st from 1.0.2 and > EVP_PKEY_get1_RSA, and then converting the n and e BIGNUMs to binary > (and then to Base64Url). > > This still works in 1.1.0 although rsa_st has more stuff after n and e, > but obviously is not ideal. I've not yet found any helpers for getting > n and e any other way. RSA_get0_key()? https://www.openssl.org/docs/man1.1.0/crypto/RSA_get0_key.html Matt > > Is there a better way to build a JWK? > > Now need to handle elliptic curve keys as well. > > Angus > > > > From angus at magsys.co.uk Thu Feb 8 19:42:00 2018 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Thu, 8 Feb 2018 19:42 +0000 (GMT Standard Time) Subject: [openssl-users] Creating a Json Web Key In-Reply-To: <4cebbf00-eeca-9b38-d811-a47eedcc1926@openssl.org> Message-ID: >> I've not yet found any helpers for getting n and e any other way. > RSA_get0_key()? Perfect, should have been able to find that myself... If there an equivalent for EC_GROUP to get x and y? Angus From matt at openssl.org Thu Feb 8 19:45:31 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Feb 2018 19:45:31 +0000 Subject: [openssl-users] Creating a Json Web Key In-Reply-To: References: Message-ID: On 08/02/18 19:42, Angus Robertson - Magenta Systems Ltd wrote: >>> I've not yet found any helpers for getting n and e any other way. >> RSA_get0_key()? > > Perfect, should have been able to find that myself... > > If there an equivalent for EC_GROUP to get x and y? Do you mean for an EC_POINT? If so then: EC_POINT_get_affine_coordinates_GFp() or EC_POINT_get_affine_coordinates_GF2m() depending on whether you are using a prime or binary field based curve. Matt From angus at magsys.co.uk Fri Feb 9 18:30:00 2018 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Fri, 9 Feb 2018 18:30 +0000 (GMT Standard Time) Subject: [openssl-users] Creating a Json Web Key In-Reply-To: Message-ID: > > If there an equivalent for EC_GROUP to get x and y? > > Do you mean for an EC_POINT? If so then: > EC_POINT_get_affine_coordinates_GFp() or Thanks, JKW now built for both key types in 1.1.0. I guess my function would be useful to others as EVP_PKEY_to_JWK_bio or something, unfortunately it's not written in C, but pascal. Angus From renxiang0214 at gmail.com Sun Feb 11 06:41:02 2018 From: renxiang0214 at gmail.com (Xiang Ren) Date: Sun, 11 Feb 2018 14:41:02 +0800 Subject: [openssl-users] crash in `sha1_block_data_order_avx` Message-ID: <1518331057002.naipotz0emlepzfda2roqntx@android.mail.163.com> Anybody has the same trouble with `sha1_block_data_order_avx`? I'm using openssl-1.0.2n. This is coredump information: ? ? ?# gdb ./channel.old core.58820 ? ? ?GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.1 ? ? ?Copyright (C) 2013 Free Software Foundation, Inc. ? ? ?License GPLv3+: GNU GPL version 3 or later ? ? ?This is free software: you are free to change and redistribute it. ? ? ?There is NO WARRANTY, to the extent permitted by law. ?Type "show copying" ? ? ?and "show warranty" for details. ? ? ?This GDB was configured as "x86_64-Huawei-linux-gnu". ? ? ?For bug reporting instructions, please see: ? ? ?... ? ? ?Reading symbols from /home/imax/chuqq/20180207/channel.old...done. ? ? ?warning: core file may not match specified executable file. ? ? ?[New LWP 59134] ? ? ?[New LWP 59135] ? ? ?[New LWP 59133] ? ? ?[New LWP 59136] ? ? ?[New LWP 59115] ? ? ?[New LWP 59116] ? ? ?[New LWP 59117] ? ? ?[New LWP 59118] ? ? ?[New LWP 59119] ? ? ?[New LWP 59120] ? ? ?[New LWP 59121] ? ? ?[New LWP 59122] ? ? ?[New LWP 59123] ? ? ?[New LWP 59125] ? ? ?[New LWP 59126] ? ? ?[New LWP 59124] ? ? ?[New LWP 59128] ? ? ?[New LWP 59127] ? ? ?[New LWP 59129] ? ? ?[New LWP 59130] ? ? ?[New LWP 59114] ? ? ?[New LWP 59131] ? ? ?[New LWP 59132] ? ? ?[New LWP 58820] ? ? ?[Thread debugging using libthread_db enabled] ? ? ?Using host libthread_db library "/lib64/libthread_db.so.1". ? ? ?Core was generated by `../channel/channel -configPath /channel/channel-1'. ? ? ?Program terminated with signal 11, Segmentation fault. ? ? ?#0 ?0x00000000007d591a in sha1_block_data_order_avx () ? ? ?Missing separate debuginfos, use: debuginfo-install glibc-2.17-111.h23.x86_64 libgcc-4.8.5-4.h2.x86_64 numactl-libs-2.0.9-6.x86_64 ? ? ?(gdb) bt ? ? ?#0 ?0x00000000007d591a in sha1_block_data_order_avx () ? ? ?#1 ?0xca62c1d6ca62c1d6 in ?? () ? ? ?#2 ?0xca62c1d6ca62c1d6 in ?? () ? ? ?#3 ?0xca62c1d6ca62c1d6 in ?? () ? ? ?#4 ?0xca62c1d6ca62c1d6 in ?? () ? ? ?#5 ?0xca62c1d6ca62c1d6 in ?? () ? ? ?#6 ?0xca62c1d6ca62c1d6 in ?? () ? ? ?#7 ?0xca62c1d6ca62c1d6 in ?? () ? ? ?#8 ?0xca62c1d6ca62c1d6 in ?? () ? ? ?#9 ?0x0000000009c0aeb1 in ?? () ? ? ?#10 0x00007f38d6aac1a4 in malloc () from /lib64/libc.so.6 ? ? ?#11 0x0000000000773c88 in CRYPTO_malloc () ? ? ?#12 0x00000000007cff2f in SHA1_Update () ? ? ?#13 0x00000000007911e5 in ssleay_rand_bytes () ? ? ?#14 0x000000000078738c in RSA_padding_add_PKCS1_OAEP () ? ? ?#15 0x0000000000784d90 in RSA_eay_public_encrypt () ? ? ?#16 0x000000000048bd35 in rsa_public_encrypt (rsa_input=0x7f369c0190d0 "r\215?\332\350\202\353^$%\215\300s.kz\301?\207p}\363kz\301?\207p}\363EB5E24258DC0732E[*****5.26.157:39044]", input_len=32, ? ? ?? ? ?enc_out=0x7f369c019120 "", public_key=0x7f369c0193d0 "0\202\001\"0\r\006\t*\206H\206\367\r\001\001\001\005", key_len=294) at /root/1.1.0.11/xchannel-1.1.0.11/channel/mc_util.c:312 ? ? ?#17 0x0000000000488798 in generate_channel_aeskey_reply_by_device (device=0x7f2e13b6fb30, dev_rand=0x7f369c019290 "r\215?\332", , ? ? ?? ? ?dev_aeskey=0x7f369c0192d0 "kz\301?\207p}\363\064.182:9877,122.11.34.183:9877", publickey=0x7f369c0193d0 "0\202\001\"0\r\006\t*\206H\206\367\r\001\001\001\005", type=2, request_id=1966548338) ? ? ?? ? ?at /root/1.1.0.11/xchannel-1.1.0.11/channel/mc_dpdktcp.c:391 ? ? ?#18 0x000000000049c499 in channel_aeskey_response (device=0x7f2e13b6fb30, ? ? ?? ? ?message=0x7f2e10455380 "^\304\a8\207(\360R\313k\026\205\220\357C\272\f\373\273@|\342xK}\214\267\367y\255f\245\200d\252\030\257\261\021z?\v\272\035\332DP2?.\a\357\001\272A?[\335-,\254?E\216\273\065\367?}\n\344:\215\237\300\037?\331[\"\210?\230\016\266\243C\362\264Sm\271f\020\373\336?\024\342,(\265\021\257S\356\236\333\340\031\t5\325I\nQ\002?\345v!\016\237,\t\365n,\233\065\336)\005`\276`Ss\274<\346\357Qw[D\321J\004\265\362\227p\251p\255\215\324\366\006\225\235\326$\204?\272hP\217\226\245\006\223\274vL\376\201,\017p\037\003\245\310\342", ..., msg_length=403, request_id=1966548338) ? ? ?? ? ?at /root/1.1.0.11/xchannel-1.1.0.11/channel/mc_outer.c:1018 ? ? ?#19 0x000000000049a07c in outer_process_engine (arg=0x0) at /root/1.1.0.11/xchannel-1.1.0.11/channel/mc_outer.c:217 ? ? ?#20 0x00000000004e6dc4 in eal_thread_loop () ? ? ?#21 0x00007f38d6df4dc5 in start_thread () from /lib64/libpthread.so.0 ? ? ?#22 0x00007f38d6b227ed in clone () from /lib64/libc.so.6 ? ? ?(gdb) i r a ? ? ?rax ? ? ? ? ? ?0x8a53275e? ? ?2320705374 ? ? ?rbx ? ? ? ? ? ?0xe4a22b4a? ? ?3835833162 ? ? ?rcx ? ? ? ? ? ?0x9a663701? ? ?2590390017 ? ? ?rdx ? ? ? ? ? ?0xd734ba54? ? ?3610557012 ? ? ?rsi ? ? ? ? ? ?0x2cea828c? ? ?753566348 ? ? ?rdi ? ? ? ? ? ?0x1a453563? ? ?440743267 ? ? ?rbp ? ? ? ? ? ?0xdd2d0e5d? ? ?0xdd2d0e5d ? ? ?rsp ? ? ? ? ? ?0x7f369c018140? ? ?0x7f369c018140 ? ? ?r8 ? ? ? ? ? ? 0x7a38cb0? ? ?128158896 ? ? ?r9 ? ? ? ? ? ? 0xd1dfd2? ? ?13754322 ? ? ?r10 ? ? ? ? ? ?0xc8d592? ? ?13161874 ? ? ?r11 ? ? ? ? ? ?0x7d7580? ? ?8222080 ? ? ?r12 ? ? ? ? ? ?0xc8d592? ? ?13161874 ? ? ?r13 ? ? ? ? ? ?0xffffffffffffffc0? ? ?-64 ? ? ?r14 ? ? ? ? ? ?0x7f369c0181d8? ? ?139872522306008 ? ? ?r15 ? ? ? ? ? ?0x9c0aeb1? ? ?163622577 ? ? ?rip ? ? ? ? ? ?0x7d591a? ? ?0x7d591a ? ? ?eflags ? ? ? ? 0x13202? ? ?[ IF #12 #13 RF ] ? ? ?cs ? ? ? ? ? ? 0x33? ? ?51 ? ? ?ss ? ? ? ? ? ? 0x2b? ? ?43 ? ? ?ds ? ? ? ? ? ? 0x0? ? ?0 ? ? ?es ? ? ? ? ? ? 0x0? ? ?0 ? ? ?fs ? ? ? ? ? ? 0x0? ? ?0 ? ? ?gs ? ? ? ? ? ? 0x0? ? ?0 ? ? ?st0 ? ? ? ? ? ?*value not available* ? ? ?st1 ? ? ? ? ? ?*value not available* ? ? ?st2 ? ? ? ? ? ?*value not available* ? ? ?st3 ? ? ? ? ? ?*value not available* ? ? ?st4 ? ? ? ? ? ?*value not available* ? ? ?st5 ? ? ? ? ? ?*value not available* ? ? ?st6 ? ? ? ? ? ?*value not available* ? ? ?st7 ? ? ? ? ? ?*value not available* ? ? ?fctrl ? ? ? ? ?*value not available* ? ? ?fstat ? ? ? ? ?*value not available* ? ? ?ftag ? ? ? ? ? *value not available* ? ? ?fiseg ? ? ? ? ?*value not available* ? ? ?fioff ? ? ? ? ?*value not available* ? ? ?foseg ? ? ? ? ?*value not available* ? ? ?fooff ? ? ? ? ?*value not available* ? ? ?fop ? ? ? ? ? ?*value not available* ? ? ?mxcsr ? ? ? ? ?*value not available* ? ? ?ymm0 ? ? ? ? ? *value not available* ? ? ?ymm1 ? ? ? ? ? *value not available* ? ? ?ymm2 ? ? ? ? ? *value not available* ? ? ?ymm3 ? ? ? ? ? *value not available* ? ? ?ymm4 ? ? ? ? ? *value not available* ? ? ?ymm5 ? ? ? ? ? *value not available* ? ? ?ymm6 ? ? ? ? ? *value not available* ? ? ?---Type to continue, or q to quit--- ? ? ?ymm7 ? ? ? ? ? *value not available* ? ? ?ymm8 ? ? ? ? ? *value not available* ? ? ?ymm9 ? ? ? ? ? *value not available* ? ? ?ymm10 ? ? ? ? ?*value not available* ? ? ?ymm11 ? ? ? ? ?*value not available* ? ? ?ymm12 ? ? ? ? ?*value not available* ? ? ?ymm13 ? ? ? ? ?*value not available* ? ? ?ymm14 ? ? ? ? ?*value not available* ? ? ?ymm15 ? ? ? ? ?*value not available* This is my code in production enviroment: ? ? ?struct rte_mbuf *generate_channel_aeskey_reply_by_device(device_t *device, uint8_t *dev_rand, uint8_t *dev_aeskey, uint8_t *publickey, int type, uint32_t request_id) ? ? ?{ ? ? ?? ? ?char devicestr[DEVICE_STR_LEN] = {0}; ? ? ?? ? ?device_str(devicestr, device->id, device->ip, device->port); ? ? ?? ? ?// returned info? RSA(ClientPubKey, ClientRand[8]+DeviceID[8]+AesKey+ServerRand[8]) ? ? ?? ? ?// ServerRand is same as aeskey ? ? ?? ? ?uint8_t hybrid_key[CHANNEL_DEVICE_RAND_LEN + CHANNEL_DEVICE_ID_LEN + CHANNEL_AESKEY_LEN + CHANNEL_AESKEY_LEN] = {0}; ? ? ?? ? ?xmemcpy(hybrid_key, dev_rand, CHANNEL_DEVICE_RAND_LEN); ? ? ?? ? ?xmemcpy(hybrid_key + CHANNEL_DEVICE_RAND_LEN, device->id, CHANNEL_DEVICE_ID_LEN); ? ? ?? ? ?xmemcpy(hybrid_key + CHANNEL_DEVICE_RAND_LEN + CHANNEL_DEVICE_ID_LEN, dev_aeskey, CHANNEL_AESKEY_LEN); ? ? ?? ? ?xmemcpy(hybrid_key + CHANNEL_DEVICE_RAND_LEN + CHANNEL_DEVICE_ID_LEN + CHANNEL_AESKEY_LEN, dev_aeskey, CHANNEL_AESKEY_LEN); ? ? ?? ? ?// alloc mem for encrypted ?head_pub_key + aes_key? ? ? ?? ? ?uint8_t encrypted_hybrid_key[RSA_CLIENT_ENCRYPTED_LEN] = {0}; ? ? ?? ? ?int encrypted_length = rsa_public_encrypt(hybrid_key, CHANNEL_DEVICE_RAND_LEN + CHANNEL_DEVICE_ID_LEN + CHANNEL_AESKEY_LEN + CHANNEL_AESKEY_LEN, encrypted_hybrid_key, publickey, CHANNEL_PUBKEY_LEN); ? ? ?? ? ?if (encrypted_length != RSA_CLIENT_ENCRYPTED_LEN) ? ? ?? ? ?{ ? ? ?? ? ?? ? ?TLOGE("generate_channel_aeskey_reply_by_device", "%s", "rsa_public_encrypt failed to encrypted aeskey_reply. encrypted_length : %d", ? ? ?? ? ?? ? ?? ? ? ?devicestr, encrypted_length); ? ? ?? ? ?? ? ?return NULL; ? ? ?? ? ?} ? ? ?? ? ?// type=(TYPE_PT_AESKEY_RES|TYPE_PT_AESKEY_UPDATE_REQ) ? ? ?? ? ?struct rte_mbuf *rpl_mbuf = generate_channel_pkt_by_device(device, encrypted_hybrid_key, RSA_CLIENT_ENCRYPTED_LEN, type, request_id); ? ? ?? ? ?if (rpl_mbuf == NULL) ? ? ?? ? ?{ ? ? ?? ? ?? ? ?TLOGE("generate_channel_aeskey_reply_by_device", "%s", "rte_pktmbuf_alloc failed to allocate mbuf.", devicestr); ? ? ?? ? ?} ? ? ?? ? ?return rpl_mbuf; ? ? ?} ? ? ?int rsa_public_encrypt(const uint8_t *rsa_input, const int input_len, uint8_t *enc_out, uint8_t *public_key, const int key_len) ? ? ?{ ? ? ?? ? ?uint8_t public_key_wrapper[RSA_PUBKEY_BUFSIZE]; ? ? ?? ? ?int wrapper_len = wrapper_rsa_public_key(public_key, key_len, public_key_wrapper); ? ? ?? ? ?if (wrapper_len >= RSA_PUBKEY_BUFSIZE) ? ? ?? ? ?{ ? ? ?? ? ?? ? ?char pkstr[1024]; // for saving publickey?294Byte?, length for printing chars is 294*2 ? ? ?? ? ?? ? ?convert_int2string(public_key, key_len, pkstr, sizeof(pkstr)); ? ? ?? ? ?? ? ?TLOGE("rsa_public_encrypt", "", "Failed to wrapper_rsa_public_key. wrapper_len: %d, max_len: %d, pk: %s", ? ? ?? ? ?? ? ?? ? ? ?wrapper_len, RSA_PUBKEY_BUFSIZE, pkstr); ? ? ?? ? ?? ? ?return 0; ? ? ?? ? ?} ? ? ?? ? ?RSA *rsa = create_rsa(public_key_wrapper, RSA_KEY_TYPE_PUBLIC); ? ? ?? ? ?if (rsa == NULL) ? ? ?? ? ?{ ? ? ?? ? ?? ? ?char pkstr[1024]; // for saving publickey?294Byte?, length for printing chars is 294*2 ? ? ?? ? ?? ? ?convert_int2string(public_key, key_len, pkstr, sizeof(pkstr)); ? ? ?? ? ?? ? ?TLOGE("rsa_public_encrypt", "", "Failed to create RSA. pk: %s", pkstr); ? ? ?? ? ?? ? ?return 0; ? ? ?? ? ?} ? ? ?? ? ?uint32_t rsa_size = RSA_size(rsa); ? ? ?? ? ?if (input_len >= rsa_size - 41) // less than RSA_size(rsa) - 41 for RSA_PKCS1_OAEP_PADDING ? ? ?? ? ?{ ? ? ?? ? ?? ? ?TLOGE("rsa_public_encrypt", "", "data too long to encrypt, must be less than %d.", RSA_size(rsa) - 41); ? ? ?? ? ?? ? ?RSA_free(rsa); ? ? ?? ? ?? ? ?return 0; ? ? ?? ? ?} ? ? ?? ? ?int ret = RSA_public_encrypt(input_len, rsa_input, enc_out, rsa, RSA_PKCS1_OAEP_PADDING); ? ? ?? ? ?if (ret <= 0) ? ? ?? ? ?{ ? ? ?? ? ?? ? ?TLOGE("rsa_public_encrypt", "", "Failed to encrypt with RSA public key."); ? ? ?? ? ?? ? ?RSA_free(rsa); ? ? ?? ? ?? ? ?return 0; ? ? ?? ? ?} ? ? ?? ? ?RSA_free(rsa); ? ? ?? ? ?return ret; ? ? ?} I've used arguments in the core to reproduce this issue in development enviroment, but failed. This is the code: ? ? ?// gcc test_rsa.c -I./deps/openssl/include/ -L./deps/openssl/lib/ -I./deps/3rd/include/ ./deps/3rd/lib/libbase64.o -lssl -lcrypto -ldl ? ? ?#include ? ? ?#include ? ? ?#include ? ? ?#include ? ? ?#include ? ? ?#include ? ? ?#include ? ? ?#include ? ? ?#include ? ? ?#include ? ? ?#include ? ? ?#include ? ? ?#include ? ? ?#include ? ? ?// #define RSA_PUBKEY_BUFSIZE ? ?600 ? ? ?#define RSA_PUBKEY_BUFSIZE 2048 ? ? ?#define RSA_KEY_LENPERLINE 64 // RSA Pri and Pub keys in base64 format, number of chars per line ? ? ?RSA **private_rsas = NULL; ? ? ?uint32_t RSA_SIZE = 0; ? ? ?#define RSA_KEY_TYPE_PUBLIC 1 ? ? ?#define RSA_KEY_TYPE_PRIVATE 0 ? ? ?#define xmemcpy memcpy ? ? ?#define xmemset memset ? ? ?#define xsnprintf snprintf ? ? ?void convert_int2string(const uint8_t *array, int len, char *str, int dst_len) ? ? ?{ ? ? ?? ? ?if (dst_len < len * 2 + 1) ? ? ?? ? ?{ ? ? ?? ? ?? ? ?return; ? ? ?? ? ?} ? ? ?? ? ?int i; ? ? ?? ? ?for (i = 0; i < len; i++) ? ? ?? ? ?{ ? ? ?? ? ?? ? ?xsnprintf(&(str[i * 2]), 3, "%02X", *(array + i)); ? ? ?? ? ?} ? ? ?} ? ? ?static RSA *create_rsa(uint8_t *key, int key_type) ? ? ?{ ? ? ?? ? ?RSA *rsa = NULL; ? ? ?? ? ?BIO *keybio; ? ? ?? ? ?keybio = BIO_new_mem_buf(key, -1); ? ? ?? ? ?if (keybio == NULL) ? ? ?? ? ?{ ? ? ?? ? ?? ? ?// TLOGE("create_rsa", "", "Failed to create key BIO."); ? ? ?? ? ?? ? ?return NULL; ? ? ?? ? ?} ? ? ?? ? ?if (key_type == RSA_KEY_TYPE_PUBLIC) ? ? ?? ? ?{ ? ? ?? ? ?? ? ?rsa = PEM_read_bio_RSA_PUBKEY(keybio, &rsa, NULL, NULL); ? ? ?? ? ?} ? ? ?? ? ?else ? ? ?? ? ?{ ? ? ?? ? ?? ? ?rsa = PEM_read_bio_RSAPrivateKey(keybio, &rsa, NULL, NULL); ? ? ?? ? ?} ? ? ?? ? ?BIO_free(keybio); ? ? ?? ? ?return rsa; ? ? ?} ? ? ?static int wrapper_rsa_public_key(uint8_t *key, int key_len, uint8_t *wrapper_key) ? ? ?{ ? ? ?? ? ?uint8_t temp[RSA_PUBKEY_BUFSIZE]; ? ? ?? ? ?uint8_t head[] = "-----BEGIN PUBLIC KEY-----\n"; ? ? ?? ? ?uint8_t tail[] = "-----END PUBLIC KEY-----\n"; ? ? ?? ? ?uint8_t *p_wapper = wrapper_key; ? ? ?? ? ?uint8_t *p_temp = temp; ? ? ?? ? ?size_t base64_len; ? ? ?? ? ?base64_encode((char *)key, key_len, (char *)temp, &base64_len, 0); ? ? ?? ? ?xmemcpy(p_wapper, head, strlen((const char *)head)); ? ? ?? ? ?p_wapper += strlen((const char *)head); ? ? ?? ? ?int times = base64_len / RSA_KEY_LENPERLINE; ? ? ?? ? ?int ret_char_cnt = times; ? ? ?? ? ?int i; ? ? ?? ? ?for (i = 0; i < times; i++) ? ? ?? ? ?{ ? ? ?? ? ?? ? ?xmemcpy(p_wapper, p_temp, RSA_KEY_LENPERLINE); ? ? ?? ? ?? ? ?p_wapper += RSA_KEY_LENPERLINE; ? ? ?? ? ?? ? ?p_temp += RSA_KEY_LENPERLINE; ? ? ?? ? ?? ? ?xmemset(p_wapper, '\n', 1); ? ? ?? ? ?? ? ?p_wapper++; ? ? ?? ? ?} ? ? ?? ? ?if (base64_len % RSA_KEY_LENPERLINE > 0) ? ? ?? ? ?{ ? ? ?? ? ?? ? ?xmemcpy(p_wapper, p_temp, base64_len % RSA_KEY_LENPERLINE); ? ? ?? ? ?? ? ?p_wapper += base64_len % RSA_KEY_LENPERLINE; ? ? ?? ? ?? ? ?xmemset(p_wapper, '\n', 1); ? ? ?? ? ?? ? ?p_wapper++; ? ? ?? ? ?? ? ?ret_char_cnt++; ? ? ?? ? ?} ? ? ?? ? ?xmemcpy(p_wapper, tail, strlen((const char *)tail)); ? ? ?? ? ?return strlen((const char *)head) + base64_len + ret_char_cnt + strlen((const char *)tail); ? ? ?} ? ? ?int rsa_public_encrypt(const uint8_t *rsa_input, const int input_len, uint8_t *enc_out, uint8_t *public_key, const int key_len) ? ? ?{ ? ? ?? ? ?uint8_t public_key_wrapper[RSA_PUBKEY_BUFSIZE]; ? ? ?? ? ?int wrapper_len = wrapper_rsa_public_key(public_key, key_len, public_key_wrapper); ? ? ?? ? ?if (wrapper_len >= RSA_PUBKEY_BUFSIZE) ? ? ?? ? ?{ ? ? ?? ? ?? ? ?char pkstr[1024]; ? ? ?? ? ?? ? ?convert_int2string(public_key, key_len, pkstr, sizeof(pkstr)); ? ? ?? ? ?? ? ?// TLOGE("rsa_public_encrypt", "", "Failed to wrapper_rsa_public_key. wrapper_len: %d, max_len: %d, pk: %s", ? ? ?? ? ?? ? ?? ? ?// ? wrapper_len, RSA_PUBKEY_BUFSIZE, pkstr); ? ? ?? ? ?? ? ?return 0; ? ? ?? ? ?} ? ? ?? ? ?RSA *rsa = create_rsa(public_key_wrapper, RSA_KEY_TYPE_PUBLIC); ? ? ?? ? ?if (rsa == NULL) ? ? ?? ? ?{ ? ? ?? ? ?? ? ?char pkstr[1024]; ? ? ?? ? ?? ? ?convert_int2string(public_key, key_len, pkstr, sizeof(pkstr)); ? ? ?? ? ?? ? ?// TLOGE("rsa_public_encrypt", "", "Failed to create RSA. pk: %s", pkstr); ? ? ?? ? ?? ? ?return 0; ? ? ?? ? ?} ? ? ?? ? ?uint32_t rsa_size = RSA_size(rsa); ? ? ?? ? ?if (input_len >= rsa_size - 41) // less than RSA_size(rsa) - 41 for RSA_PKCS1_OAEP_PADDING ? ? ?? ? ?{ ? ? ?? ? ?? ? ?// TLOGE("rsa_public_encrypt", "", "data too long to encrypt, must be less than %d.", RSA_size(rsa) - 41); ? ? ?? ? ?? ? ?RSA_free(rsa); ? ? ?? ? ?? ? ?return 0; ? ? ?? ? ?} ? ? ?? ? ?int ret = RSA_public_encrypt(input_len, rsa_input, enc_out, rsa, RSA_PKCS1_OAEP_PADDING); ? ? ?? ? ?if (ret <= 0) ? ? ?? ? ?{ ? ? ?? ? ?? ? ?// TLOGE("rsa_public_encrypt", "", "Failed to encrypt with RSA public key."); ? ? ?? ? ?? ? ?RSA_free(rsa); ? ? ?? ? ?? ? ?return 0; ? ? ?? ? ?} ? ? ?? ? ?RSA_free(rsa); ? ? ?? ? ?return ret; ? ? ?} ? ? ?int main() { ? ? ?? ? ?uint8_t rsa_input[32] = {0x72, 0x8d, 0xe5, 0xb4, 0x80, 0xda, 0xe8, 0x82, 0xeb, 0x5e, 0x24, 0x25, 0x8d, 0xc0, 0x73, 0x2e, 0x6b, 0x7a, 0xc1, 0x3f, 0x87, 0x70, 0x7d, 0xf3, 0x6b, 0x7a, 0xc1, 0x3f, 0x87, 0x70, 0x7d, 0xf3}; ? ? ?? ? ?uint8_t enc_out[256] = {0}; ? ? ?? ? ?uint8_t public_key[294] = {0x30, 0x82, 0x1, 0x22, 0x30 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sun Feb 11 13:12:02 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 11 Feb 2018 13:12:02 +0000 Subject: [openssl-users] crash in `sha1_block_data_order_avx` In-Reply-To: <1518331057002.naipotz0emlepzfda2roqntx@android.mail.163.com> References: <1518331057002.naipotz0emlepzfda2roqntx@android.mail.163.com> Message-ID: <6E1C3526-7DFA-40A9-9388-B40F7A9CEC52@akamai.com> The usual cause for this is a stray or incorrect pointer, corrupting malloc structures. Have you run your code under a valgrind or similar? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbustamante at broadsoft.com Mon Feb 12 20:47:26 2018 From: jbustamante at broadsoft.com (Jorge Bustamante) Date: Mon, 12 Feb 2018 14:47:26 -0600 Subject: [openssl-users] FIPs support on openssl 1.1.0 Message-ID: Hi all, I found that x25519 elliptic curve is only supported on openssl 1.1.0+ versions. However, I need to know if these versions support FIPs too. Do you know if openssl 1.1.0 and/or newer versions support FIPs? Regards, Jorge Bustamante -- This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. Ce message confidentiel et les ?ventuelles pi?ces jointes sont ? l?usage exclusif de son ou de sa destinataire. Il est interdit, pour toute autre personne, de le distribuer, d?en d?voiler le contenu ou de le reproduire. Si vous avez re?u cette communication par erreur, veuillez en informer imm?diatement l?exp?diteur par courrier ?lectronique et d?truire l?original de ce message ainsi que toute copie. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Feb 12 20:59:16 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 12 Feb 2018 20:59:16 +0000 Subject: [openssl-users] FIPs support on openssl 1.1.0 In-Reply-To: References: Message-ID: FIPS is not supported in 1.1.0. We will be starting a FIPS project soon, targeted for the next release after 1.1.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Tue Feb 13 06:06:24 2018 From: d3ck0r at gmail.com (J Decker) Date: Mon, 12 Feb 2018 22:06:24 -0800 Subject: [openssl-users] Has client validated successfully? Message-ID: Is there a way for a server to know if the client verified the cert chain successfully or not? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at foocrypt.net Tue Feb 13 06:05:46 2018 From: openssl at foocrypt.net (openssl at foocrypt.net) Date: Tue, 13 Feb 2018 00:05:46 -0600 Subject: [openssl-users] FooCrypt, 0.0.1, Core, 10.11.0, using OpenSSL Cypher Engines. Message-ID: Hi On the eve of the first sitting of the Australian Parliament for the calendar year 2018, FooCrypt, A Tale of Cynical Cyclical Encryption : FooCrypt,0.0.1,Core,10.11.0,Darwin https://www.fookey.net/store/p881/FooCrypt_0.0.1_Core_10.11.0_Darwin has been published in accordance with the criminalization of cryptology in Australia. Documentation and high level specifications available via : The FooKey Method http://www.foocrypt.net/the-fookey-method.html OpenSSL is the DEFAULT cypher engine for use with all FooCrypt,0.0.1,Core releases. A quick break down : Operating System instance security model constraints ( https://en.wikipedia.org/wiki/POSIX Applicable security models ) Programming languages security constraints ( Tcl/Tk, KSH, C, Expect ) POSIX compliance constraints ( https://en.wikipedia.org/wiki/POSIX ) FooCrypt runs from ANYWHERE, expect ANYWHERE BUT Software keyboard & software mouse clicks which are all internal to the programming language View able text controlled by colour schemes Identifiable cursor positioning Binary key sources are unlimited Random data key sources are unlimited Key length per encryption cycle of the cypher is maxed Cypher selection is limited to any available cypher engine you have access to Number of total cycles are only constrained by time and hardware constraints 50 cycles ( layers ) of encryption is the DEFAULT configuration which contains 25650 total characters, 24250 random / binary sourced characters @ 512 characters per cycle, protected by MD5 Checksums, which is encrypted in a single cycle ( layer ) of encryption by DEFAULT. Currently release for macOS 10.11+ Scheduled for release on : Solaris ( Sparc / x86 [ Hypervisor running { live / customised SOE} ] ) Linux ( x86 [ Hypervisor running { live / customised SOE} ] ) Windows, utilising either the Solaris or Linux Hypervisor solutions. No network, shared local mount point to the host due to proliferation of Windows MALWare, etc ? Regards, Mark A. Lane Cryptopocalypse NOW 01 04 2016 Volumes 0.0 NOW available through iTunes - iBooks @ https://itunes.apple.com/au/author/mark-a.-lane/id1100062966?mt=11 Cryptopocalypse NOW is the TRUE story behind the trials and tribulations encountered in creating "FooCrypt, A Tale of Cynical Cyclical Encryption." due to the Australian Government's ( led by Malcolm Turnbull ) criminalisation of encryption technologies on the 1st of April, 2016, as told by a Convicted Hacker. "FooCrypt, A Tale of Cynical Cyclical Encryption." is aimed at hardening several commonly used Symmetric Open Source Encryption methods so that they are hardened to a standard that is commonly termed 'QUANTUM ENCRYPTION'. "FooCrypt, A Tale of Cynical Cyclical Encryption." is currently under export control by the Australian Department of Defence Defence Export Controls Office due to the listing of Cryptology as a ?Dual Use? Technology as per the ?Wassenaar Arrangement? Limited Edition Collectors versions and Hard Back Editions are available via the store on http://www.foocrypt.net/ ? Mark A. Lane 1980 - 2018, All Rights Reserved. ? FooCrypt 1980 - 2018, All Rights Reserved. ? FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2018, All Rights Reserved. ? Cryptopocalypse 1980 - 2018, All Rights Reserved. From aerowolf at gmail.com Tue Feb 13 06:14:15 2018 From: aerowolf at gmail.com (Kyle Hamilton) Date: Mon, 12 Feb 2018 22:14:15 -0800 Subject: [openssl-users] Has client validated successfully? In-Reply-To: References: Message-ID: The only thing that the server can know is whether the client has terminated the connection with a fatal alert. If the client validates presented cert chains, then its continuation with the connection means that it passed validation. If the client does not, or ignores any given error, then it doesn't mean that it passed validation. In other words, you can only know if the client's applied policy allows the connection to continue. You cannot know if the policy that was applied was specifically related to the certificate chain presented. -Kyle H On Mon, Feb 12, 2018 at 10:06 PM, J Decker wrote: > Is there a way for a server to know if the client verified the cert chain > successfully or not? > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From maddi.nivedita at gmail.com Tue Feb 13 10:38:10 2018 From: maddi.nivedita at gmail.com (Nivedita) Date: Tue, 13 Feb 2018 16:08:10 +0530 Subject: [openssl-users] DTLS over UDP Message-ID: Hi All, I am trying to establish DTLS over UDP connection by using DTLSv1_listen method . I have followed the below steps - 1. Created a server socket and using this socket created bio and ssl object. bio = BIO_new_dgram(VI_sock,BIO_NOCLOSE)) SSL_set_bio(ssl,VP_bio,VP_bio); 2. Enable cookie exchange on SSL object. SSL_set_options(ssl, SSL_OP_COOKIE_EXCHANGE); 3. Then started listening using dtlsv1_listen for the new client connections. Once dtlsv1_listen is successful and i got the peer address. 4. Once i got the peer address , i am creating one more socket 5. With the new socket i tried to connect to peer address. 6. Then i am trying to do ssl_accept on the new socket by calling bio_set_fd. BIO_set_fd(SSL_get_rbio(ssl),VI_new_sock_id,BIO_NOCLOSE); BIO_ctrl(SSL_get_rbio(VP_ssl),BIO_CTRL_DGRAM_SET_CONNECTED, 0, &client_addr); SSL_set_fd(ssl,VI_newsock_id); VI_res = SSL_accept(ssl); But ssl_accept will always return error code 2 [ i.e want read or want write] But if i am doing ssl_accept without doing the step no 6 it it will be successful. Could someone please let us know how to switch to newly created socket, so that it can start using newly created socket for further read and write operations and original server socket will keep on listening for new connections. Regards, Nivedita -------------- next part -------------- An HTML attachment was scrubbed... URL: From renxiang0214 at gmail.com Tue Feb 13 11:16:50 2018 From: renxiang0214 at gmail.com (Xiang Ren) Date: Tue, 13 Feb 2018 19:16:50 +0800 Subject: [openssl-users] =?utf-8?b?5Zue5aSN77yaIGNyYXNoIGluIGBzaGExX2Js?= =?utf-8?q?ock=5Fdata=5Forder=5Favx=60?= In-Reply-To: <6E1C3526-7DFA-40A9-9388-B40F7A9CEC52@akamai.com> References: <1518331057002.naipotz0emlepzfda2roqntx@android.mail.163.com><6E1C3526-7DFA-40A9-9388-B40F7A9CEC52@akamai.com> Message-ID: <1518520607892.f21regmgb4wdnnpcznavikwk@android.mail.163.com> Dear all, very appreciate your reply! We have double check the implementation of related functions, and confirm that the input params for the function int rsa_public_encrypt(const uint8_t *rsa_input, const int input_len, uint8_t *enc_out, uint8_t *public_key, const int key_len) are all stack variables(say rsa_input, enc_out and public_key), so there should have no problems with alloc; we find things about threads with openssl here https://www.openssl.org/docs/man1.0.2/crypto/threads.html and add the lock functions, till now, it seems ok, but we still could not make sure whether it is the safely in multi-thread response for the crash By the way, the function 'base64_encode' is to encode chars in base64, any function implement this method could be used for compilation. renxiang0214 ???renxiang0214 at gmail.com ????????????? ?2018?02?11? 21:12?Salz, Rich via openssl-users ??? The usual cause for this is a stray or incorrect pointer, corrupting malloc structures.? Have you run your code under a valgrind or similar? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Feb 13 13:29:48 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 13 Feb 2018 14:29:48 +0100 Subject: [openssl-users] =?utf-8?b?5Zue5aSN77yaIGNyYXNoIGluIGBzaGExX2Js?= =?utf-8?q?ock=5Fdata=5Forder=5Favx=60?= In-Reply-To: <1518520607892.f21regmgb4wdnnpcznavikwk@android.mail.163.com> References: <1518331057002.naipotz0emlepzfda2roqntx@android.mail.163.com> <6E1C3526-7DFA-40A9-9388-B40F7A9CEC52@akamai.com> <1518520607892.f21regmgb4wdnnpcznavikwk@android.mail.163.com> Message-ID: On 13/02/2018 12:16, Xiang Ren wrote: > Dear all, very appreciate your reply! We have double check the > implementation of related functions, and confirm that the input params > for the function > int rsa_public_encrypt(const uint8_t *rsa_input, const int input_len, > uint8_t *enc_out, uint8_t *public_key, const int key_len) > are all stack variables(say rsa_input, enc_out and public_key), so > there should have no problems with alloc; > > we find things about threads with openssl here > https://www.openssl.org/docs/man1.0.2/crypto/threads.html > and add the lock functions, till now, it seems ok, but we still could > not make sure whether it is the safely in multi-thread response for > the crash > > By the way, the function 'base64_encode' is to encode chars in base64, > any function implement this method could be used for compilation. When a program crashes in malloc(), the likely corruption in the heap may have happened anywhere in the program, at any time before the crash.? malloc() then crashes when it uses the malloc-internal data that was corrupted. That is why the best way to find the cause is to run the program with a heap corruption detection system such as valgrind. 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 Feb 13 13:31:33 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 13 Feb 2018 13:31:33 +0000 Subject: [openssl-users] =?utf-8?b?5Zue5aSN77yaIGNyYXNoIGluIGBzaGExX2Js?= =?utf-8?q?ock=5Fdata=5Forder=5Favx=60?= In-Reply-To: <1518520607892.f21regmgb4wdnnpcznavikwk@android.mail.163.com> References: <1518331057002.naipotz0emlepzfda2roqntx@android.mail.163.com> <6E1C3526-7DFA-40A9-9388-B40F7A9CEC52@akamai.com> <1518520607892.f21regmgb4wdnnpcznavikwk@android.mail.163.com> Message-ID: <5A754234-1560-4D52-A293-98A3C145A9DC@akamai.com> If your program uses threads, then you *have* to set the thread functions. Glad you got it fixed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sfhacker at hotmail.com Tue Feb 13 14:13:18 2018 From: sfhacker at hotmail.com (Sergio NNX) Date: Tue, 13 Feb 2018 14:13:18 +0000 Subject: [openssl-users] =?big5?b?pl7OYKFHIGNyYXNoIGluIGBzaGExX2Jsb2NrX2Rh?= =?big5?b?dGFfb3JkZXJfYXZ4YA==?= In-Reply-To: <1518520607892.f21regmgb4wdnnpcznavikwk@android.mail.163.com> References: <1518331057002.naipotz0emlepzfda2roqntx@android.mail.163.com><6E1C3526-7DFA-40A9-9388-B40F7A9CEC52@akamai.com>, <1518520607892.f21regmgb4wdnnpcznavikwk@android.mail.163.com> Message-ID: > Dear all, very appreciate your reply! We have double check the implementation of related > functions, and confirm that the input params for the function > int rsa_public_encrypt(const uint8_t *rsa_input, const int input_len, uint8_t *enc_out, > uint8_t *public_key, const int key_len) > are all stack variables(say rsa_input, enc_out and public_key), so there should have no > problems with alloc; .... .... Several days ago we emailed you regarding this issue. Never got a response. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Tue Feb 13 14:33:43 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 13 Feb 2018 14:33:43 +0000 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 1 published Message-ID: <20180213143343.GA15047@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.1 pre release 1 (alpha) =========================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 1.1.1 is currently in alpha. OpenSSL 1.1.1 pre release 1 has now been made available. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. The alpha release is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1-pre1.tar.gz Size: 6406872 SHA1 checksum: 83fee0570c8aff4701700f88d193fcf785b595ae SHA256 checksum: dd291d0a81d77219d40b21b9caf4713daaf43416fe8d6eae0b96df39b8b17e6d The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1-pre1.tar.gz openssl sha256 openssl-1.1.1-pre1.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: ttps://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaguyiAAoJENnE0m0OYESRQSoH/03mmxlj3zAcOgiWcQW7Nsfv bDr6TArh2zplEv/KUxrZiy9CCCKh3p9KI2VlUclObj327pkknMrQfx2TvYDztqfn UsbBL2XA+aiTlF0qgzDQMxg4bdfzYMKL5MUxQvsteVyyTrz5Wm1EWnwjn/mtKh6f p+nJPM9slFeV5EYTdNWIsugl55xU3oueFdVKdOqdZIUkKf5yAVe0/7UH/zVHYRt9 Mq7KZP6suRWhOgcK+g16tevO03+KkY/4O8rwE05DG3gjBbpT/hQvMcluV6jpHgIK KhMUurwOwjN81TZhYmkdKf5gBRvJ03zaJE+LeZHIKR6xdzOQBURsM4m+xPAs7i0= =ZT+8 -----END PGP SIGNATURE----- From ash1412 at gmail.com Tue Feb 13 16:55:13 2018 From: ash1412 at gmail.com (Ashwani Kumar) Date: Tue, 13 Feb 2018 17:55:13 +0100 Subject: [openssl-users] extract private exponent Message-ID: Hi All, is there any openssl API to extract private exponent from DER key? -rds, -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcr at sandelman.ca Tue Feb 13 18:51:10 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 13 Feb 2018 13:51:10 -0500 Subject: [openssl-users] DTLS over UDP In-Reply-To: References: Message-ID: <10616.1518547870@obiwan.sandelman.ca> Nivedita wrote: > I am trying to establish DTLS over UDP connection by using > DTLSv1_listen method . > I have followed the below steps - 1. Created a server socket and using > this socket created bio and ssl object. bio = > BIO_new_dgram(VI_sock,BIO_NOCLOSE)) SSL_set_bio(ssl,VP_bio,VP_bio); > 2. Enable cookie exchange on SSL object. SSL_set_options(ssl, > SSL_OP_COOKIE_EXCHANGE); > 3. Then started listening using dtlsv1_listen for the new client > connections. Once dtlsv1_listen is successful and i got the peer > address. okay. > 4. Once i got the peer address , i am creating one more socket > 5. With the new socket i tried to connect to peer address. Do you mean, you call "SSL_connect()"? Or do you mean you bind(2) and connect(2) the socket. > 6. Then i am trying to do ssl_accept on the new socket by calling > bio_set_fd. > BIO_set_fd(SSL_get_rbio(ssl),VI_new_sock_id,BIO_NOCLOSE); > BIO_ctrl(SSL_get_rbio(VP_ssl),BIO_CTRL_DGRAM_SET_CONNECTED, 0, > &client_addr); > SSL_set_fd(ssl,VI_newsock_id); So, SSL_set_fd() will allocate a ne bio, which probably undoes the effect of calling BIO_CRTL_DGRAM_SET_CONNECTED. Since you have set the fd of the existing BIO, I think you can omit that line. > VI_res = SSL_accept(ssl); > But ssl_accept will always return error code 2 [ i.e want read or want > write] > But if i am doing ssl_accept without doing the step no 6 it it will be > successful. Yes. > Could someone please let us know how to switch to newly created socket, > so that it can start using newly created socket for further read and > write operations and original server socket will keep on listening for > new connections. Do you expect additional connections on the existing socket? I've been working on some new API to make this all easier. Your method may fail if you have bound your "listen" to :: (0.0.0.0), and you have multiple IPs. In my case, I expect connections over IPv6 LL addresses, and there are always multiple of those, and ifindex issues as well. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From norm.green at gemtalksystems.com Tue Feb 13 21:06:12 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 13 Feb 2018 13:06:12 -0800 Subject: [openssl-users] OpenSSL 1.1.1 pre-release 1 build failure Message-ID: This is on Ubuntu 16.04with a build configured to be debug-linux-x86_64 normg at moop>gmake make depend && make _all make[1]: Entering directory '/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1' make[1]: Leaving directory '/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1' make[1]: Entering directory '/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1' /usr/bin/gcc? -I. -Icrypto/include -Iinclude -Wall -O0 -g -pthread -m64 -fPIC -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_STATIC_ENGINE -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 -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSLDIR="\"/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1/install50/ssl\"" -DENGINESDIR="\"/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1/install50/lib/engines-1.1\"" -c -MMD -MF crypto/conf/conf_mod.d.tmp -MT crypto/conf/conf_mod.o -c -o crypto/conf/conf_mod.o crypto/conf/conf_mod.c crypto/conf/conf_mod.c: In function 'CONF_get1_default_config_file': crypto/conf/conf_mod.c:491:19: error: 'OPENSSL_CONF' undeclared (first use in this function) ???? len += strlen(OPENSSL_CONF); ?????????????????? ^ crypto/conf/conf_mod.c:491:19: note: each undeclared identifier is reported only once for each function it appears in Makefile:2305: recipe for target 'crypto/conf/conf_mod.o' failed make[1]: *** [crypto/conf/conf_mod.o] Error 1 make[1]: Leaving directory '/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1' Makefile:143: recipe for target 'all' failed make: *** [all] Error 2 Perhaps we are missing an include of: include/internal/cryptlib.h? ? Norm From openssl at jordan.maileater.net Tue Feb 13 18:37:31 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Tue, 13 Feb 2018 10:37:31 -0800 Subject: [openssl-users] =?utf-8?b?5Zue5aSN77yaIGNyYXNoIGluIGBzaGExX2Js?= =?utf-8?q?ock=5Fdata=5Forder=5Favx=60?= In-Reply-To: <5A754234-1560-4D52-A293-98A3C145A9DC@akamai.com> References: <1518331057002.naipotz0emlepzfda2roqntx@android.mail.163.com> <6E1C3526-7DFA-40A9-9388-B40F7A9CEC52@akamai.com> <1518520607892.f21regmgb4wdnnpcznavikwk@android.mail.163.com> <5A754234-1560-4D52-A293-98A3C145A9DC@akamai.com> Message-ID: <55108ec8-08a3-0b7a-71fc-ae8a8db3bf3c@jordan.maileater.net> On 2/13/2018 5:31 AM, Salz, Rich via openssl-users wrote: > > If your program uses threads, then you **have** to set the thread > functions.? Glad you got it fixed. > Why can't OpenSSL do this automatically?? Yes, some applications will need to supply specialty functions, but it could supply defaults. -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Feb 13 21:39:49 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 13 Feb 2018 21:39:49 +0000 Subject: [openssl-users] =?utf-8?b?5Zue5aSN77yaIGNyYXNoIGluIGBzaGExX2Js?= =?utf-8?q?ock=5Fdata=5Forder=5Favx=60?= In-Reply-To: <55108ec8-08a3-0b7a-71fc-ae8a8db3bf3c@jordan.maileater.net> References: <1518331057002.naipotz0emlepzfda2roqntx@android.mail.163.com> <6E1C3526-7DFA-40A9-9388-B40F7A9CEC52@akamai.com> <1518520607892.f21regmgb4wdnnpcznavikwk@android.mail.163.com> <5A754234-1560-4D52-A293-98A3C145A9DC@akamai.com> <55108ec8-08a3-0b7a-71fc-ae8a8db3bf3c@jordan.maileater.net> Message-ID: * If your program uses threads, then you *have* to set the thread functions. Glad you got it fixed. > Why can't OpenSSL do this automatically? Yes, some applications will need to supply specialty functions, but it could supply defaults. It does in 1.1.0 and later. -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at strategix.se Tue Feb 13 22:02:27 2018 From: curt at strategix.se (Curt Johansson) Date: Tue, 13 Feb 2018 23:02:27 +0100 Subject: [openssl-users] Explicit IV in TLS 1.1+ Message-ID: <69BB651F-E746-49CC-A032-FA838309C3B7@strategix.se> Hi all, I'm developing support for TLS 1.1 and 1.2 in a radius-server that until now only handles TLS 1.0. I'm testing with a testtool that the vendor says is using OpenSSL to implement the TLS support. It all seems to work except for the following: When all key exchange messages are sent from the server and back from the client the client sends the "Finished" message which is the first encrypted with the negotiated symmetric cipher suite. I use AES-128 in block mode and according to the spec (RFC4346 for TLS 1.1) the IV is prepended to the encrypted message (containing the payload, MAC and padding). The message size i right and when (in the server) I use the first 16 bytes of the message received from the client as IV the decryption fails but when I use the mechanism from TLS 1.0 to pick up the IV from the key_block the decryption is successful. I understand that this is one way to generate the IV that I suppose you use which is fine but shouldn't this 16 byte vector be prepended, unecrypted, to the encrypted data that is sent to the server? In TLS 1.2 there is not IV material generated at all in the key_block so in that case I don't even know where to find it. The simple question is, shouldn't the first 16 bytes (assuming AES) of the message (after the 5 byte header) be the unencrypted IV to be used in the decryption of the rest of the message? I tried to dig in to the OpenSSL source but it's far too long ago I did some serious C coding so I hope someone with a working knowledge can enlighten me. I might have misunderstood the spec but in that case I would be grateful if someone could clarify this specific part of it. TIA Curt Johansson From matt at openssl.org Tue Feb 13 22:59:58 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Feb 2018 22:59:58 +0000 Subject: [openssl-users] OpenSSL 1.1.1 pre-release 1 build failure In-Reply-To: References: Message-ID: <3cc33f03-d364-6df5-b39f-4656885149b8@openssl.org> On 13/02/18 21:06, Norm Green wrote: > This is on Ubuntu 16.04with a build configured to be debug-linux-x86_64 > > normg at moop>gmake > make depend && make _all > make[1]: Entering directory > '/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1' > make[1]: Leaving directory > '/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1' > make[1]: Entering directory > '/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1' > /usr/bin/gcc? -I. -Icrypto/include -Iinclude -Wall -O0 -g -pthread -m64 > -fPIC -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_STATIC_ENGINE > -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 -DRC4_ASM -DMD5_ASM -DAES_ASM > -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM > -DPOLY1305_ASM -DOPENSSL_USE_NODELETE -DL_ENDIAN > -DOPENSSLDIR="\"/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1/install50/ssl\"" > -DENGINESDIR="\"/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1/install50/lib/engines-1.1\"" > -c -MMD -MF crypto/conf/conf_mod.d.tmp -MT crypto/conf/conf_mod.o -c -o > crypto/conf/conf_mod.o crypto/conf/conf_mod.c > crypto/conf/conf_mod.c: In function 'CONF_get1_default_config_file': > crypto/conf/conf_mod.c:491:19: error: 'OPENSSL_CONF' undeclared (first > use in this function) > ???? len += strlen(OPENSSL_CONF); > ?????????????????? ^ > crypto/conf/conf_mod.c:491:19: note: each undeclared identifier is > reported only once for each function it appears in > Makefile:2305: recipe for target 'crypto/conf/conf_mod.o' failed > make[1]: *** [crypto/conf/conf_mod.o] Error 1 > make[1]: Leaving directory > '/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1' > Makefile:143: recipe for target 'all' failed > make: *** [all] Error 2 > > Perhaps we are missing an include of: include/internal/cryptlib.h? ? Hmm. That is very strange. The include of that header is right at the top of that file. Could you provide explicitly the build steps you followed to produce this result? Thanks Matt > > Norm > From matt at openssl.org Tue Feb 13 23:26:15 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Feb 2018 23:26:15 +0000 Subject: [openssl-users] Explicit IV in TLS 1.1+ In-Reply-To: <69BB651F-E746-49CC-A032-FA838309C3B7@strategix.se> References: <69BB651F-E746-49CC-A032-FA838309C3B7@strategix.se> Message-ID: On 13/02/18 22:02, Curt Johansson wrote: > Hi all, > > I'm developing support for TLS 1.1 and 1.2 in a radius-server that until now only handles TLS 1.0. I'm testing with a testtool that the vendor says is > using OpenSSL to implement the TLS support. It all seems to work except for the following: > > When all key exchange messages are sent from the server and back from the client the client sends the "Finished" message which > is the first encrypted with the negotiated symmetric cipher suite. I use AES-128 in block mode and according to the spec (RFC4346 for TLS 1.1) > the IV is prepended to the encrypted message (containing the payload, MAC and padding). The message size i right and when (in the server) I use the first 16 bytes > of the message received from the client as IV the decryption fails but when I use the mechanism from TLS 1.0 to pick up the IV from > the key_block the decryption is successful. I understand that this is one way to generate the IV that I suppose you use which is fine but > shouldn't this 16 byte vector be prepended, unecrypted, to the encrypted data that is sent to the server? In TLS 1.2 there is not IV material generated > at all in the key_block so in that case I don't even know where to find it. > > The simple question is, shouldn't the first 16 bytes (assuming AES) of the message (after the 5 byte header) be the unencrypted IV to be used in the decryption of the rest of the message? Yes, assuming you have negotiated an AES CBC ciphersuite in TLSv1.1 or TLSv1.2, then that is what happens. You don't say what version of OpenSSL you are using. Here is the code that does it for 1.1.1 (i.e. master branch): https://github.com/openssl/openssl/blob/master/ssl/record/ssl3_record.c#L954 As can be seen on line 969 we just fill the IV with random bytes. Perhaps you could provide a wireshark trace of the handshake which might provide some enlightenment as to what is happening. Matt > > I tried to dig in to the OpenSSL source but it's far too long ago I did some serious C coding so I hope someone with a working knowledge can enlighten me. I might have > misunderstood the spec but in that case I would be grateful if someone could clarify this specific part of it. > > TIA > Curt Johansson > From norm.green at gemtalksystems.com Tue Feb 13 23:26:33 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 13 Feb 2018 15:26:33 -0800 Subject: [openssl-users] OpenSSL 1.1.1 pre-release 1 build failure In-Reply-To: <3cc33f03-d364-6df5-b39f-4656885149b8@openssl.org> References: <3cc33f03-d364-6df5-b39f-4656885149b8@openssl.org> Message-ID: Turns out it only fails in my build environment and it builds clean as a stand-alone SSL build.? So it's something on my end. Sorry for the noise. Norm On 2/13/2018 2:59 PM, Matt Caswell wrote: > > On 13/02/18 21:06, Norm Green wrote: >> This is on Ubuntu 16.04with a build configured to be debug-linux-x86_64 >> >> normg at moop>gmake >> make depend && make _all >> make[1]: Entering directory >> '/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1' >> make[1]: Leaving directory >> '/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1' >> make[1]: Entering directory >> '/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1' >> /usr/bin/gcc? -I. -Icrypto/include -Iinclude -Wall -O0 -g -pthread -m64 >> -fPIC -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_STATIC_ENGINE >> -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 -DRC4_ASM -DMD5_ASM -DAES_ASM >> -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM >> -DPOLY1305_ASM -DOPENSSL_USE_NODELETE -DL_ENDIAN >> -DOPENSSLDIR="\"/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1/install50/ssl\"" >> -DENGINESDIR="\"/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1/install50/lib/engines-1.1\"" >> -c -MMD -MF crypto/conf/conf_mod.d.tmp -MT crypto/conf/conf_mod.o -c -o >> crypto/conf/conf_mod.o crypto/conf/conf_mod.c >> crypto/conf/conf_mod.c: In function 'CONF_get1_default_config_file': >> crypto/conf/conf_mod.c:491:19: error: 'OPENSSL_CONF' undeclared (first >> use in this function) >> ???? len += strlen(OPENSSL_CONF); >> ?????????????????? ^ >> crypto/conf/conf_mod.c:491:19: note: each undeclared identifier is >> reported only once for each function it appears in >> Makefile:2305: recipe for target 'crypto/conf/conf_mod.o' failed >> make[1]: *** [crypto/conf/conf_mod.o] Error 1 >> make[1]: Leaving directory >> '/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1' >> Makefile:143: recipe for target 'all' failed >> make: *** [all] Error 2 >> >> Perhaps we are missing an include of: include/internal/cryptlib.h? ? > Hmm. That is very strange. The include of that header is right at the > top of that file. > > Could you provide explicitly the build steps you followed to produce > this result? > > Thanks > > Matt > > >> Norm >> From norm.green at gemtalksystems.com Wed Feb 14 03:58:34 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 13 Feb 2018 19:58:34 -0800 Subject: [openssl-users] OSSL_STORE_ctrl Message-ID: In 1.1.1 pre-relase 1, we have this new function: int OSSL_STORE_ctrl(OSSL_STORE_CTX *ctx, int cmd, ... /* args */); Would it be possible to add a version that takes va_args like this? int OSSL_STORE_vctrl(OSSL_STORE_CTX *ctx, int cmd, va_list args); OpenSSL already have this precedent in other places, such as with BIO_printf() / BIO_vprintf() Norm From maddi.nivedita at gmail.com Wed Feb 14 06:18:27 2018 From: maddi.nivedita at gmail.com (Nivedita) Date: Wed, 14 Feb 2018 11:48:27 +0530 Subject: [openssl-users] Fwd: DTLS over UDP In-Reply-To: References: <10616.1518547870@obiwan.sandelman.ca> Message-ID: Hi Michael, Please ignore the previous mail. By mistankely it got sent. I have provided my comments below. Thanks in advance. Regards, Nivedita On Wed, Feb 14, 2018 at 10:22 AM, Nivedita wrote: > Hi Michael, > > Thanks for the reply. > > I have mentioned the answers below. > > > On Wed, Feb 14, 2018 at 12:21 AM, Michael Richardson > wrote: > >> From: Michael Richardson >> To: openssl-users at openssl.org >> Subject: Re: [openssl-users] DTLS over UDP >> In-Reply-To: > ail.com> >> References: > ail.com> >> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 >> X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS at k9X%29-lHB$Ti.V>2bi.~ehC0 >> ;<'$9xN5Ub# >> z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m> MIME-Version: 1.0 >> Content-Type: multipart/signed; boundary="=-=-="; >> micalg=pgp-sha256; protocol="application/pgp-signature" >> Date: Tue, 13 Feb 2018 13:51:10 -0500 >> Message-ID: <10616.1518547870 at obiwan.sandelman.ca> >> >> --=-=-= >> Content-Type: text/plain >> >> >> Nivedita wrote: >> > I am trying to establish DTLS over UDP connection by using >> > DTLSv1_listen method . >> >> > I have followed the below steps - 1. Created a server socket and >> using >> > this socket created bio and ssl object. bio = >> > BIO_new_dgram(VI_sock,BIO_NOCLOSE)) SSL_set_bio(ssl,VP_bio,VP_bio); >> >> > 2. Enable cookie exchange on SSL object. SSL_set_options(ssl, >> > SSL_OP_COOKIE_EXCHANGE); >> >> > 3. Then started listening using dtlsv1_listen for the new client >> > connections. Once dtlsv1_listen is successful and i got the peer >> > address. >> >> okay. >> > Nivedita- Here the ssl object is created on the server socket and same ssl is passed to dtlsv1_listen method. > > Nivedita- All the above mentioned steps i am doing on server side . On > the client side i have already initiated ssl_connect. > On the server side when i am listening using > dtlsv1_listen method - > > while ( VI_res= DTLSv1_listen(VP_ssl, &VS_client_addr) > <= 0); > Now i got the client_addr from dtlsv1_listen method. > > >> > 4. Once i got the client address , i am creating one new socket >> > 5. With the new socket i tried to connect to client address. >> >> Do you mean, you call "SSL_connect()"? >> Or do you mean you bind(2) and connect(2) the socket. >> > Nivedita- Once i got the client address from dtlsv1_listen, i am creating one more socket , tried to connect the client address, which i have got in dtlsv1_listen method Vi_res= connect(new sockid, client_addr, sizeof (client addr)); > >> > 6. Then i am trying to do ssl_accept on the new socket by calling >> > bio_set_fd. >> >> > BIO_set_fd(SSL_get_rbio(ssl),VI_new_sock_id,BIO_NOCLOSE); >> >> > BIO_ctrl(SSL_get_rbio(VP_ssl),BIO_CTRL_DGRAM_SET_CONNECTED, 0, >> > &client_addr); >> >> > SSL_set_fd(ssl,VI_newsock_id); >> >> So, SSL_set_fd() will allocate a ne bio, which probably undoes the effect >> of calling BIO_CRTL_DGRAM_SET_CONNECTED. Since you have set the fd of >> the existing BIO, I think you can omit that line. >> >> Nivedita - I have removed SSL_set _fd and tried by doing BIO_set_fd and Bio_ctrl, but still ssl_accept always returns -1 and with error code of 2. VI_res = BIO_set_fd(SSL_get_rbio(VP_ ssl),VI_new_sock_id,BIO_NOCLOSE); VI_res = BIO_ctrl(SSL_get_rbio(VP_ssl),BIO_CTRL_DGRAM_SET_CONNECTED, 0, &client_addr); SSL_set_accept_state(VP_ssl); VI_res = SSL_accept(ssl); This ssl object is the same one which we have passed in dtlsv1_listen method. Actually i am trying to do the ssl_accept on the different socket for every client, even though dtlsv1_listen happens on server socket. Could you please let me know if it is possible. > > VI_res = SSL_accept(ssl); >> >> > But ssl_accept will always return error code 2 [ i.e want read or >> want >> > write] >> >> > But if i am doing ssl_accept without doing the step no 6 it it will >> be >> > successful. >> >> Yes. >> >> > Could someone please let us know how to switch to newly created >> socket, >> > so that it can start using newly created socket for further read and >> > write operations and original server socket will keep on listening >> for >> > new connections. >> >> Do you expect additional connections on the existing socket? >> I've been working on some new API to make this all easier. >> >> Nivedita - Yes, we have multiple peers which try to connect to same server,so in that case i need different sockets for listening operations and one for read/write operations [one for client] Your method may fail if you have bound your "listen" to :: (0.0.0.0), >> and you have multiple IPs. In my case, I expect connections over IPv6 LL >> addresses, and there are always multiple of those, and ifindex issues as >> well. >> >> -- >> ] Never tell me the odds! | ipv6 mesh >> networks [ >> ] Michael Richardson, Sandelman Software Works | network >> architect [ >> ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on >> rails [ >> >> >> --=-=-= >> Content-Type: application/pgp-signature; name="signature.asc" >> >> -----BEGIN PGP SIGNATURE----- >> >> iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqDM54ACgkQgItw+93Q >> 3WW8Lgf7BwdHZbo22nUphMoVOgBek6qciLPJsa7ggwx6y/pP6kvQX/3bMn4fCx8t >> 1H/LaTX2xgw8Incz/8RL4kkhfziDYUQJ5oe4cd4b4KIQuTLRLVELFw5RbNX4hmvx >> tGd+KK2LMshcw/0+d/pAVtJpUdriHxKtMa3OQ7Tc+Lnqm338FRIhhqxi9/7IljW+ >> KA+vYcsCcLIpnlHfB5JfKR0N9S2ga7cUPCi4u/PRAZqTXuet4IPqxJLDVuNwCH8/ >> sbh/yYhFGSPOQG/c0ZaE1TDkcwYeE/lpcofkRdi+FNgBlUtZd9XGag5BW/lA3Rd7 >> IOCLfEDZENxWk2ki+PhDFwam5QO/Vw== >> =v5TB >> -----END PGP SIGNATURE----- >> --=-=-=-- >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Feb 14 09:29:42 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 14 Feb 2018 10:29:42 +0100 (CET) Subject: [openssl-users] OSSL_STORE_ctrl In-Reply-To: References: Message-ID: <20180214.102942.874260236119625613.levitte@openssl.org> In message on Tue, 13 Feb 2018 19:58:34 -0800, Norm Green said: norm.green> In 1.1.1 pre-relase 1, we have this new function: norm.green> norm.green> int OSSL_STORE_ctrl(OSSL_STORE_CTX *ctx, int cmd, ... /* args */); norm.green> norm.green> Would it be possible to add a version that takes va_args like this? norm.green> norm.green> int OSSL_STORE_vctrl(OSSL_STORE_CTX *ctx, int cmd, va_list args); norm.green> norm.green> OpenSSL already have this precedent in other places, such as with norm.green> BIO_printf() / BIO_vprintf() Good idea, that can certainly be done. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From richmoore44 at gmail.com Wed Feb 14 16:27:26 2018 From: richmoore44 at gmail.com (Richard Moore) Date: Wed, 14 Feb 2018 16:27:26 +0000 Subject: [openssl-users] Openssl 1.1 / TLS 1.3 Message-ID: If I run the following: openssl-1.1.1pre1 ciphers -tls1_3 -v Then I get lots of ciphers, for example AES128-SHA however the latest draft TLS 1.3 RFC states: The list of supported symmetric algorithms has been pruned of all algorithms that are considered legacy. Those that remain all use Authenticated Encryption with Associated Data (AEAD) algorithms. This suggests that the ciphers command isn't working as intended. Should I file an issue in github? Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Feb 14 16:34:26 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 14 Feb 2018 16:34:26 +0000 Subject: [openssl-users] Openssl 1.1 / TLS 1.3 In-Reply-To: References: Message-ID: <1625cecb-1d23-3bed-2ddd-ab90222d4460@openssl.org> On 14/02/18 16:27, Richard Moore wrote: > If I run the following: > > ?openssl-1.1.1pre1 ciphers -tls1_3 -v The man page says this about the "-tls1_3" option: "In combination with the B<-s> option, list the ciphers which would be used if TLSv1.3 were negotiated." So you need to add "-s". If you do that then you only get the TLSv1.3 ciphers. It's a little strange that the option is ignored if no -s is supplied (you might think supplying -tls1_3 would automatically imply -s). But that is the way that all the -tls* options work, so this is nothing new in 1.1.1. Matt > > Then I get lots of ciphers, for example?AES128-SHA however the latest > draft TLS 1.3 RFC states: > > The list of supported symmetric algorithms has been pruned of all > algorithms that are considered legacy. Those that remain all use > Authenticated Encryption with Associated Data (AEAD) algorithms. > > This suggests that the ciphers command isn't working as intended. Should > I file an issue in github? > > Cheers > > Rich. > > > From richmoore44 at gmail.com Wed Feb 14 17:28:34 2018 From: richmoore44 at gmail.com (Richard Moore) Date: Wed, 14 Feb 2018 17:28:34 +0000 Subject: [openssl-users] Openssl 1.1 / TLS 1.3 In-Reply-To: <1625cecb-1d23-3bed-2ddd-ab90222d4460@openssl.org> References: <1625cecb-1d23-3bed-2ddd-ab90222d4460@openssl.org> Message-ID: On 14 February 2018 at 16:34, Matt Caswell wrote: > > > On 14/02/18 16:27, Richard Moore wrote: > > If I run the following: > > > > openssl-1.1.1pre1 ciphers -tls1_3 -v > > The man page says this about the "-tls1_3" option: > > "In combination with the B<-s> option, list the ciphers which would be > used if TLSv1.3 were negotiated." > > So you need to add "-s". If you do that then you only get the TLSv1.3 > ciphers. It's a little strange that the option is ignored if no -s is > supplied (you might think supplying -tls1_3 would automatically imply > -s). But that is the way that all the -tls* options work, so this is > nothing new in 1.1.1. > ?I see thanks. That's very confusing, but yeah it seems to be there since 1.1.0. How would you feel about that being the default? I'm a little bit unclear about what the point of the option is otherwise? Thanks Rich. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkario at redhat.com Wed Feb 14 19:39:45 2018 From: hkario at redhat.com (Hubert Kario) Date: Wed, 14 Feb 2018 20:39:45 +0100 Subject: [openssl-users] TLS 1.3 PSK test server setup Message-ID: <1693848.l3FjmQ6d8I@pintsize.usersys.redhat.com> How to start current master branch OpenSSL so that it will support static PSK key exchange in TLS1.3? with client running as: openssl s_client -psk aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa I've tried: openssl s_server -psk aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa -nocert that produces 139823110240000:error:14201076:SSL routines:tls_choose_sigalg:no suitable signature algorithm:ssl/t1_lib.c:2433: and a handshake_failure alert sent to client and I've also tried openssl s_server -psk aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa -cert cert.pem -key key.pem (where cert and key pem are just self signed RSA cert and key) that establishes a TLS1.3 connection, but the ServerHello does not include pre_shared_key extension, just 43 (selected version) and 51 (key share), so the PSK mode was not used connecting with s_client -tls1_2 a PSK cipher is selected (DHE-PSK-AES256-GCM- SHA384) and in TLS1.3 I see both the pre_shared_key extension and the psk_key_exchange_modes extension in client hello, so I'm really confused why it doesn't work. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From bravo.echo.one at gmail.com Wed Feb 14 21:33:36 2018 From: bravo.echo.one at gmail.com (Sakuma, Koshiro) Date: Thu, 15 Feb 2018 06:33:36 +0900 Subject: [openssl-users] error (openssl-1.1.0g) Message-ID: Hi, Team, I'm trying to install openssl-1.1.0g on my CentOS7, but I've gotten error during do the "make test" phase. The error I've gotten is as follows. ------------------------------------------------------------ ----------------------------------------------------------------- ./test/recipes/40-test_rehash.t ........... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/5 subtests Test Summary Report ------------------- ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=95, Tests=554, 34 wallclock secs ( 0.32 usr 0.09 sys + 25.56 cusr 9.26 csys = 35.23 CPU) Result: FAIL make[1]: *** [_tests] Error 1 make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g make[1]:***[tests] error 2 ------------------------------------------------------------ ----------------------------------------------------------------- The command I tried to do was like "config --prefix=/usr/local/openssl shared zlib OR config shared OR config. The OS version is CentOS Linux release 7.4.1708 (Core). I am not sure if I can ignore this error and move forward to do "make". Thank you so much for your support. Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Wed Feb 14 21:57:54 2018 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 14 Feb 2018 21:57:54 +0000 Subject: [openssl-users] error (openssl-1.1.0g) In-Reply-To: References: Message-ID: Funny. I have the same problem with the current master on one of my two MacOS High Sierra machines. Surprisingly, the other machine builds and runs the current master just fine. Configuration and build scripts are automated and exactly the same between the two. The ?bad? machine runs a bunch of compliance-related software, but it did not seem to interfere with the previous OpenSSL code drops. -- Regards, Uri Blumenthal From: openssl-users on behalf of "Sakuma, Koshiro" Reply-To: "openssl-users at openssl.org" Date: Wednesday, February 14, 2018 at 16:33 To: "openssl-users at openssl.org" Subject: [openssl-users] error (openssl-1.1.0g) Hi, Team, I'm trying to install openssl-1.1.0g on my CentOS7, but I've gotten error during do the "make test" phase. The error I've gotten is as follows. ----------------------------------------------------------------------------------------------------------------------------- ./test/recipes/40-test_rehash.t ........... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/5 subtests Test Summary Report ------------------- ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=95, Tests=554, 34 wallclock secs ( 0.32 usr 0.09 sys + 25.56 cusr 9.26 csys = 35.23 CPU) Result: FAIL make[1]: *** [_tests] Error 1 make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g make[1]:***[tests] error 2 ----------------------------------------------------------------------------------------------------------------------------- The command I tried to do was like "config --prefix=/usr/local/openssl shared zlib OR config shared OR config. The OS version is CentOS Linux release 7.4.1708 (Core). I am not sure if I can ignore this error and move forward to do "make". Thank you so much for your support. Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From bravo.echo.one at gmail.com Wed Feb 14 22:17:21 2018 From: bravo.echo.one at gmail.com (Sakuma, Koshiro) Date: Thu, 15 Feb 2018 07:17:21 +0900 Subject: [openssl-users] error (openssl-1.1.0g) In-Reply-To: References: Message-ID: Hi, Uri, Thanks for your feedback. You think it might be something like "BUG"?? Anyway, you are also waiting for the answers right? Regards, 2018-02-15 6:57 GMT+09:00 Blumenthal, Uri - 0553 - MITLL : > Funny. I have the same problem with the current master on one of my two > MacOS High Sierra machines. Surprisingly, the other machine builds and runs > the current master just fine. Configuration and build scripts are automated > and exactly the same between the two. > > > > The ?bad? machine runs a bunch of compliance-related software, but it did > not seem to interfere with the previous OpenSSL code drops. > > -- > > Regards, > > Uri Blumenthal > > *From: *openssl-users on behalf of > "Sakuma, Koshiro" > *Reply-To: *"openssl-users at openssl.org" > *Date: *Wednesday, February 14, 2018 at 16:33 > *To: *"openssl-users at openssl.org" > *Subject: *[openssl-users] error (openssl-1.1.0g) > > > > Hi, Team, > > > > I'm trying to install openssl-1.1.0g on my CentOS7, but I've gotten error > during do the "make test" phase. The error I've gotten is as follows. > > > > ------------------------------------------------------------ > ----------------------------------------------------------------- > > ./test/recipes/40-test_rehash.t ........... Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/5 subtests > > > > Test Summary Report > > ------------------- > > ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) > > Failed test: 4 > > Non-zero exit status: 1 > > Files=95, Tests=554, 34 wallclock secs ( 0.32 usr 0.09 sys + 25.56 cusr > 9.26 csys = 35.23 CPU) > > Result: FAIL > > make[1]: *** [_tests] Error 1 > > make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g > > make[1]:***[tests] error 2 > > ------------------------------------------------------------ > ----------------------------------------------------------------- > > > > The command I tried to do was like "config --prefix=/usr/local/openssl > shared zlib OR config shared OR config. > > > > The OS version is CentOS Linux release 7.4.1708 (Core). > > > > I am not sure if I can ignore this error and move forward to do "make". > > > > Thank you so much for your support. > > > > Regards, > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Wed Feb 14 22:25:36 2018 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 14 Feb 2018 22:25:36 +0000 Subject: [openssl-users] error (openssl-1.1.0g) In-Reply-To: References: Message-ID: Thanks for your feedback. You?re welcome. You think it might be something like "BUG"?? Probably yes ? but the question is whether it?s with the new OpenSSL test infrastructure, or something with how one of my machines is configured. I do not know. Anyway, you are also waiting for the answers right? Yes I certainly am. 2018-02-15 6:57 GMT+09:00 Blumenthal, Uri - 0553 - MITLL : Funny. I have the same problem with the current master on one of my two MacOS High Sierra machines. Surprisingly, the other machine builds and runs the current master just fine. Configuration and build scripts are automated and exactly the same between the two. The ?bad? machine runs a bunch of compliance-related software, but it did not seem to interfere with the previous OpenSSL code drops. -- Regards, Uri Blumenthal From: openssl-users on behalf of "Sakuma, Koshiro" Reply-To: "openssl-users at openssl.org" Date: Wednesday, February 14, 2018 at 16:33 To: "openssl-users at openssl.org" Subject: [openssl-users] error (openssl-1.1.0g) Hi, Team, I'm trying to install openssl-1.1.0g on my CentOS7, but I've gotten error during do the "make test" phase. The error I've gotten is as follows. ----------------------------------------------------------------------------------------------------------------------------- ./test/recipes/40-test_rehash.t ........... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/5 subtests Test Summary Report ------------------- ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=95, Tests=554, 34 wallclock secs ( 0.32 usr 0.09 sys + 25.56 cusr 9.26 csys = 35.23 CPU) Result: FAIL make[1]: *** [_tests] Error 1 make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g make[1]:***[tests] error 2 ----------------------------------------------------------------------------------------------------------------------------- The command I tried to do was like "config --prefix=/usr/local/openssl shared zlib OR config shared OR config. The OS version is CentOS Linux release 7.4.1708 (Core). I am not sure if I can ignore this error and move forward to do "make". Thank you so much for your support. Regards, -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From rsalz at akamai.com Wed Feb 14 22:28:08 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 14 Feb 2018 22:28:08 +0000 Subject: [openssl-users] error (openssl-1.1.0g) In-Reply-To: References: Message-ID: <5833C84B-9C58-41F6-AD39-3B057ECCBC07@akamai.com> For the failing test, try this make TESTS=test_rehash V=1 tests -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Feb 14 23:14:05 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 14 Feb 2018 23:14:05 +0000 Subject: [openssl-users] TLS 1.3 PSK test server setup In-Reply-To: <1693848.l3FjmQ6d8I@pintsize.usersys.redhat.com> References: <1693848.l3FjmQ6d8I@pintsize.usersys.redhat.com> Message-ID: <5ffe8138-83d7-698e-15fb-b078ee196efa@openssl.org> On 14/02/18 19:39, Hubert Kario wrote: > How to start current master branch OpenSSL so that it will support static PSK > key exchange in TLS1.3? > > with client running as: > openssl s_client -psk > aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa > > I've tried: > openssl s_server -psk > aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa -nocert > > that produces > 139823110240000:error:14201076:SSL routines:tls_choose_sigalg:no suitable > signature algorithm:ssl/t1_lib.c:2433: > and a handshake_failure alert sent to client > > and I've also tried > openssl s_server -psk > aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa -cert > cert.pem -key key.pem > (where cert and key pem are just self signed RSA cert and key) For a PSK to be used in needs to be the correct length for the selected ciphersuite. The ciphersuite is selected *first*. Next the available PSKs are checked to see if they are usable with that ciphersuite. By default s_client talking to s_server will select TLS13-AES-256-GCM-SHA384. Because this is based on SHA384 we need a key which is 48 bytes long (96 hex digits). Your key is 32 bytes long (64 hex digits) so the PSK is ignored. Matt From matt at openssl.org Thu Feb 15 00:44:26 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 15 Feb 2018 00:44:26 +0000 Subject: [openssl-users] error (openssl-1.1.0g) In-Reply-To: References: Message-ID: Did you run "make test" as root by any chance? There is a known issue where this test fails if you run it as root (fixed in git by commit b15e62ecc). Matt On 14/02/18 21:33, Sakuma, Koshiro wrote: > Hi, Team, > > I'm trying to install openssl-1.1.0g on my CentOS7, but I've gotten > error during do the "make test" phase.? The error I've gotten is as follows. > > ----------------------------------------------------------------------------------------------------------------------------- > ./test/recipes/40-test_rehash.t ........... Dubious, test returned 1 > (wstat 256, 0x100) > Failed 1/5 subtests > > Test Summary Report > ------------------- > ../test/recipes/40-test_rehash.t? ? ? ? ?(Wstat: 256 Tests: 5 Failed: 1) > ? Failed test:? 4 > ? Non-zero exit status: 1 > Files=95, Tests=554, 34 wallclock secs ( 0.32 usr? 0.09 sys + 25.56 > cusr? 9.26 csys = 35.23 CPU) > Result: FAIL > make[1]: *** [_tests] Error 1 > make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g > make[1]:***[tests] error 2 > ----------------------------------------------------------------------------------------------------------------------------- > > The command I tried to do was like "config --prefix=/usr/local/openssl > shared zlib OR config shared OR config. > > The OS version is?CentOS Linux release 7.4.1708 (Core). > > I am not sure if I can ignore this error and move forward to do "make".? > > Thank you so much for your support. > > Regards, > > > From curt at strategix.se Thu Feb 15 03:52:46 2018 From: curt at strategix.se (Curt Johansson) Date: Thu, 15 Feb 2018 04:52:46 +0100 Subject: [openssl-users] Explicit IV in TLS 1.1+ In-Reply-To: References: <69BB651F-E746-49CC-A032-FA838309C3B7@strategix.se> Message-ID: Hi Matt, thanks for your prompt answer. The testclient is using openssl-1.0.2m and my previous assumption that the IV was derived from the key_block as in TLS 1.0 was wrong. It seems that when initialising the cipher with the IV is ignored when the crypto is AES and the first 16 bytes of the encrypted payload is used as IV (as per TLS spec). This is a Java issue and has nothing to do with OpenSSL but assuming this is correct behaviour (I'll have to dig in to that) I use the same logic (in this respect) for TLS1.1 and TLS1.2 assuming that the client also does which it obviously does not. Below is the logging from my server handling two authentications (the Finished message that is the first encrypted). The first (TLS1.1) succeeds and the second (1.2) fails. You can see that the decrypted text is correctly padded in the first case (TLS 1.1) indicating that the decryption succeeded but the second (1.2) decrypted buffer does not. The "Finished" message for this (AES; SHA) mac- and block size should be padded with 11 bytes which the first is. Also as seen I use the same provider and algoritm in the two cases, actually I handle the decryption in the same way for the two TLS-levels Also added the wireshark output for the two authentications where I've verified that the logged encrypted data really is whats coming in on the line. Basically when selecting 1.1 in the client everything works as expected but selecting 1.2 the prepended IV is not correct as far as I understand. The testclient vendor says they are using OpenSLL for TLS handling so I expect that they're not fiddling with any IV bytes at all. Given the version 1.0.2m, can this be explained? Best Curt -------------- next part -------------- A non-text attachment was scrubbed... Name: TLS11-TLS12.pcapng Type: application/octet-stream Size: 14640 bytes Desc: not available URL: -------------- next part -------------- TLS 1.1 04:09:40.295 Cipher provider: SunJCE 04:09:40.295 Cipher algoritm: AES/CBC/NoPadding 04:09:40.295 IV from key_block used in cipher init: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] 04:09:40.295 Encrypted: [f5, 21, 77, 27, f7, bf, 31, 1f, b9, 74, 14, 50, be, 5f, 66, 21, 1b, 4e, b, 33, 78, 3b, b8, 31, a3, 7c, c2, 93, f6, ec, a, 8f, c4, 28, 71, cb, 82, b4, 12, c2, 6b, 56, f2, 9e, c8, b0, 2b, 64, 7c, 89, ef, bb, 68, 6b, 73, 6b, 80, 3a, 1b, 7, 33, 4e, 36, 6b] 04:09:40.296 Decrypted: [a6, c7, bc, 87, 7, 2, 85, c, c3, c7, 91, 73, b3, 85, 19, 21, 14, 0, 0, c, 1, 6f, 1e, 4e, 97, d0, c4, 10, a9, 35, 37, bc, 2a, 87, 79, 78, 4c, 4, 88, a1, fd, 35, 42, 26, 56, 51, b3, 36, d, 3b, be, 4a, b, b, b, b, b, b, b, b, b, b, b, b] TLS 1.2 04:09:47.779 Cipher provider: SunJCE 04:09:47.779 Cipher algoritm: AES/CBC/NoPadding 04:09:47.779 IV from key_block used in cipher init: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] 04:09:47.779 Encrypted: [80, 83, 98, 6b, 55, 98, 73, b4, f6, 22, 2d, 88, b, 4d, af, 6f, 2d, d6, 1e, 9, 1d, b1, 94, f4, 49, 20, 15, d2, a0, a0, 35, c5, 95, 3d, d3, 35, fd, 92, ef, a6, 0, 7d, 49, 3, 70, 5e, 5a, 57, e3, f9, 89, 3f, 83, 11, cf, 82, 4e, a3, 87, 6e, 9e, 97, 9c, 7c] 04:09:47.779 Decrypted: [f1, 4e, b3, 18, 26, d7, ae, 12, bf, 5d, fe, 2a, 18, a1, 6f, 19, 60, 73, 26, c8, 74, 7c, c6, a6, a1, 65, d3, ad, 45, f9, e3, 42, aa, e0, bd, 1d, a0, 18, b3, f3, 94, 28, 4e, 2a, ca, 24, 25, 70, 7c, a9, f6, 19, 17, f5, ef, ee, b, 30, 2f, ec, 4d, b3, 9c, 8b] > On 14 Feb 2018, at 0:26 , Matt Caswell wrote: > > > > On 13/02/18 22:02, Curt Johansson wrote: >> Hi all, >> >> I'm developing support for TLS 1.1 and 1.2 in a radius-server that until now only handles TLS 1.0. I'm testing with a testtool that the vendor says is >> using OpenSSL to implement the TLS support. It all seems to work except for the following: >> >> When all key exchange messages are sent from the server and back from the client the client sends the "Finished" message which >> is the first encrypted with the negotiated symmetric cipher suite. I use AES-128 in block mode and according to the spec (RFC4346 for TLS 1.1) >> the IV is prepended to the encrypted message (containing the payload, MAC and padding). The message size i right and when (in the server) I use the first 16 bytes >> of the message received from the client as IV the decryption fails but when I use the mechanism from TLS 1.0 to pick up the IV from >> the key_block the decryption is successful. I understand that this is one way to generate the IV that I suppose you use which is fine but >> shouldn't this 16 byte vector be prepended, unecrypted, to the encrypted data that is sent to the server? In TLS 1.2 there is not IV material generated >> at all in the key_block so in that case I don't even know where to find it. >> >> The simple question is, shouldn't the first 16 bytes (assuming AES) of the message (after the 5 byte header) be the unencrypted IV to be used in the decryption of the rest of the message? > > Yes, assuming you have negotiated an AES CBC ciphersuite in TLSv1.1 or > TLSv1.2, then that is what happens. You don't say what version of > OpenSSL you are using. Here is the code that does it for 1.1.1 (i.e. > master branch): > > https://github.com/openssl/openssl/blob/master/ssl/record/ssl3_record.c#L954 > > As can be seen on line 969 we just fill the IV with random bytes. > > Perhaps you could provide a wireshark trace of the handshake which might > provide some enlightenment as to what is happening. > > Matt > > >> >> I tried to dig in to the OpenSSL source but it's far too long ago I did some serious C coding so I hope someone with a working knowledge can enlighten me. I might have >> misunderstood the spec but in that case I would be grateful if someone could clarify this specific part of it. >> >> TIA >> Curt Johansson >> > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From bravo.echo.one at gmail.com Thu Feb 15 04:03:25 2018 From: bravo.echo.one at gmail.com (Sakuma, Koshiro) Date: Thu, 15 Feb 2018 13:03:25 +0900 Subject: [openssl-users] error (openssl-1.1.0g) In-Reply-To: References: Message-ID: Hi, Matt, Yes, I did with root user, but it was failed like "access denied" when I tried to do with normal user account. Also, I didn't get any error messages like "root" user or something in the log file. Regards 2018-02-15 9:44 GMT+09:00 Matt Caswell : > Did you run "make test" as root by any chance? There is a known issue > where this test fails if you run it as root (fixed in git by commit > b15e62ecc). > > Matt > > On 14/02/18 21:33, Sakuma, Koshiro wrote: > > Hi, Team, > > > > I'm trying to install openssl-1.1.0g on my CentOS7, but I've gotten > > error during do the "make test" phase. The error I've gotten is as > follows. > > > > ------------------------------------------------------------ > ----------------------------------------------------------------- > > ./test/recipes/40-test_rehash.t ........... Dubious, test returned 1 > > (wstat 256, 0x100) > > Failed 1/5 subtests > > > > Test Summary Report > > ------------------- > > ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) > > Failed test: 4 > > Non-zero exit status: 1 > > Files=95, Tests=554, 34 wallclock secs ( 0.32 usr 0.09 sys + 25.56 > > cusr 9.26 csys = 35.23 CPU) > > Result: FAIL > > make[1]: *** [_tests] Error 1 > > make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g > > make[1]:***[tests] error 2 > > ------------------------------------------------------------ > ----------------------------------------------------------------- > > > > The command I tried to do was like "config --prefix=/usr/local/openssl > > shared zlib OR config shared OR config. > > > > The OS version is CentOS Linux release 7.4.1708 (Core). > > > > I am not sure if I can ignore this error and move forward to do "make". > > > > Thank you so much for your support. > > > > Regards, > > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From etc at coderhacks.com Thu Feb 15 05:29:23 2018 From: etc at coderhacks.com (etc at coderhacks.com) Date: Thu, 15 Feb 2018 06:29:23 +0100 Subject: [openssl-users] SMIME_read_CMS and binary signature Message-ID: <588cb7a7-b31e-ad93-a9ea-41009b38786d@coderhacks.com> Hello! I need a little hint for parsing SMIME into a CMS_ContentInfo. Here is an shortend example of my SMIME to make clear the structure of my content. ==================== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="----=_Part_abcde" ------=_Part_abcde Content-Type: application/text; name=abc.txt Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=abc.txt VU...Cc= ------=_Part_abcde Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIA...AAA= ------=_Part_abcde-- ==================== If I try SMIME_read_CMS it is working well if the signature (the 2nd MIME-part with smime-type=singed-data) has a Content-Transfer-Encodeing of "base64" (as it is in my example) But It is not working if the CTE is "binary" and also the content is. If I manually convert the signature to base64 and change the CTE to base64 the SMIME_read_CMS is working again. Is there another way of handling that? Maybe another function? Thanks for help! Best regards, Chris From openssl-users at dukhovni.org Thu Feb 15 05:43:11 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 15 Feb 2018 00:43:11 -0500 Subject: [openssl-users] SMIME_read_CMS and binary signature In-Reply-To: <588cb7a7-b31e-ad93-a9ea-41009b38786d@coderhacks.com> References: <588cb7a7-b31e-ad93-a9ea-41009b38786d@coderhacks.com> Message-ID: <0E37994F-29CF-4570-880E-D206D0FB5FCF@dukhovni.org> > On Feb 15, 2018, at 12:29 AM, etc at coderhacks.com wrote: > > If I try SMIME_read_CMS it is working well if the signature (the 2nd MIME-part with smime-type=singed-data) > has a Content-Transfer-Encodeing of "base64" (as it is in my example) > > But It is not working if the CTE is "binary" and also the content is. "binary" is not valid Content-Transfer-Encoding for SMIME. RFC 2045 Section 6.2: Mail transport for unencoded 8bit data is defined in RFC 1652. As of the initial publication of this document, there are no standardized Internet mail transports for which it is legitimate to include unencoded binary data in mail bodies. Thus there are no circumstances in which the "binary" Content-Transfer-Encoding is actually valid in Internet mail. However, in the event that binary mail transport becomes a reality in Internet mail, or when MIME is used in conjunction with any other binary-capable mail transport mechanism, binary bodies must be labelled as such using this mechanism. Even if such a binary transport existed, there is no mechanism to embed non line-oriented data inside a line-oriented MIME multipart. If you want binary data, use DER-encoded CMS objects not SMIME. -- Viktor. From beldmit at gmail.com Thu Feb 15 08:00:00 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 15 Feb 2018 11:00:00 +0300 Subject: [openssl-users] Building OpenSSL from sources Message-ID: Hello, I get problems building and installing OpenSSL 1.1.0g from source. I use Debian Wheezy (oldstable). After running ./config; make; make test; sudo make install I call /usr/local/bin/openssl I get an error /usr/local/bin/openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory $ ldd /usr/local/bin/openssl libssl.so.1.1 => not found libcrypto.so.1.1 => not found This behavior differs from the one for version 1.1.0b, where everything works fine. According to CHANGES in 1.1.0c *) Removed automatic addition of RPATH in shared libraries and executables, as this was a remainder from OpenSSL 1.0.x and isn't needed any more. [Richard Levitte] Could you please clarify why this changes were introduced? Shouldn't the INSTALL file be changed to document this change because the proposed way ( ./config; make; make test; make install) does not work? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From wouter.verhelst at bosa.fgov.be Thu Feb 15 08:20:52 2018 From: wouter.verhelst at bosa.fgov.be (Wouter Verhelst) Date: Thu, 15 Feb 2018 09:20:52 +0100 Subject: [openssl-users] Building OpenSSL from sources In-Reply-To: References: Message-ID: <13f43d52-c4b9-1e6d-e6f8-528b6b052cbf@bosa.fgov.be> Hi Dmitry, On 15-02-18 09:00, Dmitry Belyavsky wrote: > Hello, > > I get problems building and installing OpenSSL 1.1.0g from source. I > use Debian Wheezy (oldstable). > > After running ./config; make; make test; sudo make install? > > I call? /usr/local/bin/openssl? > > I get an error? > > /usr/local/bin/openssl: error while loading shared libraries: > libssl.so.1.1: cannot open shared object file: No such file or directory > > $ ldd /usr/local/bin/openssl? > ? ? ? ? libssl.so.1.1 => not found > ? ? ? ? libcrypto.so.1.1 => not found > > This behavior differs from the one for version 1.1.0b, where > everything works fine.? > > According to CHANGES in 1.1.0c > > ?*) Removed automatic addition of RPATH in shared libraries and > executables, > ? ? ?as this was a remainder from OpenSSL 1.0.x and isn't needed any more. > ? ? ?[Richard Levitte] > > Could you please clarify why this changes were introduced? RPATH has certain semantics which are unexpected for some users (e.g., copying files around and updating ld.so.conf won't work). They have their uses, but a build system using them *by default* is not necessarily a good idea. > Shouldn't the INSTALL file be changed to document this change? > because the proposed way ( ?./config; make; make test; make install) > does not work? It should, but you may have to check your dynamic linker configuration to make sure that the library in which libssl is installed is found in your library search path. Check /etc/ld.so.conf (and directories included from that file, if any) to make sure that it contains the directory where libssl.so ends up. If it does not, add it, and then run 'ldconfig' without arguments to update the cache. From levitte at openssl.org Thu Feb 15 08:48:02 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 15 Feb 2018 09:48:02 +0100 (CET) Subject: [openssl-users] Building OpenSSL from sources In-Reply-To: References: Message-ID: <20180215.094802.1191100845499196579.levitte@openssl.org> In message on Thu, 15 Feb 2018 11:00:00 +0300, Dmitry Belyavsky said: beldmit> Hello, beldmit> beldmit> I get problems building and installing OpenSSL 1.1.0g from source. I use Debian Wheezy beldmit> (oldstable). beldmit> beldmit> After running ./config; make; make test; sudo make install beldmit> beldmit> I call /usr/local/bin/openssl beldmit> beldmit> I get an error beldmit> beldmit> /usr/local/bin/openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object beldmit> file: No such file or directory beldmit> beldmit> $ ldd /usr/local/bin/openssl beldmit> libssl.so.1.1 => not found beldmit> libcrypto.so.1.1 => not found beldmit> beldmit> This behavior differs from the one for version 1.1.0b, where everything works fine. beldmit> beldmit> According to CHANGES in 1.1.0c beldmit> beldmit> *) Removed automatic addition of RPATH in shared libraries and executables, beldmit> as this was a remainder from OpenSSL 1.0.x and isn't needed any more. beldmit> [Richard Levitte] beldmit> beldmit> Could you please clarify why this changes were introduced? The change was made for a very specific reason, it screwed up testing, and here's how. On GNU systems (for example Linux), '-Wl,-rpath,/path/to/installed/lib' sets DT_RPATH. If you read the ld.so manual, you will see that DT_RPATH is used before anything else that affects what directories are looked into, including LD_LIBRARY_PATH. This meant that when running a new build of 'openssl' before installing it, it would look for a previously installed version of the libraries instead of those in the build directory. A solution that we did use was to use LD_PRELOAD, which comes before even DT_RPATH. This worked well for quite a while. Enter asan and ubsan. I don't remember which one it was, but I think it was one of those that was royally screwed up by our preloading the shared libraries in the build directory. It simply didn't work. There is of course the solution to use '-Wl,--enable-new-dtags,-rpath, /path/to/installed/lib', but that wouldn't work on older ELF systems Another factor in all of this is that the reason we used -rpath to begin with was that up until OpenSSL 1.0.2, we installed the libraries in a non-standard directory (/usr/local/ssl/lib) by default. This is not longer so, the default location is /usr/local/lib, which should be one of the standard ld.so directories. In the end, we (or I, I don't remember) concluded that we didn't actually need a compulsary use of -rpath and that this should be left to the user. beldmit> Shouldn't the INSTALL file be changed to document this change beldmit> because the proposed way ( ./config; make; make test; make beldmit> install) does not work? Actually, this is documented, in NOTES.UNIX, which is mentioned in the beginning of INSTALL: For additional platform specific requirements, solutions to specific issues and other details, please read one of these: * NOTES.UNIX (any supported Unix like system) * NOTES.VMS (OpenVMS) * NOTES.WIN (any supported Windows) * NOTES.DJGPP (DOS platform with DJGPP) You see, INSTALL is supposed to be fairly platform agnostic... Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From bravo.echo.one at gmail.com Thu Feb 15 08:52:54 2018 From: bravo.echo.one at gmail.com (Sakuma, Koshiro) Date: Thu, 15 Feb 2018 17:52:54 +0900 Subject: [openssl-users] error (openssl-1.1.0g) In-Reply-To: <5833C84B-9C58-41F6-AD39-3B057ECCBC07@akamai.com> References: <5833C84B-9C58-41F6-AD39-3B057ECCBC07@akamai.com> Message-ID: Hi, Rich, Here is the result. However, I tried to do the "config" with normal user and I got an error like you don't have permission. You have any ideas?? # Failed test 'Testing that we aren't running as a privileged user, such as root' # at ../test/recipes/40-test_rehash.t line 49. ok 5 # skip It's pointless to run the next test as root # Looks like you failed 1 test of 5. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/5 subtests (less 1 skipped subtest: 3 okay) Test Summary Report ------------------- ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=1, Tests=5, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr 0.03 csys = 0.10 CPU) Result: FAIL make[1]: *** [_tests] Error 1 make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g' 2018-02-15 7:28 GMT+09:00 Salz, Rich : > For the failing test, try this > > make TESTS=test_rehash V=1 tests > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Feb 15 09:46:18 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 15 Feb 2018 09:46:18 +0000 Subject: [openssl-users] Openssl 1.1 / TLS 1.3 In-Reply-To: References: <1625cecb-1d23-3bed-2ddd-ab90222d4460@openssl.org> Message-ID: On 14/02/18 17:28, Richard Moore wrote: > > > On 14 February 2018 at 16:34, Matt Caswell > wrote: > > > > On 14/02/18 16:27, Richard Moore wrote: > > If I run the following: > > > > ?openssl-1.1.1pre1 ciphers -tls1_3 -v > > The man page says this about the "-tls1_3" option: > > "In combination with the B<-s> option, list the ciphers which would be > used if TLSv1.3 were negotiated." > > So you need to add "-s". If you do that then you only get the TLSv1.3 > ciphers. It's a little strange that the option is ignored if no -s is > supplied (you might think supplying -tls1_3 would automatically imply > -s). But that is the way that all the -tls* options work, so this is > nothing new in 1.1.1. > > > ?I see thanks. That's very confusing, but yeah it seems to be there > since 1.1.0. How would you feel about that being the default? I'm a > little bit unclear about what the point of the option is otherwise? We're always a bit wary about changing the behaviour of command line app options. It has a tendency to "bite" us in unexpected ways (where people are relying on the behaviour being one way, and suddenly it changes). In particular 1.1.1 is supposed to be completely compatible with 1.1.0. Having said that its difficult to see what would break if we made it that specifying one of those options implicitly sets "-s" too. Or alternatively we could perhaps print a warning if you specify one of these options without -s. Matt From bravo.echo.one at gmail.com Thu Feb 15 10:43:07 2018 From: bravo.echo.one at gmail.com (Sakuma, Koshiro) Date: Thu, 15 Feb 2018 19:43:07 +0900 Subject: [openssl-users] error (openssl-1.1.0g) In-Reply-To: References: <5833C84B-9C58-41F6-AD39-3B057ECCBC07@akamai.com> Message-ID: Hi, Please let me know how I can compile the source with normal user account instead of root? The error I got was like "You don't have permission" after executing "config". Regards, 2018-02-15 17:52 GMT+09:00 Sakuma, Koshiro : > Hi, Rich, > > Here is the result. However, I tried to do the "config" with normal user > and I got an error like you don't have permission. > You have any ideas?? > > # Failed test 'Testing that we aren't running as a privileged user, such > as root' > # at ../test/recipes/40-test_rehash.t line 49. > ok 5 # skip It's pointless to run the next test as root > # Looks like you failed 1 test of 5. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/5 subtests > (less 1 skipped subtest: 3 okay) > > Test Summary Report > ------------------- > ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) > Failed test: 4 > Non-zero exit status: 1 > Files=1, Tests=5, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr > 0.03 csys = 0.10 CPU) > Result: FAIL > make[1]: *** [_tests] Error 1 > make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g' > > > > 2018-02-15 7:28 GMT+09:00 Salz, Rich : > >> For the failing test, try this >> >> make TESTS=test_rehash V=1 tests >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maddi.nivedita at gmail.com Thu Feb 15 10:47:38 2018 From: maddi.nivedita at gmail.com (Nivedita) Date: Thu, 15 Feb 2018 16:17:38 +0530 Subject: [openssl-users] DTLS over UDP In-Reply-To: <5049.1518629142@obiwan.sandelman.ca> References: <10616.1518547870@obiwan.sandelman.ca> <5049.1518629142@obiwan.sandelman.ca> Message-ID: Hi Michael, Please find the response inline. Regards, Nivedita On Wed, Feb 14, 2018 at 10:55 PM, Michael Richardson wrote: > > Nivedita wrote: > > Hi Michael, > > > Thanks for the reply. > > > I have mentioned the answers below. > > >okay. I saw only one comment. Maybe you could use standard usenet > quoting? > >Tell me a bit more about what you are working on? > >I'm trying to make CoAP+DTLS work with the ruby-on-rails "David" CoAP > server. > Nivedita - We are using c and Socket programming to establish dtls over udp for sip communication. > > Nivedita wrote: > >> I am trying to establish DTLS over UDP connection by using > >> DTLSv1_listen method . > > >> I have followed the below steps - 1. Created a server socket and > using > >> this socket created bio and ssl object. bio = > >> BIO_new_dgram(VI_sock,BIO_NOCLOSE)) SSL_set_bio(ssl,VP_bio,VP_bio); > > >> 2. Enable cookie exchange on SSL object. SSL_set_options(ssl, > >> SSL_OP_COOKIE_EXCHANGE); > > >> 3. Then started listening using dtlsv1_listen for the new client > >> connections. Once dtlsv1_listen is successful and i got the peer > >> address. > > mcr> okay. > > > > Nivedita- All the above mentioned steps i am doing on server side . > On the > > client side i have already initiated ssl_connect. > > On the server side when i am listening using dtlsv1_listen method - > > >> 4. Once i got the peer address , i am creating one more socket > >> 5. With the new socket i tried to connect to peer address. > > > mcr> Do you mean, you call "SSL_connect()"? > > mcr> Or do you mean you bind(2) and connect(2) the socket. > >You didn't answer this. >You imply you might have tried "SSL_connect()" on the server side. Nivedita - SSL_connect is already issued on client side , because of which it triggered the server and dtlsv1_listen was successful and i got the peer address from dtlsv1_listen. > Then once i got the client address from the dtlsv1_listen > method, i am creating one more socket and trying to connect to this > client address. > Vi_res= connect(new sockid, client_addr, sizeof (client addr)); I am able to connect to client address which i got in dtlsv1_listen method using new socket id. and i want to do the ssl_accept on the new socket id by issuing bio_set_fd and bio_ctrl. But ssl_accept fails with error code 2. BIO_set_fd(SSL_get_rbio(ssl),VI_new_sock_id,BIO_NOCLOSE); BIO_ctrl(SSL_get_rbio(VP_ssl),BIO_CTRL_DGRAM_SET_CONNECTED, 0, &client_addr) ssl_accept (VP_ssl) I would like to mention that VP_ssl is created using server socket id, but we are trying to do ssl_accept on newly created socket id which is connected to peer address[got from dtlsv1_listen method) , so that we can use this socket for further read-write operations and server socket for listening operations. > > > >> 6. Then i am trying to do ssl_accept on the new socket by calling > >> bio_set_fd. > > >> BIO_set_fd(SSL_get_rbio(ssl),VI_new_sock_id,BIO_NOCLOSE); > > >> BIO_ctrl(SSL_get_rbio(VP_ssl),BIO_CTRL_DGRAM_SET_CONNECTED, 0, > >> &client_addr); > > >> SSL_set_fd(ssl,VI_newsock_id); > > mcr> So, SSL_set_fd() will allocate a ne bio, which probably undoes > the effect > mcr> of calling BIO_CRTL_DGRAM_SET_CONNECTED. Since you have set the > fd of > mcr> the existing BIO, I think you can omit that line. > > Please omit the SSL_set_fd(), since you've already done it. > > I have a pull request at: > https://github.com/openssl/openssl/pull/5024 > > which I am reworking to suit the OpenSSL team. > I am solving the same problem that you have encountered. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bravo.echo.one at gmail.com Thu Feb 15 10:52:32 2018 From: bravo.echo.one at gmail.com (Sakuma, Koshiro) Date: Thu, 15 Feb 2018 19:52:32 +0900 Subject: [openssl-users] error (openssl-1.1.0g) In-Reply-To: References: Message-ID: Hi, Uri, BTW, I finished the installation without any errors (make install) even if I got an error for make test phase. Also, I can use openssl command and produce .pem keys. I am not sure if this is the correct way... Regards, 2018-02-15 7:25 GMT+09:00 Blumenthal, Uri - 0553 - MITLL : > Thanks for your feedback. > > > > You?re welcome. > > > > You think it might be something like "BUG"?? > > > > Probably yes ? but the question is whether it?s with the new OpenSSL test > infrastructure, or something with how one of my machines is configured. I > do not know. > > > > Anyway, you are also waiting for the answers right? > > > > Yes I certainly am. > > > > 2018-02-15 6:57 GMT+09:00 Blumenthal, Uri - 0553 - MITLL : > > Funny. I have the same problem with the current master on one of my two > MacOS High Sierra machines. Surprisingly, the other machine builds and runs > the current master just fine. Configuration and build scripts are automated > and exactly the same between the two. > > > > The ?bad? machine runs a bunch of compliance-related software, but it did > not seem to interfere with the previous OpenSSL code drops. > > -- > > Regards, > > Uri Blumenthal > > *From: *openssl-users on behalf of > "Sakuma, Koshiro" > *Reply-To: *"openssl-users at openssl.org" > *Date: *Wednesday, February 14, 2018 at 16:33 > *To: *"openssl-users at openssl.org" > *Subject: *[openssl-users] error (openssl-1.1.0g) > > > > Hi, Team, > > > > I'm trying to install openssl-1.1.0g on my CentOS7, but I've gotten error > during do the "make test" phase. The error I've gotten is as follows. > > > > ------------------------------------------------------------ > ----------------------------------------------------------------- > > ./test/recipes/40-test_rehash.t ........... Dubious, test returned 1 > (wstat 256, 0x100) > > Failed 1/5 subtests > > > > Test Summary Report > > ------------------- > > ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) > > Failed test: 4 > > Non-zero exit status: 1 > > Files=95, Tests=554, 34 wallclock secs ( 0.32 usr 0.09 sys + 25.56 cusr > 9.26 csys = 35.23 CPU) > > Result: FAIL > > make[1]: *** [_tests] Error 1 > > make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g > > make[1]:***[tests] error 2 > > ------------------------------------------------------------ > ----------------------------------------------------------------- > > > > The command I tried to do was like "config --prefix=/usr/local/openssl > shared zlib OR config shared OR config. > > > > The OS version is CentOS Linux release 7.4.1708 (Core). > > > > I am not sure if I can ignore this error and move forward to do "make". > > > > Thank you so much for your support. > > > > Regards, > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Feb 15 11:12:36 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 15 Feb 2018 11:12:36 +0000 Subject: [openssl-users] Explicit IV in TLS 1.1+ In-Reply-To: References: <69BB651F-E746-49CC-A032-FA838309C3B7@strategix.se> Message-ID: <4ad3a037-abe9-3e2c-535b-3b3e5b3086d8@openssl.org> On 15/02/18 03:52, Curt Johansson wrote: > Hi Matt, thanks for your prompt answer. The testclient is using > openssl-1.0.2m and my previous assumption that the IV was derived > from the key_block as in TLS 1.0 was wrong. It seems that when > initialising the cipher with the IV is ignored when the crypto is AES > and the first 16 bytes of the encrypted payload is used as IV (as per > TLS spec). This is a Java issue and has nothing to do with OpenSSL > but assuming this is correct behaviour (I'll have to dig in to that) > I use the same logic (in this respect) for TLS1.1 and TLS1.2 > assuming that the client also does which it obviously does not. > > Below is the logging from my server handling two authentications (the > Finished message that is the first encrypted). The first (TLS1.1) > succeeds and the second (1.2) fails. You can see that the decrypted > text is correctly padded in the first case (TLS 1.1) indicating that > the decryption succeeded but the second (1.2) decrypted buffer does > not. The "Finished" message for this (AES; SHA) mac- and block size > should be padded with 11 bytes which the first is. Also as seen I use > the same provider and algoritm in the two cases, actually I handle > the decryption in the same way for the two TLS-levels > > > Also added the wireshark output for the two authentications where > I've verified that the logged encrypted data really is whats coming > in on the line. > > > Basically when selecting 1.1 in the client everything works as > expected but selecting 1.2 the prepended IV is not correct as far as > I understand. The testclient vendor says they are using OpenSLL for > TLS handling so I expect that they're not fiddling with any IV bytes > at all. Given the version 1.0.2m, can this be explained? My best guess is that the calculated client write key is probably incorrect on the server side (which probably implies either the master or pre-master secret is wrong). You might need to instrument OpenSSL to dump out the internal secrets at various points and compare them with your calculations on the server to verify that they are the same. Matt > > > Best Curt > > > > > > TLS 1.1 > > 04:09:40.295 Cipher provider: SunJCE 04:09:40.295 Cipher algoritm: > AES/CBC/NoPadding 04:09:40.295 IV from key_block used in cipher init: > [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] 04:09:40.295 > Encrypted: [f5, 21, 77, 27, f7, bf, 31, 1f, b9, 74, 14, 50, be, 5f, > 66, 21, 1b, 4e, b, 33, 78, 3b, b8, 31, a3, 7c, c2, 93, f6, ec, a, 8f, > c4, 28, 71, cb, 82, b4, 12, c2, 6b, 56, f2, 9e, c8, b0, 2b, 64, 7c, > 89, ef, bb, 68, 6b, 73, 6b, 80, 3a, 1b, 7, 33, 4e, 36, 6b] > 04:09:40.296 Decrypted: [a6, c7, bc, 87, 7, 2, 85, c, c3, c7, 91, 73, > b3, 85, 19, 21, 14, 0, 0, c, 1, 6f, 1e, 4e, 97, d0, c4, 10, a9, 35, > 37, bc, 2a, 87, 79, 78, 4c, 4, 88, a1, fd, 35, 42, 26, 56, 51, b3, > 36, d, 3b, be, 4a, b, b, b, b, b, b, b, b, b, b, b, b] > > TLS 1.2 04:09:47.779 Cipher provider: SunJCE 04:09:47.779 Cipher > algoritm: AES/CBC/NoPadding 04:09:47.779 IV from key_block used in > cipher init: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] > 04:09:47.779 Encrypted: [80, 83, 98, 6b, 55, 98, 73, b4, f6, 22, 2d, > 88, b, 4d, af, 6f, 2d, d6, 1e, 9, 1d, b1, 94, f4, 49, 20, 15, d2, a0, > a0, 35, c5, 95, 3d, d3, 35, fd, 92, ef, a6, 0, 7d, 49, 3, 70, 5e, 5a, > 57, e3, f9, 89, 3f, 83, 11, cf, 82, 4e, a3, 87, 6e, 9e, 97, 9c, 7c] > 04:09:47.779 Decrypted: [f1, 4e, b3, 18, 26, d7, ae, 12, bf, 5d, fe, > 2a, 18, a1, 6f, 19, 60, 73, 26, c8, 74, 7c, c6, a6, a1, 65, d3, ad, > 45, f9, e3, 42, aa, e0, bd, 1d, a0, 18, b3, f3, 94, 28, 4e, 2a, ca, > 24, 25, 70, 7c, a9, f6, 19, 17, f5, ef, ee, b, 30, 2f, ec, 4d, b3, > 9c, 8b] > > > >> On 14 Feb 2018, at 0:26 , Matt Caswell wrote: >> >> >> >> On 13/02/18 22:02, Curt Johansson wrote: >>> Hi all, >>> >>> I'm developing support for TLS 1.1 and 1.2 in a radius-server >>> that until now only handles TLS 1.0. I'm testing with a testtool >>> that the vendor says is using OpenSSL to implement the TLS >>> support. It all seems to work except for the following: >>> >>> When all key exchange messages are sent from the server and back >>> from the client the client sends the "Finished" message which is >>> the first encrypted with the negotiated symmetric cipher suite. I >>> use AES-128 in block mode and according to the spec (RFC4346 for >>> TLS 1.1) the IV is prepended to the encrypted message (containing >>> the payload, MAC and padding). The message size i right and when >>> (in the server) I use the first 16 bytes of the message received >>> from the client as IV the decryption fails but when I use the >>> mechanism from TLS 1.0 to pick up the IV from the key_block the >>> decryption is successful. I understand that this is one way to >>> generate the IV that I suppose you use which is fine but >>> shouldn't this 16 byte vector be prepended, unecrypted, to the >>> encrypted data that is sent to the server? In TLS 1.2 there is >>> not IV material generated at all in the key_block so in that case >>> I don't even know where to find it. >>> >>> The simple question is, shouldn't the first 16 bytes (assuming >>> AES) of the message (after the 5 byte header) be the unencrypted >>> IV to be used in the decryption of the rest of the message? >> >> Yes, assuming you have negotiated an AES CBC ciphersuite in TLSv1.1 >> or TLSv1.2, then that is what happens. You don't say what version >> of OpenSSL you are using. Here is the code that does it for 1.1.1 >> (i.e. master branch): >> >> https://github.com/openssl/openssl/blob/master/ssl/record/ssl3_record.c#L954 >> >> >> As can be seen on line 969 we just fill the IV with random bytes. >> >> Perhaps you could provide a wireshark trace of the handshake which >> might provide some enlightenment as to what is happening. >> >> Matt >> >> >>> >>> I tried to dig in to the OpenSSL source but it's far too long ago >>> I did some serious C coding so I hope someone with a working >>> knowledge can enlighten me. I might have misunderstood the spec >>> but in that case I would be grateful if someone could clarify >>> this specific part of it. >>> >>> TIA Curt Johansson >>> >> -- openssl-users mailing list To unsubscribe: >> https://mta.openssl.org/mailman/listinfo/openssl-users >> > > > From matt at openssl.org Thu Feb 15 11:21:59 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 15 Feb 2018 11:21:59 +0000 Subject: [openssl-users] error (openssl-1.1.0g) In-Reply-To: References: <5833C84B-9C58-41F6-AD39-3B057ECCBC07@akamai.com> Message-ID: On 15/02/18 08:52, Sakuma, Koshiro wrote: > Hi, Rich, > > Here is the result.? However, I tried to do the "config" with normal > user and I got an error like you don't have permission.?? > You have any ideas???? > > #? ?Failed test 'Testing that we aren't running as a privileged user, > such as root' So this confirms that the issue is due to you running the test as root. You have a few options: 1) Ignore this test failure. If this is the only test failure showing up then it is harmless. It is a known issue in the test code (not in OpenSSL itself) 2) Don't build as root. The build process doesn't need any special privileges, other than obviously it needs to be able to read the source files and write out object, executables, libraries etc. If you are building as a user other than root make sure all the source files and directories are owned by that user (or at least that the user has the appropriate privs for read/write). You will probably still need to be root to do the final "make install". 3) If you must build as root, and don't want to just ignore the failure then you can apply the patch available here: https://github.com/openssl/openssl/pull/5184/files I'd go with option 1. Matt > #? ?at ../test/recipes/40-test_rehash.t line 49. > ok 5 # skip It's pointless to run the next test as root > # Looks like you failed 1 test of 5. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/5 subtests > ? ? ? ? (less 1 skipped subtest: 3 okay) > > Test Summary Report > ------------------- > ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) > ? Failed test:? 4 > ? Non-zero exit status: 1 > Files=1, Tests=5,? 0 wallclock secs ( 0.02 usr? 0.00 sys +? 0.05 cusr? > 0.03 csys =? 0.10 CPU) > Result: FAIL > make[1]: *** [_tests] Error 1 > make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g' > > > > 2018-02-15 7:28 GMT+09:00 Salz, Rich >: > > For the failing test, try this____ > > ??????????????? make TESTS=test_rehash V=1 tests____ > > __?__ > > > > From bravo.echo.one at gmail.com Thu Feb 15 12:07:29 2018 From: bravo.echo.one at gmail.com (Sakuma, Koshiro) Date: Thu, 15 Feb 2018 21:07:29 +0900 Subject: [openssl-users] error (openssl-1.1.0g) In-Reply-To: References: <5833C84B-9C58-41F6-AD39-3B057ECCBC07@akamai.com> Message-ID: Hi, Matt, Thank you so much for your comments!! Yes, I took option 2. I changed owner for binary directory and run with normal user account. Also, I did "sudo make install" . It worked finally!!! Cheers! 2018-02-15 20:21 GMT+09:00 Matt Caswell : > > > On 15/02/18 08:52, Sakuma, Koshiro wrote: > > Hi, Rich, > > > > Here is the result. However, I tried to do the "config" with normal > > user and I got an error like you don't have permission. > > You have any ideas?? > > > > # Failed test 'Testing that we aren't running as a privileged user, > > such as root' > > So this confirms that the issue is due to you running the test as root. > > You have a few options: > > 1) Ignore this test failure. If this is the only test failure showing up > then it is harmless. It is a known issue in the test code (not in > OpenSSL itself) > > 2) Don't build as root. The build process doesn't need any special > privileges, other than obviously it needs to be able to read the source > files and write out object, executables, libraries etc. If you are > building as a user other than root make sure all the source files and > directories are owned by that user (or at least that the user has the > appropriate privs for read/write). You will probably still need to be > root to do the final "make install". > > 3) If you must build as root, and don't want to just ignore the failure > then you can apply the patch available here: > https://github.com/openssl/openssl/pull/5184/files > > I'd go with option 1. > > Matt > > > > > # at ../test/recipes/40-test_rehash.t line 49. > > ok 5 # skip It's pointless to run the next test as root > > # Looks like you failed 1 test of 5. > > Dubious, test returned 1 (wstat 256, 0x100) > > Failed 1/5 subtests > > (less 1 skipped subtest: 3 okay) > > > > Test Summary Report > > ------------------- > > ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) > > Failed test: 4 > > Non-zero exit status: 1 > > Files=1, Tests=5, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr > > 0.03 csys = 0.10 CPU) > > Result: FAIL > > make[1]: *** [_tests] Error 1 > > make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g' > > > > > > > > 2018-02-15 7:28 GMT+09:00 Salz, Rich > >: > > > > For the failing test, try this____ > > > > make TESTS=test_rehash V=1 tests____ > > > > __ __ > > > > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Feb 15 14:57:20 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 15 Feb 2018 14:57:20 +0000 Subject: [openssl-users] TLS 1.3 PSK test server setup In-Reply-To: <0F759E61-6E15-41E0-9E40-508C35A59F4E@dukhovni.org> References: <1693848.l3FjmQ6d8I@pintsize.usersys.redhat.com> <5ffe8138-83d7-698e-15fb-b078ee196efa@openssl.org> <0F759E61-6E15-41E0-9E40-508C35A59F4E@dukhovni.org> Message-ID: <5498425e-05dd-3b8e-2a4d-15a01cf52bef@openssl.org> On 14/02/18 23:33, Viktor Dukhovni wrote: > > >> On Feb 14, 2018, at 6:14 PM, Matt Caswell wrote: >> >> For a PSK to be used in needs to be the correct length for the selected >> ciphersuite. The ciphersuite is selected *first*. Next the available >> PSKs are checked to see if they are usable with that ciphersuite. > > Is that (choosing the cipher first) correct behaviour? If the server > is given a specific certificate it limits its ciphers to those that > are compatible with the certificate's public key. It seems to me that > "-psk" should not be different. If we are doing PSK, we should likely > filter the ciphers to those that work with the supplied PSK first. > As pointed out by Hubert in #5378 this is in accordance with the recommendations in the spec: "Implementor's note: the most straightforward way to implement the PSK/cipher suite matching requirements is to negotiate the cipher suite first and then exclude any incompatible PSKs. Any unknown PSKs (e.g., they are not in the PSK database or are encrypted with an unknown key) SHOULD simply be ignored. If no acceptable PSKs are found, the server SHOULD perform a non-PSK handshake if possible." Matt From rsalz at akamai.com Thu Feb 15 15:13:19 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 15 Feb 2018 15:13:19 +0000 Subject: [openssl-users] error (openssl-1.1.0g) In-Reply-To: References: <5833C84B-9C58-41F6-AD39-3B057ECCBC07@akamai.com> Message-ID: You are probably having errors because you have old build results still in your tree. It might be easiest to wipe things out and start over. You can run the whole build and test without being root. I do it multiple times a day. And then, if needed run the ?make install? step as root. From: "Sakuma, Koshiro" Date: Thursday, February 15, 2018 at 5:43 AM To: Rich Salz Cc: openssl-users Subject: Re: [openssl-users] error (openssl-1.1.0g) Hi, Please let me know how I can compile the source with normal user account instead of root? The error I got was like "You don't have permission" after executing "config". Regards, 2018-02-15 17:52 GMT+09:00 Sakuma, Koshiro >: Hi, Rich, Here is the result. However, I tried to do the "config" with normal user and I got an error like you don't have permission. You have any ideas?? # Failed test 'Testing that we aren't running as a privileged user, such as root' # at ../test/recipes/40-test_rehash.t line 49. ok 5 # skip It's pointless to run the next test as root # Looks like you failed 1 test of 5. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/5 subtests (less 1 skipped subtest: 3 okay) Test Summary Report ------------------- ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=1, Tests=5, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr 0.03 csys = 0.10 CPU) Result: FAIL make[1]: *** [_tests] Error 1 make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g' 2018-02-15 7:28 GMT+09:00 Salz, Rich >: For the failing test, try this make TESTS=test_rehash V=1 tests -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Feb 15 15:47:33 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 15 Feb 2018 15:47:33 +0000 Subject: [openssl-users] TLS 1.3 PSK test server setup In-Reply-To: <2E95043E-A399-46C0-9403-2E1DF3408A66@dukhovni.org> References: <1693848.l3FjmQ6d8I@pintsize.usersys.redhat.com> <5ffe8138-83d7-698e-15fb-b078ee196efa@openssl.org> <0F759E61-6E15-41E0-9E40-508C35A59F4E@dukhovni.org> <5498425e-05dd-3b8e-2a4d-15a01cf52bef@openssl.org> <2E95043E-A399-46C0-9403-2E1DF3408A66@dukhovni.org> Message-ID: On 15/02/18 15:33, Viktor Dukhovni wrote: > > >> On Feb 15, 2018, at 9:57 AM, Matt Caswell wrote: >> >> As pointed out by Hubert in #5378 this is in accordance with the >> recommendations in the spec: >> >> "Implementor's note: the most straightforward way to implement the >> PSK/cipher suite matching requirements is to negotiate the cipher >> suite first and then exclude any incompatible PSKs. Any unknown PSKs >> (e.g., they are not in the PSK database or are encrypted with an >> unknown key) SHOULD simply be ignored. If no acceptable PSKs are >> found, the server SHOULD perform a non-PSK handshake if possible." > > OK, it is "straightforward", but I am not sure it satisfies the > principle of least surprise. So I am asking you what you think > users can reasonably expect... TLSv1.3 PSKs are very different to TLSv1.2 PSKs. In TLSv1.3 they are effectively the same thing as a session (they are indistinguishable on the wire) - and are handled internally by the same logic. As with any session the server may or may not choose to use it. If we are talking about the "principle of least surprise" then I would find it quite surprising if the server selected a non-preferred ciphersuite when a mutually supported better one exists. I suspect that most implementations will follow the advice above from the spec, and again it would be quite surprising if we did something different. Not only that it would add unnecessary complexity to the logic in this area. What is perhaps the source of any "surprise" that a user might experience is that TLSv1.2 and TLSv1.3 share the same name for PSKs, when really they are only related at a conceptual level: at an implementation level they are totally different. Perhaps it would have been better if they had been called something different. That is slightly unfortunate - but not something we can do much about (especially at this late stage). I strongly feel this is the correct behaviour. Matt From openssl-users at dukhovni.org Thu Feb 15 16:38:40 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 15 Feb 2018 11:38:40 -0500 Subject: [openssl-users] TLS 1.3 PSK test server setup In-Reply-To: References: <1693848.l3FjmQ6d8I@pintsize.usersys.redhat.com> <5ffe8138-83d7-698e-15fb-b078ee196efa@openssl.org> <0F759E61-6E15-41E0-9E40-508C35A59F4E@dukhovni.org> <5498425e-05dd-3b8e-2a4d-15a01cf52bef@openssl.org> <2E95043E-A399-46C0-9403-2E1DF3408A66@dukhovni.org> Message-ID: <54F1ED25-DBB0-4715-BFBB-A073BEE48FE0@dukhovni.org> > On Feb 15, 2018, at 10:47 AM, Matt Caswell wrote: > > TLSv1.3 PSKs are very different to TLSv1.2 PSKs. In TLSv1.3 they are > effectively the same thing as a session (they are indistinguishable on > the wire) - and are handled internally by the same logic. As with any > session the server may or may not choose to use it. My understanding was somewhat in the other directions, in TLS 1.3 sessions resumption was reimplemented as a PSK, simplifying the protocol, but this does not mean that *all* PSKs are ephemeral sessions to be optionally resumed. Are there not PSKs that are long-term shared keys? Do we provide a means to specify one of those and have it be used in preference to (or to the exclusion of) all other handshake variants? > If we are talking about the "principle of least surprise" then I would > find it quite surprising if the server selected a non-preferred > ciphersuite when a mutually supported better one exists. Sure, with session resumption, but if a user expects to use a PSK with some server for mutual authentication via a shared long-term secret, I would be as surprised if it were not used. Perhaps the technical similarity of session resumption with PSKs is contrary to user intent. The below are not the same: * A previously established resumable session * A long-term shared key PSK "established out of band" Note also that perhaps you're thinking primarily about the server, to which the RFC implementation note applies: Implementor's note: the most straightforward way to implement the PSK/cipher suite matching requirements is to negotiate the cipher suite first and then exclude any incompatible PSKs. Any unknown PSKs (e.g., they are not in the PSK database or are encrypted with an unknown key) SHOULD simply be ignored. If no acceptable PSKs are found, the server SHOULD perform a non-PSK handshake if possible. But my concern is whether a client that specifies intentional use of an out-of-band shared-key PSK will get its expected behaviour. -- Viktor. From matt at openssl.org Thu Feb 15 17:21:43 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 15 Feb 2018 17:21:43 +0000 Subject: [openssl-users] TLS 1.3 PSK test server setup In-Reply-To: <54F1ED25-DBB0-4715-BFBB-A073BEE48FE0@dukhovni.org> References: <1693848.l3FjmQ6d8I@pintsize.usersys.redhat.com> <5ffe8138-83d7-698e-15fb-b078ee196efa@openssl.org> <0F759E61-6E15-41E0-9E40-508C35A59F4E@dukhovni.org> <5498425e-05dd-3b8e-2a4d-15a01cf52bef@openssl.org> <2E95043E-A399-46C0-9403-2E1DF3408A66@dukhovni.org> <54F1ED25-DBB0-4715-BFBB-A073BEE48FE0@dukhovni.org> Message-ID: <4d1a7d60-f3f1-20fa-949f-0c23e1df6083@openssl.org> On 15/02/18 16:38, Viktor Dukhovni wrote: > > >> On Feb 15, 2018, at 10:47 AM, Matt Caswell wrote: >> >> TLSv1.3 PSKs are very different to TLSv1.2 PSKs. In TLSv1.3 they are >> effectively the same thing as a session (they are indistinguishable on >> the wire) - and are handled internally by the same logic. As with any >> session the server may or may not choose to use it. > > My understanding was somewhat in the other directions, in TLS 1.3 sessions > resumption was reimplemented as a PSK, simplifying the protocol, but this > does not mean that *all* PSKs are ephemeral sessions to be optionally > resumed. Are there not PSKs that are long-term shared keys? > > Do we provide a means to specify one of those and have it be used in > preference to (or to the exclusion of) all other handshake variants? Yes, this is of course possible. Just make sure any PSKs you have available on the server are consistent with the hash function in your preferred ciphersuites. If you don't want a non-long term key selected then don't prefer a ciphersuite that is incompatible with it. If you never want the possibility of a non-long term key being used then don't configure a Certificate on your server. > >> If we are talking about the "principle of least surprise" then I would >> find it quite surprising if the server selected a non-preferred >> ciphersuite when a mutually supported better one exists. > > Sure, with session resumption, but if a user expects to use a PSK with > some server for mutual authentication via a shared long-term secret, I > would be as surprised if it were not used. > > Perhaps the technical similarity of session resumption with PSKs is > contrary to user intent. The below are not the same: > > * A previously established resumable session > * A long-term shared key PSK "established out of band" > > Note also that perhaps you're thinking primarily about the server, > to which the RFC implementation note applies: > > Implementor's note: the most straightforward way to implement the > PSK/cipher suite matching requirements is to negotiate the cipher > suite first and then exclude any incompatible PSKs. Any unknown PSKs > (e.g., they are not in the PSK database or are encrypted with an > unknown key) SHOULD simply be ignored. If no acceptable PSKs are > found, the server SHOULD perform a non-PSK handshake if possible. > > But my concern is whether a client that specifies intentional use of > an out-of-band shared-key PSK will get its expected behaviour. > A client can "encourage" the server to select a PSK if it only offers ciphersuites that are compatible with it. If the server is OpenSSL and has the PSK available it will use it (because all shared ciphersuites will be compatible with it). Matt From artlemuel at gmail.com Thu Feb 15 17:37:46 2018 From: artlemuel at gmail.com (Jerry L) Date: Thu, 15 Feb 2018 12:37:46 -0500 Subject: [openssl-users] Compiling on AIX Message-ID: I received an error when compiling on AIX 7.1 using both cc and gcc. The 'ar' command fails with a message that / is not a valid flag when it tries to create the new archive file. I changed the ARFLAGS variable to ARFLAGS= -q -X32 in the make file and the archive was created and the object files added. I am working though some other issues (for test purposes). Currently we are using 1.0.2n with FIPS so we will not be moving to the new version until after FIPS certification. My programming knowledge has become somewhat out of date as I now work as a system administrator with little need for programming skills. So if I am missing something obvious here, please correct me. Art -------------- next part -------------- An HTML attachment was scrubbed... URL: From artlemuel at gmail.com Thu Feb 15 17:53:52 2018 From: artlemuel at gmail.com (Jerry L) Date: Thu, 15 Feb 2018 12:53:52 -0500 Subject: [openssl-users] Compiling on AIX In-Reply-To: References: Message-ID: I failed to point out that I was test compiling the 1.1.1 version. I apologize for that omission. Jerry L On Thu, Feb 15, 2018 at 12:37 PM, Jerry L wrote: > I received an error when compiling on AIX 7.1 using both cc and gcc. The > 'ar' command fails with a message that / is not a valid flag when it tries > to create the new archive file. I changed the ARFLAGS variable to ARFLAGS= > -q -X32 in the make file and the archive was created and the object files > added. > > I am working though some other issues (for test purposes). Currently we > are using 1.0.2n with FIPS so we will not be moving to the new version > until after FIPS certification. > > My programming knowledge has become somewhat out of date as I now work as > a system administrator with little need for programming skills. So if I am > missing something obvious here, please correct me. > > Art > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Feb 15 18:00:54 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 15 Feb 2018 18:00:54 +0000 Subject: [openssl-users] Compiling on AIX In-Reply-To: References: Message-ID: <5647ABFA-D3B1-4DCE-9A77-6E7FE375E416@akamai.com> FYI, FIPS does not work for 1.1.x. -------------- next part -------------- An HTML attachment was scrubbed... URL: From artlemuel at gmail.com Thu Feb 15 18:11:17 2018 From: artlemuel at gmail.com (Jerry L) Date: Thu, 15 Feb 2018 13:11:17 -0500 Subject: [openssl-users] Compiling on AIX In-Reply-To: <5647ABFA-D3B1-4DCE-9A77-6E7FE375E416@akamai.com> References: <5647ABFA-D3B1-4DCE-9A77-6E7FE375E416@akamai.com> Message-ID: I was aware of that which is the reason that I indicated we would not be looking at it until that certification was complete. On Thu, Feb 15, 2018 at 1:00 PM, Salz, Rich via openssl-users < openssl-users at openssl.org> wrote: > FYI, FIPS does not work for 1.1.x. > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkario at redhat.com Thu Feb 15 18:15:03 2018 From: hkario at redhat.com (Hubert Kario) Date: Thu, 15 Feb 2018 19:15:03 +0100 Subject: [openssl-users] TLS 1.3 PSK test server setup In-Reply-To: References: <1693848.l3FjmQ6d8I@pintsize.usersys.redhat.com> <2E95043E-A399-46C0-9403-2E1DF3408A66@dukhovni.org> Message-ID: <3708803.MshKeGAOGU@pintsize.usersys.redhat.com> On Thursday, 15 February 2018 16:47:33 CET Matt Caswell wrote: > On 15/02/18 15:33, Viktor Dukhovni wrote: > >> On Feb 15, 2018, at 9:57 AM, Matt Caswell wrote: > >> > >> As pointed out by Hubert in #5378 this is in accordance with the > >> > >> recommendations in the spec: > >> "Implementor's note: the most straightforward way to implement the > >> PSK/cipher suite matching requirements is to negotiate the cipher > >> suite first and then exclude any incompatible PSKs. Any unknown PSKs > >> (e.g., they are not in the PSK database or are encrypted with an > >> unknown key) SHOULD simply be ignored. If no acceptable PSKs are > >> found, the server SHOULD perform a non-PSK handshake if possible." > > > > OK, it is "straightforward", but I am not sure it satisfies the > > principle of least surprise. So I am asking you what you think > > users can reasonably expect... > > TLSv1.3 PSKs are very different to TLSv1.2 PSKs. they're not, you have two values - identity and a secret. in TLS 1.2 identity could be empty, in TLS 1.3 it can't be. in TLS 1.3 _optionally_ the PSK can have a hash explicitly associated with the secret. If a hash is not associated, the default sha-256 is used. > In TLSv1.3 they are > effectively the same thing as a session (they are indistinguishable on > the wire) that's not true - static PSKs are distinguished by the obfuscated_ticket_age value being 0 > - and are handled internally by the same logic. As with any > session the server may or may not choose to use it. that's an implementation detail specific to OpenSSL, and I dare say, very unexpected for a user > If we are talking about the "principle of least surprise" then I would > find it quite surprising if the server selected a non-preferred > ciphersuite when a mutually supported better one exists. except a server configured in version 1.1.0 to support just PSK will stop working as soon as both client and server update to 1.1.1 I'd call that "surprising" > I suspect that most implementations will follow the advice above from > the spec, and again it would be quite surprising if we did something > different. Not only that it would add unnecessary complexity to the > logic in this area. I've already talked with Nikos about situation in GnuTLS and it will support PSKs transparently in TLS 1.2 and TLS 1.3, configurations won't break. > What is perhaps the source of any "surprise" that a user might > experience is that TLSv1.2 and TLSv1.3 share the same name for PSKs, > when really they are only related at a conceptual level: at an > implementation level they are totally different. Perhaps it would have > been better if they had been called something different. That is > slightly unfortunate - but not something we can do much about > (especially at this late stage). that's how you see it, and having just implemented support for them, I do not agree -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From curt at strategix.se Thu Feb 15 19:42:28 2018 From: curt at strategix.se (Curt Johansson) Date: Thu, 15 Feb 2018 20:42:28 +0100 Subject: [openssl-users] Explicit IV in TLS 1.1+ In-Reply-To: <4ad3a037-abe9-3e2c-535b-3b3e5b3086d8@openssl.org> References: <69BB651F-E746-49CC-A032-FA838309C3B7@strategix.se> <4ad3a037-abe9-3e2c-535b-3b3e5b3086d8@openssl.org> Message-ID: Hi Matt, I had an error in my PRF that is new for TLS 1.2. Now it works. Thanks for pointing me in the right directionand THANK YOU all for devoting time to this important project. Best regards Curt > On 15 Feb 2018, at 12:12 , Matt Caswell wrote: > > > > On 15/02/18 03:52, Curt Johansson wrote: >> Hi Matt, thanks for your prompt answer. The testclient is using >> openssl-1.0.2m and my previous assumption that the IV was derived >> from the key_block as in TLS 1.0 was wrong. It seems that when >> initialising the cipher with the IV is ignored when the crypto is AES >> and the first 16 bytes of the encrypted payload is used as IV (as per >> TLS spec). This is a Java issue and has nothing to do with OpenSSL >> but assuming this is correct behaviour (I'll have to dig in to that) >> I use the same logic (in this respect) for TLS1.1 and TLS1.2 >> assuming that the client also does which it obviously does not. >> >> Below is the logging from my server handling two authentications (the >> Finished message that is the first encrypted). The first (TLS1.1) >> succeeds and the second (1.2) fails. You can see that the decrypted >> text is correctly padded in the first case (TLS 1.1) indicating that >> the decryption succeeded but the second (1.2) decrypted buffer does >> not. The "Finished" message for this (AES; SHA) mac- and block size >> should be padded with 11 bytes which the first is. Also as seen I use >> the same provider and algoritm in the two cases, actually I handle >> the decryption in the same way for the two TLS-levels >> >> >> Also added the wireshark output for the two authentications where >> I've verified that the logged encrypted data really is whats coming >> in on the line. >> >> >> Basically when selecting 1.1 in the client everything works as >> expected but selecting 1.2 the prepended IV is not correct as far as >> I understand. The testclient vendor says they are using OpenSLL for >> TLS handling so I expect that they're not fiddling with any IV bytes >> at all. Given the version 1.0.2m, can this be explained? > > My best guess is that the calculated client write key is probably > incorrect on the server side (which probably implies either the master > or pre-master secret is wrong). You might need to instrument OpenSSL to > dump out the internal secrets at various points and compare them with > your calculations on the server to verify that they are the same. > > Matt > >> >> >> Best Curt >> >> >> >> >> >> TLS 1.1 >> >> 04:09:40.295 Cipher provider: SunJCE 04:09:40.295 Cipher algoritm: >> AES/CBC/NoPadding 04:09:40.295 IV from key_block used in cipher init: >> [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] 04:09:40.295 >> Encrypted: [f5, 21, 77, 27, f7, bf, 31, 1f, b9, 74, 14, 50, be, 5f, >> 66, 21, 1b, 4e, b, 33, 78, 3b, b8, 31, a3, 7c, c2, 93, f6, ec, a, 8f, >> c4, 28, 71, cb, 82, b4, 12, c2, 6b, 56, f2, 9e, c8, b0, 2b, 64, 7c, >> 89, ef, bb, 68, 6b, 73, 6b, 80, 3a, 1b, 7, 33, 4e, 36, 6b] >> 04:09:40.296 Decrypted: [a6, c7, bc, 87, 7, 2, 85, c, c3, c7, 91, 73, >> b3, 85, 19, 21, 14, 0, 0, c, 1, 6f, 1e, 4e, 97, d0, c4, 10, a9, 35, >> 37, bc, 2a, 87, 79, 78, 4c, 4, 88, a1, fd, 35, 42, 26, 56, 51, b3, >> 36, d, 3b, be, 4a, b, b, b, b, b, b, b, b, b, b, b, b] >> >> TLS 1.2 04:09:47.779 Cipher provider: SunJCE 04:09:47.779 Cipher >> algoritm: AES/CBC/NoPadding 04:09:47.779 IV from key_block used in >> cipher init: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] >> 04:09:47.779 Encrypted: [80, 83, 98, 6b, 55, 98, 73, b4, f6, 22, 2d, >> 88, b, 4d, af, 6f, 2d, d6, 1e, 9, 1d, b1, 94, f4, 49, 20, 15, d2, a0, >> a0, 35, c5, 95, 3d, d3, 35, fd, 92, ef, a6, 0, 7d, 49, 3, 70, 5e, 5a, >> 57, e3, f9, 89, 3f, 83, 11, cf, 82, 4e, a3, 87, 6e, 9e, 97, 9c, 7c] >> 04:09:47.779 Decrypted: [f1, 4e, b3, 18, 26, d7, ae, 12, bf, 5d, fe, >> 2a, 18, a1, 6f, 19, 60, 73, 26, c8, 74, 7c, c6, a6, a1, 65, d3, ad, >> 45, f9, e3, 42, aa, e0, bd, 1d, a0, 18, b3, f3, 94, 28, 4e, 2a, ca, >> 24, 25, 70, 7c, a9, f6, 19, 17, f5, ef, ee, b, 30, 2f, ec, 4d, b3, >> 9c, 8b] >> >> >> >>> On 14 Feb 2018, at 0:26 , Matt Caswell wrote: >>> >>> >>> >>> On 13/02/18 22:02, Curt Johansson wrote: >>>> Hi all, >>>> >>>> I'm developing support for TLS 1.1 and 1.2 in a radius-server >>>> that until now only handles TLS 1.0. I'm testing with a testtool >>>> that the vendor says is using OpenSSL to implement the TLS >>>> support. It all seems to work except for the following: >>>> >>>> When all key exchange messages are sent from the server and back >>>> from the client the client sends the "Finished" message which is >>>> the first encrypted with the negotiated symmetric cipher suite. I >>>> use AES-128 in block mode and according to the spec (RFC4346 for >>>> TLS 1.1) the IV is prepended to the encrypted message (containing >>>> the payload, MAC and padding). The message size i right and when >>>> (in the server) I use the first 16 bytes of the message received >>>> from the client as IV the decryption fails but when I use the >>>> mechanism from TLS 1.0 to pick up the IV from the key_block the >>>> decryption is successful. I understand that this is one way to >>>> generate the IV that I suppose you use which is fine but >>>> shouldn't this 16 byte vector be prepended, unecrypted, to the >>>> encrypted data that is sent to the server? In TLS 1.2 there is >>>> not IV material generated at all in the key_block so in that case >>>> I don't even know where to find it. >>>> >>>> The simple question is, shouldn't the first 16 bytes (assuming >>>> AES) of the message (after the 5 byte header) be the unencrypted >>>> IV to be used in the decryption of the rest of the message? >>> >>> Yes, assuming you have negotiated an AES CBC ciphersuite in TLSv1.1 >>> or TLSv1.2, then that is what happens. You don't say what version >>> of OpenSSL you are using. Here is the code that does it for 1.1.1 >>> (i.e. master branch): >>> >>> https://github.com/openssl/openssl/blob/master/ssl/record/ssl3_record.c#L954 >>> >>> >>> > As can be seen on line 969 we just fill the IV with random bytes. >>> >>> Perhaps you could provide a wireshark trace of the handshake which >>> might provide some enlightenment as to what is happening. >>> >>> Matt >>> >>> >>>> >>>> I tried to dig in to the OpenSSL source but it's far too long ago >>>> I did some serious C coding so I hope someone with a working >>>> knowledge can enlighten me. I might have misunderstood the spec >>>> but in that case I would be grateful if someone could clarify >>>> this specific part of it. >>>> >>>> TIA Curt Johansson >>>> >>> -- openssl-users mailing list To unsubscribe: >>> https://mta.openssl.org/mailman/listinfo/openssl-users >>> >> >> >> > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From levitte at openssl.org Thu Feb 15 21:42:18 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 15 Feb 2018 22:42:18 +0100 (CET) Subject: [openssl-users] Compiling on AIX In-Reply-To: References: Message-ID: <20180215.224218.579385920626629676.levitte@openssl.org> Thank you, that was an omission on our part. Fixed here: https://github.com/openssl/openssl/pull/5386 Cheers, Richard In message on Thu, 15 Feb 2018 12:53:52 -0500, Jerry L said: artlemuel> I failed to point out that I was test compiling the 1.1.1 version. I apologize for that omission. artlemuel> artlemuel> Jerry L artlemuel> artlemuel> On Thu, Feb 15, 2018 at 12:37 PM, Jerry L wrote: artlemuel> artlemuel> I received an error when compiling on AIX 7.1 using both cc and gcc. The 'ar' command fails artlemuel> with a message that / is not a valid flag when it tries to create the new archive file. I changed artlemuel> the ARFLAGS variable to ARFLAGS= -q -X32 in the make file and the archive was created and artlemuel> the object files added. artlemuel> artlemuel> I am working though some other issues (for test purposes). Currently we are using 1.0.2n with artlemuel> FIPS so we will not be moving to the new version until after FIPS certification. artlemuel> artlemuel> My programming knowledge has become somewhat out of date as I now work as a system artlemuel> administrator with little need for programming skills. So if I am missing something obvious artlemuel> here, please correct me. artlemuel> artlemuel> Art artlemuel> From grace.priscilla at gmail.com Fri Feb 16 03:35:55 2018 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Fri, 16 Feb 2018 09:05:55 +0530 Subject: [openssl-users] Issue with select after SSL_get_wfd Message-ID: Hi All, I want to know the status of the SSL_WRITE for DTLS on UDP on a non-blocking socket. Only if the other end does the recvfrom I want to continue with subsequent SSL_WRITE. Below is what I have tried. //Making the socket blocking - if I dont do below then select call hangs if (wfd = SSL_get_wfd(ssl)) { flags = fcntl(wfd, F_GETFL); flags &= ~O_NONBLOCK; fcntl(a_wfd, F_SETFL, flags); FD_SET(wfd, &write_fds); } len = SSL_write( ssl, buf, elen); i = select(wfd+1, NULL, &write_fds, 0, 0); The other side has not yet done the SSL_read but i is "1". Is their something wrong with this? Thanks, Grace -------------- next part -------------- An HTML attachment was scrubbed... URL: From grace.priscilla at gmail.com Fri Feb 16 03:37:46 2018 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Fri, 16 Feb 2018 09:07:46 +0530 Subject: [openssl-users] Version compactibility Message-ID: Hi All, Which version on 1.0.2x is the same as 1.1.0g(bug fixing branch)? Thanks, Grace -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Thu Feb 15 22:41:24 2018 From: paul.dale at oracle.com (Paul Dale) Date: Thu, 15 Feb 2018 14:41:24 -0800 (PST) Subject: [openssl-users] Compiling on AIX In-Reply-To: References: Message-ID: It?s been like this for about three weeks now.? I?ve not had a chance to look into addressing the issue. ? Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia ? From: Jerry L [mailto:artlemuel at gmail.com] Sent: Friday, 16 February 2018 3:38 AM To: openssl-users at openssl.org Subject: [openssl-users] Compiling on AIX ? I received an error when compiling on AIX 7.1?using both cc and gcc.? The 'ar' command fails with a message that / is not a valid flag when it tries to create the new archive file.? I changed the ARFLAGS variable to ARFLAGS= -q -X32 in the make file and the archive was created and the object files added.? ? I am working though some other issues (for test purposes).? Currently we are using 1.0.2n with FIPS so we?will not?be moving to the new version until after FIPS certification. ? My programming knowledge has become somewhat out of date as I now work as a system administrator with little need for programming skills.? So if I am missing something obvious here,?please correct me.? ? Art -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Feb 16 04:18:07 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 16 Feb 2018 04:18:07 +0000 Subject: [openssl-users] Version compactibility In-Reply-To: References: Message-ID: <96E786E3-070B-420D-A082-8974CFC306F8@akamai.com> * Which version on 1.0.2x is the same as 1.1.0g(bug fixing branch)? None. 1.1.0 is substantially different (most structures are now opaque). -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Fri Feb 16 07:59:04 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 16 Feb 2018 10:59:04 +0300 Subject: [openssl-users] Building OpenSSL from sources In-Reply-To: <20180215.094802.1191100845499196579.levitte@openssl.org> References: <20180215.094802.1191100845499196579.levitte@openssl.org> Message-ID: Dear Richard, On Thu, Feb 15, 2018 at 11:48 AM, Richard Levitte wrote: > In message gmail.com> on Thu, 15 Feb 2018 11:00:00 +0300, Dmitry Belyavsky < > beldmit at gmail.com> said: > > beldmit> Hello, > beldmit> > beldmit> I get problems building and installing OpenSSL 1.1.0g from > source. I use Debian Wheezy > beldmit> (oldstable). > beldmit> > beldmit> After running ./config; make; make test; sudo make install > beldmit> > beldmit> I call /usr/local/bin/openssl > beldmit> > beldmit> I get an error > beldmit> > beldmit> /usr/local/bin/openssl: error while loading shared libraries: > libssl.so.1.1: cannot open shared object > beldmit> file: No such file or directory > beldmit> > beldmit> $ ldd /usr/local/bin/openssl > beldmit> libssl.so.1.1 => not found > beldmit> libcrypto.so.1.1 => not found > beldmit> > beldmit> This behavior differs from the one for version 1.1.0b, where > everything works fine. > beldmit> > beldmit> According to CHANGES in 1.1.0c > beldmit> > beldmit> *) Removed automatic addition of RPATH in shared libraries and > executables, > beldmit> as this was a remainder from OpenSSL 1.0.x and isn't needed any > more. > beldmit> [Richard Levitte] > beldmit> > beldmit> Could you please clarify why this changes were introduced? > > The change was made for a very specific reason, it screwed up testing, > and here's how. > > On GNU systems (for example Linux), '-Wl,-rpath,/path/to/installed/lib' > sets DT_RPATH. If you read the ld.so manual, you will see that > DT_RPATH is used before anything else that affects what directories > are looked into, including LD_LIBRARY_PATH. > > This meant that when running a new build of 'openssl' before > installing it, it would look for a previously installed version of the > libraries instead of those in the build directory. > > A solution that we did use was to use LD_PRELOAD, which comes before > even DT_RPATH. This worked well for quite a while. > > Enter asan and ubsan. I don't remember which one it was, but I think > it was one of those that was royally screwed up by our preloading the > shared libraries in the build directory. It simply didn't work. > > There is of course the solution to use '-Wl,--enable-new-dtags,-rpath, > /path/to/installed/lib', but that wouldn't work on older ELF systems > > Another factor in all of this is that the reason we used -rpath to > begin with was that up until OpenSSL 1.0.2, we installed the libraries > in a non-standard directory (/usr/local/ssl/lib) by default. This is > not longer so, the default location is /usr/local/lib, which should be > one of the standard ld.so directories. > > In the end, we (or I, I don't remember) concluded that we didn't > actually need a compulsary use of -rpath and that this should be left > to the user. > > beldmit> Shouldn't the INSTALL file be changed to document this change > beldmit> because the proposed way ( ./config; make; make test; make > beldmit> install) does not work? > > Actually, this is documented, in NOTES.UNIX, which is mentioned in the > beginning of INSTALL: > > > For additional platform specific requirements, solutions to specific > issues and other details, please read one of these: > > * NOTES.UNIX (any supported Unix like system) > * NOTES.VMS (OpenVMS) > * NOTES.WIN (any supported Windows) > * NOTES.DJGPP (DOS platform with DJGPP) > > You see, INSTALL is supposed to be fairly platform agnostic... > > Thank you very much for your comprehensive explanation! But doesn't it make sense to explicitly add invocation of ldconfig to make install scenario? -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Fri Feb 16 09:26:55 2018 From: levitte at openssl.org (Richard Levitte) Date: Fri, 16 Feb 2018 10:26:55 +0100 (CET) Subject: [openssl-users] Building OpenSSL from sources In-Reply-To: References: <20180215.094802.1191100845499196579.levitte@openssl.org> Message-ID: <20180216.102655.2115789732377613671.levitte@openssl.org> In message on Fri, 16 Feb 2018 10:59:04 +0300, Dmitry Belyavsky said: beldmit> But doesn't it make sense to explicitly add invocation of ldconfig to make install scenario? Maybe, depending on why. If it's to create the appropriate symlinks, you might notice that we do that ourselves using 'ln -s' (if the symlinks are wrong, please raise an issue on github). If it's for the cache, we could of course add some kind of post-shared config attribute to reflect that need (a little like we have one for ranlib). Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From hugh.maaskant at gmail.com Fri Feb 16 10:43:14 2018 From: hugh.maaskant at gmail.com (Hugh Maaskant) Date: Fri, 16 Feb 2018 11:43:14 +0100 Subject: [openssl-users] Issue with select after SSL_get_wfd In-Reply-To: References: Message-ID: Hi Grace, UDP is a datagram service - think of it as ?fire and forget?. So the sending socket will not know if or when the packet has been delivered to the receiver, let alone that it has been consumed. You could, of course, create your own application level acks and retries etcetera, but before you know it you are rebuilding TCP. See e.g. https://www.diffen.com/difference/TCP_vs_UDP for a comparison between UDP and TCP. rgds, Hugh > On 16 Feb 2018, at 04:35, Grace Priscilla Jero wrote: > > Hi All, > > I want to know the status of the SSL_WRITE for DTLS on UDP on a non-blocking socket. Only if the other end does the recvfrom I want to continue with subsequent SSL_WRITE. > > Below is what I have tried. > > //Making the socket blocking - if I dont do below then select call hangs > > if (wfd = SSL_get_wfd(ssl)) > { > flags = fcntl(wfd, F_GETFL); > flags &= ~O_NONBLOCK; > fcntl(a_wfd, F_SETFL, flags); > > FD_SET(wfd, &write_fds); > } > len = SSL_write( ssl, > buf, > elen); > > i = select(wfd+1, NULL, &write_fds, 0, 0); > > The other side has not yet done the SSL_read but i is "1". > Is their something wrong with this? > > Thanks, > Grace > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From grace.priscilla at gmail.com Fri Feb 16 10:57:55 2018 From: grace.priscilla at gmail.com (Grace Priscilla Jero) Date: Fri, 16 Feb 2018 16:27:55 +0530 Subject: [openssl-users] Issue with select after SSL_get_wfd In-Reply-To: References: Message-ID: Thankyou Hugh, I know that it is datagram and we are not acknowledged. I just was looking for a way if SSL will be aware whether the packet is consumed or not. or anyway we can get the status from SSL on the packet consumption. Thanks, Grace On Fri, Feb 16, 2018 at 4:13 PM, Hugh Maaskant wrote: > Hi Grace, > > UDP is a datagram service - think of it as ?fire and forget?. So the > sending socket will not know if or when the packet has been delivered to > the receiver, let alone that it has been consumed. You could, of course, > create your own application level acks and retries etcetera, but before you > know it you are rebuilding TCP. > > See e.g. https://www.diffen.com/difference/TCP_vs_UDP for a comparison > between UDP and TCP. > > rgds, > > Hugh > > On 16 Feb 2018, at 04:35, Grace Priscilla Jero > wrote: > > Hi All, > > I want to know the status of the SSL_WRITE for DTLS on UDP on a > non-blocking socket. Only if the other end does the recvfrom I want to > continue with subsequent SSL_WRITE. > > Below is what I have tried. > > //Making the socket blocking - if I dont do below then select call hangs > > if (wfd = SSL_get_wfd(ssl)) > { > flags = fcntl(wfd, F_GETFL); > flags &= ~O_NONBLOCK; > fcntl(a_wfd, F_SETFL, flags); > > FD_SET(wfd, &write_fds); > } > len = SSL_write( ssl, > buf, > elen); > > i = select(wfd+1, NULL, &write_fds, 0, 0); > > The other side has not yet done the SSL_read but i is "1". > Is their something wrong with this? > > Thanks, > Grace > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gadphly at gmail.com Fri Feb 16 17:24:23 2018 From: gadphly at gmail.com (Gelareh Taban) Date: Fri, 16 Feb 2018 11:24:23 -0600 Subject: [openssl-users] Programmatic key conversion of PKCS#1 to #8 Message-ID: Hi all, I need to convert a Json Web Key (JWK) to PEM PKCS#8 format. I am using creating an RSA key using the parameters in JWK and then using i2d_RSAPublicKey() to encode the RSA key to PEM PKCS#1. Are there any OpenSSL functions that programmatically convert the key (both public and private) to PKCS#8? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From angus at magsys.co.uk Fri Feb 16 17:46:00 2018 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Fri, 16 Feb 2018 17:46 +0000 (GMT Standard Time) Subject: [openssl-users] Windows 1.1.1 binaries and web server Message-ID: Windows developers may be interested in our Win32 build of OpenSSL 1.1.1-pre1 (alpha), the binaries are digitally code signed 'Open Source Developer, Fran?ois PIETTE', the lead developer for the Delphi Internet Component Suite project. About half way down the page at: http://wiki.overbyte.eu/wiki/index.php/ICS_Download The latest 1.0.2 and 1.1.0 are also available, digitally code signed. I have also built my Windows ICS web application server to use 1.1.1-pre1 (alpha) so it can be used for testing TLSv1.3, the information page shows the protocol you connect with, the ciphers available and the OpenSSL and draft version being used. Currently most browsers still connect with TLSv1.2. https://www2.telecom-tariffs.co.uk/serverinfo.htm Angus From matt at openssl.org Fri Feb 16 17:49:13 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 16 Feb 2018 17:49:13 +0000 Subject: [openssl-users] Programmatic key conversion of PKCS#1 to #8 In-Reply-To: References: Message-ID: On 16/02/18 17:24, Gelareh Taban wrote: > Hi all, > > I need to convert a Json Web Key (JWK) to PEM PKCS#8 format. > > I am using creating an RSA key using the parameters in JWK and then > using i2d_RSAPublicKey() to ?encode the RSA key to PEM PKCS#1.? > > Are there any OpenSSL functions that programmatically convert the key > (both public and private) to PKCS#8?? You can use PEM_write_bio_PrivateKey() for this purpose. You need to have your RSA key in EVP_PKEY format first. So something like (simplified to remove error handling): EVP_PKEY *key = EVP_PKEY_new(); EVP_PKEY_assign_RSA(key, rsa); https://www.openssl.org/docs/man1.1.0/crypto/PEM_write_bio_PrivateKey.html https://www.openssl.org/docs/man1.1.0/crypto/EVP_PKEY_new.html https://www.openssl.org/docs/man1.1.0/crypto/EVP_PKEY_assign_RSA.html Matt From mcr at sandelman.ca Fri Feb 16 18:46:01 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 16 Feb 2018 13:46:01 -0500 Subject: [openssl-users] Issue with select after SSL_get_wfd In-Reply-To: References: Message-ID: <32558.1518806761@obiwan.sandelman.ca> Grace Priscilla Jero wrote: > Thankyou Hugh, I know that it is datagram and we are not > acknowledged. I just was looking for a way if SSL will be aware whether > the packet is consumed or not. or anyway we can get the status from > SSL on the packet consumption. Yes, that's because you are trying to figure out if the socket has data on it that SSL needs so that you can switch to the correct SSL* for the next processing. That's why trying to do it all with one socket is a problem. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From beldmit at gmail.com Fri Feb 16 19:22:20 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 16 Feb 2018 22:22:20 +0300 Subject: [openssl-users] Building OpenSSL from sources In-Reply-To: <20180216.102655.2115789732377613671.levitte@openssl.org> References: <20180215.094802.1191100845499196579.levitte@openssl.org> <20180216.102655.2115789732377613671.levitte@openssl.org> Message-ID: Dear Richard, On Fri, Feb 16, 2018 at 12:26 PM, Richard Levitte wrote: > In message gmail.com> on Fri, 16 Feb 2018 10:59:04 +0300, Dmitry Belyavsky < > beldmit at gmail.com> said: > > beldmit> But doesn't it make sense to explicitly add invocation of > ldconfig to make install scenario? > > Maybe, depending on why. If it's to create the appropriate symlinks, > you might notice that we do that ourselves using 'ln -s' (if the > symlinks are wrong, please raise an issue on github). If it's for the > cache, we could of course add some kind of post-shared config > attribute to reflect that need (a little like we have one for ranlib). > > I mean to update the cache. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From gadphly at gmail.com Fri Feb 16 20:56:41 2018 From: gadphly at gmail.com (Gelareh Taban) Date: Fri, 16 Feb 2018 14:56:41 -0600 Subject: [openssl-users] Programmatic key conversion of PKCS#1 to #8 In-Reply-To: References: Message-ID: Works beautifully. Thanks very much Matt! On Fri, Feb 16, 2018 at 11:49 AM, Matt Caswell wrote: > > > On 16/02/18 17:24, Gelareh Taban wrote: > > Hi all, > > > > I need to convert a Json Web Key (JWK) to PEM PKCS#8 format. > > > > I am using creating an RSA key using the parameters in JWK and then > > using i2d_RSAPublicKey() to encode the RSA key to PEM PKCS#1. > > > > Are there any OpenSSL functions that programmatically convert the key > > (both public and private) to PKCS#8? > > You can use PEM_write_bio_PrivateKey() for this purpose. You need to > have your RSA key in EVP_PKEY format first. So something like > (simplified to remove error handling): > > EVP_PKEY *key = EVP_PKEY_new(); > EVP_PKEY_assign_RSA(key, rsa); > > https://www.openssl.org/docs/man1.1.0/crypto/PEM_write_bio_PrivateKey.html > > https://www.openssl.org/docs/man1.1.0/crypto/EVP_PKEY_new.html > > https://www.openssl.org/docs/man1.1.0/crypto/EVP_PKEY_assign_RSA.html > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhat.jayalakshmi at gmail.com Mon Feb 19 09:15:59 2018 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Mon, 19 Feb 2018 14:45:59 +0530 Subject: [openssl-users] How to make OpenSSL engine usage application specific? Message-ID: Hello All, We have 2 RSA OpenSSL engines in our product. Both the engines performs same RSA encyrpt/decrypt operations. For easy explaination I am naming engines as 1. RSA smart card engine 2. RSA TPM engine Engine usage is application specific.There are couple of applications dependent on RSA TPM engine. And are few applications dependent on RSA smart card engine. We wanted to know if there are any APIs provided by OpenSSL to make the engine usage application specific? Is there any way we can make OpenSSL chose specific engine for specific application. Regards Jayalakshmi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcr at sandelman.ca Mon Feb 19 18:43:08 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 19 Feb 2018 13:43:08 -0500 Subject: [openssl-users] DTLS over UDP In-Reply-To: References: <10616.1518547870@obiwan.sandelman.ca> <5049.1518629142@obiwan.sandelman.ca> Message-ID: <12591.1519065788@obiwan.sandelman.ca> Nivedita wrote: >> Nivedita wrote: >>> I am trying to establish DTLS over UDP connection by using >>> DTLSv1_listen method . >>> I have followed the below steps - 1. Created a server socket >>> and using >>> this socket created bio and ssl object. bio = >>> BIO_new_dgram(VI_sock,BIO_NOCLOSE)) SSL_set_bio >>> (ssl,VP_bio,VP_bio); >>> 2. Enable cookie exchange on SSL object. SSL_set_options(ssl, >>> SSL_OP_COOKIE_EXCHANGE); >>> 3. Then started listening using dtlsv1_listen for the new >>> client >>> connections. Once dtlsv1_listen is successful and i got the >>> peer >>> address. mcr> okay. >> Nivedita- All the above mentioned steps i am doing on server >> side . On the >> client side i have already initiated ssl_connect. >> On the server side when i am listening using dtlsv1_listen >> method - >>> 4. Once i got the peer address , i am creating one more socket >>> 5. With the new socket i tried to connect to peer address. > Then once i got the client address from the dtlsv1_listen method, > i am creating one more socket and trying to connect to this client > address. I think that I see what is wrong with your flow... you haven't taken the packet off the original socket, so SSL_accept is still looking for it. The flow is supposed to be: 1) client sends ClientHello 2) DTLSv1_listen() sees it, and sends a HelloVerifyRequest (I assume you have filled in the cookie callbacks. I think that perhaps there should be good cryptographic defaults available in the library. Maybe there are, and I'm ignorant of them) 3) Client sends ClientHello w/cookie. DTLSv1_listen() then sees that and tweaks the SSL* to indicate that the cookie has been accepted. Note that the packet is *LEFT* on the incoming socket so that SSL_accept() can process it. This is one the places where the DTLSv1_listen() API is rather hard to use in my opinion. 4) You make up new sockets, etc. 5) But, you need to call SSL_accept() once with the **old socket** to process packet that listen() left on it, and then you can switch the FD over! Of course, you probably want to make sure that SSL_accept() sends the reply correctly. What I do in my proposed DTLSv1_accept() API is that I move the data From the incoming socket to the new BIO's incoming queue: https://github.com/mcr/openssl/blob/dtls-listen-refactor/ssl/d1_lib.c#L964 /* At this point, there is a real ClientHello in serv->init_buf */ memcpy(rb->buf, serv->init_buf->data, serv->init_num); rb->offset = 0; rb->left = serv->init_num; and then remove the packet from the incoming socket. The situation is then returned like this so that the new sockets can be setup, but the incoming SSL_accept() BIO is stuffed with the correct (cookie-full) ClientHello, and replies will go to the right place with the right source address. I hope to get these patches accepted for the March 11 freeze, but you might not want to depend upon it. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From norm.green at gemtalksystems.com Mon Feb 19 20:06:08 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Mon, 19 Feb 2018 12:06:08 -0800 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC Message-ID: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> Not sure if this is expected on this platform? Test Summary Report ------------------- ../test/recipes/04-test_asn1_encode.t??????????? (Wstat: 256 Tests: 1 Failed: 1) ? Failed test:? 1 ? Non-zero exit status: 1 ../test/recipes/90-test_secmem.t???????????????? (Wstat: 256 Tests: 1 Failed: 1) ? Failed test:? 1 ? Non-zero exit status: 1 Files=141, Tests=1313, 370 wallclock secs ( 3.42 usr? 0.94 sys + 266.48 cusr 40.30 csys = 311.14 CPU) Result: FAIL Makefile:169: recipe for target '_tests' failed From bkaduk at akamai.com Mon Feb 19 20:50:05 2018 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 19 Feb 2018 14:50:05 -0600 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> Message-ID: <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> On 02/19/2018 02:06 PM, Norm Green wrote: > Not sure if this is expected on this platform? > > Test Summary Report > ------------------- > ../test/recipes/04-test_asn1_encode.t??????????? (Wstat: 256 Tests: 1 > Failed: 1) > ? Failed test:? 1 > ? Non-zero exit status: 1 > ../test/recipes/90-test_secmem.t???????????????? (Wstat: 256 Tests: 1 > Failed: 1) > ? Failed test:? 1 > ? Non-zero exit status: 1 > Files=141, Tests=1313, 370 wallclock secs ( 3.42 usr? 0.94 sys + > 266.48 cusr 40.30 csys = 311.14 CPU) > Result: FAIL > Makefile:169: recipe for target '_tests' failed I do not think it is expected.? Could you capture the output of 'make V=1 TESTS="test_asn1_encode test_secmem"' and make it available?? (Probably via posting it on the web and linking; the output may be long.) -Ben From norm.green at gemtalksystems.com Mon Feb 19 21:20:33 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Mon, 19 Feb 2018 13:20:33 -0800 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> Message-ID: <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> The output is not too long. /export/localnew/sparc.Solaris/bin/gmake depend && /export/localnew/sparc.Solaris/bin/gmake _tests gmake[1]: Entering directory '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1' gmake[1]: Leaving directory '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1' gmake[1]: Entering directory '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1' ( cd test; \ ? mkdir -p test-runs; \ ? SRCTOP=../. \ ? BLDTOP=../. \ ? RESULT_D=test-runs \ ? PERL="/opt/perl-5.24.0/bin/perl" \ ? EXE_EXT= \ ? OPENSSL_ENGINES=`cd .././engines; pwd` \ ? OPENSSL_DEBUG_MEMORY=on \ ??? /opt/perl-5.24.0/bin/perl .././test/run_tests.pl test_asn1_encode test_secmem ) ../test/recipes/04-test_asn1_encode.t .. 1..1 ??? # Subtest: ../../test/asn1_encode_test ??? 1..6 ??? ok 1 - test_long_32bit ??? # ASN1_LONG_DATA: ??? #?? success: TRUE ../../util/shlib_wrap.sh ../../test/asn1_encode_test => 138 not ok 1 - running asn1_encode_test #?? Failed test 'running asn1_encode_test' #?? at /hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/test/../util/perl/OpenSSL/Test/Simple.pm line 77. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/90-test_secmem.t ....... 1..1 ??? # Subtest: ../../test/secmemtest ??? 1..1 ??? # ERROR: (bool) 'CRYPTO_secure_malloc_init(4096, 32) == true' failed @ test/secmemtest.c:28 ??? # false ??? not ok 1 - test_sec_mem ../../util/shlib_wrap.sh ../../test/secmemtest => 1 not ok 1 - running secmemtest #?? Failed test 'running secmemtest' #?? at /hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/test/../util/perl/OpenSSL/Test/Simple.pm line 77. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests Test Summary Report ------------------- ../test/recipes/04-test_asn1_encode.t (Wstat: 256 Tests: 1 Failed: 1) ? Failed test:? 1 ? Non-zero exit status: 1 ../test/recipes/90-test_secmem.t???? (Wstat: 256 Tests: 1 Failed: 1) ? Failed test:? 1 ? Non-zero exit status: 1 Files=2, Tests=2,? 2 wallclock secs ( 0.04 usr? 0.01 sys + 0.38 cusr? 0.16 csys =? 0.59 CPU) Result: FAIL Makefile:169: recipe for target '_tests' failed gmake[1]: *** [_tests] Error 1 gmake[1]: Leaving directory '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1' Makefile:167: recipe for target 'tests' failed gmake: *** [tests] Error 2 slow test failed On 2/19/2018 12:50 PM, Benjamin Kaduk wrote: > On 02/19/2018 02:06 PM, Norm Green wrote: >> Not sure if this is expected on this platform? >> >> Test Summary Report >> ------------------- >> ../test/recipes/04-test_asn1_encode.t??????????? (Wstat: 256 Tests: 1 >> Failed: 1) >> ? Failed test:? 1 >> ? Non-zero exit status: 1 >> ../test/recipes/90-test_secmem.t???????????????? (Wstat: 256 Tests: 1 >> Failed: 1) >> ? Failed test:? 1 >> ? Non-zero exit status: 1 >> Files=141, Tests=1313, 370 wallclock secs ( 3.42 usr? 0.94 sys + >> 266.48 cusr 40.30 csys = 311.14 CPU) >> Result: FAIL >> Makefile:169: recipe for target '_tests' failed > I do not think it is expected.? Could you capture the output of 'make > V=1 TESTS="test_asn1_encode test_secmem"' and make it available? > (Probably via posting it on the web and linking; the output may be long.) > > -Ben From openssl-users at dukhovni.org Mon Feb 19 21:30:29 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 19 Feb 2018 16:30:29 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> Message-ID: > On Feb 19, 2018, at 4:20 PM, Norm Green wrote: > > /export/localnew/sparc.Solaris/bin/gmake depend && /export/localnew/sparc.Solaris/bin/gmake _tests > gmake[1]: Entering directory '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1' > gmake[1]: Leaving directory '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1' > gmake[1]: Entering directory '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1' > ( cd test; \ > mkdir -p test-runs; \ > SRCTOP=../. \ > BLDTOP=../. \ > RESULT_D=test-runs \ > PERL="/opt/perl-5.24.0/bin/perl" \ > EXE_EXT= \ > OPENSSL_ENGINES=`cd .././engines; pwd` \ > OPENSSL_DEBUG_MEMORY=on \ > /opt/perl-5.24.0/bin/perl .././test/run_tests.pl test_asn1_encode test_secmem ) > ../test/recipes/04-test_asn1_encode.t .. > 1..1 > # Subtest: ../../test/asn1_encode_test > 1..6 > ok 1 - test_long_32bit > # ASN1_LONG_DATA: > # success: TRUE > ../../util/shlib_wrap.sh ../../test/asn1_encode_test => 138 On FreeBSD signal 10 (128 + 10 == 138) is SIGBUS, which could be a result of unaligned data access (please report "kill -l" output to confirm the signal numbers). Could you run this test under gdb, or enable core dumps, and report the stack trace? You may need a build with debugging symbols. -- Viktor. From norm.green at gemtalksystems.com Mon Feb 19 21:45:26 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Mon, 19 Feb 2018 13:45:26 -0800 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> Message-ID: <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> You are correct, we are getting a SIGBUS.? Solaris SPARC does not allow unaligned data access: (dbx) run Running: asn1_encode_test (process id 11159) Reading libc_psr.so.1 Reading libscf.so.1 Reading libdoor.so.1 Reading libuutil.so.1 Reading libgen.so.1 Reading libmd.so.1 Reading libmp.so.2 1..6 ok 1 - test_long_32bit # ASN1_LONG_DATA: #?? success: TRUE t at 1 (l at 1) signal BUS (invalid address alignment) in asn1_item_print_ctx at line 155 in file "tasn_prn.c" ? 155????????? || (it->utype != V_ASN1_BOOLEAN)) && *fld == NULL) { (dbx) where current thread: t at 1 =>[1] asn1_item_print_ctx(out = 0x1001453c0, fld = 0xffffffff7fffd6dc, indent = 2, it = 0xffffffff7f3a29f0, fname = 0x100033ad8 "test_long", sname = (nil), nohdr = 0, pctx = 0xffffffff7f39e8f8), line 155 in "tasn_prn.c" ? [2] asn1_template_print_ctx(out = 0x1001453c0, fld = 0xffffffff7fffd6dc, indent = 2, tt = 0x100137808, pctx = 0xffffffff7f39e8f8), line 328 in "tasn_prn.c" ? [3] asn1_item_print_ctx(out = 0x1001453c0, fld = 0xffffffff7fffd5e0, indent = 0, it = 0x1001376c8, fname = (nil), sname = 0x100033af8 "ASN1_LONG_DATA", nohdr = 0, pctx = 0xffffffff7f39e8f8), line 241 in "tasn_prn.c" ? [4] ASN1_item_print(out = 0x1001453c0, ifld = 0xffffffff7fffd6d4, indent = 0, it = 0x1001376c8, pctx = 0xffffffff7f39e8f8), line 131 in "tasn_prn.c" ? [5] do_print_item(package = 0x100135e68), line 720 in "asn1_encode_test.c" ? [6] test_intern(package = 0x100135e68), line 815 in "asn1_encode_test.c" ? [7] test_long_64bit(), line 832 in "asn1_encode_test.c" ? [8] run_tests(test_prog_name = 0xffffffff7fffef88 "/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/test/asn1_encode_test"), line 205 in "driver.c" ? [9] main(argc = 1, argv = 0xffffffff7fffec08), line 51 in "main.c" (dbx) On 2/19/2018 1:30 PM, Viktor Dukhovni wrote: > >> On Feb 19, 2018, at 4:20 PM, Norm Green wrote: >> >> /export/localnew/sparc.Solaris/bin/gmake depend && /export/localnew/sparc.Solaris/bin/gmake _tests >> gmake[1]: Entering directory '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1' >> gmake[1]: Leaving directory '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1' >> gmake[1]: Entering directory '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1' >> ( cd test; \ >> mkdir -p test-runs; \ >> SRCTOP=../. \ >> BLDTOP=../. \ >> RESULT_D=test-runs \ >> PERL="/opt/perl-5.24.0/bin/perl" \ >> EXE_EXT= \ >> OPENSSL_ENGINES=`cd .././engines; pwd` \ >> OPENSSL_DEBUG_MEMORY=on \ >> /opt/perl-5.24.0/bin/perl .././test/run_tests.pl test_asn1_encode test_secmem ) >> ../test/recipes/04-test_asn1_encode.t .. >> 1..1 >> # Subtest: ../../test/asn1_encode_test >> 1..6 >> ok 1 - test_long_32bit >> # ASN1_LONG_DATA: >> # success: TRUE >> ../../util/shlib_wrap.sh ../../test/asn1_encode_test => 138 > On FreeBSD signal 10 (128 + 10 == 138) is SIGBUS, which could be a result of unaligned > data access (please report "kill -l" output to confirm the signal numbers). > > Could you run this test under gdb, or enable core dumps, and report the stack trace? > You may need a build with debugging symbols. > From norm.green at gemtalksystems.com Mon Feb 19 22:02:28 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Mon, 19 Feb 2018 14:02:28 -0800 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> Message-ID: <87778fae-27da-e5f5-fe3a-3a37ee0d2280@gemtalksystems.com> For the failure in secmemtst, it appears that secure memory is not enabled per this code in ./crypto/mem_sec.c ?23 /* e_os.h includes unistd.h, which defines _POSIX_VERSION */ ?24 #if !defined(OPENSSL_NO_SECURE_MEMORY) && defined(OPENSSL_SYS_UNIX) \ ?25???? && defined(_POSIX_VERSION) && _POSIX_VERSION >= 200112L ?26 # define IMPLEMENTED ?27 # include ?28 # include ?29 # include ?30 # include ?31 # include ?32 # if defined(OPENSSL_SYS_LINUX) ?33 #? include ?34 #? include ?35 #? include ?36 # endif ?37 # include ?38 # include ?39 # include ?40 #endif Solaris has this in sys/unistd.h #ifndef _POSIX_VERSION #ifdef? _XPG6 #define _POSIX_VERSION????????? 200112L /* Supports IEEE Std 1003.1-2001 */ #else #define _POSIX_VERSION????????? 199506L /* Supports POSIX-1c DIS */ #endif #endif /* _POSIX_VERSION */ I'm building with the native Oracle Solaris compiler which apparently does not define these macros. Nornm On 2/19/2018 1:20 PM, Norm Green wrote: > The output is not too long. > > > > /export/localnew/sparc.Solaris/bin/gmake depend && > /export/localnew/sparc.Solaris/bin/gmake _tests > gmake[1]: Entering directory > '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1' > gmake[1]: Leaving directory > '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1' > gmake[1]: Entering directory > '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1' > ( cd test; \ > ? mkdir -p test-runs; \ > ? SRCTOP=../. \ > ? BLDTOP=../. \ > ? RESULT_D=test-runs \ > ? PERL="/opt/perl-5.24.0/bin/perl" \ > ? EXE_EXT= \ > ? OPENSSL_ENGINES=`cd .././engines; pwd` \ > ? OPENSSL_DEBUG_MEMORY=on \ > ??? /opt/perl-5.24.0/bin/perl .././test/run_tests.pl test_asn1_encode > test_secmem ) > ../test/recipes/04-test_asn1_encode.t .. > 1..1 > ??? # Subtest: ../../test/asn1_encode_test > ??? 1..6 > ??? ok 1 - test_long_32bit > ??? # ASN1_LONG_DATA: > ??? #?? success: TRUE > ../../util/shlib_wrap.sh ../../test/asn1_encode_test => 138 > not ok 1 - running asn1_encode_test > > #?? Failed test 'running asn1_encode_test' > #?? at > /hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/test/../util/perl/OpenSSL/Test/Simple.pm > line 77. > # Looks like you failed 1 test of 1. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/1 subtests > ../test/recipes/90-test_secmem.t ....... > 1..1 > ??? # Subtest: ../../test/secmemtest > ??? 1..1 > ??? # ERROR: (bool) 'CRYPTO_secure_malloc_init(4096, 32) == true' > failed @ test/secmemtest.c:28 > ??? # false > ??? not ok 1 - test_sec_mem > ../../util/shlib_wrap.sh ../../test/secmemtest => 1 > not ok 1 - running secmemtest > > #?? Failed test 'running secmemtest' > #?? at > /hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/test/../util/perl/OpenSSL/Test/Simple.pm > line 77. > # Looks like you failed 1 test of 1. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/1 subtests > > Test Summary Report > ------------------- > ../test/recipes/04-test_asn1_encode.t (Wstat: 256 Tests: 1 Failed: 1) > ? Failed test:? 1 > ? Non-zero exit status: 1 > ../test/recipes/90-test_secmem.t???? (Wstat: 256 Tests: 1 Failed: 1) > ? Failed test:? 1 > ? Non-zero exit status: 1 > Files=2, Tests=2,? 2 wallclock secs ( 0.04 usr? 0.01 sys + 0.38 cusr? > 0.16 csys =? 0.59 CPU) > Result: FAIL > Makefile:169: recipe for target '_tests' failed > gmake[1]: *** [_tests] Error 1 > gmake[1]: Leaving directory > '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1' > Makefile:167: recipe for target 'tests' failed > gmake: *** [tests] Error 2 > slow test failed > > > > On 2/19/2018 12:50 PM, Benjamin Kaduk wrote: >> On 02/19/2018 02:06 PM, Norm Green wrote: >>> Not sure if this is expected on this platform? >>> >>> Test Summary Report >>> ------------------- >>> ../test/recipes/04-test_asn1_encode.t??????????? (Wstat: 256 Tests: 1 >>> Failed: 1) >>> ?? Failed test:? 1 >>> ?? Non-zero exit status: 1 >>> ../test/recipes/90-test_secmem.t???????????????? (Wstat: 256 Tests: 1 >>> Failed: 1) >>> ?? Failed test:? 1 >>> ?? Non-zero exit status: 1 >>> Files=141, Tests=1313, 370 wallclock secs ( 3.42 usr? 0.94 sys + >>> 266.48 cusr 40.30 csys = 311.14 CPU) >>> Result: FAIL >>> Makefile:169: recipe for target '_tests' failed >> I do not think it is expected.? Could you capture the output of 'make >> V=1 TESTS="test_asn1_encode test_secmem"' and make it available? >> (Probably via posting it on the web and linking; the output may be >> long.) >> >> -Ben > From paul.dale at oracle.com Mon Feb 19 20:30:52 2018 From: paul.dale at oracle.com (Paul Dale) Date: Mon, 19 Feb 2018 12:30:52 -0800 (PST) Subject: [openssl-users] How to make OpenSSL engine usage application specific? In-Reply-To: References: Message-ID: <55f95185-f307-437f-b2c6-b7ae041c66d8@default> Try RSA_new_method when allocating the RSA_METHOD.? It takes an engine argument which will be used for related operations. ? Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia ? From: Jayalakshmi bhat [mailto:bhat.jayalakshmi at gmail.com] Sent: Monday, 19 February 2018 7:16 PM To: openssl-users at openssl.org Subject: [openssl-users] How to make OpenSSL engine usage application specific? ? Hello All, ? We have 2 RSA OpenSSL engines in our product. Both the engines performs same RSA encyrpt/decrypt operations. For easy explaination I am naming engines as ? 1. RSA smart card? engine? 2. RSA TPM engine? ? Engine usage is application specific.There are couple of applications dependent on RSA TPM? engine. And are few applications dependent on RSA smart card engine.? We wanted to know if there are any APIs provided by OpenSSL to make the engine usage application specific? Is there any way we can make OpenSSL chose specific engine for specific application. ? Regards Jayalakshmi. ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Feb 20 05:00:23 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 20 Feb 2018 05:00:23 +0000 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> Message-ID: <20180220050022.GW3322@mournblade.imrryr.org> On Mon, Feb 19, 2018 at 01:45:26PM -0800, Norm Green wrote: > # ASN1_LONG_DATA: > #?? success: TRUE > t at 1 (l at 1) signal BUS (invalid address alignment) in asn1_item_print_ctx at > line 155 in file "tasn_prn.c" > ? 155????????? || (it->utype != V_ASN1_BOOLEAN)) && *fld == NULL) { Perhaps aligning the item buffer (by using malloc) will help, does the patch below address the problem? diff --git a/test/asn1_encode_test.c b/test/asn1_encode_test.c index e9f459ad65..77fa9b5954 100644 --- a/test/asn1_encode_test.c +++ b/test/asn1_encode_test.c @@ -709,15 +709,19 @@ static int do_encode_custom(EXPECTED *input, static int do_print_item(const TEST_PACKAGE *package) { #define DATA_BUF_SIZE 256 - unsigned char buf[DATA_BUF_SIZE]; const ASN1_ITEM *i = ASN1_ITEM_ptr(package->asn1_type); - ASN1_VALUE *o = (ASN1_VALUE *)&buf; + ASN1_VALUE *o = OPENSSL_malloc(DATA_BUF_SIZE); int ret; OPENSSL_assert(package->encode_expectations_elem_size <= DATA_BUF_SIZE); - (void)RAND_bytes(buf, (int)package->encode_expectations_elem_size); + if (o == NULL) + return 0; + + (void)RAND_bytes((unsigned char *)o, + (int)package->encode_expectations_elem_size); ret = ASN1_item_print(bio_err, o, 0, i, NULL); + OPENSSL_free(o); return ret; } -- Viktor. From tobias.dussa at kit.edu Tue Feb 20 10:04:25 2018 From: tobias.dussa at kit.edu (Tobias Dussa (SCC)) Date: Tue, 20 Feb 2018 11:04:25 +0100 Subject: [openssl-users] Combining certificate and key in PEM format into a P12 file without knowing the key password? Message-ID: <20180220100424.GA10039@kit.edu> Hi, I was wondering whether it was possible somehow to take a certificate and an enciphered private key, both in .pem format, and combine them into a PKCS12 structure without knowing the key passphrase? Googling does not reveal much useful information, unfortunately, and so far we have been unsuccessfully diving into PKCS12/8/5 specs. I don't really see a reason why it should not be possible, but of course that doesn't mean it is. :) THX & Cheers, Toby. -- I am Gates of Borg. Resistance is futile. You will be assimilated. >From now on, you will finance... us. From jb-openssl at wisemo.com Tue Feb 20 11:23:14 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 20 Feb 2018 12:23:14 +0100 Subject: [openssl-users] Combining certificate and key in PEM format into a P12 file without knowing the key password? In-Reply-To: <20180220100424.GA10039@kit.edu> References: <20180220100424.GA10039@kit.edu> Message-ID: On 20/02/2018 11:04, Tobias Dussa (SCC) wrote: > Hi, > > I was wondering whether it was possible somehow to take a certificate and an > enciphered private key, both in .pem format, and combine them into a PKCS12 > structure without knowing the key passphrase? > > Googling does not reveal much useful information, unfortunately, and so far we > have been unsuccessfully diving into PKCS12/8/5 specs. I don't really see a > reason why it should not be possible, but of course that doesn't mean it is. :) > > THX & Cheers, > Toby. In the commonly accepted variants of PKCS#12, private key and all the certificates are encrypted with the same password.? PKCS#12 with different password for private key and certificates is not widely supported. In the concatenated PEM format, only the private key is encrypted, but not the certificates. So to convert from concatenated PEM format to PKCS#12, even if the encrypted private key could be kept without decrypting the private key, the password for the private key is still needed to encrypt the certificates with the same password. 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 tobias.dussa at kit.edu Tue Feb 20 12:15:40 2018 From: tobias.dussa at kit.edu (Tobias Dussa (SCC)) Date: Tue, 20 Feb 2018 13:15:40 +0100 Subject: [openssl-users] Combining certificate and key in PEM format into a P12 file without knowing the key password? In-Reply-To: References: <20180220100424.GA10039@kit.edu> Message-ID: <20180220121540.GB8389@kit.edu> Hi, On Tue, Feb 20, 2018 at 12:23:14PM +0100, Jakob Bohm wrote: > >Googling does not reveal much useful information, unfortunately, and so far we > >have been unsuccessfully diving into PKCS12/8/5 specs. I don't really see a > >reason why it should not be possible, but of course that doesn't mean it is. :) > In the commonly accepted variants of PKCS#12, private key and all the > certificates are encrypted with the same password.? PKCS#12 with > different password for private key and certificates is not widely > supported. I see. > In the concatenated PEM format, only the private key is encrypted, but > not the certificates. Yep. > So to convert from concatenated PEM format to PKCS#12, even if the > encrypted private key could be kept without decrypting the private > key, the password for the private key is still needed to encrypt > the certificates with the same password. ... iff you need to retain wide-spread compatibility. So if that is not necessary, the question remains: Is there a way to reuse an already-encrypted privkey? THX & Cheers, Toby. -- I know that you believe that you understood what you think I said, but I am not sure you realize that what you heard is not what I meant. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6312 bytes Desc: not available URL: From rsalz at akamai.com Tue Feb 20 13:26:02 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 20 Feb 2018 13:26:02 +0000 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <20180220050022.GW3322@mournblade.imrryr.org> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> Message-ID: Would making buf a union also avoid the problem? union { unsigned long dummy[2]; char buf[DATA_BUF_SIZE]; } d and then replace 'buf' with 'd.buf' in the code? ?On 2/20/18, 12:00 AM, "Viktor Dukhovni" wrote: On Mon, Feb 19, 2018 at 01:45:26PM -0800, Norm Green wrote: > # ASN1_LONG_DATA: > # success: TRUE > t at 1 (l at 1) signal BUS (invalid address alignment) in asn1_item_print_ctx at > line 155 in file "tasn_prn.c" > 155 || (it->utype != V_ASN1_BOOLEAN)) && *fld == NULL) { Perhaps aligning the item buffer (by using malloc) will help, does the patch below address the problem? diff --git a/test/asn1_encode_test.c b/test/asn1_encode_test.c index e9f459ad65..77fa9b5954 100644 --- a/test/asn1_encode_test.c +++ b/test/asn1_encode_test.c @@ -709,15 +709,19 @@ static int do_encode_custom(EXPECTED *input, static int do_print_item(const TEST_PACKAGE *package) { #define DATA_BUF_SIZE 256 - unsigned char buf[DATA_BUF_SIZE]; const ASN1_ITEM *i = ASN1_ITEM_ptr(package->asn1_type); - ASN1_VALUE *o = (ASN1_VALUE *)&buf; + ASN1_VALUE *o = OPENSSL_malloc(DATA_BUF_SIZE); int ret; OPENSSL_assert(package->encode_expectations_elem_size <= DATA_BUF_SIZE); - (void)RAND_bytes(buf, (int)package->encode_expectations_elem_size); + if (o == NULL) + return 0; + + (void)RAND_bytes((unsigned char *)o, + (int)package->encode_expectations_elem_size); ret = ASN1_item_print(bio_err, o, 0, i, NULL); + OPENSSL_free(o); return ret; } -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From openssl-users at dukhovni.org Tue Feb 20 13:27:51 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 20 Feb 2018 13:27:51 +0000 Subject: [openssl-users] Combining certificate and key in PEM format into a P12 file without knowing the key password? In-Reply-To: References: <20180220100424.GA10039@kit.edu> Message-ID: <20180220132750.GX3322@mournblade.imrryr.org> On Tue, Feb 20, 2018 at 12:23:14PM +0100, Jakob Bohm wrote: > > I was wondering whether it was possible somehow to take a certificate and an > > enciphered private key, both in .pem format, and combine them into a PKCS12 > > structure without knowing the key passphrase? > > In the commonly accepted variants of PKCS#12, private key and all the > certificates are encrypted with the same password.? PKCS#12 with > different password for private key and certificates is not widely > supported. Do any of the PKCS#12 key derivation functions implement the same password -> key algorithm as is used in OpenSSL's PEM password to key mapping for private keys? I suspect that might be another problem area. What combination of the "-keypbe", "-macalg", and "-maciter" options yields a key derivation function that matches PEM? -- Viktor. From stevenx.linsell at intel.com Tue Feb 20 13:22:20 2018 From: stevenx.linsell at intel.com (Linsell, StevenX) Date: Tue, 20 Feb 2018 13:22:20 +0000 Subject: [openssl-users] How to make OpenSSL engine usage application specific? Message-ID: > On Mon, 19 Feb 2018 Jayalakshmi Bhat wrote: > > Engine usage is application specific.There are couple of applications > dependent on RSA TPM? engine. And are few applications dependent on > RSA smart card engine.? > > We wanted to know if there are any APIs provided by OpenSSL to make the > engine usage application specific? Is there any way we can make OpenSSL > chose specific engine for > > specific application. > I think but don't quote me that if your applications are using the openssl.cnf file to configure the engine you are going to use, then the OPENSSL_CONF environment variable will allow you to control the configuration file loaded by OpenSSL. This allows you to have application specific configuration files that load the engine you require and make it the default engine. This is dependent on your application having been built with OPENSSL_LOAD_CONF defined. You can also control the config file loaded programmatically via OPENSSL_config. The alternative is loading your engine programmatically such as nginx does: https://github.com/nginx/nginx/blob/master/src/event/ngx_event_openssl.c#L4193-L4237 and use ENGINE_set_default to make the engine you require the default for that application. Of course that is only useful if you are in control of your applications source code. There are more details here: https://wiki.openssl.org/index.php/Library_Initialization https://www.openssl.org/docs/manmaster/man5/config.html Steve Linsell Intel Shannon DCG/CID Software Development Team Stevenx.Linsell at intel.com -------------------------------------------------------------- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From openssl-users at dukhovni.org Tue Feb 20 13:38:32 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 20 Feb 2018 13:38:32 +0000 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> Message-ID: <20180220133832.GY3322@mournblade.imrryr.org> On Tue, Feb 20, 2018 at 01:26:02PM +0000, Salz, Rich via openssl-users wrote: > Would making buf a union also avoid the problem? > > union { unsigned long dummy[2]; char buf[DATA_BUF_SIZE]; } d > and then replace 'buf' with 'd.buf' in the code? If alignment of "buf" is the issue, then yes, a suitable union would be an alternative to using malloc. We could make the union: union { unsigned long long dummyl; ossl_uintmax_t dummym; char *dummyp; char buf[DATA_BUF_SIZE]; } d; just in case that's what it takes for the required alignment. But, OPENSSL_malloc() should do the job simply, without such hoop jumping. Either way, the OP should confirm that aligning "buf" solves the reported problem. -- Viktor. From Michael.Wojcik at microfocus.com Tue Feb 20 13:43:27 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 20 Feb 2018 13:43:27 +0000 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <87778fae-27da-e5f5-fe3a-3a37ee0d2280@gemtalksystems.com> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <87778fae-27da-e5f5-fe3a-3a37ee0d2280@gemtalksystems.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Norm Green > Sent: Monday, February 19, 2018 17:02 > To: Benjamin Kaduk; openssl-users at openssl.org > Subject: Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC > > For the failure in secmemtst, it appears that secure memory is not > enabled per this code in ./crypto/mem_sec.c > > ?23 /* e_os.h includes unistd.h, which defines _POSIX_VERSION */ > ?24 #if !defined(OPENSSL_NO_SECURE_MEMORY) && > defined(OPENSSL_SYS_UNIX) \ > ?25???? && defined(_POSIX_VERSION) && _POSIX_VERSION >= 200112L > ?26 # define IMPLEMENTED > ?27 # include > ?28 # include > ?29 # include > ?30 # include > ?31 # include > ?32 # if defined(OPENSSL_SYS_LINUX) > ?33 #? include > ?34 #? include > ?35 #? include > ?36 # endif > ?37 # include > ?38 # include > ?39 # include > ?40 #endif > > > > Solaris has this in sys/unistd.h > > #ifndef _POSIX_VERSION > #ifdef? _XPG6 > #define _POSIX_VERSION????????? 200112L /* Supports IEEE Std 1003.1-2001 */ > #else > #define _POSIX_VERSION????????? 199506L /* Supports POSIX-1c DIS */ > #endif > #endif /* _POSIX_VERSION */ > > I'm building with the native Oracle Solaris compiler which apparently > does not define these macros. Not by default. The comments in /usr/include/sys/feature_tests.h (on a Solaris system) explain this in excruciating detail, but in short you need either -DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or the equivalent in the code) to compile with XPG6 (aka IEEE 1003.1-2001). Solaris has always (well, since Solaris 2) been a bit cautious about making new standards the default, preferring backward compatibility as the default and requiring applications that want new features to set the appropriate feature macros. In this case, that's one of the two macros I listed above. One of them should probably be added to the appropriate entries in Configure. I don't think it much matters which one; they ought to have the same effect, and neither is particularly clear to people who haven't had to dig into this stuff. Disclaimer: I haven't tested this (in the OpenSSL case), just confirmed what feature_tests.h says. -- Michael Wojcik Distinguished Engineer, Micro Focus From dlmeetei at gmail.com Tue Feb 20 15:38:25 2018 From: dlmeetei at gmail.com (Devchandra L Meetei) Date: Tue, 20 Feb 2018 21:08:25 +0530 Subject: [openssl-users] Loading CA from memory Message-ID: I have been looking for API like `SSL_CTX_load_verify_mem` which will load CA[s] from mem buffer. Looks like OpenSSL does not have it yet, Is there any other way to work around this ? -- Warm Regards --Dev OpenPegasus Developer "I'm one of those people that think Thomas Edison and the light bulb changed the world more than Karl Marx ever did,? Steve Jobs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Feb 20 15:53:48 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 20 Feb 2018 16:53:48 +0100 Subject: [openssl-users] Loading CA from memory In-Reply-To: References: Message-ID: <5b27fe5e-e2b9-c6fa-391f-75c4ffcdb5d8@wisemo.com> On 20/02/2018 16:38, Devchandra L Meetei wrote: > I have been looking for? API like `SSL_CTX_load_verify_mem` which will > load > CA[s] from mem buffer. > > Looks like OpenSSL does not have it yet, Is there any other way to > work around > this ? > > I think it can be done step by step, at least in 1.0.x: First allocate an empty STACK_OF X509 certificates Then loop over your in-memory CA certificates, passing each to d2i_X509, then adding the resulting X509 object to the stack. Finally pass that stack as the CA collection to an appropriate SSL_CTX function. 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 fm at frank4dd.com Tue Feb 20 16:04:17 2018 From: fm at frank4dd.com (Frank Migge) Date: Wed, 21 Feb 2018 01:04:17 +0900 Subject: [openssl-users] Combining certificate and key in PEM format into a P12 file without knowing the key password? In-Reply-To: <20180220121540.GB8389@kit.edu> References: <20180220100424.GA10039@kit.edu> <20180220121540.GB8389@kit.edu> Message-ID: <5A8C4701.50703@frank4dd.com> Hi Toby, >> the question remains: Is there a way to reuse an already-encrypted privkey? I'd say yes it *could* work, but not with OpenSSL API functions. You'd have to roll your own code for the PKCS12 creation. OpenSSL's PKCS12_create() function expects an unencrypted EVP_PKEY object. But, internally, that key is turned into a encrypted PKCS8 structure, as expected by the PKCS8ShroudedKeyBag type defined in RFC-7292. Thats why I think it may be possible to experiment and modify code such as in crypto/pkcs12/p12_crt.c, trying to pass-through that already encrypted PKCS8 key "as-is" straight into the pkcs8ShroudedKeyBag object. If your key is a file in PEM format, you'd need to get that into an internal structure first (more coding), I don't think there is a simple API import (without decryption). If you manage to successfully built that PKCS12, you'd run into trouble for decoding, which probably fails for all known software. They all expect to be able to read the private key, when in your case it needs saving to a file somewhere for further handling, or for entering that second key-specific password. You'd again have to code your own PKCS12 unpack program, just for this specific use case. I may be wrong but to me it looks doable, just a *lot* of work. Frank > Tobias Dussa (SCC) > Tuesday, February 20, 2018 9:15 PM > Hi, > > On Tue, Feb 20, 2018 at 12:23:14PM +0100, Jakob Bohm wrote: >>> Googling does not reveal much useful information, unfortunately, and so far we >>> have been unsuccessfully diving into PKCS12/8/5 specs. I don't really see a >>> reason why it should not be possible, but of course that doesn't mean it is. :) >> In the commonly accepted variants of PKCS#12, private key and all the >> certificates are encrypted with the same password. PKCS#12 with >> different password for private key and certificates is not widely >> supported. > > I see. > >> In the concatenated PEM format, only the private key is encrypted, but >> not the certificates. > > Yep. > >> So to convert from concatenated PEM format to PKCS#12, even if the >> encrypted private key could be kept without decrypting the private >> key, the password for the private key is still needed to encrypt >> the certificates with the same password. > > ... iff you need to retain wide-spread compatibility. So if that is not > necessary, the question remains: Is there a way to reuse an already-encrypted > privkey? > > THX & Cheers, > Toby. > Jakob Bohm > Tuesday, February 20, 2018 8:23 PM > > In the commonly accepted variants of PKCS#12, private key and all the > certificates are encrypted with the same password. PKCS#12 with > different password for private key and certificates is not widely > supported. > > In the concatenated PEM format, only the private key is encrypted, but > not the certificates. > > So to convert from concatenated PEM format to PKCS#12, even if the > encrypted private key could be kept without decrypting the private > key, the password for the private key is still needed to encrypt > the certificates with the same password. > > > Enjoy > > Jakob > Tobias Dussa (SCC) > Tuesday, February 20, 2018 7:04 PM > Hi, > > I was wondering whether it was possible somehow to take a certificate > and an > enciphered private key, both in .pem format, and combine them into a > PKCS12 > structure without knowing the key passphrase? > > Googling does not reveal much useful information, unfortunately, and > so far we > have been unsuccessfully diving into PKCS12/8/5 specs. I don't really > see a > reason why it should not be possible, but of course that doesn't mean > it is. :) > > THX & Cheers, > Toby. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.dussa at kit.edu Tue Feb 20 16:33:38 2018 From: tobias.dussa at kit.edu (Tobias Dussa (SCC)) Date: Tue, 20 Feb 2018 17:33:38 +0100 Subject: [openssl-users] Combining certificate and key in PEM format into a P12 file without knowing the key password? In-Reply-To: <5A8C4701.50703@frank4dd.com> References: <20180220100424.GA10039@kit.edu> <20180220121540.GB8389@kit.edu> <5A8C4701.50703@frank4dd.com> Message-ID: <20180220163338.GC8389@kit.edu> Hi, On Wed, Feb 21, 2018 at 01:04:17AM +0900, Frank Migge wrote: > >> the question remains: Is there a way to reuse an already-encrypted privkey? > I'd say yes it *could* work, but not with OpenSSL API functions. You'd > have to roll your own code for the PKCS12 creation. > OpenSSL's PKCS12_create() function expects an unencrypted EVP_PKEY > object. But, internally, that key is turned into a encrypted PKCS8 > structure, as expected by the PKCS8ShroudedKeyBag type defined in RFC-7292. That's about what I thought I figured out, yeah. :) > Thats why I think it may be possible to experiment and modify code such > as in crypto/pkcs12/p12_crt.c, trying to pass-through that already > encrypted PKCS8 key "as-is" straight into the pkcs8ShroudedKeyBag > object. If your key is a file in PEM format, you'd need to get that into > an internal structure first (more coding), I don't think there is a > simple API import (without decryption). > If you manage to successfully built that PKCS12, you'd run into trouble > for decoding, which probably fails for all known software. They all > expect to be able to read the private key, when in your case it needs > saving to a file somewhere for further handling, or for entering that > second key-specific password. You'd again have to code your own PKCS12 > unpack program, just for this specific use case. > I may be wrong but to me it looks doable, just a *lot* of work. ... and that, unfortunately, is about what I concluded as well. Bummer. ;-) But thanks a lot for your thoughts (also to Jakob and Viktor)! :) Cheers, Toby. -- To the systems programmer, users and applications serve only to provide a test load. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6312 bytes Desc: not available URL: From tobias.dussa at kit.edu Tue Feb 20 16:35:43 2018 From: tobias.dussa at kit.edu (Tobias Dussa (SCC)) Date: Tue, 20 Feb 2018 17:35:43 +0100 Subject: [openssl-users] Combining certificate and key in PEM format into a P12 file without knowing the key password? In-Reply-To: <20180220132750.GX3322@mournblade.imrryr.org> References: <20180220100424.GA10039@kit.edu> <20180220132750.GX3322@mournblade.imrryr.org> Message-ID: <20180220163543.GD8389@kit.edu> Hi, On Tue, Feb 20, 2018 at 01:27:51PM +0000, Viktor Dukhovni wrote: > > In the commonly accepted variants of PKCS#12, private key and all the > > certificates are encrypted with the same password.? PKCS#12 with > > different password for private key and certificates is not widely > > supported. > Do any of the PKCS#12 key derivation functions implement the same > password -> key algorithm as is used in OpenSSL's PEM password to > key mapping for private keys? I suspect that might be another > problem area. Uh... Good point. Didn't have that on the radar actually. Thanks! Cheers, Toby. -- We're Germans and we use Unix. That's a combination of two demographic groups known to have no sense of humour whatsoever. ---Hanno Mueller in de.comp.os.unix.programming -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6312 bytes Desc: not available URL: From norm.green at gemtalksystems.com Tue Feb 20 16:36:55 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 20 Feb 2018 08:36:55 -0800 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <20180220050022.GW3322@mournblade.imrryr.org> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> Message-ID: Hi Viktor, Your patch tests clean, however there is an easier way which avoids malloc: Norm Index: test/asn1_encode_test.c =================================================================== --- test/asn1_encode_test.c???? (revision 43654) +++ test/asn1_encode_test.c???? (working copy) @@ -706,15 +706,16 @@ ???? return ret; ?} ?static int do_print_item(const TEST_PACKAGE *package) ?{ ?#define DATA_BUF_SIZE 256 -??? unsigned char buf[DATA_BUF_SIZE]; +??? uint64_t _buf[DATA_BUF_SIZE / sizeof(uint64_t)];/* force 8-byte alignment */ +??? unsigned char *buf = (unsigned char *) _buf; ???? const ASN1_ITEM *i = ASN1_ITEM_ptr(package->asn1_type); -??? ASN1_VALUE *o = (ASN1_VALUE *)&buf; +??? ASN1_VALUE *o = (ASN1_VALUE *)buf; ???? int ret; OPENSSL_assert(package->encode_expectations_elem_size <= DATA_BUF_SIZE); ???? (void)RAND_bytes(buf, (int)package->encode_expectations_elem_size); ???? ret = ASN1_item_print(bio_err, o, 0, i, NULL); On 2/19/2018 9:00 PM, Viktor Dukhovni wrote: > On Mon, Feb 19, 2018 at 01:45:26PM -0800, Norm Green wrote: > >> # ASN1_LONG_DATA: >> #?? success: TRUE >> t at 1 (l at 1) signal BUS (invalid address alignment) in asn1_item_print_ctx at >> line 155 in file "tasn_prn.c" >> ? 155????????? || (it->utype != V_ASN1_BOOLEAN)) && *fld == NULL) { > Perhaps aligning the item buffer (by using malloc) will help, does > the patch below address the problem? > > diff --git a/test/asn1_encode_test.c b/test/asn1_encode_test.c > index e9f459ad65..77fa9b5954 100644 > --- a/test/asn1_encode_test.c > +++ b/test/asn1_encode_test.c > @@ -709,15 +709,19 @@ static int do_encode_custom(EXPECTED *input, > static int do_print_item(const TEST_PACKAGE *package) > { > #define DATA_BUF_SIZE 256 > - unsigned char buf[DATA_BUF_SIZE]; > const ASN1_ITEM *i = ASN1_ITEM_ptr(package->asn1_type); > - ASN1_VALUE *o = (ASN1_VALUE *)&buf; > + ASN1_VALUE *o = OPENSSL_malloc(DATA_BUF_SIZE); > int ret; > > OPENSSL_assert(package->encode_expectations_elem_size <= DATA_BUF_SIZE); > > - (void)RAND_bytes(buf, (int)package->encode_expectations_elem_size); > + if (o == NULL) > + return 0; > + > + (void)RAND_bytes((unsigned char *)o, > + (int)package->encode_expectations_elem_size); > ret = ASN1_item_print(bio_err, o, 0, i, NULL); > + OPENSSL_free(o); > > return ret; > } > From d3ck0r at gmail.com Tue Feb 20 17:34:18 2018 From: d3ck0r at gmail.com (J Decker) Date: Tue, 20 Feb 2018 09:34:18 -0800 Subject: [openssl-users] Has client validated successfully? In-Reply-To: References: Message-ID: On Tue, Feb 13, 2018 at 9:33 AM, Emmanuel Deloget wrote: > Hello, > > On Tue, Feb 13, 2018 at 7:14 AM, Kyle Hamilton wrote: > > > The only thing that the server can know is whether the client has > > terminated the connection with a fatal alert. If the client validates > > presented cert chains, then its continuation with the connection means > > that it passed validation. If the client does not, or ignores any > > given error, then it doesn't mean that it passed validation. > > > > In other words, you can only know if the client's applied policy > > allows the connection to continue. You cannot know if the policy that > > was applied was specifically related to the certificate chain > > presented. > > > > -Kyle H > > > > On Mon, Feb 12, 2018 at 10:06 PM, J Decker wrote: > > > Is there a way for a server to know if the client verified the cert > chain > > > successfully or not? > > > > ?From a security PoV, that doesn't help much. One can build a malicious > version of openvpn that will tell you "everything's ok" (or "it failed!", > depending of its goal)?. The server should not make any decision w.r.t. the > client state (that's more or less what is implied by Kyle's answer ; I just > wanted to stress it). > > Yes that is true.... however here's the scenario. Client does a verification and passes or fails, and via the SSL layer I can query if the client validated the certificate. If it failed, provide a option for the client to get a renewed certificate for verification. If success, no action. If an actor lies in this scenario he answers lies *yes* and didn't, don't give him a means to actually verify. *noop* lies *no* but did, then give him the root cert he already has.... *noop* so I don't have to trust the reply.... I'm willing to give him the right root. > BR, > > -- Emmanuel Deloget > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norm.green at gemtalksystems.com Tue Feb 20 17:47:34 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 20 Feb 2018 09:47:34 -0800 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <87778fae-27da-e5f5-fe3a-3a37ee0d2280@gemtalksystems.com> Message-ID: <6d71ad48-5754-f942-ae33-2dc606083371@gemtalksystems.com> On 2/20/2018 5:43 AM, Michael Wojcik wrote: > Not by default. The comments in /usr/include/sys/feature_tests.h (on a Solaris system) explain this in excruciating detail, but in short you need either -DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or the equivalent in the code) to compile with XPG6 (aka IEEE 1003.1-2001). Thanks for the suggestions Michael.? Neither resolves the problem. In fact, adding -D_XOPEN_SOURCE=600 causes a new problem: /opt/solarisstudio12.3/bin/c99? -I. -Icrypto/include -Iinclude -m64 -xtarget=ultra2 -D_XOPEN_SOURCE=600 -xstrconst -Xa -DB_ENDIAN -DBN_DIV2W -KPIC -xildoff -mt -xcode=pic32 -g -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DFILIO_H -DB_ENDIAN -DBN_DIV2W -D_REENTRANT -DOPENSSLDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/ssl\"" -DENGINESDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/lib/engines-1.1\"" -c -o crypto/bio/b_addr.o crypto/bio/b_addr.c "crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXHOST "crypto/bio/b_addr.c", line 198: variable length array can not be initialized: host "crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXSERV "crypto/bio/b_addr.c", line 198: variable length array can not be initialized: serv c99: acomp failed for crypto/bio/b_addr.c Makefile:881: recipe for target 'crypto/bio/b_addr.o' failed I also tried building with c99 instead of cc, without success. Norm From dlmeetei at gmail.com Tue Feb 20 17:58:21 2018 From: dlmeetei at gmail.com (Devchandra L Meetei) Date: Tue, 20 Feb 2018 23:28:21 +0530 Subject: [openssl-users] Loading CA from memory In-Reply-To: <5b27fe5e-e2b9-c6fa-391f-75c4ffcdb5d8@wisemo.com> References: <5b27fe5e-e2b9-c6fa-391f-75c4ffcdb5d8@wisemo.com> Message-ID: Thanks Jakob for the hint Let me try out the suggested approach. By the way, Is there any plan to port SSL_CTX_load_verify_mem to openssl? On Tue, Feb 20, 2018 at 9:23 PM, Jakob Bohm wrote: > On 20/02/2018 16:38, Devchandra L Meetei wrote: > >> I have been looking for API like `SSL_CTX_load_verify_mem` which will >> load >> CA[s] from mem buffer. >> >> Looks like OpenSSL does not have it yet, Is there any other way to work >> around >> this ? >> >> >> I think it can be done step by step, at least in 1.0.x: > > First allocate an empty STACK_OF X509 certificates > > Then loop over your in-memory CA certificates, passing each to d2i_X509, > then adding the resulting X509 object to the stack. > > Finally pass that stack as the CA collection to an appropriate SSL_CTX > function. > > > 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 > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Warm Regards --Dev OpenPegasus Developer "I'm one of those people that think Thomas Edison and the light bulb changed the world more than Karl Marx ever did,? Steve Jobs -------------- next part -------------- An HTML attachment was scrubbed... URL: From dclarke at blastwave.org Tue Feb 20 18:01:40 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 20 Feb 2018 13:01:40 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <6d71ad48-5754-f942-ae33-2dc606083371@gemtalksystems.com> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <87778fae-27da-e5f5-fe3a-3a37ee0d2280@gemtalksystems.com> <6d71ad48-5754-f942-ae33-2dc606083371@gemtalksystems.com> Message-ID: <0283f58e-d834-d250-ae95-414793523caf@blastwave.org> On 20/02/18 12:47 PM, Norm Green wrote: > On 2/20/2018 5:43 AM, Michael Wojcik wrote: >> Not by default. The comments in /usr/include/sys/feature_tests.h (on a >> Solaris system) explain this in excruciating detail, but in short you >> need either -DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or the >> equivalent in the code) to compile with XPG6 (aka IEEE 1003.1-2001). > Thanks for the suggestions Michael.? Neither resolves the problem. In > fact, adding -D_XOPEN_SOURCE=600 causes a new problem: > > /opt/solarisstudio12.3/bin/c99? -I. -Icrypto/include -Iinclude -m64 > -xtarget=ultra2 -D_XOPEN_SOURCE=600 -xstrconst -Xa -DB_ENDIAN -DBN_DIV2W > -KPIC -xildoff -mt -xcode=pic32 -g -DDSO_DLFCN -DHAVE_DLFCN_H > -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM > -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM > -DPOLY1305_ASM -DFILIO_H -DB_ENDIAN -DBN_DIV2W -D_REENTRANT > -DOPENSSLDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/ssl\"" > -DENGINESDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/lib/engines-1.1\"" > -c -o crypto/bio/b_addr.o crypto/bio/b_addr.c > "crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXHOST > "crypto/bio/b_addr.c", line 198: variable length array can not be > initialized: host > "crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXSERV > "crypto/bio/b_addr.c", line 198: variable length array can not be > initialized: serv > c99: acomp failed for crypto/bio/b_addr.c > Makefile:881: recipe for target 'crypto/bio/b_addr.o' failed > > > I also tried building with c99 instead of cc, without success. > Is there a handy source tarball somewhere so that I may also have a look at this? I have had good success in the past with both c99 and with fairly restrictive CFLAGS so I would like to look into this also. Dennis From norm.green at gemtalksystems.com Tue Feb 20 18:11:26 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 20 Feb 2018 10:11:26 -0800 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <0283f58e-d834-d250-ae95-414793523caf@blastwave.org> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <87778fae-27da-e5f5-fe3a-3a37ee0d2280@gemtalksystems.com> <6d71ad48-5754-f942-ae33-2dc606083371@gemtalksystems.com> <0283f58e-d834-d250-ae95-414793523caf@blastwave.org> Message-ID: Just download and build v1.1.1 pre alpha 1 on Solaris.? It's on ftp.openssl.org.? That's all I did.? Configure using solaris64-sparcv9-cc .? I'm using Solaris studio 12.3. Norm On 2/20/2018 10:01 AM, Dennis Clarke wrote: > On 20/02/18 12:47 PM, Norm Green wrote: >> On 2/20/2018 5:43 AM, Michael Wojcik wrote: >>> Not by default. The comments in /usr/include/sys/feature_tests.h (on >>> a Solaris system) explain this in excruciating detail, but in short >>> you need either -DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or >>> the equivalent in the code) to compile with XPG6 (aka IEEE >>> 1003.1-2001). >> Thanks for the suggestions Michael.? Neither resolves the problem. In >> fact, adding -D_XOPEN_SOURCE=600 causes a new problem: >> >> /opt/solarisstudio12.3/bin/c99? -I. -Icrypto/include -Iinclude -m64 >> -xtarget=ultra2 -D_XOPEN_SOURCE=600 -xstrconst -Xa -DB_ENDIAN >> -DBN_DIV2W -KPIC -xildoff -mt -xcode=pic32 -g -DDSO_DLFCN >> -DHAVE_DLFCN_H -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC >> -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m >> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM >> -DECP_NISTZ256_ASM -DPOLY1305_ASM -DFILIO_H -DB_ENDIAN -DBN_DIV2W >> -D_REENTRANT >> -DOPENSSLDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/ssl\"" >> -DENGINESDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/lib/engines-1.1\"" >> -c -o crypto/bio/b_addr.o crypto/bio/b_addr.c >> "crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXHOST >> "crypto/bio/b_addr.c", line 198: variable length array can not be >> initialized: host >> "crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXSERV >> "crypto/bio/b_addr.c", line 198: variable length array can not be >> initialized: serv >> c99: acomp failed for crypto/bio/b_addr.c >> Makefile:881: recipe for target 'crypto/bio/b_addr.o' failed >> >> >> I also tried building with c99 instead of cc, without success. >> > > > Is there a handy source tarball somewhere so that I may also have a > look at this?? I have had good success in the past with both c99 and > with fairly restrictive CFLAGS so I would like to look into this > also. > > Dennis > > > From dclarke at blastwave.org Tue Feb 20 18:14:34 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 20 Feb 2018 13:14:34 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <87778fae-27da-e5f5-fe3a-3a37ee0d2280@gemtalksystems.com> <6d71ad48-5754-f942-ae33-2dc606083371@gemtalksystems.com> <0283f58e-d834-d250-ae95-414793523caf@blastwave.org> Message-ID: On 20/02/18 01:11 PM, Norm Green wrote: > Just download and build v1.1.1 pre alpha 1 on Solaris.? It's on > ftp.openssl.org.? That's all I did.? Configure using > solaris64-sparcv9-cc .? I'm using Solaris studio 12.3. Did you modify the Configure file ? Last time I looked the CFLAGS as well as some other bits in there were terribly out of date and not really what we want for a debug build. Dennis From dclarke at blastwave.org Tue Feb 20 18:33:43 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 20 Feb 2018 13:33:43 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <87778fae-27da-e5f5-fe3a-3a37ee0d2280@gemtalksystems.com> <6d71ad48-5754-f942-ae33-2dc606083371@gemtalksystems.com> <0283f58e-d834-d250-ae95-414793523caf@blastwave.org> Message-ID: <407358b3-adc3-69b9-1393-200e11f64349@blastwave.org> On 20/02/18 01:11 PM, Norm Green wrote: > Just download and build v1.1.1 pre alpha 1 on Solaris.? It's on > ftp.openssl.org.? That's all I did.? Configure using > solaris64-sparcv9-cc .? I'm using Solaris studio 12.3. Let's have a look. corv $ uname -a SunOS corv 5.10 Generic_150400-59 sun4u sparc SUNW,SPARC-Enterprise corv $ /opt/developerstudio12.6/bin/c99 -V c99: Studio 12.6 Sun C 5.15 SunOS_sparc 2017/05/30 corv $ psrinfo -pv The physical processor has 8 virtual processors (0-7) SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz) corv $ pwd /usr/local/src corv $ cd ../build corv $ gzip -dc ../src/openssl-1.1.1-pre1.tar.gz | tar -xf - corv $ mv openssl-1.1.1-pre1 openssl-1.1.1-pre1_SunOS5.10_sparcv9.001 corv $ cd openssl-1.1.1-pre1_SunOS5.10_sparcv9.001 corv $ cp -p Configure Configure.backup corv $ OPENSSL_SOURCE=`pwd` corv $ export OPENSSL_SOURCE corv $ echo $OPENSSL_SOURCE /usr/local/build/openssl-1.1.1-pre1_SunOS5.10_sparcv9.001 OKay .. whats going on here ? corv $ grep -i "sparc" Configure Doesn't exist ... has to have been moved somewhere. These two files make reference to solaris64 in some way : ./Configurations/10-main.conf ./config Interesting comment : #### Solaris x86 with Sun C setups # There used to be solaris-x86-cc target, but it was removed, # primarily because vendor assembler can't assemble our modules # with -KPIC flag. As result it, assembly support, was not even # available as option. But its lack means lack of side-channel # resistant code, which is incompatible with security by todays # standards. Fortunately gcc is readily available prepackaged # option, which we can firmly point at... # # On related note, solaris64-x86_64-cc target won't compile code # paths utilizing AVX and post-Haswell instruction extensions. # Consider switching to solaris64-x86_64-gcc even here... # Pre-packaged? Really ... let's not go down the route of argument today. "solaris64-sparcv9-cc" => { inherit_from => [ "solaris-sparcv7-cc", asm("sparcv9_asm") ], cflags => add_before("-xarch=v9"), bn_ops => "BN_LLONG RC4_CHAR", multilib => "/64", }, Actually xarch=v9 is wrong. Should just say "sparc". Well it looks like lots has changed ... so let me fish around in here and find what is going on with Configure and its new sub-files and then see if I can get a compile going as a debug build. Also I have gcc 7.2.0 here but there isn't any such thing as "pre-packaged". Dennis From norm.green at gemtalksystems.com Tue Feb 20 18:36:38 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 20 Feb 2018 10:36:38 -0800 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <87778fae-27da-e5f5-fe3a-3a37ee0d2280@gemtalksystems.com> <6d71ad48-5754-f942-ae33-2dc606083371@gemtalksystems.com> <0283f58e-d834-d250-ae95-414793523caf@blastwave.org> Message-ID: <12c1260d-e354-41fd-51db-d7b94dc2af7d@gemtalksystems.com> Hi Dennis, You're right, I did modify the config file, sorry.? I did it so long ago I had forgotten.? I will email it to you shortly. Norm On 2/20/2018 10:14 AM, Dennis Clarke wrote: > On 20/02/18 01:11 PM, Norm Green wrote: >> Just download and build v1.1.1 pre alpha 1 on Solaris.? It's on >> ftp.openssl.org.? That's all I did. Configure using >> solaris64-sparcv9-cc .? I'm using Solaris studio 12.3. > > Did you modify the Configure file ?? Last time I looked the CFLAGS > as well as some other bits in there were terribly out of date and > not really what we want for a debug build. > > Dennis > From jochen.bern at binect.de Tue Feb 20 18:33:03 2018 From: jochen.bern at binect.de (Jochen Bern) Date: Tue, 20 Feb 2018 19:33:03 +0100 Subject: [openssl-users] Has client validated successfully? In-Reply-To: References: Message-ID: <61642344-0b92-df56-a87a-a06fd4ab2ab7@binect.de> On 02/20/2018 06:34 PM, J Decker wrote: > Yes that is true.... however here's the scenario. > Client does a verification and passes or fails, and via the SSL layer I can > query if the client validated the certificate. > If it failed, provide a option for the client to get a renewed certificate > for verification. If success, no action. > If an actor lies in this scenario he answers > lies *yes* and didn't, don't give him a means to actually verify. *noop* > lies *no* but did, then give him the root cert he already has.... *noop* > > so I don't have to trust the reply.... I'm willing to give him the right > root. That's nice from the server's POV, but the client REALLY REALLY SHOULD NOT install and/or put trust into any CA certs it received in-band in a connection that failed verification. The best (for you) it can do is to store it and offer it to its user for additional verification and *then* installation - and I'ld venture a guess that you'ld have to write such a client yourself. (And offering the *root* certificate isn't that far from the common practice of a server sending *most* of its CA chain in addition to its own certificate, anyway, so it's debatable whether you even *need* the result of the client's verification as an input to send the root as well.) Kind regards, -- Jochen Bern Systemingenieur Binect GmbH -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4278 bytes Desc: S/MIME Cryptographic Signature URL: From aerowolf at gmail.com Tue Feb 20 18:50:01 2018 From: aerowolf at gmail.com (Kyle Hamilton) Date: Tue, 20 Feb 2018 10:50:01 -0800 Subject: [openssl-users] Has client validated successfully? In-Reply-To: References: Message-ID: No, you cannot query the SSL layer to know if the client validated the certificate. SSL/TLS don't provide any means of querying the remote side. Here's how the workflow works: 1) client doesn't trust certificate, doesn't override distrust: connection closes with fatal unknown_ca or expired_certificate alert. 2) client doesn't trust certificate, does override distrust: connection continues. No way to query if distrust was overridden. 3) client does trust certificate, no need to override: connection continues. No way to query if distrust was overridden. There's no way for the server to know if the client trusts the certificate, or if the client overrode the distrust. There's generally also no way for Javascript on the client to know this, either. However, because this is a list about OpenSSL (and not about any given application of OpenSSL, i.e. the web) it's not the best place to ask about how to do this on the web. Certificate chain updates (to avoid chain expiration) by the server are expected to be done unilaterally, by the server operator. If different certificate chains need to be provided to different clients, the different clients can request different hostnames (via the Server Name Indication extension) so the server can decide which certificate chain to present. As much as it sucks, this is the only server certificate selection mechanism that exists in SSL/TLS. -Kyle H On Tue, Feb 20, 2018 at 9:34 AM, J Decker wrote: > > > On Tue, Feb 13, 2018 at 9:33 AM, Emmanuel Deloget wrote: >> >> Hello, >> >> On Tue, Feb 13, 2018 at 7:14 AM, Kyle Hamilton wrote: >> >> > The only thing that the server can know is whether the client has >> > terminated the connection with a fatal alert. If the client validates >> > presented cert chains, then its continuation with the connection means >> > that it passed validation. If the client does not, or ignores any >> > given error, then it doesn't mean that it passed validation. >> > >> > In other words, you can only know if the client's applied policy >> > allows the connection to continue. You cannot know if the policy that >> > was applied was specifically related to the certificate chain >> > presented. >> > >> > -Kyle H >> > >> > On Mon, Feb 12, 2018 at 10:06 PM, J Decker wrote: >> > > Is there a way for a server to know if the client verified the cert >> > > chain >> > > successfully or not? >> > >> >> From a security PoV, that doesn't help much. One can build a malicious >> version of openvpn that will tell you "everything's ok" (or "it failed!", >> depending of its goal). The server should not make any decision w.r.t. the >> client state (that's more or less what is implied by Kyle's answer ; I >> just >> wanted to stress it). >> > > Yes that is true.... however here's the scenario. > Client does a verification and passes or fails, and via the SSL layer I can > query if the client validated the certificate. > If it failed, provide a option for the client to get a renewed certificate > for verification. If success, no action. > If an actor lies in this scenario he answers > lies *yes* and didn't, don't give him a means to actually verify. *noop* > lies *no* but did, then give him the root cert he already has.... *noop* > > so I don't have to trust the reply.... I'm willing to give him the right > root. > >> >> BR, >> >> -- Emmanuel Deloget > > From dclarke at blastwave.org Tue Feb 20 18:50:06 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 20 Feb 2018 13:50:06 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <12c1260d-e354-41fd-51db-d7b94dc2af7d@gemtalksystems.com> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <87778fae-27da-e5f5-fe3a-3a37ee0d2280@gemtalksystems.com> <6d71ad48-5754-f942-ae33-2dc606083371@gemtalksystems.com> <0283f58e-d834-d250-ae95-414793523caf@blastwave.org> <12c1260d-e354-41fd-51db-d7b94dc2af7d@gemtalksystems.com> Message-ID: On 20/02/18 01:36 PM, Norm Green wrote: > Hi Dennis, > > You're right, I did modify the config file, sorry.? I did it so long ago > I had forgotten.? I will email it to you shortly. > Not a problem .. everyone does. I mean look at this mess if you don't : corv $ ./Configure shared zlib threads solaris64-sparcv9-cc Perl v5.10.0 required--this is only v5.8.4, stopped at ./Configure line 12. BEGIN failed--compilation aborted at ./Configure line 12. corv $ uh huh. I have newer perl I built myself but I generally start with the baseline system stuff .. which is covered in dust and mold : corv $ /usr/local/bin/perl -V Summary of my perl5 (revision 5 version 26 subversion 0) configuration: . . . So ... this will be fun. Dennis From rsalz at akamai.com Tue Feb 20 18:52:39 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 20 Feb 2018 18:52:39 +0000 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <87778fae-27da-e5f5-fe3a-3a37ee0d2280@gemtalksystems.com> <6d71ad48-5754-f942-ae33-2dc606083371@gemtalksystems.com> <0283f58e-d834-d250-ae95-414793523caf@blastwave.org> <12c1260d-e354-41fd-51db-d7b94dc2af7d@gemtalksystems.com> Message-ID: > So ... this will be fun. :) Thanks for poking at this, folks. Please take a look at the INSTALL and README files which do cover some of this prerequisites. And then once you've "fixed" it, let us know what we need to change!! From dclarke at blastwave.org Tue Feb 20 19:01:04 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 20 Feb 2018 14:01:04 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <87778fae-27da-e5f5-fe3a-3a37ee0d2280@gemtalksystems.com> <6d71ad48-5754-f942-ae33-2dc606083371@gemtalksystems.com> <0283f58e-d834-d250-ae95-414793523caf@blastwave.org> <12c1260d-e354-41fd-51db-d7b94dc2af7d@gemtalksystems.com> Message-ID: <2d41710b-e268-a726-283f-0f0931032221@blastwave.org> On 20/02/18 01:50 PM, Dennis Clarke wrote: > On 20/02/18 01:36 PM, Norm Green wrote: Making progress here ... /opt/developerstudio12.6/bin/c99 -I. -Icrypto/include -Iinclude -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -Qy -xs -g -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -KPIC -DDSO_DLFCN -DHAVE_DLFCN_H -DZLIB -DNDEBUG -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -c -o crypto/bio/bss_bio.o crypto/bio/bss_bio.c "crypto/bio/bss_bio.c", line 244: error: undefined symbol: OSSL_SSIZE_MAX "crypto/bio/bss_bio.c", line 400: error: undefined symbol: OSSL_SSIZE_MAX c99: acomp failed for crypto/bio/bss_bio.c gmake[1]: *** [Makefile:1781: crypto/bio/bss_bio.o] Error 2 gmake[1]: Leaving directory '/usr/local/build/openssl-1.1.1-pre1_SunOS5.10_sparcv9.001' gmake: *** [Makefile:143: all] Error 2 corv $ let me track down that undef there dc From openssl-users at dukhovni.org Tue Feb 20 19:08:21 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 20 Feb 2018 14:08:21 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> Message-ID: <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> > On Feb 20, 2018, at 11:36 AM, Norm Green wrote: > > Your patch tests clean, however there is an easier way which avoids malloc: Great, so it was the unaligned "buf". Great. As for malloc vs. tricks to align the stack-based array, I see little need to avoid malloc() this is a test function, not a performance-critical library function. Exercising OPENSSL_malloc() is arguably a feature. :-) That said, I have no religion on which approach is taken to align "buf". I prefer "malloc" because it unasks the question of which type to use in an array or union to ensure the "proper" alignment. Using any of "long" or "long long" is likely good enough, but could prove more fragile as the code evolves. -- Viktor. From rsalz at akamai.com Tue Feb 20 19:09:21 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 20 Feb 2018 19:09:21 +0000 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> Message-ID: I agree, let's just use malloc for the reasons you said. PR later today. ?On 2/20/18, 2:08 PM, "Viktor Dukhovni" wrote: > On Feb 20, 2018, at 11:36 AM, Norm Green wrote: > > Your patch tests clean, however there is an easier way which avoids malloc: Great, so it was the unaligned "buf". Great. As for malloc vs. tricks to align the stack-based array, I see little need to avoid malloc() this is a test function, not a performance-critical library function. Exercising OPENSSL_malloc() is arguably a feature. :-) That said, I have no religion on which approach is taken to align "buf". I prefer "malloc" because it unasks the question of which type to use in an array or union to ensure the "proper" alignment. Using any of "long" or "long long" is likely good enough, but could prove more fragile as the code evolves. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From erik at efca.com Tue Feb 20 19:06:43 2018 From: erik at efca.com (Erik Forsberg) Date: Tue, 20 Feb 2018 11:06:43 -0800 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <0283f58e-d834-d250-ae95-414793523caf@blastwave.org> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <0283f58e-d834-d250-ae95-414793523caf@blastwave.org> Message-ID: >-- Original Message -- > >On 20/02/18 12:47 PM, Norm Green wrote: >> On 2/20/2018 5:43 AM, Michael Wojcik wrote: >>> Not by default. The comments in /usr/include/sys/feature_tests.h (on a >>> Solaris system) explain this in excruciating detail, but in short you >>> need either -DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or the >>> equivalent in the code) to compile with XPG6 (aka IEEE 1003.1-2001). >> Thanks for the suggestions Michael.? Neither resolves the problem. In >> fact, adding -D_XOPEN_SOURCE=600 causes a new problem: >> >> /opt/solarisstudio12.3/bin/c99? -I. -Icrypto/include -Iinclude -m64 >> -xtarget=ultra2 -D_XOPEN_SOURCE=600 -xstrconst -Xa -DB_ENDIAN -DBN_DIV2W >> -KPIC -xildoff -mt -xcode=pic32 -g -DDSO_DLFCN -DHAVE_DLFCN_H >> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ >> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM >> -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM >> -DPOLY1305_ASM -DFILIO_H -DB_ENDIAN -DBN_DIV2W -D_REENTRANT >> -DOPENSSLDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/ssl\"" >> -DENGINESDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/lib/engines-1.1\"" >> -c -o crypto/bio/b_addr.o crypto/bio/b_addr.c >> "crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXHOST >> "crypto/bio/b_addr.c", line 198: variable length array can not be >> initialized: host >> "crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXSERV >> "crypto/bio/b_addr.c", line 198: variable length array can not be >> initialized: serv >> c99: acomp failed for crypto/bio/b_addr.c >> Makefile:881: recipe for target 'crypto/bio/b_addr.o' failed >> >> >> I also tried building with c99 instead of cc, without success. >> > I build my Solaris OpenSSL binaries using studo compiler 12.4 cc -xc99 Havent tried latest 1.1.1 snapshot yet though, probably a good time From dclarke at blastwave.org Tue Feb 20 19:20:19 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 20 Feb 2018 14:20:19 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <0283f58e-d834-d250-ae95-414793523caf@blastwave.org> Message-ID: <2d6527f2-ecf9-80ab-06bb-5d84da7300a1@blastwave.org> On 20/02/18 02:06 PM, Erik Forsberg wrote: > >> -- Original Message -- >> >> On 20/02/18 12:47 PM, Norm Green wrote: >>> On 2/20/2018 5:43 AM, Michael Wojcik wrote: <... snippage ...> >>> >>> I also tried building with c99 instead of cc, without success. >>> >> > > I build my Solaris OpenSSL binaries using studo compiler 12.4 cc -xc99 > Havent tried latest 1.1.1 snapshot yet though, probably a good time > working on it now .. gimme a few coffee cups to dig into this. Dennis From dclarke at blastwave.org Tue Feb 20 19:44:18 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 20 Feb 2018 14:44:18 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <87778fae-27da-e5f5-fe3a-3a37ee0d2280@gemtalksystems.com> <6d71ad48-5754-f942-ae33-2dc606083371@gemtalksystems.com> <0283f58e-d834-d250-ae95-414793523caf@blastwave.org> <12c1260d-e354-41fd-51db-d7b94dc2af7d@gemtalksystems.com> Message-ID: <67564e1d-9265-def1-ff1e-e37233c0dab7@blastwave.org> On 20/02/18 01:52 PM, Salz, Rich via openssl-users wrote: > >> So ... this will be fun. > > :) > > Thanks for poking at this, folks. Please take a look at the INSTALL and README files which do cover some of this prerequisites. And then once you've "fixed" it, let us know what we need to change!! > fixed? .. well .. hacked at for sure. getting there .. hitting little snags as I go : /opt/developerstudio12.6/bin/c99 -I. -Icrypto/include -Iinclude -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -Qy -xs -g -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=sparc64viiplus -xarch=sparcima -xchip=sparc64viiplus -xcache=64/64/2:11264/256/11 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -KPIC -DDSO_DLFCN -DHAVE_DLFCN_H -DZLIB -DNDEBUG -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -c -o crypto/sparcv9cap.o crypto/sparcv9cap.c "crypto/sparcv9cap.c", line 132: warning: no explicit type given "crypto/sparcv9cap.c", line 132: error: syntax error before or at: common_jmp "crypto/sparcv9cap.c", line 132: warning: old-style declaration or incorrect type for: common_jmp "crypto/sparcv9cap.c", line 135: warning: implicit function declaration: siglongjmp "crypto/sparcv9cap.c", line 214: warning: implicit function declaration: sigfillset "crypto/sparcv9cap.c", line 215: warning: implicit function declaration: sigdelset "crypto/sparcv9cap.c", line 223: warning: implicit function declaration: sigprocmask "crypto/sparcv9cap.c", line 229: warning: implicit function declaration: sigaction "crypto/sparcv9cap.c", line 233: warning: implicit function declaration: sigsetjmp c99: acomp failed for crypto/sparcv9cap.c gmake[1]: *** [Makefile:6253: crypto/sparcv9cap.o] Error 2 gmake[1]: Leaving directory '/usr/local/build/openssl-1.1.1-pre1_SunOS5.10_sparcv9.001' gmake: *** [Makefile:143: all] Error 2 corv $ yep . Dennis From adanaila at ctrlinux.com Wed Feb 21 01:19:25 2018 From: adanaila at ctrlinux.com (Andrei Danaila) Date: Tue, 20 Feb 2018 17:19:25 -0800 Subject: [openssl-users] OpenSSL Version Definitions Issue on ARM Message-ID: <1519175965.2280264.1277786192.47B8C274@webmail.messagingengine.com> Hi, I am attempting to crosscompile openssl for ARM and am having some issues when linking an external application to the crosscompiled OpenSSL version. I am compiling OpenSSL like so: ./Configure linux-generic32 shared \ --prefix=/openssl_libs \ --openssldir=/openssl_libs \ --cross-compile-prefix=/usr/local/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- make depend make -j8 make install What I am finding however is that there is no version definitions in the generated .so. This causes any other application that I link against the generated .so, to expect the exact same version as the .so, in this case lib.so.1.0.0. objdump --private-headers libssl.so.1.0.0 [...snip...] Version References: required from libc.so.6: 0x0d696914 0x00 02 GLIBC_2.4 Whereas, if I look on the OpenSSL library which ships on my ubuntu box, I see: Version definitions: 1 0x01 0x09bbb660 libssl.so.1.0.0 2 0x00 0x066a2b20 OPENSSL_1.0.0 3 0x00 0x066a2b21 OPENSSL_1.0.1 OPENSSL_1.0.0 4 0x00 0x06a2b214 OPENSSL_1.0.1d OPENSSL_1.0.1 5 0x00 0x066a2b22 OPENSSL_1.0.2 OPENSSL_1.0.1d 6 0x00 0x06a2b2e7 OPENSSL_1.0.2g OPENSSL_1.0.2 Version References: required from libc.so.6: 0x06969194 0x00 14 GLIBC_2.14 0x0d696914 0x00 13 GLIBC_2.4 0x09691974 0x00 11 GLIBC_2.3.4 0x09691a75 0x00 09 GLIBC_2.2.5 required from libcrypto.so.1.0.0: 0x06a2b214 0x00 12 OPENSSL_1.0.1d 0x066a2b21 0x00 10 OPENSSL_1.0.1 0x066a2b22 0x00 08 OPENSSL_1.0.2 0x066a2b20 0x00 07 OPENSSL_1.0.0 Any insight would be greatly appreciated. From dclarke at blastwave.org Wed Feb 21 02:17:32 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 20 Feb 2018 21:17:32 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <12c1260d-e354-41fd-51db-d7b94dc2af7d@gemtalksystems.com> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <87778fae-27da-e5f5-fe3a-3a37ee0d2280@gemtalksystems.com> <6d71ad48-5754-f942-ae33-2dc606083371@gemtalksystems.com> <0283f58e-d834-d250-ae95-414793523caf@blastwave.org> <12c1260d-e354-41fd-51db-d7b94dc2af7d@gemtalksystems.com> Message-ID: <6088d4cb-7566-c216-1e28-0892641cd64e@blastwave.org> On 20/02/18 01:36 PM, Norm Green wrote: > Hi Dennis, > > You're right, I did modify the config file... I have managed to get to the link stage here and ran into some odd syntax issue. Have to dig around and see what LDCMD was intended to be. ${LDCMD:-/opt/developerstudio12.6/bin/cc} -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -Qy -xs -g -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=sparc64viiplus -xarch=sparcima -xchip=sparc64viiplus -xcache=64/64/2:11264/256/11 -D_TS_ERRNO -D__EXTENSIONS__ -D_POSIX_C_SOURCE -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -L. -mt \ -o apps/openssl apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o apps/s_client.o apps/s_server.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/storeutl.o apps/ts.o apps/verify.o apps/version.o apps/x509.o \ apps/libapps.a -lssl -lcrypto -lz -lsocket -lnsl -ldl -lpthread Undefined first referenced symbol in file OPENSSL_LH_stats_bio apps/asn1pars.o SSL_stateless apps/s_server.o BN_GENCB_free apps/dhparam.o SSL_CTX_set_ctlog_list_file apps/libapps.a(apps.o) TLS_client_method apps/ocsp.o SSL_SESSION_get0_cipher apps/s_client.o OPENSSL_strlcpy apps/ca.o OPENSSL_strlcat apps/ca.o OPENSSL_sk_pop_free apps/asn1pars.o SSL_CTX_set_options apps/s_time.o BN_is_zero apps/ca.o BIO_ADDRINFO_free apps/libapps.a(s_socket.o) BIO_ADDRINFO_next apps/libapps.a(s_socket.o) SSL_is_dtls apps/libapps.a(s_cb.o) BIO_sock_info apps/s_client.o OpenSSL_version apps/speed.o PKCS12_SAFEBAG_get0_attrs apps/pkcs12.o PKCS12_SAFEBAG_get_nid apps/pkcs12.o PKCS12_SAFEBAG_get0_safes apps/pkcs12.o PKCS12_SAFEBAG_get0_p8inf apps/pkcs12.o PKCS12_SAFEBAG_get0_pkcs8 apps/pkcs12.o SSL_get0_dane_authority apps/libapps.a(s_cb.o) PEM_write_bio_PrivateKey_traditional apps/pkcs8.o CRYPTO_clear_free apps/dgst.o SSL_CTX_set_default_read_buffer_len apps/s_client.o SSL_write_early_data apps/s_client.o RSA_check_key_ex apps/rsa.o SSL_get1_supported_ciphers apps/ciphers.o SSL_SESSION_get_max_early_data apps/s_client.o EVP_PKEY_meth_get0 apps/openssl.o X509_STORE_CTX_set0_trusted_stack apps/verify.o PKCS12_SAFEBAG_get0_attr apps/pkcs12.o PKCS12_SAFEBAG_get0_type apps/pkcs12.o PKCS12_SAFEBAG_get1_cert apps/pkcs12.o ASN1_TIME_set_string_X509 apps/ca.o OPENSSL_sk_dup apps/asn1pars.o OPENSSL_sk_pop apps/asn1pars.o OPENSSL_sk_num apps/asn1pars.o OPENSSL_sk_new apps/asn1pars.o OPENSSL_sk_set apps/asn1pars.o EVP_PKEY_meth_get_count apps/openssl.o BIO_ADDRINFO_protocol apps/libapps.a(s_socket.o) SCT_validation_status_string apps/s_client.o SSL_ct_is_enabled apps/s_client.o IDEA_options apps/speed.o IDEA_set_encrypt_key apps/speed.o PKCS8_pkey_get0_attrs apps/pkcs12.o RSA_generate_multi_prime_key apps/genrsa.o X509_STORE_CTX_get_obj_by_subject apps/crl.o X509_CRL_get0_nextUpdate apps/crl.o X509_CRL_get0_lastUpdate apps/crl.o ASN1_ITEM_lookup apps/asn1pars.o SSL_get0_peer_CA_list apps/libapps.a(s_cb.o) X509_CRL_set1_nextUpdate apps/ca.o X509_CRL_set1_lastUpdate apps/ca.o SSL_CTX_dane_enable apps/s_client.o SSL_CTX_set_default_ctlog_list_file apps/libapps.a(apps.o) SSL_CTX_set_keylog_callback apps/libapps.a(s_cb.o) X509_CRL_get0_signature apps/crl.o PKCS8_set0_pbe apps/pkcs8.o EVP_MD_CTX_new apps/ocsp.o PKCS12_get0_mac apps/pkcs12.o SSL_set_options apps/s_client.o ASYNC_WAIT_CTX_free apps/speed.o SSL_get_options apps/s_server.o OPENSSL_sk_free apps/asn1pars.o OPENSSL_sk_find apps/asn1pars.o OPENSSL_sk_push apps/asn1pars.o OPENSSL_sk_sort apps/asn1pars.o OPENSSL_sk_zero apps/asn1pars.o PKCS12_mac_present apps/pkcs12.o OPENSSL_LH_get_down_load apps/asn1pars.o BIO_lookup_ex apps/libapps.a(s_socket.o) HMAC_CTX_free apps/speed.o OCSP_basic_sign_ctx apps/ocsp.o OPENSSL_sk_is_sorted apps/asn1pars.o TS_RESP_CTX_set_signer_digest apps/ts.o OPENSSL_sk_shift apps/asn1pars.o OPENSSL_sk_value apps/asn1pars.o SSL_has_pending apps/s_client.o OSSL_STORE_LOADER_get0_engine apps/engine.o X509_get0_extensions apps/ca.o EVP_PKEY_param_check apps/pkeyparam.o BIO_meth_set_callback_ctrl apps/libapps.a(bf_prefix.o) SSL_get0_peer_scts apps/s_client.o SSL_CTX_set_max_early_data apps/s_server.o SSL_CTX_set_default_verify_dir apps/libapps.a(apps.o) TS_VERIFY_CTX_set_data apps/ts.o BN_GENCB_set apps/dhparam.o BN_GENCB_new apps/dhparam.o TS_VERIFY_CTX_set_imprint apps/ts.o BN_is_odd apps/s_client.o OSSL_STORE_LOADER_get0_scheme apps/engine.o X509_get_X509_PUBKEY apps/x509.o BIO_listen apps/libapps.a(s_socket.o) EVP_PKEY_check apps/pkey.o X509_SIG_get0 apps/pkcs12.o SSL_get0_peername apps/libapps.a(s_cb.o) BN_GENCB_get_arg apps/dhparam.o BIO_socket apps/libapps.a(s_socket.o) ASYNC_start_job apps/speed.o PKCS5_pbe2_set_scrypt apps/pkcs8.o OPENSSL_uni2utf8 apps/pkcs12.o SSL_CTX_get0_ctlog_store apps/s_client.o ASYNC_WAIT_CTX_get_all_fds apps/speed.o OSSL_STORE_INFO_free apps/storeutl.o X509_OBJECT_free apps/crl.o SSL_dane_enable apps/s_client.o BIO_ADDR_rawaddress apps/libapps.a(s_cb.o) SCRYPT_PARAMS_it apps/pkcs12.o OPENSSL_die apps/ocsp.o OSSL_STORE_INFO_get0_CERT apps/storeutl.o OSSL_STORE_INFO_get0_NAME apps/storeutl.o OSSL_STORE_INFO_get0_PKEY apps/storeutl.o ASYNC_WAIT_CTX_new apps/speed.o SSL_is_init_finished apps/s_client.o OpenSSL_version_num apps/version.o OPENSSL_init_ssl apps/errstr.o OPENSSL_hexchar2int apps/enc.o OPENSSL_LH_set_down_load apps/asn1pars.o OPENSSL_LH_new apps/asn1pars.o BIO_meth_new apps/libapps.a(bf_prefix.o) EVP_PKEY_get0_RSA apps/req.o EVP_PKEY_get0_DSA apps/x509.o DSA_set0_pqg apps/speed.o DSA_get0_pqg apps/dsaparam.o DSA_get0_key apps/dsa.o DSA_set0_key apps/speed.o DH_bits apps/dhparam.o OPENSSL_sk_delete_ptr apps/asn1pars.o BIO_read_ex apps/s_client.o RSA_get0_key apps/genrsa.o BIO_set_init apps/libapps.a(bf_prefix.o) BIO_get_data apps/libapps.a(bf_prefix.o) BIO_set_data apps/libapps.a(bf_prefix.o) OSSL_STORE_error apps/storeutl.o OSSL_STORE_close apps/storeutl.o X509_REQ_get0_pubkey apps/ca.o X509_get0_pubkey apps/ca.o OPENSSL_sk_unshift apps/asn1pars.o EVP_PKEY_public_check apps/pkey.o SSL_dane_tlsa_add apps/s_client.o OSSL_STORE_do_all_loaders apps/engine.o OPENSSL_LH_strhash apps/openssl.o OPENSSL_hexstr2buf apps/cms.o SSL_SESSION_up_ref apps/s_client.o BIO_closesocket apps/s_client.o BIO_meth_set_create apps/libapps.a(bf_prefix.o) SSL_CTX_set0_CA_list apps/s_client.o UI_null apps/libapps.a(apps.o) SSL_CIPHER_standard_name apps/ciphers.o ASN1_STRING_get0_data apps/ca.o BIO_connect apps/s_server.o OPENSSL_LH_retrieve apps/asn1pars.o BIO_ADDRINFO_family apps/libapps.a(s_socket.o) SSL_verify_client_post_handshake apps/s_server.o X509_STORE_set_lookup_crls apps/libapps.a(apps.o) BIO_parse_hostserv apps/s_client.o SCT_print apps/s_client.o OPENSSL_cipher_name apps/ciphers.o SSL_waiting_for_async apps/s_server.o X509_VERIFY_PARAM_set_auth_level apps/libapps.a(opt.o) SSL_get_all_async_fds apps/libapps.a(apps.o) OPENSSL_sk_new_null apps/asn1pars.o OPENSSL_LH_free apps/asn1pars.o OPENSSL_sk_set_cmp_func apps/asn1pars.o ASYNC_is_capable apps/speed.o SSL_get_early_data_status apps/s_client.o SSL_SESSION_set_protocol_version apps/s_client.o X509_CRL_print_ex apps/crl.o OPENSSL_LH_node_stats_bio apps/asn1pars.o SSL_dane_set_flags apps/s_client.o OPENSSL_sk_reserve apps/asn1pars.o TS_CONF_set_ess_cert_id_digest apps/ts.o BIO_ADDR_rawport apps/libapps.a(s_cb.o) SSL_CTX_set_default_verify_file apps/libapps.a(apps.o) SSL_CTX_set_not_resumable_session_callback apps/s_server.o OPENSSL_LH_num_items apps/asn1pars.o OPENSSL_sk_new_reserve apps/asn1pars.o DH_get0_pqg apps/dhparam.o BIO_meth_free apps/libapps.a(apps.o) OPENSSL_LH_node_usage_stats_bio apps/asn1pars.o HMAC_CTX_new apps/speed.o X509_STORE_CTX_get_num_untrusted apps/verify.o OSSL_STORE_INFO_get0_NAME_description apps/storeutl.o BIO_meth_set_read_ex apps/libapps.a(bf_prefix.o) X509_CRL_get_issuer apps/crl.o RSA_pkey_ctx_ctrl apps/req.o TS_VERIFY_CTX_set_store apps/ts.o BIO_ADDRINFO_socktype apps/libapps.a(s_socket.o) SSL_read_early_data apps/s_server.o SSL_CTX_set_psk_find_session_callback apps/s_server.o OSSL_STORE_eof apps/storeutl.o TS_VERIFY_CTS_set_certs apps/ts.o BIO_meth_set_write_ex apps/libapps.a(bf_prefix.o) TS_VERIFY_CTX_add_flags apps/ts.o ASYNC_cleanup_thread apps/speed.o BIO_ADDR_new apps/s_client.o IDEA_cbc_encrypt apps/speed.o TS_STATUS_INFO_set_status apps/ts.o SSL_SESSION_set1_master_key apps/s_client.o X509_OBJECT_get0_X509 apps/crl.o OSSL_STORE_INFO_type_string apps/storeutl.o BIO_write_ex apps/libapps.a(bf_prefix.o) SSL_get0_dane_tlsa apps/libapps.a(s_cb.o) OSSL_STORE_INFO_get_type apps/storeutl.o SSL_SESSION_print_keylog apps/sess_id.o CRYPTO_set_mem_debug apps/openssl.o OSSL_STORE_INFO_get0_CRL apps/storeutl.o SSL_CTX_get_security_callback apps/libapps.a(s_cb.o) SSL_CTX_set_security_callback apps/libapps.a(s_cb.o) OPENSSL_sk_delete apps/asn1pars.o OPENSSL_LH_delete apps/asn1pars.o SSL_CTX_set_tlsext_max_fragment_length apps/s_client.o TLS_server_method apps/ciphers.o OCSP_resp_get0_signature apps/ocsp.o DTLSv1_listen apps/s_server.o SSL_force_post_handshake_auth apps/s_client.o SSL_CTX_config apps/s_client.o OPENSSL_LH_insert apps/asn1pars.o OPENSSL_sk_insert apps/asn1pars.o SSL_SESSION_set_cipher apps/s_client.o X509_REQ_get_subject_name apps/ca.o PKCS12_SAFEBAG_get_bag_nid apps/pkcs12.o OPENSSL_sk_deep_copy apps/asn1pars.o ASN1_ITEM_get apps/asn1pars.o CRYPTO_memdup apps/s_server.o SSL_get_key_update_type apps/s_client.o SSL_CTX_set_psk_use_session_callback apps/s_client.o OSSL_STORE_open apps/storeutl.o OSSL_STORE_load apps/storeutl.o DH_get_length apps/dhparam.o SSL_CIPHER_get_handshake_digest apps/s_client.o SSL_key_update apps/s_client.o X509_getm_notAfter apps/libapps.a(apps.o) BIO_meth_set_destroy apps/libapps.a(bf_prefix.o) X509_get0_notAfter apps/ca.o BIO_accept_ex apps/libapps.a(s_socket.o) BIO_meth_set_gets apps/libapps.a(bf_prefix.o) BIO_meth_set_ctrl apps/libapps.a(bf_prefix.o) BIO_meth_set_puts apps/libapps.a(bf_prefix.o) BIO_ADDRINFO_address apps/libapps.a(s_socket.o) SSL_CTX_enable_ct apps/s_client.o CRYPTO_zalloc apps/passwd.o X509_get0_notBefore apps/x509.o OSSL_STORE_INFO_get0_PARAMS apps/storeutl.o BIO_ADDR_free apps/s_client.o EVP_MD_CTX_free apps/ocsp.o OPENSSL_sk_find_ex apps/asn1pars.o TS_CONF_set_signer_digest apps/ts.o SSL_session_reused apps/s_client.o ASYNC_init_thread apps/speed.o X509_getm_notBefore apps/libapps.a(apps.o) SCRYPT_PARAMS_free apps/pkcs12.o OPENSSL_LH_doall apps/asn1pars.o SSL_get_peer_signature_type_nid apps/libapps.a(s_cb.o) OPENSSL_LH_error apps/asn1pars.o SSL_CTX_set0_security_ex_data apps/libapps.a(s_cb.o) ld: fatal: symbol referencing errors. No output written to apps/openssl gmake[1]: *** [Makefile:7936: apps/openssl] Error 2 gmake[1]: Leaving directory '/usr/local/build/openssl-1.1.1-pre1_SunOS5.10_sparcv9.001' gmake: *** [Makefile:143: all] Error 2 corv $ Making progress here however. Dennis From rsalz at akamai.com Wed Feb 21 03:21:50 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 21 Feb 2018 03:21:50 +0000 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> Message-ID: https://github.com/openssl/openssl/pull/5423 ?On 2/20/18, 2:10 PM, "Salz, Rich via openssl-users" wrote: I agree, let's just use malloc for the reasons you said. PR later today. On 2/20/18, 2:08 PM, "Viktor Dukhovni" wrote: > On Feb 20, 2018, at 11:36 AM, Norm Green wrote: > > Your patch tests clean, however there is an easier way which avoids malloc: Great, so it was the unaligned "buf". Great. As for malloc vs. tricks to align the stack-based array, I see little need to avoid malloc() this is a test function, not a performance-critical library function. Exercising OPENSSL_malloc() is arguably a feature. :-) That said, I have no religion on which approach is taken to align "buf". I prefer "malloc" because it unasks the question of which type to use in an array or union to ensure the "proper" alignment. Using any of "long" or "long long" is likely good enough, but could prove more fragile as the code evolves. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From openssl-users at dukhovni.org Wed Feb 21 04:28:03 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 20 Feb 2018 23:28:03 -0500 Subject: [openssl-users] Loading CA from memory In-Reply-To: References: <5b27fe5e-e2b9-c6fa-391f-75c4ffcdb5d8@wisemo.com> Message-ID: <0602E968-8254-41B5-8232-2D88F9B7B147@dukhovni.org> > On Feb 20, 2018, at 12:58 PM, Devchandra L Meetei wrote: > > By the way, Is there any plan to port SSL_CTX_load_verify_mem to openssl? The basic functionality is already there: If you want to parse in-memory PEM, see the use of PEM_X509_INFO_read_bio() [needs documentation] at: https://github.com/openssl/openssl/blob/master/apps/crl2p7.c#L179 if have a PKCS7 DER or PEM structure, there are suitable functions for pulling out a chain from that. Then you can set a "trusted stack" for your X509_STORE_CTX. -- Viktor. From dlmeetei at gmail.com Wed Feb 21 04:54:50 2018 From: dlmeetei at gmail.com (Devchandra L Meetei) Date: Wed, 21 Feb 2018 10:24:50 +0530 Subject: [openssl-users] Loading CA from memory In-Reply-To: <0602E968-8254-41B5-8232-2D88F9B7B147@dukhovni.org> References: <5b27fe5e-e2b9-c6fa-391f-75c4ffcdb5d8@wisemo.com> <0602E968-8254-41B5-8232-2D88F9B7B147@dukhovni.org> Message-ID: Thanks Viktor As usual, Your answer throws light. Now, it is time to get started. Will revert if got obstructed on the way On Wed, Feb 21, 2018 at 9:58 AM, Viktor Dukhovni wrote: > > > > On Feb 20, 2018, at 12:58 PM, Devchandra L Meetei > wrote: > > > > By the way, Is there any plan to port SSL_CTX_load_verify_mem to openssl? > > The basic functionality is already there: > > If you want to parse in-memory PEM, see the use of > PEM_X509_INFO_read_bio() [needs documentation] at: > > https://github.com/openssl/openssl/blob/master/apps/crl2p7.c#L179 > > if have a PKCS7 DER or PEM structure, there are suitable functions for > pulling > out a chain from that. Then you can set a "trusted stack" for your > X509_STORE_CTX. > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Warm Regards --Dev OpenPegasus Developer "I'm one of those people that think Thomas Edison and the light bulb changed the world more than Karl Marx ever did,? Steve Jobs -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Feb 21 06:58:21 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 21 Feb 2018 07:58:21 +0100 (CET) Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <6088d4cb-7566-c216-1e28-0892641cd64e@blastwave.org> References: <12c1260d-e354-41fd-51db-d7b94dc2af7d@gemtalksystems.com> <6088d4cb-7566-c216-1e28-0892641cd64e@blastwave.org> Message-ID: <20180221.075821.990851754505278989.levitte@openssl.org> In message <6088d4cb-7566-c216-1e28-0892641cd64e at blastwave.org> on Tue, 20 Feb 2018 21:17:32 -0500, Dennis Clarke said: dclarke> Have to dig around and see what LDCMD was intended to be. LDCMD is a convenience variable for some users to specify a different command than the configured C compiler for linking programs. So unless you define it specifically, it will remain undefined. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Wed Feb 21 09:38:59 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 21 Feb 2018 09:38:59 +0000 Subject: [openssl-users] OpenSSL Version Definitions Issue on ARM In-Reply-To: <1519175965.2280264.1277786192.47B8C274@webmail.messagingengine.com> References: <1519175965.2280264.1277786192.47B8C274@webmail.messagingengine.com> Message-ID: <30c9cfd4-1dc3-ae3b-6399-43d4b35da633@openssl.org> On 21/02/18 01:19, Andrei Danaila wrote: > Any insight would be greatly appreciated. > All OpenSSL versions before 1.1.0 provide no symbol version information. However Debian distribute a patched version of OpenSSL that adds this - so this is why you will see a difference between your system supplied OpenSSL and the downloaded OpenSSL in this respect. >From OpenSSL 1.1.0 onwards we do provide symbol versions on platforms where we support that capability (e.g. Linux). Matt From appro at openssl.org Wed Feb 21 09:57:43 2018 From: appro at openssl.org (Andy Polyakov) Date: Wed, 21 Feb 2018 10:57:43 +0100 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <407358b3-adc3-69b9-1393-200e11f64349@blastwave.org> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <87778fae-27da-e5f5-fe3a-3a37ee0d2280@gemtalksystems.com> <6d71ad48-5754-f942-ae33-2dc606083371@gemtalksystems.com> <0283f58e-d834-d250-ae95-414793523caf@blastwave.org> <407358b3-adc3-69b9-1393-200e11f64349@blastwave.org> Message-ID: <4924de48-fbcc-aded-79f5-4113600df98e@openssl.org> > Interesting comment : > > > #### Solaris x86 with Sun C setups > ??? # There used to be solaris-x86-cc target, but it was removed, > ??? # primarily because vendor assembler can't assemble our modules > ??? # with -KPIC flag. As result it, assembly support, was not even > ??? # available as option. But its lack means lack of side-channel > ??? # resistant code, which is incompatible with security by todays > ??? # standards. Fortunately gcc is readily available prepackaged > ??? # option, which we can firmly point at... > ??? # > ??? # On related note, solaris64-x86_64-cc target won't compile code > ??? # paths utilizing AVX and post-Haswell instruction extensions. > ??? # Consider switching to solaris64-x86_64-gcc even here... > ??? # > > > Pre-packaged? Really ... Nowadays you just pkgadd it from some common Oracle repository. Well, at least on x86, as I have no idea if SPARC Solaris offers it. But the comment is explicitly about x86. > let's not go down the route of argument today. > > > ??? "solaris64-sparcv9-cc" => { > ??????? inherit_from???? => [ "solaris-sparcv7-cc", asm("sparcv9_asm") ], > ??????? cflags?????????? => add_before("-xarch=v9"), > ??????? bn_ops?????????? => "BN_LLONG RC4_CHAR", > ??????? multilib???????? => "/64", > ??? }, > > > Actually xarch=v9 is wrong.? Should just say "sparc". So assertion is that compiler recognizes option -sparc? Don't see anything of the sort in the manual page. Well, I can see that contemporary compiler would recognize -xarch=sparc, but that's *contemporary* version. But more importantly manual also says that -xarch=v9 is equivalent to -m64 -xarch=sparc and -m64 is the essence of this configuration. So -xarch=v9 is right, because it generates 64-bit code and works with all compiler versions. [Well, one can probably argue that it's time to reconsider meaning of "all compiler versions" in the context, yet it wouldn't make "just say "sparc"" right :-)] From appro at openssl.org Wed Feb 21 10:06:37 2018 From: appro at openssl.org (Andy Polyakov) Date: Wed, 21 Feb 2018 11:06:37 +0100 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> Message-ID: > https://github.com/openssl/openssl/pull/5423 I wonder how come the problem with asn1_encode_test.c went unnoticed so far. Objects on stack are customarily aligned at pointer size, even if their declaration doesn't imply corresponding guarantee. So there are two options here: a) it's first time it's tested with SPARC Solaris cc (note that it is regularly tested on SPARC Linux, naturally with gcc); b) compiler was recently patched/upgraded. Do note that I don't dispute suggested fix (or compiler's "right" to misalign buf in this case), only wonder how come it worked so far. Implied question would be what are other possible implications of b). From rsalz at akamai.com Wed Feb 21 14:12:25 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 21 Feb 2018 14:12:25 +0000 Subject: [openssl-users] Windows 1.1.1 binaries and web server In-Reply-To: References: Message-ID: <16DBF3DC-4983-47CA-BF45-D224068D1985@akamai.com> This is very useful! Can you post an udate to the wiki? https://wiki.openssl.org/index.php/Binaries ?On 2/21/18, 8:57 AM, "Angus Robertson - Magenta Systems Ltd" wrote: Windows developers may be interested in our Win32 build of OpenSSL 1.1.1-pre1 (alpha), the binaries are digitally code signed 'Open Source Developer, Fran?ois PIETTE', the lead developer for the Delphi Internet Component Suite project. About half way down the page at: http://wiki.overbyte.eu/wiki/index.php/ICS_Download The latest 1.0.2 and 1.1.0 are also available, digitally code signed. I have also built my Windows ICS web application server to use 1.1.1-pre1 (alpha) so it can be used for testing TLSv1.3, the information page shows the protocol you connect with, the ciphers available and the OpenSSL and draft version being used. Currently most browsers still connect with TLSv1.2. https://www2.telecom-tariffs.co.uk/serverinfo.htm Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From openssl-users at dukhovni.org Wed Feb 21 14:14:48 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 21 Feb 2018 09:14:48 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> Message-ID: <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> > On Feb 21, 2018, at 5:06 AM, Andy Polyakov wrote: > > I wonder how come the problem with asn1_encode_test.c went unnoticed so > far. Objects on stack are customarily aligned at pointer size, even if > their declaration doesn't imply corresponding guarantee. So there are > two options here: a) it's first time it's tested with SPARC Solaris cc > (note that it is regularly tested on SPARC Linux, naturally with gcc); > b) compiler was recently patched/upgraded. Do note that I don't dispute > suggested fix (or compiler's "right" to misalign buf in this case), only > wonder how come it worked so far. Implied question would be what are > other possible implications of b). The code introduced the misaligned "bug" is master-only, added in Apr/2017, so quite possibly nobody has ever built in SunOS+SPARC, in which case it never worked, but simply was never tested until now. -- Viktor. From robert at gillecaluim.com Wed Feb 21 16:16:05 2018 From: robert at gillecaluim.com (Robert Watson) Date: Wed, 21 Feb 2018 08:16:05 -0800 Subject: [openssl-users] compilation error with openssl-1.1.0 and DH_get0_key Message-ID: I'm trying to update a crypto library for crtmpserver to work with openssl 1.1.0. The software is no longer actively maintained and my c++ skills are somewhat rudimentary but I keep getting a compilation error for something that seems trivial. Here's the code snippet: bool DHWrapper::CopyPublicKey(uint8_t *pDst, int32_t dstLength) { if (_pDH == NULL) { FATAL("DHWrapper not initialized"); return false; } BIGNUM *_keyPublic,*_keyPrivate; _keyPublic = BN_new(); _keyPrivate = BN_new(); DH_get0_key( _pDH, *_keyPublic, *_keyPrivate ); CopyKey(_keyPublic, pDst, dstLength); return true; } Here's the compilation error: /build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp: In member function ?bool DHWrapper::CopyPublicKey(uint8_t*, int32_t)?: /build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp:92:47: error: cannot convert ?BIGNUM {aka bignum_st}? to ?const BIGNUM** {aka const bignum_st**}? for argument ?2? to ?void DH_get0_key(const DH*, const BIGNUM**, const BIGNUM**)? DH_get0_key( _pDH, *_keyPublic, *_keyPrivate ); ^ make[2]: *** [common/CMakeFiles/common.dir/build.make:591: common/CMakeFiles/common.dir/build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:231: common/CMakeFiles/common.dir/all] Error 2 make: *** [Makefile:130: all] Error 2 What am I doing wrong? Thanks, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Wed Feb 21 16:20:54 2018 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 21 Feb 2018 10:20:54 -0600 Subject: [openssl-users] compilation error with openssl-1.1.0 and DH_get0_key In-Reply-To: References: Message-ID: On 02/21/2018 10:16 AM, Robert Watson wrote: > I'm trying to update a crypto library for crtmpserver to work with > openssl 1.1.0.? The software is no longer actively maintained and my > c++ skills are somewhat rudimentary but I keep getting a compilation > error for something that seems trivial. > > Here's the code snippet: > bool DHWrapper::CopyPublicKey(uint8_t *pDst, int32_t dstLength) { > ??? if (_pDH == NULL) { > ??? ??? FATAL("DHWrapper not initialized"); > ??? ??? return false; > ??? } > ??? BIGNUM *_keyPublic,*_keyPrivate; > ??? _keyPublic = BN_new(); > ??? _keyPrivate = BN_new(); > ??? DH_get0_key( _pDH, *_keyPublic, *_keyPrivate ); Use '&' instead of '*' -Ben > ??? CopyKey(_keyPublic, pDst, dstLength); > ??? return true; > } > > Here's the compilation error: > /build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp: > In member function ?bool DHWrapper::CopyPublicKey(uint8_t*, int32_t)?: > /build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp:92:47: > error: cannot convert ?BIGNUM {aka bignum_st}? to ?const BIGNUM** {aka > const bignum_st**}? for argument ?2? to ?void DH_get0_key(const DH*, > const BIGNUM**, const BIGNUM**)? > ? DH_get0_key( _pDH, *_keyPublic, *_keyPrivate ); > ?????????????????????????????????????????????? ^ > make[2]: *** [common/CMakeFiles/common.dir/build.make:591: > common/CMakeFiles/common.dir/build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp.o] > Error 1 > make[1]: *** [CMakeFiles/Makefile2:231: > common/CMakeFiles/common.dir/all] Error 2 > make: *** [Makefile:130: all] Error 2 > > What am I doing wrong? Thanks, > Robert > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Feb 21 16:24:11 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 21 Feb 2018 16:24:11 +0000 Subject: [openssl-users] compilation error with openssl-1.1.0 and DH_get0_key In-Reply-To: References: Message-ID: <209baf2d-e699-5895-6ae0-c5d97c7bcb60@openssl.org> On 21/02/18 16:20, Benjamin Kaduk via openssl-users wrote: > On 02/21/2018 10:16 AM, Robert Watson wrote: >> I'm trying to update a crypto library for crtmpserver to work with >> openssl 1.1.0.? The software is no longer actively maintained and my >> c++ skills are somewhat rudimentary but I keep getting a compilation >> error for something that seems trivial. >> >> Here's the code snippet: >> bool DHWrapper::CopyPublicKey(uint8_t *pDst, int32_t dstLength) { >> ??? if (_pDH == NULL) { >> ??? ??? FATAL("DHWrapper not initialized"); >> ??? ??? return false; >> ??? } >> ??? BIGNUM *_keyPublic,*_keyPrivate; >> ??? _keyPublic = BN_new(); >> ??? _keyPrivate = BN_new(); >> ??? DH_get0_key( _pDH, *_keyPublic, *_keyPrivate ); > > Use '&' instead of '*' Yes, this is the problem. In addition to that though you have a memory leak. DH_get0_key() will overwrite the values pointed to by _keyPublic and_keyPrivate. So don't initialise them first with the BN_new() calls. Matt From dclarke at blastwave.org Wed Feb 21 16:42:53 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Wed, 21 Feb 2018 11:42:53 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> Message-ID: On 21/02/18 09:14 AM, Viktor Dukhovni wrote: > > >> On Feb 21, 2018, at 5:06 AM, Andy Polyakov wrote: >> >> I wonder how come the problem with asn1_encode_test.c went unnoticed so >> far. Objects on stack are customarily aligned at pointer size, even if >> their declaration doesn't imply corresponding guarantee. So there are >> two options here: a) it's first time it's tested with SPARC Solaris cc >> (note that it is regularly tested on SPARC Linux, naturally with gcc); >> b) compiler was recently patched/upgraded. Do note that I don't dispute >> suggested fix (or compiler's "right" to misalign buf in this case), only >> wonder how come it worked so far. Implied question would be what are >> other possible implications of b). > > The code introduced the misaligned "bug" is master-only, added in Apr/2017, > so quite possibly nobody has ever built in SunOS+SPARC, in which case it > never worked, but simply was never tested until now. > Pretty sure I have done builds and tests. In fact I am certain of it. Dennis From openssl-users at dukhovni.org Wed Feb 21 16:55:06 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 21 Feb 2018 11:55:06 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> Message-ID: <556A755B-5BDC-4666-93F8-A1A30EE591CF@dukhovni.org> > On Feb 21, 2018, at 11:42 AM, Dennis Clarke wrote: > > On 21/02/18 09:14 AM, Viktor Dukhovni wrote: >>> On Feb 21, 2018, at 5:06 AM, Andy Polyakov wrote: >>> >>> I wonder how come the problem with asn1_encode_test.c went unnoticed so >>> far. Objects on stack are customarily aligned at pointer size, even if >>> their declaration doesn't imply corresponding guarantee. So there are >>> two options here: a) it's first time it's tested with SPARC Solaris cc >>> (note that it is regularly tested on SPARC Linux, naturally with gcc); >>> b) compiler was recently patched/upgraded. Do note that I don't dispute >>> suggested fix (or compiler's "right" to misalign buf in this case), only >>> wonder how come it worked so far. Implied question would be what are >>> other possible implications of b). >> The code introduced the misaligned "bug" is master-only, added in Apr/2017, >> so quite possibly nobody has ever built in SunOS+SPARC, in which case it >> never worked, but simply was never tested until now. > > Pretty sure I have done builds and tests. In fact I am certain of it. Were you testing "master"? Or OpenSSL_1_1_0-stable? The alignment of "buf" is of course compiler-version dependent, and can also change from unrelated later changes in the surrounding code. In any case, the problem code is comparatively recent (less than a year old), and only users testing the master development branch on SPARC would have run into the issue. -- Viktor. From robert at gillecaluim.com Wed Feb 21 17:02:42 2018 From: robert at gillecaluim.com (Robert Watson) Date: Wed, 21 Feb 2018 09:02:42 -0800 Subject: [openssl-users] compilation error with openssl-1.1.0 and DH_get0_key In-Reply-To: References: Message-ID: Thanks for suggestion, don't understand why the compiler didn't complain about the first argument. Unfortunately, that just brings out other problem.... code: bool DHWrapper::CopyPublicKey(uint8_t *pDst, int32_t dstLength) { if (_pDH == NULL) { FATAL("DHWrapper not initialized"); return false; } BIGNUM *_keyPublic, *_keyPrivate; _keyPublic = BN_new(); _keyPrivate = BN_new(); DH_get0_key( _pDH, &_keyPublic, &_keyPrivate ); CopyKey(_keyPublic, pDst, dstLength); return true; } Still fails compilation with: /build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp: In member function ?bool DHWrapper::CopyPublicKey(uint8_t*, int32_t)?: /build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp:92:21: error: invalid conversion from ?BIGNUM** {aka bignum_st**}? to ?const BIGNUM** {aka const bignum_st**}? [-fpermissive] DH_get0_key( _pDH, &_keyPublic, &_keyPrivate ); ^~~~~~~~~~~ In file included from /build/crtmpserver/src/crtmpserver/sources/common/include/utils/misc/crypto.h:26:0, from /build/crtmpserver/src/crtmpserver/sources/common/include/utils/buffering/iobuffer.h:27, from /build/crtmpserver/src/crtmpserver/sources/common/include/utils/buffering/buffering.h:23, from /build/crtmpserver/src/crtmpserver/sources/common/include/utils/utils.h:23, from /build/crtmpserver/src/crtmpserver/sources/common/include/common.h:25: /usr/include/openssl/dh.h:183:6: note: initializing argument 2 of ?void DH_get0_key(const DH*, const BIGNUM**, const BIGNUM**)? void DH_get0_key(const DH *dh, ^~~~~~~~~~~ /build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp:92:34: error: invalid conversion from ?BIGNUM** {aka bignum_st**}? to ?const BIGNUM** {aka const bignum_st**}? [-fpermissive] DH_get0_key( _pDH, &_keyPublic, &_keyPrivate ); ^~~~~~~~~~~~ In file included from /build/crtmpserver/src/crtmpserver/sources/common/include/utils/misc/crypto.h:26:0, from /build/crtmpserver/src/crtmpserver/sources/common/include/utils/buffering/iobuffer.h:27, from /build/crtmpserver/src/crtmpserver/sources/common/include/utils/buffering/buffering.h:23, from /build/crtmpserver/src/crtmpserver/sources/common/include/utils/utils.h:23, from /build/crtmpserver/src/crtmpserver/sources/common/include/common.h:25: /usr/include/openssl/dh.h:183:6: note: initializing argument 3 of ?void DH_get0_key(const DH*, const BIGNUM**, const BIGNUM**)? void DH_get0_key(const DH *dh, ^~~~~~~~~~~ make[2]: *** [common/CMakeFiles/common.dir/build.make:591: common/CMakeFiles/common.dir/build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:231: common/CMakeFiles/common.dir/all] Error 2 make: *** [Makefile:130: all] Error 2 On Wed, Feb 21, 2018 at 8:20 AM, Benjamin Kaduk wrote: > On 02/21/2018 10:16 AM, Robert Watson wrote: > > I'm trying to update a crypto library for crtmpserver to work with openssl > 1.1.0. The software is no longer actively maintained and my c++ skills are > somewhat rudimentary but I keep getting a compilation error for something > that seems trivial. > > Here's the code snippet: > bool DHWrapper::CopyPublicKey(uint8_t *pDst, int32_t dstLength) { > if (_pDH == NULL) { > FATAL("DHWrapper not initialized"); > return false; > } > BIGNUM *_keyPublic,*_keyPrivate; > _keyPublic = BN_new(); > _keyPrivate = BN_new(); > DH_get0_key( _pDH, *_keyPublic, *_keyPrivate ); > > > Use '&' instead of '*' > > -Ben > > CopyKey(_keyPublic, pDst, dstLength); > return true; > } > > Here's the compilation error: > /build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp: > In member function ?bool DHWrapper::CopyPublicKey(uint8_t*, int32_t)?: > /build/crtmpserver/src/crtmpserver/sources/common/ > src/utils/misc/crypto.cpp:92:47: error: cannot convert ?BIGNUM {aka > bignum_st}? to ?const BIGNUM** {aka const bignum_st**}? for argument ?2? to > ?void DH_get0_key(const DH*, const BIGNUM**, const BIGNUM**)? > DH_get0_key( _pDH, *_keyPublic, *_keyPrivate ); > ^ > make[2]: *** [common/CMakeFiles/common.dir/build.make:591: > common/CMakeFiles/common.dir/build/crtmpserver/src/ > crtmpserver/sources/common/src/utils/misc/crypto.cpp.o] Error 1 > make[1]: *** [CMakeFiles/Makefile2:231: common/CMakeFiles/common.dir/all] > Error 2 > make: *** [Makefile:130: all] Error 2 > > What am I doing wrong? Thanks, > Robert > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norm.green at gemtalksystems.com Wed Feb 21 17:11:16 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Wed, 21 Feb 2018 09:11:16 -0800 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> Message-ID: On 2/21/2018 8:42 AM, Dennis Clarke wrote: > Pretty sure I have done builds and tests. In fact I am certain of it. If you added -xmemalign=8s to the SPARC compiler flags (as shown in one of your emails from yesterday) then you would not see the problem.? -xmemalign=8s forces the compiler to use 8-byte alignment. Norm From dclarke at blastwave.org Wed Feb 21 17:42:33 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Wed, 21 Feb 2018 12:42:33 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> Message-ID: <23c20ae7-efa7-c0e9-730c-bf1df507aa71@blastwave.org> On 21/02/18 12:11 PM, Norm Green wrote: > On 2/21/2018 8:42 AM, Dennis Clarke wrote: >> Pretty sure I have done builds and tests. In fact I am certain of it. > > If you added -xmemalign=8s to the SPARC compiler flags (as shown in one > of your emails from yesterday) then you would not see the problem. > -xmemalign=8s forces the compiler to use 8-byte alignment. Which is correct way to do this on sparc systems. I am digging into the whole build process to see what needs to be "hacked" at to get solid and reasonable results. The real issue is compilers. Sorry but gcc just won't do the right things on sparc and that isn't anyones fault. This is where we could go down a deep dark hole. For the sake of getting it out there we may as well just admit that the compilers that are generally installed on Solaris systems were of the Forte flavour way back when little dinosaurs were still roaming the datacenters and the cost of the license was about $3000 or so. The acquisitions and rename of everything happened for a while there and I am surprised no one at Sun lost their little minds and called it the Java Enterprise C Compiler because everything else had "Java" slapped on it. Regardless, the Forte name went away and we then had "Sun Studio" which revved up until we were able to compile the whole source code base with it and Solaris "UNIX" was self hosted and self boot-strappable and time marched on. So here we are today with Oracle Studio compilers and they are very very good. At least on sparc they are. The concept of doing a compile for a very specific machine class was dropped on the market way back in 1999 or so and I think by 2002 we could target flavours of sparc v9 with the vis instructions as well as a lot of hullabaloo about fused multiply etc. However that was a sun4c and sun4m issue back when we needed the optional weitek coprocessor. So anyways the "target" option was born out of necessity to get the right opcodes for given sparc units. People had fights over the entire x86 platform and Sun dropped it. Then picked it up again. Then built a version for Itanium. Put that on a shelf and hid it. Buried it. Then went back and released a general x86 version again. Madness. I had a sit down coffee with the global manager for the "solaris" product and it is history now but the compiler tools for x86 were never the same quality as the sparc tools. Never have been. One needs to use "fpversion" to get the correct target and cache line options but someone at Oracle has spilled a coffee and shuffled papers and forgot to release fpversion in the latest flavour of the Studio compilers. I will take a look on a big new shiney M-class machine and see what is there but I can tell you that the openssl binaries I build from sources are at least the same speed or better than the ones shipped out by Oracle. For a given specific type of machine and sparc target. jupiter # /opt/developerstudio12.5/bin/fpversion A SPARC-based CPU is available. Kernel says main memory's clock rate is 1272.0 MHz. Sun-4 floating-point controller version 0 found. An UltraSPARC chip is available. Use "-xtarget=sparc64viiplus -xcache=64/64/2:11264/256/11" code-generation option. Hostid = 0xBADCAFFE. A much older system may say : mimas $ /opt/solarisstudio12.4/bin/fpversion A SPARC-based CPU is available. Kernel says CPU's clock rate is 500.0 MHz. Kernel says main memory's clock rate is 100.0 MHz. Sun-4 floating-point controller version 0 found. An UltraSPARC chip is available. Use "-xtarget=ultra2e -xcache=16/32/1:256/64/1" code-generation option. Hostid = 0xBADCAFFE. Even more bizarre and older : ns1_$ /opt/solarisstudio12.4/bin/fpversion A SPARC-based CPU is available. Kernel says CPU's clock rate is 360.0 MHz. Kernel says main memory's clock rate is 90.0 MHz. Sun-4 floating-point controller version 0 found. An UltraSPARC chip is available. Use "-xtarget=ultra2i -xcache=16/32/1:1024/64/1" code-generation option. Hostid = 0xDEADBEEF. I say "bizarre" because that is a system that uses the memory options which were shipped on the E10k servers and those cache lines are wrong. That machine will always report "infinite" performance from openssl speed results and be damned if I can figure out why. Yet. ns1_$ /usr/local/ssl/bin/openssl speed rsa4096 Doing 4096 bit private rsa's for 10s: 13 4096 bit private RSA's in 0.00s Doing 4096 bit public rsa's for 10s: 1436 4096 bit public RSA's in 0.00s OpenSSL 1.0.2n 7 Dec 2017 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(ptr,risc1,16,int) aes(partial) idea(int) blowfish(ptr) compiler: /opt/solarisstudio12.4/bin/c99 -I. -I.. -I../include -KPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Xc -g -errfmt=error -erroff=%none -xmemalign=8s -errshort=full -xstrconst -xildoff -m64 -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -ftrap=%none -xarch=sparc -mc -xs -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -DB_ENDIAN -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM sign verify sign/s verify/s rsa 4096 bits 0.000000s 0.000000s inf inf However the latest from Oracle claims : $ ls /opt/developerstudio12.6/bin/fpversion /opt/developerstudio12.6/bin/fpversion: No such file or directory However it is in the manual still. Messy. Very. So as I said earlier ... this should be fun. Dennis From norm.green at gemtalksystems.com Wed Feb 21 17:57:17 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Wed, 21 Feb 2018 09:57:17 -0800 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <23c20ae7-efa7-c0e9-730c-bf1df507aa71@blastwave.org> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> <23c20ae7-efa7-c0e9-730c-bf1df507aa71@blastwave.org> Message-ID: On 2/21/2018 9:42 AM, Dennis Clarke wrote: > Which is correct way to do this on sparc systems. Why do you say that?? We've been building OpenSSL on SPARC for the past 7 years without that flag and it's worked just fine with only a few minor changes to the compile/link flags. Norm From dclarke at blastwave.org Wed Feb 21 18:12:12 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Wed, 21 Feb 2018 13:12:12 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> <23c20ae7-efa7-c0e9-730c-bf1df507aa71@blastwave.org> Message-ID: <5d624a03-998f-74a0-c957-5fee9e3cedc7@blastwave.org> On 21/02/18 12:57 PM, Norm Green wrote: > On 2/21/2018 9:42 AM, Dennis Clarke wrote: >> Which is correct way to do this on sparc systems. > > Why do you say that?? We've been building OpenSSL on SPARC for the past > 7 years without that flag and it's worked just fine with only a few > minor changes to the compile/link flags. > The whole idea here is that openssl ( like a lot of things ) is supposed to be portable code across a whack of platforms and while I can not recall the dusty memories of why this option was invented way way back in time I can at least quote the manual : B.2.144 -xmemalign=ab (SPARC) Use the -xmemalign option to control the assumptions that the compiler makes about the alignment of data. By controlling the code generated for potentially misaligned memory accesses and by controlling program behavior in the event of a misaligned access, you can more easily port your code to the SPARC platform. Right ... like it says. However what we are not saying here is what happens ( sig sig core dump and halt ) when the system attempts to reach out and touch memory in an icky way? You must provide a value for both alignment and behavior : Alignment Behavior 1 at most 1 byte alignment. i Interpret access and continue exec 2 at most 2 byte alignment. s Raise signal SIGBUS 4 at most 4 byte alignment. f same as specifying i when the alignment is 1, 2, or 4, also same as s when a=8 or 16 8 at most 8 byte alignment. 16 at most 16 byte alignment. So really we could do all manner of nasty things here and watch all manner of performance results and cool coredumps and it would be fun to try. However the option -xmemalign=8s will enforce "There should be no misaligned accesses in the program". So sayeth the manual going back way way back in time and so sayeth ye gray beard here from experience. So I guess that is why I would say this is the right way to do stuff. Dennis From openssl at jordan.maileater.net Wed Feb 21 18:06:48 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Wed, 21 Feb 2018 10:06:48 -0800 Subject: [openssl-users] Has client validated successfully? In-Reply-To: References: Message-ID: <611903bb-dd55-a03e-d754-2fd294953d16@jordan.maileater.net> On 2/20/2018 9:34 AM, J Decker wrote: > Client does a verification and passes or fails, and via the SSL layer > I can query if the client validated the certificate. > If it failed, provide a option for the client to get a renewed > certificate for verification.? If success, no action. > If an actor lies in this scenario he answers > lies *yes* and didn't, don't give him a means to actually verify. *noop* > lies *no* but did, then give him the root cert he already has.... *noop* Er... so I have my malicious MITM server serve up a certificate that the client won't accept, and then helpfully provide it with my root certificate so that it won't have any trouble talking to me? There's a reason for the client to verify the server's certificate.? If the client can't verify the server's certificate, then there's no reason to believe that it's the right server and can be trusted. Any certificate updates have to be protected by the previous certificate.? If you've let the certificate lapse then you need some kind of out-of-band verification. -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From dclarke at blastwave.org Wed Feb 21 18:15:52 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Wed, 21 Feb 2018 13:15:52 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> <23c20ae7-efa7-c0e9-730c-bf1df507aa71@blastwave.org> Message-ID: <9256be2c-9b5e-0d55-ba25-5ec570dd199e@blastwave.org> On 21/02/18 12:57 PM, Norm Green wrote: > On 2/21/2018 9:42 AM, Dennis Clarke wrote: >> Which is correct way to do this on sparc systems. > > Why do you say that?? We've been building OpenSSL on SPARC for the past > 7 years without that flag and it's worked just fine with only a few > minor changes to the compile/link flags. > > Norm > More simply ... there may be no code issue here at all. This is a compiler issue. Dennis From appro at openssl.org Wed Feb 21 20:46:22 2018 From: appro at openssl.org (Andy Polyakov) Date: Wed, 21 Feb 2018 21:46:22 +0100 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <5d624a03-998f-74a0-c957-5fee9e3cedc7@blastwave.org> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> <23c20ae7-efa7-c0e9-730c-bf1df507aa71@blastwave.org> <5d624a03-998f-74a0-c957-5fee9e3cedc7@blastwave.org> Message-ID: > So really we could do all manner of nasty things here and watch all > manner of performance results and cool coredumps and it would be fun to > try.? However the option -xmemalign=8s will enforce "There should be no > misaligned accesses in the program". And "the default for all v9 architectures is -xmemalign=8s". Other values are effectively for those who are lazy enough to fix broken code taken from x86[_64]. Values other than 8s are also kind of "whole application" things, i.e. it would be inappropriate to compile a *library* [such as OpenSSL] with any other flag than -xmemalign=8s. Which is why it *is* the default, has to be, so you don't have to actually specify it. In other words assertion that not specifying -xmemalign=8s is somehow wrong is not actually substantiated. Not specifying it is perfectly appropriate. On related note OpenSSL is periodically tested on RISC platforms and misalignment issues get ironed out in time. [That's why I wondered how come it went unnoticed so far.] Just in case for reference, default for 32-bit code is 8i. I assume that it implies 4s, which would be consistent with expected RISC behaviour, i.e. SIGBUS on register-sized loads/stores. Though there is ambiguity. One would expect SIGBUG on double-precision floating point load/store even on 32-bit system. So does 8i mean that it would actually tolerate misaligned doubles? From mcr at sandelman.ca Wed Feb 21 21:38:18 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 21 Feb 2018 16:38:18 -0500 Subject: [openssl-users] DTLS server records repeated Message-ID: <19445.1519249098@obiwan.sandelman.ca> I'm capturing from my DTLS client and server, with CoAP running on top. I've been debugging some ruby-level I/O buffering issues. I noticed this while capturing, and used tshark to get this print out. (I've added columns for port numbers) 2 66.009171 ::2 35345 ::2 5684 DTLSv1.0 263 Client Hello 3 66.009494 ::2 5684 ::2 35345 DTLSv1.0 122 Hello Verify Request 4 66.009798 ::2 35345 ::2 5684 DTLSv1.0 295 Client Hello 5 66.011771 ::2 5684 ::2 35345 DTLSv1.2 810 Server Hello, Certificate, Server Key Exchange[Malformed Packet] The Hello/Verify/Hello makes complete sense. tshark claims there is a malformed packet, but it seems to be the opinion of wireshark/tshark 1.12.1, as 2.2.6 (on my desktop vs laptop) has no problem with the packet. But, why are the Server Hello, Certificate and ServerKeyExchange then repeated in another three packets? The sequence numbers in the DTLS header seem to increment as well. It's like some PMTU detector is getting confused and trying to send again. 6 67.037421 ::2 5684 ::2 35345 DTLSv1.2 148 Server Hello 7 67.037453 ::2 5684 ::2 35345 DTLSv1.2 562 Certificate 8 67.037468 ::2 5684 ::2 35345 DTLSv1.2 199 Server Key Exchange[Malformed Packet] And then things proceed, apparently just fine. 9 67.037482 ::2 5684 ::2 35345 DTLSv1.2 87 Server Hello Done 10 67.037518 ::2 35345 ::2 5684 DTLSv1.0 295 Client Hello 11 67.041860 ::2 35345 ::2 5684 DTLSv1.2 195 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 12 67.044257 ::2 5684 ::2 35345 DTLSv1.2 328 New Session Ticket, Change Cipher Spec, Encrypted Handshake Message 13 67.044909 ::2 35345 ::2 5684 DTLSv1.2 135 Application Data 14 67.056746 ::2 5684 ::2 35345 DTLSv1.2 111 Application Data http://junk.sandelman.ca/junk/dtls1.pcap if you want to see more details. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From norm.green at gemtalksystems.com Wed Feb 21 21:53:40 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Wed, 21 Feb 2018 13:53:40 -0800 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> <23c20ae7-efa7-c0e9-730c-bf1df507aa71@blastwave.org> <5d624a03-998f-74a0-c957-5fee9e3cedc7@blastwave.org> Message-ID: On 2/21/2018 12:46 PM, Andy Polyakov wrote: > And "the default for all v9 architectures is -xmemalign=8s". I'm getting confused.? Since I did not specify -xmemalign at all, why did the test fail with SIGBUS in the first place?? Seems like there should have been no alignment problem if the compiler is doing the right thing by default as you say. Norm From appro at openssl.org Wed Feb 21 22:40:45 2018 From: appro at openssl.org (Andy Polyakov) Date: Wed, 21 Feb 2018 23:40:45 +0100 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> <23c20ae7-efa7-c0e9-730c-bf1df507aa71@blastwave.org> <5d624a03-998f-74a0-c957-5fee9e3cedc7@blastwave.org> Message-ID: <2ac2c7bd-52b5-1b25-dc46-34aa7abbc60d@openssl.org> >> And "the default for all v9 architectures is -xmemalign=8s". > I'm getting confused.? Since I did not specify -xmemalign at all, And not specifying -xmemalign is equivalent of specifying 8s in 64-bit build such as one in question. > why > did the test fail with SIGBUS in the first place?? Seems like there > should have been no alignment problem if the compiler is doing the right > thing by default as you say. Once again, objects on stack are *customarily* aligned at pointer size, i.e. at 8 bytes in -xarch=v9 case, even if their declaration doesn't imply corresponding guarantee. Or in other words, specifically in context of this question, even though 'buf' is *not required* to be aligned at 8 bytes by language standard, so far it was effectively observed to be aligned anyway, at least on other RISC platforms. Now, I'm *not* saying that we should *rely* on this custom, rather contrary, we definitely should *not*. Question is what does the fact that it went unnoticed till now mean. Or in more practical terms are there more such dependencies that shouldn't be there? Because if possible, it would only be appropriate to locate and eliminate them. In yet other words, mystery is not why this specific test crashed on you, but rather what else can crash (but doesn't for some reason). From matt at openssl.org Wed Feb 21 23:44:47 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 21 Feb 2018 23:44:47 +0000 Subject: [openssl-users] DTLS server records repeated In-Reply-To: <19445.1519249098@obiwan.sandelman.ca> References: <19445.1519249098@obiwan.sandelman.ca> Message-ID: <7942812e-0ddf-9075-c73a-9152d49492ec@openssl.org> On 21/02/18 21:38, Michael Richardson wrote: > > I'm capturing from my DTLS client and server, with CoAP running on top. > I've been debugging some ruby-level I/O buffering issues. > I noticed this while capturing, and used tshark to get this print out. > (I've added columns for port numbers) > > 2 66.009171 ::2 35345 ::2 5684 DTLSv1.0 263 Client Hello > 3 66.009494 ::2 5684 ::2 35345 DTLSv1.0 122 Hello Verify Request > 4 66.009798 ::2 35345 ::2 5684 DTLSv1.0 295 Client Hello > 5 66.011771 ::2 5684 ::2 35345 DTLSv1.2 810 Server Hello, Certificate, Server Key Exchange[Malformed Packet] The Server Hello Done seems to be missing from this sequence. Perhaps dropped somewhere en-route? > > 6 67.037421 ::2 5684 ::2 35345 DTLSv1.2 148 Server Hello > 7 67.037453 ::2 5684 ::2 35345 DTLSv1.2 562 Certificate > 8 67.037468 ::2 5684 ::2 35345 DTLSv1.2 199 Server Key Exchange[Malformed Packet] The client is waiting for the Server Hello Done to arrive which seems to have been dropped. Meanwhile the server is waiting for the client's response to the flight of messages it just sent. After a timeout the server retransmits its last flight (note the sudden increment in time between the previous Server Key Exchange, and the second Server Hello). > > And then things proceed, apparently just fine. > > 9 67.037482 ::2 5684 ::2 35345 DTLSv1.2 87 Server Hello Done > This time the Server Hello Done has arrived. > 10 67.037518 ::2 35345 ::2 5684 DTLSv1.0 295 Client Hello This appears to be a retransmit on the client side. Probably the server retransmit and the client retransmit crossed. > 11 67.041860 ::2 35345 ::2 5684 DTLSv1.2 195 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message Now the client has received the Server Hello Done it was waiting for and the handshake can proceed. Matt From angus at magsys.co.uk Thu Feb 22 17:58:00 2018 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Thu, 22 Feb 2018 17:58 +0000 (GMT Standard Time) Subject: [openssl-users] [wiki-support] Wiki In-Reply-To: <013e4d42-76a3-6d38-d461-08830b310724@openssl.org> Message-ID: Subject:* Re: [openssl-users] Windows 1.1.1 binaries and web server *From:* "Salz, Rich" *To:* "angus at magsys.co.uk" , "openssl-users at openssl.org" *Date:* Wed, 21 Feb 2018 14:12:25 +0000 This is very useful! Can you post an udate to the wiki? https://wiki.openssl.org/index.php/Binaries -------- Original Message -------- *Subject:* Re: [wiki-support] Wiki *From:* Matt Caswell *To:* wiki-support at openssl.org, angus at magsys.co.uk *Date:* Thu, 22 Feb 2018 15:48:41 +0000 On 21/02/18 17:31, Angus Robertson - Magenta Systems Ltd wrote: > Can I please have an account on the wiki, I'm already on the mailing > lists. Hi Angus Please could you some examples of changes that you wish to make on the wiki? Please be specific. Also, what username would you like? Regards Matt From angus at magsys.co.uk Fri Feb 23 12:13:00 2018 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Fri, 23 Feb 2018 12:13 +0000 (GMT Standard Time) Subject: [openssl-users] Windows 1.1.1 binaries and web server In-Reply-To: <16DBF3DC-4983-47CA-BF45-D224068D1985@akamai.com> Message-ID: > This is very useful! Can you post an udate to the wiki? > https://wiki.openssl.org/index.php/Binaries Wiki has been updated with details of the binaries and download locations. Angus From etc at coderhacks.com Fri Feb 23 14:06:41 2018 From: etc at coderhacks.com (etc at coderhacks.com) Date: Fri, 23 Feb 2018 15:06:41 +0100 Subject: [openssl-users] c_hash/ca-certificates.crt Message-ID: <2222b25d-c179-0825-95c6-a0bc9f28bb52@coderhacks.com> Hello! Normally I put new certificates into /etc/ssl/certs and create the hash-link. That workes for me for many years. Just found out 2 new things agout that. 1. There is c_hash that does the creation of the hash-link for me. Great! 2. ca-certificates.crt is there too. It has any certificate inside of it that is also in the directory but not the ones I added by myself over the years. Today was the 1st time I had to add a certificate to thefile because a tool looked into that file and not into the directory. Please what is the relation to the directory and ca-certificates.crt and is there a tool/command to that adds new certificates to the file too? Thanks! CH From matt at openssl.org Fri Feb 23 14:55:47 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 23 Feb 2018 14:55:47 +0000 Subject: [openssl-users] c_hash/ca-certificates.crt In-Reply-To: <2222b25d-c179-0825-95c6-a0bc9f28bb52@coderhacks.com> References: <2222b25d-c179-0825-95c6-a0bc9f28bb52@coderhacks.com> Message-ID: <38f1885f-0f17-3f01-afdd-fc6d1ba4eb49@openssl.org> On 23/02/18 14:06, etc at coderhacks.com wrote: > Hello! > > Normally I put new certificates into /etc/ssl/certs and create the > hash-link. > That workes for me for many years. > > > Just found out 2 new things agout that. > > 1. There is c_hash that does the creation of the hash-link for me. > Great! > > 2. ca-certificates.crt is there too. It has any certificate inside of it > that is also in the directory but not the ones I added by myself over > the years. > Today was the 1st time I had to add a certificate to thefile because a > tool looked into that file and not into the directory. > > Please what is the relation to the directory and ca-certificates.crt and > is there a tool/command to that adds new certificates to the file too? Strictly speaking this isn't an OpenSSL question. OpenSSL does not create or distribute the contents of /etc/ssl/certs. However it *does* provide the ability to read a set of CA certs from either a directory or a file. Applications can choose to work which ever way they want. I assume that distros have opted to provide both a directory *and* a file so that they can supply certs for which ever way an application chooses to work. My understanding is that you are supposed to put locally added certs in /usr/local/share/ca-certficates, and then run the update-ca-certificates tool which updates both the directory and the file. Matt From jb-openssl at wisemo.com Fri Feb 23 15:07:57 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 23 Feb 2018 16:07:57 +0100 Subject: [openssl-users] c_hash/ca-certificates.crt In-Reply-To: <38f1885f-0f17-3f01-afdd-fc6d1ba4eb49@openssl.org> References: <2222b25d-c179-0825-95c6-a0bc9f28bb52@coderhacks.com> <38f1885f-0f17-3f01-afdd-fc6d1ba4eb49@openssl.org> Message-ID: On 23/02/2018 15:55, Matt Caswell wrote: > > On 23/02/18 14:06, etc at coderhacks.com wrote: >> Hello! >> >> Normally I put new certificates into /etc/ssl/certs and create the >> hash-link. >> That workes for me for many years. >> >> >> Just found out 2 new things agout that. >> >> 1. There is c_hash that does the creation of the hash-link for me. >> Great! >> >> 2. ca-certificates.crt is there too. It has any certificate inside of it >> that is also in the directory but not the ones I added by myself over >> the years. >> Today was the 1st time I had to add a certificate to thefile because a >> tool looked into that file and not into the directory. >> >> Please what is the relation to the directory and ca-certificates.crt and >> is there a tool/command to that adds new certificates to the file too? > Strictly speaking this isn't an OpenSSL question. OpenSSL does not > create or distribute the contents of /etc/ssl/certs. However it *does* > provide the ability to read a set of CA certs from either a directory or > a file. Applications can choose to work which ever way they want. > > I assume that distros have opted to provide both a directory *and* a > file so that they can supply certs for which ever way an application > chooses to work. > > My understanding is that you are supposed to put locally added certs in > /usr/local/share/ca-certficates, and then run the update-ca-certificates > tool which updates both the directory and the file. > > Matt If the system is a recent version of Debian or similar (this may or may not include DevUan and Ubuntu), you are supposed to put your private certificates in /usr/local/share/ca-certificates/*.crt while the system supplied root certs are in /usr/share/ca-certificates/ .? Then rerun dpkg-reconfigure ca-certificates, and edit (by check boxes) which of the standard CAs you trust.? The ones in /usr/local/share/ca-certificates/ are trusted unconditionally, no questions asked.? Due to bugs, you may have to run the command twice, with the same selections. 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 dan at woz.io Fri Feb 23 17:47:14 2018 From: dan at woz.io (Daniel Wozniak) Date: Fri, 23 Feb 2018 10:47:14 -0700 Subject: [openssl-users] M2Crypto Updates Message-ID: I've recently made some changes to M2Crypto (a SWIG wrapper around OpenSSL for Python). The changes update M2Crypto such that it can be compiled and run on Windows without needing applink.c. M2Crypto's maintainer Mat?j has reviewed the changes and was happy enough with them that he's pushed a release 0.29 this morning. At this time there has only been a few people actually look at the changes. I'm reaching out to the OpenSSL community in hopes one or more people will review the changes that were made: https://gitlab.com/m2crypto/m2crypto/merge_requests/26 -Daniel Wozniak From mcepl at cepl.eu Fri Feb 23 21:04:27 2018 From: mcepl at cepl.eu (=?UTF-8?Q?Mat=C4=9Bj?= Cepl) Date: Fri, 23 Feb 2018 22:04:27 +0100 Subject: [openssl-users] [ANN] M2Crypto 0.29.0 ... now supporting Windows Message-ID: <1519419867.4399.7.camel@cepl.eu> Hi, everybody, just on the heels of 0.28.* with Python 3 compatibility with 0.29.0 resolving another heavy problem. This time we have renewed compatibility with Windows (all tests pass on Win32 and Win64 on all supported combinations of versions of OpenSSL and Python). The problem I have and I would like to input especially from those of you who might be interested in the Windows builds is which kind of package we want. Appveyor CI (which we use for testing) gives us in https://ci.appveyor.com/project/mcepl/m2cryp to-6gp50/build/1.0.52 as artifacts binary wheels, Windows executable installers, and MSI files. Which one of them is the most desired by Python developers on Windows? Where do you expect such binary packages to be found? PyPI, Chocolatey, somewhere else? Also, reminder, that we have special email list for development of M2Crypto. Its web page is http://redcrew.org/mailman/listinfo/ m2crypto and it is mailman with the posting address m2crypto at lists.redcrew.org so all email commands work. All complaints, support requests, and bug reports are welcome in the email list or on the issue tracker https://gitlab.com/m2crypto/m2crypto/issues Happy security hacking! Mat?j -- https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Because dwm is customized through editing its source code, it?s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. -- http://dwm.suckless.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From norm.green at gemtalksystems.com Fri Feb 23 22:31:49 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Fri, 23 Feb 2018 14:31:49 -0800 Subject: [openssl-users] OpenSSL 1.1.1pre1 fails to build on AIX 7.1 Message-ID: <793d23fd-5c34-880a-c8da-d5ea66061fd1@gemtalksystems.com> Looks like no target .a file is passed to ar ? Note: OpenSSL 1.1.0 succeeds on this platform. /export/localnew/RISC6000.AIX/perl-5.24.0/bin/perl -i -pe 's/^.*\|//; s/ \/(\\.|[^ ])*//; $_ = undef if (/: *$/ || /^(#.*| *)$/); $_.="\n" unless !defined($_) or /\R$/g;' apps/s_socket.d.tmp ar -X 64 apps/libapps.a apps/app_rand.o apps/apps.o apps/bf_prefix.o apps/opt.o apps/s_cb.o apps/s_socket.o ar: 0707-101 / is not a valid flag. make: The error code from the last command is 1. Stop. make: The error code from the last command is 2. From dclarke at blastwave.org Fri Feb 23 22:36:49 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Fri, 23 Feb 2018 17:36:49 -0500 Subject: [openssl-users] OpenSSL 1.1.1pre1 fails to build on AIX 7.1 In-Reply-To: <793d23fd-5c34-880a-c8da-d5ea66061fd1@gemtalksystems.com> References: <793d23fd-5c34-880a-c8da-d5ea66061fd1@gemtalksystems.com> Message-ID: <3fa71274-ad3e-7e35-c14a-3070f6348b55@blastwave.org> On 23/02/18 05:31 PM, Norm Green wrote: > Looks like no target .a file is passed to ar ? > > Note: OpenSSL 1.1.0 succeeds on this platform. > > > /export/localnew/RISC6000.AIX/perl-5.24.0/bin/perl -i -pe 's/^.*\|//; s/ > \/(\\.|[^ ])*//; $_ = undef if (/: *$/ || /^(#.*| *)$/); $_.="\n" unless > !defined($_) or /\R$/g;' apps/s_socket.d.tmp > ar -X 64 apps/libapps.a apps/app_rand.o apps/apps.o apps/bf_prefix.o > apps/opt.o apps/s_cb.o apps/s_socket.o > ar: 0707-101 / is not a valid flag. > make: The error code from the last command is 1. > > > Stop. > make: The error code from the last command is 2. > slightly off topic .. sorry. Looks like you are on a few risc platforms whereas I am still hacking away on sparc. When I say "sparc" I really mean a Fujitsu SPARCVII+ type unit and not a classic Sun sparcv9 unit. I will get to those afterwards. Dennis From norm.green at gemtalksystems.com Fri Feb 23 23:36:58 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Fri, 23 Feb 2018 15:36:58 -0800 Subject: [openssl-users] OpenSSL 1.1.1pre1 fails to build on AIX 7.1 In-Reply-To: <3fa71274-ad3e-7e35-c14a-3070f6348b55@blastwave.org> References: <793d23fd-5c34-880a-c8da-d5ea66061fd1@gemtalksystems.com> <3fa71274-ad3e-7e35-c14a-3070f6348b55@blastwave.org> Message-ID: <1649276c-f9f0-6d81-8c1e-09129a1f8ec9@gemtalksystems.com> Adding "-cru" to arflags for AIX in Configuratinos/10-main.conf solves the problem. On 2/23/2018 2:36 PM, Dennis Clarke wrote: > On 23/02/18 05:31 PM, Norm Green wrote: >> Looks like no target .a file is passed to ar ? >> >> Note: OpenSSL 1.1.0 succeeds on this platform. >> >> >> /export/localnew/RISC6000.AIX/perl-5.24.0/bin/perl -i -pe 's/^.*\|//; >> s/ \/(\\.|[^ ])*//; $_ = undef if (/: *$/ || /^(#.*| *)$/); $_.="\n" >> unless !defined($_) or /\R$/g;' apps/s_socket.d.tmp >> ar -X 64 apps/libapps.a apps/app_rand.o apps/apps.o apps/bf_prefix.o >> apps/opt.o apps/s_cb.o apps/s_socket.o >> ar: 0707-101 / is not a valid flag. >> make: The error code from the last command is 1. >> >> >> Stop. >> make: The error code from the last command is 2. >> > > slightly off topic .. sorry. > > Looks like you are on a few risc platforms whereas I am still hacking > away on sparc.? When I say "sparc" I really mean a Fujitsu SPARCVII+ > type unit and not a classic Sun sparcv9 unit. I will get to those > afterwards. > > Dennis From dclarke at blastwave.org Sat Feb 24 00:04:43 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Fri, 23 Feb 2018 19:04:43 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> <23c20ae7-efa7-c0e9-730c-bf1df507aa71@blastwave.org> <5d624a03-998f-74a0-c957-5fee9e3cedc7@blastwave.org> Message-ID: On 21/02/18 04:53 PM, Norm Green wrote: > On 2/21/2018 12:46 PM, Andy Polyakov wrote: >> And "the default for all v9 architectures is -xmemalign=8s". > I'm getting confused.? Since I did not specify -xmemalign at all.. Without getting into some needed CFLAGS let me just say that the build ran fine here other than test/ct_test.c needs to link with libm. I just tossed in the required -lm on the EX_LIBS in the Makefile. Not optimal but gets the job done for the moment. Also there is a nagging perl version problem and that is just .. annoying. So testsuite is running but this is a non-optimal debug build and only on the Fujitsu sparc and not on a baseline v9 yet. See "e_flags" in the ELF header below which is somewhat restrictive. corv $ elfdump -devl ./apps/openssl ELF Header ei_magic: { 0x7f, E, L, F } ei_class: ELFCLASS64 ei_data: ELFDATA2MSB ei_osabi: ELFOSABI_SOLARIS ei_abiversion: EAV_SUNW_CURRENT e_machine: EM_SPARCV9 e_version: EV_CURRENT e_type: ET_EXEC e_flags: [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ] e_entry: 0x10001c600 e_ehsize: 64 e_shstrndx: 29 e_shoff: 0xe0ea38 e_shentsize: 64 e_shnum: 31 e_phoff: 0x40 e_phentsize: 56 e_phnum: 6 Version Needed Section: .SUNW_version index file version [2] libssl.so OPENSSL_1_1_0 [ INFO ] [3] OPENSSL_1_1_1 [4] libcrypto.so OPENSSL_1_1_0 [ INFO ] [5] OPENSSL_1_1_1 [6] libsocket.so.1 SUNW_0.7 [7] libpthread.so.1 SUNW_1.2 [8] SUNW_0.9 [ INFO ] [9] libc.so.1 SUNW_1.21.2 [10] SUNW_0.7 [ INFO ] Dynamic Section: .dynamic index tag value [0] NEEDED 0x6d18 libssl.so [1] NEEDED 0x6d3e libcrypto.so [2] NEEDED 0x6d9b libz.so.1 [3] NEEDED 0x6d4b libsocket.so.1 [4] NEEDED 0x6da5 libnsl.so.1 [5] NEEDED 0x6db1 libdl.so.1 [6] NEEDED 0x6d63 libpthread.so.1 [7] NEEDED 0x6d85 libc.so.1 [8] INIT 0x1006caa58 [9] FINI 0x1006caa68 [10] RUNPATH 0x6dbc /usr/local/lib:/usr/local/ssl/lib [11] RPATH 0x6dbc /usr/local/lib:/usr/local/ssl/lib [12] HASH 0x1000001d0 [13] STRTAB 0x10000c9c0 [14] STRSZ 0x6fde [15] SYMTAB 0x1000033d8 [16] SYMENT 0x18 [17] CHECKSUM 0x33bc [18] VERNEED 0x1000139a0 [19] VERNEEDNUM 0x5 [20] PLTRELSZ 0x7b60 [21] PLTREL 0x7 [22] JMPREL 0x100014a90 [23] RELA 0x100014700 [24] RELASZ 0x7ef0 [25] RELAENT 0x18 [26] DEBUG 0 [27] SUNW_CAP 0x1000001b0 [28] FLAGS 0 0 [29] FLAGS_1 0 0 [30] SUNW_STRPAD 0x200 [31] SUNW_LDMACH 0x2b EM_SPARCV9 [32] PLTGOT 0x1007ead00 [33-43] NULL 0 corv $ LD_LIBRARY_PATH=`pwd` ./apps/openssl version OpenSSL 1.1.1-pre1 (alpha) 13 Feb 2018 corv $ So .. this is progress. Dennis ps: Oracle bugid 26277061 explains e_flags must only be EF_SPARCV9_TSO From dclarke at blastwave.org Sat Feb 24 05:24:34 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Sat, 24 Feb 2018 00:24:34 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> Message-ID: <607c8d70-4283-1b55-2eac-c9f30a3a3f92@blastwave.org> I have run into a bit of a snag here. Firstly everything compiles just fine with zero code changes. Zero. All we need are some careful CFLAGS and the compile moves along swimmingly. However the test stage gets terribly wedged just after test 70-test_clienthello.t completes. Not sure why but the various scripts and test files are hell bent on using the perl in the system as opposed to what I have set in an env var PERL=/usr/local/bin/perl. That may be the issue. Not sure. Also would be really nice if all the shell scripts could use the the bash shell in the env var CONFIG_SHELL which is pointed to /usr/local/bin/bash. If you have any thoughts let me know or I will jsut keep on with my awk and sed kung fu here changing all the scripts. Dennis ps: I still need to get this all built for baseline v9 and not the more modern processors : corv $ elfdump -devl ./apps/openssl ELF Header ei_magic: { 0x7f, E, L, F } ei_class: ELFCLASS64 ei_data: ELFDATA2MSB ei_osabi: ELFOSABI_SOLARIS ei_abiversion: EAV_SUNW_CURRENT e_machine: EM_SPARCV9 e_version: EV_CURRENT e_type: ET_EXEC e_flags: [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ] e_entry: 0x10001c600 e_ehsize: 64 e_shstrndx: 29 e_shoff: 0xe0ea38 e_shentsize: 64 e_shnum: 31 e_phoff: 0x40 e_phentsize: 56 e_phnum: 6 Version Needed Section: .SUNW_version index file version [2] libssl.so OPENSSL_1_1_0 [ INFO ] [3] OPENSSL_1_1_1 [4] libcrypto.so OPENSSL_1_1_0 [ INFO ] [5] OPENSSL_1_1_1 [6] libsocket.so.1 SUNW_0.7 [7] libpthread.so.1 SUNW_1.2 [8] SUNW_0.9 [ INFO ] [9] libc.so.1 SUNW_1.21.2 [10] SUNW_0.7 [ INFO ] Dynamic Section: .dynamic index tag value [0] NEEDED 0x6d18 libssl.so [1] NEEDED 0x6d3e libcrypto.so [2] NEEDED 0x6d9b libz.so.1 [3] NEEDED 0x6d4b libsocket.so.1 [4] NEEDED 0x6da5 libnsl.so.1 [5] NEEDED 0x6db1 libdl.so.1 [6] NEEDED 0x6d63 libpthread.so.1 [7] NEEDED 0x6d85 libc.so.1 [8] INIT 0x1006caa58 [9] FINI 0x1006caa68 [10] RUNPATH 0x6dbc /usr/local/lib:/usr/local/ssl/lib [11] RPATH 0x6dbc /usr/local/lib:/usr/local/ssl/lib [12] HASH 0x1000001d0 [13] STRTAB 0x10000c9c0 [14] STRSZ 0x6fde [15] SYMTAB 0x1000033d8 [16] SYMENT 0x18 [17] CHECKSUM 0x33bc [18] VERNEED 0x1000139a0 [19] VERNEEDNUM 0x5 [20] PLTRELSZ 0x7b60 [21] PLTREL 0x7 [22] JMPREL 0x100014a90 [23] RELA 0x100014700 [24] RELASZ 0x7ef0 [25] RELAENT 0x18 [26] DEBUG 0 [27] SUNW_CAP 0x1000001b0 [28] FLAGS 0 0 [29] FLAGS_1 0 0 [30] SUNW_STRPAD 0x200 [31] SUNW_LDMACH 0x2b EM_SPARCV9 [32] PLTGOT 0x1007ead00 [33-43] NULL 0 corv $ LD_LIBRARY_PATH=`pwd` ./apps/openssl version OpenSSL 1.1.1-pre1 (alpha) 13 Feb 2018 corv $ From appro at openssl.org Sat Feb 24 09:13:10 2018 From: appro at openssl.org (Andy Polyakov) Date: Sat, 24 Feb 2018 10:13:10 +0100 Subject: [openssl-users] OpenSSL 1.1.1pre1 fails to build on AIX 7.1 In-Reply-To: <793d23fd-5c34-880a-c8da-d5ea66061fd1@gemtalksystems.com> References: <793d23fd-5c34-880a-c8da-d5ea66061fd1@gemtalksystems.com> Message-ID: <9ebc2bfb-5cd7-daaf-d508-83c03ea913ad@openssl.org> > Looks like no target .a file is passed to ar ? > > Note: OpenSSL 1.1.0 succeeds on this platform. > > > /export/localnew/RISC6000.AIX/perl-5.24.0/bin/perl -i -pe 's/^.*\|//; s/ > \/(\\.|[^ ])*//; $_ = undef if (/: *$/ || /^(#.*| *)$/); $_.="\n" unless > !defined($_) or /\R$/g;' apps/s_socket.d.tmp > ar -X 64 apps/libapps.a apps/app_rand.o apps/apps.o apps/bf_prefix.o > apps/opt.o apps/s_cb.o apps/s_socket.o > ar: 0707-101 / is not a valid flag. > make: The error code from the last command is 1. This was resolved, https://github.com/openssl/openssl/pull/5386. From appro at openssl.org Sat Feb 24 09:47:07 2018 From: appro at openssl.org (Andy Polyakov) Date: Sat, 24 Feb 2018 10:47:07 +0100 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> <23c20ae7-efa7-c0e9-730c-bf1df507aa71@blastwave.org> <5d624a03-998f-74a0-c957-5fee9e3cedc7@blastwave.org> Message-ID: <2faa10cf-888d-651d-eda5-77af1169520e@openssl.org> > So testsuite is running but this is a non-optimal debug build and only > on the Fujitsu sparc and not on a baseline v9 yet. See "e_flags" in the > ELF header below which is somewhat restrictive. > > ? e_flags:??? [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ] If "somewhat restrictive" refers to presence of EF_SPARC_SUN_US1 and EF_SPARC_SUN_US3, then it's likely to be between you and compiler/run-time. The flags are set by linker as logical 'or' of flags from all input object files involved. What you need is to identify which of the *.o files that carries additional flags. On Linux I'd simply 'find . -name \*.o -exec file {} \;' and would show things like "Sun UltraSPARC1 Extensions Required". If you find nothing among OpenSSL .o files, then flag comes from elsewhere, and that would be question to vendor. But even if you find OpenSSL *.o file with undesired flag, it would still be question to vendor, because -xarch=v9 is documented to mean "no extensions please", so there shouldn't be any. As for -lm, which symbol was undefined? From levitte at openssl.org Sat Feb 24 10:01:30 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 24 Feb 2018 11:01:30 +0100 (CET) Subject: [openssl-users] OpenSSL 1.1.1pre1 fails to build on AIX 7.1 In-Reply-To: <793d23fd-5c34-880a-c8da-d5ea66061fd1@gemtalksystems.com> References: <793d23fd-5c34-880a-c8da-d5ea66061fd1@gemtalksystems.com> Message-ID: <20180224.110130.536857137023868136.levitte@openssl.org> Oh, it's passed alright, but no command flag is passed. The attached patch (which is currently in master and will therefore be part of the next pre-release) fixes it. Cheers, Richard In message <793d23fd-5c34-880a-c8da-d5ea66061fd1 at gemtalksystems.com> on Fri, 23 Feb 2018 14:31:49 -0800, Norm Green said: norm.green> Looks like no target .a file is passed to ar ? norm.green> norm.green> Note: OpenSSL 1.1.0 succeeds on this platform. norm.green> norm.green> norm.green> /export/localnew/RISC6000.AIX/perl-5.24.0/bin/perl -i -pe 's/^.*\|//; norm.green> s/ \/(\\.|[^ ])*//; $_ = undef if (/: *$/ || /^(#.*| *)$/); $_.="\n" norm.green> unless !defined($_) or /\R$/g;' apps/s_socket.d.tmp norm.green> ar -X 64 apps/libapps.a apps/app_rand.o apps/apps.o apps/bf_prefix.o norm.green> apps/opt.o apps/s_cb.o apps/s_socket.o norm.green> ar: 0707-101 / is not a valid flag. norm.green> make: The error code from the last command is 1. norm.green> norm.green> norm.green> Stop. norm.green> make: The error code from the last command is 2. norm.green> norm.green> -------------- next part -------------- A non-text attachment was scrubbed... Name: aix.diff Type: text/x-patch Size: 2808 bytes Desc: not available URL: From levitte at openssl.org Sat Feb 24 10:13:20 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 24 Feb 2018 11:13:20 +0100 (CET) Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <607c8d70-4283-1b55-2eac-c9f30a3a3f92@blastwave.org> References: <607c8d70-4283-1b55-2eac-c9f30a3a3f92@blastwave.org> Message-ID: <20180224.111320.668675301640295218.levitte@openssl.org> In message <607c8d70-4283-1b55-2eac-c9f30a3a3f92 at blastwave.org> on Sat, 24 Feb 2018 00:24:34 -0500, Dennis Clarke said: dclarke> Not sure why but the various scripts and test files are hell dclarke> bent on using the perl in the system as opposed to what I dclarke> have set in an env var PERL=/usr/local/bin/perl. Hmmm, if it's hell bent on anything, it's on what perl was used to run 'Configure'. I'm not sure if you use that script directly or if you use 'config'... the latter will certainly look at $PERL to run 'Configure', and this one will register $^X (perl's internal variable to indicate the exact file name of the interpreter), which is then propagated to Makefile (make variable $(PERL)) and used there. Did we miss a spot? I'm willing to correct that... Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From dclarke at blastwave.org Sat Feb 24 11:13:18 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Sat, 24 Feb 2018 06:13:18 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <2faa10cf-888d-651d-eda5-77af1169520e@openssl.org> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> <23c20ae7-efa7-c0e9-730c-bf1df507aa71@blastwave.org> <5d624a03-998f-74a0-c957-5fee9e3cedc7@blastwave.org> <2faa10cf-888d-651d-eda5-77af1169520e@openssl.org> Message-ID: <43ad924b-c05b-e9c0-e1cf-2178e2ae2075@blastwave.org> On 24/02/18 04:47 AM, Andy Polyakov wrote: >> So testsuite is running but this is a non-optimal debug build and only >> on the Fujitsu sparc and not on a baseline v9 yet. See "e_flags" in the >> ELF header below which is somewhat restrictive. >> >> ? e_flags:??? [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ] > > If "somewhat restrictive" refers to presence of EF_SPARC_SUN_US1 and > EF_SPARC_SUN_US3 ... I wasn't clear. I know exactly what causes this. I am saying that I will have to redo everything again and get the process down to a baseline config. > As for -lm, which symbol was undefined? > Undefined first referenced symbol in file fabs test/ct_test.o dc From dclarke at blastwave.org Sat Feb 24 11:14:50 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Sat, 24 Feb 2018 06:14:50 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <20180224.111320.668675301640295218.levitte@openssl.org> References: <607c8d70-4283-1b55-2eac-c9f30a3a3f92@blastwave.org> <20180224.111320.668675301640295218.levitte@openssl.org> Message-ID: On 24/02/18 05:13 AM, Richard Levitte wrote: > In message <607c8d70-4283-1b55-2eac-c9f30a3a3f92 at blastwave.org> on Sat, 24 Feb 2018 00:24:34 -0500, Dennis Clarke said: > > > dclarke> Not sure why but the various scripts and test files are hell > dclarke> bent on using the perl in the system as opposed to what I > dclarke> have set in an env var PERL=/usr/local/bin/perl. > > Hmmm, if it's hell bent on anything, it's on what perl was used to run > 'Configure'. I'm not sure if you use that script directly or if you > use 'config'... the latter will certainly look at $PERL to run OKay ... I can try "config" however I did use "Configure" : corv $ ./Configure shared zlib threads solaris64-sparcv9-cc dc From dclarke at blastwave.org Sat Feb 24 11:18:54 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Sat, 24 Feb 2018 06:18:54 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <20180224.111320.668675301640295218.levitte@openssl.org> References: <607c8d70-4283-1b55-2eac-c9f30a3a3f92@blastwave.org> <20180224.111320.668675301640295218.levitte@openssl.org> Message-ID: On 24/02/18 05:13 AM, Richard Levitte wrote: > In message <607c8d70-4283-1b55-2eac-c9f30a3a3f92 at blastwave.org> on Sat, 24 Feb 2018 00:24:34 -0500, Dennis Clarke said: > > > dclarke> Not sure why but the various scripts and test files are hell > dclarke> bent on using the perl in the system as opposed to what I > dclarke> have set in an env var PERL=/usr/local/bin/perl. > > Hmmm, if it's hell bent on anything, it's on what perl was used to run > 'Configure'. I'm not sure if you use that script directly or if you > use 'config'... Ah well ... config isn't too helpful with building a 64-bit lib : corv $ corv $ ./config Operating system: sun4u-whatever-solaris2 WARNING! If you wish to build 64-bit library, then you have to invoke './Configure solaris64-sparcv9-cc' *manually*. Using implicit seed configuration Configuring OpenSSL version 1.1.1-pre1 (0x10101001L) for solaris-sparcv9-cc Creating configdata.pm Creating Makefile NOTE: Starting with OpenSSL 1.1.1, 'Configure' doesn't display all the disabled options or the "make variables" with their values. Instead, you must use 'configdata.pm' as a script to get a display of the configuration data. For help, please do this: perl configdata.pm --help corv $ dc From appro at openssl.org Sat Feb 24 12:51:45 2018 From: appro at openssl.org (Andy Polyakov) Date: Sat, 24 Feb 2018 13:51:45 +0100 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <43ad924b-c05b-e9c0-e1cf-2178e2ae2075@blastwave.org> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> <23c20ae7-efa7-c0e9-730c-bf1df507aa71@blastwave.org> <5d624a03-998f-74a0-c957-5fee9e3cedc7@blastwave.org> <2faa10cf-888d-651d-eda5-77af1169520e@openssl.org> <43ad924b-c05b-e9c0-e1cf-2178e2ae2075@blastwave.org> Message-ID: >> As for -lm, which symbol was undefined? >> > > Undefined?????????????????????? first referenced > ?symbol???????????????????????????? in file > fabs??????????????????????????????? test/ct_test.o ??? One can only wonder where does it come from. I see no fabs anywhere... There also was remark about shell. Why? We don't aim for any specific flavour, or in other words it's expected to work with *any* Bourne-compatible shell, or in yet other words if it doesn't, then we'd rather hear about it and eliminate the dependency. From dclarke at blastwave.org Sat Feb 24 14:13:23 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Sat, 24 Feb 2018 09:13:23 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> <23c20ae7-efa7-c0e9-730c-bf1df507aa71@blastwave.org> <5d624a03-998f-74a0-c957-5fee9e3cedc7@blastwave.org> <2faa10cf-888d-651d-eda5-77af1169520e@openssl.org> <43ad924b-c05b-e9c0-e1cf-2178e2ae2075@blastwave.org> Message-ID: On 24/02/18 07:51 AM, Andy Polyakov wrote: >>> As for -lm, which symbol was undefined? >>> >> >> Undefined?????????????????????? first referenced >> ?symbol???????????????????????????? in file >> fabs??????????????????????????????? test/ct_test.o > > ??? One can only wonder where does it come from. I see no fabs anywhere... > ${LDCMD:-/opt/developerstudio12.6/bin/cc} -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -Qy -xs -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -L. -mt \ -o test/crltest test/crltest.o \ test/libtestutil.a -lcrypto -lz -lsocket -lnsl -ldl -lpthread /opt/developerstudio12.6/bin/cc -Iinclude -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -Qy -xs -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -DZLIB -DNDEBUG -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -c -o test/ct_test.o test/ct_test.c /usr/openwin/bin/makedepend -f- -o"|test/ct_test.o" -- -Iinclude -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -Qy -xs -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -DDSO_DLFCN -DHAVE_DLFCN_H -DZLIB -DNDEBUG -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -c -- test/ct_test.c \ >test/ct_test.d.tmp 2>/dev/null /usr/local/bin/perl -i -pe 's/^.*\|//; s/ \/(\\.|[^ ])*//; $_ = undef if (/: *$/ || /^(#.*| *)$/); $_.="\n" unless !defined($_) or /\R$/g;' test/ct_test.d.tmp rm -f test/ct_test ${LDCMD:-/opt/developerstudio12.6/bin/cc} -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -Qy -xs -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -L. -mt \ -o test/ct_test test/ct_test.o \ test/libtestutil.a -lcrypto -lz -lsocket -lnsl -ldl -lpthread Undefined first referenced symbol in file fabs test/ct_test.o ld: fatal: symbol referencing errors. No output written to test/ct_test gmake[1]: *** [Makefile:10579: test/ct_test] Error 2 gmake[1]: Leaving directory '/usr/local/build/openssl-1.1.1-pre1_SunOS5.10_sparcv9.002' gmake: *** [Makefile:143: all] Error 2 corv $ find . | grep "ct_test" ./test/ct_test.c ./test/ct_test.d ./test/ct_test.o corv $ corv $ grep "math\.h" ./test/ct_test.c #include corv $ From levitte at openssl.org Sat Feb 24 14:37:21 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 24 Feb 2018 15:37:21 +0100 (CET) Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <607c8d70-4283-1b55-2eac-c9f30a3a3f92@blastwave.org> <20180224.111320.668675301640295218.levitte@openssl.org> Message-ID: <20180224.153721.1452496864411978169.levitte@openssl.org> In message on Sat, 24 Feb 2018 06:14:50 -0500, Dennis Clarke said: dclarke> On 24/02/18 05:13 AM, Richard Levitte wrote: dclarke> > In message <607c8d70-4283-1b55-2eac-c9f30a3a3f92 at blastwave.org> on dclarke> > Sat, 24 Feb 2018 00:24:34 -0500, Dennis Clarke dclarke> > said: dclarke> > dclarke> Not sure why but the various scripts and test files are hell dclarke> > dclarke> bent on using the perl in the system as opposed to what I dclarke> > dclarke> have set in an env var PERL=/usr/local/bin/perl. dclarke> > Hmmm, if it's hell bent on anything, it's on what perl was used to run dclarke> > 'Configure'. I'm not sure if you use that script directly or if you dclarke> > use 'config'... the latter will certainly look at $PERL to run dclarke> dclarke> OKay ... I can try "config" however I did use "Configure" : dclarke> dclarke> corv $ ./Configure shared zlib threads solaris64-sparcv9-cc Ah, yes. And since you probably have the system perl first along your $PATH, that's the one you're gonna get registered. The workaround would be this: /usr/local/bin/perl ./Configure shared zlib threads solaris64-sparcv9-cc Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sat Feb 24 14:51:05 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 24 Feb 2018 15:51:05 +0100 (CET) Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <2faa10cf-888d-651d-eda5-77af1169520e@openssl.org> <43ad924b-c05b-e9c0-e1cf-2178e2ae2075@blastwave.org> Message-ID: <20180224.155105.1880453555927774732.levitte@openssl.org> In message on Sat, 24 Feb 2018 13:51:45 +0100, Andy Polyakov said: appro> >> As for -lm, which symbol was undefined? appro> >> appro> > appro> > Undefined?????????????????????? first referenced appro> > ?symbol???????????????????????????? in file appro> > fabs??????????????????????????????? test/ct_test.o appro> appro> ??? One can only wonder where does it come from. I see no fabs anywhere... Errrr.... : ; git grep fabs test/ct_test.c: if (!TEST_uint_le((unsigned int)fabs(difftime(time(NULL), default_time)), -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From appro at openssl.org Sat Feb 24 15:10:43 2018 From: appro at openssl.org (Andy Polyakov) Date: Sat, 24 Feb 2018 16:10:43 +0100 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> <23c20ae7-efa7-c0e9-730c-bf1df507aa71@blastwave.org> <5d624a03-998f-74a0-c957-5fee9e3cedc7@blastwave.org> <2faa10cf-888d-651d-eda5-77af1169520e@openssl.org> <43ad924b-c05b-e9c0-e1cf-2178e2ae2075@blastwave.org> Message-ID: >>>> As for -lm, which symbol was undefined? >>>> >>> >>> Undefined?????????????????????? first referenced >>> ??symbol???????????????????????????? in file >>> fabs??????????????????????????????? test/ct_test.o >> >> ??? One can only wonder where does it come from. I see no fabs >> anywhere... Ah! Missed it! There is fabs call in ct_test. I was looking for reference in binary code. On multiple platforms including Solaris x86. Question is how come it isn't a problem anywhere else. It looks like it's customarily inlined, but not here. Well, you insist on -xbuiltin=%none, so I suppose this has to be it. In such case it's on you... From appro at openssl.org Sat Feb 24 15:21:27 2018 From: appro at openssl.org (Andy Polyakov) Date: Sat, 24 Feb 2018 16:21:27 +0100 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> <23c20ae7-efa7-c0e9-730c-bf1df507aa71@blastwave.org> <5d624a03-998f-74a0-c957-5fee9e3cedc7@blastwave.org> <2faa10cf-888d-651d-eda5-77af1169520e@openssl.org> <43ad924b-c05b-e9c0-e1cf-2178e2ae2075@blastwave.org> Message-ID: <5fc83124-fa81-a5a4-9716-5cdc34a69c88@openssl.org> >>>>> As for -lm, which symbol was undefined? >>>>> >>>> >>>> Undefined?????????????????????? first referenced >>>> ??symbol???????????????????????????? in file >>>> fabs??????????????????????????????? test/ct_test.o >>> >>> ??? One can only wonder where does it come from. I see no fabs >>> anywhere... > > Ah! Missed it! There is fabs call in ct_test. I was looking for > reference in binary code. On multiple platforms including Solaris x86. > Question is how come it isn't a problem anywhere else. It looks like > it's customarily inlined, but not here. Well, you insist on > -xbuiltin=%none, so I suppose this has to be it. In such case it's on you... Well, one can probably argue that it might be appropriate to solve it anyway. And provided that this is the *only* reference to -lm, it wouldn't be inappropriate to solve it rather by casting difftime return value to integer and then passing it to abs(3). From erik at efca.com Sat Feb 24 19:13:11 2018 From: erik at efca.com (Erik Forsberg) Date: Sat, 24 Feb 2018 11:13:11 -0800 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <43ad924b-c05b-e9c0-e1cf-2178e2ae2075@blastwave.org> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <43ad924b-c05b-e9c0-e1cf-2178e2ae2075@blastwave.org> Message-ID: as that is the ONLY -lm reference and the fact its in test code, why not simply avoid using fabs(), that is so trivial here ? if (value < 0) value = -value; >-- Original Message -- > >On 24/02/18 04:47 AM, Andy Polyakov wrote: >>> So testsuite is running but this is a non-optimal debug build and only >>> on the Fujitsu sparc and not on a baseline v9 yet. See "e_flags" in the >>> ELF header below which is somewhat restrictive. >>> >>> ? e_flags:??? [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ] >> >> If "somewhat restrictive" refers to presence of EF_SPARC_SUN_US1 and >> EF_SPARC_SUN_US3 ... > > >I wasn't clear. I know exactly what causes this. I am saying that I will >have to redo everything again and get the process down to a baseline >config. > >> As for -lm, which symbol was undefined? >> > >Undefined first referenced > symbol in file >fabs test/ct_test.o > >dc >-- >openssl-users mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From erik at efca.com Sat Feb 24 19:15:49 2018 From: erik at efca.com (Erik Forsberg) Date: Sat, 24 Feb 2018 11:15:49 -0800 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> Message-ID: <109fDQTBvfyxtR2@srv.efca.com> >-- Original Message -- > >>> As for -lm, which symbol was undefined? >>> >> >> Undefined?????????????????????? first referenced >> ?symbol???????????????????????????? in file >> fabs??????????????????????????????? test/ct_test.o > >??? One can only wonder where does it come from. I see no fabs anywhere... > /* * Tests that the CT_POLICY_EVAL_CTX default time is approximately now. * Allow +-10 minutes, as it may compensate for clock skew. */ static int test_default_ct_policy_eval_ctx_time_is_now() { int success = 0; CT_POLICY_EVAL_CTX *ct_policy_ctx = CT_POLICY_EVAL_CTX_new(); const time_t default_time = CT_POLICY_EVAL_CTX_get_time(ct_policy_ctx) / 1000; const time_t time_tolerance = 600; /* 10 minutes */ if (fabs(difftime(time(NULL), default_time)) > time_tolerance) { fprintf(stderr, "Default CT_POLICY_EVAL_CTX time is not approximately now.\n"); goto end; } if (fabs(difftime(time(NULL), default_time)) > time_tolerance) { fprintf(stderr, "Default CT_POLICY_EVAL_CTX time is not approximately now.\n"); goto end; } success = 1; end: CT_POLICY_EVAL_CTX_free(ct_policy_ctx); return success; } From erik at efca.com Sat Feb 24 19:18:41 2018 From: erik at efca.com (Erik Forsberg) Date: Sat, 24 Feb 2018 11:18:41 -0800 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> Message-ID: >-- Original Message -- > >>>>> As for -lm, which symbol was undefined? >>>>> >>>> >>>> Undefined?????????????????????? first referenced >>>> ??symbol???????????????????????????? in file >>>> fabs??????????????????????????????? test/ct_test.o >>> >>> ??? One can only wonder where does it come from. I see no fabs >>> anywhere... > >Ah! Missed it! There is fabs call in ct_test. I was looking for >reference in binary code. On multiple platforms including Solaris x86. >Question is how come it isn't a problem anywhere else. It looks like >it's customarily inlined, but not here. Well, you insist on >-xbuiltin=%none, so I suppose this has to be it. In such case it's on you... Most compilers (including gcc) inlines fabs() Solaris cc does not when using -O0 -g which I use when debugging. If I remember correctly, solaris cc also inlines when using higher level of optimization but I may remember wrong. From dclarke at blastwave.org Sat Feb 24 20:21:32 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Sat, 24 Feb 2018 15:21:32 -0500 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> Message-ID: <9e30b38c-9796-3f4d-6ead-e74cb64fbd45@blastwave.org> On 24/02/18 02:18 PM, Erik Forsberg wrote: > >> -- Original Message -- >> >>>>>> As for -lm, which symbol was undefined? >>>>>> >>>>> >>>>> Undefined?????????????????????? first referenced >>>>> ??symbol???????????????????????????? in file >>>>> fabs??????????????????????????????? test/ct_test.o >>>> >>>> ??? One can only wonder where does it come from. I see no fabs >>>> anywhere... >> >> Ah! Missed it! There is fabs call in ct_test. I was looking for >> reference in binary code. On multiple platforms including Solaris x86. >> Question is how come it isn't a problem anywhere else. It looks like >> it's customarily inlined, but not here. Well, you insist on >> -xbuiltin=%none, so I suppose this has to be it. In such case it's on you... > > Most compilers (including gcc) inlines fabs() > Solaris cc does not when using -O0 -g which I use when debugging. > If I remember correctly, solaris cc also inlines when using higher level of optimization > but I may remember wrong. > I like having nice debug builds first that I can single step through if needed. The joy of fast processors and buckets of cheap memory is that I can have an entire dev type amp stack that runs just fine with debug libs everywhere and then a prod stack which is slightly more optimal. In any case, this seems to me like we are fetching a unit64_t type of number for milliseconds and should just check if it is within 600000 of some value for "now". No need for the divide by 1000 in there. Looking in ./include/openssl/ct.h we see : /* * Gets the time, in milliseconds since the Unix epoch, that will be used as the * current time when checking whether an SCT was issued in the future. * Such SCTs will fail validation, as required by RFC6962. */ uint64_t CT_POLICY_EVAL_CTX_get_time(const CT_POLICY_EVAL_CTX *ctx); OKay so it is an uint64_t for milliseconds. Perfect. So maybe just use that in line 503 : uint64_t default_time = CT_POLICY_EVAL_CTX_get_time(ct_policy_ctx); What in the name of Smokey Robinson is TEST_uint_le? Looks to be a "define" in ./test/testutil.h : # define TEST_uint_le(a, b) test_uint_le(__FILE__, __LINE__, #a, #b, a, b) uh huh ... and in turn where is test_uint_le coming from ? I don't know. No where in the tarball that is for sure. I do see it out in the world at : https://github.com/openssl/openssl/blob/master/test/test_test.c Seems like a test for "less than or equal to" for two uintXX_t things. Regardless there isn't a need for a double difftime nor a floating point fabs here. Am I missing something obvious ? dc From openssl at foocrypt.net Sun Feb 25 01:36:18 2018 From: openssl at foocrypt.net (openssl at foocrypt.net) Date: Sat, 24 Feb 2018 19:36:18 -0600 Subject: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC In-Reply-To: <23c20ae7-efa7-c0e9-730c-bf1df507aa71@blastwave.org> References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> <960E9EB9-1F99-48F3-8747-3824E1D84235@dukhovni.org> <23c20ae7-efa7-c0e9-730c-bf1df507aa71@blastwave.org> Message-ID: Morning Dennis, et al This may be off thread topic, but one thing I have noticed with the x86 openssl builds shipped by Oracle and Blastwave in the releases I have been testing FooCrypt against ( 10u11 through 11.3 ) is that openssl seems to ?HANG? when inputting a string greater than 262 characters which is quite different behavious to the Linux / macOS stock builds that accept a string of up to 522 characters. Anyone know if this is a ?feature? of the Solaris x86 compiles or is it inherent to openssl compiling on Solaris x86 ? name -a : SunOS FooCrypt 5.10 Generic_147148-26 i86pc i386 i86pc /opt/csw/bin/openssl version OpenSSL 1.0.2n 7 Dec 2017 name -a : SunOS FooCrypt 5.11 11.3 i86pc i386 i86pc /opt/csw/bin/openssl version : OpenSSL 1.0.2n 7 Dec 2017 /usr/bin/openssl version : OpenSSL 1.0.1p 9 Jul 2015 ? Regards, Mark A. Lane Cryptopocalypse NOW 01 04 2016 Volumes 0.0 NOW available through iTunes - iBooks @ https://itunes.apple.com/au/author/mark-a.-lane/id1100062966?mt=11 Cryptopocalypse NOW is the TRUE story behind the trials and tribulations encountered in creating "FooCrypt, A Tale of Cynical Cyclical Encryption." due to the Australian Government's ( led by Malcolm Turnbull ) criminalisation of encryption technologies on the 1st of April, 2016, as told by a Convicted Hacker. "FooCrypt, A Tale of Cynical Cyclical Encryption." is aimed at hardening several commonly used Symmetric Open Source Encryption methods so that they are hardened to a standard that is commonly termed 'QUANTUM ENCRYPTION'. "FooCrypt, A Tale of Cynical Cyclical Encryption." is currently under export control by the Australian Department of Defence Defence Export Controls Office due to the listing of Cryptology as a ?Dual Use? Technology as per the ?Wassenaar Arrangement? Limited Edition Collectors versions and Hard Back Editions are available via the store on http://www.foocrypt.net/ ? Mark A. Lane 1980 - 2018, All Rights Reserved. ? FooCrypt 1980 - 2018, All Rights Reserved. ? FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2018, All Rights Reserved. ? Cryptopocalypse 1980 - 2018, All Rights Reserved. On 2018-02-21 11:42, Dennis Clarke wrote: > On 21/02/18 12:11 PM, Norm Green wrote: >> On 2/21/2018 8:42 AM, Dennis Clarke wrote: >>> Pretty sure I have done builds and tests. In fact I am certain of it. >> >> If you added -xmemalign=8s to the SPARC compiler flags (as shown in >> one >> of your emails from yesterday) then you would not see the problem. >> -xmemalign=8s forces the compiler to use 8-byte alignment. > > Which is correct way to do this on sparc systems. I am digging into > the > whole build process to see what needs to be "hacked" at to get solid > and > reasonable results. The real issue is compilers. Sorry but gcc just > won't do the right things on sparc and that isn't anyones fault. > > This is where we could go down a deep dark hole. For the sake of > getting it out there we may as well just admit that the compilers that > are generally installed on Solaris systems were of the Forte flavour > way > back when little dinosaurs were still roaming the datacenters and the > cost of the license was about $3000 or so. The acquisitions and rename > of everything happened for a while there and I am surprised no one at > Sun lost their little minds and called it the Java Enterprise C > Compiler > because everything else had "Java" slapped on it. Regardless, the Forte > name went away and we then had "Sun Studio" which revved up until we > were able to compile the whole source code base with it and Solaris > "UNIX" was self hosted and self boot-strappable and time marched on. So > here we are today with Oracle Studio compilers and they are very very > good. At least on sparc they are. The concept of doing a compile for a > very specific machine class was dropped on the market way back in 1999 > or so and I think by 2002 we could target flavours of sparc v9 with the > vis instructions as well as a lot of hullabaloo about fused multiply > etc. However that was a sun4c and sun4m issue back when we needed the > optional weitek coprocessor. > > So anyways the "target" option was born out of necessity to get the > right opcodes for given sparc units. People had fights over the entire > x86 platform and Sun dropped it. Then picked it up again. Then built a > version for Itanium. Put that on a shelf and hid it. Buried it. Then > went back and released a general x86 version again. Madness. I had a > sit > down coffee with the global manager for the "solaris" product and it is > history now but the compiler tools for x86 were never the same quality > as the sparc tools. Never have been. One needs to use "fpversion" to > get the correct target and cache line options but someone at Oracle has > spilled a coffee and shuffled papers and forgot to release fpversion in > the latest flavour of the Studio compilers. I will take a look on a big > new shiney M-class machine and see what is there but I can tell you > that > the openssl binaries I build from sources are at least the same speed > or > better than the ones shipped out by Oracle. For a given specific type > of > machine and sparc target. > > > jupiter # /opt/developerstudio12.5/bin/fpversion > A SPARC-based CPU is available. > Kernel says main memory's clock rate is 1272.0 MHz. > > Sun-4 floating-point controller version 0 found. > An UltraSPARC chip is available. > > Use "-xtarget=sparc64viiplus -xcache=64/64/2:11264/256/11" > code-generation option. > > Hostid = 0xBADCAFFE. > > > A much older system may say : > > > mimas $ /opt/solarisstudio12.4/bin/fpversion > A SPARC-based CPU is available. > Kernel says CPU's clock rate is 500.0 MHz. > Kernel says main memory's clock rate is 100.0 MHz. > > Sun-4 floating-point controller version 0 found. > An UltraSPARC chip is available. > > Use "-xtarget=ultra2e -xcache=16/32/1:256/64/1" code-generation > option. > > Hostid = 0xBADCAFFE. > > > Even more bizarre and older : > > ns1_$ /opt/solarisstudio12.4/bin/fpversion > A SPARC-based CPU is available. > Kernel says CPU's clock rate is 360.0 MHz. > Kernel says main memory's clock rate is 90.0 MHz. > > Sun-4 floating-point controller version 0 found. > An UltraSPARC chip is available. > > Use "-xtarget=ultra2i -xcache=16/32/1:1024/64/1" code-generation > option. > > Hostid = 0xDEADBEEF. > > > I say "bizarre" because that is a system that uses the memory options > which were shipped on the E10k servers and those cache lines are wrong. > That machine will always report "infinite" performance from openssl > speed results and be damned if I can figure out why. Yet. > > ns1_$ /usr/local/ssl/bin/openssl speed rsa4096 > Doing 4096 bit private rsa's for 10s: 13 4096 bit private RSA's in > 0.00s > Doing 4096 bit public rsa's for 10s: 1436 4096 bit public RSA's in > 0.00s > OpenSSL 1.0.2n 7 Dec 2017 > built on: reproducible build, date unspecified > options:bn(64,32) rc4(ptr,char) des(ptr,risc1,16,int) aes(partial) > idea(int) blowfish(ptr) > compiler: /opt/solarisstudio12.4/bin/c99 -I. -I.. -I../include -KPIC > -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN > -DHAVE_DLFCN_H -Xc -g -errfmt=error -erroff=%none -xmemalign=8s > -errshort=full -xstrconst -xildoff -m64 -xnolibmil -xcode=pic32 > -xregs=no%appl -xlibmieee -ftrap=%none -xarch=sparc -mc -xs > -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO > -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -DB_ENDIAN > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM > -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM > sign verify sign/s verify/s > rsa 4096 bits 0.000000s 0.000000s inf inf > > > However the latest from Oracle claims : > > $ ls /opt/developerstudio12.6/bin/fpversion > /opt/developerstudio12.6/bin/fpversion: No such file or directory > > However it is in the manual still. > > Messy. Very. > > So as I said earlier ... this should be fun. > > Dennis From pratyush.parimal at gmail.com Mon Feb 26 01:15:33 2018 From: pratyush.parimal at gmail.com (pratyush parimal) Date: Sun, 25 Feb 2018 20:15:33 -0500 Subject: [openssl-users] Is EVP_BytesToKey() still recommended ? Message-ID: Hi everyone, I'm trying to find a way to convert a string password to an AES-256 encryption key. I came across EVP_BytesToKey(), but the man-page says at the end: "Newer applications should use a more modern algorithm such as PBKDF2 as defined in PKCS#5v2.1 and provided by PKCS5_PBKDF2_HMAC". Does this mean I shouldn't use EVP_BytesToKey(), and should instead find out how to use PBKDF2 ? Or do I need to find out how to get EVP_BytesToKey() to use PBKDF2? Any clarifications will be appreciated! -Pratyush. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Feb 26 10:08:40 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 26 Feb 2018 10:08:40 +0000 Subject: [openssl-users] Is EVP_BytesToKey() still recommended ? In-Reply-To: References: Message-ID: <4996ba70-f4a5-93a6-c157-5bde3c88b4e0@openssl.org> On 26/02/18 01:15, pratyush parimal wrote: > Hi everyone, > > I'm trying to find a way to convert a string password to an AES-256 > encryption key. I came across?EVP_BytesToKey(), but the man-page says at > the end: > > "Newer applications should use a more modern algorithm such as PBKDF2 as > defined in PKCS#5v2.1 and provided by PKCS5_PBKDF2_HMAC". > > Does this mean I shouldn't use?EVP_BytesToKey(), and should instead find > out how to use?PBKDF2 ? Or do I need to find out how to > get?EVP_BytesToKey() to use?PBKDF2? Don't use EVP_BytesToKey(). Details on the PKCS5_PBKDF2_HMAC function are here: https://www.openssl.org/docs/man1.1.0/crypto/PKCS5_PBKDF2_HMAC.html Matt From paulyang.inf at gmail.com Tue Feb 27 06:08:34 2018 From: paulyang.inf at gmail.com (Paul Yang) Date: Tue, 27 Feb 2018 14:08:34 +0800 Subject: [openssl-users] Anecdotes of OpenSSL China Tour Message-ID: Hi there, Some people may know that five then OMC members had a tour in China last September. You can find some official media articles reporting the event in Tim?s blogs: https://www.openssl.org/blog/blog/2017/09/28/china/ and https://www.openssl.org/blog/blog/2017/10/18/china/ Here comes another article depicting the tour from a different aspect - the interesting stuffs during the 7 days without business: https://paulyang.cn/2018/02/26/the-untold-story-en.html I shared this link on facebook yesterday and Rich suggested to post it to the mailing list either, thus more people could have the stories. Happy reading! Regards, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From openssl at openssl.org Tue Feb 27 14:29:24 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 27 Feb 2018 14:29:24 +0000 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 2 published Message-ID: <20180227142924.GA9892@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.1 pre release 2 (alpha) =========================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 1.1.1 is currently in alpha. OpenSSL 1.1.1 pre release 2 has now been made available. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. The alpha release is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1-pre2.tar.gz Size: 6485957 SHA1 checksum: 11be9034aa6b84eb8bfff7accc2a1a3f940deef9 SHA256 checksum: 33dbda4a90345d256942fb5316967efd90df4f2373578c7b56c90062fe21fc9c The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1-pre2.tar.gz openssl sha256 openssl-1.1.1-pre2.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJalV/kAAoJENnE0m0OYESRW3kIAJhmXNT0kBRffoJn4jK5VC/R eDd+Pv25fNBq+LaNKd1m0B0BO+cZcxw6fygxM4rrsU8vchbWmquY4HH8rCaXZ7SE iW2EsnJJR9JZk7dnhNImmct3jYhALHnabC0qrinvIYVJRWaFRmpPPOFkvVaJ3Ouy 24vQ4Np98x33fw+p/0m6r4wHZ6c5zkHMUw5W1bmGPJF6i7YkZcM8ZKpMM2svObuS 2NEZvyfqrZNiBKwtRzl2WFFOMEgk/bbDrpqUPg6Ul2iYyfyz/LGtu5O5xYGxHCbq AptoWRILpkYmpgH+2ULJWuiVb21wIWCLcgKIfmizdMOPqsO6XmgzFJOV730HEW0= =W0yX -----END PGP SIGNATURE----- From norm.green at gemtalksystems.com Tue Feb 27 20:39:47 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 27 Feb 2018 12:39:47 -0800 Subject: [openssl-users] OpenSSL 1.1.1pre2 build failure on Darwin Message-ID: <6acdd452-4b5e-1225-bb3c-b5e0243a0c93@gemtalksystems.com> With CC=cc, I get this: cc? -I. -Icrypto/include -Iinclude -g -O0 -arch x86_64 -Wall -Qunused-arguments -fPIC -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_STATIC_ENGINE -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 -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -D_REENTRANT -DL_ENDIAN -DOPENSSLDIR="\"/Volumes/orpheus3/users/normg/sslinstall/ssl\"" -DENGINESDIR="\"/Volumes/orpheus3/users/normg/sslinstall/lib/engines-1.1\"" -c -MMD -MF crypto/ec/x25519-x86_64.d.tmp -MT crypto/ec/x25519-x86_64.o -c -o crypto/ec/x25519-x86_64.o crypto/ec/x25519-x86_64.s crypto/ec/x25519-x86_64.s:164:1: error: assembler local symbol 'L$reduce51' not defined and with CC=gcc I get this similar error: CC="gcc" perl crypto/ec/asm/x25519-x86_64.pl macosx crypto/ec/x25519-x86_64.s gcc? -I. -Icrypto/include -Iinclude -g -O0 -arch x86_64 -Wall -Qunused-arguments -fPIC -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_STATIC_ENGINE -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 -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -D_REENTRANT -DL_ENDIAN -DOPENSSLDIR="\"/Volumes/orpheus3/users/normg/sslinstall/ssl\"" -DENGINESDIR="\"/Volumes/orpheus3/users/normg/sslinstall/lib/engines-1.1\"" -c -MMD -MF crypto/ec/x25519-x86_64.d.tmp -MT crypto/ec/x25519-x86_64.o -c -o crypto/ec/x25519-x86_64.o crypto/ec/x25519-x86_64.s crypto/ec/x25519-x86_64.s:187:1: error: assembler local symbol 'L$reduce51' not defined clang -cc1as: fatal error: error in backend: unsupported relocation of undefined symbol 'L$reduce51' make[1]: *** [crypto/ec/x25519-x86_64.o] Error 1 make: *** [all] Error 2 Config details: normg at orpheus>cc --version Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin13.4.0 Thread model: posix normg at orpheus>uname -a Darwin orpheus 13.4.0 Darwin Kernel Version 13.4.0: Wed Mar 18 16:20:14 PDT 2015; root:xnu-2422.115.14~1/RELEASE_X86_64 x86_64 Results from perl configdata.pm --dump: Use of uninitialized value $prefix in concatenation (.) or string at configdata.pm line 15413. Use of uninitialized value $prefix in concatenation (.) or string at configdata.pm line 15413. Use of uninitialized value $prefix in concatenation (.) or string at configdata.pm line 15413. Use of uninitialized value $prefix in concatenation (.) or string at configdata.pm line 15413. Use of uninitialized value $prefix in concatenation (.) or string at configdata.pm line 15413. Command line (with current working directory = .): ??? perl ./Configure threads shared no-zlib --prefix=/Volumes/orpheus3/users/normg/sslinstall debug-darwin64-x86_64-cc Perl information: ??? perl ??? 5.16.2 for darwin-thread-multi-2level Enabled features: ??? aria ??? asm ??? async ??? autoalginit ??? autoerrinit ??? bf ??? blake2 ??? camellia ??? capieng ??? cast ??? chacha ??? cmac ??? cms ??? comp ??? ct ??? deprecated ??? des ??? dgram ??? dh ??? dsa ??? dso ??? dtls ??? dynamic-engine ??? ec ??? ec2m ??? ecdh ??? ecdsa ??? engine ??? err ??? filenames ??? gost ??? hw(-.+)? ??? idea ??? makedepend ??? md4 ??? mdc2 ??? multiblock ??? nextprotoneg ??? ocb ??? ocsp ??? pic ??? poly1305 ??? posix-io ??? psk ??? rc2 ??? rc4 ??? rdrand ??? rfc3779 ??? rmd160 ??? scrypt ??? seed ??? shared ??? siphash ??? sm3 ??? sm4 ??? sock ??? srp ??? srtp ??? sse2 ??? ssl ??? static-engine ??? stdio ??? tests ??? threads ??? tls ??? ts ??? ui-console ??? whirlpool ??? 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??????????????? [not-linux] ??? 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 ??? ec_nistp_64_gcc_128???? [default] OPENSSL_NO_EC_NISTP_64_GCC_128 ??? 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 ??? md2???????????????????? [default]?? OPENSSL_NO_MD2 (skip crypto/md2) ??? msan??????????????????? [default]?? OPENSSL_NO_MSAN ??? rc5???????????????????? [default]?? OPENSSL_NO_RC5 (skip crypto/rc5) ??? sctp??????????????????? [default]?? OPENSSL_NO_SCTP ??? ssl-trace?????????????? [default]?? OPENSSL_NO_SSL_TRACE ??? tls13downgrade????????? [default] OPENSSL_NO_TLS13DOWNGRADE ??? ubsan?????????????????? [default]?? OPENSSL_NO_UBSAN ??? unit-test?????????????? [default]?? OPENSSL_NO_UNIT_TEST ??? weak-ssl-ciphers??????? [default] OPENSSL_NO_WEAK_SSL_CIPHERS ??? zlib??????????????????? [option] ??? zlib-dynamic??????????? [default] ??? ssl3??????????????????? [default]?? OPENSSL_NO_SSL3 ??? ssl3-method???????????? [default]?? OPENSSL_NO_SSL3_METHOD Config target attributes: ??? 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 => "", ??? ar => "ar", ??? arflags => "r", ??? 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", ??? cc => "cc", ??? cflags => "-g -O0 -arch x86_64 -Wall", ??? 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 => "-D_REENTRANT -DL_ENDIAN", ??? cpuid_asm_src => "x86_64cpuid.s", ??? cpuid_obj => "x86_64cpuid.o", ??? defines => [? ], ??? des_asm_src => "des_enc.c fcrypt_b.c", ??? des_obj => "des_enc.o fcrypt_b.o", ??? disable => [? ], ??? dso_cflags => "-fPIC", ??? dso_cxxflags => "", ??? dso_extension => ".dylib", ??? dso_lflags => "-bundle", ??? 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 => [? ], ??? exe_extension => "", ??? hashbangperl => "/usr/bin/env perl", ??? includes => [? ], ??? lflags => "", ??? 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", ??? padlock_asm_src => "e_padlock-x86_64.s", ??? padlock_obj => "e_padlock-x86_64.o", ??? perlasm_scheme => "macosx", ??? plib_lflags => "-Wl,-search_paths_first", ??? poly1305_asm_src => "poly1305-x86_64.s", ??? poly1305_obj => "poly1305-x86_64.o", ??? ranlib => "ranlib -c", ??? rc => "windres", ??? 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_defines => [? ], ??? shared_extension => ".\$(SHLIB_VERSION_NUMBER).dylib", ??? shared_extension_simple => ".dylib", ??? shared_ldflag => "-dynamiclib -current_version \$(SHLIB_VERSION_NUMBER) -compatibility_version \$(SHLIB_VERSION_NUMBER)", ??? shared_rcflag => "", ??? shared_sonameflag => "-install_name \$(INSTALLTOP)/\$(LIBDIR)/", ??? shared_target => "darwin-shared", ??? sys_id => "MACOSX", ??? 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 = gcc ??? CFLAGS = ??? CPP = ??? CPPDEFINES = ??? CPPFLAGS = ??? CPPINCLUDES = ??? CROSS_COMPILE = ??? CXX = ??? CXXFLAGS = ??? HASHBANGPERL = ??? LD = gcc ??? LDFLAGS = ??? LDLIBS = ??? MT = ??? MTFLAGS = ??? OPENSSL_LOCAL_CONFIG_DIR = ??? PERL = perl ??? RANLIB = ??? RC = ??? RCFLAGS = ??? RM = ??? WINDRES = Makevars: ??? AR????????????? = ar ??? ARFLAGS???????? = r ??? CC????????????? = gcc ??? CFLAGS????????? = -g -O0 -arch x86_64 -Wall -Qunused-arguments ??? CPPDEFINES????? = DSO_DLFCN HAVE_DLFCN_H OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_CPUID_OBJ OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM X25519_ASM PADLOCK_ASM POLY1305_ASM ??? CPPFLAGS??????? = -D_REENTRANT -DL_ENDIAN ??? CPPINCLUDES???? = ??? CXXFLAGS??????? = ??? HASHBANGPERL??? = perl ??? LD????????????? = gcc ??? LDFLAGS???????? = ??? LDLIBS????????? = ??? RANLIB????????? = ranlib -c ??? RC????????????? = windres 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/unix-Makefile.tmpl ??? Configurations/common.tmpl From levitte at openssl.org Tue Feb 27 20:50:00 2018 From: levitte at openssl.org (Richard Levitte) Date: Tue, 27 Feb 2018 21:50:00 +0100 (CET) Subject: [openssl-users] OpenSSL 1.1.1pre2 build failure on Darwin In-Reply-To: <6acdd452-4b5e-1225-bb3c-b5e0243a0c93@gemtalksystems.com> References: <6acdd452-4b5e-1225-bb3c-b5e0243a0c93@gemtalksystems.com> Message-ID: <20180227.215000.2017932839143938744.levitte@openssl.org> I fixes got merged about half an hour ago: https://github.com/openssl/openssl/pull/5472 Cheers, Richard In message <6acdd452-4b5e-1225-bb3c-b5e0243a0c93 at gemtalksystems.com> on Tue, 27 Feb 2018 12:39:47 -0800, Norm Green said: norm.green> With CC=cc, I get this: norm.green> norm.green> cc? -I. -Icrypto/include -Iinclude -g -O0 -arch x86_64 -Wall norm.green> -Qunused-arguments -fPIC -DDSO_DLFCN -DHAVE_DLFCN_H norm.green> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ norm.green> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 norm.green> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM norm.green> -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM norm.green> -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM norm.green> -D_REENTRANT -DL_ENDIAN norm.green> -DOPENSSLDIR="\"/Volumes/orpheus3/users/normg/sslinstall/ssl\"" norm.green> -DENGINESDIR="\"/Volumes/orpheus3/users/normg/sslinstall/lib/engines-1.1\"" norm.green> -c -MMD -MF crypto/ec/x25519-x86_64.d.tmp -MT norm.green> crypto/ec/x25519-x86_64.o -c -o crypto/ec/x25519-x86_64.o norm.green> crypto/ec/x25519-x86_64.s norm.green> crypto/ec/x25519-x86_64.s:164:1: error: assembler local symbol norm.green> 'L$reduce51' not defined norm.green> norm.green> and with CC=gcc I get this similar error: norm.green> norm.green> norm.green> CC="gcc" perl crypto/ec/asm/x25519-x86_64.pl macosx norm.green> crypto/ec/x25519-x86_64.s norm.green> gcc? -I. -Icrypto/include -Iinclude -g -O0 -arch x86_64 -Wall norm.green> -Qunused-arguments -fPIC -DDSO_DLFCN -DHAVE_DLFCN_H norm.green> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ norm.green> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 norm.green> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM norm.green> -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM norm.green> -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM norm.green> -D_REENTRANT -DL_ENDIAN norm.green> -DOPENSSLDIR="\"/Volumes/orpheus3/users/normg/sslinstall/ssl\"" norm.green> -DENGINESDIR="\"/Volumes/orpheus3/users/normg/sslinstall/lib/engines-1.1\"" norm.green> -c -MMD -MF crypto/ec/x25519-x86_64.d.tmp -MT norm.green> crypto/ec/x25519-x86_64.o -c -o crypto/ec/x25519-x86_64.o norm.green> crypto/ec/x25519-x86_64.s norm.green> crypto/ec/x25519-x86_64.s:187:1: error: assembler local symbol norm.green> 'L$reduce51' not defined norm.green> clang -cc1as: fatal error: error in backend: unsupported relocation of norm.green> undefined symbol 'L$reduce51' norm.green> make[1]: *** [crypto/ec/x25519-x86_64.o] Error 1 norm.green> make: *** [all] Error 2 norm.green> norm.green> Config details: norm.green> norm.green> norm.green> normg at orpheus>cc --version norm.green> Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) norm.green> Target: x86_64-apple-darwin13.4.0 norm.green> Thread model: posix norm.green> norm.green> normg at orpheus>uname -a norm.green> Darwin orpheus 13.4.0 Darwin Kernel Version 13.4.0: Wed Mar 18 norm.green> 16:20:14 PDT 2015; root:xnu-2422.115.14~1/RELEASE_X86_64 x86_64 norm.green> norm.green> norm.green> Results from perl configdata.pm --dump: norm.green> norm.green> norm.green> Use of uninitialized value $prefix in concatenation (.) or string at norm.green> configdata.pm line 15413. norm.green> Use of uninitialized value $prefix in concatenation (.) or string at norm.green> configdata.pm line 15413. norm.green> Use of uninitialized value $prefix in concatenation (.) or string at norm.green> configdata.pm line 15413. norm.green> Use of uninitialized value $prefix in concatenation (.) or string at norm.green> configdata.pm line 15413. norm.green> Use of uninitialized value $prefix in concatenation (.) or string at norm.green> configdata.pm line 15413. norm.green> norm.green> Command line (with current working directory = .): norm.green> norm.green> ??? perl ./Configure threads shared no-zlib norm.green> --prefix=/Volumes/orpheus3/users/normg/sslinstall norm.green> debug-darwin64-x86_64-cc norm.green> norm.green> Perl information: norm.green> norm.green> ??? perl norm.green> ??? 5.16.2 for darwin-thread-multi-2level norm.green> norm.green> Enabled features: norm.green> norm.green> ??? aria norm.green> ??? asm norm.green> ??? async norm.green> ??? autoalginit norm.green> ??? autoerrinit norm.green> ??? bf norm.green> ??? blake2 norm.green> ??? camellia norm.green> ??? capieng norm.green> ??? cast norm.green> ??? chacha norm.green> ??? cmac norm.green> ??? cms norm.green> ??? comp norm.green> ??? ct norm.green> ??? deprecated norm.green> ??? des norm.green> ??? dgram norm.green> ??? dh norm.green> ??? dsa norm.green> ??? dso norm.green> ??? dtls norm.green> ??? dynamic-engine norm.green> ??? ec norm.green> ??? ec2m norm.green> ??? ecdh norm.green> ??? ecdsa norm.green> ??? engine norm.green> ??? err norm.green> ??? filenames norm.green> ??? gost norm.green> ??? hw(-.+)? norm.green> ??? idea norm.green> ??? makedepend norm.green> ??? md4 norm.green> ??? mdc2 norm.green> ??? multiblock norm.green> ??? nextprotoneg norm.green> ??? ocb norm.green> ??? ocsp norm.green> ??? pic norm.green> ??? poly1305 norm.green> ??? posix-io norm.green> ??? psk norm.green> ??? rc2 norm.green> ??? rc4 norm.green> ??? rdrand norm.green> ??? rfc3779 norm.green> ??? rmd160 norm.green> ??? scrypt norm.green> ??? seed norm.green> ??? shared norm.green> ??? siphash norm.green> ??? sm3 norm.green> ??? sm4 norm.green> ??? sock norm.green> ??? srp norm.green> ??? srtp norm.green> ??? sse2 norm.green> ??? ssl norm.green> ??? static-engine norm.green> ??? stdio norm.green> ??? tests norm.green> ??? threads norm.green> ??? tls norm.green> ??? ts norm.green> ??? ui-console norm.green> ??? whirlpool norm.green> ??? tls1 norm.green> ??? tls1-method norm.green> ??? tls1_1 norm.green> ??? tls1_1-method norm.green> ??? tls1_2 norm.green> ??? tls1_2-method norm.green> ??? tls1_3 norm.green> ??? dtls1 norm.green> ??? dtls1-method norm.green> ??? dtls1_2 norm.green> ??? dtls1_2-method norm.green> norm.green> Disabled features: norm.green> norm.green> ??? afalgeng??????????????? [not-linux] norm.green> ??? asan??????????????????? [default]?? OPENSSL_NO_ASAN norm.green> ??? crypto-mdebug?????????? [default]?? OPENSSL_NO_CRYPTO_MDEBUG norm.green> ??? crypto-mdebug-backtrace [default] norm.green> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE norm.green> ??? devcryptoeng??????????? [default]?? OPENSSL_NO_DEVCRYPTOENG norm.green> ??? ec_nistp_64_gcc_128???? [default] OPENSSL_NO_EC_NISTP_64_GCC_128 norm.green> ??? egd???????????????????? [default]?? OPENSSL_NO_EGD norm.green> ??? external-tests????????? [default] OPENSSL_NO_EXTERNAL_TESTS norm.green> ??? fuzz-libfuzzer????????? [default] OPENSSL_NO_FUZZ_LIBFUZZER norm.green> ??? fuzz-afl??????????????? [default]?? OPENSSL_NO_FUZZ_AFL norm.green> ??? heartbeats????????????? [default]?? OPENSSL_NO_HEARTBEATS norm.green> ??? md2???????????????????? [default]?? OPENSSL_NO_MD2 (skip norm.green> crypto/md2) norm.green> ??? msan??????????????????? [default]?? OPENSSL_NO_MSAN norm.green> ??? rc5???????????????????? [default]?? OPENSSL_NO_RC5 (skip norm.green> crypto/rc5) norm.green> ??? sctp??????????????????? [default]?? OPENSSL_NO_SCTP norm.green> ??? ssl-trace?????????????? [default]?? OPENSSL_NO_SSL_TRACE norm.green> ??? tls13downgrade????????? [default] OPENSSL_NO_TLS13DOWNGRADE norm.green> ??? ubsan?????????????????? [default]?? OPENSSL_NO_UBSAN norm.green> ??? unit-test?????????????? [default]?? OPENSSL_NO_UNIT_TEST norm.green> ??? weak-ssl-ciphers??????? [default] OPENSSL_NO_WEAK_SSL_CIPHERS norm.green> ??? zlib??????????????????? [option] norm.green> ??? zlib-dynamic??????????? [default] norm.green> ??? ssl3??????????????????? [default]?? OPENSSL_NO_SSL3 norm.green> ??? ssl3-method???????????? [default]?? OPENSSL_NO_SSL3_METHOD norm.green> norm.green> Config target attributes: norm.green> norm.green> ??? aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s norm.green> aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s norm.green> aesni-mb-x86_64.s", norm.green> ??? aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o norm.green> aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o norm.green> aesni-mb-x86_64.o", norm.green> ??? apps_aux_src => "", norm.green> ??? apps_init_src => "", norm.green> ??? apps_obj => "", norm.green> ??? ar => "ar", norm.green> ??? arflags => "r", norm.green> ??? bf_asm_src => "bf_enc.c", norm.green> ??? bf_obj => "bf_enc.o", norm.green> ??? bn_asm_src => "asm/x86_64-gcc.c x86_64-mont.s x86_64-mont5.s norm.green> x86_64-gf2m.s rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s", norm.green> ??? bn_obj => "asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o norm.green> x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o", norm.green> ??? bn_ops => "SIXTY_FOUR_BIT_LONG", norm.green> ??? build_file => "Makefile", norm.green> ??? build_scheme => [ "unified", "unix" ], norm.green> ??? cast_asm_src => "c_enc.c", norm.green> ??? cast_obj => "c_enc.o", norm.green> ??? cc => "cc", norm.green> ??? cflags => "-g -O0 -arch x86_64 -Wall", norm.green> ??? chacha_asm_src => "chacha-x86_64.s", norm.green> ??? chacha_obj => "chacha-x86_64.o", norm.green> ??? cmll_asm_src => "cmll-x86_64.s cmll_misc.c", norm.green> ??? cmll_obj => "cmll-x86_64.o cmll_misc.o", norm.green> ??? cppflags => "-D_REENTRANT -DL_ENDIAN", norm.green> ??? cpuid_asm_src => "x86_64cpuid.s", norm.green> ??? cpuid_obj => "x86_64cpuid.o", norm.green> ??? defines => [? ], norm.green> ??? des_asm_src => "des_enc.c fcrypt_b.c", norm.green> ??? des_obj => "des_enc.o fcrypt_b.o", norm.green> ??? disable => [? ], norm.green> ??? dso_cflags => "-fPIC", norm.green> ??? dso_cxxflags => "", norm.green> ??? dso_extension => ".dylib", norm.green> ??? dso_lflags => "-bundle", norm.green> ??? dso_scheme => "DLFCN", norm.green> ??? ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s norm.green> x25519-x86_64.s", norm.green> ??? ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o", norm.green> ??? enable => [? ], norm.green> ??? exe_extension => "", norm.green> ??? hashbangperl => "/usr/bin/env perl", norm.green> ??? includes => [? ], norm.green> ??? lflags => "", norm.green> ??? md5_asm_src => "md5-x86_64.s", norm.green> ??? md5_obj => "md5-x86_64.o", norm.green> ??? modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s", norm.green> ??? modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o", norm.green> ??? padlock_asm_src => "e_padlock-x86_64.s", norm.green> ??? padlock_obj => "e_padlock-x86_64.o", norm.green> ??? perlasm_scheme => "macosx", norm.green> ??? plib_lflags => "-Wl,-search_paths_first", norm.green> ??? poly1305_asm_src => "poly1305-x86_64.s", norm.green> ??? poly1305_obj => "poly1305-x86_64.o", norm.green> ??? ranlib => "ranlib -c", norm.green> ??? rc => "windres", norm.green> ??? rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s", norm.green> ??? rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o", norm.green> ??? rc5_asm_src => "rc5_enc.c", norm.green> ??? rc5_obj => "rc5_enc.o", norm.green> ??? rmd160_asm_src => "", norm.green> ??? rmd160_obj => "", norm.green> ??? sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s norm.green> sha1-mb-x86_64.s sha256-mb-x86_64.s", norm.green> ??? sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o norm.green> sha1-mb-x86_64.o sha256-mb-x86_64.o", norm.green> ??? shared_cflag => "-fPIC", norm.green> ??? shared_defines => [? ], norm.green> ??? shared_extension => ".\$(SHLIB_VERSION_NUMBER).dylib", norm.green> ??? shared_extension_simple => ".dylib", norm.green> ??? shared_ldflag => "-dynamiclib -current_version norm.green> \$(SHLIB_VERSION_NUMBER) -compatibility_version norm.green> \$(SHLIB_VERSION_NUMBER)", norm.green> ??? shared_rcflag => "", norm.green> ??? shared_sonameflag => "-install_name \$(INSTALLTOP)/\$(LIBDIR)/", norm.green> ??? shared_target => "darwin-shared", norm.green> ??? sys_id => "MACOSX", norm.green> ??? thread_defines => [? ], norm.green> ??? thread_scheme => "pthreads", norm.green> ??? unistd => "", norm.green> ??? uplink_aux_src => "", norm.green> ??? uplink_obj => "", norm.green> ??? wp_asm_src => "wp-x86_64.s", norm.green> ??? wp_obj => "wp-x86_64.o", norm.green> norm.green> Recorded environment: norm.green> norm.green> ??? AR = norm.green> ??? ARFLAGS = norm.green> ??? AS = norm.green> ??? ASFLAGS = norm.green> ??? BUILDFILE = norm.green> ??? CC = gcc norm.green> ??? CFLAGS = norm.green> ??? CPP = norm.green> ??? CPPDEFINES = norm.green> ??? CPPFLAGS = norm.green> ??? CPPINCLUDES = norm.green> ??? CROSS_COMPILE = norm.green> ??? CXX = norm.green> ??? CXXFLAGS = norm.green> ??? HASHBANGPERL = norm.green> ??? LD = gcc norm.green> ??? LDFLAGS = norm.green> ??? LDLIBS = norm.green> ??? MT = norm.green> ??? MTFLAGS = norm.green> ??? OPENSSL_LOCAL_CONFIG_DIR = norm.green> ??? PERL = perl norm.green> ??? RANLIB = norm.green> ??? RC = norm.green> ??? RCFLAGS = norm.green> ??? RM = norm.green> ??? WINDRES = norm.green> norm.green> Makevars: norm.green> norm.green> ??? AR????????????? = ar norm.green> ??? ARFLAGS???????? = r norm.green> ??? CC????????????? = gcc norm.green> ??? CFLAGS????????? = -g -O0 -arch x86_64 -Wall -Qunused-arguments norm.green> ??? CPPDEFINES????? = DSO_DLFCN HAVE_DLFCN_H OPENSSL_NO_STATIC_ENGINE norm.green> OPENSSL_PIC OPENSSL_CPUID_OBJ OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT norm.green> OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM norm.green> SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM norm.green> ECP_NISTZ256_ASM X25519_ASM PADLOCK_ASM POLY1305_ASM norm.green> ??? CPPFLAGS??????? = -D_REENTRANT -DL_ENDIAN norm.green> ??? CPPINCLUDES???? = norm.green> ??? CXXFLAGS??????? = norm.green> ??? HASHBANGPERL??? = perl norm.green> ??? LD????????????? = gcc norm.green> ??? LDFLAGS???????? = norm.green> ??? LDLIBS????????? = norm.green> ??? RANLIB????????? = ranlib -c norm.green> ??? RC????????????? = windres norm.green> norm.green> NOTE: These variables only represent the configuration view. The build norm.green> file norm.green> template may have processed these variables further, please have a norm.green> look at the norm.green> build file for more exact data: norm.green> ??? Makefile norm.green> norm.green> build file: norm.green> norm.green> ??? Makefile norm.green> norm.green> build file templates: norm.green> norm.green> ??? Configurations/unix-Makefile.tmpl norm.green> ??? Configurations/common.tmpl norm.green> norm.green> From norm.green at gemtalksystems.com Tue Feb 27 21:58:04 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Tue, 27 Feb 2018 13:58:04 -0800 Subject: [openssl-users] OpenSSL 1.1.1pre2 build failure on Darwin In-Reply-To: <20180227.215000.2017932839143938744.levitte@openssl.org> References: <6acdd452-4b5e-1225-bb3c-b5e0243a0c93@gemtalksystems.com> <20180227.215000.2017932839143938744.levitte@openssl.org> Message-ID: <8570ed9e-8487-7dfa-894c-d077381f23e8@gemtalksystems.com> Thank you Richard, that seems to fix it. Norm On 2/27/18 12:50, Richard Levitte wrote: > I fixes got merged about half an hour ago: > > https://github.com/openssl/openssl/pull/5472 > > Cheers, > Richard > > In message <6acdd452-4b5e-1225-bb3c-b5e0243a0c93 at gemtalksystems.com> on Tue, 27 Feb 2018 12:39:47 -0800, Norm Green said: > > norm.green> With CC=cc, I get this: > norm.green> > norm.green> cc? -I. -Icrypto/include -Iinclude -g -O0 -arch x86_64 -Wall > norm.green> -Qunused-arguments -fPIC -DDSO_DLFCN -DHAVE_DLFCN_H > norm.green> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ > norm.green> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > norm.green> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM > norm.green> -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM > norm.green> -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM > norm.green> -D_REENTRANT -DL_ENDIAN > norm.green> -DOPENSSLDIR="\"/Volumes/orpheus3/users/normg/sslinstall/ssl\"" > norm.green> -DENGINESDIR="\"/Volumes/orpheus3/users/normg/sslinstall/lib/engines-1.1\"" > norm.green> -c -MMD -MF crypto/ec/x25519-x86_64.d.tmp -MT > norm.green> crypto/ec/x25519-x86_64.o -c -o crypto/ec/x25519-x86_64.o > norm.green> crypto/ec/x25519-x86_64.s > norm.green> crypto/ec/x25519-x86_64.s:164:1: error: assembler local symbol > norm.green> 'L$reduce51' not defined > norm.green> > norm.green> and with CC=gcc I get this similar error: > norm.green> > norm.green> > norm.green> CC="gcc" perl crypto/ec/asm/x25519-x86_64.pl macosx > norm.green> crypto/ec/x25519-x86_64.s > norm.green> gcc? -I. -Icrypto/include -Iinclude -g -O0 -arch x86_64 -Wall > norm.green> -Qunused-arguments -fPIC -DDSO_DLFCN -DHAVE_DLFCN_H > norm.green> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ > norm.green> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > norm.green> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM > norm.green> -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM > norm.green> -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM > norm.green> -D_REENTRANT -DL_ENDIAN > norm.green> -DOPENSSLDIR="\"/Volumes/orpheus3/users/normg/sslinstall/ssl\"" > norm.green> -DENGINESDIR="\"/Volumes/orpheus3/users/normg/sslinstall/lib/engines-1.1\"" > norm.green> -c -MMD -MF crypto/ec/x25519-x86_64.d.tmp -MT > norm.green> crypto/ec/x25519-x86_64.o -c -o crypto/ec/x25519-x86_64.o > norm.green> crypto/ec/x25519-x86_64.s > norm.green> crypto/ec/x25519-x86_64.s:187:1: error: assembler local symbol > norm.green> 'L$reduce51' not defined > norm.green> clang -cc1as: fatal error: error in backend: unsupported relocation of > norm.green> undefined symbol 'L$reduce51' > norm.green> make[1]: *** [crypto/ec/x25519-x86_64.o] Error 1 > norm.green> make: *** [all] Error 2 > norm.green> > norm.green> Config details: > norm.green> > norm.green> > norm.green> normg at orpheus>cc --version > norm.green> Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) > norm.green> Target: x86_64-apple-darwin13.4.0 > norm.green> Thread model: posix > norm.green> > norm.green> normg at orpheus>uname -a > norm.green> Darwin orpheus 13.4.0 Darwin Kernel Version 13.4.0: Wed Mar 18 > norm.green> 16:20:14 PDT 2015; root:xnu-2422.115.14~1/RELEASE_X86_64 x86_64 > norm.green> > norm.green> > norm.green> Results from perl configdata.pm --dump: > norm.green> > norm.green> > norm.green> Use of uninitialized value $prefix in concatenation (.) or string at > norm.green> configdata.pm line 15413. > norm.green> Use of uninitialized value $prefix in concatenation (.) or string at > norm.green> configdata.pm line 15413. > norm.green> Use of uninitialized value $prefix in concatenation (.) or string at > norm.green> configdata.pm line 15413. > norm.green> Use of uninitialized value $prefix in concatenation (.) or string at > norm.green> configdata.pm line 15413. > norm.green> Use of uninitialized value $prefix in concatenation (.) or string at > norm.green> configdata.pm line 15413. > norm.green> > norm.green> Command line (with current working directory = .): > norm.green> > norm.green> ??? perl ./Configure threads shared no-zlib > norm.green> --prefix=/Volumes/orpheus3/users/normg/sslinstall > norm.green> debug-darwin64-x86_64-cc > norm.green> > norm.green> Perl information: > norm.green> > norm.green> ??? perl > norm.green> ??? 5.16.2 for darwin-thread-multi-2level > norm.green> > norm.green> Enabled features: > norm.green> > norm.green> ??? aria > norm.green> ??? asm > norm.green> ??? async > norm.green> ??? autoalginit > norm.green> ??? autoerrinit > norm.green> ??? bf > norm.green> ??? blake2 > norm.green> ??? camellia > norm.green> ??? capieng > norm.green> ??? cast > norm.green> ??? chacha > norm.green> ??? cmac > norm.green> ??? cms > norm.green> ??? comp > norm.green> ??? ct > norm.green> ??? deprecated > norm.green> ??? des > norm.green> ??? dgram > norm.green> ??? dh > norm.green> ??? dsa > norm.green> ??? dso > norm.green> ??? dtls > norm.green> ??? dynamic-engine > norm.green> ??? ec > norm.green> ??? ec2m > norm.green> ??? ecdh > norm.green> ??? ecdsa > norm.green> ??? engine > norm.green> ??? err > norm.green> ??? filenames > norm.green> ??? gost > norm.green> ??? hw(-.+)? > norm.green> ??? idea > norm.green> ??? makedepend > norm.green> ??? md4 > norm.green> ??? mdc2 > norm.green> ??? multiblock > norm.green> ??? nextprotoneg > norm.green> ??? ocb > norm.green> ??? ocsp > norm.green> ??? pic > norm.green> ??? poly1305 > norm.green> ??? posix-io > norm.green> ??? psk > norm.green> ??? rc2 > norm.green> ??? rc4 > norm.green> ??? rdrand > norm.green> ??? rfc3779 > norm.green> ??? rmd160 > norm.green> ??? scrypt > norm.green> ??? seed > norm.green> ??? shared > norm.green> ??? siphash > norm.green> ??? sm3 > norm.green> ??? sm4 > norm.green> ??? sock > norm.green> ??? srp > norm.green> ??? srtp > norm.green> ??? sse2 > norm.green> ??? ssl > norm.green> ??? static-engine > norm.green> ??? stdio > norm.green> ??? tests > norm.green> ??? threads > norm.green> ??? tls > norm.green> ??? ts > norm.green> ??? ui-console > norm.green> ??? whirlpool > norm.green> ??? tls1 > norm.green> ??? tls1-method > norm.green> ??? tls1_1 > norm.green> ??? tls1_1-method > norm.green> ??? tls1_2 > norm.green> ??? tls1_2-method > norm.green> ??? tls1_3 > norm.green> ??? dtls1 > norm.green> ??? dtls1-method > norm.green> ??? dtls1_2 > norm.green> ??? dtls1_2-method > norm.green> > norm.green> Disabled features: > norm.green> > norm.green> ??? afalgeng??????????????? [not-linux] > norm.green> ??? asan??????????????????? [default]?? OPENSSL_NO_ASAN > norm.green> ??? crypto-mdebug?????????? [default]?? OPENSSL_NO_CRYPTO_MDEBUG > norm.green> ??? crypto-mdebug-backtrace [default] > norm.green> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE > norm.green> ??? devcryptoeng??????????? [default]?? OPENSSL_NO_DEVCRYPTOENG > norm.green> ??? ec_nistp_64_gcc_128???? [default] OPENSSL_NO_EC_NISTP_64_GCC_128 > norm.green> ??? egd???????????????????? [default]?? OPENSSL_NO_EGD > norm.green> ??? external-tests????????? [default] OPENSSL_NO_EXTERNAL_TESTS > norm.green> ??? fuzz-libfuzzer????????? [default] OPENSSL_NO_FUZZ_LIBFUZZER > norm.green> ??? fuzz-afl??????????????? [default]?? OPENSSL_NO_FUZZ_AFL > norm.green> ??? heartbeats????????????? [default]?? OPENSSL_NO_HEARTBEATS > norm.green> ??? md2???????????????????? [default]?? OPENSSL_NO_MD2 (skip > norm.green> crypto/md2) > norm.green> ??? msan??????????????????? [default]?? OPENSSL_NO_MSAN > norm.green> ??? rc5???????????????????? [default]?? OPENSSL_NO_RC5 (skip > norm.green> crypto/rc5) > norm.green> ??? sctp??????????????????? [default]?? OPENSSL_NO_SCTP > norm.green> ??? ssl-trace?????????????? [default]?? OPENSSL_NO_SSL_TRACE > norm.green> ??? tls13downgrade????????? [default] OPENSSL_NO_TLS13DOWNGRADE > norm.green> ??? ubsan?????????????????? [default]?? OPENSSL_NO_UBSAN > norm.green> ??? unit-test?????????????? [default]?? OPENSSL_NO_UNIT_TEST > norm.green> ??? weak-ssl-ciphers??????? [default] OPENSSL_NO_WEAK_SSL_CIPHERS > norm.green> ??? zlib??????????????????? [option] > norm.green> ??? zlib-dynamic??????????? [default] > norm.green> ??? ssl3??????????????????? [default]?? OPENSSL_NO_SSL3 > norm.green> ??? ssl3-method???????????? [default]?? OPENSSL_NO_SSL3_METHOD > norm.green> > norm.green> Config target attributes: > norm.green> > norm.green> ??? aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s > norm.green> aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s > norm.green> aesni-mb-x86_64.s", > norm.green> ??? aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o > norm.green> aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o > norm.green> aesni-mb-x86_64.o", > norm.green> ??? apps_aux_src => "", > norm.green> ??? apps_init_src => "", > norm.green> ??? apps_obj => "", > norm.green> ??? ar => "ar", > norm.green> ??? arflags => "r", > norm.green> ??? bf_asm_src => "bf_enc.c", > norm.green> ??? bf_obj => "bf_enc.o", > norm.green> ??? bn_asm_src => "asm/x86_64-gcc.c x86_64-mont.s x86_64-mont5.s > norm.green> x86_64-gf2m.s rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s", > norm.green> ??? bn_obj => "asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o > norm.green> x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o", > norm.green> ??? bn_ops => "SIXTY_FOUR_BIT_LONG", > norm.green> ??? build_file => "Makefile", > norm.green> ??? build_scheme => [ "unified", "unix" ], > norm.green> ??? cast_asm_src => "c_enc.c", > norm.green> ??? cast_obj => "c_enc.o", > norm.green> ??? cc => "cc", > norm.green> ??? cflags => "-g -O0 -arch x86_64 -Wall", > norm.green> ??? chacha_asm_src => "chacha-x86_64.s", > norm.green> ??? chacha_obj => "chacha-x86_64.o", > norm.green> ??? cmll_asm_src => "cmll-x86_64.s cmll_misc.c", > norm.green> ??? cmll_obj => "cmll-x86_64.o cmll_misc.o", > norm.green> ??? cppflags => "-D_REENTRANT -DL_ENDIAN", > norm.green> ??? cpuid_asm_src => "x86_64cpuid.s", > norm.green> ??? cpuid_obj => "x86_64cpuid.o", > norm.green> ??? defines => [? ], > norm.green> ??? des_asm_src => "des_enc.c fcrypt_b.c", > norm.green> ??? des_obj => "des_enc.o fcrypt_b.o", > norm.green> ??? disable => [? ], > norm.green> ??? dso_cflags => "-fPIC", > norm.green> ??? dso_cxxflags => "", > norm.green> ??? dso_extension => ".dylib", > norm.green> ??? dso_lflags => "-bundle", > norm.green> ??? dso_scheme => "DLFCN", > norm.green> ??? ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s > norm.green> x25519-x86_64.s", > norm.green> ??? ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o", > norm.green> ??? enable => [? ], > norm.green> ??? exe_extension => "", > norm.green> ??? hashbangperl => "/usr/bin/env perl", > norm.green> ??? includes => [? ], > norm.green> ??? lflags => "", > norm.green> ??? md5_asm_src => "md5-x86_64.s", > norm.green> ??? md5_obj => "md5-x86_64.o", > norm.green> ??? modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s", > norm.green> ??? modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o", > norm.green> ??? padlock_asm_src => "e_padlock-x86_64.s", > norm.green> ??? padlock_obj => "e_padlock-x86_64.o", > norm.green> ??? perlasm_scheme => "macosx", > norm.green> ??? plib_lflags => "-Wl,-search_paths_first", > norm.green> ??? poly1305_asm_src => "poly1305-x86_64.s", > norm.green> ??? poly1305_obj => "poly1305-x86_64.o", > norm.green> ??? ranlib => "ranlib -c", > norm.green> ??? rc => "windres", > norm.green> ??? rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s", > norm.green> ??? rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o", > norm.green> ??? rc5_asm_src => "rc5_enc.c", > norm.green> ??? rc5_obj => "rc5_enc.o", > norm.green> ??? rmd160_asm_src => "", > norm.green> ??? rmd160_obj => "", > norm.green> ??? sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s > norm.green> sha1-mb-x86_64.s sha256-mb-x86_64.s", > norm.green> ??? sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o > norm.green> sha1-mb-x86_64.o sha256-mb-x86_64.o", > norm.green> ??? shared_cflag => "-fPIC", > norm.green> ??? shared_defines => [? ], > norm.green> ??? shared_extension => ".\$(SHLIB_VERSION_NUMBER).dylib", > norm.green> ??? shared_extension_simple => ".dylib", > norm.green> ??? shared_ldflag => "-dynamiclib -current_version > norm.green> \$(SHLIB_VERSION_NUMBER) -compatibility_version > norm.green> \$(SHLIB_VERSION_NUMBER)", > norm.green> ??? shared_rcflag => "", > norm.green> ??? shared_sonameflag => "-install_name \$(INSTALLTOP)/\$(LIBDIR)/", > norm.green> ??? shared_target => "darwin-shared", > norm.green> ??? sys_id => "MACOSX", > norm.green> ??? thread_defines => [? ], > norm.green> ??? thread_scheme => "pthreads", > norm.green> ??? unistd => "", > norm.green> ??? uplink_aux_src => "", > norm.green> ??? uplink_obj => "", > norm.green> ??? wp_asm_src => "wp-x86_64.s", > norm.green> ??? wp_obj => "wp-x86_64.o", > norm.green> > norm.green> Recorded environment: > norm.green> > norm.green> ??? AR = > norm.green> ??? ARFLAGS = > norm.green> ??? AS = > norm.green> ??? ASFLAGS = > norm.green> ??? BUILDFILE = > norm.green> ??? CC = gcc > norm.green> ??? CFLAGS = > norm.green> ??? CPP = > norm.green> ??? CPPDEFINES = > norm.green> ??? CPPFLAGS = > norm.green> ??? CPPINCLUDES = > norm.green> ??? CROSS_COMPILE = > norm.green> ??? CXX = > norm.green> ??? CXXFLAGS = > norm.green> ??? HASHBANGPERL = > norm.green> ??? LD = gcc > norm.green> ??? LDFLAGS = > norm.green> ??? LDLIBS = > norm.green> ??? MT = > norm.green> ??? MTFLAGS = > norm.green> ??? OPENSSL_LOCAL_CONFIG_DIR = > norm.green> ??? PERL = perl > norm.green> ??? RANLIB = > norm.green> ??? RC = > norm.green> ??? RCFLAGS = > norm.green> ??? RM = > norm.green> ??? WINDRES = > norm.green> > norm.green> Makevars: > norm.green> > norm.green> ??? AR????????????? = ar > norm.green> ??? ARFLAGS???????? = r > norm.green> ??? CC????????????? = gcc > norm.green> ??? CFLAGS????????? = -g -O0 -arch x86_64 -Wall -Qunused-arguments > norm.green> ??? CPPDEFINES????? = DSO_DLFCN HAVE_DLFCN_H OPENSSL_NO_STATIC_ENGINE > norm.green> OPENSSL_PIC OPENSSL_CPUID_OBJ OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT > norm.green> OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM > norm.green> SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM > norm.green> ECP_NISTZ256_ASM X25519_ASM PADLOCK_ASM POLY1305_ASM > norm.green> ??? CPPFLAGS??????? = -D_REENTRANT -DL_ENDIAN > norm.green> ??? CPPINCLUDES???? = > norm.green> ??? CXXFLAGS??????? = > norm.green> ??? HASHBANGPERL??? = perl > norm.green> ??? LD????????????? = gcc > norm.green> ??? LDFLAGS???????? = > norm.green> ??? LDLIBS????????? = > norm.green> ??? RANLIB????????? = ranlib -c > norm.green> ??? RC????????????? = windres > norm.green> > norm.green> NOTE: These variables only represent the configuration view. The build > norm.green> file > norm.green> template may have processed these variables further, please have a > norm.green> look at the > norm.green> build file for more exact data: > norm.green> ??? Makefile > norm.green> > norm.green> build file: > norm.green> > norm.green> ??? Makefile > norm.green> > norm.green> build file templates: > norm.green> > norm.green> ??? Configurations/unix-Makefile.tmpl > norm.green> ??? Configurations/common.tmpl > norm.green> > norm.green>