From norm.green at gemtalksystems.com Tue Oct 1 01:11:39 2019 From: norm.green at gemtalksystems.com (Norm Green) Date: Mon, 30 Sep 2019 18:11:39 -0700 Subject: EVP_aes_256_xts() problems with multiple calls to EVP_CipherUpdate Message-ID: <802336fd-f568-7a6b-de67-03f0d054d45a@gemtalksystems.com> Hi all, I'm using OpenSSL 1.1.1d on Linux with the cipher EVP_aes_256_xts() in order to write database/disk encryption software. When encrypting, I have problems if I call EVP_CipherUpdate() and encrypt the data in chunks. Encrypting only works when I encrypt the entire payload with one and only one call to EVP_CipherUpdate. If I try to break the data into chunks (and make more than one call to EVP_CipherUpdate), then decrypting the data produces garbage after the first chunk that was encrypted When decrypting, I always decrypt all data in one call to EVP_CipherUpdate . For example, when encrypting 1024 bytes, this pseudo-code sequence works: char payload[1024]; char encrypted[1024]; int destSize = sizeof(encrypted); EVP_CipherInit_ex(); EVP_CipherUpdate(ctx, encrypted, &destSize, payload, sizeof(payload)); EVP_CipherFinal(); (produces no additional data) However if I break the 1024 payload into 2 x 512 byte chunks, decrypting the entire 1024 bytes of cipher text produces garbage every time: char payload[1024]; char encrypted[1024]; int destSize = sizeof(encrypted); EVP_CipherInit_ex(); EVP_CipherUpdate(ctx, encrypted, &destSize, payload, 512); // first chunk destSize -= 512; EVP_CipherUpdate(ctx, &encrypted[512], &destSize, &payload[512], 512); // second chunk EVP_CipherFinal(); (produces no additional data) I have a short C program that demonstrates the problem that I can post if necessary. Can anyone explain what's going on? Norm Green CTO, GemTalk Systems Inc. From thulasi.goriparthi at gmail.com Tue Oct 1 03:04:23 2019 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Tue, 1 Oct 2019 08:34:23 +0530 Subject: EVP_aes_256_xts() problems with multiple calls to EVP_CipherUpdate In-Reply-To: <802336fd-f568-7a6b-de67-03f0d054d45a@gemtalksystems.com> References: <802336fd-f568-7a6b-de67-03f0d054d45a@gemtalksystems.com> Message-ID: As 512 byte blocks are independently encrypted, they should be decrypted similarly. This is how XTS mode is defined. i.e Try to decrypt 512 byte blocks separately with two CipherUpdates. Thanks, Thulasi. On Tue, 1 Oct 2019 at 06:43, Norm Green wrote: > Hi all, > > I'm using OpenSSL 1.1.1d on Linux with the cipher EVP_aes_256_xts() in > order to write database/disk encryption software. > > When encrypting, I have problems if I call EVP_CipherUpdate() and > encrypt the data in chunks. Encrypting only works when I encrypt the > entire payload with one and only one call to EVP_CipherUpdate. > > If I try to break the data into chunks (and make more than one call to > EVP_CipherUpdate), then decrypting the data produces garbage after the > first chunk that was encrypted > When decrypting, I always decrypt all data in one call to EVP_CipherUpdate > . > > For example, when encrypting 1024 bytes, this pseudo-code sequence works: > > char payload[1024]; > char encrypted[1024]; > int destSize = sizeof(encrypted); > EVP_CipherInit_ex(); > EVP_CipherUpdate(ctx, encrypted, &destSize, payload, sizeof(payload)); > EVP_CipherFinal(); (produces no additional data) > > However if I break the 1024 payload into 2 x 512 byte chunks, decrypting > the entire 1024 bytes of cipher text produces garbage every time: > > char payload[1024]; > char encrypted[1024]; > int destSize = sizeof(encrypted); > EVP_CipherInit_ex(); > EVP_CipherUpdate(ctx, encrypted, &destSize, payload, 512); // first chunk > destSize -= 512; > EVP_CipherUpdate(ctx, &encrypted[512], &destSize, &payload[512], 512); > // second chunk > EVP_CipherFinal(); (produces no additional data) > > I have a short C program that demonstrates the problem that I can post > if necessary. > > Can anyone explain what's going on? > > Norm Green > CTO, GemTalk Systems Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norm.green at gemtalksystems.com Tue Oct 1 03:16:11 2019 From: norm.green at gemtalksystems.com (Norm Green) Date: Mon, 30 Sep 2019 20:16:11 -0700 Subject: EVP_aes_256_xts() problems with multiple calls to EVP_CipherUpdate In-Reply-To: References: <802336fd-f568-7a6b-de67-03f0d054d45a@gemtalksystems.com> Message-ID: Could be, but that's not how EVP_CipherUpdate is documented to work.? If this is an XTS mode limitation and not a bug, shouldn't the limitation be documented on a man page somewhere?? And shouldn't my second call to EVP_CipherUpdate fail? Norm Green On 9/30/2019 8:04 PM, Thulasi Goriparthi wrote: > As 512 byte blocks are independently encrypted, they should be > decrypted similarly. This is how XTS mode is defined. > i.e Try to decrypt 512 byte blocks separately with two CipherUpdates. > > Thanks, > Thulasi. > > On Tue, 1 Oct 2019 at 06:43, Norm Green > wrote: > > Hi all, > > I'm using OpenSSL 1.1.1d on Linux with the cipher > EVP_aes_256_xts() in > order to write database/disk encryption software. > > When encrypting, I have problems if I call EVP_CipherUpdate() and > encrypt the data in chunks. Encrypting only works when I encrypt the > entire payload with one and only one call to EVP_CipherUpdate. > > If I try to break the data into chunks (and make more than one > call to > EVP_CipherUpdate), then decrypting the data produces garbage after > the > first chunk that was encrypted > When decrypting, I always decrypt all data in one call to > EVP_CipherUpdate . > > For example, when encrypting 1024 bytes, this pseudo-code sequence > works: > > char payload[1024]; > char encrypted[1024]; > int destSize = sizeof(encrypted); > EVP_CipherInit_ex(); > EVP_CipherUpdate(ctx, encrypted, &destSize, payload, sizeof(payload)); > EVP_CipherFinal(); (produces no additional data) > > However if I break the 1024 payload into 2 x 512 byte chunks, > decrypting > the entire 1024 bytes of cipher text produces garbage every time: > > char payload[1024]; > char encrypted[1024]; > int destSize = sizeof(encrypted); > EVP_CipherInit_ex(); > EVP_CipherUpdate(ctx, encrypted, &destSize, payload, 512); // > first chunk > destSize -= 512; > EVP_CipherUpdate(ctx, &encrypted[512], &destSize, &payload[512], > 512); > // second chunk > EVP_CipherFinal(); (produces no additional data) > > I have a short C program that demonstrates the problem that I can > post > if necessary. > > Can anyone explain what's going on? > > Norm Green > CTO, GemTalk Systems Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thulasi.goriparthi at gmail.com Tue Oct 1 04:25:59 2019 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Tue, 1 Oct 2019 09:55:59 +0530 Subject: EVP_aes_256_xts() problems with multiple calls to EVP_CipherUpdate In-Reply-To: References: <802336fd-f568-7a6b-de67-03f0d054d45a@gemtalksystems.com> Message-ID: Agree that XTS specific deviation should have been documented similar to some of the AEAD ciphers with EVP interface. Thanks, Thulasi. On Tue, 1 Oct 2019 at 08:46, Norm Green wrote: > Could be, but that's not how EVP_CipherUpdate is documented to work. If > this is an XTS mode limitation and not a bug, shouldn't the limitation be > documented on a man page somewhere? And shouldn't my second call to > EVP_CipherUpdate fail? > > Norm Green > > > On 9/30/2019 8:04 PM, Thulasi Goriparthi wrote: > > As 512 byte blocks are independently encrypted, they should be decrypted > similarly. This is how XTS mode is defined. > i.e Try to decrypt 512 byte blocks separately with two CipherUpdates. > > Thanks, > Thulasi. > > On Tue, 1 Oct 2019 at 06:43, Norm Green > wrote: > >> Hi all, >> >> I'm using OpenSSL 1.1.1d on Linux with the cipher EVP_aes_256_xts() in >> order to write database/disk encryption software. >> >> When encrypting, I have problems if I call EVP_CipherUpdate() and >> encrypt the data in chunks. Encrypting only works when I encrypt the >> entire payload with one and only one call to EVP_CipherUpdate. >> >> If I try to break the data into chunks (and make more than one call to >> EVP_CipherUpdate), then decrypting the data produces garbage after the >> first chunk that was encrypted >> When decrypting, I always decrypt all data in one call to >> EVP_CipherUpdate . >> >> For example, when encrypting 1024 bytes, this pseudo-code sequence works: >> >> char payload[1024]; >> char encrypted[1024]; >> int destSize = sizeof(encrypted); >> EVP_CipherInit_ex(); >> EVP_CipherUpdate(ctx, encrypted, &destSize, payload, sizeof(payload)); >> EVP_CipherFinal(); (produces no additional data) >> >> However if I break the 1024 payload into 2 x 512 byte chunks, decrypting >> the entire 1024 bytes of cipher text produces garbage every time: >> >> char payload[1024]; >> char encrypted[1024]; >> int destSize = sizeof(encrypted); >> EVP_CipherInit_ex(); >> EVP_CipherUpdate(ctx, encrypted, &destSize, payload, 512); // first chunk >> destSize -= 512; >> EVP_CipherUpdate(ctx, &encrypted[512], &destSize, &payload[512], 512); >> // second chunk >> EVP_CipherFinal(); (produces no additional data) >> >> I have a short C program that demonstrates the problem that I can post >> if necessary. >> >> Can anyone explain what's going on? >> >> Norm Green >> CTO, GemTalk Systems Inc. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nagalakshmi.j at altran.com Tue Oct 1 05:41:46 2019 From: nagalakshmi.j at altran.com (Nagalakshmi V J) Date: Tue, 1 Oct 2019 05:41:46 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: , Message-ID: Hi Sergio, We are using OpenSSL APIs in our product code. We are not making any changes in OpenSSL. Our product code is a C++ code and it makes use of openSSL APIs for some functionality. This compilation error we are getting in Linux and windows platforms. But in Linux, we have a '-fpermissive' flag which is suppressing those errors as warnings and so compilation is getting successful. The issue here is in Windows , we are not able to find alternative flag for -'fpermissive' in Visual studio and due to that compilation is unsuccessful. It would be helpful if anyone suggests some option to get the compilation successful. Thanks and regards, Nagalakshmi From: Sergio NNX Sent: Monday, September 30, 2019 9:06 PM To: Dr. Matthias St. Pierre ; Nagalakshmi V J ; Michael Mueller Cc: openssl-users at openssl.org; Umamaheswari Nagarajan Subject: Re: OpenSSL compilation errors in Windows ** This mail has been sent from an external source ** Ciao. I haven't had a chance to compile the exact OpenSSL version using g++ compiler as stated by the user/poster. If this user is using a modified or altered version of OpenSSL provided source code, is there support available? Don't get me wrong, I don't mind helping out but ..... I'll try to compile OpenSSL source code this evening and I'll post my findings here. Regards. Sergio. ________________________________ From: openssl-users > on behalf of Dr. Matthias St. Pierre > Sent: Tuesday, 1 October 2019 12:28 AM To: Nagalakshmi V J >; Michael Mueller > Cc: openssl-users at openssl.org >; Umamaheswari Nagarajan > Subject: AW: OpenSSL compilation errors in Windows > OpenSSL code is compiling without any issues. When it is used from our product code and while compiling using C++ compiler, the issue is seen. As I wrote previously, the error you posted was caused by the fact that you are compiling Ansi C (a.k.a ISO/IEC 9899:1990, a.k.a C90) source code using a C++ compiler. While C permits a cast from 'void *' to 'anytype *', C++ doesn't allow it without an explicit cast. Only the *public* OpenSSL headers are guaranteed to be includable by a C++ compiler (they contain the necessary ` extern "C" ` blocks, etc.), not the internal headers. Including *internal* headers is neither supported nor possible with a C++ compiler. And as Matt Caswell already told you, there are no compatibility guarantees for those headers. Matthias ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Oct 1 08:11:25 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 1 Oct 2019 09:11:25 +0100 Subject: [openssl-users] issue with EVP_EncryptUpdate in XTS mode? In-Reply-To: References: Message-ID: <1370915b-a9ba-3b32-f033-87aa0557be6c@openssl.org> On 25/01/2019 20:16, Andrew Tucker wrote: > I was doing some comparisons of XTS and GCM mode using the EVP APIs and found a > discrepancy that seems to be an issue with XTS. > > In GCM mode if the buffer is encrypted in one call to EVP_EncryptUpdate or with > several calls with smaller buffers the resulting ciphertext is the same, as I > would expect.? ?With XTS mode, calling EVP_EncryptUpdate results in the same > ciphertext for the same plaintext and does not match the results when the buffer > is encrypted with one call to EVP_EncryptUpdate. > > I would expect that the counter is incremented in both XTS and GCM mode in the > same way and that in both cases the output would match regardless of the > encryption block size. > > A simple repro test is attached.? ? If you run it you can see that the output > "GCM in one block" matches the output for "GCM in 16 byte blocks" and the > outputs do not match for XTS. > > I am using OpenSSL v1.02p but I have tried with other versions and got the same > results. > > Am I misunderstanding the use of XTS mode or is this an issue with OpenSSL? Please see my previous post on this topic here: https://mta.openssl.org/pipermail/openssl-users/2019-January/009781.html PRs welcome to improve the documentation in this area. Matt From Matthias.St.Pierre at ncp-e.com Tue Oct 1 11:13:10 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 1 Oct 2019 11:13:10 +0000 Subject: AW: OpenSSL compilation errors in Windows In-Reply-To: References: , Message-ID: <2b8035491b1d40668758b78936fab706@Ex13.ncp.local> > We are using OpenSSL APIs in our product code. We are not making any changes in OpenSSL. > Our product code is a C++ code and it makes use of openSSL APIs for some functionality. Local headers (like "ssl_locl.h" and "packet_locl.h") are *NOT* part of the official OpenSSL API. Please don't expect any support w.r.t. compilation or compatibility problems if you do include them in your application, even more if it's compiled using a C++ compiler. It would be more helpful if you would tell us *why* you are including ssl_locl.h and what you are trying to achieve. Then we might be able to tell you how you could achieve your goal using the officially supported API. Please note that many of the OpenSSL structures were made opaque in version 1.1.0. This means that there are only forward declarations of the structures in the public headers and the compiler does not get to see the structure members. Instead of directly accessing the members, it is now necessary to use accessor functions (a.k.a. getters and setters). If this is the reason why you are including private OpenSSL headers then you should adopt you application to use the new accessors instead, instead of forcing the impossible to circumvent the new policy. For more information, see https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes Matthias From jgh at wizmail.org Tue Oct 1 11:21:21 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Tue, 1 Oct 2019 12:21:21 +0100 Subject: full-chain ocsp stapling In-Reply-To: <9d2cfd7b-c83d-06ba-5a46-da3fd0672697@openssl.org> References: <86bfc59e-a2d8-d2a3-a81d-3abf43705853@wizmail.org> <9d2cfd7b-c83d-06ba-5a46-da3fd0672697@openssl.org> Message-ID: <3a9e3d31-4ee6-4acd-e05d-9beb79044125@wizmail.org> On 30/09/2019 17:02, Matt Caswell wrote: >> Alternatively^2, is there some way to get such a blob from a tool >> (openssl ocsp, or similar) ready built? For this purpose, I am >> the CA. >> > > Yes, you can do this. For example see the "respout" option in the > ocsp command. > > From the examples in the ocsp man page: > > Send a query to an OCSP responder with URL http://ocsp.myhost.com/ > save the response to a file, print it out in text form, and verify > the response: > > openssl ocsp -issuer issuer.pem -cert c1.pem -cert c2.pem \ -url > http://ocsp.myhost.com/ -resp_text -respout resp.der I'm using the indexfile variant. It seems that the -CA argument needs to be the signer of the cert, not the CA for the chain; and you cannot give -CA multiple times. So you don't get good OCSP status for all elements in the chain: $ cat $ifile V 130110200751Z 65 unknown CN=server1.example.com V 130110200751Z 66 unknown CN=revoked1.example.com V 130110200751Z 67 unknown CN=expired1.example.com V 130110200751Z c9 unknown CN=server2.example.com V 130110200751Z ca unknown CN=revoked2.example.com V 130110200751Z cb unknown CN=expired2.example.com V 130110200751Z 42 unknown CN=clica Signing Cert rsa V 130110200751Z 41 unknown CN=clica CA rsa $ $ openssl ocsp -sha256 -no_nonce -issuer $CADIR/Signer.pem -cert $leafcert -issuer $CADIR/CA.pem -cert $CADIR/Signer.pem -cert $CADIR/CA.pem -reqout $REQ -req_text OCSP Request Data: Version: 1 (0x0) Requestor List: Certificate ID: Hash Algorithm: sha256 Issuer Name Hash: 5AF082E51D62FE01FD706BAEBEB878DB64E68F76E74A36F36D914297DDEE24B8 Issuer Key Hash: 333DB14364B98E78A33DD8A4FAE8D8378EA9B0F5FBCA97B25685AA0D32116091 Serial Number: 65 Certificate ID: Hash Algorithm: sha256 Issuer Name Hash: BFA7275A566EFD4BE2DF82DBD9D1290D470186F6FF2ACD8C16659F342AB56109 Issuer Key Hash: 208F9D28C7C0BC914144DFA8C0BE3D5B3BFCEBB622C8A8DC27E865FC06CA0E12 Serial Number: 42 Certificate ID: Hash Algorithm: sha256 Issuer Name Hash: BFA7275A566EFD4BE2DF82DBD9D1290D470186F6FF2ACD8C16659F342AB56109 Issuer Key Hash: 208F9D28C7C0BC914144DFA8C0BE3D5B3BFCEBB622C8A8DC27E865FC06CA0E12 Serial Number: 41 $ $ openssl ocsp -index $ifile -rsigner $CADIR/CA.pem -rkey $CADIR/CA.key -CA $CADIR/CA.pem -resp_no_certs -noverify -ndays 3652 -reqin $REQ -respout $RESP -resp_text | egrep '(Serial|Status)' OCSP Response Status: successful (0x0) Serial Number: 65 Cert Status: unknown Serial Number: 42 Cert Status: good Serial Number: 41 Cert Status: good $ -- Cheers, Jeremy From rsalz at akamai.com Tue Oct 1 12:59:52 2019 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 1 Oct 2019 12:59:52 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: Message-ID: Several people have told you the following: That is an *internal* openssl header file; do not use it. Remove the include statement from your code. Your code is wrong. That file is a C file, not compatible with C++ Why do you not listen? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nagalakshmi.j at altran.com Tue Oct 1 13:03:12 2019 From: nagalakshmi.j at altran.com (Nagalakshmi V J) Date: Tue, 1 Oct 2019 13:03:12 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: <2b8035491b1d40668758b78936fab706@Ex13.ncp.local> References: , <2b8035491b1d40668758b78936fab706@Ex13.ncp.local> Message-ID: Thank you Matthias for the explanation. I am going through my code to understand why ssl_locl.h is included. I will check and get back on this ASAP. Also if there is other way to achieve that I will use the same. Thanks and regards, Nagalakshmi -----Original Message----- From: Dr. Matthias St. Pierre Sent: Tuesday, October 1, 2019 4:43 PM To: Nagalakshmi V J Cc: openssl-users at openssl.org; Umamaheswari Nagarajan Subject: AW: OpenSSL compilation errors in Windows ** This mail has been sent from an external source ** > We are using OpenSSL APIs in our product code. We are not making any changes in OpenSSL. > Our product code is a C++ code and it makes use of openSSL APIs for some functionality. Local headers (like "ssl_locl.h" and "packet_locl.h") are *NOT* part of the official OpenSSL API. Please don't expect any support w.r.t. compilation or compatibility problems if you do include them in your application, even more if it's compiled using a C++ compiler. It would be more helpful if you would tell us *why* you are including ssl_locl.h and what you are trying to achieve. Then we might be able to tell you how you could achieve your goal using the officially supported API. Please note that many of the OpenSSL structures were made opaque in version 1.1.0. This means that there are only forward declarations of the structures in the public headers and the compiler does not get to see the structure members. Instead of directly accessing the members, it is now necessary to use accessor functions (a.k.a. getters and setters). If this is the reason why you are including private OpenSSL headers then you should adopt you application to use the new accessors instead, instead of forcing the impossible to circumvent the new policy. For more information, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openssl.org_index.php_OpenSSL-5F1.1.0-5FChanges&d=DwIGaQ&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=wpEV8Q2RDZjERhtJGZl9HajV9jd2dJFF10J30_YrPQo&s=sX1YilJaXloAQDzrjD3Lz-I6DOej3QduhsAanXOYxVM&e= Matthias Dr. Matthias St. Pierre Senior Software Engineer matthias.st.pierre at ncp-e.com Phone: +49 911 9968-0 www.ncp-e.com Headquarters Germany: NCP engineering GmbH ? Dombuehler Str. 2 ? 90449 ? Nuremberg North American HQ: NCP engineering Inc. ? 678 Georgia Ave. ? Sunnyvale, CA 94085 East Coast Office: NCP engineering Inc. ? 601 Cleveland Str., Suite 501-25 ? Clearwater, FL 33755 Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich Registry Court: Lower District Court of Nuremberg Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE 133557619 This e-mail message including any attachments is for the sole use of the intended recipient(s) and may contain privileged or confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply e-mail and delete the original message and destroy all copies thereof. ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== From nagalakshmi.j at altran.com Tue Oct 1 13:04:11 2019 From: nagalakshmi.j at altran.com (Nagalakshmi V J) Date: Tue, 1 Oct 2019 13:04:11 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: Message-ID: Hi Salz, I am working on that only. I will try to not use those internal files as per the suggestions. Thanks and regards, Nagalakshmi From: Salz, Rich Sent: Tuesday, October 1, 2019 6:30 PM To: Nagalakshmi V J ; Sergio NNX ; Dr. Matthias St. Pierre ; Michael Mueller Cc: openssl-users at openssl.org; Umamaheswari Nagarajan Subject: Re: OpenSSL compilation errors in Windows ** This mail has been sent from an external source ** Several people have told you the following: That is an *internal* openssl header file; do not use it. Remove the include statement from your code. Your code is wrong. That file is a C file, not compatible with C++ Why do you not listen? ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Tue Oct 1 13:13:36 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Tue, 1 Oct 2019 16:13:36 +0300 Subject: KeyAgreeRecipientInfo.ukm Message-ID: Dear all, I don't see anywhere except parsing any mention of the KeyAgreeRecipientInfo.ukm field. Russian GOST CMS standard implies using of ukm value. Do I correctly understand that I have to add some support (presumably in the EVP_PKEY_CTX) of this field if it should be passed to the derivation procedure? -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Tue Oct 1 13:39:58 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Tue, 1 Oct 2019 16:39:58 +0300 Subject: KeyAgreeRecipientInfo.ukm In-Reply-To: References: Message-ID: Hello, Well, some more diving into the code and I got the point. We already have the corresponding control ASN1_PKEY_CTRL_CMS_ENVELOPE On Tue, Oct 1, 2019 at 4:13 PM Dmitry Belyavsky wrote: > Dear all, > > I don't see anywhere except parsing any mention of > the KeyAgreeRecipientInfo.ukm field. > Russian GOST CMS standard implies using of ukm value. > > Do I correctly understand that I have to add some support (presumably in > the EVP_PKEY_CTX) of this field if it should be passed to the derivation > procedure? > > -- > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafal.arciszewski at gmail.com Tue Oct 1 15:30:56 2019 From: rafal.arciszewski at gmail.com (=?UTF-8?Q?Rafa=C5=82_Arciszewski?=) Date: Tue, 1 Oct 2019 17:30:56 +0200 Subject: Fwd: ASN1_generate_nconf - incorrect integer encoding? In-Reply-To: References: Message-ID: Hi all, I am trying to use OpenSSL libraries (libssl-dev 1.0.2 or 1.1.1) to encode integers into DER format.I am using ASN1_generate_nconf but it seems that this function incorrectly encodes integers. It should encode in two's complement format and should prepend 0x00 byte if the first byte of encoded integer is greater then 0x80. But it is not doing that. Here is my simple program where I check the length of encoded integer. For example for int = 128 the length should be 2. But the length is 2 beginning from int = 256. Am I using correct function or should I use different one? #include #include #include uint64_t i; char str[100]; ASN1_TYPE *asn_ptr = NULL; int main () { for(i = 120; i < 270; i++) { sprintf(str,"INTEGER:%lu",i); asn_ptr = ASN1_generate_nconf(str, NULL); printf("i: %lu, str: %s , len: %d \n", i, str, asn_ptr->value.integer->length); } } i: 120, str: INTEGER:120 , len: 1 i: 121, str: INTEGER:121 , len: 1 i: 122, str: INTEGER:122 , len: 1 i: 123, str: INTEGER:123 , len: 1 i: 124, str: INTEGER:124 , len: 1 i: 125, str: INTEGER:125 , len: 1 i: 126, str: INTEGER:126 , len: 1 i: 127, str: INTEGER:127 , len: 1 i: 128, str: INTEGER:128 , len: 1 i: 129, str: INTEGER:129 , len: 1 i: 130, str: INTEGER:130 , len: 1 i: 131, str: INTEGER:131 , len: 1 i: 132, str: INTEGER:132 , len: 1 i: 133, str: INTEGER:133 , len: 1 i: 134, str: INTEGER:134 , len: 1 i: 135, str: INTEGER:135 , len: 1 i: 136, str: INTEGER:136 , len: 1 i: 137, str: INTEGER:137 , len: 1 i: 138, str: INTEGER:138 , len: 1 i: 139, str: INTEGER:139 , len: 1 i: 140, str: INTEGER:140 , len: 1 i: 141, str: INTEGER:141 , len: 1 i: 142, str: INTEGER:142 , len: 1 i: 143, str: INTEGER:143 , len: 1 i: 144, str: INTEGER:144 , len: 1 i: 145, str: INTEGER:145 , len: 1 i: 146, str: INTEGER:146 , len: 1 i: 147, str: INTEGER:147 , len: 1 i: 148, str: INTEGER:148 , len: 1 i: 149, str: INTEGER:149 , len: 1 i: 150, str: INTEGER:150 , len: 1 i: 151, str: INTEGER:151 , len: 1 i: 152, str: INTEGER:152 , len: 1 i: 153, str: INTEGER:153 , len: 1 i: 154, str: INTEGER:154 , len: 1 i: 155, str: INTEGER:155 , len: 1 i: 156, str: INTEGER:156 , len: 1 i: 157, str: INTEGER:157 , len: 1 i: 158, str: INTEGER:158 , len: 1 i: 159, str: INTEGER:159 , len: 1 i: 160, str: INTEGER:160 , len: 1 i: 161, str: INTEGER:161 , len: 1 i: 162, str: INTEGER:162 , len: 1 i: 163, str: INTEGER:163 , len: 1 i: 164, str: INTEGER:164 , len: 1 i: 165, str: INTEGER:165 , len: 1 i: 166, str: INTEGER:166 , len: 1 i: 167, str: INTEGER:167 , len: 1 i: 168, str: INTEGER:168 , len: 1 i: 169, str: INTEGER:169 , len: 1 i: 170, str: INTEGER:170 , len: 1 i: 171, str: INTEGER:171 , len: 1 i: 172, str: INTEGER:172 , len: 1 i: 173, str: INTEGER:173 , len: 1 i: 174, str: INTEGER:174 , len: 1 i: 175, str: INTEGER:175 , len: 1 i: 176, str: INTEGER:176 , len: 1 i: 177, str: INTEGER:177 , len: 1 i: 178, str: INTEGER:178 , len: 1 i: 179, str: INTEGER:179 , len: 1 i: 180, str: INTEGER:180 , len: 1 i: 181, str: INTEGER:181 , len: 1 i: 182, str: INTEGER:182 , len: 1 i: 183, str: INTEGER:183 , len: 1 i: 184, str: INTEGER:184 , len: 1 i: 185, str: INTEGER:185 , len: 1 i: 186, str: INTEGER:186 , len: 1 i: 187, str: INTEGER:187 , len: 1 i: 188, str: INTEGER:188 , len: 1 i: 189, str: INTEGER:189 , len: 1 i: 190, str: INTEGER:190 , len: 1 i: 191, str: INTEGER:191 , len: 1 i: 192, str: INTEGER:192 , len: 1 i: 193, str: INTEGER:193 , len: 1 i: 194, str: INTEGER:194 , len: 1 i: 195, str: INTEGER:195 , len: 1 i: 196, str: INTEGER:196 , len: 1 i: 197, str: INTEGER:197 , len: 1 i: 198, str: INTEGER:198 , len: 1 i: 199, str: INTEGER:199 , len: 1 i: 200, str: INTEGER:200 , len: 1 i: 201, str: INTEGER:201 , len: 1 i: 202, str: INTEGER:202 , len: 1 i: 203, str: INTEGER:203 , len: 1 i: 204, str: INTEGER:204 , len: 1 i: 205, str: INTEGER:205 , len: 1 i: 206, str: INTEGER:206 , len: 1 i: 207, str: INTEGER:207 , len: 1 i: 208, str: INTEGER:208 , len: 1 i: 209, str: INTEGER:209 , len: 1 i: 210, str: INTEGER:210 , len: 1 i: 211, str: INTEGER:211 , len: 1 i: 212, str: INTEGER:212 , len: 1 i: 213, str: INTEGER:213 , len: 1 i: 214, str: INTEGER:214 , len: 1 i: 215, str: INTEGER:215 , len: 1 i: 216, str: INTEGER:216 , len: 1 i: 217, str: INTEGER:217 , len: 1 i: 218, str: INTEGER:218 , len: 1 i: 219, str: INTEGER:219 , len: 1 i: 220, str: INTEGER:220 , len: 1 i: 221, str: INTEGER:221 , len: 1 i: 222, str: INTEGER:222 , len: 1 i: 223, str: INTEGER:223 , len: 1 i: 224, str: INTEGER:224 , len: 1 i: 225, str: INTEGER:225 , len: 1 i: 226, str: INTEGER:226 , len: 1 i: 227, str: INTEGER:227 , len: 1 i: 228, str: INTEGER:228 , len: 1 i: 229, str: INTEGER:229 , len: 1 i: 230, str: INTEGER:230 , len: 1 i: 231, str: INTEGER:231 , len: 1 i: 232, str: INTEGER:232 , len: 1 i: 233, str: INTEGER:233 , len: 1 i: 234, str: INTEGER:234 , len: 1 i: 235, str: INTEGER:235 , len: 1 i: 236, str: INTEGER:236 , len: 1 i: 237, str: INTEGER:237 , len: 1 i: 238, str: INTEGER:238 , len: 1 i: 239, str: INTEGER:239 , len: 1 i: 240, str: INTEGER:240 , len: 1 i: 241, str: INTEGER:241 , len: 1 i: 242, str: INTEGER:242 , len: 1 i: 243, str: INTEGER:243 , len: 1 i: 244, str: INTEGER:244 , len: 1 i: 245, str: INTEGER:245 , len: 1 i: 246, str: INTEGER:246 , len: 1 i: 247, str: INTEGER:247 , len: 1 i: 248, str: INTEGER:248 , len: 1 i: 249, str: INTEGER:249 , len: 1 i: 250, str: INTEGER:250 , len: 1 i: 251, str: INTEGER:251 , len: 1 i: 252, str: INTEGER:252 , len: 1 i: 253, str: INTEGER:253 , len: 1 i: 254, str: INTEGER:254 , len: 1 i: 255, str: INTEGER:255 , len: 1 i: 256, str: INTEGER:256 , len: 2 i: 257, str: INTEGER:257 , len: 2 i: 258, str: INTEGER:258 , len: 2 i: 259, str: INTEGER:259 , len: 2 i: 260, str: INTEGER:260 , len: 2 i: 261, str: INTEGER:261 , len: 2 i: 262, str: INTEGER:262 , len: 2 i: 263, str: INTEGER:263 , len: 2 i: 264, str: INTEGER:264 , len: 2 i: 265, str: INTEGER:265 , len: 2 i: 266, str: INTEGER:266 , len: 2 i: 267, str: INTEGER:267 , len: 2 i: 268, str: INTEGER:268 , len: 2 i: 269, str: INTEGER:269 , len: 2 Regards, Rafa? Arciszewski -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Oct 1 16:06:46 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 1 Oct 2019 17:06:46 +0100 Subject: Fwd: ASN1_generate_nconf - incorrect integer encoding? In-Reply-To: References: Message-ID: <84f72d1c-3d1c-a401-956c-75892d84117a@openssl.org> On 01/10/2019 16:30, Rafa? Arciszewski wrote: > Hi all, > I am trying to use OpenSSL libraries (libssl-dev 1.0.2 or 1.1.1)? to encode > integers into DER format.I am using ASN1_generate_nconf but it seems that this > function incorrectly encodes integers. It should encode in two's complement > format and should prepend 0x00 byte if the first byte of encoded integer is > greater then 0x80. But it is not doing that. > > Here is my simple program where I check the length of encoded integer. For > example for int = 128 the length should be 2. But the length is 2 beginning from > int = 256. > > > Am I using correct function or should I use different one? I think you've misunderstood what the function actually does. It enables you to create an ASN1_TYPE object based on an input string. An ASN1_TYPE object does *not* give you the DER encoding of that object. It is an internal representation of ASN1 data. You can convert it to DER using the i2d_ASN1_TYPE function: https://www.openssl.org/docs/man1.1.1/man3/i2d_ASN1_TYPE.html If all you need to do is create a DER encoding of an INTEGER then ASN1_generate_nconf() is probably overkill. Perhaps simpler would be to create an ASN1_INTEGER object like this (untested and error checking omitted): ASN1_INTEGER *myval = ASN1_INTEGER_new(); ASN1_INTEGER_set_uint64(myval, 123456); You can then create the DER encoding of that INTEGER using the i2d_ASN1_INTEGER function (on the same man page as above). Matt From christian.mazakas at gmail.com Wed Oct 2 02:10:55 2019 From: christian.mazakas at gmail.com (Christian Mazakas) Date: Tue, 1 Oct 2019 19:10:55 -0700 Subject: EVP_PKEY_CTX* Best Practices Message-ID: I'm relatively new to the world of OpenSSL. I'm trying to write a QUIC stream class and for that, I need to use the EVP_PKEY_CTX and I'm not sure what's the optimal way of scoping instances of this context. For example, should I have a CTX per Quic connection? Or rather one that's shared by many in a thread-safe manner? What's the cost of generating one per connection? Are there docs where I can read about this kind of stuff? - Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Oct 2 09:19:44 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 2 Oct 2019 10:19:44 +0100 Subject: EVP_PKEY_CTX* Best Practices In-Reply-To: References: Message-ID: On 02/10/2019 03:10, Christian Mazakas wrote: > I'm relatively new to the world of OpenSSL. > > I'm trying to write a QUIC stream class and for that, I need to use the > EVP_PKEY_CTX and I'm not sure what's the optimal way of scoping instances of > this context. > > For example, should I have a CTX per Quic connection? Or rather one that's > shared by many in a thread-safe manner? What's the cost of generating one per > connection? Are there docs where I can read about this kind of stuff? There are no hard and fast rules on this as much is going to depend on the particular application. However EVP_PKEY_CTX creation is not particularly expensive. As a point of reference libssl creates and destroys these on a temporary basis per connection. Most likely the overhead of trying to share these between multiple threads, and the locking that would therefore be required, is not going to be worth it. Matt From andy.kennedy.1814 at gmail.com Wed Oct 2 23:50:26 2019 From: andy.kennedy.1814 at gmail.com (Andy Kennedy) Date: Wed, 2 Oct 2019 18:50:26 -0500 Subject: Windows 10 run-time issue In-Reply-To: <5ADFF93892EDB147B66FCBABC8E4F27F16292D00@prgmbx01> References: <5ADFF93892EDB147B66FCBABC8E4F27F16292D00@prgmbx01> Message-ID: All, Previous versions used: Windows 7 openssl-1.0.2s libssh-0.9.0 VS2017 Strawberry Perl This configuration worked without issue. Then, MS EOL'ed Windows 7. My configuration is now: Windows 10 openssl-1.1.1d (someone on libssh told me that I needed this version) VS2017 Strawberry Perl NASM Build instructions for x64 command console: set PATH=%PATH%;%USERPROFILE%\strawberry\perl\bin set PATH=%PATH%;%USERPROFILE%\nasm-2.14.03rc2 cd %USERPROFILE%\source\oss\openssl-1.1.1d perl Configure VC-WIN64A --prefix=%USERPROFILE%\oss --openssldir=%USERPROFILE%\oss nmake nmake test nmake install Now, with Windows 10, I get a "Microsoft Visual C++ Runtime Library" box with the following text: Debug Assertion Failed! Program File minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp Line: 908 Expression: is_block_type_valid(header->_block_use) So, I connect to the app with the VS debugger and find: file: pki_crypto.c: function: pki_signature_from_ecdsa_blob() line: (1769) SAFE_FREE(raw_sig_data); is what VS claims generated this error. >From the above description, can anyone tell me what I have done wrong in the build? Or, have I stumbled upon a bug? Thanks in advance for any assistance you can provide. Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From shivakumar2696 at gmail.com Thu Oct 3 07:58:59 2019 From: shivakumar2696 at gmail.com (shiva kumar) Date: Thu, 3 Oct 2019 13:28:59 +0530 Subject: OPENSSL IS NOT GENERATING RESPONSE Message-ID: HI, when I run the following command the response is not generated *util/shlib_wrap.sh apps/openssl ts -config test/CAtsa.cnf -reply -section tsa_config1 -queryfile req1.tsq -out resp1.tsr* output >>Using configuration from test/CAtsa.cnf >>Response is not generated. though I have run and generated the file request file req1.tsq can anyone let me know why I'm getting this error? -- *With Best Regards* *Shivakumar S* -------------- next part -------------- An HTML attachment was scrubbed... URL: From nagalakshmi.j at altran.com Thu Oct 3 10:10:00 2019 From: nagalakshmi.j at altran.com (Nagalakshmi V J) Date: Thu, 3 Oct 2019 10:10:00 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: , <2b8035491b1d40668758b78936fab706@Ex13.ncp.local> Message-ID: Hi Matthias, Please find my response for your queries below. It would be more helpful if you would tell us *why* you are including ssl_locl.h and what you are trying to achieve. Then we might be able to tell you how you could achieve your goal using the officially supported API. [Nagalakshmi]: In our product code, we are using the structures 'ssl_st' and 'ssl_session_st' which were defined in ssl.h file in Openssl 1.0.2.j version. Since the structure definitions are made opaque in openssl 1.1.1c, we used ssl_locl.h where the structure definitions are available. Please note that many of the OpenSSL structures were made opaque in version 1.1.0. This means that there are only forward declarations of the structures in the public headers and the compiler does not get to see the structure members. Instead of directly accessing the members, it is now necessary to use accessor functions (a.k.a. getters and setters). [Nagalakshmi]: Regarding usage of accessor functions, I got the following APIs. SSL_get_session(s) SSL_SESSION_get_master_key(). If we use those APIs, I am again getting errors like the below. .\odlibPrf_OSSL.h(164) : error C2027: use of undefined type 'ssl_session_st' ..\..\OpenSSL\openssl-1.1.1c\include\openssl/ssl.h(213) : see declaration of 'ssl_session_st' .\odlibPrf_OSSL.h(164) : error C2227: left of '->SSL_SESSION_get_master_key' must point to class/struct/union .\odlibPrf_OSSL.h(167) : error C2027: use of undefined type 'ssl_st' ..\..\OpenSSL\openssl-1.1.1c\include\openssl/ossl_typ.h(147) : see declaration of 'ssl_st' .\odlibPrf_OSSL.h(167) : error C2227: left of '->session' must point to class/struct/union .\odlibPrf_OSSL.h(167) : error C2227: left of '->master_key' must point to class/struct/union .\odlibPrf_OSSL.h(168) : error C2027: use of undefined type 'ssl_st' Can you help me to get the corresponding accessor functions for these 2 structures. Thanks and regards, Nagalakshmi -----Original Message----- From: Nagalakshmi V J Sent: Tuesday, October 1, 2019 6:33 PM To: Dr. Matthias St. Pierre ; Nagalakshmi V J Cc: openssl-users at openssl.org; Umamaheswari Nagarajan Subject: RE: OpenSSL compilation errors in Windows Thank you Matthias for the explanation. I am going through my code to understand why ssl_locl.h is included. I will check and get back on this ASAP. Also if there is other way to achieve that I will use the same. Thanks and regards, Nagalakshmi -----Original Message----- From: Dr. Matthias St. Pierre > Sent: Tuesday, October 1, 2019 4:43 PM To: Nagalakshmi V J > Cc: openssl-users at openssl.org; Umamaheswari Nagarajan > Subject: AW: OpenSSL compilation errors in Windows ** This mail has been sent from an external source ** > We are using OpenSSL APIs in our product code. We are not making any changes in OpenSSL. > Our product code is a C++ code and it makes use of openSSL APIs for some functionality. Local headers (like "ssl_locl.h" and "packet_locl.h") are *NOT* part of the official OpenSSL API. Please don't expect any support w.r.t. compilation or compatibility problems if you do include them in your application, even more if it's compiled using a C++ compiler. It would be more helpful if you would tell us *why* you are including ssl_locl.h and what you are trying to achieve. Then we might be able to tell you how you could achieve your goal using the officially supported API. Please note that many of the OpenSSL structures were made opaque in version 1.1.0. This means that there are only forward declarations of the structures in the public headers and the compiler does not get to see the structure members. Instead of directly accessing the members, it is now necessary to use accessor functions (a.k.a. getters and setters). If this is the reason why you are including private OpenSSL headers then you should adopt you application to use the new accessors instead, instead of forcing the impossible to circumvent the new policy. For more information, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openssl.org_index.php_OpenSSL-5F1.1.0-5FChanges&d=DwIGaQ&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=wpEV8Q2RDZjERhtJGZl9HajV9jd2dJFF10J30_YrPQo&s=sX1YilJaXloAQDzrjD3Lz-I6DOej3QduhsAanXOYxVM&e= Matthias Dr. Matthias St. Pierre Senior Software Engineer matthias.st.pierre at ncp-e.com Phone: +49 911 9968-0 www.ncp-e.com Headquarters Germany: NCP engineering GmbH ? Dombuehler Str. 2 ? 90449 ? Nuremberg North American HQ: NCP engineering Inc. ? 678 Georgia Ave. ? Sunnyvale, CA 94085 East Coast Office: NCP engineering Inc. ? 601 Cleveland Str., Suite 501-25 ? Clearwater, FL 33755 Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich Registry Court: Lower District Court of Nuremberg Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE 133557619 This e-mail message including any attachments is for the sole use of the intended recipient(s) and may contain privileged or confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply e-mail and delete the original message and destroy all copies thereof. ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From russellbell at gmail.com Thu Oct 3 12:32:48 2019 From: russellbell at gmail.com (russellbell at gmail.com) Date: Thu, 3 Oct 2019 06:32:48 -0600 Subject: error 114 Message-ID: <201910031232.x93CWm18002673@randytool.net> fetchmail fails when openssl reports an error 114 (I think) stat("/etc/ssl/certs/4a6481c9.0", {st_mode=S_IFREG|0644, st_size=1354, ...}) = 0 openat(AT_FDCWD, "/etc/ssl/certs/4a6481c9.0", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=1354, ...}) = 0 read(4, "-----BEGIN CERTIFICATE-----\nMIID"..., 4096) = 1354 read(4, "", 4096) = 0 close(4) = 0 stat("/etc/ssl/certs/4a6481c9.1", 0x7ffefc274100) = -1 ENOENT (No such file or directory) write(1, "fetchmail: SSL verify callback d"..., 71) = 71 write(1, "fetchmail: Certificate chain, fr"..., 70) = 70 write(1, "fetchmail: Issuer Organization: "..., 43) = 43 write(1, "fetchmail: Issuer CommonName: Gl"..., 41) = 41 write(1, "fetchmail: Subject CommonName: G"..., 42) = 42 write(1, "fetchmail: SSL verify callback d"..., 71) = 71 write(1, "fetchmail: Certificate at depth "..., 35) = 35 write(1, "fetchmail: Issuer Organization: "..., 43) = 43 write(1, "fetchmail: Issuer CommonName: Gl"..., 41) = 41 write(1, "fetchmail: Subject CommonName: G"..., 42) = 42 write(1, "fetchmail: SSL verify callback d"..., 71) = 71 write(1, "fetchmail: Server certificate:\n", 31) = 31 write(1, "fetchmail: Issuer Organization: "..., 54) = 54 write(1, "fetchmail: Issuer CommonName: GT"..., 41) = 41 write(1, "fetchmail: Subject CommonName: p"..., 45) = 45 write(1, "fetchmail: Subject Alternative N"..., 51) = 51 write(1, "fetchmail: pop.gmail.com key fin"..., 90) = 90 fstat(2, {st_mode=S_IFREG|0644, st_size=6732357, ...}) = 0 write(2, "fetchmail: pop.gmail.com fingerp"..., 52) = 52 write(3, "\25\3\3\0\2\2P", 7) = 7 write(2, "fetchmail: OpenSSL reported: err"..., 114) = 114 What is an error 114? Why does openssl look for /etc/ssl/certs/4a6481c9.1 ? All the hashes for my certs end in .0 Linux kernel 5.3.2, Slackware latest, fetchmail 6.4.1, OpenSSL 1.1.1d 10 Sep 2019 russell bell From jb-openssl at wisemo.com Thu Oct 3 13:07:11 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 3 Oct 2019 15:07:11 +0200 Subject: error 114 In-Reply-To: <201910031232.x93CWm18002673@randytool.net> References: <201910031232.x93CWm18002673@randytool.net> Message-ID: <663a6c38-758c-7947-57fb-2ff9fb6a1719@wisemo.com> On 03/10/2019 14:32, russellbell at gmail.com wrote: > fetchmail fails when openssl reports an error 114 (I think) > > stat("/etc/ssl/certs/4a6481c9.0", {st_mode=S_IFREG|0644, st_size=1354, ...}) = 0 > openat(AT_FDCWD, "/etc/ssl/certs/4a6481c9.0", O_RDONLY) = 4 > fstat(4, {st_mode=S_IFREG|0644, st_size=1354, ...}) = 0 > read(4, "-----BEGIN CERTIFICATE-----\nMIID"..., 4096) = 1354 > read(4, "", 4096) = 0 > close(4) = 0 > stat("/etc/ssl/certs/4a6481c9.1", 0x7ffefc274100) = -1 ENOENT (No such file or directory) > write(1, "fetchmail: SSL verify callback d"..., 71) = 71 > write(1, "fetchmail: Certificate chain, fr"..., 70) = 70 > write(1, "fetchmail: Issuer Organization: "..., 43) = 43 > write(1, "fetchmail: Issuer CommonName: Gl"..., 41) = 41 > write(1, "fetchmail: Subject CommonName: G"..., 42) = 42 > write(1, "fetchmail: SSL verify callback d"..., 71) = 71 > write(1, "fetchmail: Certificate at depth "..., 35) = 35 > write(1, "fetchmail: Issuer Organization: "..., 43) = 43 > write(1, "fetchmail: Issuer CommonName: Gl"..., 41) = 41 > write(1, "fetchmail: Subject CommonName: G"..., 42) = 42 > write(1, "fetchmail: SSL verify callback d"..., 71) = 71 > write(1, "fetchmail: Server certificate:\n", 31) = 31 > write(1, "fetchmail: Issuer Organization: "..., 54) = 54 > write(1, "fetchmail: Issuer CommonName: GT"..., 41) = 41 > write(1, "fetchmail: Subject CommonName: p"..., 45) = 45 > write(1, "fetchmail: Subject Alternative N"..., 51) = 51 > write(1, "fetchmail: pop.gmail.com key fin"..., 90) = 90 > fstat(2, {st_mode=S_IFREG|0644, st_size=6732357, ...}) = 0 > write(2, "fetchmail: pop.gmail.com fingerp"..., 52) = 52 > write(3, "\25\3\3\0\2\2P", 7) = 7 > write(2, "fetchmail: OpenSSL reported: err"..., 114) = 114 > > > What is an error 114? Why does openssl look for > /etc/ssl/certs/4a6481c9.1 ? All the hashes for my certs end in .0 > > Linux kernel 5.3.2, Slackware latest, fetchmail 6.4.1, OpenSSL 1.1.1d 10 Sep 2019 > This looks like the output of running strace on fetchmail. 114 in the last line is just the number of characters in the error message printed by fetchmail, the first 33 of those 114 characters are "fetchmail: OpenSSL reported: err", the remaining 81 are not shown above. The hashed name ending in ".1" is OpenSSL looking to see if you have more than one cert with the hash value 4a6481c9, which does happen for some users.? If you had such a second cert, OpenSSL wouldalso load 4a6481c9.2, then 4a6481c9.3 and so on until it reaches a name you don't have. 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 matt at openssl.org Thu Oct 3 13:21:01 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 3 Oct 2019 14:21:01 +0100 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: <2b8035491b1d40668758b78936fab706@Ex13.ncp.local> Message-ID: <2739d542-13a2-4778-47fd-c45b45492f37@openssl.org> On 03/10/2019 11:10, Nagalakshmi V J wrote: > Hi Matthias, > > ? > > Please find my response for your queries below. > > ? > > It would be more helpful if you would tell us *why* you are including ssl_locl.h > and what you are trying to achieve. Then we might be able to tell you how you > could achieve your goal using the officially supported API. > > [Nagalakshmi]: > > In our product code, we are using the structures 'ssl_st' ?and 'ssl_session_st' > which were defined in ssl.h file in Openssl 1.0.2.j version. > > Since the structure definitions are made opaque in openssl 1.1.1c, we used > ssl_locl.h where the structure definitions are available. > > ? > > Please note that many of the OpenSSL structures were made opaque in version > 1.1.0. This means that there are only forward declarations of the structures in > the public headers and the compiler does not get to? see the structure members. > Instead of directly accessing the members, it is now necessary to use accessor > functions (a.k.a. getters and setters). > > [Nagalakshmi]: > > Regarding usage of accessor functions, I got the following APIs. > > SSL_get_session(s) > > SSL_SESSION_get_master_key(). > > ? > > If we use those APIs, I am again getting errors like the below. > > /.\odlibPrf_OSSL.h(164) : error C2027: use of undefined type 'ssl_session_st'/ > > /??????? ..\..\OpenSSL\openssl-1.1.1c\include\openssl/ssl.h(213) : see > declaration of 'ssl_session_st'/ > > /.\odlibPrf_OSSL.h(164) : error C2227: left of '->SSL_SESSION_get_master_key' > must point to class/struct/union/ This at least looks like a syntax error. > > /.\odlibPrf_OSSL.h(167) : error C2027: use of undefined type 'ssl_st'/ > > /??????? ..\..\OpenSSL\openssl-1.1.1c\include\openssl/ossl_typ.h(147) : see > declaration of 'ssl_st'/ > > /.\odlibPrf_OSSL.h(167) : error C2227: left of '->session' must point to > class/struct/union/ > > /.\odlibPrf_OSSL.h(167) : error C2227: left of '->master_key' must point to > class/struct/union/ These suggest you're still trying to direct access structure members. > > /.\odlibPrf_OSSL.h(168) : error C2027: use of undefined type 'ssl_st'/ Please show us the source code for the lines these error message correspond to. Matt > > ? > > Can you help me to get the corresponding accessor functions for these 2 structures. > > ? > > Thanks and regards, > > Nagalakshmi > > ? > > -----Original Message----- > From: Nagalakshmi V J > Sent: Tuesday, October 1, 2019 6:33 PM > To: Dr. Matthias St. Pierre ; Nagalakshmi V J > > Cc: openssl-users at openssl.org; Umamaheswari Nagarajan > > Subject: RE: OpenSSL compilation errors in Windows > > ? > > Thank you Matthias for the explanation. I am going through my code to understand > why ssl_locl.h is included. I will check and get back on this ASAP. Also if > there is other way to achieve that I will use the same. > > ? > > Thanks and regards, > > Nagalakshmi > > ? > > -----Original Message----- > > From: Dr. Matthias St. Pierre > > > Sent: Tuesday, October 1, 2019 4:43 PM > > To: Nagalakshmi V J > > > Cc: openssl-users at openssl.org ; Umamaheswari > Nagarajan > > > Subject: AW: OpenSSL compilation errors in Windows > > ? > > ** This mail has been sent from an external source ** > > ? > > ? > >> We are using OpenSSL APIs in our product code. We are not making any changes > in OpenSSL. > >> Our product code is a C++ code and it makes use of openSSL APIs for some > functionality. > > ? > > Local headers (like "ssl_locl.h" and "packet_locl.h") are *NOT* part of the > official OpenSSL API. > > Please don't expect any support w.r.t. compilation or compatibility problems if > you do include them in your application, even more if it's compiled using a C++ > compiler. > > ? > > It would be more helpful if you would tell us *why* you are including ssl_locl.h > and what you are trying to achieve. Then we might be able to tell you how you > could achieve your goal using the officially supported API. > > ? > > Please note that many of the OpenSSL structures were made opaque in version > 1.1.0. This means that there are only forward declarations of the structures in > the public headers and the compiler does not get to? see the structure members. > Instead of directly accessing the members, it is now necessary to use accessor > functions (a.k.a. getters and setters). If this is the reason why you are > including private OpenSSL headers then you should adopt you application to use > the new accessors instead, instead of forcing the impossible to circumvent the > new policy. > > ? > > For more information, see > > ? > > https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openssl.org_index.php_OpenSSL-5F1.1.0-5FChanges&d=DwIGaQ&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=wpEV8Q2RDZjERhtJGZl9HajV9jd2dJFF10J30_YrPQo&s=sX1YilJaXloAQDzrjD3Lz-I6DOej3QduhsAanXOYxVM&e= > > ? > > Matthias > > ? > > ? > > ? > > ? > > ? > > Dr. Matthias St. Pierre > > Senior Software Engineer > > matthias.st.pierre at ncp-e.com > > Phone: +49 911 9968-0 > > www.ncp-e.com > > ? > > Headquarters Germany: NCP engineering GmbH ? Dombuehler Str. 2 ? 90449 ? > Nuremberg North American HQ: NCP engineering Inc. ? 678 Georgia Ave. ? > Sunnyvale, CA 94085 East Coast Office: NCP engineering Inc. ? 601 Cleveland > Str., Suite 501-25 ? Clearwater, FL 33755 > > ? > > Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich > Registry Court: Lower District Court of Nuremberg Commercial register No.: HRB > 7786 Nuremberg, VAT identification No.: DE 133557619 > > ? > > This e-mail message including any attachments is for the sole use of the > intended recipient(s) and may contain privileged or confidential information. > Any unauthorized review, use, disclosure or distribution is prohibited. If you > are not the intended recipient, please immediately contact the sender by reply > e-mail and delete the original message and destroy all copies thereof. > > ===================================================== > > Please refer to https://northamerica.altran.com/email-disclaimer > > for important disclosures regarding this electronic communication. > > ===================================================== > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== From vcizek at suse.com Thu Oct 3 13:04:05 2019 From: vcizek at suse.com (Vitezslav Cizek) Date: Thu, 3 Oct 2019 15:04:05 +0200 Subject: error 114 In-Reply-To: <201910031232.x93CWm18002673@randytool.net> References: <201910031232.x93CWm18002673@randytool.net> Message-ID: <20191003150405.4aaeead5@zvon.suse.cz> V Thu, 3 Oct 2019 06:32:48 -0600 naps?no: > fetchmail fails when openssl reports an error 114 (I think) Actually it doesn't. > stat("/etc/ssl/certs/4a6481c9.0", {st_mode=S_IFREG|0644, > st_size=1354, ...}) = 0 openat(AT_FDCWD, "/etc/ssl/certs/4a6481c9.0", > O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=1354, ...}) = 0 > read(4, "-----BEGIN CERTIFICATE-----\nMIID"..., 4096) = 1354 > read(4, "", 4096) = 0 > close(4) = 0 > stat("/etc/ssl/certs/4a6481c9.1", 0x7ffefc274100) = -1 ENOENT (No > such file or directory) write(1, "fetchmail: SSL verify callback > d"..., 71) = 71 write(1, "fetchmail: Certificate chain, fr"..., 70) = > 70 write(1, "fetchmail: Issuer Organization: "..., 43) = 43 > write(1, "fetchmail: Issuer CommonName: Gl"..., 41) = 41 > write(1, "fetchmail: Subject CommonName: G"..., 42) = 42 > write(1, "fetchmail: SSL verify callback d"..., 71) = 71 > write(1, "fetchmail: Certificate at depth "..., 35) = 35 > write(1, "fetchmail: Issuer Organization: "..., 43) = 43 > write(1, "fetchmail: Issuer CommonName: Gl"..., 41) = 41 > write(1, "fetchmail: Subject CommonName: G"..., 42) = 42 > write(1, "fetchmail: SSL verify callback d"..., 71) = 71 > write(1, "fetchmail: Server certificate:\n", 31) = 31 > write(1, "fetchmail: Issuer Organization: "..., 54) = 54 > write(1, "fetchmail: Issuer CommonName: GT"..., 41) = 41 > write(1, "fetchmail: Subject CommonName: p"..., 45) = 45 > write(1, "fetchmail: Subject Alternative N"..., 51) = 51 > write(1, "fetchmail: pop.gmail.com key fin"..., 90) = 90 > fstat(2, {st_mode=S_IFREG|0644, st_size=6732357, ...}) = 0 > write(2, "fetchmail: pop.gmail.com fingerp"..., 52) = 52 > write(3, "\25\3\3\0\2\2P", 7) = 7 > write(2, "fetchmail: OpenSSL reported: err"..., 114) = 114 > > What is an error 114? 114 isn't an openssl error number, it's the amount of bytes the write() syscall wrote. Run strace -s1024 to get the whole error string. > Why does openssl look for > /etc/ssl/certs/4a6481c9.1 ? All the hashes for my certs end in .0 During c_rehash, if a certificate object has the same hash value as an existing one, the last digit number is incremented to distinguish it. So by looking for 4a6481c9.1, openssl is checking against a possible conflict in the hashes. > russell bell Vita -- V?t?zslav ???ek Emergency Update Team (EMU) "Consider it fixed." From matt at openssl.org Thu Oct 3 13:24:59 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 3 Oct 2019 14:24:59 +0100 Subject: Windows 10 run-time issue In-Reply-To: References: <5ADFF93892EDB147B66FCBABC8E4F27F16292D00@prgmbx01> Message-ID: On 03/10/2019 00:50, Andy Kennedy wrote: > So, I connect to the app with the VS debugger and find:____ > > file: pki_crypto.c:____ > > function:? pki_signature_from_ecdsa_blob()____ > > line: (1769) SAFE_FREE(raw_sig_data);____ These symbols all appear to be libssh symbols so I don't think we can really advise you on this. Your question might be better posted on a libssh forum. Matt From andy.kennedy.1814 at gmail.com Thu Oct 3 15:19:39 2019 From: andy.kennedy.1814 at gmail.com (Andy Kennedy) Date: Thu, 3 Oct 2019 10:19:39 -0500 Subject: Windows 10 run-time issue In-Reply-To: References: <5ADFF93892EDB147B66FCBABC8E4F27F16292D00@prgmbx01> Message-ID: Please excuse the top post, replying from my cell phone. And so it is. My bad! Andy On Thu, Oct 3, 2019, 8:25 AM Matt Caswell wrote: > > > On 03/10/2019 00:50, Andy Kennedy wrote: > > > So, I connect to the app with the VS debugger and find:____ > > > > file: pki_crypto.c:____ > > > > function: pki_signature_from_ecdsa_blob()____ > > > > line: (1769) SAFE_FREE(raw_sig_data);____ > > These symbols all appear to be libssh symbols so I don't think we can > really > advise you on this. Your question might be better posted on a libssh forum. > > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeykalyan at gmail.com Fri Oct 4 13:58:20 2019 From: jeykalyan at gmail.com (Kalyan Kumar) Date: Fri, 4 Oct 2019 19:28:20 +0530 Subject: Generate X509 version 2 certificate Message-ID: Hi, We are trying to qualify a feature which can consume ca signed certificate . Part of this we verified X509 v3 and v1 but unable to get the actual attributes for v2 creation. Is this feasible in openssl and also whether standard supports ? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Oct 4 14:16:52 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 4 Oct 2019 10:16:52 -0400 Subject: Generate X509 version 2 certificate In-Reply-To: References: Message-ID: <20191004141652.GD21772@straasha.imrryr.org> On Fri, Oct 04, 2019 at 07:28:20PM +0530, Kalyan Kumar wrote: > We are trying to qualify a feature which can consume ca signed certificate > . Part of this we verified X509 v3 and v1 but unable to get the actual > attributes for v2 creation. > > Is this feasible in openssl and also whether standard supports ? Nobody uses X.509v2 certificates. In the context of X.509, the successor of 1 is effectively 3, there is no "2". https://blogs.technet.microsoft.com/option_explicit/2012/04/09/pki-certificates-and-the-x-509-standard/ Version 2 (ITU-T Recommendation X.509, Nov 1993 http://www.itu.int/rec/T-REC-X.509-199311-S) Version 2 of the X.509 certificate was very short-lived and rarely used. In fact, the Internet Engineering Task Force (IETF) did not turn version 2 of the certificate into a RFC standard whatsoever. [...] -- Viktor. From dheinz at softwarekey.com Mon Oct 7 15:19:26 2019 From: dheinz at softwarekey.com (Dan Heinz) Date: Mon, 7 Oct 2019 15:19:26 +0000 Subject: Linux linking issues moving from 1.0.2t to 1.1.1c Message-ID: Please bear with me as I am a Windows developer, and not too adept with Linux. Our library has been using the OpenSSL 1.0.2x branch, and we are moving to 1.1.1c. I have the Windows build of our libraries working, and now I've moved to Linux. Our library is built as a shared library as well as static library and both use the static OpenSSL library (we archive the OpenSSL static library with our static library). When I built our shared library I had some linker errors: e/Debug32/mylib.so: undefined reference to `dlopen' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_rwlock_rdlock' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_rwlock_init' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_getspecific' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_rwlock_destroy' ../../MyLib/Debug32/libMyLib.so: undefined reference to `dlclose' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_key_create' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_rwlock_wrlock' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_once' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_atfork' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_setspecific' ../../MyLib/Debug32/libMyLib.so: undefined reference to `dlerror' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_rwlock_unlock' ../../MyLib/Debug32/libMyLib.so: undefined reference to `dlsym' ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_key_delete' ../../MyLib/Debug32/libMyLib.so: undefined reference to `dladdr' And the Configuration line from our build script: ./Configure linux-x86_64 --prefix=$install_path/openssl_64 -DPURIFY -DOPENSSL_NO_COMP no-shared no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp no-afalgeng no-pinshared As our library does not use multiple threads, I can build the OpenSSL library with the no-threads configuration parameter to remove the pthread references. Is there anything I should be aware of when doing so? For the dlopen, dlclose, dlerror,dlsym, and dladdr references, it seems I need to link libld using -ldl. Isn't the no-dso configuration option supposed to remove the need for this library? Is there a way to do so with 1.1.1c? While I can link this in our shared library, our static library will require anyone using our library to link libld. I'd like to avoid this if possible, and it seems we could with the 1.0.2 branch. Am I missing something here? Thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Oct 7 19:07:53 2019 From: levitte at openssl.org (Richard Levitte) Date: Mon, 07 Oct 2019 21:07:53 +0200 Subject: Linux linking issues moving from 1.0.2t to 1.1.1c In-Reply-To: References: Message-ID: <87muecjrw6.wl-levitte@openssl.org> The no-dso is silently not valid in 1.1.1c. That option didn't work right, so it was unusable in practice anyway. However, someone recently fixed that up, unfortunately after the last 1.1.1 release. The specific patch may be possible to find on github (unless that branch has been deleted), otherwise you will have to cherry-pick the appropriate commit. Github PR: https://github.com/openssl/openssl/pull/9889 Commit ID: 8dcd57461972dceaaf014b71d173d0a8758e7054 Cheers, Richard On Mon, 07 Oct 2019 17:19:26 +0200, Dan Heinz wrote: > > > Please bear with me as I am a Windows developer, and not too adept with Linux. > > Our library has been using the OpenSSL 1.0.2x branch, and we are moving to 1.1.1c. I have the > Windows build of our libraries working, and now I?ve moved to Linux. > > Our library is built as a shared library as well as static library and both use the static OpenSSL > library (we archive the OpenSSL static library with our static library). > > When I built our shared library I had some linker errors: > e/Debug32/mylib.so: undefined reference to `dlopen' > > ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_rwlock_rdlock' > > ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_rwlock_init' > > ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_getspecific' > > ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_rwlock_destroy' > > ../../MyLib/Debug32/libMyLib.so: undefined reference to `dlclose' > > ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_key_create' > > ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_rwlock_wrlock' > > ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_once' > > ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_atfork' > > ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_setspecific' > > ../../MyLib/Debug32/libMyLib.so: undefined reference to `dlerror' > > ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_rwlock_unlock' > > ../../MyLib/Debug32/libMyLib.so: undefined reference to `dlsym' > > ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_key_delete' > > ../../MyLib/Debug32/libMyLib.so: undefined reference to `dladdr' > > And the Configuration line from our build script: > ./Configure linux-x86_64 --prefix=$install_path/openssl_64 -DPURIFY -DOPENSSL_NO_COMP no-shared > no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp no-afalgeng no-pinshared > > As our library does not use multiple threads, I can build the OpenSSL library with the no-threads > configuration parameter to remove the pthread references. Is there anything I should be aware of > when doing so? > > For the dlopen, dlclose, dlerror,dlsym, and dladdr references, it seems I need to link libld using > -ldl. Isn?t the no-dso configuration option supposed to remove the need for this library? Is > there a way to do so with 1.1.1c? While I can link this in our shared library, our static library > will require anyone using our library to link libld. I?d like to avoid this if possible, and it > seems we could with the 1.0.2 branch. > > Am I missing something here? > > Thanks in advance! > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From dheinz at softwarekey.com Mon Oct 7 19:55:50 2019 From: dheinz at softwarekey.com (Dan Heinz) Date: Mon, 7 Oct 2019 19:55:50 +0000 Subject: Linux linking issues moving from 1.0.2t to 1.1.1c In-Reply-To: <87muecjrw6.wl-levitte@openssl.org> References: <87muecjrw6.wl-levitte@openssl.org> Message-ID: >The no-dso is silently not valid in 1.1.1c. That option didn't work right, so it was unusable in practice anyway. However, someone recently fixed that up, unfortunately after the last 1.1.1 release. >The specific patch may be possible to find on github (unless that branch has been deleted), otherwise you will have to cherry-pick the appropriate commit. >Github PR: https://github.com/openssl/openssl/pull/9889 >Commit ID: 8dcd57461972dceaaf014b71d173d0a8758e7054 >Cheers, >Richard Thanks for the info. I did some more digging and you had actually posted a workaround in this thread: https://github.com/openssl/openssl/issues/9036 I thought I would try it out. I used your example and created my own config target in file named no_dos.conf. ( 'my-linux-x86_64' => { inherit_from => [ 'linux-x86_64' ], dso_scheme => undef, } ); ./Configure --config ../no_dso.conf my-linux-x86_64 -m32 --prefix=$install_path/openssl_32 -DPURIFY -DOPENSSL_NO_COMP no-asm no-shared no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp no-afalgeng no-pinshared But I'm getting this error from the script when Configure is run: target already defined - ../no_dso.conf (offending arg: my-linux-x86_64) What did I miss? From space.ship.traveller at gmail.com Mon Oct 7 23:20:05 2019 From: space.ship.traveller at gmail.com (Samuel Williams) Date: Tue, 8 Oct 2019 12:20:05 +1300 Subject: OPENSSL_config vs OPENSSL_init_crypto Message-ID: Hello, I am trying to understand what is the correct initialization process for Ruby's SSL module. It's not my area so any input would be most welcome. https://github.com/ruby/openssl/pull/267 Thanks, Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Oct 8 07:34:07 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 8 Oct 2019 08:34:07 +0100 Subject: OPENSSL_config vs OPENSSL_init_crypto In-Reply-To: References: Message-ID: <9b6f88dd-2736-591d-a468-5fa2f1f62731@openssl.org> On 08/10/2019 00:20, Samuel Williams wrote: > Hello, > > I am trying to understand what is the correct initialization?process for Ruby's > SSL module. It's not my area so any input would be most welcome. > > https://github.com/ruby/openssl/pull/267 Reading that PR it seems your objective is to ensure that the config file is loaded before you do any libssl work. How OpenSSL behaves depends on the version. Note that OpenSSL 1.1.0 is now out of support, and OpenSSL 1.0.2 goes out of support at the end of this year. >From OpenSSL 1.1.0 and onwards OpenSSL auto-initialises so, in most cases, there is no need to explicitly call initialisation functions such as OPENSSL_init_crypto() or OPENSSL_init_ssl(). The only reason for applications to ever call these functions directly is if you want some non-default initialisation to occur. I notice that Ruby's SSL module is explicitly calling OPENSSL_init_ssl() with 0 and NULL for arguments - which just gives you the default initialisation. There seems little point in this - that will happen automatically the first time you create an SSL_CTX. >From OpenSSL 1.1.1 onwards loading the config file is part of libssl's default initialisation, i.e. as soon as you create an SSL_CTX OPENSSL_init_ssl() is called automatically and the config file is loaded. Therefore there is no need to take any specific action on this version of OpenSSL. In OpenSSL 1.1.0 (which is now out of support), loading the config file was *not* part of the default initialisation. You can force it to be loaded using the OPENSSL_INIT_LOAD_CONFIG option to OPENSSL_init_ssl(): OPENSSL_init_ssl(OPENSSL_INIT_LOAD_CONFIG, NULL); You *may* choose to do this unconditionally in both 1.1.0 and 1.1.1 if you wish. In 1.1.1 it has no effect because that's the default anyway - but it does no harm. OpenSSL 1.0.2 (out of support from the end of this year) does not automatically initialise/de-initialise and OPENSSL_init_crypto() and OPENSSL_init_ssl() do not even exist. Therefore you have to call initialisation functions explicitly. Calling OPENSSL_config() there would seem reasonable. Hope that helps, Matt From mcr at sandelman.ca Tue Oct 8 09:23:56 2019 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 08 Oct 2019 05:23:56 -0400 Subject: debian openssh issue with openssl 1.1.1d Message-ID: <22446.1570526636@localhost> Salvatore Bonaccorso wrote: > ------------------------------------------------------------------------- > Debian Security Advisory DSA-4539-2 security at debian.org > https://www.debian.org/security/ Salvatore Bonaccorso > October 07, 2019 https://www.debian.org/security/faq > ------------------------------------------------------------------------- > Package : openssh > Debian Bug : 941663 > A change introduced in openssl 1.1.1d (which got released as DSA 4539-1) > requires sandboxing features which are not available in Linux kernels > before 3.19, resulting in OpenSSH rejecting connection attempts if I've gone through the changelog for 1.1.1d, but I can't figure out what 1.1.1d would have changed that would have caused this. -- ] 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 [ From bkaduk at akamai.com Tue Oct 8 10:27:17 2019 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 8 Oct 2019 03:27:17 -0700 Subject: debian openssh issue with openssl 1.1.1d In-Reply-To: <22446.1570526636@localhost> References: <22446.1570526636@localhost> Message-ID: <20191008102717.GN13477@akamai.com> On Tue, Oct 08, 2019 at 05:23:56AM -0400, Michael Richardson wrote: > Salvatore Bonaccorso wrote: > > ------------------------------------------------------------------------- > > Debian Security Advisory DSA-4539-2 security at debian.org > > https://www.debian.org/security/ Salvatore Bonaccorso > > October 07, 2019 https://www.debian.org/security/faq > > ------------------------------------------------------------------------- > > > Package : openssh > > Debian Bug : 941663 > > > A change introduced in openssl 1.1.1d (which got released as DSA 4539-1) > > requires sandboxing features which are not available in Linux kernels > > before 3.19, resulting in OpenSSH rejecting connection attempts if > > I've gone through the changelog for 1.1.1d, but I can't figure out what > 1.1.1d would have changed that would have caused this. The RNG uses sysV shm to convey to other processes that /dev/[u]random has been properly seeded, under some configurations/kernel versions. -Ben From levitte at openssl.org Tue Oct 8 12:59:23 2019 From: levitte at openssl.org (Richard Levitte) Date: Tue, 08 Oct 2019 14:59:23 +0200 Subject: Linux linking issues moving from 1.0.2t to 1.1.1c In-Reply-To: References: <87muecjrw6.wl-levitte@openssl.org> Message-ID: <87lftvjsus.wl-levitte@openssl.org> On Mon, 07 Oct 2019 21:55:50 +0200, Dan Heinz wrote: > > >The no-dso is silently not valid in 1.1.1c. That option didn't work right, so it was unusable in practice anyway. However, someone recently fixed that up, unfortunately after the last 1.1.1 release. > >The specific patch may be possible to find on github (unless that branch has been deleted), otherwise you will have to cherry-pick the appropriate commit. > > >Github PR: https://github.com/openssl/openssl/pull/9889 > >Commit ID: 8dcd57461972dceaaf014b71d173d0a8758e7054 > > >Cheers, > >Richard > > Thanks for the info. I did some more digging and you had actually posted a workaround in this thread: > https://github.com/openssl/openssl/issues/9036 > > I thought I would try it out. > I used your example and created my own config target in file named no_dos.conf. > ( > 'my-linux-x86_64' => { > inherit_from => [ 'linux-x86_64' ], > dso_scheme => undef, > } > ); > > ./Configure --config ../no_dso.conf my-linux-x86_64 -m32 --prefix=$install_path/openssl_32 -DPURIFY -DOPENSSL_NO_COMP no-asm no-shared no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp no-afalgeng no-pinshared > > But I'm getting this error from the script when Configure is run: > target already defined - ../no_dso.conf (offending arg: my-linux-x86_64) > > What did I miss? You don't happen to have edited some Configurations/*.conf and added that name already? I'm otherwise unsure for the moment. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From wouter.van.hemel at helsinki.fi Tue Oct 8 13:44:23 2019 From: wouter.van.hemel at helsinki.fi (van Hemel, Wouter J M) Date: Tue, 8 Oct 2019 13:44:23 +0000 Subject: Blake2b with key Message-ID: Hello, I'm trying to create a blake2b512 digest with a key. I've made an attempt to follow the source code and I'm assuming the algorithm's name for blake2b MAC is blake2bmac, though I have tried different values. I don't seem to be able to create a valid checksum: $ openssl version; echo -n "hello" | openssl dgst -blake2b512 -mac blake2bmac -macopt key:secret OpenSSL 1.1.1d 10 Sep 2019 Algorithm blake2bmac not found Is keyed blake2b supported in openssl-dgst (latest OpenSSL release)? Thanks! From levitte at openssl.org Tue Oct 8 14:45:16 2019 From: levitte at openssl.org (Richard Levitte) Date: Tue, 08 Oct 2019 16:45:16 +0200 Subject: Linux linking issues moving from 1.0.2t to 1.1.1c In-Reply-To: <87lftvjsus.wl-levitte@openssl.org> References: <87muecjrw6.wl-levitte@openssl.org> <87lftvjsus.wl-levitte@openssl.org> Message-ID: <87k19fjnyb.wl-levitte@openssl.org> On Tue, 08 Oct 2019 14:59:23 +0200, Richard Levitte wrote: > > On Mon, 07 Oct 2019 21:55:50 +0200, > Dan Heinz wrote: > > > > >The no-dso is silently not valid in 1.1.1c. That option didn't work right, so it was unusable in practice anyway. However, someone recently fixed that up, unfortunately after the last 1.1.1 release. > > >The specific patch may be possible to find on github (unless that branch has been deleted), otherwise you will have to cherry-pick the appropriate commit. > > > > >Github PR: https://github.com/openssl/openssl/pull/9889 > > >Commit ID: 8dcd57461972dceaaf014b71d173d0a8758e7054 > > > > >Cheers, > > >Richard > > > > Thanks for the info. I did some more digging and you had actually posted a workaround in this thread: > > https://github.com/openssl/openssl/issues/9036 > > > > I thought I would try it out. > > I used your example and created my own config target in file named no_dos.conf. > > ( > > 'my-linux-x86_64' => { > > inherit_from => [ 'linux-x86_64' ], > > dso_scheme => undef, > > } > > ); > > > > ./Configure --config ../no_dso.conf my-linux-x86_64 -m32 --prefix=$install_path/openssl_32 -DPURIFY -DOPENSSL_NO_COMP no-asm no-shared no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp no-afalgeng no-pinshared > > > > But I'm getting this error from the script when Configure is run: > > target already defined - ../no_dso.conf (offending arg: my-linux-x86_64) > > > > What did I miss? > > You don't happen to have edited some Configurations/*.conf and added > that name already? I'm otherwise unsure for the moment. Figured it out. Configure requires that '--config' be joined to its value with an equal sign. In other words, this slight variation works: ./Configure --config=../no_dso.conf my-linux-x86_64 -m32 --prefix=$install_path/openssl_32 -DPURIFY -DOPENSSL_NO_COMP no-asm no-shared no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp no-afalgeng no-pinshared Cheers, Richard ( is just a messenger in this case, yeah? ) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Tue Oct 8 14:48:14 2019 From: levitte at openssl.org (Richard Levitte) Date: Tue, 08 Oct 2019 16:48:14 +0200 Subject: Blake2b with key In-Reply-To: References: Message-ID: <87imozjntd.wl-levitte@openssl.org> On Tue, 08 Oct 2019 15:44:23 +0200, van Hemel, Wouter J M wrote: > > Hello, > > I'm trying to create a blake2b512 digest with a key. I've made an attempt to follow the source code and I'm assuming the algorithm's name for blake2b MAC is blake2bmac, though I have tried different values. I don't seem to be able to create a valid checksum: > > $ openssl version; echo -n "hello" | openssl dgst -blake2b512 -mac blake2bmac -macopt key:secret > OpenSSL 1.1.1d 10 Sep 2019 > Algorithm blake2bmac not found > > Is keyed blake2b supported in openssl-dgst (latest OpenSSL release)? No, sorry. It has been added for upcoming OpenSSL 3.0, though. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From uri at ll.mit.edu Tue Oct 8 15:15:22 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 8 Oct 2019 15:15:22 +0000 Subject: Blake2b with key In-Reply-To: References: <87imozjntd.wl-levitte@openssl.org> Message-ID: <668BCC92-B52D-4BFC-B677-75864274AD82@ll.mit.edu> Answered my own questions: $ openssl3 list -mac-algorithms Provided MACs: BLAKE2bMAC @ default BLAKE2sMAC @ default CMAC @ default GMAC @ default HMAC @ default KMAC128 @ default KMAC256 @ default Poly1305 @ default SipHash @ default $ $ echo -n "hello" | openssl3 mac -macopt key:secret blake2bmac 6EDF9AA44DFC7590DE00FCFDBE2F0D917CDEEB170301416929CC625D19D24EDC1040FF760C1F9BB61AD439A0AF5D492FBB01B46ED3FEB4E6076383B7885A9486 $ ?On 10/8/19, 11:03 AM, "Uri Blumenthal" wrote: > > Is keyed blake2b supported in openssl-dgst (latest OpenSSL release)? > No, sorry. It has been added for upcoming OpenSSL 3.0, though. Doesn't look like it's there: $ openssl3 version OpenSSL 3.0.0-dev xx XXX xxxx (Library: OpenSSL 3.0.0-dev xx XXX xxxx) $ echo -n "hello" | openssl3 dgst -blake2b512 BLAKE2b512(stdin)= e4cfa39a3d37be31c59609e807970799caa68a19bfaa15135f165085e01d41a65ba1e1b146aeb6bd0092b49eac214c103ccfa3a365954bbbe52f74a2b3620c94 $ echo -n "hello" | openssl3 dgst -blake2b512 -mac blake2bmac -macopt key:secret Algorithm blake2bmac not found $ Besides, how does one print a list of supported MAC algorithms? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4933 bytes Desc: not available URL: From uri at ll.mit.edu Tue Oct 8 15:03:45 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 8 Oct 2019 15:03:45 +0000 Subject: Blake2b with key In-Reply-To: <87imozjntd.wl-levitte@openssl.org> References: <87imozjntd.wl-levitte@openssl.org> Message-ID: > > Is keyed blake2b supported in openssl-dgst (latest OpenSSL release)? > No, sorry. It has been added for upcoming OpenSSL 3.0, though. Doesn't look like it's there: $ openssl3 version OpenSSL 3.0.0-dev xx XXX xxxx (Library: OpenSSL 3.0.0-dev xx XXX xxxx) $ echo -n "hello" | openssl3 dgst -blake2b512 BLAKE2b512(stdin)= e4cfa39a3d37be31c59609e807970799caa68a19bfaa15135f165085e01d41a65ba1e1b146aeb6bd0092b49eac214c103ccfa3a365954bbbe52f74a2b3620c94 $ echo -n "hello" | openssl3 dgst -blake2b512 -mac blake2bmac -macopt key:secret Algorithm blake2bmac not found $ Besides, how does one print a list of supported MAC algorithms? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4933 bytes Desc: not available URL: From dheinz at softwarekey.com Tue Oct 8 16:53:37 2019 From: dheinz at softwarekey.com (Dan Heinz) Date: Tue, 8 Oct 2019 16:53:37 +0000 Subject: Linux linking issues moving from 1.0.2t to 1.1.1c In-Reply-To: <87k19fjnyb.wl-levitte@openssl.org> References: <87muecjrw6.wl-levitte@openssl.org> <87lftvjsus.wl-levitte@openssl.org> <87k19fjnyb.wl-levitte@openssl.org> Message-ID: > > > >The no-dso is silently not valid in 1.1.1c. That option didn't work right, so it was unusable in practice anyway. However, someone recently fixed that up, unfortunately after the last 1.1.1 release. > > > >The specific patch may be possible to find on github (unless that branch has been deleted), otherwise you will have to cherry-pick the appropriate commit. > > > > > > >Github PR: https://github.com/openssl/openssl/pull/9889 > > > >Commit ID: 8dcd57461972dceaaf014b71d173d0a8758e7054 > > > > > > >Cheers, > > > >Richard > > > > > > Thanks for the info. I did some more digging and you had actually posted a workaround in this thread: > > > https://github.com/openssl/openssl/issues/9036 > > > > > > I thought I would try it out. > > > I used your example and created my own config target in file named no_dos.conf. > > > ( > > > 'my-linux-x86_64' => { > > > inherit_from => [ 'linux-x86_64' ], > > > dso_scheme => undef, > > > } > > > ); > > > > > > ./Configure --config ../no_dso.conf my-linux-x86_64 -m32 > > > --prefix=$install_path/openssl_32 -DPURIFY -DOPENSSL_NO_COMP no-asm > > > no-shared no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib > > > no-comp no-afalgeng no-pinshared > > > > > > But I'm getting this error from the script when Configure is run: > > > target already defined - ../no_dso.conf (offending arg: > > > my-linux-x86_64) > > > > > > What did I miss? > > > > You don't happen to have edited some Configurations/*.conf and added > > that name already? I'm otherwise unsure for the moment. > > Figured it out. Configure requires that '--config' be joined to its value with an equal sign. In other words, this slight variation > works: > >./Configure --config=../no_dso.conf my-linux-x86_64 -m32 --prefix=$install_path/openssl_32 -DPURIFY -DOPENSSL_NO_COMP no-asm no-shared no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp no-afalgeng no-pinshared > Thank you! That seems to have fixed things up nicely, and I no longer need to link libdl when linking my library. Another question is why I now need to link pthreads when I did not in the 1.0.2 version? I've added no-threads to the configuration, but I'm curious why I didn't need to previously link it. And I'd prefer not to change too many configuration parameters if possible. From openssl-users at dukhovni.org Tue Oct 8 17:51:18 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 8 Oct 2019 13:51:18 -0400 Subject: debian openssh issue with openssl 1.1.1d In-Reply-To: <20191008102717.GN13477@akamai.com> References: <22446.1570526636@localhost> <20191008102717.GN13477@akamai.com> Message-ID: <0537C39E-237C-42F4-8EB6-99B3B04280A2@dukhovni.org> > On Oct 8, 2019, at 6:27 AM, Benjamin Kaduk via openssl-users wrote: > > The RNG uses sysV shm to convey to other processes that /dev/[u]random has been > properly seeded, under some configurations/kernel versions. This apprently affects some sandboxed configurations: https://anongit.mindrot.org/openssh.git/commit/?id=3ef92a657444f172b61f92d5da66d94fa8265602 aka https://github.com/openssh/openssh-portable/commit/3ef92a657444f172b61f92d5da66d94fa8265602 -- Viktor. From levitte at openssl.org Tue Oct 8 18:32:55 2019 From: levitte at openssl.org (Richard Levitte) Date: Tue, 08 Oct 2019 20:32:55 +0200 Subject: Linux linking issues moving from 1.0.2t to 1.1.1c In-Reply-To: References: <87muecjrw6.wl-levitte@openssl.org> <87lftvjsus.wl-levitte@openssl.org> <87k19fjnyb.wl-levitte@openssl.org> Message-ID: <87ftk3jdew.wl-levitte@openssl.org> On Tue, 08 Oct 2019 18:53:37 +0200, Dan Heinz wrote: > > Another question is why I now need to link pthreads when I did not > in the 1.0.2 version? I've added no-threads to the configuration, > but I'm curious why I didn't need to previously link it. And I'd > prefer not to change too many configuration parameters if possible. We have radically changed how threads-related things are handled. Previous to 1.1.0, we required the application to provide us with the locking functionality in form of callbacks. Since 1.1.0, these matters are entirely internal, so libcrypto requires the presence of the platform specific thread implementation of our choosing, which is pthread on everything but Windows, where we use Windows thread calls. So if you really really really want to have nothing to do with threads in your applications, the 'no-threads' configuration option is the right move. However, if your applications do deal with threads, directly or indirectly, disabling threads in libcrypto is of course a bad move. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From tim.j.culhane at gmail.com Wed Oct 9 10:37:02 2019 From: tim.j.culhane at gmail.com (tim.j.culhane at gmail.com) Date: Wed, 9 Oct 2019 11:37:02 +0100 Subject: building OpenSSL 1.1.1 with -DPURIFY Message-ID: <007701d57e8d$7f0944a0$7d1bcde0$@gmail.com> Hi, I've built OpenSSL 1.1.1c locally on my 64 bit CentOS 7 server. My application links with the libraries contained in this build. When running tests for my application under valgrind I'm seeing lots of errors like the below: Use of uninitialised value of size 8 at 0x4C30DDF: memset (vg_replace_strmem.c:1252) by 0xB389872: CRYPTO_zalloc (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB2C3BDA: bn_expand2 (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB2CACFD: bn_lshift_fixed_top (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB2BCC61: bn_div_fixed_top (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB2BD081: BN_div (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB2C054E: int_bn_mod_inverse (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB2BC0B5: BN_BLINDING_create_param (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB3BDAB0: RSA_setup_blinding (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB3C276A: rsa_ossl_private_encrypt (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB3C4FE2: pkey_rsa_sign (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB37A716: EVP_DigestSignFinal (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xAFC4413: tls_construct_cert_verify (in /opt/openssl/1.1.1/lib/libssl.so.1.1) by 0xAFBB526: state_machine (in /opt/openssl/1.1.1/lib/libssl.so.1.1) by 0xAFA6937: SSL_do_handshake (in /opt/openssl/1.1.1/lib/libssl.so.1.1) by 0xAD64C2C: sncr_tls_negotiation_ex (tls_openssl.c:1766) by 0xAD64D84: sncr_tls_negotiation (tls_openssl.c:1846) by 0x5A890E: run_smtp_server (receiver.c:1367) by 0x5A55A2: smtp_recv_thread (receiver.c:326) by 0x73158F: generic_worker_thread (threads.c:301) by 0x546BDD4: start_thread (in /usr/lib64/libpthread-2.17.so) by 0x61A502C: clone (in /usr/lib64/libc-2.17.so) Uninitialised value was created by a stack allocation at 0xB3B5000: rand_drbg_get_nonce (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) Conditional jump or move depends on uninitialised value(s) at 0x4C30DE5: memset (vg_replace_strmem.c:1252) by 0xB389872: CRYPTO_zalloc (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB2C3BDA: bn_expand2 (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB2CACFD: bn_lshift_fixed_top (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB2BCC61: bn_div_fixed_top (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB2BD081: BN_div (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB2C054E: int_bn_mod_inverse (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB2BC0B5: BN_BLINDING_create_param (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB3BDAB0: RSA_setup_blinding (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB3C276A: rsa_ossl_private_encrypt (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB3C4FE2: pkey_rsa_sign (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB37A716: EVP_DigestSignFinal (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xAFC4413: tls_construct_cert_verify (in /opt/openssl/1.1.1/lib/libssl.so.1.1) by 0xAFBB526: state_machine (in /opt/openssl/1.1.1/lib/libssl.so.1.1) by 0xAFA6937: SSL_do_handshake (in /opt/openssl/1.1.1/lib/libssl.so.1.1) by 0xAD64C2C: sncr_tls_negotiation_ex (tls_openssl.c:1766) by 0xAD64D84: sncr_tls_negotiation (tls_openssl.c:1846) by 0x5A890E: run_smtp_server (receiver.c:1367) by 0x5A55A2: smtp_recv_thread (receiver.c:326) by 0x73158F: generic_worker_thread (threads.c:301) by 0x546BDD4: start_thread (in /usr/lib64/libpthread-2.17.so) by 0x61A502C: clone (in /usr/lib64/libc-2.17.so) Uninitialised value was created by a stack allocation at 0xB3B5000: rand_drbg_get_nonce (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) Conditional jump or move depends on uninitialised value(s) at 0xB2C4070: bn_correct_top (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB2C5397: BN_mod_mul_montgomery (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB3C2704: rsa_ossl_private_encrypt (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB3C4FE2: pkey_rsa_sign (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xB37A716: EVP_DigestSignFinal (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) by 0xAFC4413: tls_construct_cert_verify (in /opt/openssl/1.1.1/lib/libssl.so.1.1) by 0xAFBB526: state_machine (in /opt/openssl/1.1.1/lib/libssl.so.1.1) by 0xAFA6937: SSL_do_handshake (in /opt/openssl/1.1.1/lib/libssl.so.1.1) by 0xAD64C2C: sncr_tls_negotiation_ex (tls_openssl.c:1766) by 0xAD64D84: sncr_tls_negotiation (tls_openssl.c:1846) by 0x5A890E: run_smtp_server (receiver.c:1367) by 0x5A55A2: smtp_recv_thread (receiver.c:326) by 0x73158F: generic_worker_thread (threads.c:301) by 0x546BDD4: start_thread (in /usr/lib64/libpthread-2.17.so) by 0x61A502C: clone (in /usr/lib64/libc-2.17.so) Uninitialised value was created by a stack allocation at 0xB3E2363: sha256_block_data_order_avx2 (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) There are many, many of these errors with varying backtraces shown. But the common function seems to be either sha256_block_data_order_avx2 or rand_drbg_get_nonce I've read somewhere that compiling OpenSSL with -DPURIFY would help remove these errors. However, looking at the CHANGES document which comes with the source I see the below change in 1.1.0: *) Always DPURIFY. Remove the use of uninitialized memory in the RNG, and other conditional uses of DPURIFY. This makes -DPURIFY a no-op. [Emilia K?sper] So does this mean that -DPURIFY is enabled by default? If so, why am I seeing these valgrind errors? I've shown the output of my openssl version -a below. I could put in suppressions for these valgrind errors but there are so many and affect so many areas that it would almost make my valgrind tests useless. Looking forward to any help, Tim OpenSSL 1.1.1c 28 May 2019 platform: linux-x86_64 options: bn(64,64) rc4(16x,int) des(int) idea(int) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPE NSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_A SM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG OPENSSLDIR: "/opt/openssl/1.1.1" ENGINESDIR: "/opt/openssl/1.1.1/lib/engines-1.1" Seeding source: os-specific From np at acronisscs.com Wed Oct 9 11:32:53 2019 From: np at acronisscs.com (Neil Proctor) Date: Wed, 9 Oct 2019 11:32:53 +0000 Subject: ECC CDH (KAS) Message-ID: Hello, I had a question regarding the ECC CDH (KAS) algorithm listed on Page 15 of https://www.openssl.org/docs/fips/SecurityPolicy-2.0.15.pdf Which mode is used for the Key Agreement Scheme? Full Unified Full MVQ Ephemeral Unified One Pass Unified One Pass MVQ One Pass DH Static Unified And which of these functions are performed? Domain Parameter Generation Domain Parameter Verification Key Pair Generation Full Validation (as specified in SP 800-131A, section 5.6.2.4 and/or 5.6.2.5) Partial Validation (as specified in SP 800-131A, section 5.6.2.6) Key Regeneration I'm very new to Diffie Hellman, and I'm trying to learn more about it in regards to how it conforms with some of the NIST guidance and FIPS certification. Thanks, Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric at Deplagne.name Wed Oct 9 11:57:18 2019 From: Eric at Deplagne.name (Eric Deplagne) Date: Wed, 9 Oct 2019 13:57:18 +0200 Subject: building OpenSSL 1.1.1 with -DPURIFY In-Reply-To: <007701d57e8d$7f0944a0$7d1bcde0$@gmail.com> References: <007701d57e8d$7f0944a0$7d1bcde0$@gmail.com> Message-ID: <20191009115718.GI19069@mail.eric.deplagne.name> On Wed, 09 Oct 2019 11:37:02 +0100, tim.j.culhane at gmail.com wrote: > Hi, > > I've built OpenSSL 1.1.1c locally on my 64 bit CentOS 7 server. > > My application links with the libraries contained in this build. > > When running tests for my application under valgrind I'm seeing lots of > errors like the below: > > Use of uninitialised value of size 8 > at 0x4C30DDF: memset (vg_replace_strmem.c:1252) > by 0xB389872: CRYPTO_zalloc (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB2C3BDA: bn_expand2 (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB2CACFD: bn_lshift_fixed_top (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB2BCC61: bn_div_fixed_top (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB2BD081: BN_div (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB2C054E: int_bn_mod_inverse (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB2BC0B5: BN_BLINDING_create_param (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB3BDAB0: RSA_setup_blinding (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB3C276A: rsa_ossl_private_encrypt (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB3C4FE2: pkey_rsa_sign (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB37A716: EVP_DigestSignFinal (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xAFC4413: tls_construct_cert_verify (in > /opt/openssl/1.1.1/lib/libssl.so.1.1) > by 0xAFBB526: state_machine (in /opt/openssl/1.1.1/lib/libssl.so.1.1) > by 0xAFA6937: SSL_do_handshake (in /opt/openssl/1.1.1/lib/libssl.so.1.1) > by 0xAD64C2C: sncr_tls_negotiation_ex (tls_openssl.c:1766) > by 0xAD64D84: sncr_tls_negotiation (tls_openssl.c:1846) > by 0x5A890E: run_smtp_server (receiver.c:1367) > by 0x5A55A2: smtp_recv_thread (receiver.c:326) > by 0x73158F: generic_worker_thread (threads.c:301) > by 0x546BDD4: start_thread (in /usr/lib64/libpthread-2.17.so) > by 0x61A502C: clone (in /usr/lib64/libc-2.17.so) > Uninitialised value was created by a stack allocation > at 0xB3B5000: rand_drbg_get_nonce (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > > Conditional jump or move depends on uninitialised value(s) > at 0x4C30DE5: memset (vg_replace_strmem.c:1252) > by 0xB389872: CRYPTO_zalloc (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB2C3BDA: bn_expand2 (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB2CACFD: bn_lshift_fixed_top (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB2BCC61: bn_div_fixed_top (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB2BD081: BN_div (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB2C054E: int_bn_mod_inverse (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB2BC0B5: BN_BLINDING_create_param (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB3BDAB0: RSA_setup_blinding (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB3C276A: rsa_ossl_private_encrypt (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB3C4FE2: pkey_rsa_sign (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB37A716: EVP_DigestSignFinal (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xAFC4413: tls_construct_cert_verify (in > /opt/openssl/1.1.1/lib/libssl.so.1.1) > by 0xAFBB526: state_machine (in /opt/openssl/1.1.1/lib/libssl.so.1.1) > by 0xAFA6937: SSL_do_handshake (in /opt/openssl/1.1.1/lib/libssl.so.1.1) > by 0xAD64C2C: sncr_tls_negotiation_ex (tls_openssl.c:1766) > by 0xAD64D84: sncr_tls_negotiation (tls_openssl.c:1846) > by 0x5A890E: run_smtp_server (receiver.c:1367) > by 0x5A55A2: smtp_recv_thread (receiver.c:326) > by 0x73158F: generic_worker_thread (threads.c:301) > by 0x546BDD4: start_thread (in /usr/lib64/libpthread-2.17.so) > by 0x61A502C: clone (in /usr/lib64/libc-2.17.so) > Uninitialised value was created by a stack allocation > at 0xB3B5000: rand_drbg_get_nonce (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > > > Conditional jump or move depends on uninitialised value(s) > at 0xB2C4070: bn_correct_top (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB2C5397: BN_mod_mul_montgomery (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB3C2704: rsa_ossl_private_encrypt (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB3C4FE2: pkey_rsa_sign (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xB37A716: EVP_DigestSignFinal (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > by 0xAFC4413: tls_construct_cert_verify (in > /opt/openssl/1.1.1/lib/libssl.so.1.1) > by 0xAFBB526: state_machine (in /opt/openssl/1.1.1/lib/libssl.so.1.1) > by 0xAFA6937: SSL_do_handshake (in /opt/openssl/1.1.1/lib/libssl.so.1.1) > by 0xAD64C2C: sncr_tls_negotiation_ex (tls_openssl.c:1766) > by 0xAD64D84: sncr_tls_negotiation (tls_openssl.c:1846) > by 0x5A890E: run_smtp_server (receiver.c:1367) > by 0x5A55A2: smtp_recv_thread (receiver.c:326) > by 0x73158F: generic_worker_thread (threads.c:301) > by 0x546BDD4: start_thread (in /usr/lib64/libpthread-2.17.so) > by 0x61A502C: clone (in /usr/lib64/libc-2.17.so) > Uninitialised value was created by a stack allocation > at 0xB3E2363: sha256_block_data_order_avx2 (in > /opt/openssl/1.1.1/lib/libcrypto.so.1.1) > > > There are many, many of these errors with varying backtraces shown. > > But the common function seems to be either sha256_block_data_order_avx2 or > rand_drbg_get_nonce > I've read somewhere that compiling OpenSSL with -DPURIFY would help remove > these errors. > > However, looking at the CHANGES document which comes with the source I see > the below change in 1.1.0: > > *) Always DPURIFY. Remove the use of uninitialized memory in the > RNG, and other conditional uses of DPURIFY. This makes -DPURIFY a no-op. > [Emilia K?sper] > > So does this mean that -DPURIFY is enabled by default? > > If so, why am I seeing these valgrind errors? > > I've shown the output of my openssl version -a below. > > I could put in suppressions for these valgrind errors but there are so many > and affect so many areas that it would almost make my valgrind tests > useless. Sorry for it being kind of a troll, but in that matter one has to remember what someone at debian obtained when trying to satisfy valgrind with openssl. (He almost killed the PRNG, and the bug remained from september 2006 to may 2008). So only go this way being skilled and cautious... > Looking forward to any help, > > Tim > > > OpenSSL 1.1.1c 28 May 2019 > platform: linux-x86_64 > options: bn(64,64) rc4(16x,int) des(int) idea(int) blowfish(ptr) > compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 > -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ > -DOPENSSL_IA32_SSE2 -DOPE > NSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM > -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM > -DVPAES_A > SM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM > -DNDEBUG > OPENSSLDIR: "/opt/openssl/1.1.1" > ENGINESDIR: "/opt/openssl/1.1.1/lib/engines-1.1" > Seeding source: os-specific > -- Eric Deplagne -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From rsalz at akamai.com Wed Oct 9 12:52:54 2019 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 9 Oct 2019 12:52:54 +0000 Subject: building OpenSSL 1.1.1 with -DPURIFY In-Reply-To: <20191009115718.GI19069@mail.eric.deplagne.name> References: <007701d57e8d$7f0944a0$7d1bcde0$@gmail.com> <20191009115718.GI19069@mail.eric.deplagne.name> Message-ID: <2A0FCBD8-F572-4330-AA3B-0F59DEEEC362@akamai.com> Emilia's work removed the need to add -DPURIFY; you never need to add it. Note that the BN code is clever, it doesn't bother to zero everything when it knows which bits within a word it is using. From tmraz at redhat.com Wed Oct 9 13:29:55 2019 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 09 Oct 2019 15:29:55 +0200 Subject: building OpenSSL 1.1.1 with -DPURIFY In-Reply-To: <007701d57e8d$7f0944a0$7d1bcde0$@gmail.com> References: <007701d57e8d$7f0944a0$7d1bcde0$@gmail.com> Message-ID: <6d16a1fb65c51983c29a60cf7413a8dee0cbcab0.camel@redhat.com> On Wed, 2019-10-09 at 11:37 +0100, tim.j.culhane at gmail.com wrote: > Hi, > > I've built OpenSSL 1.1.1c locally on my 64 bit CentOS 7 server. > > My application links with the libraries contained in this build. > > When running tests for my application under valgrind I'm seeing lots > of > errors like the below: You can either try 1.1.1d or the patch from https://github.com/openssl/openssl/pull/9217 It should solve the problem. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From jgh at wizmail.org Wed Oct 9 14:49:46 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Wed, 9 Oct 2019 15:49:46 +0100 Subject: full-chain ocsp stapling In-Reply-To: <3a9e3d31-4ee6-4acd-e05d-9beb79044125@wizmail.org> References: <86bfc59e-a2d8-d2a3-a81d-3abf43705853@wizmail.org> <9d2cfd7b-c83d-06ba-5a46-da3fd0672697@openssl.org> <3a9e3d31-4ee6-4acd-e05d-9beb79044125@wizmail.org> Message-ID: <51c088ad-01d4-997e-6c8d-c51ad498a29a@wizmail.org> On 01/10/2019 12:21, Jeremy Harris wrote: > On 30/09/2019 17:02, Matt Caswell wrote: >>> Alternatively^2, is there some way to get such a blob from a tool >>> (openssl ocsp, or similar) ready built? For this purpose, I am >>> the CA. >>> >> >> Yes, you can do this. For example see the "respout" option in the >> ocsp command. >> >> From the examples in the ocsp man page: >> >> Send a query to an OCSP responder with URL http://ocsp.myhost.com/ >> save the response to a file, print it out in text form, and verify >> the response: >> >> openssl ocsp -issuer issuer.pem -cert c1.pem -cert c2.pem \ -url >> http://ocsp.myhost.com/ -resp_text -respout resp.der > > I'm using the indexfile variant. It seems that the -CA argument > needs to be the signer of the cert, not the CA for the chain; and > you cannot give -CA multiple times. So you don't get good OCSP status > for all elements in the chain: > > $ cat $ifile > V 130110200751Z 65 unknown CN=server1.example.com > V 130110200751Z 66 unknown CN=revoked1.example.com > V 130110200751Z 67 unknown CN=expired1.example.com > V 130110200751Z c9 unknown CN=server2.example.com > V 130110200751Z ca unknown CN=revoked2.example.com > V 130110200751Z cb unknown CN=expired2.example.com > V 130110200751Z 42 unknown CN=clica Signing Cert rsa > V 130110200751Z 41 unknown CN=clica CA rsa > $ > $ openssl ocsp -sha256 -no_nonce -issuer $CADIR/Signer.pem -cert > $leafcert -issuer $CADIR/CA.pem -cert $CADIR/Signer.pem -cert > $CADIR/CA.pem -reqout $REQ -req_text > OCSP Request Data: > Version: 1 (0x0) > Requestor List: > Certificate ID: > Hash Algorithm: sha256 > Issuer Name Hash: > 5AF082E51D62FE01FD706BAEBEB878DB64E68F76E74A36F36D914297DDEE24B8 > Issuer Key Hash: > 333DB14364B98E78A33DD8A4FAE8D8378EA9B0F5FBCA97B25685AA0D32116091 > Serial Number: 65 > Certificate ID: > Hash Algorithm: sha256 > Issuer Name Hash: > BFA7275A566EFD4BE2DF82DBD9D1290D470186F6FF2ACD8C16659F342AB56109 > Issuer Key Hash: > 208F9D28C7C0BC914144DFA8C0BE3D5B3BFCEBB622C8A8DC27E865FC06CA0E12 > Serial Number: 42 > Certificate ID: > Hash Algorithm: sha256 > Issuer Name Hash: > BFA7275A566EFD4BE2DF82DBD9D1290D470186F6FF2ACD8C16659F342AB56109 > Issuer Key Hash: > 208F9D28C7C0BC914144DFA8C0BE3D5B3BFCEBB622C8A8DC27E865FC06CA0E12 > Serial Number: 41 > $ > $ openssl ocsp -index $ifile -rsigner $CADIR/CA.pem -rkey $CADIR/CA.key > -CA $CADIR/CA.pem -resp_no_certs -noverify -ndays 3652 -reqin > $REQ -respout $RESP -resp_text | egrep '(Serial|Status)' > OCSP Response Status: successful (0x0) > Serial Number: 65 > Cert Status: unknown > Serial Number: 42 > Cert Status: good > Serial Number: 41 > Cert Status: good > $ > > No answers on how to get ocsp responses for all elements of a certificate chain? -- Cheers, Jeremy From georg.hoellrigl at gmx.at Wed Oct 9 17:50:54 2019 From: georg.hoellrigl at gmx.at (=?iso-8859-1?Q?Georg_H=F6llrigl?=) Date: Wed, 9 Oct 2019 19:50:54 +0200 Subject: Troubles Compiling in Mobaxterm Message-ID: <002e01d57eca$1a103120$4e309360$@gmx.at> Hello, I've tried to compile openssl 1.1.1d in Mobaxterm. The same is working with 1.1.1c Any ideas, what's wrong? Georg /openssl-1.1.1d ./config no-async && time make Operating system: i686-pc-cygwin Configuring OpenSSL version 1.1.1d (0x1010104fL) for Cygwin-x86 Using os-specific seed configuration Creating configdata.pm Creating Makefile ********************************************************************** *** *** *** OpenSSL has been successfully configured *** *** *** *** If you encounter a problem while building, please open an *** *** issue on GitHub *** *** and include the output from the following command: *** *** *** *** perl configdata.pm --dump *** *** *** *** (If you are new to OpenSSL, you might want to consult the *** *** 'Troubleshooting' section in the INSTALL file first) *** *** *** ********************************************************************** ---------------------------------------------------------------------- gcc -I. -Icrypto/include -Iinclude -Wall -O3 -fomit-frame-pointer -DTERMIOS -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DRMD160_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -DNDEBUG -MMD -MF crypto/dso/dso_dlfcn.d.tmp -MT crypto/dso/dso_dlfcn.o -c -o crypto/dso/dso_dlfcn.o crypto/dso/dso_dlfcn.c crypto/dso/dso_dlfcn.c: In function 'dlfcn_pathbyaddr': crypto/dso/dso_dlfcn.c:409:5: error: unknown type name 'Dl_info' Dl_info dli; ^ crypto/dso/dso_dlfcn.c:422:5: warning: implicit declaration of function 'dladdr' [-Wimplicit-function-declaration] if (dladdr(addr, &dli)) { ^ crypto/dso/dso_dlfcn.c:423:30: error: request for member 'dli_fname' in something not a structure or union len = (int)strlen(dli.dli_fname); ^ crypto/dso/dso_dlfcn.c:432:25: error: request for member 'dli_fname' in something not a structure or union memcpy(path, dli.dli_fname, len); ^ Makefile:2735: recipe for target 'crypto/dso/dso_dlfcn.o' failed make[1]: *** [crypto/dso/dso_dlfcn.o] Error 1 make[1]: Leaving directory '/drives/c/temp/openssl-1.1.1d' Makefile:174: recipe for target 'all' failed make: *** [all] Error 2 Command exited with non-zero status 2 From tim.j.culhane at gmail.com Wed Oct 9 19:48:34 2019 From: tim.j.culhane at gmail.com (tim.j.culhane at gmail.com) Date: Wed, 9 Oct 2019 20:48:34 +0100 Subject: building OpenSSL 1.1.1 with -DPURIFY In-Reply-To: <6d16a1fb65c51983c29a60cf7413a8dee0cbcab0.camel@redhat.com> References: <007701d57e8d$7f0944a0$7d1bcde0$@gmail.com> <6d16a1fb65c51983c29a60cf7413a8dee0cbcab0.camel@redhat.com> Message-ID: <002801d57eda$8bbff0c0$a33fd240$@gmail.com> Hi Tom?s I've downloaded and build openssl 1.1.1d. However, when I run the tests there appears to be failures. Extract of the make test output below: ../test/recipes/20-test_enc.t ...................... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/172 subtests Test summary shows: Test Summary Report ------------------- ../test/recipes/20-test_enc.t (Wstat: 256 Tests: 172 Failed: 1) Failed test: 171 Non-zero exit status: 1 Files=155, Tests=1457, 97 wallclock secs ( 1.74 usr 0.17 sys + 85.00 cusr 21.23 csys = 108.14 CPU) Result: FAIL gmake[1]: *** [_tests] Error 1 gmake[1]: Leaving directory `/root/openssl-1.1.1d' gmake: *** [tests] Error 2 Is this something I need to resolve before installing 1.1.1d and if so how can I resolve the test failures? Thanks, Tim -----Original Message----- From: Tomas Mraz Sent: Wednesday 9 October 2019 14:30 To: tim.j.culhane at gmail.com; openssl-users at openssl.org Subject: Re: building OpenSSL 1.1.1 with -DPURIFY On Wed, 2019-10-09 at 11:37 +0100, tim.j.culhane at gmail.com wrote: > Hi, > > I've built OpenSSL 1.1.1c locally on my 64 bit CentOS 7 server. > > My application links with the libraries contained in this build. > > When running tests for my application under valgrind I'm seeing lots > of errors like the below: You can either try 1.1.1d or the patch from https://github.com/openssl/openssl/pull/9217 It should solve the problem. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From Matthias.St.Pierre at ncp-e.com Wed Oct 9 21:57:56 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 9 Oct 2019 21:57:56 +0000 Subject: AW: building OpenSSL 1.1.1 with -DPURIFY In-Reply-To: <002801d57eda$8bbff0c0$a33fd240$@gmail.com> References: <007701d57e8d$7f0944a0$7d1bcde0$@gmail.com> <6d16a1fb65c51983c29a60cf7413a8dee0cbcab0.camel@redhat.com> <002801d57eda$8bbff0c0$a33fd240$@gmail.com> Message-ID: <54de7255b9284076b3a49fe89e886558@Ex13.ncp.local> Hi Tim, > However, when I run the tests there appears to be failures. > > Extract of the make test output below: > > > ../test/recipes/20-test_enc.t ...................... > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/172 subtests Your test failure looks like issue https://github.com/openssl/openssl/issues/9866 which was fixed by Tomas in commit https://github.com/openssl/openssl/commit/86ed78676c660b553696cc10c682962522dfeb6c The easiest way to obtain the fix is to update to the current head of the 1.1.1. stable branch. https://github.com/openssl/openssl/commits/OpenSSL_1_0_1-stable Regards, Matthias From matt at openssl.org Thu Oct 10 08:21:48 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 10 Oct 2019 09:21:48 +0100 Subject: AW: building OpenSSL 1.1.1 with -DPURIFY In-Reply-To: <54de7255b9284076b3a49fe89e886558@Ex13.ncp.local> References: <007701d57e8d$7f0944a0$7d1bcde0$@gmail.com> <6d16a1fb65c51983c29a60cf7413a8dee0cbcab0.camel@redhat.com> <002801d57eda$8bbff0c0$a33fd240$@gmail.com> <54de7255b9284076b3a49fe89e886558@Ex13.ncp.local> Message-ID: On 09/10/2019 22:57, Dr. Matthias St. Pierre wrote: > Hi Tim, > >> However, when I run the tests there appears to be failures. >> >> Extract of the make test output below: >> >> >> ../test/recipes/20-test_enc.t ...................... >> Dubious, test returned 1 (wstat 256, 0x100) >> Failed 1/172 subtests > > Your test failure looks like issue > https://github.com/openssl/openssl/issues/9866 > > which was fixed by Tomas in commit > https://github.com/openssl/openssl/commit/86ed78676c660b553696cc10c682962522dfeb6c > > The easiest way to obtain the fix is to update to the current head of the 1.1.1. stable branch. > https://github.com/openssl/openssl/commits/OpenSSL_1_0_1-stable I think you meant to link to the 1.1.1 branch not 1.0.1! https://github.com/openssl/openssl/commits/OpenSSL_1_1_1-stable Matt > > Regards, > Matthias > From tim.j.culhane at gmail.com Thu Oct 10 08:57:00 2019 From: tim.j.culhane at gmail.com (tim.j.culhane at gmail.com) Date: Thu, 10 Oct 2019 09:57:00 +0100 Subject: building OpenSSL 1.1.1 with -DPURIFY In-Reply-To: <54de7255b9284076b3a49fe89e886558@Ex13.ncp.local> References: <007701d57e8d$7f0944a0$7d1bcde0$@gmail.com> <6d16a1fb65c51983c29a60cf7413a8dee0cbcab0.camel@redhat.com> <002801d57eda$8bbff0c0$a33fd240$@gmail.com> <54de7255b9284076b3a49fe89e886558@Ex13.ncp.local> Message-ID: <001801d57f48$ae404c80$0ac0e580$@gmail.com> Hi all, Glad to report that using the latest 1.1.1 stable build from git, all tests pass successfully and also my issue with the valgrind issues is resolved. Many thanks for your prompt help. Tim -----Original Message----- From: Dr. Matthias St. Pierre Sent: Wednesday 9 October 2019 22:58 To: tim.j.culhane at gmail.com; 'Tomas Mraz' ; openssl-users at openssl.org Subject: AW: building OpenSSL 1.1.1 with -DPURIFY Hi Tim, > However, when I run the tests there appears to be failures. > > Extract of the make test output below: > > > ../test/recipes/20-test_enc.t ...................... > Dubious, test returned 1 (wstat 256, 0x100) Failed 1/172 subtests Your test failure looks like issue https://github.com/openssl/openssl/issues/9866 which was fixed by Tomas in commit https://github.com/openssl/openssl/commit/86ed78676c660b553696cc10c682962522dfeb6c The easiest way to obtain the fix is to update to the current head of the 1.1.1. stable branch. https://github.com/openssl/openssl/commits/OpenSSL_1_0_1-stable Regards, Matthias Dr. Matthias St. Pierre Senior Software Engineer matthias.st.pierre at ncp-e.com Phone: +49 911 9968-0 www.ncp-e.com Headquarters Germany: NCP engineering GmbH ? Dombuehler Str. 2 ? 90449 ? Nuremberg North American HQ: NCP engineering Inc. ? 678 Georgia Ave. ? Sunnyvale, CA 94085 East Coast Office: NCP engineering Inc. ? 601 Cleveland Str., Suite 501-25 ? Clearwater, FL 33755 Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich Registry Court: Lower District Court of Nuremberg Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE 133557619 This e-mail message including any attachments is for the sole use of the intended recipient(s) and may contain privileged or confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply e-mail and delete the original message and destroy all copies thereof. From Matthias.St.Pierre at ncp-e.com Thu Oct 10 10:26:23 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 10 Oct 2019 10:26:23 +0000 Subject: AW: AW: building OpenSSL 1.1.1 with -DPURIFY In-Reply-To: References: <007701d57e8d$7f0944a0$7d1bcde0$@gmail.com> <6d16a1fb65c51983c29a60cf7413a8dee0cbcab0.camel@redhat.com> <002801d57eda$8bbff0c0$a33fd240$@gmail.com> <54de7255b9284076b3a49fe89e886558@Ex13.ncp.local> Message-ID: > > The easiest way to obtain the fix is to update to the current head of the 1.1.1. stable branch. > > https://github.com/openssl/openssl/commits/OpenSSL_1_0_1-stable > > I think you meant to link to the 1.1.1 branch not 1.0.1! > > https://github.com/openssl/openssl/commits/OpenSSL_1_1_1-stable > > Matt You are right, thanks for the correction. I must have selected the wrong entry in the GitHub branch selection box without noticing it. Fortunately, Tim didn't follow my advice blindly ;-) Matthias From rolsen at quotient-inc.com Thu Oct 10 14:58:03 2019 From: rolsen at quotient-inc.com (Richard Olsen) Date: Thu, 10 Oct 2019 10:58:03 -0400 Subject: Openssl config file string_mask Message-ID: On our RHEL7 system I created a local CA. When i try to sign the linux created csr there is no problem. But trying to sign from Palo Alto or F5 csr's it errors with The stateOrProvinceName field needed to be the same > in the CA certificate CA certificate (My Entry) and the request (My Entry) So researching i found the references to the openssl asn1parse to see the encoding of the csr. The PA and F5 csr's use PRINTABLESTRING instead of utf8 like the openssl req command from the command line. I have been trying to use the string_mask option in the openssl.cnf. I've tried setting it to multiple options (one at a time) as listed in the default config. It still fails everytime. I've verified that i am using the correct config file that i've modified. (Using configuration from when i run the command) string_mask = nombstr string_mask = default string_mask = pkix I know that i can change policy_match from match to either optional or supplied but i don't want to have to do that. I don't get any error when i put random entry in the string_mask variable but i don't know if that is a way to test the config file anyway. Rick. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdrotter at us.ibm.com Thu Oct 10 15:40:02 2019 From: pdrotter at us.ibm.com (Neptune) Date: Thu, 10 Oct 2019 08:40:02 -0700 (MST) Subject: FIPS 3.0 private_* hash functions Message-ID: <1570722002316-0.post@n7.nabble.com> Hi all, I am in the process of making required changes to migrate our code to the 1.1.x branch. We are currently using the FIPS Object Module 2.0 and eagerly await word on the new 3.0 FIPS Object Module, but in the meantime there is one issue of concern in our code for which I need some clarification: This is a fairly old code base which contains some MD4 and MD5 usages. These are merely used to create some comparison hashes, but because of constraints with other applications we integrate with, it would be painful to replace these with newer FIPS-compliant hashes. For our current code using 1.0.2 we got around the FIPS Object Module in these cases by using the private variants of these hash functions (i.e. private_MD5_init). Will there be any such provisions for the 3.0 FIPS Object Module? Thank you! Paul -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From matt at openssl.org Thu Oct 10 15:42:01 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 10 Oct 2019 16:42:01 +0100 Subject: FIPS 3.0 private_* hash functions In-Reply-To: <1570722002316-0.post@n7.nabble.com> References: <1570722002316-0.post@n7.nabble.com> Message-ID: On 10/10/2019 16:40, Neptune wrote: > Hi all, > I am in the process of making required changes to migrate our code to the > 1.1.x branch. We are currently using the FIPS Object Module 2.0 and eagerly > await word on the new 3.0 FIPS Object Module, but in the meantime there is > one issue of concern in our code for which I need some clarification: > > This is a fairly old code base which contains some MD4 and MD5 usages. These > are merely used to create some comparison hashes, but because of constraints > with other applications we integrate with, it would be painful to replace > these with newer FIPS-compliant hashes. For our current code using 1.0.2 we > got around the FIPS Object Module in these cases by using the private > variants of these hash functions (i.e. private_MD5_init). > > Will there be any such provisions for the 3.0 FIPS Object Module? > OpenSSL 3.0 is a completely different architecture to the older versions. Algorithm implementations are available via "providers". There will be 3 providers available initially (others might come from 3rd parties). These are the default, legacy and fips providers. FIPS validated algorithms will be in the fips provider. The legacy provider will have MD4 and MD5 implementations. It is perfectly possible to have more than one provider loaded at the same time. Configuration will enable you to specify which algorithm implementations you wish to use for any given circumstance. You can also override configuration on a per call site basis. For example you can load both the fips and legacy providers and configure things so that by default you only ever use fips algorithms. For specific cases you can override the default configuration to load algorithms from the legacy provider. Matt From tmraz at redhat.com Thu Oct 10 15:49:28 2019 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 10 Oct 2019 17:49:28 +0200 Subject: FIPS 3.0 private_* hash functions In-Reply-To: <1570722002316-0.post@n7.nabble.com> References: <1570722002316-0.post@n7.nabble.com> Message-ID: <35cc210573942b2a0ca24e51382a2b6127cb06ce.camel@redhat.com> On Thu, 2019-10-10 at 08:40 -0700, Neptune wrote: > Hi all, > I am in the process of making required changes to migrate our code to > the > 1.1.x branch. We are currently using the FIPS Object Module 2.0 and > eagerly > await word on the new 3.0 FIPS Object Module, but in the meantime > there is > one issue of concern in our code for which I need some clarification: > > This is a fairly old code base which contains some MD4 and MD5 > usages. These > are merely used to create some comparison hashes, but because of > constraints > with other applications we integrate with, it would be painful to > replace > these with newer FIPS-compliant hashes. For our current code using > 1.0.2 we > got around the FIPS Object Module in these cases by using the private > variants of these hash functions (i.e. private_MD5_init). > > Will there be any such provisions for the 3.0 FIPS Object Module? Yes, they already are there in the master branch! See: https://github.com/openssl/openssl/issues/10129 -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From jgh at wizmail.org Thu Oct 10 21:53:21 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Thu, 10 Oct 2019 22:53:21 +0100 Subject: full-chain ocsp stapling In-Reply-To: <3a9e3d31-4ee6-4acd-e05d-9beb79044125@wizmail.org> References: <86bfc59e-a2d8-d2a3-a81d-3abf43705853@wizmail.org> <9d2cfd7b-c83d-06ba-5a46-da3fd0672697@openssl.org> <3a9e3d31-4ee6-4acd-e05d-9beb79044125@wizmail.org> Message-ID: On 01/10/2019 12:21, Jeremy Harris wrote: > I'm using the indexfile variant. It seems that the -CA argument > needs to be the signer of the cert, not the CA for the chain; and > you cannot give -CA multiple times. So you don't get good OCSP status > for all elements in the chain: > $ openssl ocsp -sha256 -no_nonce -issuer $CADIR/Signer.pem -cert > $leafcert -issuer $CADIR/CA.pem -cert $CADIR/Signer.pem -cert > $CADIR/CA.pem -reqout $REQ -req_text Further experimentation finds that the "-CA" argument can be a PEM with multiple issuers, and this gets me a resp with all of the Cert Status values "good" rather than some "unknown". [ The "openssl ocsp" manpage could possibly use more info on the situation ] However, in trying to use that, I'm now less certain it was what was wanted. It results in a server TLS1.3 Certificates record having a single extension, placed after the first certificate of the three bundled in my testcase (leaf, signer, root). The extension is a certificate-status with three single-response items. This contrasts with the situation I had developed using GnuTLS (which accepts a multi-PEM file for proofs); it placed an extension with a single status after each of the three certificates. Are both layouts of the TLS1.3 Certificates record valid? FWIW, feeding this same multi-resp to GnuTLS makes it bahave the same way as OpenSSL. The triplet of single-responses is _also_ visible in a TLS1.2 Certificate Status record. -- Cheers, Jeremy From matt at openssl.org Fri Oct 11 08:57:19 2019 From: matt at openssl.org (Matt Caswell) Date: Fri, 11 Oct 2019 09:57:19 +0100 Subject: full-chain ocsp stapling In-Reply-To: References: <86bfc59e-a2d8-d2a3-a81d-3abf43705853@wizmail.org> <9d2cfd7b-c83d-06ba-5a46-da3fd0672697@openssl.org> <3a9e3d31-4ee6-4acd-e05d-9beb79044125@wizmail.org> Message-ID: On 10/10/2019 22:53, Jeremy Harris wrote: > On 01/10/2019 12:21, Jeremy Harris wrote: >> I'm using the indexfile variant. It seems that the -CA argument >> needs to be the signer of the cert, not the CA for the chain; and >> you cannot give -CA multiple times. So you don't get good OCSP status >> for all elements in the chain: > >> $ openssl ocsp -sha256 -no_nonce -issuer $CADIR/Signer.pem -cert >> $leafcert -issuer $CADIR/CA.pem -cert $CADIR/Signer.pem -cert >> $CADIR/CA.pem -reqout $REQ -req_text > > Further experimentation finds that the "-CA" argument can be > a PEM with multiple issuers, and this gets me a resp with all > of the Cert Status values "good" rather than some "unknown". > > [ The "openssl ocsp" manpage could possibly use more info > on the situation ] > > However, in trying to use that, I'm now less certain it was what > was wanted. It results in a server TLS1.3 Certificates record > having a single extension, placed after the first certificate > of the three bundled in my testcase (leaf, signer, root). > The extension is a certificate-status with three single-response > items. > This contrasts with the situation I had developed using GnuTLS > (which accepts a multi-PEM file for proofs); it placed an extension > with a single status after each of the three certificates. OpenSSL does not currently support that. You can only place a status response after the first certificate. Matt > > Are both layouts of the TLS1.3 Certificates record valid? > > > FWIW, feeding this same multi-resp to GnuTLS makes it bahave > the same way as OpenSSL. The triplet of single-responses is > _also_ visible in a TLS1.2 Certificate Status record. > From jgh at wizmail.org Fri Oct 11 09:10:23 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Fri, 11 Oct 2019 10:10:23 +0100 Subject: full-chain ocsp stapling In-Reply-To: References: <86bfc59e-a2d8-d2a3-a81d-3abf43705853@wizmail.org> <9d2cfd7b-c83d-06ba-5a46-da3fd0672697@openssl.org> <3a9e3d31-4ee6-4acd-e05d-9beb79044125@wizmail.org> Message-ID: On 11/10/2019 09:57, Matt Caswell wrote: > OpenSSL does not currently support that. You can only place a status response > after the first certificate. > > Matt That's why I asked: >> Are both layouts of the TLS1.3 Certificates record valid? -- Cheers, Jeremy From matt at openssl.org Fri Oct 11 09:29:03 2019 From: matt at openssl.org (Matt Caswell) Date: Fri, 11 Oct 2019 10:29:03 +0100 Subject: full-chain ocsp stapling In-Reply-To: References: <86bfc59e-a2d8-d2a3-a81d-3abf43705853@wizmail.org> <9d2cfd7b-c83d-06ba-5a46-da3fd0672697@openssl.org> <3a9e3d31-4ee6-4acd-e05d-9beb79044125@wizmail.org> Message-ID: <2fd533ad-e7f2-775c-3190-6943c96a9122@openssl.org> On 11/10/2019 10:10, Jeremy Harris wrote: > On 11/10/2019 09:57, Matt Caswell wrote: >> OpenSSL does not currently support that. You can only place a status response >> after the first certificate. >> >> Matt > > > That's why I asked: > >>> Are both layouts of the TLS1.3 Certificates record valid? > RFC8446 is not really very clear in this regards. All it says is: "In TLS 1.3, the server's OCSP information is carried in an extension in the CertificateEntry containing the associated certificate. Specifically, the body of the "status_request" extension from the server MUST be a CertificateStatus structure as defined in [RFC6066], which is interpreted as defined in [RFC6960]." Putting everything in a single CertificateEntry gives you equivalence with what can be achieved in TLSv1.2 and is allowed by the syntax of a CertificateStatus structure. So I *think* this is ok. It is not described how one should interpret a single CertificateStatus covering the whole chain, vs individual CertificateStatus entries, one for each Certificate. Matt From rafab969 at gmail.com Mon Oct 14 18:49:13 2019 From: rafab969 at gmail.com (Freddy Anaut) Date: Mon, 14 Oct 2019 20:49:13 +0200 Subject: "Unable to connect to Wiktionary" . Message-ID: <5da4c32a.1c69fb81.4e610.3a9c@mx.google.com> Hi!! I have ?OpenSSL 1.1.1d Light? (32 bit) installed for playing a game that needs it. It is called ?Connectagram? (Anagram game) . ?Connectagram? version I have is 1.2.10 . I have a ?Windows 10 Home Edition? PC. It is a 64bit System Type. The processor is: Intel(R) Core ? i5-4440 CPU @ 3.10GHz 3.10GHz. Windows version I have is: 1903 and the system operative version is: 18362.418? . The author of the game says : ?Wiktionary requires SSL. Windows users will need to install Win32 OpenSSL to fetch the definitions?. Before last version of ?Connectagram?, I had the same issue as now: On solving words, definitions window opens, and says: ?Unable to connect to Wiktionary?, and sometimes: ?Downloading definition?, and gets stuck there for a long time? I followed the instructions on a webpage , that said to download the ?libeay? and ?ssleay? files and paste on some system folders. http://docwiki.embarcadero.com/RADStudio/Rio/en/OpenSSL In the last versi?n of the programme, I solved the issue by following that webpage guide. But now, in spite of downloading that files I cannot get ?Connectagram? to fetch definitions from ?Wiktionary?. I have done another thing, I don?t know whether I should have done: To set the configuration file of ?OpenSSL? as this webpage says at the end . https://www.osradar.com/install-openssl-windows/ Does anyone have any idea to get the definitions from ?Wiktionary??? (Or to get ?OpenSSL? to work in my system, for it does not) . Thanks!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From schmidt.ajax at gmail.com Tue Oct 15 05:59:46 2019 From: schmidt.ajax at gmail.com (Anton Schmidt) Date: Tue, 15 Oct 2019 12:59:46 +0700 Subject: How to run OpenSSL command line utility under debugger? Message-ID: I've got an error in openssl library function when trying to read a pkcs7 message [schmidt at localhost ssl]$ ./bin/openssl version OpenSSL 3.0.0-dev xx XXX xxxx (Library: OpenSSL 3.0.0-dev xx XXX xxxx) [schmidt at localhost ssl]$ ./bin/openssl pkcs7 -in /tmp/55b0822e148e4ffaa0bd9ebc41814f54.der -inform DER -print_certs unable to load PKCS7 object 40:57:70:89:A5:7F:00:00:error:asn1 encoding routines:(unknown function):sequence length mismatch:crypto/asn1/tasn_dec.c:388:Type=PKCS7_ENVELOPE 40:57:70:89:A5:7F:00:00:error:asn1 encoding routines:(unknown function):nested asn1 error:crypto/asn1/tasn_dec.c:629: 40:57:70:89:A5:7F:00:00:error:asn1 encoding routines:(unknown function):nested asn1 error:crypto/asn1/tasn_dec.c:479:Field=d.enveloped, Type=PKCS7 openssl asn1parse and other online tools correctly parse and display ASN1 of pkcs7 envelopedData. I want to run openssl utility under debugger to see what is happening inside the library function. I've found OpenSSL library source code https://github.com/openssl/openssl but not the sources for command line utility. Are the sources available? Or as an option is there a guide how I could write a simple pkcs7 envelopedData reader to debug the library function? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at jordan.maileater.net Tue Oct 15 06:02:35 2019 From: openssl at jordan.maileater.net (Jordan Brown) Date: Tue, 15 Oct 2019 06:02:35 +0000 Subject: How to run OpenSSL command line utility under debugger? In-Reply-To: References: Message-ID: <0101016dce02d633-12e8b64b-8ef9-4efe-b91c-f4d150457bc3-000000@us-west-2.amazonses.com> On 10/14/2019 10:59 PM, Anton Schmidt wrote: > I've found OpenSSL library source > code?https://github.com/openssl/openssl?but not the sources for > command line utility. Are the sources available?? I believe they are in the "apps" directory of that repository. -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From navin.shivanna at gmail.com Tue Oct 15 06:51:34 2019 From: navin.shivanna at gmail.com (Naveen Shivanna) Date: Tue, 15 Oct 2019 12:21:34 +0530 Subject: No subject Message-ID: Hi, After adding 'enable-sctp' compile option, OpenSSL (DTLS) can work with SCTP as transport. OpenSSL bss_dgram.c file includes the kernel /netinet/sctp.h. We have our own custom SCTP implementation (also implements custom BIO METHODS, do not use the default methods), so we need to remove the dependency of kernel sctp.h from bss_gram.c file. Our build environment do not have the sctp.h and we are not supposed to install lksctp-tools. Can we tailor the bss_gram.c with new compile macro or is there any other better solution ? Rgds, Navi -------------- next part -------------- An HTML attachment was scrubbed... URL: From navin.shivanna at gmail.com Tue Oct 15 06:55:37 2019 From: navin.shivanna at gmail.com (Naveen Shivanna) Date: Tue, 15 Oct 2019 12:25:37 +0530 Subject: Regarding netinet/sctp.h inclusion in bss_dgram.c Message-ID: Hi, After adding 'enable-sctp' compile option, OpenSSL (DTLS) can work with SCTP as transport. OpenSSL bss_dgram.c file includes the kernel /netinet/sctp.h. We have our own custom SCTP implementation (also implements custom BIO METHODS, do not use the default methods), so we need to remove the dependency of kernel sctp.h from bss_gram.c file. Our build environment do not have the sctp.h and we are not supposed to install lksctp-tools. Can we tailor the bss_gram.c with new compile macro or is there any other better solution ? Rgds, Navi -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Tue Oct 15 06:57:10 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Tue, 15 Oct 2019 09:57:10 +0300 Subject: How to run OpenSSL command line utility under debugger? In-Reply-To: References: Message-ID: Dear Anton, On Tue, Oct 15, 2019 at 9:00 AM Anton Schmidt wrote: > I've got an error in openssl library function when trying to read a pkcs7 > message > > [schmidt at localhost ssl]$ ./bin/openssl version > OpenSSL 3.0.0-dev xx XXX xxxx (Library: OpenSSL 3.0.0-dev xx XXX xxxx) > [schmidt at localhost ssl]$ ./bin/openssl pkcs7 -in > /tmp/55b0822e148e4ffaa0bd9ebc41814f54.der -inform DER -print_certs > unable to load PKCS7 object > 40:57:70:89:A5:7F:00:00:error:asn1 encoding routines:(unknown > function):sequence length > mismatch:crypto/asn1/tasn_dec.c:388:Type=PKCS7_ENVELOPE > 40:57:70:89:A5:7F:00:00:error:asn1 encoding routines:(unknown > function):nested asn1 error:crypto/asn1/tasn_dec.c:629: > 40:57:70:89:A5:7F:00:00:error:asn1 encoding routines:(unknown > function):nested asn1 error:crypto/asn1/tasn_dec.c:479:Field=d.enveloped, > Type=PKCS7 > > openssl asn1parse and other online tools correctly parse and display ASN1 > of pkcs7 envelopedData. > > I want to run openssl utility under debugger to see what is happening > inside the library function. > > I've found OpenSSL library source code https://github.com/openssl/openssl but > not the sources for command line utility. Are the sources available? > > Or as an option is there a guide how I could write a simple pkcs7 > envelopedData reader to debug the library function? > You can build openssl using the following steps: ./config -ggdb make and then debug LD_LIBRARY_PATH=. gdb --args apps/openssl ... -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Oct 15 09:32:41 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 15 Oct 2019 10:32:41 +0100 Subject: In-Reply-To: References: Message-ID: <5b42fde4-6ed7-2cfc-e6dc-487f8098ed20@openssl.org> On 15/10/2019 07:51, Naveen Shivanna wrote: > Hi,? > > After adding 'enable-sctp' compile option, OpenSSL (DTLS) can work with > SCTP as transport. > > OpenSSL bss_dgram.c file includes the kernel /netinet/sctp.h. > > We have our own custom SCTP implementation (also implements? custom BIO > METHODS, do not use the default methods), so we need to remove the > dependency of kernel sctp.h from bss_gram.c file. Our build environment > do not have the sctp.h and we are not supposed to install lksctp-tools. > > Can we tailor the bss_gram.c with new compile macro or is there any > other better solution ? Hmm. There isn't really a "good" way to do this. I can think of two options: 1) Modify the OpenSSL source (perhaps in the way that you suggest with a compile time macro) or 2) Provide a "dummy" implementation of netinet/sctp.h. This would have to provide "stub" implementations of any SCTP related functions/macros used by bss_dgram.c. That would enable you to build unmodified OpenSSL source. Matt From matt at openssl.org Tue Oct 15 09:49:42 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 15 Oct 2019 10:49:42 +0100 Subject: Regarding netinet/sctp.h inclusion in bss_dgram.c In-Reply-To: <5b42fde4-6ed7-2cfc-e6dc-487f8098ed20@openssl.org> References: <5b42fde4-6ed7-2cfc-e6dc-487f8098ed20@openssl.org> Message-ID: <17341ead-00c6-6789-b249-6e54daaefbf5@openssl.org> On 15/10/2019 10:32, Matt Caswell wrote: > > > On 15/10/2019 07:51, Naveen Shivanna wrote: >> Hi,? >> >> After adding 'enable-sctp' compile option, OpenSSL (DTLS) can work with >> SCTP as transport. >> >> OpenSSL bss_dgram.c file includes the kernel /netinet/sctp.h. >> >> We have our own custom SCTP implementation (also implements? custom BIO >> METHODS, do not use the default methods), so we need to remove the >> dependency of kernel sctp.h from bss_gram.c file. Our build environment >> do not have the sctp.h and we are not supposed to install lksctp-tools. >> >> Can we tailor the bss_gram.c with new compile macro or is there any >> other better solution ? > > Hmm. There isn't really a "good" way to do this. I can think of two options: > > 1) Modify the OpenSSL source (perhaps in the way that you suggest with a > compile time macro) > > or > > 2) Provide a "dummy" implementation of netinet/sctp.h. This would have > to provide "stub" implementations of any SCTP related functions/macros > used by bss_dgram.c. That would enable you to build unmodified OpenSSL > source. Thinking about this a little more, I think you may encounter other problems with replacing the standard SCTP BIO with your own one. The functions BIO_dgram_sctp_wait_for_dry() and BIO_dgram_sctp_msg_waiting() spring to mind. They get called by libssl in certain scenarios, are specific to the standard SCTP BIO, and are not replaceable via BIO_METHOD. I think you would have to implement your own versions of those functions, which implies that modifying the OpenSSL source is the only possibility. Matt From navin.shivanna at gmail.com Tue Oct 15 10:34:29 2019 From: navin.shivanna at gmail.com (Naveen Shivanna) Date: Tue, 15 Oct 2019 16:04:29 +0530 Subject: Regarding netinet/sctp.h inclusion in bss_dgram.c In-Reply-To: <17341ead-00c6-6789-b249-6e54daaefbf5@openssl.org> References: <5b42fde4-6ed7-2cfc-e6dc-487f8098ed20@openssl.org> <17341ead-00c6-6789-b249-6e54daaefbf5@openssl.org> Message-ID: Thanks. Regarding BIO_dgram_sctp_wait_for_dry() and BIO_dgram_sctp_msg_waiting(), we can use the new control options which are already merged in master : BIO_CTRL_DGRAM_SCTP_WAIT_FOR_DRY BIO_CTRL_DGRAM_SCTP_MSG_WAITING. On Tue, 15 Oct, 2019, 3:19 PM Matt Caswell, wrote: > > > On 15/10/2019 10:32, Matt Caswell wrote: > > > > > > On 15/10/2019 07:51, Naveen Shivanna wrote: > >> Hi, > >> > >> After adding 'enable-sctp' compile option, OpenSSL (DTLS) can work with > >> SCTP as transport. > >> > >> OpenSSL bss_dgram.c file includes the kernel /netinet/sctp.h. > >> > >> We have our own custom SCTP implementation (also implements custom BIO > >> METHODS, do not use the default methods), so we need to remove the > >> dependency of kernel sctp.h from bss_gram.c file. Our build environment > >> do not have the sctp.h and we are not supposed to install lksctp-tools. > >> > >> Can we tailor the bss_gram.c with new compile macro or is there any > >> other better solution ? > > > > Hmm. There isn't really a "good" way to do this. I can think of two > options: > > > > 1) Modify the OpenSSL source (perhaps in the way that you suggest with a > > compile time macro) > > > > or > > > > 2) Provide a "dummy" implementation of netinet/sctp.h. This would have > > to provide "stub" implementations of any SCTP related functions/macros > > used by bss_dgram.c. That would enable you to build unmodified OpenSSL > > source. > > Thinking about this a little more, I think you may encounter other > problems with replacing the standard SCTP BIO with your own one. The > functions BIO_dgram_sctp_wait_for_dry() and BIO_dgram_sctp_msg_waiting() > spring to mind. They get called by libssl in certain scenarios, are > specific to the standard SCTP BIO, and are not replaceable via BIO_METHOD. > > I think you would have to implement your own versions of those > functions, which implies that modifying the OpenSSL source is the only > possibility. > > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stse+openssl at fsing.rootsland.net Tue Oct 15 13:43:28 2019 From: stse+openssl at fsing.rootsland.net (Stephan Seitz) Date: Tue, 15 Oct 2019 15:43:28 +0200 Subject: Questions about secure curves Message-ID: <20191015T153733.GA.7f17d.stse@fsing.rootsland.net> Hi! I was looking at the output of ?openssl ecparam -list_curves? and trying to choose a curve for the web server together with letsencrypt. It seems, letsencrypt supports prime256v1, secp256r1, and secp384r1. Then I found the site https://safecurves.cr.yp.to/. I have problems mapping the openssl curves with the curve names from the web site, but I have the feeling that none of the choices above are safe. Or what am I missing? Shade and sweet water! Stephan -- | If your life was a horse, you'd have to shoot it. | From rsalz at akamai.com Tue Oct 15 13:52:38 2019 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 15 Oct 2019 13:52:38 +0000 Subject: Questions about secure curves In-Reply-To: <20191015T153733.GA.7f17d.stse@fsing.rootsland.net> References: <20191015T153733.GA.7f17d.stse@fsing.rootsland.net> Message-ID: <0506C611-7041-4037-A8C2-ACBD7B983350@akamai.com> There is nothing known to be wrong with NIST P256. If you don't have a known reason to use 384, then don't use it. From tmraz at redhat.com Tue Oct 15 14:50:56 2019 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 15 Oct 2019 16:50:56 +0200 Subject: Questions about secure curves In-Reply-To: <20191015T153733.GA.7f17d.stse@fsing.rootsland.net> References: <20191015T153733.GA.7f17d.stse@fsing.rootsland.net> Message-ID: <4beb73ff822ba7fc260d814bd547e992e5e104b0.camel@redhat.com> On Tue, 2019-10-15 at 15:43 +0200, Stephan Seitz wrote: > Hi! > > I was looking at the output of ?openssl ecparam -list_curves? and > trying > to choose a curve for the web server together with letsencrypt. > > It seems, letsencrypt supports prime256v1, secp256r1, and secp384r1. > > Then I found the site https://safecurves.cr.yp.to/. > I have problems mapping the openssl curves with the curve names from > the > web site, but I have the feeling that none of the choices above are > safe. > > Or what am I missing? They are not 'safe' in the sense the page above declares some elliptic curves to be safe. In particular these curves do not have some good properties the safe curves have. On the other hand that does not mean these curves are inherently insecure. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From jb-openssl at wisemo.com Tue Oct 15 15:24:12 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 15 Oct 2019 17:24:12 +0200 Subject: Questions about secure curves In-Reply-To: <20191015T153733.GA.7f17d.stse@fsing.rootsland.net> References: <20191015T153733.GA.7f17d.stse@fsing.rootsland.net> Message-ID: On 15/10/2019 15:43, Stephan Seitz wrote: > Hi! > > I was looking at the output of ?openssl ecparam -list_curves? and > trying to choose a curve for the web server together with letsencrypt. > > It seems, letsencrypt supports prime256v1, secp256r1, and secp384r1. > > Then I found the site https://safecurves.cr.yp.to/. > I have problems mapping the openssl curves with the curve names from > the web site, but I have the feeling that none of the choices above > are safe. > safecurves.cr.yp.to lists some curves that Daniel J. Bernstein (who runs the cr.yp.to domain) wants to promote, and emphasizes problems with many other popular curves. prime256v1 = secp256r1 = P-256 and secp384r1 = P-384 are two curves that the US government (NIST in cooperation with NSA) wants to promote. It so happens that the CA/Browser forum has mysteriously decided that the big (US made) web browsers should only trust CAs that only accept curves that the US government promotes.? So if you want your SSL/TLS implementation to work with widely distributed US Browsers (Chrome, Safari, Firefox, IE, Edge etc.) you have to use the US government curves P-256 and P-384 .? The third US governmentcurve P-521 is banned by Firefox, so no trusted CA can support it. 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 markhack at markhack.com Tue Oct 15 17:02:59 2019 From: markhack at markhack.com (Mark Hack) Date: Tue, 15 Oct 2019 12:02:59 -0500 Subject: Questions about secure curves In-Reply-To: References: <20191015T153733.GA.7f17d.stse@fsing.rootsland.net> Message-ID: <39a4901c223d796977c6f7bdb030ffa127d3d483.camel@markhack.com> I believe that Firefox does still support P-521 but Chrome does not. Also be aware that if you set server side cipher selection and use default curves, that OpenSSL orders the curves weakest to strongest ( even with @STRENGTH) so you will end up forcing P-256. On Tue, 2019-10-15 at 17:24 +0200, Jakob Bohm via openssl-users wrote: > On 15/10/2019 15:43, Stephan Seitz wrote: > > Hi! > > > > I was looking at the output of ?openssl ecparam -list_curves? and > > trying to choose a curve for the web server together with > > letsencrypt. > > > > It seems, letsencrypt supports prime256v1, secp256r1, and > > secp384r1. > > > > Then I found the site https://safecurves.cr.yp.to/. > > I have problems mapping the openssl curves with the curve names > > from > > the web site, but I have the feeling that none of the choices > > above > > are safe. > > > > safecurves.cr.yp.to lists some curves that Daniel J. Bernstein > (who runs the cr.yp.to domain) wants to promote, and emphasizes > problems with many other popular curves. > > prime256v1 = secp256r1 = P-256 and secp384r1 = P-384 are two curves > that the US government (NIST in cooperation with NSA) wants to > promote. > > It so happens that the CA/Browser forum has mysteriously decided > that the big (US made) web browsers should only trust CAs that > only accept curves that the US government promotes. So if you > want your SSL/TLS implementation to work with widely distributed > US Browsers (Chrome, Safari, Firefox, IE, Edge etc.) you have to > use the US government curves P-256 and P-384 . The third US > governmentcurve P-521 is banned by Firefox, so no trusted CA can > support it. > > > Enjoy > > Jakob From Maxwell_G at fortlewis.edu Tue Oct 15 17:42:14 2019 From: Maxwell_G at fortlewis.edu (Maxwell, Gary) Date: Tue, 15 Oct 2019 17:42:14 +0000 Subject: Linux error compiling OpenSSL 1.1.1d Message-ID: I have downloaded and ran the following configuration for OpenSSL 1.1.1.d ./config shared --prefix=/opt/test/openssl -openssldir=/opt/test/openssl Does anyone have any idea why I receive the following error when executing "Make" c1: error: apps/app_rand.d: No such file or directory make[1]: *** [apps/app_rand.o] Error 1 make[1]: Leaving directory `/opt/src/test/openssl' make: *** [all] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Oct 15 18:03:08 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 15 Oct 2019 14:03:08 -0400 Subject: Questions about secure curves In-Reply-To: <39a4901c223d796977c6f7bdb030ffa127d3d483.camel@markhack.com> References: <20191015T153733.GA.7f17d.stse@fsing.rootsland.net> <39a4901c223d796977c6f7bdb030ffa127d3d483.camel@markhack.com> Message-ID: <0F51DDE4-ACF5-4FA4-905C-7F67DB913978@dukhovni.org> An HTML attachment was scrubbed... URL: From georg.hoellrigl at gmx.at Tue Oct 15 18:44:01 2019 From: georg.hoellrigl at gmx.at (=?iso-8859-1?Q?Georg_H=F6llrigl?=) Date: Tue, 15 Oct 2019 20:44:01 +0200 Subject: Compile Error in Cygwin / openssl 1.1.1d Message-ID: <004301d58388$84104f70$8c30ee50$@gmx.at> Hello, I'm getting this error on compiling on MobaXTerm (basically Cygwin) compiling 1.1.1d: -------------------------------------------------------------------------- gcc -I. -Icrypto/include -Iinclude -Wall -O3 -fomit-frame-pointer -DTERMIOS -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_ IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DRMD160_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_A SM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -DNDEBUG -MMD -MF crypto/dso/dso_dlfcn.d.tm p -MT crypto/dso/dso_dlfcn.o -c -o crypto/dso/dso_dlfcn.o crypto/dso/dso_dlfcn.c crypto/dso/dso_dlfcn.c: In function 'dlfcn_pathbyaddr': crypto/dso/dso_dlfcn.c:409:5: error: unknown type name 'Dl_info' Dl_info dli; ^ crypto/dso/dso_dlfcn.c:422:5: warning: implicit declaration of function 'dladdr' [-Wimplicit-function-declaration] if (dladdr(addr, &dli)) { ^ crypto/dso/dso_dlfcn.c:423:30: error: request for member 'dli_fname' in something not a structure or union len = (int)strlen(dli.dli_fname); ^ crypto/dso/dso_dlfcn.c:432:25: error: request for member 'dli_fname' in something not a structure or union memcpy(path, dli.dli_fname, len); ^ Makefile:2735: recipe for target 'crypto/dso/dso_dlfcn.o' failed make[1]: *** [crypto/dso/dso_dlfcn.o] Error 1 make[1]: Leaving directory '/drives/c/temp/openssl-1.1.1d' Makefile:174: recipe for target 'all' failed make: *** [all] Error 2 -------------------------------------------------------------------------- I tracked down what has changed. I guess the problems were introduced with that issue & commit: https://github.com/openssl/openssl/issues/9385 https://github.com/openssl/openssl/commit/38f6f99cdf0a87345d646d30a764c089c3 8627ad Replacing the file crypto/dso/dso_dlfcn.c- with the version from 1.1.1c fixes the problem. Is there a way to get that fixed otherwise? Is that sufficient for an issue on GitHub? Any more Information I should provide? Kind Regards, Georg From yicding at gmail.com Wed Oct 16 06:45:18 2019 From: yicding at gmail.com (Yichun Ding) Date: Tue, 15 Oct 2019 23:45:18 -0700 Subject: ENGINE_init fails on TPM engine Message-ID: openssl version: *1.0.1e* During reboot, the following code is used to set up the tpm engine: ENGINE_load_builtin_engines(); e = ENGINE_by_id("tpm"); if(!e) { /* the engine isn't available */ ERR("ENGINE_by_id failed."); ERR_print_errors_fp(stderr); return CU_ERROR; } if (!ENGINE_init(e)) { int err_num = ERR_get_error(); char buf[128] = {0}; * ERR("ENGINE_init failed.");* printf("ENGINE_init error: %s\n", ERR_error_string(err_num, buf)); return CU_ERROR; } What happens is that ENGINE_init(e) fails sometimes (not always) with the following error: *ENGINE_init error: error:00000000:lib(0):func(0):reason(0)* There is no race condition in this case as far as I can tell. Is this a bug in this version of openSSL? Thanks, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Oct 16 11:48:13 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 16 Oct 2019 13:48:13 +0200 Subject: Questions about secure curves In-Reply-To: <39a4901c223d796977c6f7bdb030ffa127d3d483.camel@markhack.com> References: <20191015T153733.GA.7f17d.stse@fsing.rootsland.net> <39a4901c223d796977c6f7bdb030ffa127d3d483.camel@markhack.com> Message-ID: <79c64f40-dff1-1ee4-cac8-cd8c6e1e19af@wisemo.com> To clarify, Firefox/Mozilla the organization enforces an unexplained policy of prohibiting all included CAs from issuing any P-521 certificate, thus effectively banning their use on public servers regardless of technical abilities. On 15/10/2019 19:02, Mark Hack wrote: > I believe that Firefox does still support P-521 but Chrome does not. > Also be aware that if you set server side cipher selection and use > default curves, that OpenSSL orders the curves weakest to strongest ( > even with @STRENGTH) so you will end up forcing P-256. > > > On Tue, 2019-10-15 at 17:24 +0200, Jakob Bohm via openssl-users wrote: >> On 15/10/2019 15:43, Stephan Seitz wrote: >>> Hi! >>> >>> I was looking at the output of ?openssl ecparam -list_curves? and >>> trying to choose a curve for the web server together with >>> letsencrypt. >>> >>> It seems, letsencrypt supports prime256v1, secp256r1, and >>> secp384r1. >>> >>> Then I found the site https://safecurves.cr.yp.to/. >>> I have problems mapping the openssl curves with the curve names >>> from >>> the web site, but I have the feeling that none of the choices >>> above >>> are safe. >>> >> safecurves.cr.yp.to lists some curves that Daniel J. Bernstein >> (who runs the cr.yp.to domain) wants to promote, and emphasizes >> problems with many other popular curves. >> >> prime256v1 = secp256r1 = P-256 and secp384r1 = P-384 are two curves >> that the US government (NIST in cooperation with NSA) wants to >> promote. >> >> It so happens that the CA/Browser forum has mysteriously decided >> that the big (US made) web browsers should only trust CAs that >> only accept curves that the US government promotes. So if you >> want your SSL/TLS implementation to work with widely distributed >> US Browsers (Chrome, Safari, Firefox, IE, Edge etc.) you have to >> use the US government curves P-256 and P-384 . The third US >> governmentcurve P-521 is banned by Firefox, so no trusted CA can >> support it. >> Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Soborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From michaeladria at me.com Wed Oct 16 20:10:13 2019 From: michaeladria at me.com (Michael Adria) Date: Wed, 16 Oct 2019 20:10:13 -0000 Subject: Building and testing 1.1.1t with /MT run-time library Message-ID: <5c867266-4ffc-46b4-9225-2192140fc562@me.com> Hi everyone, On Windows, we require both /MD and /MT builds of OpenSSL, with Control Flow Guard enabled. To do so, we tried using these steps in cmd.exe recently when compiling 1.1.1d for /MT (64-bit shown; we also build 32-bit): $ perl Configure VC-WIN64A no-asm --prefix= $ ms\do_ms $?perl -p -i.back -e "s/\/MD/\/MT/g;"?makefile $?perl -p -i.back -e "s/^CFLAGS=/CFLAGS=\/GUARD:cf /g;" makefile $?perl -p -i.back -e "s/^LDFLAGS=/LDFLAGS=\/GUARD:cf /g;" makefile $ nmake $ nmake test $ nmake install_sw Unfortunately, there are failing tests (There are "Failed x/y subtests" and "Dubious, test returned..." messages for almost all tests). When we follow similar steps for 1.0.2t (by modifying ms\ntdll.mak), the tests pass for both the default /MD and the /MT modification. Is there a correct way to build OpenSSL 1.1.1d with the /MT run-time library such that the tests run successfully? Also, is there a better way to use CFG? Thanks, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From mann.patidar at gmail.com Thu Oct 17 04:57:54 2019 From: mann.patidar at gmail.com (Manish Patidar) Date: Thu, 17 Oct 2019 10:27:54 +0530 Subject: Fipsinstall failing Message-ID: Hi I am trying latest master code to install the fips, but it is not working. openssl fipsinstall -module ./fips.so -out fips.conf -provider_name fips - section_name fipsinstall -mac_name HMAC -macopt digest:SHA256 -macopt hexkey:000102030405060708090A0B0C0D0E0F10111213 It is failing in verify_integrity function as hmac is not matching. Please help to solve this issue Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.ente at cromology.com Fri Oct 18 06:51:23 2019 From: benjamin.ente at cromology.com (Benjamin ENTE) Date: Fri, 18 Oct 2019 06:51:23 +0000 Subject: Base64 or Base64url In-Reply-To: References: Message-ID: Hi everyone I'm looking for an information I can't find. I'm using OpenSSL 1.0.1e 11 Feb 2013 and I want to know if it's encoding in base64 or in base64url. Thank you in advance for your help Best regards Benjamin [http://www.cromology.com/mail/cromology-it.gif] Benjamin ENTE Ing?nieur syst?me et BDD Services Infrastructure 71, Bd du G?n?ral Leclerc - 92583 Clichy cedex Tel. +33(0)175338276 | Mobile. +33(0)678003942 benjamin.ente at cromology.com www.cromology.com Merci de penser ? l'environnement avant d'imprimer ce message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Fri Oct 18 07:05:18 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Fri, 18 Oct 2019 07:05:18 +0000 Subject: AW: Base64 or Base64url In-Reply-To: References: Message-ID: <1d25d543781c43f5a1bcb3e5f337dbaa@Ex13.ncp.local> OpenSSL is using regular base64 encoding, see for example https://www.openssl.org/docs/man1.1.1/man3/EVP_EncodeInit.html But if you need base64url encoding, no problem: a simple string replace will help. https://brockallen.com/2014/10/17/base64url-encoding/ Regards, Matthias Von: openssl-users Im Auftrag von Benjamin ENTE Gesendet: Freitag, 18. Oktober 2019 08:51 An: openssl-users at openssl.org Betreff: Base64 or Base64url Hi everyone I'm looking for an information I can't find. I'm using?OpenSSL 1.0.1e 11 Feb 2013 and I want to know if it's encoding in base64 or in base64url. Thank you in advance for your help Best regards Benjamin Benjamin ENTE Ing?nieur syst?me et BDD Services Infrastructure 71, Bd du G?n?ral Leclerc - 92583 Clichy cedex Tel. +33(0)175338276 | Mobile. +33(0)678003942 mailto:%22benjamin.ente at cromology.com%22? http://www.cromology.com/ Merci de penser ? l'environnement avant d'imprimer ce message. From Matthias.St.Pierre at ncp-e.com Fri Oct 18 07:10:26 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Fri, 18 Oct 2019 07:10:26 +0000 Subject: AW: Base64 or Base64url In-Reply-To: References: Message-ID: <819c8bee3f2e402a962ee438e2a93918@Ex13.ncp.local> Just noticed your OpenSSL version: it is _very_ old and not supported anymore. its successor, OpenSSL 1.0.2, will be EOL by the end of this year. The current stable LTS version is OpenSSL 1.1.1. Matthias Von: openssl-users Im Auftrag von Benjamin ENTE Gesendet: Freitag, 18. Oktober 2019 08:51 An: openssl-users at openssl.org Betreff: Base64 or Base64url Hi everyone I'm looking for an information I can't find. I'm using OpenSSL 1.0.1e 11 Feb 2013 and I want to know if it's encoding in base64 or in base64url. Thank you in advance for your help Best regards Benjamin [http://www.cromology.com/mail/cromology-it.gif] Benjamin ENTE Ing?nieur syst?me et BDD Services Infrastructure 71, Bd du G?n?ral Leclerc - 92583 Clichy cedex Tel. +33(0)175338276 | Mobile. +33(0)678003942 benjamin.ente at cromology.com www.cromology.com Merci de penser ? l'environnement avant d'imprimer ce message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Fri Oct 18 07:14:51 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Fri, 18 Oct 2019 07:14:51 +0000 Subject: AW: Base64 or Base64url In-Reply-To: <819c8bee3f2e402a962ee438e2a93918@Ex13.ncp.local> References: <819c8bee3f2e402a962ee438e2a93918@Ex13.ncp.local> Message-ID: <851716020f7846ffa50bed7e1d48754c@Ex13.ncp.local> P.S: My answer to your original question applies to 1.0.1 as well: https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/doc/crypto/EVP_EncodeInit.pod Von: openssl-users Im Auftrag von Dr. Matthias St. Pierre Gesendet: Freitag, 18. Oktober 2019 09:10 An: Benjamin ENTE ; openssl-users at openssl.org Betreff: AW: Base64 or Base64url Just noticed your OpenSSL version: it is _very_ old and not supported anymore. its successor, OpenSSL 1.0.2, will be EOL by the end of this year. The current stable LTS version is OpenSSL 1.1.1. Matthias Von: openssl-users > Im Auftrag von Benjamin ENTE Gesendet: Freitag, 18. Oktober 2019 08:51 An: openssl-users at openssl.org Betreff: Base64 or Base64url Hi everyone I'm looking for an information I can't find. I'm using OpenSSL 1.0.1e 11 Feb 2013 and I want to know if it's encoding in base64 or in base64url. Thank you in advance for your help Best regards Benjamin [http://www.cromology.com/mail/cromology-it.gif] Benjamin ENTE Ing?nieur syst?me et BDD Services Infrastructure 71, Bd du G?n?ral Leclerc - 92583 Clichy cedex Tel. +33(0)175338276 | Mobile. +33(0)678003942 benjamin.ente at cromology.com www.cromology.com Merci de penser ? l'environnement avant d'imprimer ce message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.ente at cromology.com Fri Oct 18 08:17:55 2019 From: benjamin.ente at cromology.com (Benjamin ENTE) Date: Fri, 18 Oct 2019 08:17:55 +0000 Subject: Base64 or Base64url In-Reply-To: <819c8bee3f2e402a962ee438e2a93918@Ex13.ncp.local> References: , <819c8bee3f2e402a962ee438e2a93918@Ex13.ncp.local> Message-ID: Thank you for your answer. I know, my version is old and I need to update (and I will). It's installed on IBM AIX server. I was not precise enough in my question, I need to have base64url natively supported for a certification purpose. I'm using openssl in some bash scripts, I can easily replace characters to bypass the problem of / and + but I don't think I will be authorized to do so. Is there any other options ? Best regards [http://www.cromology.com/mail/cromology-it.gif] Benjamin ENTE Ing?nieur syst?me et BDD Services Infrastructure 71, Bd du G?n?ral Leclerc - 92583 Clichy cedex Tel. +33(0)175338276 | Mobile. +33(0)678003942 benjamin.ente at cromology.com www.cromology.com Merci de penser ? l'environnement avant d'imprimer ce message. ________________________________ De : Dr. Matthias St. Pierre Envoy? : vendredi 18 octobre 2019 09:10 ? : Benjamin ENTE ; openssl-users at openssl.org Objet : AW: Base64 or Base64url Just noticed your OpenSSL version: it is _very_ old and not supported anymore. its successor, OpenSSL 1.0.2, will be EOL by the end of this year. The current stable LTS version is OpenSSL 1.1.1. Matthias [NCP engingeering GmbH] Dr. Matthias St. Pierre Senior Software Engineer matthias.st.pierre at ncp-e.com Phone: +49 911 9968-0 www.ncp-e.com Follow us on: Facebook | Twitter | Xing | YouTube | LinkedIn Headquarters Germany: NCP engineering GmbH ? Dombuehler Str. 2 ? 90449 ? Nuremberg North American HQ: NCP engineering Inc. ? 678 Georgia Ave. ? Sunnyvale, CA 94085 East Coast Office: NCP engineering Inc. ? 601 Cleveland Str., Suite 501-25 ? Clearwater, FL 33755 Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich Registry Court: Lower District Court of Nuremberg Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE 133557619 This e-mail message including any attachments is for the sole use of the intended recipient(s) and may contain privileged or confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply e-mail and delete the original message and destroy all copies thereof. Von: openssl-users Im Auftrag von Benjamin ENTE Gesendet: Freitag, 18. Oktober 2019 08:51 An: openssl-users at openssl.org Betreff: Base64 or Base64url Hi everyone I'm looking for an information I can't find. I'm using OpenSSL 1.0.1e 11 Feb 2013 and I want to know if it's encoding in base64 or in base64url. Thank you in advance for your help Best regards Benjamin [http://www.cromology.com/mail/cromology-it.gif] Benjamin ENTE Ing?nieur syst?me et BDD Services Infrastructure 71, Bd du G?n?ral Leclerc - 92583 Clichy cedex Tel. +33(0)175338276 | Mobile. +33(0)678003942 benjamin.ente at cromology.com www.cromology.com Merci de penser ? l'environnement avant d'imprimer ce message. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Outlook-NCP enging.png Type: image/png Size: 4278 bytes Desc: Outlook-NCP enging.png URL: From luca.dimauro at cnit.it Fri Oct 18 08:22:50 2019 From: luca.dimauro at cnit.it (Luca Di Mauro) Date: Fri, 18 Oct 2019 08:22:50 +0000 Subject: Compute EC_KEY starting from X or Y coordinate only Message-ID: <20191018082250.Horde.X2EVDG4j6ZO3jOF3bhcPJA1@webmail.cnit.it> Hello all, I don't know if it is the correct mailing list to ask this, so I'm sorry if it is the wrong palce. I'm using openssl v1.1, and I'm trying to compute both the X and Y coordinates of an elliptic curve point starting from a single coordinate (X or Y). How can i perform that in C/C++ language using libssl? I searched on google for a couple of days but i haven't found a solution. Luca Di Mauro From nic.tuv at gmail.com Fri Oct 18 08:46:16 2019 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Fri, 18 Oct 2019 11:46:16 +0300 Subject: Compute EC_KEY starting from X or Y coordinate only In-Reply-To: <20191018082250.Horde.X2EVDG4j6ZO3jOF3bhcPJA1@webmail.cnit.it> References: <20191018082250.Horde.X2EVDG4j6ZO3jOF3bhcPJA1@webmail.cnit.it> Message-ID: Hi, with traditional EC from the x coordinate alone you can't really do that, because there are always 2 possible solutions for y (in R the curve is symmetrical on the x axis). The standards define a "compressed point" format in which you can send the coordinate x and an additional bit to select which of the 2 y solutions to pick. You can read more about it in EC_GROUP_set_point_conversion_form at https://www.openssl.org/docs/man1.1.1/man3/EC_GROUP_copy.html and in EC_POINT_set_compressed_coordinates at https://www.openssl.org/docs/man1.1.1/man3/EC_POINT_new.html Hope this helps, Nicola Tuveri On Fri, Oct 18, 2019, 11:31 Luca Di Mauro wrote: > > Hello all, > > I don't know if it is the correct mailing list to ask this, so I'm > sorry if it is the wrong palce. > > I'm using openssl v1.1, and I'm trying to compute both the X and Y > coordinates of an elliptic curve point starting from a single > coordinate (X or Y). > > How can i perform that in C/C++ language using libssl? I searched on > google for a couple of days but i haven't found a solution. > > Luca Di Mauro > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.dimauro at cnit.it Fri Oct 18 09:56:27 2019 From: luca.dimauro at cnit.it (Luca Di Mauro) Date: Fri, 18 Oct 2019 09:56:27 +0000 Subject: Compute EC_KEY starting from X or Y coordinate only In-Reply-To: References: <20191018082250.Horde.X2EVDG4j6ZO3jOF3bhcPJA1@webmail.cnit.it> Message-ID: <20191018095627.Horde.MZt6vFx0ov5Nc8zyVlGlyw4@webmail.cnit.it> Thank you very much for the reply! Yes, I have also the additional information about on which of two solutions I should take. I'll check the guides you linked below. Luca Di Mauro Nicola Tuveri ha scritto: > Hi, > > with traditional EC from the x coordinate alone you can't really do that, > because there are always 2 possible solutions for y (in R the curve is > symmetrical on the x axis). > > The standards define a "compressed point" format in which you can send the > coordinate x and an additional bit to select which of the 2 y solutions to > pick. > > You can read more about it in EC_GROUP_set_point_conversion_form at > https://www.openssl.org/docs/man1.1.1/man3/EC_GROUP_copy.html > > and in EC_POINT_set_compressed_coordinates at > https://www.openssl.org/docs/man1.1.1/man3/EC_POINT_new.html > > Hope this helps, > > Nicola Tuveri > > > On Fri, Oct 18, 2019, 11:31 Luca Di Mauro wrote: > >> >> Hello all, >> >> I don't know if it is the correct mailing list to ask this, so I'm >> sorry if it is the wrong palce. >> >> I'm using openssl v1.1, and I'm trying to compute both the X and Y >> coordinates of an elliptic curve point starting from a single >> coordinate (X or Y). >> >> How can i perform that in C/C++ language using libssl? I searched on >> google for a couple of days but i haven't found a solution. >> >> Luca Di Mauro >> >> >> From nagalakshmi.j at altran.com Fri Oct 18 10:49:58 2019 From: nagalakshmi.j at altran.com (Nagalakshmi V J) Date: Fri, 18 Oct 2019 10:49:58 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: <2739d542-13a2-4778-47fd-c45b45492f37@openssl.org> References: <2b8035491b1d40668758b78936fab706@Ex13.ncp.local> <2739d542-13a2-4778-47fd-c45b45492f37@openssl.org> Message-ID: Hi Matt, Sorry I missed your reply as all the conversations are jumbled in that mail. Please find the sample code snippet. This is a small part. Like the below sample, we are using SSL and SSL_SESSION structures in many places. struct PRF_GENERATOR { unsigned char master_secret[48]; unsigned char server_random[32]; unsigned char client_random[32]; }; int functionA(SSL* s, PRF_GENERATOR* pGenerator) { if( s->session->master_key_length != sizeof(pGenerator->master_secret) ) return -1; memcpy(pGenerator->master_secret, s->session->master_key, sizeof(pGenerator->master_secret)); memcpy(pGenerator->server_random, s->s3->server_random, sizeof(pGenerator->server_random)); memcpy(pGenerator->client_random, s->s3->client_random, sizeof(pGenerator->client_random)); return 0; } In the above function, they are accessing the session from SSL structure as s->session (using openssl 1.0.2j). We cannot access like this 1.1.1c. So we need to use the accessor API which is SSL_get_session(s). Referred this link (https://www.openssl.org/docs/man1.1.0/man7/ssl.html) Now the issue is SSL_session structure is also having accessor APIs which I am not aware of. So I need to get the APIs for accessing the master_key_length,etc.. given in the above code. Those are not listed in the openssl link referred. It would be helpful if I can get to know about the accessor APIs. If you know any documentation link which talks about accessor APIs or any files where all these details are there, you can refer me that. Kindly let me know if you have any queries with respect to this sample code. Thanks and regards, Nagalakshmi -----Original Message----- From: openssl-users On Behalf Of Matt Caswell Sent: Thursday, October 3, 2019 6:51 PM To: openssl-users at openssl.org Subject: Re: OpenSSL compilation errors in Windows ** This mail has been sent from an external source ** On 03/10/2019 11:10, Nagalakshmi V J wrote: > Hi Matthias, > > > > Please find my response for your queries below. > > > > It would be more helpful if you would tell us *why* you are including > ssl_locl.h and what you are trying to achieve. Then we might be able > to tell you how you could achieve your goal using the officially supported API. > > [Nagalakshmi]: > > In our product code, we are using the structures 'ssl_st' and 'ssl_session_st' > which were defined in ssl.h file in Openssl 1.0.2.j version. > > Since the structure definitions are made opaque in openssl 1.1.1c, we > used ssl_locl.h where the structure definitions are available. > > > > Please note that many of the OpenSSL structures were made opaque in > version 1.1.0. This means that there are only forward declarations of > the structures in the public headers and the compiler does not get to see the structure members. > Instead of directly accessing the members, it is now necessary to use > accessor functions (a.k.a. getters and setters). > > [Nagalakshmi]: > > Regarding usage of accessor functions, I got the following APIs. > > SSL_get_session(s) > > SSL_SESSION_get_master_key(). > > > > If we use those APIs, I am again getting errors like the below. > > /.\odlibPrf_OSSL.h(164) : error C2027: use of undefined type > 'ssl_session_st'/ > > / ..\..\OpenSSL\openssl-1.1.1c\include\openssl/ssl.h(213) : see > declaration of 'ssl_session_st'/ > > /.\odlibPrf_OSSL.h(164) : error C2227: left of '->SSL_SESSION_get_master_key' > must point to class/struct/union/ This at least looks like a syntax error. > > /.\odlibPrf_OSSL.h(167) : error C2027: use of undefined type 'ssl_st'/ > > / ..\..\OpenSSL\openssl-1.1.1c\include\openssl/ossl_typ.h(147) : see > declaration of 'ssl_st'/ > > /.\odlibPrf_OSSL.h(167) : error C2227: left of '->session' must point > to class/struct/union/ > > /.\odlibPrf_OSSL.h(167) : error C2227: left of '->master_key' must > point to class/struct/union/ These suggest you're still trying to direct access structure members. > > /.\odlibPrf_OSSL.h(168) : error C2027: use of undefined type 'ssl_st'/ Please show us the source code for the lines these error message correspond to. Matt > > > > Can you help me to get the corresponding accessor functions for these 2 structures. > > > > Thanks and regards, > > Nagalakshmi > > > > -----Original Message----- > From: Nagalakshmi V J > Sent: Tuesday, October 1, 2019 6:33 PM > To: Dr. Matthias St. Pierre ; > Nagalakshmi V J > Cc: openssl-users at openssl.org; Umamaheswari Nagarajan > > Subject: RE: OpenSSL compilation errors in Windows > > > > Thank you Matthias for the explanation. I am going through my code to > understand why ssl_locl.h is included. I will check and get back on > this ASAP. Also if there is other way to achieve that I will use the same. > > > > Thanks and regards, > > Nagalakshmi > > > > -----Original Message----- > > From: Dr. Matthias St. Pierre > > > Sent: Tuesday, October 1, 2019 4:43 PM > > To: Nagalakshmi V J > > > Cc: openssl-users at openssl.org ; > Umamaheswari Nagarajan > > > Subject: AW: OpenSSL compilation errors in Windows > > > > ** This mail has been sent from an external source ** > > > > > >> We are using OpenSSL APIs in our product code. We are not making any >> changes > in OpenSSL. > >> Our product code is a C++ code and it makes use of openSSL APIs for >> some > functionality. > > > > Local headers (like "ssl_locl.h" and "packet_locl.h") are *NOT* part > of the official OpenSSL API. > > Please don't expect any support w.r.t. compilation or compatibility > problems if you do include them in your application, even more if it's > compiled using a C++ compiler. > > > > It would be more helpful if you would tell us *why* you are including > ssl_locl.h and what you are trying to achieve. Then we might be able > to tell you how you could achieve your goal using the officially supported API. > > > > Please note that many of the OpenSSL structures were made opaque in > version 1.1.0. This means that there are only forward declarations of > the structures in the public headers and the compiler does not get to see the structure members. > Instead of directly accessing the members, it is now necessary to use > accessor functions (a.k.a. getters and setters). If this is the reason > why you are including private OpenSSL headers then you should adopt > you application to use the new accessors instead, instead of forcing > the impossible to circumvent the new policy. > > > > For more information, see > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openssl.org_ > index.php_OpenSSL-5F1.1.0-5FChanges&d=DwIGaQ&c=cxWN2QSDopt5SklNfbjIjg& > r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=wpEV8Q2RDZjERhtJGZl9Ha > jV9jd2dJFF10J30_YrPQo&s=sX1YilJaXloAQDzrjD3Lz-I6DOej3QduhsAanXOYxVM&e= > > > > Matthias > > > > > > > > > > > > Dr. Matthias St. Pierre > > Senior Software Engineer > > matthias.st.pierre at ncp-e.com > > Phone: +49 911 9968-0 > > www.ncp-e.com > =DwIDaQ&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5at > SqEGOnpA&m=cDw8_L60-mZAOD-FHwthgUKK4jglLexW6Wpi6EEaKM4&s=XlNG1utFTM1jM > -izig9lVO9BsRhW9nRWv3oqbsVCOmw&e= > > > > > Headquarters Germany: NCP engineering GmbH ? Dombuehler Str. 2 ? 90449 > ? Nuremberg North American HQ: NCP engineering Inc. ? 678 Georgia Ave. > ? Sunnyvale, CA 94085 East Coast Office: NCP engineering Inc. ? 601 > Cleveland Str., Suite 501-25 ? Clearwater, FL 33755 > > > > Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate > Dietrich Registry Court: Lower District Court of Nuremberg Commercial > register No.: HRB > 7786 Nuremberg, VAT identification No.: DE 133557619 > > > > This e-mail message including any attachments is for the sole use of > the intended recipient(s) and may contain privileged or confidential information. > Any unauthorized review, use, disclosure or distribution is > prohibited. If you are not the intended recipient, please immediately > contact the sender by reply e-mail and delete the original message and destroy all copies thereof. > > ===================================================== > > Please refer to https://northamerica.altran.com/email-disclaimer > > for important disclosures regarding this electronic communication. > > ===================================================== > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== From matt at openssl.org Fri Oct 18 14:48:33 2019 From: matt at openssl.org (Matt Caswell) Date: Fri, 18 Oct 2019 15:48:33 +0100 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: <2b8035491b1d40668758b78936fab706@Ex13.ncp.local> <2739d542-13a2-4778-47fd-c45b45492f37@openssl.org> Message-ID: On 18/10/2019 11:49, Nagalakshmi V J wrote: > Now the issue is SSL_session structure is also having accessor APIs > which I am not aware of. So I need to get the APIs for accessing the > master_key_length,etc.. given in the above code. Those are not listed > in the openssl link referred. On this page look a the various functions beginning with "SSL_SESSION_" in the name: https://www.openssl.org/docs/man1.1.1/man3/ >From the code sample you gave you are probably mostly interested in the functions on this page: https://www.openssl.org/docs/man1.1.1/man3/SSL_SESSION_get_master_key.html Matt From rsalz at akamai.com Fri Oct 18 21:10:18 2019 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 18 Oct 2019 21:10:18 +0000 Subject: Need a .gitignore fix on master Message-ID: <5C633E97-B3A6-4008-A004-95CF6AA978CB@akamai.com> >; git status >On branch master >Your branch is up-to-date with 'origin/master'. >Untracked files: > (use "git add ..." to include in what will be committed) > > include/openssl/opensslv.h > >nothing added to commit but untracked files present (use "git add" to >track) >; From nagalakshmi.j at altran.com Sun Oct 20 07:43:03 2019 From: nagalakshmi.j at altran.com (Nagalakshmi V J) Date: Sun, 20 Oct 2019 07:43:03 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: <2b8035491b1d40668758b78936fab706@Ex13.ncp.local> <2739d542-13a2-4778-47fd-c45b45492f37@openssl.org> , Message-ID: Hi Matt, This link is having few APIS. But for getting master_key_length, I don't find any API. Not sure if we need to use getMasterKey API for that. I will try to use these APIs and get back. Thanks & Regards, Nagalakshmi V J ________________________________ From: Matt Caswell Sent: 18 October 2019 14:48:33 To: Nagalakshmi V J ; openssl-users at openssl.org Subject: Re: OpenSSL compilation errors in Windows ** This mail has been sent from an external source ** On 18/10/2019 11:49, Nagalakshmi V J wrote: > Now the issue is SSL_session structure is also having accessor APIs > which I am not aware of. So I need to get the APIs for accessing the > master_key_length,etc.. given in the above code. Those are not listed > in the openssl link referred. On this page look a the various functions beginning with "SSL_SESSION_" in the name: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.1.1_man3_&d=DwICaQ&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=MZhYFrTAuuHOqAirPiGbT1CY6HDdH2U_CWYq12626Ts&s=gE0JHTVoToRHQRu5h2amvKa5WzyXsortlw0IoQd3VG4&e= >From the code sample you gave you are probably mostly interested in the functions on this page: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.1.1_man3_SSL-5FSESSION-5Fget-5Fmaster-5Fkey.html&d=DwICaQ&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=MZhYFrTAuuHOqAirPiGbT1CY6HDdH2U_CWYq12626Ts&s=XTuEzS7qyBvIHc_qWJYoh3JVC4zPCzvUzNPStW_SvLI&e= Matt ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From salman.a.baset at gmail.com Mon Oct 21 11:11:23 2019 From: salman.a.baset at gmail.com (Salman Baset) Date: Mon, 21 Oct 2019 07:11:23 -0400 Subject: OpenSSL 1.0.2 EOL and new FIPS-validated crypto module Message-ID: Hello everyone, I was wondering if there is any update on getting a new FIPS-validated module for OpenSSL by the end of this year (before EOL of 1.0.2), as was mentioned in this blog post: https://www.openssl.org/blog/blog/2018/09/25/fips/ According to this email, the new FIPS module is dependent on OpenSSL 3.0, whose release timing is not certain yet. https://mta.openssl.org/pipermail/openssl-users/2019-February/009836.html I will appreciate if someone can provide an update on the new FIPS timeline as that will help folks who are looking to depend on OpenSSL's FIPS-validated modules in the next 6-9 months or so. Lastly, is there any chance of extending the EOL date of OpenSSL 1.0.2 till the new FIPS module/OpenSSL 3.0 becomes available? Thanks Salman -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Oct 21 12:33:29 2019 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 21 Oct 2019 12:33:29 +0000 Subject: OpenSSL 1.0.2 EOL and new FIPS-validated crypto module In-Reply-To: References: Message-ID: <45E39F73-0CC9-4424-8861-E85B7E98955B@akamai.com> * Lastly, is there any chance of extending the EOL date of OpenSSL 1.0.2 till the new FIPS module/OpenSSL 3.0 becomes available? This question gets asked a great deal. Why? The OpenSSL project has not done any 1.0.2-FIPS work for years. This means that if there are any CVE-level bugs in 1.0.2 that affect(ed) that FIPS module, they weren?t getting fixed and the module wasn?t being revalidated. This has been the situation for several years. By 1.0.2 going out of support, all this means is that the OpenSSL project will not be posting bugfixes. Nobody is going to come and make you delete your own copies. So why do people care if it goes out of support? I suspect the answer is this: by using the open source code, you didn?t have to pay anything or do any support and maintenance, and now they are worried about having to do so. Is there another reason? -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Mon Oct 21 15:56:16 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Tue, 22 Oct 2019 01:56:16 +1000 Subject: OpenSSL 1.0.2 EOL and new FIPS-validated crypto module In-Reply-To: References: Message-ID: <0EDDD039-95A2-4B33-8A3D-434BE0A9EA9B@oracle.com> The EOL date for OpenSSL 1.0.2 will not be extended. It is possible to purchase premium level support which will provide 1.0.2 updates beyond its normal end of life. See: https://www.openssl.org/support/contracts.html#premium Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 21 Oct 2019, at 9:11 pm, Salman Baset wrote: > > Hello everyone, > > I was wondering if there is any update on getting a new FIPS-validated module for OpenSSL by the end of this year (before EOL of 1.0.2), as was mentioned in this blog post: > https://www.openssl.org/blog/blog/2018/09/25/fips/ > > According to this email, the new FIPS module is dependent on OpenSSL 3.0, whose release timing is not certain yet. > https://mta.openssl.org/pipermail/openssl-users/2019-February/009836.html > > I will appreciate if someone can provide an update on the new FIPS timeline as that will help folks who are looking to depend on OpenSSL's FIPS-validated modules in the next 6-9 months or so. > > Lastly, is there any chance of extending the EOL date of OpenSSL 1.0.2 till the new FIPS module/OpenSSL 3.0 becomes available? > > Thanks > Salman -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Oct 21 21:26:32 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 21 Oct 2019 22:26:32 +0100 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: <2b8035491b1d40668758b78936fab706@Ex13.ncp.local> <2739d542-13a2-4778-47fd-c45b45492f37@openssl.org> Message-ID: On 20/10/2019 08:43, Nagalakshmi V J wrote: > Hi Matt, > > This link is having few APIS. But for getting master_key_length, I don't > find any API. Not sure if we need to use getMasterKey API for that. You can use SSL_SESSION_get_master_key() for this. Note this comment in the RETURN VALUES section: "For the other functions, if outlen is greater than 0 then these functions return the number of bytes actually copied, which will be less than or equal to outlen. If outlen is 0 then these functions return the maximum number of bytes they would copy -- that is, the length of the underlying field." So to discover the master_key_length call the function with outlen to zero. You can then allocate an appropriate sized buffer and call the function again in order to get the actual master key. Matt > > I will try to use these APIs and get back. > > Thanks & Regards, > Nagalakshmi V J > ------------------------------------------------------------------------ > *From:* Matt Caswell > *Sent:* 18 October 2019 14:48:33 > *To:* Nagalakshmi V J ; > openssl-users at openssl.org > *Subject:* Re: OpenSSL compilation errors in Windows > ? > ** This mail has been sent from an external source ** > > > On 18/10/2019 11:49, Nagalakshmi V J wrote: >> Now the issue is SSL_session structure is also having accessor APIs >> which I am not aware of. So I need to get the APIs for accessing the >> master_key_length,etc.. given in the above code. Those are not listed >> in the openssl link referred. > > On this page look a the various functions beginning with "SSL_SESSION_" > in the name: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.1.1_man3_&d=DwICaQ&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=MZhYFrTAuuHOqAirPiGbT1CY6HDdH2U_CWYq12626Ts&s=gE0JHTVoToRHQRu5h2amvKa5WzyXsortlw0IoQd3VG4&e= > > From the code sample you gave you are probably mostly interested in the > functions on this page: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.1.1_man3_SSL-5FSESSION-5Fget-5Fmaster-5Fkey.html&d=DwICaQ&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=MZhYFrTAuuHOqAirPiGbT1CY6HDdH2U_CWYq12626Ts&s=XTuEzS7qyBvIHc_qWJYoh3JVC4zPCzvUzNPStW_SvLI&e= > > Matt > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== From nagalakshmi.j at altran.com Tue Oct 22 04:09:00 2019 From: nagalakshmi.j at altran.com (Nagalakshmi V J) Date: Tue, 22 Oct 2019 04:09:00 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: <2b8035491b1d40668758b78936fab706@Ex13.ncp.local> <2739d542-13a2-4778-47fd-c45b45492f37@openssl.org> , Message-ID: Hi Matt, Yes. Exactly we followed the same and able to resolve errors. Thank you so much for the support and guidance. I'll get back if any further errors. Thanks & Regards, Nagalakshmi V J ________________________________ From: Matt Caswell Sent: 21 October 2019 21:26:32 To: Nagalakshmi V J ; openssl-users at openssl.org Subject: Re: OpenSSL compilation errors in Windows ** This mail has been sent from an external source ** On 20/10/2019 08:43, Nagalakshmi V J wrote: > Hi Matt, > > This link is having few APIS. But for getting master_key_length, I don't > find any API. Not sure if we need to use getMasterKey API for that. You can use SSL_SESSION_get_master_key() for this. Note this comment in the RETURN VALUES section: "For the other functions, if outlen is greater than 0 then these functions return the number of bytes actually copied, which will be less than or equal to outlen. If outlen is 0 then these functions return the maximum number of bytes they would copy -- that is, the length of the underlying field." So to discover the master_key_length call the function with outlen to zero. You can then allocate an appropriate sized buffer and call the function again in order to get the actual master key. Matt > > I will try to use these APIs and get back. > > Thanks & Regards, > Nagalakshmi V J > ------------------------------------------------------------------------ > *From:* Matt Caswell > *Sent:* 18 October 2019 14:48:33 > *To:* Nagalakshmi V J ; > openssl-users at openssl.org > *Subject:* Re: OpenSSL compilation errors in Windows > > ** This mail has been sent from an external source ** > > > On 18/10/2019 11:49, Nagalakshmi V J wrote: >> Now the issue is SSL_session structure is also having accessor APIs >> which I am not aware of. So I need to get the APIs for accessing the >> master_key_length,etc.. given in the above code. Those are not listed >> in the openssl link referred. > > On this page look a the various functions beginning with "SSL_SESSION_" > in the name: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.1.1_man3_&d=DwICaQ&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=MZhYFrTAuuHOqAirPiGbT1CY6HDdH2U_CWYq12626Ts&s=gE0JHTVoToRHQRu5h2amvKa5WzyXsortlw0IoQd3VG4&e= > > From the code sample you gave you are probably mostly interested in the > functions on this page: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.1.1_man3_SSL-5FSESSION-5Fget-5Fmaster-5Fkey.html&d=DwICaQ&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=MZhYFrTAuuHOqAirPiGbT1CY6HDdH2U_CWYq12626Ts&s=XTuEzS7qyBvIHc_qWJYoh3JVC4zPCzvUzNPStW_SvLI&e= > > Matt > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Tue Oct 22 07:04:15 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Tue, 22 Oct 2019 17:04:15 +1000 Subject: OpenSSL blog post by APNIC Message-ID: <3EB1068D-EA00-4FC8-BF76-67AF0688E536@oracle.com> An APNIC article loosely based on the OpenSSL presentation at AusCERT earlier this year: https://blog.apnic.net/2019/10/21/openssl-3-0-accelerating-forwards/ Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From nagalakshmi.j at altran.com Tue Oct 22 10:41:40 2019 From: nagalakshmi.j at altran.com (Nagalakshmi V J) Date: Tue, 22 Oct 2019 10:41:40 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: <2b8035491b1d40668758b78936fab706@Ex13.ncp.local> <2739d542-13a2-4778-47fd-c45b45492f37@openssl.org> , Message-ID: Hi Matt, Could you please help to get any clue on the ACCESSOR APIs of the following. I tried searching APIs. Not getting exact matches. Referred the below links. https://www.openssl.org/docs/man1.1.1/man3/SSL_set_info_callback.html https://www.openssl.org/docs/man1.1.1/man3/EVP_md5.html Getting similar error for the below code. tls1_PRF(s->ctx->md5,s->ctx->sha1,buf,(int)(p-buf), pGenerator->master_secret,sizeof(pGenerator->master_secret), km,tmp,num); Struct ssl_ctx_st { ... const EVP_MD *md5; /* For SSLv3/TLSv1 'ssl3-md5' */ const EVP_MD *sha1; /* For SSLv3/TLSv1 'ssl3->sha1' */ ... } struct evp_md_st { int type; int pkey_type; int md_size; unsigned long flags; int (*init) (EVP_MD_CTX *ctx); int (*update) (EVP_MD_CTX *ctx, const void *data, size_t count); int (*final) (EVP_MD_CTX *ctx, unsigned char *md); int (*copy) (EVP_MD_CTX *to, const EVP_MD_CTX *from); int (*cleanup) (EVP_MD_CTX *ctx); int block_size; int ctx_size; /* how big does the ctx->md_data need to be */ /* control function */ int (*md_ctrl) (EVP_MD_CTX *ctx, int cmd, int p1, void *p2); } /* EVP_MD */ ; Thanks and regards, Nagalakshmi From: Nagalakshmi V J Sent: Tuesday, October 22, 2019 9:39 AM To: Matt Caswell ; Nagalakshmi V J ; openssl-users at openssl.org Subject: Re: OpenSSL compilation errors in Windows Hi Matt, Yes. Exactly we followed the same and able to resolve errors. Thank you so much for the support and guidance. I'll get back if any further errors. Thanks & Regards, Nagalakshmi V J ________________________________ From: Matt Caswell > Sent: 21 October 2019 21:26:32 To: Nagalakshmi V J >; openssl-users at openssl.org > Subject: Re: OpenSSL compilation errors in Windows ** This mail has been sent from an external source ** On 20/10/2019 08:43, Nagalakshmi V J wrote: > Hi Matt, > > This link is having few APIS. But for getting master_key_length, I don't > find any API. Not sure if we need to use getMasterKey API for that. You can use SSL_SESSION_get_master_key() for this. Note this comment in the RETURN VALUES section: "For the other functions, if outlen is greater than 0 then these functions return the number of bytes actually copied, which will be less than or equal to outlen. If outlen is 0 then these functions return the maximum number of bytes they would copy -- that is, the length of the underlying field." So to discover the master_key_length call the function with outlen to zero. You can then allocate an appropriate sized buffer and call the function again in order to get the actual master key. Matt > > I will try to use these APIs and get back. > > Thanks & Regards, > Nagalakshmi V J > ------------------------------------------------------------------------ > *From:* Matt Caswell > > *Sent:* 18 October 2019 14:48:33 > *To:* Nagalakshmi V J >; > openssl-users at openssl.org > > *Subject:* Re: OpenSSL compilation errors in Windows > > ** This mail has been sent from an external source ** > > > On 18/10/2019 11:49, Nagalakshmi V J wrote: >> Now the issue is SSL_session structure is also having accessor APIs >> which I am not aware of. So I need to get the APIs for accessing the >> master_key_length,etc.. given in the above code. Those are not listed >> in the openssl link referred. > > On this page look a the various functions beginning with "SSL_SESSION_" > in the name: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.1.1_man3_&d=DwICaQ&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=MZhYFrTAuuHOqAirPiGbT1CY6HDdH2U_CWYq12626Ts&s=gE0JHTVoToRHQRu5h2amvKa5WzyXsortlw0IoQd3VG4&e= > > From the code sample you gave you are probably mostly interested in the > functions on this page: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.1.1_man3_SSL-5FSESSION-5Fget-5Fmaster-5Fkey.html&d=DwICaQ&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=MZhYFrTAuuHOqAirPiGbT1CY6HDdH2U_CWYq12626Ts&s=XTuEzS7qyBvIHc_qWJYoh3JVC4zPCzvUzNPStW_SvLI&e= > > Matt > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From ylavic.dev at gmail.com Tue Oct 22 12:30:37 2019 From: ylavic.dev at gmail.com (Yann Ylavic) Date: Tue, 22 Oct 2019 14:30:37 +0200 Subject: Should SSL_get_servername() depend on SNI callback (no-)ACK? Message-ID: Hi, in master (and 1.1.1), SSL_get_servername() returns either s->session->ext.hostname (when s->hit == 1), or s->ext.hostname (otherwise). It seems, according to final_server_name(), that s->session->ext.hostname is set only: if (sent && ret == SSL_TLSEXT_ERR_OK && (!s->hit || SSL_IS_TLS13(s))) { ... s->session->ext.hostname = OPENSSL_strdup(s->ext.hostname); ... } that is if a SNI callback exists and returns OK (no callback defaulting to NOACK). And it _seems_ that browsers (or Chrome only?) don't set a tlsext_hostname in their session (ASN1) on resumption, so s->session->ext.hostname isn't set by that either. Note that this leaves s->servername_done = 0 in the below code from tls_parse_ctos_server_name(): if (s->hit) { /* * TODO(openssl-team): if the SNI doesn't match, we MUST * fall back to a full handshake. */ s->servername_done = (s->session->ext.hostname != NULL) && PACKET_equal(&hostname, s->session->ext.hostname, strlen(s->session->ext.hostname)); if (!s->servername_done && s->session->ext.hostname != NULL) s->ext.early_data_ok = 0; } So it's possible that, on session resumption (s->hit == 1), SSL_get_servername() returns NULL (unset s->session->ext.hostname) even though an SNI is provided by ClientHello. Shouldn't it return the ClientHello's SNI regardless of the presence/return of the callback? Something like the below (where s->servername_done is also tested)? const char *SSL_get_servername(const SSL *s, const int type) { if (type != TLSEXT_NAMETYPE_host_name) return NULL; /* * SNI is not negotiated in pre-TLS-1.3 resumption flows, so fake up an * SNI value to return if we are resuming/resumed. N.B. that we still * call the relevant callbacks for such resumption flows, and callbacks * might error out if there is not a SNI value available. */ if (s->hit && s->servername_done) return s->session->ext.hostname; return s->ext.hostname; } Regards, Yann. From Tobias.Wolf at t-systems.com Tue Oct 22 13:03:00 2019 From: Tobias.Wolf at t-systems.com (Tobias.Wolf at t-systems.com) Date: Tue, 22 Oct 2019 13:03:00 +0000 Subject: openssl and external card reader support in TLS Message-ID: I need to implement support for the external authentication of a card reader within a TLS handshake. We did this already with PKCS11 using the C_Sign function and it is working fine. Now I need to implement the same functionality in another use case with openssl for TLS handshake. My Question is there a callback I can use or do I need to implement my own ENGINE? I want to avoid implementing the ENGINE interface, because that is a lot of work and maybe over engineered for this scenario, right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From salman.a.baset at gmail.com Tue Oct 22 13:46:51 2019 From: salman.a.baset at gmail.com (Salman Baset) Date: Tue, 22 Oct 2019 09:46:51 -0400 Subject: OpenSSL 1.0.2 EOL and new FIPS-validated crypto module In-Reply-To: <0EDDD039-95A2-4B33-8A3D-434BE0A9EA9B@oracle.com> References: <0EDDD039-95A2-4B33-8A3D-434BE0A9EA9B@oracle.com> Message-ID: Thank you very much. This is helpful. Will the support also include any updates to the FIPS compatible part, or is that out of scope because any update essentially invalidates existing FIPS cert for potential use? On Mon, Oct 21, 2019 at 11:56 AM Dr Paul Dale wrote: > The EOL date for OpenSSL 1.0.2 will not be extended. > > It is possible to purchase premium level support which will provide 1.0.2 > updates beyond its normal end of life. See: > https://www.openssl.org/support/contracts.html#premium > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > > On 21 Oct 2019, at 9:11 pm, Salman Baset wrote: > > Hello everyone, > > I was wondering if there is any update on getting a new FIPS-validated > module for OpenSSL by the end of this year (before EOL of 1.0.2), as was > mentioned in this blog post: > https://www.openssl.org/blog/blog/2018/09/25/fips/ > > According to this email, the new FIPS module is dependent on OpenSSL 3.0, > whose release timing is not certain yet. > https://mta.openssl.org/pipermail/openssl-users/2019-February/009836.html > > I will appreciate if someone can provide an update on the new FIPS > timeline as that will help folks who are looking to depend on OpenSSL's > FIPS-validated modules in the next 6-9 months or so. > > Lastly, is there any chance of extending the EOL date of OpenSSL 1.0.2 > till the new FIPS module/OpenSSL 3.0 becomes available? > > Thanks > Salman > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Tue Oct 22 14:15:44 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Wed, 23 Oct 2019 00:15:44 +1000 Subject: OpenSSL 1.0.2 EOL and new FIPS-validated crypto module In-Reply-To: References: <0EDDD039-95A2-4B33-8A3D-434BE0A9EA9B@oracle.com> Message-ID: <9D14E7A8-26A6-4E53-A2B9-ABC96173073E@oracle.com> The FIPS module source code can?t be changed without losing validation. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 22 Oct 2019, at 11:46 pm, Salman Baset wrote: > > Thank you very much. This is helpful. Will the support also include any updates to the FIPS compatible part, or is that out of scope because any update essentially invalidates existing FIPS cert for potential use? > > > On Mon, Oct 21, 2019 at 11:56 AM Dr Paul Dale > wrote: > The EOL date for OpenSSL 1.0.2 will not be extended. > > It is possible to purchase premium level support which will provide 1.0.2 updates beyond its normal end of life. See: https://www.openssl.org/support/contracts.html#premium > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 21 Oct 2019, at 9:11 pm, Salman Baset > wrote: >> >> Hello everyone, >> >> I was wondering if there is any update on getting a new FIPS-validated module for OpenSSL by the end of this year (before EOL of 1.0.2), as was mentioned in this blog post: >> https://www.openssl.org/blog/blog/2018/09/25/fips/ >> >> According to this email, the new FIPS module is dependent on OpenSSL 3.0, whose release timing is not certain yet. >> https://mta.openssl.org/pipermail/openssl-users/2019-February/009836.html >> >> I will appreciate if someone can provide an update on the new FIPS timeline as that will help folks who are looking to depend on OpenSSL's FIPS-validated modules in the next 6-9 months or so. >> >> Lastly, is there any chance of extending the EOL date of OpenSSL 1.0.2 till the new FIPS module/OpenSSL 3.0 becomes available? >> >> Thanks >> Salman > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Tue Oct 22 15:09:34 2019 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 22 Oct 2019 08:09:34 -0700 Subject: Should SSL_get_servername() depend on SNI callback (no-)ACK? In-Reply-To: References: Message-ID: <20191022150933.GA10092@akamai.com> There's some (additional?) discussion on this topic in https://github.com/openssl/openssl/pull/10018 . A couple comments inline, though... On Tue, Oct 22, 2019 at 02:30:37PM +0200, Yann Ylavic wrote: > Hi, > > in master (and 1.1.1), SSL_get_servername() returns either > s->session->ext.hostname (when s->hit == 1), or s->ext.hostname > (otherwise). > > It seems, according to final_server_name(), that > s->session->ext.hostname is set only: > if (sent && ret == SSL_TLSEXT_ERR_OK && (!s->hit || SSL_IS_TLS13(s))) { > ... > s->session->ext.hostname = OPENSSL_strdup(s->ext.hostname); > ... > } > that is if a SNI callback exists and returns OK (no callback > defaulting to NOACK). > > And it _seems_ that browsers (or Chrome only?) don't set a > tlsext_hostname in their session (ASN1) on resumption, so I don't understand what you mean by "set a tlsext_hostname in their session (ASN1) on resumption". Are you saying that browsers do not send the server_name_indication extension in the ClientHello for resumption handshakes? > s->session->ext.hostname isn't set by that either. Note that this > leaves s->servername_done = 0 in the below code from > tls_parse_ctos_server_name(): > if (s->hit) { > /* > * TODO(openssl-team): if the SNI doesn't match, we MUST > * fall back to a full handshake. > */ > s->servername_done = (s->session->ext.hostname != NULL) > && PACKET_equal(&hostname, s->session->ext.hostname, > strlen(s->session->ext.hostname)); > > if (!s->servername_done && s->session->ext.hostname != NULL) > s->ext.early_data_ok = 0; > } > > So it's possible that, on session resumption (s->hit == 1), > SSL_get_servername() returns NULL (unset s->session->ext.hostname) > even though an SNI is provided by ClientHello. Shouldn't it return the > ClientHello's SNI regardless of the presence/return of the callback? > Something like the below (where s->servername_done is also tested)? There's something of a philosophical debate; some additional (heated) discussion can be found in https://github.com/openssl/openssl/pull/7115 but I think the real cause of problems in this space is that the SSL_get_servername() API contract has been underspecified from the start. Note that the documentation for SSL_get_servername() is in the page for SSL_CTX_set_tlsext_servername_callback() and claims to return the value from the Client Hello (if present). Yet, historically, prior to TLS 1.3 on resumption we did not even look at the ClientHello to see whether the extension was present; we just resumed and thus the "Client Hello" in the above would be the *initial* ClientHello. This was perhaps tolerable if the servername callback was never called, if you assume that the API would only be called from that callback, but that assumption is no longer anywhere close to true. -Ben > const char *SSL_get_servername(const SSL *s, const int type) > { > if (type != TLSEXT_NAMETYPE_host_name) > return NULL; > > /* > * SNI is not negotiated in pre-TLS-1.3 resumption flows, so fake up an > * SNI value to return if we are resuming/resumed. N.B. that we still > * call the relevant callbacks for such resumption flows, and callbacks > * might error out if there is not a SNI value available. > */ > if (s->hit && s->servername_done) > return s->session->ext.hostname; > return s->ext.hostname; > } > > > Regards, > Yann. From Michael.Wojcik at microfocus.com Tue Oct 22 15:00:15 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 22 Oct 2019 15:00:15 +0000 Subject: openssl and external card reader support in TLS In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Tobias.Wolf at t-systems.com > Sent: Tuesday, October 22, 2019 07:03 > I need to implement support for the external authentication of a card reader within a > TLS handshake. We did this already with PKCS11 using the C_Sign function and it is > working fine. > Now I need to implement the same functionality in another use case with openssl for > TLS handshake. > My Question is there a callback I can use or do I need to implement my own ENGINE? OpenSSL includes a PKCS#11 engine. I've used it in the past to interact with some HSMs for cryptographic operations such as code signing. While some research and additional software may be required to get all the PKCS#11 ducks in a row, it sounds like you've already successfully used PKCS#11 with your device, so I'd expect using it with OpenSSL will be fairly straightforward. You can find examples of using the openssl command-line utility with the PKCS#11 engine online. That's a good way to get started; it will let you confirm what settings and commands you need. -- Michael Wojcik Distinguished Engineer, Micro Focus From ylavic.dev at gmail.com Tue Oct 22 16:09:02 2019 From: ylavic.dev at gmail.com (Yann Ylavic) Date: Tue, 22 Oct 2019 18:09:02 +0200 Subject: Should SSL_get_servername() depend on SNI callback (no-)ACK? In-Reply-To: <20191022150933.GA10092@akamai.com> References: <20191022150933.GA10092@akamai.com> Message-ID: On Tue, Oct 22, 2019 at 5:09 PM Benjamin Kaduk wrote: > > There's some (additional?) discussion on this topic in > https://github.com/openssl/openssl/pull/10018 . A couple comments inline, though... Thanks, will look at it. More comment below too... > On Tue, Oct 22, 2019 at 02:30:37PM +0200, Yann Ylavic wrote: > > > > And it _seems_ that browsers (or Chrome only?) don't set a > > tlsext_hostname in their session (ASN1) on resumption, so > > I don't understand what you mean by "set a tlsext_hostname in their session (ASN1) > on resumption". Are you saying that browsers do not send the server_name_indication > extension in the ClientHello for resumption handshakes? Sorry for the shortcut, by "tlsext_hostname" I meant the name of the field in SSL_SESSION_ASN1. My observation is that when browsers resume a session, s->hit is set but s->session->ext.hostname is NULL, which I interpret as no SNI found in the SSL_SESSION (and thus no SNI encoded in the session ticket, presumably). On the other hand, the SNI is always in ClientHello (though there is no way to match it against the session's). > > Note that the documentation for SSL_get_servername() is in > the page for SSL_CTX_set_tlsext_servername_callback() and claims to > return the value from the Client Hello (if present). Yet, historically, > prior to TLS 1.3 on resumption we did not even look at the ClientHello > to see whether the extension was present; we just resumed and thus the > "Client Hello" in the above would be the *initial* ClientHello. This requires that the initial SNI be encoded in the session (ticket), does this changed with TLS 1.3 somehow? > This > was perhaps tolerable if the servername callback was never called, if > you assume that the API would only be called from that callback, but > that assumption is no longer anywhere close to true. Yes, I found this "issue" by trying to modify Apache httpd, which was previously using the SNI callback to select the right TLS configuration (per virtual host), to now do that in the new ClientHello callback (which allows for setting the configured TLS protocol version too, whereas the SNI callback is too late for that). When doing this, I naively first removed the SNI callback completely, and discovered that further call to SSL_get_hostname() was returning NULL, for some cases (resumption)... Regards, Yann. From stephen.farrell at cs.tcd.ie Tue Oct 22 17:39:59 2019 From: stephen.farrell at cs.tcd.ie (Stephen Farrell) Date: Tue, 22 Oct 2019 18:39:59 +0100 Subject: Should SSL_get_servername() depend on SNI callback (no-)ACK? In-Reply-To: References: <20191022150933.GA10092@akamai.com> Message-ID: <80c0b42f-017b-d547-b8cd-150ad8fbf735@cs.tcd.ie> Hiya, On 22/10/2019 17:09, Yann Ylavic wrote: > Sorry for the shortcut, by "tlsext_hostname" I meant the name of the > field in SSL_SESSION_ASN1. > My observation is that when browsers resume a session, s->hit is set > but s->session->ext.hostname is NULL, which I interpret as no SNI > found in the SSL_SESSION (and thus no SNI encoded in the session > ticket, presumably). > On the other hand, the SNI is always in ClientHello (though there is > no way to match it against the session's). FWIW, I also had to play about a bit with that to get ESNI working with tickets. I can chase down the bits of code for that in my fork [1] if it's useful. Cheers, S. [1] https://github.com/sftcd/openssl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x5AB2FAF17B172BEA.asc Type: application/pgp-keys Size: 10715 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From hammond at txcorp.com Tue Oct 22 22:56:49 2019 From: hammond at txcorp.com (Anne M. Hammond) Date: Tue, 22 Oct 2019 16:56:49 -0600 Subject: openssl 1.0.2 with TLS 1.2 Message-ID: I built openssl 1.0.2 from the tar.gz file. I am trying to verify a connection, but TLS does not find the ca-bundle.crt unless it is on the command line: /usr/local/openssl/bin/openssl s_client -showcerts -connect mta3.edu:25 -starttls smtp New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: 653E180E0E46DB0E2B268F2FB7AB583B66F31269AD7F073FF23531C14A7DAE66 Session-ID-ctx: Master-Key: 7D54E27BFBAC1422F3C23055359E222DE1865A71F8DD7CF0B9FAAE2CEBA8D3EE17AA27A183206B814EDA0016EA699020 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1571773604 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) /usr/local/openssl/bin/openssl s_client -showcerts -CAfile /usr/local/openssl/ssl/certs/ca-bundle.crt -connect mta3.edu:25 -starttls smtp New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: 68EB6663064D12857FFFB061F29BF4DFB081A8322A30AF292E8CC88CEE5F7B47 Session-ID-ctx: Master-Key: 5FF67384CB91433D39ACA430E4AD447A3C854B865A8E71FB46AAD79C5CCFB56B2FB57AFED08FA73227BCFBFDE0633C85 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1571773646 Timeout : 300 (sec) Verify return code: 0 (ok) ?Why does faile with a certificate verify error?? faq says: this typically means that the CA certificate must be placed in a directory or file and the relevant program configured to read it. I can?t find documentation on how to tell TLS where to look. I?ve tried placing ca-bundle.crt in /usr/local/openssl/ssl/certs/ /etc/pki/tls/certs Any pointers appreciated. Anne -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Oct 22 23:41:36 2019 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 22 Oct 2019 23:41:36 +0000 Subject: openssl 1.0.2 with TLS 1.2 In-Reply-To: References: Message-ID: <8F0A5A7D-E801-40C2-9EEB-20946045FEB0@akamai.com> * I can?t find documentation on how to tell TLS where to look. Not sure about 1.0.2, but ?openssl version -a? should show you the CERT directory. BTW, that?s an old release, you should upgrade if possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tobias.Wolf at t-systems.com Wed Oct 23 08:11:12 2019 From: Tobias.Wolf at t-systems.com (Tobias.Wolf at t-systems.com) Date: Wed, 23 Oct 2019 08:11:12 +0000 Subject: AW: openssl and external card reader support in TLS In-Reply-To: References: Message-ID: Our PKCS11 module development will discontinue and therefore I can`t use it anymore, but the idea is great and very interesting. To give more details we need a callback or similar mechanism to replace the signature created in Certificate TLS message with our signature coming from the card reader. TLS handshake ...... S: Certificate Request C: Certificate Verify --> here we want to hook in "Signature" and replace the value! ..... We tried already with the client callback int (*client_cert_cb)(SSL *ssl, X509 **x509, EVP_PKEY **pkey)); But there it is mandatory to give in the private key which we don`t have, because that part is done by the card reader machine. I think the caller of the callback is doing later on a rsa sign processing with the private key and there I want to hook in! Tobias Wolf, T-Systems -----Urspr?ngliche Nachricht----- Von: openssl-users Im Auftrag von Michael Wojcik Gesendet: Dienstag, 22. Oktober 2019 17:00 An: openssl-users at openssl.org Betreff: RE: openssl and external card reader support in TLS > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Tobias.Wolf at t-systems.com > Sent: Tuesday, October 22, 2019 07:03 > I need to implement support for the external authentication of a card > reader within a TLS handshake. We did this already with PKCS11 using > the C_Sign function and it is working fine. > Now I need to implement the same functionality in another use case > with openssl for TLS handshake. > My Question is there a callback I can use or do I need to implement my own ENGINE? OpenSSL includes a PKCS#11 engine. I've used it in the past to interact with some HSMs for cryptographic operations such as code signing. While some research and additional software may be required to get all the PKCS#11 ducks in a row, it sounds like you've already successfully used PKCS#11 with your device, so I'd expect using it with OpenSSL will be fairly straightforward. You can find examples of using the openssl command-line utility with the PKCS#11 engine online. That's a good way to get started; it will let you confirm what settings and commands you need. -- Michael Wojcik Distinguished Engineer, Micro Focus From dfnsonfsduifb at gmx.de Wed Oct 23 09:24:49 2019 From: dfnsonfsduifb at gmx.de (Johannes Bauer) Date: Wed, 23 Oct 2019 11:24:49 +0200 Subject: PSK with TLSv1.3 Message-ID: <99a83036-5382-2de3-afb3-680204c55acd@gmx.de> Hi list, I'm in the process of refactoring/updating code that has been using TLS-PSK with TLSv1.2 for a number of years successfully. I want to upgrade it so that it uses TLSv1.3 exclusively. I find it *exceptionally* hard to wrap my head around the new API and the documentation/manpages are extremely confusing to me. E.g., while https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_psk_use_session_callback.html mentions specifically TLSv1.3 clients, there's no mention of server implementation and the text does not seem to have been updated for TLSv1.3 entirely (e.g., there's mention of "the callback" -- clearly previously there was only one, now there's two, SSL_psk_use_session_cb_func and SSL_psk_client_cb_func). I'm struggling with all of it, in particular the way the server callback works in TLSv1.3: What I'm doing now is register a static int psk_server_callback(SSL *ssl, const unsigned char *identity, size_t identity_len, SSL_SESSION **sessptr); using SSL_CTX_set_psk_find_session_callback(cctx, psk_server_callback); Then, inside the callback I create a SSL_SESSION* in the callback (if I want to return a PSK) using SSL_SESSION_new(). Setting the master key (that's the PSK, right?) using SSL_SESSION_set1_master_key and the protocol version using SSL_SESSION_set_protocol_version is straightforward. But what the heck am I supposed to do with SSL_SESSION_set_cipher? The text in https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_psk_find_session_callback.html does not contain any hint on what to do in the server case and the text provided in the client manpage is exceedingly confusing: "Only the handshake digest associated with the ciphersuite is relevant for the PSK (the server may go on to negotiate any ciphersuite which is compatible with the digest). The application can use any TLSv1.3 ciphersuite." So, wait, I can use any TLSv1.3 ciphersuite but it's not relevant because only the MD of the suite is used, everything else is discarded? So I return a cipher suite value, but it doesn't have to do anything with the cipher suites that I allow, it's just a "wrapper" for a MD? Here's what I'm doing right now in my server callback: static int psk_server_callback(SSL *ssl, const unsigned char *identity, size_t identity_len, SSL_SESSION **sessptr) { fprintf(stderr, "PSK server SSL %p identity %s len %ld sess %p\n", ssl, identity, identity_len, *sessptr); SSL_SESSION *sess = SSL_SESSION_new(); SSL_SESSION_set1_master_key(sess, (const unsigned char*)"\x00\x11\x22", 3); SSL_SESSION_set_cipher(sess, SSL_get_pending_cipher(ssl)); SSL_SESSION_set_protocol_version(sess, TLS1_3_VERSION); *sessptr = sess; return 1; } All error checking omitted for now, this is obviously just a sample. When I try to connect to my server on the command line using s_client: $ openssl s_client -connect 127.0.0.1:12345 -psk_identity foo -psk 001122 The server pukes: PSK server SSL 0x623000000100 identity foo len 3 sess (nil) 139933268309760:error:141F906E:SSL routines:tls_parse_ctos_psk:bad extension:../ssl/statem/extensions_srvr.c:1267: And I have no idea what that's supposed to mean. I'm willing to update the documentation/manpage and create a PR, but I don't understand it as-it right now. So any help getting me up to speed would be greatly appreciated. Examples would be also extremely useful for this. All the best, Johannes From dfnsonfsduifb at gmx.de Wed Oct 23 11:32:19 2019 From: dfnsonfsduifb at gmx.de (Johannes Bauer) Date: Wed, 23 Oct 2019 13:32:19 +0200 Subject: PSK with TLSv1.3 In-Reply-To: <99a83036-5382-2de3-afb3-680204c55acd@gmx.de> References: <99a83036-5382-2de3-afb3-680204c55acd@gmx.de> Message-ID: <5d66065a-ec43-4333-f192-95a086e4b734@gmx.de> On 23.10.19 11:24, Johannes Bauer wrote: > All error checking omitted for now, this is obviously just a sample. > When I try to connect to my server on the command line using s_client: > > $ openssl s_client -connect 127.0.0.1:12345 -psk_identity foo -psk 001122 > > The server pukes: > > PSK server SSL 0x623000000100 identity foo len 3 sess (nil) > 139933268309760:error:141F906E:SSL routines:tls_parse_ctos_psk:bad > extension:../ssl/statem/extensions_srvr.c:1267: > > And I have no idea what that's supposed to mean. One step further... I've peeked at s_server.c and copied some of that code. I.e., concretely I now am at: const unsigned char tls13_aes128gcmsha256_id[] = { 0x13, 0x01 }; const SSL_CIPHER *cipher = SSL_CIPHER_find(ssl, tls13_aes128gcmsha256_id); if (!cipher) { return 0; } SSL_SESSION_set_cipher(sess, cipher); But, uhm... this is positively terrifying code. Is this how it's supposed to look, i.e., hard-coded magic numbers in the application?! Or is that just the route s_server took and there's a preferred, better way? In any case, while it throws a different error message now, it still does not work: PSK server SSL 0x62300000fd00 identity foo len 3 sess (nil) 140710464452352:error:14201076:SSL routines:tls_choose_sigalg:no suitable signature algorithm:../ssl/t1_lib.c:2649: I've never in the setup limited the signature algorithms and s_client does not, either (when I peek at the ClientHello it advertises a whole bunch of signature algorithms). Any advice? Thank you, Johannes From dfnsonfsduifb at gmx.de Wed Oct 23 12:59:25 2019 From: dfnsonfsduifb at gmx.de (Johannes Bauer) Date: Wed, 23 Oct 2019 14:59:25 +0200 Subject: Preferred way of passing user context void* inside SSL* Message-ID: <084d778c-2cdc-1169-e42b-a31f92a6670b@gmx.de> Hi list, yet another question. In my process with TLS13-PSK, I've noticed that the PSK callback does not have a user-definable callback context value. However, the callback is passed the SSL* which I created when the session was established. Is there a way for me to piggyback a void* inside the SSL structure so that I can access it from within the callback? I've noticed a couple of member variables that might be abused for this purpose (async_cb_arg, allow_early_data_cb_data, default_passwd_callback_userdata, msg_callback_arg) and think in my usecase they hopefully should all be safe to use (I don't use async I/O, no early data, no SRP, no msg callback) -- but is this the preferred way to do it? I.e., hijack a different callback argument that isn't used? Am I overlooking the supposed way of doing this? Or is this typically done via global variables (which in my case I *really* would want to avoid)? Cheers, Johannes From rsalz at akamai.com Wed Oct 23 13:21:54 2019 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 23 Oct 2019 13:21:54 +0000 Subject: Preferred way of passing user context void* inside SSL* In-Reply-To: <084d778c-2cdc-1169-e42b-a31f92a6670b@gmx.de> References: <084d778c-2cdc-1169-e42b-a31f92a6670b@gmx.de> Message-ID: > Is there a way for me to piggyback a void* inside the SSL structure so that I can access it from within the callback? Yes, you can use SSL_set_app_data and SSL_get_app_data which are documented in https://github.com/openssl/openssl/pull/10216 (and due to be merged to master soon) From dfnsonfsduifb at gmx.de Wed Oct 23 13:40:09 2019 From: dfnsonfsduifb at gmx.de (Johannes Bauer) Date: Wed, 23 Oct 2019 15:40:09 +0200 Subject: Preferred way of passing user context void* inside SSL* In-Reply-To: References: <084d778c-2cdc-1169-e42b-a31f92a6670b@gmx.de> Message-ID: On 23.10.19 15:21, Salz, Rich wrote: >> Is there a way for me to piggyback a void* inside the SSL structure so > that I can access it from within the callback? > > Yes, you can use SSL_set_app_data and SSL_get_app_data which are documented in https://github.com/openssl/openssl/pull/10216 (and due to be merged to master soon) Ah, completely overlooked that! Thanks, Rich, this scratches *exactly* my itch. All the best, Joe From bruce.r.stephens at gmail.com Wed Oct 23 14:07:59 2019 From: bruce.r.stephens at gmail.com (Bruce Stephens) Date: Wed, 23 Oct 2019 15:07:59 +0100 Subject: Using X509_verify_cert with (possibly) OCSP? Message-ID: Suppose I want to verify a certificate, and I've collected some CRLs and some OCSP responses. How can I do that? If I just want to verify revocation for the end certificate (so X509_V_FLAG_CRL_CHECK rather than X509_V_FLAG_CRL_CHECK_ALL) then that's straightforward: I use X509_verify_cert without those settings and then do the OCSP check for the end certificate. But how can I check the whole chain, using some mixture of CRLs and OCSP? It looks like I can use verify_cb and perform my own checks when the error is X509_V_ERR_UNABLE_TO_GET_CRL. I think really what I'd want is to have some more low-level callback used in check_cert or check_revocation, but I don't see one. In 1.0.2 I'm just changing check_revocation (since ) but in order to keep the usual CRL checking that involved basically copying check_cert and a bunch of related functions with small changes to one or two of them (because they're mostly static so I can't just call them). In OpenSSL-1.1 that doesn't look so attractive (and it's not terribly pretty with 1.0.2) because the code accesses things in X509 and X509_CRL that aren't accessible. Am I missing something obvious? Does the TLS code do this in some way? (It doesn't look like it does, but possibly I'm just missing it.) From Michael.Wojcik at microfocus.com Wed Oct 23 14:51:29 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 23 Oct 2019 14:51:29 +0000 Subject: openssl and external card reader support in TLS In-Reply-To: References: Message-ID: > From: Tobias.Wolf at t-systems.com [mailto:Tobias.Wolf at t-systems.com] > Sent: Wednesday, October 23, 2019 02:11 > > Our PKCS11 module development will discontinue and therefore I can`t use it > anymore, but the idea is great and very interesting. > To give more details we need a callback or similar mechanism to replace the > signature created in Certificate TLS message with our signature coming from > the card reader. For OpenSSL 1, the Engine mechanism is the way to do this. If you're discontinuing your PKCS#11 interface, then I think the only option is to write a custom engine. For OpenSSL 3, I understand there's a new Provider mechanism for this purpose, but I haven't investigated it. -- Michael Wojcik Distinguished Engineer, Micro Focus From openssl-users at dukhovni.org Wed Oct 23 15:57:55 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 23 Oct 2019 11:57:55 -0400 Subject: Preferred way of passing user context void* inside SSL* In-Reply-To: References: <084d778c-2cdc-1169-e42b-a31f92a6670b@gmx.de> Message-ID: <20191023155755.GX34850@straasha.imrryr.org> On Wed, Oct 23, 2019 at 01:21:54PM +0000, Salz, Rich via openssl-users wrote: > > Is there a way for me to piggyback a void* inside the SSL structure so > that I can access it from within the callback? > > Yes, you can use SSL_set_app_data and SSL_get_app_data which are documented > in https://github.com/openssl/openssl/pull/10216 (and due to be merged to > master soon) If the data is needed by a *library* and not "the application", then it is not appropriate to use index 0, which is reserved for "the application". In that case, the library needs to register its own "ex data index". Examples can be seen at: 1-time init: https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L353 Setter usage: https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L977 Getter usage: https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L255 -- Viktor. From matt at openssl.org Wed Oct 23 18:52:54 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 23 Oct 2019 19:52:54 +0100 Subject: PSK with TLSv1.3 In-Reply-To: <99a83036-5382-2de3-afb3-680204c55acd@gmx.de> References: <99a83036-5382-2de3-afb3-680204c55acd@gmx.de> Message-ID: <64376803-73f5-6dd5-303b-1ad3cdd0555d@openssl.org> On 23/10/2019 10:24, Johannes Bauer wrote: > Hi list, > > I'm in the process of refactoring/updating code that has been using > TLS-PSK with TLSv1.2 for a number of years successfully. I want to > upgrade it so that it uses TLSv1.3 exclusively. > > I find it *exceptionally* hard to wrap my head around the new API and > the documentation/manpages are extremely confusing to me. I'd be grateful if you could submit suggested improvements as PRs to make this clearer for the next person who comes along trying to do this. > > E.g., while > https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_psk_use_session_callback.html > mentions specifically TLSv1.3 clients, there's no mention of server > implementation The page you referenced is the man page for clients. The man page for servers is here: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_psk_find_session_callback.html Unfortunately this page is not made any clearer by a copy & paste error in the opening paragraph which suggests it is about the client side API calls rather than the server side one. I've just opened a PR to fix that here: https://github.com/openssl/openssl/pull/10245 > and the text does not seem to have been updated for > TLSv1.3 entirely (e.g., there's mention of "the callback" -- clearly > previously there was only one, now there's two, > SSL_psk_use_session_cb_func and SSL_psk_client_cb_func). > > I'm struggling with all of it, in particular the way the server callback > works in TLSv1.3: What I'm doing now is register a > > static int psk_server_callback(SSL *ssl, const unsigned char *identity, > size_t identity_len, SSL_SESSION **sessptr); > > using > > SSL_CTX_set_psk_find_session_callback(cctx, psk_server_callback); > > Then, inside the callback I create a SSL_SESSION* in the callback (if I > want to return a PSK) using SSL_SESSION_new(). Setting the master key > (that's the PSK, right?) using SSL_SESSION_set1_master_key and the > protocol version using SSL_SESSION_set_protocol_version is straightforward. > > But what the heck am I supposed to do with SSL_SESSION_set_cipher? The > text in > https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_psk_find_session_callback.html > does not contain any hint on what to do in the server case and the text > provided in the client manpage is exceedingly confusing: > > "Only the handshake digest associated with the ciphersuite is relevant > for the PSK (the server may go on to negotiate any ciphersuite which is > compatible with the digest). The application can use any TLSv1.3 > ciphersuite." > > So, wait, I can use any TLSv1.3 ciphersuite but it's not relevant > because only the MD of the suite is used, everything else is discarded? > So I return a cipher suite value, but it doesn't have to do anything > with the cipher suites that I allow, it's just a "wrapper" for a MD? Yes, exactly that. This comes about because of some quirks in the TLSv1.3 spec. Historically (TLSv1.2 and below) the ciphersuite that is negotiated is an important part of the session (SSL_SESSION object) and the same ciphersuite is used in any subsequent resumption of that session. In TLSv1.3 there is no difference between a PSK and a session. The mechanism used for establishing a connection using a PSK is exactly the same one used for resuming a session. So when we establish an initial connection in TLSv1.3 we store away various values in the session in exactly the same way that we do for TLSv1.2, and then use some of them in the resumption. In the case of the ciphersuite its actually only the MD part that we're interested in. With a PSK of course there was no "initial handshake", so there was no previous ciphersuite negotiated. However, since the mechanism is the same as for a resumption we still need to have one there so we can get the MD out of it - which leads to this slightly surprising way of doing things. > > Here's what I'm doing right now in my server callback: > > static int psk_server_callback(SSL *ssl, const unsigned char *identity, > size_t identity_len, SSL_SESSION **sessptr) { > fprintf(stderr, "PSK server SSL %p identity %s len %ld sess %p\n", ssl, > identity, identity_len, *sessptr); > SSL_SESSION *sess = SSL_SESSION_new(); > SSL_SESSION_set1_master_key(sess, (const unsigned char*)"\x00\x11\x22", 3); > SSL_SESSION_set_cipher(sess, SSL_get_pending_cipher(ssl)); > SSL_SESSION_set_protocol_version(sess, TLS1_3_VERSION); > *sessptr = sess; > return 1; > } > > All error checking omitted for now, this is obviously just a sample. > When I try to connect to my server on the command line using s_client: > > $ openssl s_client -connect 127.0.0.1:12345 -psk_identity foo -psk 001122 > > The server pukes: > > PSK server SSL 0x623000000100 identity foo len 3 sess (nil) > 139933268309760:error:141F906E:SSL routines:tls_parse_ctos_psk:bad > extension:../ssl/statem/extensions_srvr.c:1267: That error is coming from this sanity check: if (PACKET_remaining(&binder) != hashsize) { SSLfatal(s, SSL_AD_DECODE_ERROR, SSL_F_TLS_PARSE_CTOS_PSK, SSL_R_BAD_EXTENSION); goto err; } We could do with updating the error code to be something more helpful (PRs welcome!). "Bad extension" doesn't really tell you anything. The problem is that the callback has found the SESSION object for the presented identity but the hash size used by the client doesn't match the hash size associated with the ciphersuite in the SESSION object. Matt From matt at openssl.org Wed Oct 23 19:09:55 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 23 Oct 2019 20:09:55 +0100 Subject: PSK with TLSv1.3 In-Reply-To: <5d66065a-ec43-4333-f192-95a086e4b734@gmx.de> References: <99a83036-5382-2de3-afb3-680204c55acd@gmx.de> <5d66065a-ec43-4333-f192-95a086e4b734@gmx.de> Message-ID: On 23/10/2019 12:32, Johannes Bauer wrote: > One step further... I've peeked at s_server.c and copied some of that > code. I.e., concretely I now am at: > > const unsigned char tls13_aes128gcmsha256_id[] = { 0x13, 0x01 }; > const SSL_CIPHER *cipher = SSL_CIPHER_find(ssl, tls13_aes128gcmsha256_id); > if (!cipher) { > return 0; > } > SSL_SESSION_set_cipher(sess, cipher); > > But, uhm... this is positively terrifying code. Is this how it's > supposed to look, i.e., hard-coded magic numbers in the application?! Or > is that just the route s_server took and there's a preferred, better way? Unfortunately the only way we have for getting hold of a single SSL_CIPHER object is to use the SSL_CIPHER_find() function. You can also get the list of ciphers configured for a particular SSL object or SSL_CTX....but you that's an even worse way of getting hold of a single SSL_CIPHER. It would be nice to have a function to get hold of an SSL_CIPHER based on its name and a function to get hold of one based on its id as defined in the tls1.h, e.g. TLS1_3_CK_AES_256_GCM_SHA384 - but at the moment such a function doesn't exist. > > In any case, while it throws a different error message now, it still > does not work: > > PSK server SSL 0x62300000fd00 identity foo len 3 sess (nil) > 140710464452352:error:14201076:SSL routines:tls_choose_sigalg:no > suitable signature algorithm:../ssl/t1_lib.c:2649: > > I've never in the setup limited the signature algorithms and s_client > does not, either (when I peek at the ClientHello it advertises a whole > bunch of signature algorithms). Since you're using PSKs I'm guessing you haven't set up a certificate. If no suitable PSK has been found then OpenSSL will press ahead and attempt to do an "initial" handshake with a certificate. It gets so far and attempts to find a signature algorithm to use that is in the list of signature algorithms presented by the client, as well as in the list of signature algorithms configured for the server, and *also* is suitable for use with one of the certificates configured for use by the server. If there are no certificates configured then there is no signature algorithm that can match these criteria, and you will get this error message. Matt From hammond at txcorp.com Wed Oct 23 23:27:06 2019 From: hammond at txcorp.com (Anne M. Hammond) Date: Wed, 23 Oct 2019 17:27:06 -0600 Subject: openssl 1.0.2 with TLS 1.2 In-Reply-To: <8F0A5A7D-E801-40C2-9EEB-20946045FEB0@akamai.com> References: <8F0A5A7D-E801-40C2-9EEB-20946045FEB0@akamai.com> Message-ID: Thanks Rich. openssl version -a ? OPENSSLDIR: "/usr/local/openssl-1.0.2a/ssl" ????? That tells me the dir openssl is looking in. ls /usr/local/openssl-1.0.2a/ssl total 36 drwxr-xr-x 6 root root 4096 2019-10-23 16:34 . drwxr-xr-x 7 root root 4096 2019-10-22 12:27 .. drwxr-xr-x 2 root root 4096 2019-10-22 13:23 certs drwxr-xr-x 6 root root 4096 2019-10-21 16:01 man drwxr-xr-x 2 root root 4096 2019-10-21 16:02 misc -rw-r--r-- 1 root root 10835 2019-10-21 16:02 openssl.cnf drwx------ 2 root root 4096 2019-10-21 16:29 private ca-bundle.crt IS in certs. On another system, where openssl s_client works, there is a link: lrwxrwxrwx 1 root root 19 May 10 2015 cert.pem -> certs/ca-bundle.crt I created this link in /usr/local/openssl-1.0.2a/ssl and now openssl s_client works on the system I am working on. I will update to the newer version. Thank you for the pointer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nagalakshmi.j at altran.com Thu Oct 24 03:29:27 2019 From: nagalakshmi.j at altran.com (Nagalakshmi V J) Date: Thu, 24 Oct 2019 03:29:27 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: <2b8035491b1d40668758b78936fab706@Ex13.ncp.local> <2739d542-13a2-4778-47fd-c45b45492f37@openssl.org> , , Message-ID: Hi Matt, Kindly provide your inputs for the below mail. Thanks & Regards, Nagalakshmi V J ________________________________ From: Nagalakshmi V J Sent: 22 October 2019 10:41:40 To: Matt Caswell ; openssl-users at openssl.org Cc: Nagalakshmi V J Subject: RE: OpenSSL compilation errors in Windows Hi Matt, Could you please help to get any clue on the ACCESSOR APIs of the following. I tried searching APIs. Not getting exact matches. Referred the below links. https://www.openssl.org/docs/man1.1.1/man3/SSL_set_info_callback.html https://www.openssl.org/docs/man1.1.1/man3/EVP_md5.html Getting similar error for the below code. tls1_PRF(s->ctx->md5,s->ctx->sha1,buf,(int)(p-buf), pGenerator->master_secret,sizeof(pGenerator->master_secret), km,tmp,num); Struct ssl_ctx_st { ? const EVP_MD *md5; /* For SSLv3/TLSv1 'ssl3-md5' */ const EVP_MD *sha1; /* For SSLv3/TLSv1 'ssl3->sha1' */ ? } struct evp_md_st { int type; int pkey_type; int md_size; unsigned long flags; int (*init) (EVP_MD_CTX *ctx); int (*update) (EVP_MD_CTX *ctx, const void *data, size_t count); int (*final) (EVP_MD_CTX *ctx, unsigned char *md); int (*copy) (EVP_MD_CTX *to, const EVP_MD_CTX *from); int (*cleanup) (EVP_MD_CTX *ctx); int block_size; int ctx_size; /* how big does the ctx->md_data need to be */ /* control function */ int (*md_ctrl) (EVP_MD_CTX *ctx, int cmd, int p1, void *p2); } /* EVP_MD */ ; Thanks and regards, Nagalakshmi From: Nagalakshmi V J Sent: Tuesday, October 22, 2019 9:39 AM To: Matt Caswell ; Nagalakshmi V J ; openssl-users at openssl.org Subject: Re: OpenSSL compilation errors in Windows Hi Matt, Yes. Exactly we followed the same and able to resolve errors. Thank you so much for the support and guidance. I'll get back if any further errors. Thanks & Regards, Nagalakshmi V J ________________________________ From: Matt Caswell > Sent: 21 October 2019 21:26:32 To: Nagalakshmi V J >; openssl-users at openssl.org > Subject: Re: OpenSSL compilation errors in Windows ** This mail has been sent from an external source ** On 20/10/2019 08:43, Nagalakshmi V J wrote: > Hi Matt, > > This link is having few APIS. But for getting master_key_length, I don't > find any API. Not sure if we need to use getMasterKey API for that. You can use SSL_SESSION_get_master_key() for this. Note this comment in the RETURN VALUES section: "For the other functions, if outlen is greater than 0 then these functions return the number of bytes actually copied, which will be less than or equal to outlen. If outlen is 0 then these functions return the maximum number of bytes they would copy -- that is, the length of the underlying field." So to discover the master_key_length call the function with outlen to zero. You can then allocate an appropriate sized buffer and call the function again in order to get the actual master key. Matt > > I will try to use these APIs and get back. > > Thanks & Regards, > Nagalakshmi V J > ------------------------------------------------------------------------ > *From:* Matt Caswell > > *Sent:* 18 October 2019 14:48:33 > *To:* Nagalakshmi V J >; > openssl-users at openssl.org > > *Subject:* Re: OpenSSL compilation errors in Windows > > ** This mail has been sent from an external source ** > > > On 18/10/2019 11:49, Nagalakshmi V J wrote: >> Now the issue is SSL_session structure is also having accessor APIs >> which I am not aware of. So I need to get the APIs for accessing the >> master_key_length,etc.. given in the above code. Those are not listed >> in the openssl link referred. > > On this page look a the various functions beginning with "SSL_SESSION_" > in the name: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.1.1_man3_&d=DwICaQ&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=MZhYFrTAuuHOqAirPiGbT1CY6HDdH2U_CWYq12626Ts&s=gE0JHTVoToRHQRu5h2amvKa5WzyXsortlw0IoQd3VG4&e= > > From the code sample you gave you are probably mostly interested in the > functions on this page: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.1.1_man3_SSL-5FSESSION-5Fget-5Fmaster-5Fkey.html&d=DwICaQ&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=MZhYFrTAuuHOqAirPiGbT1CY6HDdH2U_CWYq12626Ts&s=XTuEzS7qyBvIHc_qWJYoh3JVC4zPCzvUzNPStW_SvLI&e= > > Matt > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From Fen.Fox at Microfocus.com Thu Oct 24 17:55:13 2019 From: Fen.Fox at Microfocus.com (Fen Fox) Date: Thu, 24 Oct 2019 17:55:13 +0000 Subject: Retrieve CA for client cert from SSL* In-Reply-To: References: Message-ID: Is there a way to figure out which CA the server used to validate the client certificate? -Fen http://pronouns.is/fae/faer -------------- next part -------------- An HTML attachment was scrubbed... URL: From shivakumar2696 at gmail.com Thu Oct 24 18:41:28 2019 From: shivakumar2696 at gmail.com (shiva kumar) Date: Fri, 25 Oct 2019 00:11:28 +0530 Subject: use of makedepend in openssl 1.1.1 Message-ID: what is the use of makedepend in openssl 1.1.1? openssl 1.1.1 can build without makepend then what's the use of makedepend? is it good to use makedepend while building openssl 1.1.1? please answer me thanks in advance -- *With Best Regards* *Shivakumar S* -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu Oct 24 19:56:14 2019 From: levitte at openssl.org (Richard Levitte) Date: Thu, 24 Oct 2019 21:56:14 +0200 Subject: use of makedepend in openssl 1.1.1 In-Reply-To: References: Message-ID: <10F5104D-4605-41EB-A350-26D53CF25938@openssl.org> For C compilers that can't generate makefile dependency files, we have makedepend as a fallback. Cheers Richard shiva kumar skrev: (24 oktober 2019 20:41:28 CEST) >what is the use of makedepend in openssl 1.1.1? >openssl 1.1.1 can build without makepend then what's the use of >makedepend? >is it good to use makedepend while building openssl 1.1.1? >please answer me >thanks in advance -- Richard by mobile From luca.dimauro at cnit.it Thu Oct 24 21:00:08 2019 From: luca.dimauro at cnit.it (Luca Di Mauro) Date: Thu, 24 Oct 2019 21:00:08 +0000 Subject: Compute EC_KEY starting from X or Y coordinate only In-Reply-To: <20191018095627.Horde.MZt6vFx0ov5Nc8zyVlGlyw4@webmail.cnit.it> References: <20191018082250.Horde.X2EVDG4j6ZO3jOF3bhcPJA1@webmail.cnit.it> <20191018095627.Horde.MZt6vFx0ov5Nc8zyVlGlyw4@webmail.cnit.it> Message-ID: <20191024210008.Horde.qhbPlR8c3H8Kvz5A_UqqAA1@webmail.cnit.it> Hi, the link you posted below are very useful! However, after many trials and errors, I created a little program to derive a public key from an x-only coordinate but, in the last step, it fails, namely in the function 'EC_POINT_set_compressed_coordinates_GFp' called in the function 'loadKey_xOnly'. Here the whole code: #include #include #include #include #include #include #include char *ossl_err_as_string (void) { BIO *bio = BIO_new (BIO_s_mem ()); ERR_print_errors (bio); char *buf = NULL; size_t len = BIO_get_mem_data (bio, &buf); char *ret = (char *) calloc (1, 1 + len); if (ret) memcpy (ret, buf, len); BIO_free (bio); return ret; } void printAndExit (std::string s) { std::cerr << "ERROR!\n" << s << std::endl << ossl_err_as_string () << std::endl; exit(EXIT_FAILURE); } EC_KEY* loadKey_xOnly (std::string& xOnly) { EC_GROUP* group = EC_GROUP_new_by_curve_name (NID_secp256k1); if (group == NULL) printAndExit ("group null"); EC_GROUP_set_point_conversion_form (group, POINT_CONVERSION_COMPRESSED); EC_POINT* pubPoint = EC_POINT_new (group); if (pubPoint == NULL) printAndExit ("pibpoint == null"); BN_CTX* bnCtx = BN_CTX_new (); BIGNUM* x = BN_new (); if (x == NULL) printAndExit ("X == NULL"); if (BN_hex2bn (&x, (const char*) xOnly.c_str()) == 0) printAndExit ("hex2bn == 0"); std::cout << "x_BN:\t" << BN_bn2hex (x) << std::endl; std::cout << "x_BA:\t" << xOnly << std::endl; if (EC_POINT_set_compressed_coordinates_GFp (group, pubPoint, x, 0, bnCtx) == 0) printAndExit ("set_compr_coord == 0"); } int main () { std::string xOnlyStr = "c16b4ce0532f5dc9d09114fe121d3956ae84f9eb677a0d4bdac1d3af7a91950c"; EC_KEY* key = loadKey_xOnly (xOnlyStr); return 0; } The string 'xOnlyStr' contains a real x-only coordinate of a verification key. Could you help me? Thank you, Luca Di Mauro Luca Di Mauro ha scritto: > Thank you very much for the reply! > Yes, I have also the additional information about on which of two > solutions I should take. > > I'll check the guides you linked below. > > Luca Di Mauro > > Nicola Tuveri ha scritto: > >> Hi, >> >> with traditional EC from the x coordinate alone you can't really do that, >> because there are always 2 possible solutions for y (in R the curve is >> symmetrical on the x axis). >> >> The standards define a "compressed point" format in which you can send the >> coordinate x and an additional bit to select which of the 2 y solutions to >> pick. >> >> You can read more about it in EC_GROUP_set_point_conversion_form at >> https://www.openssl.org/docs/man1.1.1/man3/EC_GROUP_copy.html >> >> and in EC_POINT_set_compressed_coordinates at >> https://www.openssl.org/docs/man1.1.1/man3/EC_POINT_new.html >> >> Hope this helps, >> >> Nicola Tuveri >> >> >> On Fri, Oct 18, 2019, 11:31 Luca Di Mauro wrote: >> >>> >>> Hello all, >>> >>> I don't know if it is the correct mailing list to ask this, so I'm >>> sorry if it is the wrong palce. >>> >>> I'm using openssl v1.1, and I'm trying to compute both the X and Y >>> coordinates of an elliptic curve point starting from a single >>> coordinate (X or Y). >>> >>> How can i perform that in C/C++ language using libssl? I searched on >>> google for a couple of days but i haven't found a solution. >>> >>> Luca Di Mauro >>> >>> >>> From Michael.Wojcik at microfocus.com Thu Oct 24 23:21:25 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 24 Oct 2019 23:21:25 +0000 Subject: use of makedepend in openssl 1.1.1 In-Reply-To: <10F5104D-4605-41EB-A350-26D53CF25938@openssl.org> References: <10F5104D-4605-41EB-A350-26D53CF25938@openssl.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of > Richard Levitte > Sent: Thursday, October 24, 2019 13:56 > > shiva kumar skrev: (24 oktober 2019 20:41:28 CEST) > >what is the use of makedepend in openssl 1.1.1? > >openssl 1.1.1 can build without makepend then what's the use of > >makedepend? > > For C compilers that can't generate makefile dependency files, we have > makedepend as a fallback. And, of course, makedepend is never *necessary* for building anything. You can create dependencies by hand, or always do a full build if you change any headers, and so on. makedepend is an optimization for the build process. As such, it has exactly the same purpose in OpenSSL as it does in any other project. -- Michael Wojcik Distinguished Engineer, Micro Focus From bbrumley at gmail.com Fri Oct 25 04:42:46 2019 From: bbrumley at gmail.com (Billy Brumley) Date: Fri, 25 Oct 2019 07:42:46 +0300 Subject: Compute EC_KEY starting from X or Y coordinate only In-Reply-To: <20191024210008.Horde.qhbPlR8c3H8Kvz5A_UqqAA1@webmail.cnit.it> References: <20191018082250.Horde.X2EVDG4j6ZO3jOF3bhcPJA1@webmail.cnit.it> <20191018095627.Horde.MZt6vFx0ov5Nc8zyVlGlyw4@webmail.cnit.it> <20191024210008.Horde.qhbPlR8c3H8Kvz5A_UqqAA1@webmail.cnit.it> Message-ID: > EC_GROUP* group = EC_GROUP_new_by_curve_name (NID_secp256k1); > "c16b4ce0532f5dc9d09114fe121d3956ae84f9eb677a0d4bdac1d3af7a91950c"; I don't believe there's a point on secp256k1 with that x-coordinate. If you check the failure reason for EC_POINT_set_compressed_coordinates_GFp in the debugger, that is probably what it is telling you. Where did this curve / x-coord pair come from? BBB From luca.dimauro at cnit.it Fri Oct 25 06:28:39 2019 From: luca.dimauro at cnit.it (Luca Di Mauro) Date: Fri, 25 Oct 2019 06:28:39 +0000 Subject: Compute EC_KEY starting from X or Y coordinate only In-Reply-To: References: <20191018082250.Horde.X2EVDG4j6ZO3jOF3bhcPJA1@webmail.cnit.it> <20191018095627.Horde.MZt6vFx0ov5Nc8zyVlGlyw4@webmail.cnit.it> <20191024210008.Horde.qhbPlR8c3H8Kvz5A_UqqAA1@webmail.cnit.it> Message-ID: <20191025062839.Horde.kRubPiNBXokHTRdWUl_vfg1@webmail.cnit.it> I think it is correct because I extracted the hexadecimal string from a packet contained in a pcap. This compressed point is created following the ETSI TS 103 097 v1.3.1 standard for secured communications in the vehicular communication context (https://www.etsi.org/deliver/etsi_ts/103000_103099/103097/01.03.01_60/ts_103097v010301p.pdf). I notice that the point 'pubPoint' that I created is empty when I try to call 'EC_POINT_set_compressed_coordinates_GFp' function. How can I put a BIGNUM into an EC_POINT? Luca Billy Brumley ha scritto: >> EC_GROUP* group = EC_GROUP_new_by_curve_name >> (NID_secp256k1); > >> "c16b4ce0532f5dc9d09114fe121d3956ae84f9eb677a0d4bdac1d3af7a91950c"; > > I don't believe there's a point on secp256k1 with that x-coordinate. > If you check the failure reason for > EC_POINT_set_compressed_coordinates_GFp in the debugger, that is > probably what it is telling you. > > Where did this curve / x-coord pair come from? > > BBB From bbrumley at gmail.com Fri Oct 25 07:05:54 2019 From: bbrumley at gmail.com (Billy Brumley) Date: Fri, 25 Oct 2019 10:05:54 +0300 Subject: Compute EC_KEY starting from X or Y coordinate only In-Reply-To: <20191025062839.Horde.kRubPiNBXokHTRdWUl_vfg1@webmail.cnit.it> References: <20191018082250.Horde.X2EVDG4j6ZO3jOF3bhcPJA1@webmail.cnit.it> <20191018095627.Horde.MZt6vFx0ov5Nc8zyVlGlyw4@webmail.cnit.it> <20191024210008.Horde.qhbPlR8c3H8Kvz5A_UqqAA1@webmail.cnit.it> <20191025062839.Horde.kRubPiNBXokHTRdWUl_vfg1@webmail.cnit.it> Message-ID: Don't do that. As I said, the library is trying to tell you that's not a point on the secp256k1 curve. Quickly browsing the standard, you are likely looking for the prime256v1 curve. BBB On Fri, 25 Oct 2019, 9.28 Luca Di Mauro, wrote: > I think it is correct because I extracted the hexadecimal string from > a packet contained in a pcap. > > This compressed point is created following the ETSI TS 103 097 v1.3.1 > standard for secured communications in the vehicular communication > context > ( > https://www.etsi.org/deliver/etsi_ts/103000_103099/103097/01.03.01_60/ts_103097v010301p.pdf > ). > > I notice that the point 'pubPoint' that I created is empty when I try > to call 'EC_POINT_set_compressed_coordinates_GFp' function. How can I > put a BIGNUM into an EC_POINT? > > Luca > > Billy Brumley ha scritto: > > >> EC_GROUP* group = EC_GROUP_new_by_curve_name > >> (NID_secp256k1); > > > >> "c16b4ce0532f5dc9d09114fe121d3956ae84f9eb677a0d4bdac1d3af7a91950c"; > > > > I don't believe there's a point on secp256k1 with that x-coordinate. > > If you check the failure reason for > > EC_POINT_set_compressed_coordinates_GFp in the debugger, that is > > probably what it is telling you. > > > > Where did this curve / x-coord pair come from? > > > > BBB > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.sha.jiang at gmail.com Fri Oct 25 07:33:43 2019 From: john.sha.jiang at gmail.com (John Jiang) Date: Fri, 25 Oct 2019 15:33:43 +0800 Subject: Are DHE_DSS cipher suites not supported? Message-ID: Hi, I'm using OpenSSL 1.1.1d. Just want to confirm if DHE_DSS cipher suites are not supported by this version. Please consider the below simple case, 1. s_server uses a DSA certifcate 2. force s_client to use TLS 1.2 and TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (DHE-DSS-AES256-GCM-SHA384) the connection failed, and s_server reported: no shared cipher:ssl/statem/statem_srvr.c:2259 But I still can see this cipher suite in the below doc, https://www.openssl.org/docs/man1.1.1/man1/ciphers.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Oct 25 08:39:57 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 25 Oct 2019 04:39:57 -0400 Subject: Are DHE_DSS cipher suites not supported? In-Reply-To: References: Message-ID: <20191025083957.GC34850@straasha.imrryr.org> On Fri, Oct 25, 2019 at 03:33:43PM +0800, John Jiang wrote: > I'm using OpenSSL 1.1.1d. > Just want to confirm if DHE_DSS cipher suites are not supported by this > version. They are supported, but: * DSS ciphersuites are disabled by DEFAULT. You need to specify an explicit "-cipher" option to enable these, for example: $ openssl s_server -accept 12345 \ -tls1_2 -cipher DHE-DSS-AES256-GCM-SHA384 \ -dhparam dhparam.pem -key dsakey.pem -cert dsacert.pem or more typically: -cipher 'ALL:!RC4:!aNULL' * You should also supply DH parameters as above: -dhparam dhparam.pem I generated these with: $ openssl genpkey -genparam -algorithm dh \ -pkeyopt dh_paramgen_prime_len:2048 -out dhparam.pem -- Viktor. From luca.dimauro at cnit.it Fri Oct 25 09:43:04 2019 From: luca.dimauro at cnit.it (Luca Di Mauro) Date: Fri, 25 Oct 2019 09:43:04 +0000 Subject: Compute EC_KEY starting from X or Y coordinate only In-Reply-To: References: <20191018082250.Horde.X2EVDG4j6ZO3jOF3bhcPJA1@webmail.cnit.it> <20191018095627.Horde.MZt6vFx0ov5Nc8zyVlGlyw4@webmail.cnit.it> <20191024210008.Horde.qhbPlR8c3H8Kvz5A_UqqAA1@webmail.cnit.it> <20191025062839.Horde.kRubPiNBXokHTRdWUl_vfg1@webmail.cnit.it> Message-ID: <20191025094304.Horde.-gnS_gyxW4gC71zi8F03HA1@webmail.cnit.it> Thank you! I thought they were the same. And given an x-only coordinate, how can I find the y coordinate? I don't find the relative functions on the documentation. Luca Billy Brumley ha scritto: > Don't do that. As I said, the library is trying to tell you that's not a > point on the secp256k1 curve. > > Quickly browsing the standard, you are likely looking for the prime256v1 > curve. > > BBB > > On Fri, 25 Oct 2019, 9.28 Luca Di Mauro, wrote: > >> I think it is correct because I extracted the hexadecimal string from >> a packet contained in a pcap. >> >> This compressed point is created following the ETSI TS 103 097 v1.3.1 >> standard for secured communications in the vehicular communication >> context >> ( >> https://www.etsi.org/deliver/etsi_ts/103000_103099/103097/01.03.01_60/ts_103097v010301p.pdf >> ). >> >> I notice that the point 'pubPoint' that I created is empty when I try >> to call 'EC_POINT_set_compressed_coordinates_GFp' function. How can I >> put a BIGNUM into an EC_POINT? >> >> Luca >> >> Billy Brumley ha scritto: >> >> >> EC_GROUP* group = EC_GROUP_new_by_curve_name >> >> (NID_secp256k1); >> > >> >> "c16b4ce0532f5dc9d09114fe121d3956ae84f9eb677a0d4bdac1d3af7a91950c"; >> > >> > I don't believe there's a point on secp256k1 with that x-coordinate. >> > If you check the failure reason for >> > EC_POINT_set_compressed_coordinates_GFp in the debugger, that is >> > probably what it is telling you. >> > >> > Where did this curve / x-coord pair come from? >> > >> > BBB >> >> >> >> From bbrumley at gmail.com Fri Oct 25 10:02:37 2019 From: bbrumley at gmail.com (Billy Brumley) Date: Fri, 25 Oct 2019 13:02:37 +0300 Subject: Compute EC_KEY starting from X or Y coordinate only In-Reply-To: <20191025094304.Horde.-gnS_gyxW4gC71zi8F03HA1@webmail.cnit.it> References: <20191018082250.Horde.X2EVDG4j6ZO3jOF3bhcPJA1@webmail.cnit.it> <20191018095627.Horde.MZt6vFx0ov5Nc8zyVlGlyw4@webmail.cnit.it> <20191024210008.Horde.qhbPlR8c3H8Kvz5A_UqqAA1@webmail.cnit.it> <20191025062839.Horde.kRubPiNBXokHTRdWUl_vfg1@webmail.cnit.it> <20191025094304.Horde.-gnS_gyxW4gC71zi8F03HA1@webmail.cnit.it> Message-ID: > Thank you! I thought they were the same. > > And given an x-only coordinate, how can I find the y coordinate? I > don't find the relative functions on the documentation. Well it depends on what you mean. Internally, EC_POINT_set_compressed_coordinates_GFp will internally automatically compute the y coordinate based on the y_bit argument. EC_POINT_set_compressed_coordinates_GFp(group, p, x, 0, ... EC_POINT_get_affine_coordinates_GFp(group, p, X0, Y0 ... That will get you one of the points in X0, Y0. EC_POINT_set_compressed_coordinates_GFp(group, p, x, 1, ... EC_POINT_get_affine_coordinates_GFp(group, p, X1, Y1 ... That will get you the other point in X1, Y1. (Where X0 = X1 = x.) (But you are probably looking to do something cryptographically interesting between set/get, which is application specific.) Generally, in addition to the man pages which you seem to have found, check the "tests" folder if you are looking for examples to get started. BBB From luca.dimauro at cnit.it Fri Oct 25 11:19:33 2019 From: luca.dimauro at cnit.it (Luca Di Mauro) Date: Fri, 25 Oct 2019 11:19:33 +0000 Subject: Compute EC_KEY starting from X or Y coordinate only In-Reply-To: References: <20191018082250.Horde.X2EVDG4j6ZO3jOF3bhcPJA1@webmail.cnit.it> <20191018095627.Horde.MZt6vFx0ov5Nc8zyVlGlyw4@webmail.cnit.it> <20191024210008.Horde.qhbPlR8c3H8Kvz5A_UqqAA1@webmail.cnit.it> <20191025062839.Horde.kRubPiNBXokHTRdWUl_vfg1@webmail.cnit.it> <20191025094304.Horde.-gnS_gyxW4gC71zi8F03HA1@webmail.cnit.it> Message-ID: <20191025111933.Horde.Rs6jXXKFF2SGz8qJ3Iw-CA1@webmail.cnit.it> Mh, maybe I didn't understand. If I have an x-point which follows this representation https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html (so it is composed by 33 byte and first byte is '0x02') and I use 'EC_POINT_set_compressed_coordinates_GFp' function, it will be considered as compressed-y-0 or compressed-y-1? Or it is correctly considered as the x coordinate? Luca Billy Brumley ha scritto: >> Thank you! I thought they were the same. >> >> And given an x-only coordinate, how can I find the y coordinate? I >> don't find the relative functions on the documentation. > > Well it depends on what you mean. Internally, > EC_POINT_set_compressed_coordinates_GFp will internally automatically > compute the y coordinate based on the y_bit argument. > > EC_POINT_set_compressed_coordinates_GFp(group, p, x, 0, ... > EC_POINT_get_affine_coordinates_GFp(group, p, X0, Y0 ... > > That will get you one of the points in X0, Y0. > > EC_POINT_set_compressed_coordinates_GFp(group, p, x, 1, ... > EC_POINT_get_affine_coordinates_GFp(group, p, X1, Y1 ... > > That will get you the other point in X1, Y1. (Where X0 = X1 = x.) > > (But you are probably looking to do something cryptographically > interesting between set/get, which is application specific.) > > Generally, in addition to the man pages which you seem to have found, > check the "tests" folder if you are looking for examples to get > started. > > BBB From thulasi.goriparthi at gmail.com Fri Oct 25 11:24:42 2019 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Fri, 25 Oct 2019 16:54:42 +0530 Subject: Compute EC_KEY starting from X or Y coordinate only In-Reply-To: <20191025111933.Horde.Rs6jXXKFF2SGz8qJ3Iw-CA1@webmail.cnit.it> References: <20191018082250.Horde.X2EVDG4j6ZO3jOF3bhcPJA1@webmail.cnit.it> <20191018095627.Horde.MZt6vFx0ov5Nc8zyVlGlyw4@webmail.cnit.it> <20191024210008.Horde.qhbPlR8c3H8Kvz5A_UqqAA1@webmail.cnit.it> <20191025062839.Horde.kRubPiNBXokHTRdWUl_vfg1@webmail.cnit.it> <20191025094304.Horde.-gnS_gyxW4gC71zi8F03HA1@webmail.cnit.it> <20191025111933.Horde.Rs6jXXKFF2SGz8qJ3Iw-CA1@webmail.cnit.it> Message-ID: 02 indicates y bit is 0 03 indicates y bit is 1 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.202.2977&rep=rep1&type=pdf Thanks, Thulasi. On Fri, 25 Oct 2019 at 16:50, Luca Di Mauro wrote: > > Mh, maybe I didn't understand. > > If I have an x-point which follows this representation > https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html (so it is > composed by 33 byte and first byte is '0x02') and I use > 'EC_POINT_set_compressed_coordinates_GFp' function, it will be > considered as compressed-y-0 or compressed-y-1? Or it is correctly > considered as the x coordinate? > > Luca > > Billy Brumley ha scritto: > > >> Thank you! I thought they were the same. > >> > >> And given an x-only coordinate, how can I find the y coordinate? I > >> don't find the relative functions on the documentation. > > > > Well it depends on what you mean. Internally, > > EC_POINT_set_compressed_coordinates_GFp will internally automatically > > compute the y coordinate based on the y_bit argument. > > > > EC_POINT_set_compressed_coordinates_GFp(group, p, x, 0, ... > > EC_POINT_get_affine_coordinates_GFp(group, p, X0, Y0 ... > > > > That will get you one of the points in X0, Y0. > > > > EC_POINT_set_compressed_coordinates_GFp(group, p, x, 1, ... > > EC_POINT_get_affine_coordinates_GFp(group, p, X1, Y1 ... > > > > That will get you the other point in X1, Y1. (Where X0 = X1 = x.) > > > > (But you are probably looking to do something cryptographically > > interesting between set/get, which is application specific.) > > > > Generally, in addition to the man pages which you seem to have found, > > check the "tests" folder if you are looking for examples to get > > started. > > > > BBB > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.dimauro at cnit.it Fri Oct 25 11:39:24 2019 From: luca.dimauro at cnit.it (Luca Di Mauro) Date: Fri, 25 Oct 2019 11:39:24 +0000 Subject: Compute EC_KEY starting from X or Y coordinate only In-Reply-To: References: <20191018082250.Horde.X2EVDG4j6ZO3jOF3bhcPJA1@webmail.cnit.it> <20191018095627.Horde.MZt6vFx0ov5Nc8zyVlGlyw4@webmail.cnit.it> <20191024210008.Horde.qhbPlR8c3H8Kvz5A_UqqAA1@webmail.cnit.it> <20191025062839.Horde.kRubPiNBXokHTRdWUl_vfg1@webmail.cnit.it> <20191025094304.Horde.-gnS_gyxW4gC71zi8F03HA1@webmail.cnit.it> <20191025111933.Horde.Rs6jXXKFF2SGz8qJ3Iw-CA1@webmail.cnit.it> Message-ID: <20191025113924.Horde.XdhdcGrdFe1TYyzZs6HTIw6@webmail.cnit.it> But the y bit is indicated by the foutth parameter of 'EC_POINT_set_compressed_coordinates_GFp' function. Isn't the representation you linked different by that that I linked previously? Luca Thulasi Goriparthi ha scritto: > 02 indicates y bit is 0 > 03 indicates y bit is 1 > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.202.2977&rep=rep1&type=pdf > > > Thanks, > Thulasi. > > On Fri, 25 Oct 2019 at 16:50, Luca Di Mauro wrote: > >> >> Mh, maybe I didn't understand. >> >> If I have an x-point which follows this representation >> https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html (so it is >> composed by 33 byte and first byte is '0x02') and I use >> 'EC_POINT_set_compressed_coordinates_GFp' function, it will be >> considered as compressed-y-0 or compressed-y-1? Or it is correctly >> considered as the x coordinate? >> >> Luca >> >> Billy Brumley ha scritto: >> >> >> Thank you! I thought they were the same. >> >> >> >> And given an x-only coordinate, how can I find the y coordinate? I >> >> don't find the relative functions on the documentation. >> > >> > Well it depends on what you mean. Internally, >> > EC_POINT_set_compressed_coordinates_GFp will internally automatically >> > compute the y coordinate based on the y_bit argument. >> > >> > EC_POINT_set_compressed_coordinates_GFp(group, p, x, 0, ... >> > EC_POINT_get_affine_coordinates_GFp(group, p, X0, Y0 ... >> > >> > That will get you one of the points in X0, Y0. >> > >> > EC_POINT_set_compressed_coordinates_GFp(group, p, x, 1, ... >> > EC_POINT_get_affine_coordinates_GFp(group, p, X1, Y1 ... >> > >> > That will get you the other point in X1, Y1. (Where X0 = X1 = x.) >> > >> > (But you are probably looking to do something cryptographically >> > interesting between set/get, which is application specific.) >> > >> > Generally, in addition to the man pages which you seem to have found, >> > check the "tests" folder if you are looking for examples to get >> > started. >> > >> > BBB >> >> >> >> From bbrumley at gmail.com Fri Oct 25 12:01:30 2019 From: bbrumley at gmail.com (Billy Brumley) Date: Fri, 25 Oct 2019 15:01:30 +0300 Subject: Compute EC_KEY starting from X or Y coordinate only In-Reply-To: <20191025111933.Horde.Rs6jXXKFF2SGz8qJ3Iw-CA1@webmail.cnit.it> References: <20191018082250.Horde.X2EVDG4j6ZO3jOF3bhcPJA1@webmail.cnit.it> <20191018095627.Horde.MZt6vFx0ov5Nc8zyVlGlyw4@webmail.cnit.it> <20191024210008.Horde.qhbPlR8c3H8Kvz5A_UqqAA1@webmail.cnit.it> <20191025062839.Horde.kRubPiNBXokHTRdWUl_vfg1@webmail.cnit.it> <20191025094304.Horde.-gnS_gyxW4gC71zi8F03HA1@webmail.cnit.it> <20191025111933.Horde.Rs6jXXKFF2SGz8qJ3Iw-CA1@webmail.cnit.it> Message-ID: > If I have an x-point which follows this representation > https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html (so it is > composed by 33 byte and first byte is '0x02') and I use > 'EC_POINT_set_compressed_coordinates_GFp' function, it will be > considered as compressed-y-0 or compressed-y-1? Or it is correctly > considered as the x coordinate? What you are saying and what you are doing are two different things. Your code is at a very low level. Above this there is some encoding of points, depending on any number of standards. OpenSSL implements some of them, but at a higher level. The low level API you're talking about provides maximum flexibility to map that high level encoding in to the API's "x-coord + y-bit" concept. It's up to you to figure out the details. (Including determining if the encoding in OpenSSL matches what's expected in your spec.) You need to play around a bit with the lib -- you can't expect this list to interpret the standard for you. Check the "test" folder for sample code. BBB From matt at openssl.org Fri Oct 25 12:49:54 2019 From: matt at openssl.org (Matt Caswell) Date: Fri, 25 Oct 2019 13:49:54 +0100 Subject: Are DHE_DSS cipher suites not supported? In-Reply-To: <20191025083957.GC34850@straasha.imrryr.org> References: <20191025083957.GC34850@straasha.imrryr.org> Message-ID: <293d4256-5776-9fb8-6315-ab4a40393488@openssl.org> On 25/10/2019 09:39, Viktor Dukhovni wrote: > On Fri, Oct 25, 2019 at 03:33:43PM +0800, John Jiang wrote: > >> I'm using OpenSSL 1.1.1d. >> Just want to confirm if DHE_DSS cipher suites are not supported by this >> version. > > They are supported, but: > > * DSS ciphersuites are disabled by DEFAULT. You need to > specify an explicit "-cipher" option to enable these, > for example: > > $ openssl s_server -accept 12345 \ > -tls1_2 -cipher DHE-DSS-AES256-GCM-SHA384 \ > -dhparam dhparam.pem -key dsakey.pem -cert dsacert.pem > > or more typically: > > -cipher 'ALL:!RC4:!aNULL' > > * You should also supply DH parameters as above: This step is optional. It will work just fine with default parameters if you don't specify them. Matt > > -dhparam dhparam.pem > > I generated these with: > > $ openssl genpkey -genparam -algorithm dh \ > -pkeyopt dh_paramgen_prime_len:2048 -out dhparam.pem > From john.sha.jiang at gmail.com Fri Oct 25 12:52:50 2019 From: john.sha.jiang at gmail.com (John Jiang) Date: Fri, 25 Oct 2019 20:52:50 +0800 Subject: Are DHE_DSS cipher suites not supported? In-Reply-To: <293d4256-5776-9fb8-6315-ab4a40393488@openssl.org> References: <20191025083957.GC34850@straasha.imrryr.org> <293d4256-5776-9fb8-6315-ab4a40393488@openssl.org> Message-ID: On Fri, Oct 25, 2019 at 8:50 PM Matt Caswell wrote: > > > On 25/10/2019 09:39, Viktor Dukhovni wrote: > > On Fri, Oct 25, 2019 at 03:33:43PM +0800, John Jiang wrote: > > > >> I'm using OpenSSL 1.1.1d. > >> Just want to confirm if DHE_DSS cipher suites are not supported by this > >> version. > > > > They are supported, but: > > > > * DSS ciphersuites are disabled by DEFAULT. You need to > > specify an explicit "-cipher" option to enable these, > > for example: > > > > $ openssl s_server -accept 12345 \ > > -tls1_2 -cipher DHE-DSS-AES256-GCM-SHA384 \ > > -dhparam dhparam.pem -key dsakey.pem -cert dsacert.pem > > > > or more typically: > > > > -cipher 'ALL:!RC4:!aNULL' > > > > * You should also supply DH parameters as above: > > This step is optional. It will work just fine with default parameters if > you don't specify them. > I only add option -cipher to s_server. That works for me. Thanks! > > Matt > > > > > > > -dhparam dhparam.pem > > > > I generated these with: > > > > $ openssl genpkey -genparam -algorithm dh \ > > -pkeyopt dh_paramgen_prime_len:2048 -out dhparam.pem > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janjust at nikhef.nl Fri Oct 25 15:38:27 2019 From: janjust at nikhef.nl (Jan Just Keijser) Date: Fri, 25 Oct 2019 17:38:27 +0200 Subject: Retrieve CA for client cert from SSL* In-Reply-To: References: Message-ID: On 24/10/19 19:55, Fen Fox wrote: > > Is there a way to figure out which CA the server used to validate the > client certificate? > > on the server side?? you would have to write your own verify callback to intercept the certificate stack as it is processed. That way, you can monitor which CA openssl selected for verification. HTH, JJK -------------- next part -------------- An HTML attachment was scrubbed... URL: From janjust at nikhef.nl Fri Oct 25 15:37:22 2019 From: janjust at nikhef.nl (Jan Just Keijser) Date: Fri, 25 Oct 2019 17:37:22 +0200 Subject: AW: openssl and external card reader support in TLS In-Reply-To: References: Message-ID: <3e8a51ac-47a0-573c-3995-cc241e12ef1e@nikhef.nl> Hi Tobias, On 23/10/19 10:11, Tobias.Wolf at t-systems.com wrote: > Our PKCS11 module development will discontinue and therefore I can`t use it anymore, but the idea is great and very interesting. > To give more details we need a callback or similar mechanism to replace the signature created in Certificate TLS message with our signature coming from the card reader. > > TLS handshake > ...... > S: Certificate Request > C: Certificate Verify --> here we want to hook in "Signature" and replace the value! > ..... > > We tried already with the client callback > > int (*client_cert_cb)(SSL *ssl, X509 **x509, > EVP_PKEY **pkey)); > > But there it is mandatory to give in the private key which we don`t have, because that part is done by the card reader machine. > I think the caller of the callback is doing later on a rsa sign processing with the private key and there I want to hook in! > writing your own engine might be the easiest thing: the way it currently(most likely) works, is ? openssl -> engine_pkcs11 -> libp11 -> pkcs11 driver all you'd have to do is move your pkcs11 driver code into a fork of the engine_pkcs11 code. That code is less than 2000 lines long, so it should be fairly straightforward. JM2CW, JJK From rsalz at akamai.com Fri Oct 25 15:49:33 2019 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 25 Oct 2019 15:49:33 +0000 Subject: Retrieve CA for client cert from SSL* In-Reply-To: References: Message-ID: <9FCEF66E-14B1-4245-8167-F6788E3A945B@akamai.com> Is looking at the IssuerDN good enough? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Oct 25 15:54:40 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 25 Oct 2019 17:54:40 +0200 Subject: Retrieve CA for client cert from SSL* In-Reply-To: References: Message-ID: <49E2C1C7-69C1-4346-94E6-098E092D9633@dukhovni.org> > On Oct 25, 2019, at 5:38 PM, Jan Just Keijser wrote: > >> Is there a way to figure out which CA the server used to validate the client certificate? > > on the server side? you would have to write your own verify callback to intercept the certificate stack as it is processed. That way, you can monitor which CA openssl selected for verification. No, that's not necessary. After the completion of the handshake one can call SSL_get0_verified_chain(3). This chain is only available on full handshakes, when validation is successful (SSL_get_verify_result(3) returns X509_V_OK). On resumption, only the leaf certificate is available from the resumed session, via SSL_get_peer_certificate(3). Of course there might not be a client certificate at all. -- Viktor. From Fen.Fox at Microfocus.com Fri Oct 25 16:03:53 2019 From: Fen.Fox at Microfocus.com (Fen Fox) Date: Fri, 25 Oct 2019 16:03:53 +0000 Subject: Retrieve CA for client cert from SSL* In-Reply-To: <49E2C1C7-69C1-4346-94E6-098E092D9633@dukhovni.org> References: <49E2C1C7-69C1-4346-94E6-098E092D9633@dukhovni.org> Message-ID: SSL_get0_verified_chain was exactly what I needed, thanks! -----Original Message----- From: openssl-users On Behalf Of Viktor Dukhovni Sent: Friday, October 25, 2019 11:55 AM To: openssl-users at openssl.org Subject: Re: Retrieve CA for client cert from SSL* > On Oct 25, 2019, at 5:38 PM, Jan Just Keijser wrote: > >> Is there a way to figure out which CA the server used to validate the client certificate? > > on the server side? you would have to write your own verify callback to intercept the certificate stack as it is processed. That way, you can monitor which CA openssl selected for verification. No, that's not necessary. After the completion of the handshake one can call SSL_get0_verified_chain(3). This chain is only available on full handshakes, when validation is successful (SSL_get_verify_result(3) returns X509_V_OK). On resumption, only the leaf certificate is available from the resumed session, via SSL_get_peer_certificate(3). Of course there might not be a client certificate at all. -- Viktor. From luca.dimauro at cnit.it Sat Oct 26 07:50:37 2019 From: luca.dimauro at cnit.it (Luca Di Mauro) Date: Sat, 26 Oct 2019 07:50:37 +0000 Subject: Compute EC_KEY starting from X or Y coordinate only In-Reply-To: References: <20191018082250.Horde.X2EVDG4j6ZO3jOF3bhcPJA1@webmail.cnit.it> <20191018095627.Horde.MZt6vFx0ov5Nc8zyVlGlyw4@webmail.cnit.it> <20191024210008.Horde.qhbPlR8c3H8Kvz5A_UqqAA1@webmail.cnit.it> <20191025062839.Horde.kRubPiNBXokHTRdWUl_vfg1@webmail.cnit.it> <20191025094304.Horde.-gnS_gyxW4gC71zi8F03HA1@webmail.cnit.it> <20191025111933.Horde.Rs6jXXKFF2SGz8qJ3Iw-CA1@webmail.cnit.it> Message-ID: <20191026075037.Horde.6dzm_ijQXdmgnNw60TSRGw5@webmail.cnit.it> I checked the 'test' folder but I didn't found any tests that help me in this case. However the only doubt is how I can use the API offered by openssl library. I understand how retreive a point (and consequently to assign it to a public key) starting from a compressed-y representation (which belongs to this standard https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html). My doubt now is how to obtain a point (x,y) given the coordinate, which means resolve the equation y^2= x^3 + ax + b. Can you give me some tips to found a solution? Luca Billy Brumley ha scritto: >> If I have an x-point which follows this representation >> https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html (so it is >> composed by 33 byte and first byte is '0x02') and I use >> 'EC_POINT_set_compressed_coordinates_GFp' function, it will be >> considered as compressed-y-0 or compressed-y-1? Or it is correctly >> considered as the x coordinate? > > What you are saying and what you are doing are two different things. > > Your code is at a very low level. > > Above this there is some encoding of points, depending on any number > of standards. OpenSSL implements some of them, but at a higher level. > > The low level API you're talking about provides maximum flexibility to > map that high level encoding in to the API's "x-coord + y-bit" > concept. It's up to you to figure out the details. (Including > determining if the encoding in OpenSSL matches what's expected in your > spec.) > > You need to play around a bit with the lib -- you can't expect this > list to interpret the standard for you. Check the "test" folder for > sample code. > > BBB From thulasi.goriparthi at gmail.com Sat Oct 26 11:41:09 2019 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Sat, 26 Oct 2019 17:11:09 +0530 Subject: Compute EC_KEY starting from X or Y coordinate only In-Reply-To: <20191026075037.Horde.6dzm_ijQXdmgnNw60TSRGw5@webmail.cnit.it> References: <20191018082250.Horde.X2EVDG4j6ZO3jOF3bhcPJA1@webmail.cnit.it> <20191018095627.Horde.MZt6vFx0ov5Nc8zyVlGlyw4@webmail.cnit.it> <20191024210008.Horde.qhbPlR8c3H8Kvz5A_UqqAA1@webmail.cnit.it> <20191025062839.Horde.kRubPiNBXokHTRdWUl_vfg1@webmail.cnit.it> <20191025094304.Horde.-gnS_gyxW4gC71zi8F03HA1@webmail.cnit.it> <20191025111933.Horde.Rs6jXXKFF2SGz8qJ3Iw-CA1@webmail.cnit.it> <20191026075037.Horde.6dzm_ijQXdmgnNw60TSRGw5@webmail.cnit.it> Message-ID: Call to EC_POINT_set_compressed_coodinates() with with x-coordinate and y-bit will resolve the curve equation for y and chooses y out of two possible y values based on y-bit input. You can retrieve the x and y co-ordinates using EC_POINT_get_affine_coordinates as below, where x-cordinate matches with your input x. EC_POINT_get_affine_coordinates(group, ec_pub_key, bn_x, bn_y, NULL); Thanks, Thulasi. On Sat, 26 Oct 2019 at 13:21, Luca Di Mauro wrote: > I checked the 'test' folder but I didn't found any tests that help me > in this case. > > However the only doubt is how I can use the API offered by openssl library. > I understand how retreive a point (and consequently to assign it to a > public key) starting from a compressed-y representation (which belongs > to this standard > https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html). > > My doubt now is how to obtain a point (x,y) given the coordinate, > which means resolve the equation y^2= x^3 + ax + b. > Can you give me some tips to found a solution? > > Luca > > Billy Brumley ha scritto: > > >> If I have an x-point which follows this representation > >> https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html (so it is > >> composed by 33 byte and first byte is '0x02') and I use > >> 'EC_POINT_set_compressed_coordinates_GFp' function, it will be > >> considered as compressed-y-0 or compressed-y-1? Or it is correctly > >> considered as the x coordinate? > > > > What you are saying and what you are doing are two different things. > > > > Your code is at a very low level. > > > > Above this there is some encoding of points, depending on any number > > of standards. OpenSSL implements some of them, but at a higher level. > > > > The low level API you're talking about provides maximum flexibility to > > map that high level encoding in to the API's "x-coord + y-bit" > > concept. It's up to you to figure out the details. (Including > > determining if the encoding in OpenSSL matches what's expected in your > > spec.) > > > > You need to play around a bit with the lib -- you can't expect this > > list to interpret the standard for you. Check the "test" folder for > > sample code. > > > > BBB > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tobias.Wolf at t-systems.com Mon Oct 28 15:14:00 2019 From: Tobias.Wolf at t-systems.com (Tobias.Wolf at t-systems.com) Date: Mon, 28 Oct 2019 15:14:00 +0000 Subject: AW: openssl and external card reader support in TLS In-Reply-To: References: Message-ID: We decided to implement the engine concept, but as far as I understood acts the engine on a globally level, right? But in our application we have two different TLS communication ways, is it possible that our custom engine is only active for one transport way i.e. on ssl context level? From nagalakshmi.j at altran.com Tue Oct 29 10:34:34 2019 From: nagalakshmi.j at altran.com (Nagalakshmi V J) Date: Tue, 29 Oct 2019 10:34:34 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: <2b8035491b1d40668758b78936fab706@Ex13.ncp.local> <2739d542-13a2-4778-47fd-c45b45492f37@openssl.org> , , , Message-ID: Hi All, Appreciate the response for the below query. Anyone faced the same issue? Thanks & Regards, Nagalakshmi V J ________________________________ From: Nagalakshmi V J Sent: 24 October 2019 03:29 To: Nagalakshmi V J ; Matt Caswell ; openssl-users at openssl.org Subject: Re: OpenSSL compilation errors in Windows Hi Matt, Kindly provide your inputs for the below mail. Thanks & Regards, Nagalakshmi V J ________________________________ From: Nagalakshmi V J Sent: 22 October 2019 10:41:40 To: Matt Caswell ; openssl-users at openssl.org Cc: Nagalakshmi V J Subject: RE: OpenSSL compilation errors in Windows Hi Matt, Could you please help to get any clue on the ACCESSOR APIs of the following. I tried searching APIs. Not getting exact matches. Referred the below links. https://www.openssl.org/docs/man1.1.1/man3/SSL_set_info_callback.html https://www.openssl.org/docs/man1.1.1/man3/EVP_md5.html Getting similar error for the below code. tls1_PRF(s->ctx->md5,s->ctx->sha1,buf,(int)(p-buf), pGenerator->master_secret,sizeof(pGenerator->master_secret), km,tmp,num); Struct ssl_ctx_st { ? const EVP_MD *md5; /* For SSLv3/TLSv1 'ssl3-md5' */ const EVP_MD *sha1; /* For SSLv3/TLSv1 'ssl3->sha1' */ ? } struct evp_md_st { int type; int pkey_type; int md_size; unsigned long flags; int (*init) (EVP_MD_CTX *ctx); int (*update) (EVP_MD_CTX *ctx, const void *data, size_t count); int (*final) (EVP_MD_CTX *ctx, unsigned char *md); int (*copy) (EVP_MD_CTX *to, const EVP_MD_CTX *from); int (*cleanup) (EVP_MD_CTX *ctx); int block_size; int ctx_size; /* how big does the ctx->md_data need to be */ /* control function */ int (*md_ctrl) (EVP_MD_CTX *ctx, int cmd, int p1, void *p2); } /* EVP_MD */ ; Thanks and regards, Nagalakshmi From: Nagalakshmi V J Sent: Tuesday, October 22, 2019 9:39 AM To: Matt Caswell ; Nagalakshmi V J ; openssl-users at openssl.org Subject: Re: OpenSSL compilation errors in Windows Hi Matt, Yes. Exactly we followed the same and able to resolve errors. Thank you so much for the support and guidance. I'll get back if any further errors. Thanks & Regards, Nagalakshmi V J ________________________________ From: Matt Caswell > Sent: 21 October 2019 21:26:32 To: Nagalakshmi V J >; openssl-users at openssl.org > Subject: Re: OpenSSL compilation errors in Windows ** This mail has been sent from an external source ** On 20/10/2019 08:43, Nagalakshmi V J wrote: > Hi Matt, > > This link is having few APIS. But for getting master_key_length, I don't > find any API. Not sure if we need to use getMasterKey API for that. You can use SSL_SESSION_get_master_key() for this. Note this comment in the RETURN VALUES section: "For the other functions, if outlen is greater than 0 then these functions return the number of bytes actually copied, which will be less than or equal to outlen. If outlen is 0 then these functions return the maximum number of bytes they would copy -- that is, the length of the underlying field." So to discover the master_key_length call the function with outlen to zero. You can then allocate an appropriate sized buffer and call the function again in order to get the actual master key. Matt > > I will try to use these APIs and get back. > > Thanks & Regards, > Nagalakshmi V J > ------------------------------------------------------------------------ > *From:* Matt Caswell > > *Sent:* 18 October 2019 14:48:33 > *To:* Nagalakshmi V J >; > openssl-users at openssl.org > > *Subject:* Re: OpenSSL compilation errors in Windows > > ** This mail has been sent from an external source ** > > > On 18/10/2019 11:49, Nagalakshmi V J wrote: >> Now the issue is SSL_session structure is also having accessor APIs >> which I am not aware of. So I need to get the APIs for accessing the >> master_key_length,etc.. given in the above code. Those are not listed >> in the openssl link referred. > > On this page look a the various functions beginning with "SSL_SESSION_" > in the name: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.1.1_man3_&d=DwICaQ&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=MZhYFrTAuuHOqAirPiGbT1CY6HDdH2U_CWYq12626Ts&s=gE0JHTVoToRHQRu5h2amvKa5WzyXsortlw0IoQd3VG4&e= > > From the code sample you gave you are probably mostly interested in the > functions on this page: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.1.1_man3_SSL-5FSESSION-5Fget-5Fmaster-5Fkey.html&d=DwICaQ&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=MZhYFrTAuuHOqAirPiGbT1CY6HDdH2U_CWYq12626Ts&s=XTuEzS7qyBvIHc_qWJYoh3JVC4zPCzvUzNPStW_SvLI&e= > > Matt > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Oct 29 10:47:46 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 29 Oct 2019 10:47:46 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: <2b8035491b1d40668758b78936fab706@Ex13.ncp.local> <2739d542-13a2-4778-47fd-c45b45492f37@openssl.org> Message-ID: <66049c61-3b52-3be0-b568-9a36f2a8b166@openssl.org> On 29/10/2019 10:34, Nagalakshmi V J wrote: > > tls1_PRF(s->ctx->md5,s->ctx->sha1,buf,(int)(p-buf), > > ???????? pGenerator->master_secret,sizeof(pGenerator->master_secret), > > ???????? km,tmp,num); It seems your code is replicating parts of libssl - which seems like a strange (and possibly dangerous) thing to do! > Struct ssl_ctx_st { > > ? > > constEVP_MD *md5;????????? /* For SSLv3/TLSv1 'ssl3-md5' */ > > constEVP_MD *sha1;???????? /* For SSLv3/TLSv1 'ssl3->sha1' */ > > ? > > } You really don't need to access these things. They're just cached references to the value returned by EVP_get_digestbyname("ssl3-md5") and EVP_get_digestbyname("ssl3-sha1"). So you can call those functions directly anyway. Matt From nagalakshmi.j at altran.com Tue Oct 29 11:55:27 2019 From: nagalakshmi.j at altran.com (Nagalakshmi V J) Date: Tue, 29 Oct 2019 11:55:27 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: <66049c61-3b52-3be0-b568-9a36f2a8b166@openssl.org> References: <2b8035491b1d40668758b78936fab706@Ex13.ncp.local> <2739d542-13a2-4778-47fd-c45b45492f37@openssl.org> , <66049c61-3b52-3be0-b568-9a36f2a8b166@openssl.org> Message-ID: Hi Matt, Thank you so much for your response. Those mentioned APIs resolved my errors. For the below code, return SSL_get_session(pConnection) != NULL && pConnection->session->session_id_length != 0; Any reference for accessing session_id_length? https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_set_generate_session_id.html Not sure if I can use the above link. Thanks & Regards, Nagalakshmi V J ________________________________ From: Matt Caswell Sent: 29 October 2019 10:47 To: Nagalakshmi V J ; openssl-users at openssl.org Subject: Re: OpenSSL compilation errors in Windows ** This mail has been sent from an external source ** On 29/10/2019 10:34, Nagalakshmi V J wrote: > > tls1_PRF(s->ctx->md5,s->ctx->sha1,buf,(int)(p-buf), > > pGenerator->master_secret,sizeof(pGenerator->master_secret), > > km,tmp,num); It seems your code is replicating parts of libssl - which seems like a strange (and possibly dangerous) thing to do! > Struct ssl_ctx_st { > > ? > > constEVP_MD *md5; /* For SSLv3/TLSv1 'ssl3-md5' */ > > constEVP_MD *sha1; /* For SSLv3/TLSv1 'ssl3->sha1' */ > > ? > > } You really don't need to access these things. They're just cached references to the value returned by EVP_get_digestbyname("ssl3-md5") and EVP_get_digestbyname("ssl3-sha1"). So you can call those functions directly anyway. Matt ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From ratheesh.ksz at gmail.com Wed Oct 30 03:04:55 2019 From: ratheesh.ksz at gmail.com (ratheesh kannoth) Date: Wed, 30 Oct 2019 08:34:55 +0530 Subject: SHA_CTX h0, h1, h2, h3, h4 Message-ID: Hi, 1. what are these h0....h4 ? 2. How are they generated ? 3. Could you help to locate code in openssl ? typedef struct SHAstate_st { SHA_LONG h0, h1, h2, h3, h4; SHA_LONG Nl, Nh; SHA_LONG data[SHA_LBLOCK]; unsigned int num; } SHA_CTX; Thanks,, From nagalakshmi.j at altran.com Wed Oct 30 13:02:06 2019 From: nagalakshmi.j at altran.com (Nagalakshmi V J) Date: Wed, 30 Oct 2019 13:02:06 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: <2b8035491b1d40668758b78936fab706@Ex13.ncp.local> <2739d542-13a2-4778-47fd-c45b45492f37@openssl.org> , <66049c61-3b52-3be0-b568-9a36f2a8b166@openssl.org> Message-ID: Hi Matt, Any inputs on the below query? Thanks and regards, Nagalakshmi From: Nagalakshmi V J Sent: Tuesday, October 29, 2019 5:25 PM To: Matt Caswell ; Nagalakshmi V J ; openssl-users at openssl.org Subject: Re: OpenSSL compilation errors in Windows Hi Matt, Thank you so much for your response. Those mentioned APIs resolved my errors. For the below code, return SSL_get_session(pConnection) != NULL && pConnection->session->session_id_length != 0; Any reference for accessing session_id_length? https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_set_generate_session_id.html Not sure if I can use the above link. Thanks & Regards, Nagalakshmi V J ________________________________ From: Matt Caswell > Sent: 29 October 2019 10:47 To: Nagalakshmi V J >; openssl-users at openssl.org > Subject: Re: OpenSSL compilation errors in Windows ** This mail has been sent from an external source ** On 29/10/2019 10:34, Nagalakshmi V J wrote: > > tls1_PRF(s->ctx->md5,s->ctx->sha1,buf,(int)(p-buf), > > pGenerator->master_secret,sizeof(pGenerator->master_secret), > > km,tmp,num); It seems your code is replicating parts of libssl - which seems like a strange (and possibly dangerous) thing to do! > Struct ssl_ctx_st { > > ... > > constEVP_MD *md5; /* For SSLv3/TLSv1 'ssl3-md5' */ > > constEVP_MD *sha1; /* For SSLv3/TLSv1 'ssl3->sha1' */ > > ... > > } You really don't need to access these things. They're just cached references to the value returned by EVP_get_digestbyname("ssl3-md5") and EVP_get_digestbyname("ssl3-sha1"). So you can call those functions directly anyway. Matt ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Oct 30 14:24:30 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 30 Oct 2019 14:24:30 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: <2739d542-13a2-4778-47fd-c45b45492f37@openssl.org> <66049c61-3b52-3be0-b568-9a36f2a8b166@openssl.org> Message-ID: <92db124c-3cf0-0474-dc88-a5663fa5561e@openssl.org> On 29/10/2019 11:55, Nagalakshmi V J wrote: > Hi Matt, > > Thank you so much for your response. Those mentioned APIs resolved my > errors. > > For the below code, > > ?return ?SSL_get_session(pConnection) != NULL && > ? ? ? ? ? ? ? ? pConnection->session->session_id_length != 0; > > Any reference for accessing session_id_length? > https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_set_generate_session_id.html You should use SSL_SESSION_get_id() to get hold of the length: https://www.openssl.org/docs/man1.1.1/man3/SSL_SESSION_get_id.html Matt > > Not sure if I can use the above link. > > > /Thanks & Regards,/ > /Nagalakshmi V J/ > ------------------------------------------------------------------------ > *From:* Matt Caswell > *Sent:* 29 October 2019 10:47 > *To:* Nagalakshmi V J ; > openssl-users at openssl.org > *Subject:* Re: OpenSSL compilation errors in Windows > ? > ** This mail has been sent from an external source ** > > > On 29/10/2019 10:34, Nagalakshmi V J wrote: >> >> tls1_PRF(s->ctx->md5,s->ctx->sha1,buf,(int)(p-buf), >> >>????????? pGenerator->master_secret,sizeof(pGenerator->master_secret), >> >>????????? km,tmp,num); > > It seems your code is replicating parts of libssl - which seems like a > strange (and possibly dangerous) thing to do! > >> Struct ssl_ctx_st { >> >> ? >> >> constEVP_MD *md5;????????? /* For SSLv3/TLSv1 'ssl3-md5' */ >> >> constEVP_MD *sha1;???????? /* For SSLv3/TLSv1 'ssl3->sha1' */ >> >> ? >> >> } > > You really don't need to access these things. They're just cached > references to the value returned by EVP_get_digestbyname("ssl3-md5") and > EVP_get_digestbyname("ssl3-sha1"). So you can call those functions > directly anyway. > > Matt > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== From cauldwell.thomas at gmail.com Wed Oct 30 14:12:19 2019 From: cauldwell.thomas at gmail.com (Frederick Gotham) Date: Wed, 30 Oct 2019 14:12:19 -0000 (UTC) Subject: Remove All Software Generators Message-ID: I'm working on Linux with a x86-64 CPU. I have a TPM2 chip, and so I want OpenSSL to do all of its encryption and random number generation through the TPM2 chip. In the event that the chip fails, I do NOT want there to be a backup system. I do NOT want any kind of software psuedorandom number generator nor any software encryption routines. The engine that I'm using for OpenSSL is "libtpm2tss.so". This engine library requires two more libraries, "libtss2-tcti-device.so" and "libtss2-tcti-mssim.so". (The former is for using the TPM2 chip, whereas the latter is a software simulator). As I don't want to have a simulator, I tried simply deleting the simulator library, but this caused linkage problems for the mother engine library. As an alternative, I made a new dummy library in which all of the functions return an error value, and I put this dummy library in the place of the simulator. This transplant went fine. It appears that OpenSSL will kick and scream and refuse to die not matter how hard you hit it. If I try to generate a random number like this: openssl rand -hex 8 Then it seems it will try in this order: 1) The TPM2 chip 2) The software simulator of the TPM2 chip 3) The built-in RDRAND number 4) Another one that I can't find I have recompiled OpenSSL with the flag OPENSSL_NO_RDRAND to get rid of the in-built engine. I have even done "rm /dev/random" and "rm /dev/urandom", but SOME HOW, SOME WAY, I'm still getting output when I run openssl rand -hex 8. How on earth to get OpenSSL to simply give up? I simply cannot have it use anything other than my TPM2 chip. Frederick From beldmit at gmail.com Wed Oct 30 14:48:16 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 30 Oct 2019 17:48:16 +0300 Subject: Remove All Software Generators In-Reply-To: References: Message-ID: Did you try to create your own RAND_METHOD and set it as default on loading the engine? On Wed, Oct 30, 2019 at 5:40 PM Frederick Gotham wrote: > > I'm working on Linux with a x86-64 CPU. > > I have a TPM2 chip, and so I want OpenSSL to do all of its encryption > and random number generation through the TPM2 chip. > > In the event that the chip fails, I do NOT want there to be a backup > system. I do NOT want any kind of software psuedorandom number generator > nor any software encryption routines. > > The engine that I'm using for OpenSSL is "libtpm2tss.so". This engine > library requires two more libraries, "libtss2-tcti-device.so" and > "libtss2-tcti-mssim.so". (The former is for using the TPM2 chip, whereas > the latter is a software simulator). > > As I don't want to have a simulator, I tried simply deleting the > simulator library, but this caused linkage problems for the mother > engine library. As an alternative, I made a new dummy library in which > all of the functions return an error value, and I put this dummy library > in the place of the simulator. This transplant went fine. > > It appears that OpenSSL will kick and scream and refuse to die not > matter how hard you hit it. If I try to generate a random number like > this: > > openssl rand -hex 8 > > Then it seems it will try in this order: > > 1) The TPM2 chip > 2) The software simulator of the TPM2 chip > 3) The built-in RDRAND number > 4) Another one that I can't find > > I have recompiled OpenSSL with the flag OPENSSL_NO_RDRAND to get rid of > the in-built engine. I have even done "rm /dev/random" and "rm > /dev/urandom", but SOME HOW, SOME WAY, I'm still getting output when I > run openssl rand -hex 8. > > How on earth to get OpenSSL to simply give up? I simply cannot have it > use anything other than my TPM2 chip. > > Frederick > > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From cauldwell.thomas at gmail.com Wed Oct 30 15:00:04 2019 From: cauldwell.thomas at gmail.com (Frederick Gotham) Date: Wed, 30 Oct 2019 15:00:04 -0000 (UTC) Subject: Remove All Software Generators References: Message-ID: Dmitry Belyavsky wrote: > Did you try to create your own RAND_METHOD and set it as default on > loading the engine? No, I didn't try that. Note that I'm only using the OpenSSL binary, I'm not interfacing with an API. From beldmit at gmail.com Wed Oct 30 15:05:20 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 30 Oct 2019 18:05:20 +0300 Subject: Remove All Software Generators In-Reply-To: References: Message-ID: On Wed, Oct 30, 2019 at 6:00 PM Frederick Gotham wrote: > Dmitry Belyavsky wrote: > > > Did you try to create your own RAND_METHOD and set it as default on > > loading the engine? > > > No, I didn't try that. > > Note that I'm only using the OpenSSL binary, I'm not interfacing with an > API. > > It can be done via the engine code and config. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From cauldwell.thomas at gmail.com Wed Oct 30 15:08:00 2019 From: cauldwell.thomas at gmail.com (Frederick Gotham) Date: Wed, 30 Oct 2019 15:08:00 -0000 (UTC) Subject: Remove All Software Generators References: Message-ID: Dmitry Belyavsky wrote: >> It can be done via the engine code and config. Do you mean /etc/ssl/openssl.cnf ? From beldmit at gmail.com Wed Oct 30 15:09:12 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 30 Oct 2019 18:09:12 +0300 Subject: Remove All Software Generators In-Reply-To: References: Message-ID: On Wed, Oct 30, 2019 at 6:08 PM Frederick Gotham wrote: > Dmitry Belyavsky wrote: > > > >> It can be done via the engine code and config. > > > Do you mean > > /etc/ssl/openssl.cnf > > ? > Yes, or any custom. But the engine must provide the RAND_METHOD and set it as default. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From cauldwell.thomas at gmail.com Wed Oct 30 15:19:43 2019 From: cauldwell.thomas at gmail.com (Frederick Gotham) Date: Wed, 30 Oct 2019 15:19:43 -0000 (UTC) Subject: Remove All Software Generators References: Message-ID: Dmitry Belyavsky wrote >> /etc/ssl/openssl.cnf > > Yes, or any custom. > But the engine must provide the RAND_METHOD and set it as default. > > But if my TPM2 engine fails to load, then OpenSSL will just use the 'rdrand' engine. So my defense agains this is to rebuild OpenSSL with the flag OPENSSL_NO_RDRAND. After I rebuild OpenSSL, I can then remove my TPM2 engine so that there's no engine at all. I tried running OpenSSL at my commandline just now, and here's what I got: ~# openssl OpenSSL> engine (dynamic) Dynamic engine loading support OpenSSL> rand -hex 10 f49ca711e3056cf9064a OpenSSL> Where is it it getting that random data from ? ? ? There's no engine and yet it can still get a random number! I even tried deleting /dev/random and /dev/urandom, but it somehow is still getting random data from somewhere! But where? From beldmit at gmail.com Wed Oct 30 15:28:32 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 30 Oct 2019 18:28:32 +0300 Subject: Remove All Software Generators In-Reply-To: References: Message-ID: On Wed, Oct 30, 2019 at 6:20 PM Frederick Gotham wrote: > Dmitry Belyavsky wrote > > >> /etc/ssl/openssl.cnf > > > > Yes, or any custom. > > But the engine must provide the RAND_METHOD and set it as default. > > > > > > > > But if my TPM2 engine fails to load, then OpenSSL will just use the > 'rdrand' engine. > > So my defense agains this is to rebuild OpenSSL with the flag > OPENSSL_NO_RDRAND. > It means that you've disabled the RDRAND engine. > After I rebuild OpenSSL, I can then remove my TPM2 engine so that there's > no engine at all. > > I tried running OpenSSL at my commandline just now, and here's what I got: > > ~# openssl > OpenSSL> engine > (dynamic) Dynamic engine loading support > OpenSSL> rand -hex 10 > f49ca711e3056cf9064a > OpenSSL> > > > Where is it it getting that random data from ? ? ? There's no engine and > yet it can still get a random number! I even tried deleting /dev/random > and > /dev/urandom, but it somehow is still getting random data from somewhere! > But where? > > > > You still have the OpenSSL built-in RNG. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From cauldwell.thomas at gmail.com Wed Oct 30 15:35:48 2019 From: cauldwell.thomas at gmail.com (Frederick Gotham) Date: Wed, 30 Oct 2019 15:35:48 -0000 (UTC) Subject: Remove All Software Generators References: Message-ID: Dmitry Belyavsky wrote: >> You still have the OpenSSL built-in RNG. Is there a simple compiler flag to remove this? Or do I need to go into the source code and stick a "return -1;" somewhere? From beldmit at gmail.com Wed Oct 30 15:41:38 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 30 Oct 2019 18:41:38 +0300 Subject: Remove All Software Generators In-Reply-To: References: Message-ID: On Wed, Oct 30, 2019 at 6:39 PM Frederick Gotham wrote: > Dmitry Belyavsky wrote: > > >> You still have the OpenSSL built-in RNG. > > > > Is there a simple compiler flag to remove this? > > Or do I need to go into the source code and stick a "return -1;" somewhere? > > No. Openssl will not work if you do not provide a valid RAND_METHOD except a very minimal set of operations. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From cauldwell.thomas at gmail.com Wed Oct 30 15:55:23 2019 From: cauldwell.thomas at gmail.com (Frederick Gotham) Date: Wed, 30 Oct 2019 15:55:23 -0000 (UTC) Subject: Remove All Software Generators References: Message-ID: Dmitry Belyavsky wrote in news:CADqLbz+JCTu_yQiW9w-fyO0O56MquA2NRi6HELR6pggxQdHHWA at mail.gmail.com: > On Wed, Oct 30, 2019 at 6:39 PM Frederick Gotham > wrote: > >> Dmitry Belyavsky >> wrote: >> >> >> You still have the OpenSSL built-in RNG. >> >> >> >> Is there a simple compiler flag to remove this? >> >> Or do I need to go into the source code and stick a "return -1;" >> somewhere? >> >> No. Openssl will not work if you do not provide a valid RAND_METHOD >> except > a very minimal set of operations. > So I have to go into the source code and do the following? int RAND_bytes(unsigned char *buf, int num) { memset(buf,0,num); return 1; } I can either make this function fail (e.g. call 'abort'), or I can always make it return 0. What do you think? From beldmit at gmail.com Wed Oct 30 16:06:39 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 30 Oct 2019 19:06:39 +0300 Subject: Remove All Software Generators In-Reply-To: References: Message-ID: On Wed, Oct 30, 2019 at 6:58 PM Frederick Gotham wrote: > Dmitry Belyavsky wrote > in > news:CADqLbz+JCTu_yQiW9w-fyO0O56MquA2NRi6HELR6pggxQdHHWA at mail.gmail.com: > > > On Wed, Oct 30, 2019 at 6:39 PM Frederick Gotham > > wrote: > > > >> Dmitry Belyavsky > >> wrote: > >> > >> >> You still have the OpenSSL built-in RNG. > >> > >> > >> > >> Is there a simple compiler flag to remove this? > >> > >> Or do I need to go into the source code and stick a "return -1;" > >> somewhere? > >> > >> No. Openssl will not work if you do not provide a valid RAND_METHOD > >> except > > a very minimal set of operations. > > > > > So I have to go into the source code and do the following? > > int RAND_bytes(unsigned char *buf, int num) > { > memset(buf,0,num); > return 1; > } > > I can either make this function fail (e.g. call 'abort'), or I can always > make it return 0. > > What do you think? > > No. It just makes the RNG unsuitable for any purpose but does not help you. You should do in your engine the following: Implement the TPM-provided RAND_METHOD in the engine call ENGINE_set_RAND for RAND method in the engine bind fuction and write a config file similar to ========= openssl_conf = openssl_def [ openssl_def ] engines = engines_section [ engines_section ] cryptocom = my_section [ my_section ] engine_id = myengine.so default_algorithms = RAND ========= -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From cauldwell.thomas at gmail.com Wed Oct 30 16:14:42 2019 From: cauldwell.thomas at gmail.com (Frederick Gotham) Date: Wed, 30 Oct 2019 16:14:42 -0000 (UTC) Subject: Remove All Software Generators References: Message-ID: Dmitry Belyavsky wrote: > You should do in your engine the following: Just so you know, I'm not a developer of the TPM2 engine for OpenSSL. Of course though I can still go in and edit the code here and there. > Implement the TPM-provided RAND_METHOD in the engine > call ENGINE_set_RAND for RAND method in the engine bind fuction > > and write a config file similar to > Even if I do all that, there is still the possibility that OpenSSL might use its built-in generator (for example if my library fails to load). So it seems I must get the built-in generator to either: 1) Always return 0 2) Call 'abort' From Jochen.Bern at binect.de Wed Oct 30 17:44:43 2019 From: Jochen.Bern at binect.de (Jochen Bern) Date: Wed, 30 Oct 2019 17:44:43 +0000 Subject: Remove All Software Generators In-Reply-To: References: Message-ID: <9bb34afb-f50b-90df-de0e-1dd74648161e@binect.de> On 10/30/2019 04:19 PM, openssl-users-request at openssl.org digested: > From: Frederick Gotham > To: openssl-users at openssl.org > > I even tried deleting /dev/random and /dev/urandom ... don't do that. The Linux kernel is both a provider and a consumer of entropy, e.g., to randomize the TCP sequence numbers as it establishes TCP connections on behalf of applications. Unless you go all the way and add a TPM driver (as the only source of entropy) to *the kernel*, you risk ending up with "good crypto" on the application layer but easily hijacked connections, defeated stack randomization, SSH logins from remote that fail, etc. etc.. Kind regards, -- Jochen Bern Systemingenieur E jochen.bern at binect.de W www.binect.de From cauldwell.thomas at gmail.com Wed Oct 30 18:21:46 2019 From: cauldwell.thomas at gmail.com (Frederick Gotham) Date: Wed, 30 Oct 2019 18:21:46 -0000 (UTC) Subject: Remove All Software Generators References: <9bb34afb-f50b-90df-de0e-1dd74648161e@binect.de> Message-ID: Jochen Bern wrote: > SSH logins from remote that fail This is my exact problem right now. My device has booted up and I can't SSH into it.But this doesn't entirely make sense since it should be getting random numbers from the TPM2 chip anyway. From cauldwell.thomas at gmail.com Wed Oct 30 18:30:44 2019 From: cauldwell.thomas at gmail.com (Frederick Gotham) Date: Wed, 30 Oct 2019 18:30:44 -0000 (UTC) Subject: Remove All Software Generators References: <9bb34afb-f50b-90df-de0e-1dd74648161e@binect.de> Message-ID: Frederick Gotham wrote in news:XnsAAF8BACC24C3Bfgotham at 195.159.176.226: > Jochen Bern > wrote: > >> SSH logins from remote that fail > > > This is my exact problem right now. My device has booted up and I > can't SSH into it.But this doesn't entirely make sense since it should > be getting random numbers from the TPM2 chip anyway. And anyway this behaviour didn't come from deleting /dev/random, but rather from making the default generator inside OpenSSL always give 0 for a random byte. From jb-openssl at wisemo.com Wed Oct 30 18:45:28 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 30 Oct 2019 19:45:28 +0100 Subject: SHA_CTX h0, h1, h2, h3, h4 In-Reply-To: References: Message-ID: <32b1178d-6817-a1df-7af7-fb2ca2827850@wisemo.com> On 30/10/2019 04:04, ratheesh kannoth wrote: > Hi, > > 1. what are these h0....h4 ? > > 2. How are they generated ? > > 3. Could you help to locate code in openssl ? > > typedef struct SHAstate_st { > SHA_LONG h0, h1, h2, h3, h4; > SHA_LONG Nl, Nh; > SHA_LONG data[SHA_LBLOCK]; > unsigned int num; > } SHA_CTX; > > Thanks,, Read the specification of the SHA-1 algorithm (either in the FIPS 180-1 standard or in a textbook). 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 cauldwell.thomas at gmail.com Thu Oct 31 07:48:29 2019 From: cauldwell.thomas at gmail.com (Frederick Gotham) Date: Thu, 31 Oct 2019 07:48:29 -0000 (UTC) Subject: Remove All Software Generators References: <9bb34afb-f50b-90df-de0e-1dd74648161e@binect.de> Message-ID: Frederick Gotham wrote: > > And anyway this behaviour didn't come from deleting /dev/random, but > rather from making the default generator inside OpenSSL always give 0 > for a random byte. I will change the random number generator built into OpenSSL to always return sequential numbers, something like: { static char unsigned val = 0; while ( num-- ) *buff++ = val++; } This shouldn't break anything. Then if ever I am in doubt about where a random number came from, I just check to see if it's something like 0102030405. From cauldwell.thomas at gmail.com Thu Oct 31 08:06:22 2019 From: cauldwell.thomas at gmail.com (Frederick Gotham) Date: Thu, 31 Oct 2019 08:06:22 -0000 (UTC) Subject: Remove All Software Generators References: <9bb34afb-f50b-90df-de0e-1dd74648161e@binect.de> Message-ID: Frederick Gotham wrote: > > I will change the random number generator built into OpenSSL to always > return sequential numbers, something like: Here's what I have: static int drbg_bytes(unsigned char *out, int count) { int const retval = drbg_bytes_REAL(out, count); /* Try to get a semi-unique value for the first byte */ char unsigned rotating_value = (unsigned)out ^ ((unsigned)count << 4u); while ( count-- ) *out++ = rotating_value++; return retval; } From cauldwell.thomas at gmail.com Thu Oct 31 10:12:03 2019 From: cauldwell.thomas at gmail.com (Frederick Gotham) Date: Thu, 31 Oct 2019 10:12:03 -0000 (UTC) Subject: Remove All Software Generators References: <9bb34afb-f50b-90df-de0e-1dd74648161e@binect.de> Message-ID: Frederick Gotham wrote: > static int drbg_bytes(unsigned char *out, int count) > { > int const retval = drbg_bytes_REAL(out, count); > > /* Try to get a semi-unique value for the first byte */ > char unsigned rotating_value = (unsigned)out ^ ((unsigned)count << > 4u); > > while ( count-- ) > *out++ = rotating_value++; > > return retval; > } Ugh........ This doesn't work either. It fails to boot up when it tries to generate keys for SSH. Next I'll try to make every nibble sequential -- instead of just every byte. From space.ship.traveller at gmail.com Thu Oct 31 11:59:59 2019 From: space.ship.traveller at gmail.com (Samuel Williams) Date: Fri, 1 Nov 2019 00:59:59 +1300 Subject: Digest algorithms for Ruby Message-ID: I am maintaining the OpenSSL bindings for Ruby, and I'm considering exposing SHA3 and BLAKE digests. In addition, for the first time, I wrote some tests to test ALL algorithms we expose, and found that "DSS", "DSS1" and "SHA" no longer exist. I'm going to assume this algorithm is removed because it's old and/or insecure. But I would like to seek some clarification on this because it represents a breaking change in semantic versioning, to the extent that we exposed these digests explicitly. So: - Did they exist? - When did they stop existing? - Are they still relevant? Kind regards, Samuel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Oct 31 13:04:06 2019 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 31 Oct 2019 13:04:06 +0000 Subject: Remove All Software Generators In-Reply-To: References: <9bb34afb-f50b-90df-de0e-1dd74648161e@binect.de> Message-ID: <8223FBE3-7318-4EB4-A673-532C43EBD052@akamai.com> Why not just change things so that if your module fails to load, the library exits? Don't change the RAND code, change the INIT code. From openssl-users at dukhovni.org Thu Oct 31 14:35:05 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 31 Oct 2019 10:35:05 -0400 Subject: Digest algorithms for Ruby In-Reply-To: References: Message-ID: <167EC78D-8587-4CE2-9B24-DB454B8E7490@dukhovni.org> > On Oct 31, 2019, at 7:59 AM, Samuel Williams wrote: > > I am maintaining the OpenSSL bindings for Ruby, and I'm considering exposing SHA3 and BLAKE digests. > > In addition, for the first time, I wrote some tests to test ALL algorithms we expose, and found that "DSS", "DSS1" and "SHA" no longer exist. > > I'm going to assume this algorithm is removed because it's old and/or insecure. But I would like to seek some clarification on this because it represents a breaking change in semantic versioning, to the extent that we exposed these digests explicitly. My advice would be to avoid specific support for any *particular* digest algorithm. Instead, provide bindings to: - EVP_get_digestbyname(), - EVP_MD_CTX_create(3), - EVP_DigestInit_ex(3), - EVP_DigestUpdate(3), - EVP_DigestFinal_ex(3), - EVP_MD_CTX_destroy(3) which can they use *any* available digest algorithm (by name). -- Viktor. From Tobias.Wolf at t-systems.com Thu Oct 31 15:01:18 2019 From: Tobias.Wolf at t-systems.com (Tobias.Wolf at t-systems.com) Date: Thu, 31 Oct 2019 15:01:18 +0000 Subject: get serialnumber from X509_REQ Message-ID: How can I get the serialnumber from X509_REQ pointer. I saw in the code that there is no getter function? Regard Tobi -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Thu Oct 31 16:24:15 2019 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 31 Oct 2019 17:24:15 +0100 Subject: Remove All Software Generators In-Reply-To: References: Message-ID: <20191031162414.GA7175@roeckx.be> On Wed, Oct 30, 2019 at 02:12:19PM -0000, Frederick Gotham wrote: > > It appears that OpenSSL will kick and scream and refuse to die not > matter how hard you hit it. If I try to generate a random number like > this: > > openssl rand -hex 8 > > Then it seems it will try in this order: > > 1) The TPM2 chip > 2) The software simulator of the TPM2 chip > 3) The built-in RDRAND number > 4) Another one that I can't find Which version of OpenSSL are you using? > I have recompiled OpenSSL with the flag OPENSSL_NO_RDRAND to get rid of > the in-built engine. I have even done "rm /dev/random" and "rm > /dev/urandom", but SOME HOW, SOME WAY, I'm still getting output when I > run openssl rand -hex 8. Depending on the version of OpenSSL and the kernel, you might also use the getentropy()/getrandom() cal. Since 1.1.0 we Configure supports the --with-rand-seed=none option. Kurt From matt at openssl.org Thu Oct 31 17:56:25 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 31 Oct 2019 17:56:25 +0000 Subject: Digest algorithms for Ruby In-Reply-To: References: Message-ID: On 31/10/2019 11:59, Samuel Williams wrote: > I am maintaining the OpenSSL bindings for Ruby, and I'm considering > exposing SHA3 and BLAKE digests. > > In addition, for the first time, I wrote some tests to test ALL > algorithms we expose, and found that "DSS", "DSS1" and "SHA" no longer > exist. > > I'm going to assume this algorithm is removed because it's old and/or > insecure. But I would like to seek some clarification on this because it > represents a breaking change in semantic versioning, to the extent that > we exposed these digests explicitly. > > So: > > - Did they exist? Yes, they did exist. EVP_sha() (aka SHA0) and EVP_dss() (aka DSS0) were removed by commit 474e469bb. It had this commit description: commit 474e469bbd056aebcf7e7d3207ef820f2faed4ce Author: Rich Salz AuthorDate: Tue Jan 27 12:34:45 2015 -0500 Commit: Rich Salz CommitDate: Tue Jan 27 12:34:45 2015 -0500 OPENSSL_NO_xxx cleanup: SHA Remove support for SHA0 and DSS0 (they were broken), and remove the ability to attempt to build without SHA (it didn't work). For simplicity, remove the option of not building various SHA algorithms; you could argue that SHA_224/256/384/512 should be kept, since they're like crypto algorithms, but I decided to go the other way. So these options are gone: GENUINE_DSA OPENSSL_NO_SHA0 OPENSSL_NO_SHA OPENSSL_NO_SHA1 OPENSSL_NO_SHA224 OPENSSL_NO_SHA256 OPENSSL_NO_SHA384 OPENSSL_NO_SHA512 Reviewed-by: Richard Levitte EVP_dss1() was removed by commit 7f572e958b with this commit description: commit 7f572e958b13041056f377a62d3219633cfb1e8a Author: Dr. Stephen Henson AuthorDate: Wed Dec 2 13:57:04 2015 +0000 Commit: Dr. Stephen Henson CommitDate: Wed Dec 2 17:52:01 2015 +0000 Remove legacy sign/verify from EVP_MD. Remove sign/verify and required_pkey_type fields of EVP_MD: these are a legacy from when digests were linked to public key types. All signing is now handled by the corresponding EVP_PKEY_METHOD. Only allow supported digest types in RSA EVP_PKEY_METHOD: other algorithms already block unsupported types. Remove now obsolete EVP_dss1() and EVP_ecdsa(). Reviewed-by: Richard Levitte > - When did they stop existing? The first release that contained the above commits was OpenSSL 1.1.0. That was a major release that did not claim backwards source compatibility. Most notably because of the structures becoming opaque, but it did impact some other areas too. > - Are they still relevant? Since 1.1.0 has been around for nearly 4 years now, and this is the first time I recall anyone ever noticing this, I would say "No".