From ceo at teo-en-ming-corp.com Sun Mar 1 07:11:36 2020 From: ceo at teo-en-ming-corp.com (Turritopsis Dohrnii Teo En Ming) Date: Sun, 1 Mar 2020 07:11:36 +0000 Subject: Enabling SSL Virtual Hosts on Apache Web Server and Installing Free SSL Certificates on CentOS Web Panel Web Hosting Control Panel Message-ID: Subject: Enabling SSL Virtual Hosts on Apache Web Server and Installing Free SSL Certificates on CentOS Web Panel Web Hosting Control Panel Author: Mr. Turritopsis Dohrnii Teo En Ming, Singapore Date: 1st Mar 2020, Sunday EXTREMELY DETAILED INSTRUCTIONS OF TEO EN MING'S GUIDE ====================================================== Login to CentOS Web Panel admin interface. >From the left menu, click WebServer Settings, then click SSL Certificates. Click the AutoSSL [FREE] tab. User: enming Domain: teo-en-ming.com Check all items in Additional Services. Click Install SSL. Click the Configure tab. Activate Alerts. Activate Auto Renovations. Activate Automatic SSL generation. Click Save. Click the AutoSSL [FREE] tab. User: tocsg Domain: theonlinecitizens.com Check all items in Additional Services. Click Install SSL. Click Logout. AutoSSL generation uses Let's Encrypt Free SSL/TLS Certificates. REFERENCE ========= Guide: Enable AutoSSL In CentOS Web Panel Link: https://www.hostwinds.com/guide/cwp-auto-ssl/ -----BEGIN EMAIL SIGNATURE----- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html ******************************************************************************************** Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -----END EMAIL SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From eureka6676 at gmail.com Sun Mar 1 07:51:00 2020 From: eureka6676 at gmail.com (Rafael Ferrer) Date: Sun, 1 Mar 2020 15:51:00 +0800 Subject: Naming of methods in RSA_METHOD In-Reply-To: References: Message-ID: So I went back to this and I think the problem is we are forced to create a RSA_private_encrypt function even if all we want to do is sign. https://github.com/openssl/openssl/blob/master/crypto/rsa/rsa_pmeth.c#L184 That branch gets hit on doing a TLS connection but not on creating a certificate. Ideally, shouldn't RSA_PKCS1_PSS_PADDING (and the other padding mode) also be handled by the RSA_sign of the engine implementation? I mean it is inside a function called pkey_rsa_sign. Though the RSA_sign function signature doesn't seem to allow specifying the padding. From eureka6676 at gmail.com Sun Mar 1 08:11:54 2020 From: eureka6676 at gmail.com (Rafael Ferrer) Date: Sun, 1 Mar 2020 16:11:54 +0800 Subject: Naming of methods in RSA_METHOD In-Reply-To: References: Message-ID: <41b01dad-abb1-661d-62e1-688c6ec0692b@gmail.com> > Though the RSA_sign function signature doesn't seem to allow specifying the padding. Sorry I meant the hashing algorithm. From phani2004 at gmail.com Mon Mar 2 07:54:28 2020 From: phani2004 at gmail.com (Phani 2004) Date: Mon, 2 Mar 2020 13:24:28 +0530 Subject: aes_cbc_hmac_sha1 implementation In-Reply-To: References: <42e06df6-ca34-38de-b481-3b67776c0614@openssl.org> <8234c622-e1a1-40b0-be44-7ced7a5c47d6@redhat.com> <13810e4f-b374-20c8-2732-31eff4d17518@openssl.org> Message-ID: Hi Team, Can anyone help me with the below queries. Thanks in Advance. Regards Phani On Fri, Feb 28, 2020 at 2:41 PM Phani 2004 wrote: > OK. I understood that "AES-128-CBC-HMAC-SHA1"(aesni_cbc_hmac_sha1) always > does mte. > I am trying to implement engine implementation of combined mode cipher > aes_cbc_hmac_sha1. > So in my aes_cbc_hmac_sha1_cipher implementation should i do mte only? > > If hardware engine can do both operations in a single request and save > time. Also, say there is a flag which indicates whether its mte or etm. > How should my aes_cbc_hmac_sha1 implementation look like? > Should it do only mte always? Should i have two ciphers, one for etm and > other for mte. > But how to i tell openssl to use this cipher for etm and other for mte > without changing the openssl code. > > One more query i have is, how do we pass the etm option to the openssl in > conf file. > > Regards > Phani > > On Fri, Feb 28, 2020 at 8:53 AM Matt Caswell wrote: > >> >> >> On 27/02/2020 18:30, Phani 2004 wrote: >> > Thanks for the reply. >> > >> > In ssl_get_evp_cipher api when etm flag is enabled the >> > aesni_cbc_hmac_sha1_cipher is not used. In this cipher only it >> > implements mte. This part is not clear to me? Support I implement one >> > cipher func which needs to handle both etm as well as mte, at the cipher >> > api level how do I know if we have etm extension enabled or not. >> >> At the engine level all it knows about are ciphers and hashes. Engines >> know nothing about TLS ciphersuites or TLS extensions. Your engine will >> not know whether etm or mte is in use. libssl makes the decision about >> what cipher it is going to ask the engine for based on what has been >> negotiated. >> >> If mte is in use then it will first look to see if it has an >> implementation of "AES-128-CBC-HMAC-SHA1" (of which >> aesni_cbc_hmac_sha1_cipher is the built-in implementation). >> >> If that is not available it will look for individual implementations of >> "AES-128" and "SHA1". >> >> If etm is in use it will just look for individual implementations of >> "AES-128" and "SHA1". >> >> Matt >> >> >> >> > >> > Regards >> > Phani >> > >> > On Wed, 26 Feb, 2020, 6:03 PM Hubert Kario, > > > wrote: >> > >> > On Wednesday, 26 February 2020 08:59:01 CET, Phani 2004 wrote: >> > > Thanks for the quick response Matt. >> > > >> > > My command was : >> > > openssl s_client -connect 10.29.20.26 -cipher ECDHE-RSA-AES128-SHA >> > -tls1_2. >> > > I did not realise that "2" was not copied. >> > > >> > > I am trying to implement combined algo support on our engine. >> > > I am using the openssl s_server and s_client apps to validate my >> > > implementation. >> > > The combined algo that i am looking to implement is AES128/256 and >> > SHA1. >> > > Its clear that i should always use tls version less than 1.3 >> > otherwise GCM >> > > ciphers are used. >> > > >> > > What cipher suites can i use to validate the above combination of >> > combined >> > > algo? >> > >> > OpenSSL internally treats key exchange and symmetric cipher >> > separately, so >> > all "*AES128-SHA" ciphers use the same cipher backend >> > >> > you should also test AES256-SHA, AES128-SHA256, AES256-SHA256 and >> > AES256-SHA384 >> > >> > > Which tls versions support which cipher suites? >> > >> > *-SHA1 and *MD5 is supported by everything between SSL3 and TLS 1.2 >> > *-SHA256 and *-SHA384 (if they are not TLS1.3 cipher suites) are >> > supported >> > by TLS 1.2 only >> > >> > > Should i be doing "encrypt-then-mac" or "mac-then-encrypt" in my >> > > implementation? >> > > Does the cipher suite decide this? >> > > If yes, what are the ciphers which do "encrypt-then-mac" and what >> > ciphers >> > > to "mac-then-encrypt"? >> > >> > etm vs mte happens based on negotiated extension, not cipher suite >> > >> > -- >> > Regards, >> > Hubert Kario >> > Senior Quality Engineer, QE BaseOS Security team >> > Web: www.cz.redhat.com >> > Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shivakumar2696 at gmail.com Mon Mar 2 08:18:20 2020 From: shivakumar2696 at gmail.com (shiva kumar) Date: Mon, 2 Mar 2020 13:48:20 +0530 Subject: certificate verification error OpenSSL 1.1.1 Message-ID: when I tried to verify the the self signed certificate in OpenSSL 1.0.2 it is giving error 18 and gives OK as o/p, when I tried the same with OpenSSL 1.1.1 there is slight change in the behavior it also gives the same error, but instead of OK it gives different error as "*ca.crt: verification failed*" as follows. *in OpenSSL 1.0.2* openssl verify ./ca.crt *error 18* at 0 depth lookup:self signed certificate *OK* *in OpenSSL 1.1.1 * openssl verify ./ca.crt *error 18* at 0 depth lookup:self signed certificate *error /tmp/1.1/conf/ssl.crt/ca.crt: verification failed* # echo $? 2 why I'm getting this error? is this an expected behavior in OpenSSL 1.1.1? Please answer my question. -- *With Best Regards* *Shivakumar S* -------------- next part -------------- An HTML attachment was scrubbed... URL: From shivakumar2696 at gmail.com Mon Mar 2 09:00:32 2020 From: shivakumar2696 at gmail.com (shiva kumar) Date: Mon, 2 Mar 2020 14:30:32 +0530 Subject: certificate verification error OpenSSL 1.1.1 In-Reply-To: References: Message-ID: Hi, Please help me, is this an expected behavior? On Mon, Mar 2, 2020 at 1:48 PM shiva kumar wrote: > when I tried to verify the the self signed certificate in OpenSSL 1.0.2 it > is giving error 18 and gives OK as o/p, when I tried the same with OpenSSL > 1.1.1 there is slight change in the behavior it also gives the same error, > but instead of OK it gives different error as "*ca.crt: verification > failed*" as follows. > > > > *in OpenSSL 1.0.2* > > openssl verify ./ca.crt > > *error 18* at 0 depth lookup:self signed certificate > > *OK* > > > *in OpenSSL 1.1.1 * > > openssl verify ./ca.crt > > *error 18* at 0 depth lookup:self signed certificate > > *error /tmp/1.1/conf/ssl.crt/ca.crt: verification failed* > > # echo $? > > 2 > > > why I'm getting this error? is this an expected behavior in OpenSSL 1.1.1? > > Please answer my question. > > > > > -- > *With Best Regards* > *Shivakumar S* > -- *With Best Regards* *Shivakumar S* -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Mon Mar 2 09:06:32 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 2 Mar 2020 12:06:32 +0300 Subject: certificate verification error OpenSSL 1.1.1 In-Reply-To: References: Message-ID: First, I recommend you not to hurry up :) Second, the validation procedures have changed between 1.0.2 and 1.1.1, 1.1.1 checks more strictly. E.g., a self-signed certificate without "CA:TRUE" will be treated as valid CA cert in 1.0.2 but not valid in 1.1.1 On Mon, Mar 2, 2020 at 12:01 PM shiva kumar wrote: > Hi, > Please help me, is this an expected behavior? > > On Mon, Mar 2, 2020 at 1:48 PM shiva kumar > wrote: > >> when I tried to verify the the self signed certificate in OpenSSL 1.0.2 >> it is giving error 18 and gives OK as o/p, when I tried the same with >> OpenSSL 1.1.1 there is slight change in the behavior it also gives the >> same error, but instead of OK it gives different error as "*ca.crt: >> verification failed*" as follows. >> >> >> >> *in OpenSSL 1.0.2* >> >> openssl verify ./ca.crt >> >> *error 18* at 0 depth lookup:self signed certificate >> >> *OK* >> >> >> *in OpenSSL 1.1.1 * >> >> openssl verify ./ca.crt >> >> *error 18* at 0 depth lookup:self signed certificate >> >> *error /tmp/1.1/conf/ssl.crt/ca.crt: verification failed* >> >> # echo $? >> >> 2 >> >> >> why I'm getting this error? is this an expected behavior in OpenSSL 1.1.1? >> >> Please answer my question. >> >> >> >> >> -- >> *With Best Regards* >> *Shivakumar S* >> > > > -- > *With Best Regards* > *Shivakumar S* > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Mar 2 10:11:26 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 2 Mar 2020 10:11:26 +0000 Subject: aes_cbc_hmac_sha1 implementation In-Reply-To: References: <42e06df6-ca34-38de-b481-3b67776c0614@openssl.org> <8234c622-e1a1-40b0-be44-7ced7a5c47d6@redhat.com> <13810e4f-b374-20c8-2732-31eff4d17518@openssl.org> Message-ID: <137e2de2-28bb-73a1-70c2-49a413b97b80@openssl.org> On 28/02/2020 09:11, Phani 2004 wrote: > OK. I understood that "AES-128-CBC-HMAC-SHA1"(aesni_cbc_hmac_sha1) > always does mte. > I am trying to implement engine implementation of combined mode cipher > aes_cbc_hmac_sha1. > So in my aes_cbc_hmac_sha1_cipher implementation should i do mte only? Yes. > If hardware engine can do both operations in a single request and save > time. Also, say there is a flag which indicates whether its mte or etm. > How should my aes_cbc_hmac_sha1 implementation look like? That cipher only does mte. > Should it do only mte always? Should i have two ciphers, one for etm and > other for mte. > But how to i tell openssl to use this cipher for etm and other for mte > without changing?the openssl code. If you want to support etm you have to implement aes-cbc and sha1 separately. > > One more query i have is, how do we pass the etm option to the openssl > in conf file. etm will be negotiated by default if it is available - there is no need to configure this. You can disable etm using the "EncryptThenMac" option, e.g. Options = -EncryptThenMac See: https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html Matt > > Regards > Phani > > On Fri, Feb 28, 2020 at 8:53 AM Matt Caswell > wrote: > > > > On 27/02/2020 18:30, Phani 2004 wrote: > > Thanks for the?reply. > > > > In ssl_get_evp_cipher api when etm flag is enabled the > > aesni_cbc_hmac_sha1_cipher is not used. In this cipher only it > > implements mte. This part is not clear to me? Support I implement one > > cipher func which needs to handle both etm as well as mte, at the > cipher > > api level how do I know if we have etm extension enabled or not. > > At the engine level all it knows about are ciphers and hashes. Engines > know nothing about TLS ciphersuites or TLS extensions. Your engine will > not know whether etm or mte is in use. libssl makes the decision about > what cipher it is going to ask the engine for based on what has been > negotiated. > > If mte is in use then it will first look to see if it has an > implementation of "AES-128-CBC-HMAC-SHA1" (of which > aesni_cbc_hmac_sha1_cipher is the built-in implementation). > > If that is not available it will look for individual implementations of > "AES-128" and "SHA1". > > If etm is in use it will just look for individual implementations of > "AES-128" and "SHA1". > > Matt > > > > > > > Regards > > Phani > > > > On Wed, 26 Feb, 2020, 6:03 PM Hubert Kario, > > >> wrote: > > > >? ? ?On Wednesday, 26 February 2020 08:59:01 CET, Phani 2004 wrote: > >? ? ?> Thanks for the quick response Matt. > >? ? ?> > >? ? ?> My command was : > >? ? ?> openssl s_client -connect 10.29.20.26 -cipher > ECDHE-RSA-AES128-SHA > >? ? ?-tls1_2. > >? ? ?> I did not realise that "2" was not copied. > >? ? ?> > >? ? ?> I am trying to implement combined algo support on our engine. > >? ? ?> I am using the openssl s_server and s_client apps to validate my > >? ? ?> implementation. > >? ? ?> The combined algo that i am looking to implement is > AES128/256 and > >? ? ?SHA1. > >? ? ?> Its clear that i should always use tls version less than 1.3 > >? ? ?otherwise GCM > >? ? ?> ciphers are used. > >? ? ?> > >? ? ?> What cipher suites can i use to validate the above > combination of > >? ? ?combined > >? ? ?> algo? > > > >? ? ?OpenSSL internally treats key exchange and symmetric cipher > >? ? ?separately, so > >? ? ?all "*AES128-SHA" ciphers use the same cipher backend > > > >? ? ?you should also test AES256-SHA, AES128-SHA256, AES256-SHA256 and > >? ? ?AES256-SHA384 > > > >? ? ?> Which tls versions support which cipher suites? > > > >? ? ?*-SHA1 and *MD5 is supported by everything between SSL3 and > TLS 1.2 > >? ? ?*-SHA256 and *-SHA384 (if they are not TLS1.3 cipher suites) are > >? ? ?supported > >? ? ?by TLS 1.2 only > > > >? ? ?> Should i be doing "encrypt-then-mac" or "mac-then-encrypt" in my > >? ? ?> implementation? > >? ? ?> Does the cipher suite decide this? > >? ? ?> If yes, what are the ciphers which do "encrypt-then-mac" and > what > >? ? ?ciphers > >? ? ?> to "mac-then-encrypt"? > > > >? ? ?etm vs mte happens based on negotiated extension, not cipher suite > > > >? ? ?-- > >? ? ?Regards, > >? ? ?Hubert Kario > >? ? ?Senior Quality Engineer, QE BaseOS Security team > >? ? ?Web: www.cz.redhat.com > > >? ? ?Red Hat Czech s.r.o., Purky?ova 115, 612 00? Brno, Czech Republic > > > From kevin.lengauer at adnovum.ch Mon Mar 2 11:03:14 2020 From: kevin.lengauer at adnovum.ch (K Lengauer) Date: Mon, 2 Mar 2020 04:03:14 -0700 (MST) Subject: Problems porting Openssl 1.1.1d to zos. In-Reply-To: <9f376311-0608-c59b-cdf4-ff92a8b26cff@tibco.com> References: <9f376311-0608-c59b-cdf4-ff92a8b26cff@tibco.com> Message-ID: <1583146994563-0.post@n7.nabble.com> Dear all, I stumbled across this mails when looking for information regarding OpenSSL on zOS. Currently, I am working on getting OpenSSL 1.1.1c running on zOS. So far I created my own config "target" inside 10-main.conf based on the old configuration that was used pre OpenSSL 1.1.0. Still, I was not able to get that far yet and was wondering how you proceeded regarding this issue? Apart from some github issues and the likes regarding EBCDIC patches I was unable to find much advice on how to configure the build and how to tackle common issues. One config target for zOS OS390 was created a while back but then removed again from OpenSSL 1.1.1. With my config target I made it to the compile step but still face build issues. Reaching a complete build like Wendell Nichols would already by a great step. Are any of you aware of zOS specific OpenSSL development branches that I have yet to find? Or is this mainly done in private repositories/branches and not offered for PRs to the OpenSSL repository? Any advice is greatly appreciated. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From Irina.Ilina-Sidorova at ulb.ac.be Mon Mar 2 11:28:18 2020 From: Irina.Ilina-Sidorova at ulb.ac.be (iilinasi) Date: Mon, 02 Mar 2020 12:28:18 +0100 Subject: OpenSSL reports wrong TLS version to FreeRADIUS Message-ID: <953ab89f22097fcb53ede1b9f60d7a9c@imapproxy.vub.ac.be> Dear everyone, I'm looking for your pointers to help me to debug&solve the issue I have. I try to implement an auth exchange with the RADIUS, requesting EAP-TLS. At this moment I only need to get to the phase when server responds with Access-Challenge with server certificate (so, 2 packets from NAD and 2 from the server). To generate NAD-side packets I use python3 with scapy. Freeradius (3.0.16, 3.0.20) was set up to use EAP-TLS for test user auth. First access-request from the NAD side is responded with Access-Challenge from the server. So far so good. But when I send the second packet, I receive an Access-Reject. Suprisingly, the server reports I'm using unsupported TLS version ?0304? (which corresponds to TLS1.3). Why "surprizingly"? Well, because I use earlier TLS version, and it is well visible (AVP "Eap-Message" - EAP section - TLS part has "0301", that corresponds to TLS1.0, handshake version also set to TLS1.0 (0x0301)). I also checked in Wireshark (captured both on the server machine and "NAD" machine - same results) - the packet is correctly dissected by latest wireshark (no errors reported) and has TLS1.0 inside. OpenSSL is already at the newest version (1.1.1-1ubuntu2.1~18.04.5). After a discussion in freeradius maillist, I got to know that freeradius receives all the TLS-related information from the OpenSSL. I attach the packet exchange for the reference, the packet in question is packet#3. I'd like to understand, how does OpenSSL get to the idea of "0304" version, if there is no such a byte sequence in the packet... My question is: how OpenSSL determines the TLS version? How to debug it? -- Have a great day! Irina Ilina-Sidorova -------------- next part -------------- A non-text attachment was scrubbed... Name: test.pcapng Type: application/octet-stream Size: 996 bytes Desc: not available URL: From matt at openssl.org Mon Mar 2 13:17:08 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 2 Mar 2020 13:17:08 +0000 Subject: OpenSSL reports wrong TLS version to FreeRADIUS In-Reply-To: <953ab89f22097fcb53ede1b9f60d7a9c@imapproxy.vub.ac.be> References: <953ab89f22097fcb53ede1b9f60d7a9c@imapproxy.vub.ac.be> Message-ID: <00ebef0a-8a09-7c34-e677-4b432950f503@openssl.org> On 02/03/2020 11:28, iilinasi wrote: > I'd like to understand, how does OpenSSL get to the idea of "0304" > version, if there is no such a byte sequence in the packet... > My question is: how OpenSSL determines the TLS version? How to debug it? > Very strange. I have no idea. Looking at the packet in question this does appear to be a straight forward TLSv1.0 ClientHello. TLSv1.3 would normally only ever be negotiated if the supported_versions extension is present, and that extension lists 0304 as one of the supported versions. But since the extension does not exist in the ClientHello it should be attempting to use TLSv1.3. > > Suprisingly, the server reports I'm using unsupported TLS version ?0304? > (which corresponds to TLS1.3). Is there any more detail around this? Server logs etc? Matt From alfred at ccac.rwth-aachen.de Mon Mar 2 13:15:41 2020 From: alfred at ccac.rwth-aachen.de (Alfred Arnold) Date: Mon, 2 Mar 2020 14:15:41 +0100 (CET) Subject: OpenSSL reports wrong TLS version to FreeRADIUS In-Reply-To: <953ab89f22097fcb53ede1b9f60d7a9c@imapproxy.vub.ac.be> References: <953ab89f22097fcb53ede1b9f60d7a9c@imapproxy.vub.ac.be> Message-ID: Hi, >I'd like to understand, how does OpenSSL get to the idea of "0304" >version, if there is no such a >byte sequence in the packet... >My question is: how OpenSSL determines the TLS version? How to debug it? I don't see any TLS 1.3 in the capture as well, but I see that your client is using only outdated (if not to say: historic) cryptographic algorithms: RC4, RC2 (never seen that in practice!), 3DES and DES. And those even combined with export options to weaken key strength. Many modern servers are configured to disallow such outdated crypto: make your client use at least - AES128/256 (either in CBC or GCM mode) - TLS 1.2 - no export cipher suites Then you might get a more positive reply from the server... Best regards Alfred Arnold -- Alfred Arnold E-Mail: alfred at ccac.rwth-aachen.de Computer Club at the http://john.ccac.rwth-aachen.de:8000/alf/ Technical University Phone: +49-241-406526 of Aachen From kaushalshriyan at gmail.com Tue Mar 3 04:05:26 2020 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Tue, 3 Mar 2020 09:35:26 +0530 Subject: Suggest strong cipher suites Message-ID: Hi, We are using the Nginx Web server on CentOS Linux release 7.7.1908 (Core). *OpenSSL Version* #openssl version OpenSSL 1.0.2k-fips 26 Jan 2017 # *Nginx Version* #rpm -qa | grep nginx nginx-1.16.1-1.el7.x86_64 # Can someone please suggest me to use strong cipher suites for SSL/TLS encryption. Thanks in advance and I look forward to hearing from you. Best Regards, Kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaushalshriyan at gmail.com Tue Mar 3 05:39:00 2020 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Tue, 3 Mar 2020 11:09:00 +0530 Subject: Openssl version question Message-ID: Hi, I am curious to know regarding *k* in 1.0.2k-fips, *d* in 1.1.1d, *l* in 1.1.0l and *u* in 1.0.2u. What does this alphabet mean? Best Regards, Kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: From shivakumar2696 at gmail.com Tue Mar 3 06:06:35 2020 From: shivakumar2696 at gmail.com (shiva kumar) Date: Tue, 3 Mar 2020 11:36:35 +0530 Subject: certificate verification error OpenSSL 1.1.1 In-Reply-To: References: Message-ID: Hi, can you please tell me more about 1) How to verify a self signed (.crt) key in OpenSSL 1.1.1? 2) Is key generated by OpenSSL 1.0.2 can be used to connect with OpenSSL 1.1.1 and vice versa? Thanks and regards Shivakumar On Mon, Mar 2, 2020 at 2:36 PM Dmitry Belyavsky wrote: > First, I recommend you not to hurry up :) > > Second, the validation procedures have changed between 1.0.2 and 1.1.1, > 1.1.1 checks more strictly. > E.g., a self-signed certificate without "CA:TRUE" will be treated as valid > CA cert in 1.0.2 but not valid in 1.1.1 > > > > On Mon, Mar 2, 2020 at 12:01 PM shiva kumar > wrote: > >> Hi, >> Please help me, is this an expected behavior? >> >> On Mon, Mar 2, 2020 at 1:48 PM shiva kumar >> wrote: >> >>> when I tried to verify the the self signed certificate in OpenSSL 1.0.2 >>> it is giving error 18 and gives OK as o/p, when I tried the same with >>> OpenSSL 1.1.1 there is slight change in the behavior it also gives the >>> same error, but instead of OK it gives different error as "*ca.crt: >>> verification failed*" as follows. >>> >>> >>> >>> *in OpenSSL 1.0.2* >>> >>> openssl verify ./ca.crt >>> >>> *error 18* at 0 depth lookup:self signed certificate >>> >>> *OK* >>> >>> >>> *in OpenSSL 1.1.1 * >>> >>> openssl verify ./ca.crt >>> >>> *error 18* at 0 depth lookup:self signed certificate >>> >>> *error /tmp/1.1/conf/ssl.crt/ca.crt: verification failed* >>> >>> # echo $? >>> >>> 2 >>> >>> >>> why I'm getting this error? is this an expected behavior in OpenSSL >>> 1.1.1? >>> >>> Please answer my question. >>> >>> >>> >>> >>> -- >>> *With Best Regards* >>> *Shivakumar S* >>> >> >> >> -- >> *With Best Regards* >> *Shivakumar S* >> > > > -- > SY, Dmitry Belyavsky > -- *With Best Regards* *Shivakumar S* -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Tue Mar 3 06:18:07 2020 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Tue, 3 Mar 2020 07:18:07 +0100 Subject: Openssl version question In-Reply-To: References: Message-ID: You can read details about current OpenSSL versioning at https://wiki.openssl.org/index.php/Versioning Going forward with the upcoming 3.0.0 release, the versioning scheme will change to a more contemporary format. You can read about it at https://www.openssl.org/policies/releasestrat.html Best regards, Nicola Tuveri On Tue, Mar 3, 2020, 06:39 Kaushal Shriyan wrote: > Hi, > > I am curious to know regarding *k* in 1.0.2k-fips, *d* in 1.1.1d, *l* in > 1.1.0l and *u* in 1.0.2u. What does this alphabet mean? > > Best Regards, > > Kaushal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phani2004 at gmail.com Tue Mar 3 06:46:55 2020 From: phani2004 at gmail.com (Phani 2004) Date: Tue, 3 Mar 2020 12:16:55 +0530 Subject: Which RFC explains how the mac-then-encrypt needs to be implemented Message-ID: Hi Team, I am trying to implement mac-then-encrypt for aes_cbc_hmac_sha1 combined cipher. From the code i could understand that the first 16 bytes were being used as explicit IV while decrypting and the hmac is done for 13 bye AAD and 16 byte Fin record in finish message. Which RFC/section explains this in detail? Regards Phani -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Mar 3 07:02:17 2020 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 3 Mar 2020 08:02:17 +0100 Subject: Which RFC explains how the mac-then-encrypt needs to be implemented In-Reply-To: References: Message-ID: On 2020-03-03 07:46, Phani 2004 wrote: > Hi Team, > > I am trying to implement mac-then-encrypt for aes_cbc_hmac_sha1 > combined cipher. From the code i could understand that the first 16 > bytes were being used as explicit IV while decrypting and the hmac is > done for 13 bye AAD and 16 byte Fin record in finish message. > > Which RFC/section explains?this in detail? > > For TLS 1.2, this is RFC5246 Section 6.2.3.2 Note that each version of TLS makes arbitrary changes to the record encryption. 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 openssl-users at dukhovni.org Tue Mar 3 07:19:34 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 3 Mar 2020 02:19:34 -0500 Subject: certificate verification error OpenSSL 1.1.1 In-Reply-To: References: Message-ID: <20200303071934.GK7977@straasha.imrryr.org> On Mon, Mar 02, 2020 at 01:48:20PM +0530, shiva kumar wrote: > when I tried to verify the the self signed certificate in OpenSSL 1.0.2 it > is giving error 18 and gives OK as o/p, when I tried the same with OpenSSL > 1.1.1 there is slight change in the behavior it also gives the same error, > but instead of OK it gives different error as "*ca.crt: verification failed*" > as follows. The 1.1.1 behaviour is correct. But you also don't seem to have a clear idea of what it means to "verify" a self-signed certificate. Indeed most likely you don't actually want to verify it at all, and are really trying to solve other problem, which you've decided involves verifying the certificate in question. So it is likely best to describe the *actual* issue you're trying to solve. However, that said: > openssl verify ./ca.crt This command verifies the certificate in question by trying to find in the default store a chain of issuers leading up to a trust anchor (typically a self-signed root CA). But a self-signed certificate is self-issued, so unless it is itself present in the trust store, no possible issuer can be found there. So verification must always fail, and so it does. > why I'm getting this error? Well ultimately because you don't know what you're trying to do, but specifically because the certificate is not issued by an already trusted issuer. > is this an expected behavior in OpenSSL 1.1.1? Yes. -- Viktor. From guoxiaobinni at 163.com Tue Mar 3 07:48:24 2020 From: guoxiaobinni at 163.com (guoxiaobinni at 163.com) Date: Tue, 3 Mar 2020 15:48:24 +0800 Subject: Ues 'openssl s_server command' to disable TLS1.0 Message-ID: <000001d5f130$1e7cd780$5b768680$@163.com> Dear All, I hit the following error when used 'openssl s_server -no_tls1' command to disable TLS1.0 on Redhat Linux server. It shows the openssl version as well. ---------------------------------------------------------------------------- ------------------------------------------------------------------------ $ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 $ openssl s_server -no_tls1 Error opening server certificate private key file server.pem 140057863432008:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen('server.pem','r') 140057863432008:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400: unable to load server certificate private key file ---------------------------------------------------------------------------- ------------------------------------------------------------------------- I can't confirm if the command format is fine or not. Would you please help to correct me? Thanks and Regards, Chobin Guo -------------- next part -------------- An HTML attachment was scrubbed... URL: From iliya.yurkevic at mail.ru Tue Mar 3 07:25:16 2020 From: iliya.yurkevic at mail.ru (=?UTF-8?B?0JjQu9GM0Y8g0K7RgNC60LXQstC40YcgKElseWEgWXVya2V2aWNoKQ==?=) Date: Tue, 03 Mar 2020 10:25:16 +0300 Subject: =?UTF-8?B?UmU6IFN0cmVhbSBFbmNyaXB0aW9u?= Message-ID: <1583220316.958452003@f185.i.mail.ru> No, I want to get CMS Enveloped data in the end of the procedure.? ? Firstly, I?initialize the encryption operation by adding recipient certificates, algorithms, etc., then send the data in chunks for encryption and receive them in an encrypted format for further writing to the file. At the end of the operation, I call the finalizing of the encryption, which adds the final bytes 0x00 0x00 to the cms structure for internal?blocks, meaning the end of each?cms block?- this is what I mean.?As far as I know?CryptMsgUpdate() in CryptoApi allows it -?I'm trying to explain my?purpose?to you better using examples. I want to get?something similar in OpenSSL. It?s possible? ? Now?I use such method: ? cms = CMS_encrypt(certs, NULL, cipher, CMS_STREAM | CMS_BINARY); //call it once?at the start ? BIO* input = CMS_dataInit(cms, NULL); //call it once?at the start BIO_write(input, pbData, cbData);//call each time to add another part?of data ? CMS_dataFinal(cms, input);?//call it once in the end of encryption ? ? This method allows me to read data in stream mode and send?it to?BIO_write(). But I can?t send encrypted data by parts ??only after calling?CMS_dataFinal() ??from cms structure. Thanks for any help. ? >???????, 28 ??????? 2020, 16:55 +03:00 ?? Dmitry Belyavsky < beldmit at gmail.com >: >? >Hello, >? >If you mean encryption/decryption only, I strongly suppose you should look at EVP_CipherInit/Update/Final functions. ? >On Fri, Feb 28, 2020 at 4:53 PM Ilya Yurkevich?via openssl-users < openssl-users at openssl.org > wrote: >>Hello, >>I have a client, that sends me data,?that I need to?encrypt, in few steps. I can use such functions in PKCS11: C_EncryptInit (...), C_EncryptUpdate (...), C_EncryptFinal (...). It?allows me add data, that will be encrypted at every step, using?C_EncryptUpdate ?function. >>? >>In OpenSSL I found CMS_encrypt (...) with flag = CMS_STREAM, but I can't understand how I can add data as I described above or another way? I get data in unsigned char* every time. Any help would be appreciated.?Thanks. >? >? -- >SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Mar 3 08:32:06 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 3 Mar 2020 03:32:06 -0500 Subject: Stream Encription In-Reply-To: <1583220316.958452003@f185.i.mail.ru> References: <1583220316.958452003@f185.i.mail.ru> Message-ID: <20200303083206.GL7977@straasha.imrryr.org> On Tue, Mar 03, 2020 at 10:25:16AM +0300, ???? ??????? (Ilya Yurkevich) via openssl-users wrote: > No, I want to get CMS Enveloped data in the end of the procedure.? The OpenSSL cms(1) command supports streaming when encoding (but not when decoding). If you wade through the source of apps/cms.c, you'll find the relevant calls. -- Viktor. From jb-openssl at wisemo.com Tue Mar 3 09:38:01 2020 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 3 Mar 2020 10:38:01 +0100 Subject: certificate verification error OpenSSL 1.1.1 In-Reply-To: <20200303071934.GK7977@straasha.imrryr.org> References: <20200303071934.GK7977@straasha.imrryr.org> Message-ID: On 2020-03-03 08:19, Viktor Dukhovni wrote: > On Mon, Mar 02, 2020 at 01:48:20PM +0530, shiva kumar wrote: > >> when I tried to verify the the self signed certificate in OpenSSL 1.0.2 it >> is giving error 18 and gives OK as o/p, when I tried the same with OpenSSL >> 1.1.1 there is slight change in the behavior it also gives the same error, >> but instead of OK it gives different error as "*ca.crt: verification failed*" >> as follows. > The 1.1.1 behaviour is correct. But you also don't seem to have a clear > idea of what it means to "verify" a self-signed certificate. Indeed > most likely you don't actually want to verify it at all, and are really > trying to solve other problem, which you've decided involves verifying > the certificate in question. So it is likely best to describe the > *actual* issue you're trying to solve. Depends heavily if you formally interpret a self-signed and self-issued end cert as a CA issuing itself (thus requiring CA:TRUE and making it invalid as an end cert) or as an end cert with no separate CA chain (thus requiring CA:FALSE and making it not trusted as a CA for any other certificate). Either way, the typical case is to use such a self-signed and self-issued cert in the various OpenSSL supported protocols (SSL, TLS, CMS etc.) > However, that said: > >> openssl verify ./ca.crt > This command verifies the certificate in question by trying to find in > the default store a chain of issuers leading up to a trust anchor > (typically a self-signed root CA). > > But a self-signed certificate is self-issued, so unless it is itself > present in the trust store, no possible issuer can be found there. So > verification must always fail, and so it does. > >> why I'm getting this error? > Well ultimately because you don't know what you're trying to do, > but specifically because the certificate is not issued by an > already trusted issuer. > >> is this an expected behavior in OpenSSL 1.1.1? > Yes. > 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 Tue Mar 3 10:51:25 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 3 Mar 2020 10:51:25 +0000 Subject: Ues 'openssl s_server command' to disable TLS1.0 In-Reply-To: <000001d5f130$1e7cd780$5b768680$@163.com> References: <000001d5f130$1e7cd780$5b768680$@163.com> Message-ID: <81805f14-fda9-755c-b127-e21230f51778@openssl.org> On 03/03/2020 07:48, guoxiaobinni at 163.com wrote: > Dear All, > > ? > > I hit the following error when used ?openssl s_server -no_tls1? command > to disable TLS1.0 on Redhat Linux server. Your question is slightly ambiguous. It implies you expect the command to disable TLSv1.0 for all applications on your server. If that is what you meant then you will be disappointed. "openssl s_server" runs a test server to enable testing TLS connections from clients. The "-no_tls1" option disables TLSv1.0 for that test server instance only. If you really mean to start a test server then you need to additionally supply a key and certificate file. By default s_server will look for the key/cert in the file server.pem in the current working directory. Otherwise you have to explicitly state the location of these files with the "-key" and "-cert" options. Matt > It shows the openssl version > as well. > > ? > > ---------------------------------------------------------------------------------------------------------------------------------------------------- > > $ openssl version > > OpenSSL 1.0.1e-fips 11 Feb 2013 > > $ openssl s_server ?no_tls1 > > Error opening server certificate private key file server.pem > > 140057863432008:error:02001002:system library:fopen:No such file or > directory:bss_file.c:398:fopen(?server.pem?,?r?) > > 140057863432008:error:20074002:BIO routines:FILE_CTRL:system > lib:bss_file.c:400: > > unable to load server certificate private key file > > ----------------------------------------------------------------------------------------------------------------------------------------------------- > > ? > > I can?t confirm if the command format is fine or not. Would you please > help to correct me? > > ? > > Thanks and Regards, > > Chobin Guo > From Irina.Ilina-Sidorova at ulb.ac.be Tue Mar 3 11:25:08 2020 From: Irina.Ilina-Sidorova at ulb.ac.be (iilinasi) Date: Tue, 03 Mar 2020 12:25:08 +0100 Subject: OpenSSL reports wrong TLS version to FreeRADIUS In-Reply-To: References: <953ab89f22097fcb53ede1b9f60d7a9c@imapproxy.vub.ac.be> Message-ID: Thank you Alfred! Yup, I used old ciphers indeed. I suspect it stops even before checking them, but I'll add newer ones and let you know. This is the relevant part of freeradius log, just in case: -- (1) eap_tls: TLS_accept: before SSL initialization (1) eap_tls: TLS_accept: before SSL initialization (1) eap_tls: <<< recv TLS 1.3 [length 0048] (1) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal protocol_version (1) eap_tls: ERROR: TLS Alert write:fatal:protocol version tls: TLS_accept: Error in error (1) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol (1) eap_tls: ERROR: System call (I/O) error (-1) (1) eap_tls: ERROR: TLS receive handshake failed during operation (1) eap_tls: ERROR: [eaptls process] = fail -- On 02.03.2020 14:15, Alfred Arnold wrote: > Hi, > >> I'd like to understand, how does OpenSSL get to the idea of "0304" >> version, if there is no such a >> byte sequence in the packet... >> My question is: how OpenSSL determines the TLS version? How to debug >> it? > > I don't see any TLS 1.3 in the capture as well, but I see that your > client is using only outdated (if not to say: historic) cryptographic > algorithms: RC4, RC2 (never seen that in practice!), 3DES and DES. > And those even combined with export options to weaken key strength. > Many modern servers are configured to disallow such outdated crypto: > make your client use at least > > - AES128/256 (either in CBC or GCM mode) > - TLS 1.2 > - no export cipher suites > > Then you might get a more positive reply from the server... > > Best regards > > Alfred Arnold -- Thanks and regards, Irina Ilina-Sidorova From Irina.Ilina-Sidorova at ulb.ac.be Tue Mar 3 12:51:09 2020 From: Irina.Ilina-Sidorova at ulb.ac.be (iilinasi) Date: Tue, 03 Mar 2020 13:51:09 +0100 Subject: OpenSSL reports wrong TLS version to FreeRADIUS In-Reply-To: References: <953ab89f22097fcb53ede1b9f60d7a9c@imapproxy.vub.ac.be> Message-ID: <232ab877ff01de96c19f0b605ddf1aac@imapproxy.vub.ac.be> Alfred, I'd like to say "thanks" once more. I tried with newer ciphers and version 1.2 - and now freeradius (3.0.16) indeed sends me the second "challenge". So, it's a huge progress. However it still complains on the unknown TLS version. I attach the server log and the packet capture, just in case. Have a lovely day! -- Thanks and regards, Irina Ilina-Sidorova On 03.03.2020 12:25, iilinasi wrote: > Thank you Alfred! > > Yup, I used old ciphers indeed. I suspect it stops even before > checking them, but I'll add newer ones and let you know. > > > This is the relevant part of freeradius log, just in case: > -- > (1) eap_tls: TLS_accept: before SSL initialization > (1) eap_tls: TLS_accept: before SSL initialization > (1) eap_tls: <<< recv TLS 1.3 [length 0048] > (1) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal > protocol_version > (1) eap_tls: ERROR: TLS Alert write:fatal:protocol version > tls: TLS_accept: Error in error > (1) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): > error:14209102:SSL > routines:tls_early_post_process_client_hello:unsupported protocol > (1) eap_tls: ERROR: System call (I/O) error (-1) > (1) eap_tls: ERROR: TLS receive handshake failed during operation > (1) eap_tls: ERROR: [eaptls process] = fail > -- > > > On 02.03.2020 14:15, Alfred Arnold wrote: >> Hi, >> >>> I'd like to understand, how does OpenSSL get to the idea of "0304" >>> version, if there is no such a >>> byte sequence in the packet... >>> My question is: how OpenSSL determines the TLS version? How to debug >>> it? >> >> I don't see any TLS 1.3 in the capture as well, but I see that your >> client is using only outdated (if not to say: historic) cryptographic >> algorithms: RC4, RC2 (never seen that in practice!), 3DES and DES. >> And those even combined with export options to weaken key strength. >> Many modern servers are configured to disallow such outdated crypto: >> make your client use at least >> >> - AES128/256 (either in CBC or GCM mode) >> - TLS 1.2 >> - no export cipher suites >> >> Then you might get a more positive reply from the server... >> >> Best regards >> >> Alfred Arnold -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test_with_1_2.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_with_1_2.pcapng Type: application/octet-stream Size: 2020 bytes Desc: not available URL: From matt at openssl.org Tue Mar 3 14:44:06 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 3 Mar 2020 14:44:06 +0000 Subject: OpenSSL reports wrong TLS version to FreeRADIUS In-Reply-To: <232ab877ff01de96c19f0b605ddf1aac@imapproxy.vub.ac.be> References: <953ab89f22097fcb53ede1b9f60d7a9c@imapproxy.vub.ac.be> <232ab877ff01de96c19f0b605ddf1aac@imapproxy.vub.ac.be> Message-ID: <67140e16-28d3-6824-2340-8f59f1784301@openssl.org> On 03/03/2020 12:51, iilinasi wrote: > Alfred, I'd like to say "thanks" once more. > > I tried with newer ciphers and version 1.2 - and now freeradius (3.0.16) > indeed sends me the second "challenge". So, it's a huge progress. > > However it still complains on the unknown TLS version. I attach the > server log and the packet capture, just in case. This is the interesting part from the server log. (1) eap_tls: TLS_accept: before SSL initialization (1) eap_tls: <<< recv UNKNOWN TLS VERSION ?0304? [length 0048] (1) eap_tls: TLS_accept: SSLv3/TLS read client hello The "before SSL initialization" and the "SSLv3/TLS read client hello" strings are generated by OpenSSL. They are the return values from a call to the function SSL_state_string_long() and are intended to give a human readable output of what state the SSL object is in and where in the handshake process it has got to. Interestingly the "UNKNOWN TLS VERSION" message appears between the "before" state and the "read client hello" state. The latter will be returned after the SSL object has gone through its initial setup but before or during the processing of a ClientHello received from the client. The TLS protocol version that server will use is chosen during the processing of that ClientHello. Depending on exactly at what point we're at it is possible that a call to SSL_version() will return either the selected version or (if we haven't got as far as selecting a version yet), the version that the SSL object was initialised with. New SSL objects created using TLS_method(), or TLS_server_method() will have their version initialised to TLS_MAX_VERSION. In OpenSSL 1.1.1 TLS_MAX_VERSION is 0x0304 (TLSv1.3). The string "UNKNOWN TLS VERSION" does not appear in libssl at all. So my guess is that this warning is actually coming from eap_tls after it has made a call to SSL_version(). Since the version has not actually been negotiated yet it comes back with TLSv1.3, and eap_tls doesn't know how to handle it. Is this actually an error? Or just a warning? Matt From richard.simard at groupesti.com Tue Mar 3 14:56:39 2020 From: richard.simard at groupesti.com (Richard Simard) Date: Tue, 3 Mar 2020 14:56:39 +0000 Subject: Config question Message-ID: Good Morning all. Wen I creating my root certificates I would like to add the version of the certification authority. I searched but I couldn't find anything. Is there anyone among you who could tell me how to add this information in the configuration of OpenSSL Tank-You [https://www.groupesti.com/img/logo-28x28.png]Groupe Solutions TI [cid:image002.jpg at 01D5F141.F213CD90] Richard Simard B. Sc. I, ING. I, M.S.I. ASER Pr?sident Agent Provincial FQCQ Matricule : 83787 Radioamateur : VA2SI Formateur et Examinateur Groupe Solutions TI 3-4109, Saint-Alexandre Saguenay, Qu?bec G8A 2H1, Canada Cellulaire : +1 (418) 812-8760 Courriel : richard.simard at groupesti.com Messages de confidentialit? : Ce courriel (de m?me que les fichiers joints) est strictement r?serv? ? l'usage de la personne ou de l'entit? ? qui il est adress? et peut contenir de l'information privil?gi?e et confidentielle. Toute divulgation, distribution ou copie de ce courriel est strictement prohib?e. Si vous avez re?u ce courriel par erreur, veuillez nous en aviser sur-le-champ, d?truire toutes les copies et le supprimer de votre syst?me informatique. Confidentiality Message : This communication (including any files transmitted with it) is intended solely for the person or entity to whom it is addressed, and may contain confidential or privileged information. The disclosure, distribution or copying of this message is strictly forbidden. Should you have received this communication in error, kindly contact the sender promptly, destroy any copies and delete this message from your computer system. [cid:image003.png at 01D5F141.F213CD90] [cid:image004.png at 01D5F141.F213CD90] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4501 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 3383 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 11840 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 14130 bytes Desc: image004.png URL: From matt at openssl.org Tue Mar 3 14:57:05 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 3 Mar 2020 14:57:05 +0000 Subject: OpenSSL reports wrong TLS version to FreeRADIUS In-Reply-To: <953ab89f22097fcb53ede1b9f60d7a9c@imapproxy.vub.ac.be> References: <953ab89f22097fcb53ede1b9f60d7a9c@imapproxy.vub.ac.be> Message-ID: <9d92fdb8-2406-6f84-9102-ba08a136d718@openssl.org> On 02/03/2020 11:28, iilinasi wrote: > Freeradius (3.0.16, 3.0.20) Could be this issue: https://github.com/FreeRADIUS/freeradius-server/issues/2385 "It may be due to the issue fixed in commit fd803c9. 3.0.17 sometimes complained that TLS 1.3 was unknown, and refused to do TLS 1.3 at all. That patch should fix it." Matt From alfred at ccac.rwth-aachen.de Tue Mar 3 15:03:03 2020 From: alfred at ccac.rwth-aachen.de (Alfred Arnold) Date: Tue, 3 Mar 2020 16:03:03 +0100 (CET) Subject: OpenSSL reports wrong TLS version to FreeRADIUS In-Reply-To: <232ab877ff01de96c19f0b605ddf1aac@imapproxy.vub.ac.be> References: <953ab89f22097fcb53ede1b9f60d7a9c@imapproxy.vub.ac.be> <232ab877ff01de96c19f0b605ddf1aac@imapproxy.vub.ac.be> Message-ID: Hi, >Alfred, I'd like to say "thanks" once more. > >I tried with newer ciphers and version 1.2 - and now freeradius (3.0.16) >indeed sends me the second >"challenge". So, it's a huge progress. Indeed, the capture now looks like an EAP-TLS negotiation should go on. The server accepted the client hello, an prepared its message flight of messages. Among them is the server's Certificate message, which is quite huge, and so they cannot be sent in one packet. Your client would next send an empty EAP-TLS message, thereby acknowledging reception of this message fragment. The server would then send the next fragment of these messages. Since the overall length of the message flight is 3137, and FreeRADUIS decided to send ~1000 bytes per fragment, expect another two of those 'ping-pongs' to happen until your client is able to reassemble and process the server's messages. >However it still complains on the unknown TLS version. I attach the >server log and the packet capture, just in case. Well, no idea where the version 0x0304 is coming from. One would probably have to look into the FreeRADIUS sources, or ask on the proper FreeRADIUS mailing lists for assistance. My personal "wild guess" is that this is some sort of 'internal default' as long as the the EAP-TLS module hasn't yet decided about the used protocol version. I wouldn't bother about this too much if you're interested in other things. There's however one other thing I wanted to mention: The Random value your clients sends in the Client Hello is not that random...there is the time stamp in the first four bytes, but the remaining 28 bytes are all-zero - they should contain data from a cryptographically safe random number generator. Best regards Alfred Arnold -- Alfred Arnold E-Mail: alfred at ccac.rwth-aachen.de Computer Club at the http://john.ccac.rwth-aachen.de:8000/alf/ Technical University Phone: +49-241-406526 of Aachen From Michael.Wojcik at microfocus.com Tue Mar 3 16:01:47 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 3 Mar 2020 16:01:47 +0000 Subject: Config question In-Reply-To: References: Message-ID: From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Richard Simard Sent: Tuesday, March 03, 2020 07:57 > Wen I creating my root certificates I would like to add the version of the > certification authority. I searched but I couldn't find anything. Is there > anyone among you who could tell me how to add this information in the > configuration of OpenSSL What does this "version" look like? Can you simply make it one of the components of the Subject and Issuer DNs (which must be the same, since this is a root certificate)? Assuming you want to conform to PKIX, RFC 5280 allows the serialNumber attribute (which is not the same as the certificate serial number) in a DN; you could use that. There's also the old "Netscape Comment" extension. There might be other suitable extensions. -- Michael Wojcik Distinguished Engineer, Micro Focus From abaci.mjm at gmail.com Tue Mar 3 19:41:57 2020 From: abaci.mjm at gmail.com (Michael Mueller) Date: Tue, 3 Mar 2020 14:41:57 -0500 Subject: Problems porting Openssl 1.1.1d to zos. In-Reply-To: <1583146994563-0.post@n7.nabble.com> References: <9f376311-0608-c59b-cdf4-ff92a8b26cff@tibco.com> <1583146994563-0.post@n7.nabble.com> Message-ID: We recently abandoned our effort to port 1.1.1d to zos. Attempting to use GSK now. Lack of a zos dev community is a hurdle. M On Mon, Mar 2, 2020, 6:04 AM K Lengauer wrote: > Dear all, > > I stumbled across this mails when looking for information regarding OpenSSL > on zOS. Currently, I am working on getting OpenSSL 1.1.1c running on zOS. > So > far I created my own config "target" inside 10-main.conf based on the old > configuration that was used pre OpenSSL 1.1.0. > > Still, I was not able to get that far yet and was wondering how you > proceeded regarding this issue? Apart from some github issues and the likes > regarding EBCDIC patches I was unable to find much advice on how to > configure the build and how to tackle common issues. One config target for > zOS OS390 was created a while back but then removed again from OpenSSL > 1.1.1. With my config target I made it to the compile step but still face > build issues. Reaching a complete build like Wendell Nichols would already > by a great step. > > Are any of you aware of zOS specific OpenSSL development branches that I > have yet to find? Or is this mainly done in private repositories/branches > and not offered for PRs to the OpenSSL repository? > > Any advice is greatly appreciated. > > > > -- > Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crhoads at identify3d.com Tue Mar 3 22:16:51 2020 From: crhoads at identify3d.com (Chris Rhoads) Date: Tue, 3 Mar 2020 17:16:51 -0500 Subject: CVE-1999-0428 Message-ID: Hi openssl-users, I am researching the known vulnerabilities of open source software that we are considering. According to the NIST NVD web site, the 1.1.1d version of OpenSSL has a few known vulnerabilities: https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&cpe_vendor=cpe%3A%2F%3Aopenssl&cpe_product=cpe%3A%2F%3A%3Aopenssl&cpe_version=cpe%3A%2F%3Aopenssl%3Aopenssl%3A1.1.1d It appears most of the vulnerabilities that are listed by NIST can be dismissed since the security vulnerability was actually in an application that uses OpenSSL instead of being in OpenSSL itself. But I've been unable to determine with certainty how the last vulnerability on this list (CVE-1999-0428) was fixed. In my research, I've found a potential OpenSSL update in release 0.9.2b that may have addressed the vulnerability: https://seclists.org/bugtraq/1999/Mar/144. But this security alert message doesn't reference any CVE number. The OpenSSL Vulnerabilities web page ( https://www.openssl.org/news/vulnerabilities.html) doesn't go back to 1999, so it doesn't provide any information regarding this vulnerability. Can anyone point me to OpenSSL documentation that indicates CVE-1999-0428 was fixed? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.c.roberts at gmail.com Tue Mar 3 22:31:40 2020 From: bill.c.roberts at gmail.com (William Roberts) Date: Tue, 3 Mar 2020 16:31:40 -0600 Subject: [RFC] TLS salt length auto detection, switch from DIGEST to AUTO In-Reply-To: <930CAB4739D381479DFFE47BE9B633F054166D46@ORSMSX111.amr.corp.intel.com> References: <930CAB4739D381479DFFE47BE9B633F054166D10@ORSMSX111.amr.corp.intel.com> <930CAB4739D381479DFFE47BE9B633F054166D46@ORSMSX111.amr.corp.intel.com> Message-ID: On Thu, Feb 27, 2020 at 1:01 PM Andersen, John S wrote: > > Hi All, > > The TPM 2.0 PKCS11 project has been attempting to get the TPM working with > EAP-TLS WiFi. > > We've run into an issue where the TPM spec specifies that for RSA PSS signing > keys, the random salt length will be the largest size allowed by the key size > and message digest size. > > Server side, in SSL state machine the salt length gets set to > RSA_PSS_SALTLEN_DIGEST (aka -1) which means the salt length must equal the > hash length. Since the TPM used the largest size allowed by the key size and > message digest size, rather than digest size, the handshake fails. > > The TSS and TPM TCG working groups will be working to modify this behavior, so > that the salt length equals the hash length. However, rolling out the update to > the spec and then firmware updates to TPMs will take a very long time. As such > we're wondering if OpenSSL would default to verifying with > RSA_PSS_SALTLEN_AUTO for RSA PSS keys instead of RSA_PSS_SALTLEN_DIGEST > as an intermediary measure. > > This was my original stab at it which made it work, which of course isn't upstreamable. > > diff --git a/crypto/rsa/rsa_pss.c b/crypto/rsa/rsa_pss.c > index f7c575d00a..26c9dcd078 100644 > --- a/crypto/rsa/rsa_pss.c > +++ b/crypto/rsa/rsa_pss.c > @@ -50,6 +50,10 @@ int RSA_verify_PKCS1_PSS_mgf1(RSA *rsa, const unsigned char *mHash, > hLen = EVP_MD_size(Hash); > if (hLen < 0) > goto err; > + > + dprintf(2, "openssl: sLen: %d\n", sLen); > + sLen = -2; > + > /*- > * Negative sLen has special meanings: > * -1 sLen == hLen > > > > The following isn't hacky, but it doesn't work and I'm not yet sure why (still in the > process of debugging but wanted to float the idea on the list). > > > > diff --git b/ssl/statem/statem_srvr.c a/ssl/statem/statem_srvr.c > index 8cf9c40d15..d6793e01a4 100644 > --- b/ssl/statem/statem_srvr.c > +++ a/ssl/statem/statem_srvr.c > @@ -2783,7 +2783,7 @@ int tls_construct_server_key_exchange(SSL *s, WPACKET *pkt) > } > if (lu->sig == EVP_PKEY_RSA_PSS) { > if (EVP_PKEY_CTX_set_rsa_padding(pctx, RSA_PKCS1_PSS_PADDING) <= 0 > - || EVP_PKEY_CTX_set_rsa_pss_saltlen(pctx, RSA_PSS_SALTLEN_DIGEST) <= 0) { > + || EVP_PKEY_CTX_set_rsa_pss_saltlen(pctx, RSA_PSS_SALTLEN_AUTO) <= 0) { > SSLfatal(s, SSL_AD_INTERNAL_ERROR, > SSL_F_TLS_CONSTRUCT_SERVER_KEY_EXCHANGE, > ERR_R_EVP_LIB); > > > Reference: https://github.com/tpm2-software/tpm2-pkcs11/pull/403#issuecomment-590395767 > I was hoping to hear some thoughts from OSSL maintainers. I guess perhaps the question wasn't clear. The question is, can we relax the TLS requirement that slen == hlen and set the flag to autodetect and upstream this? Thanks, Bill From quanah at symas.com Tue Mar 3 23:23:36 2020 From: quanah at symas.com (Quanah Gibson-Mount) Date: Tue, 03 Mar 2020 15:23:36 -0800 Subject: CVE-1999-0428 In-Reply-To: References: Message-ID: <09386BA97A69247E69054B14@[192.168.1.144]> --On Tuesday, March 3, 2020 5:16 PM -0500 Chris Rhoads wrote: > But I've been unable to determine with certainty how the last > vulnerability on this list (CVE-1999-0428) was fixed.? In my research, > I've found a potential OpenSSL update in release 0.9.2b that may have > addressed the vulnerability: https://seclists.org/bugtraq/1999/Mar/144.? > But this security alert message doesn't reference any CVE number. The above email is related to this commit in the OpenSSL source tree: b4cadc6e1343c01b06613053a90ed2ee85e65090 Since it pre-dates the CVE being filed, it has no reference to the CVE itself in the commit. Someone from the OpenSSL project would have to confirm if that is indeed the fix for the above CVE (and if so, then the CVE database needs updating). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From iliya.yurkevic at mail.ru Wed Mar 4 08:18:32 2020 From: iliya.yurkevic at mail.ru (=?UTF-8?B?0JjQu9GM0Y8g0K7RgNC60LXQstC40YcgKElseWEgWXVya2V2aWNoKQ==?=) Date: Wed, 04 Mar 2020 11:18:32 +0300 Subject: =?UTF-8?B?U2lnbmluZyBjbXMgdXNpbmcgaGFzaCBvZiBkYXRhIGluc3RlYWQgZGF0YQ==?= Message-ID: <1583309912.685556862@f56.i.mail.ru> Hello everyone. Is it possible to create cms Signed Data using hash of the input data instead of the data? What I need use? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guoxiaobinni at 163.com Wed Mar 4 08:31:20 2020 From: guoxiaobinni at 163.com (guoxiaobinni at 163.com) Date: Wed, 4 Mar 2020 16:31:20 +0800 Subject: Ues 'openssl s_server command' to disable TLS1.0 Message-ID: <000001d5f1ff$49276250$db7626f0$@163.com> Thanks Matt, As your advice, I tried to execute the following both commands to disable TLS 1.0 for Client and Server separately. Since I have no right to access private keyfile, of course they failed. Could you please correct me if the command format is fine? I then will assign them to senior colleague to execute. $ openssl s_server -no_tls1 -key keyfile -cert certname $ openssl s_client -no_tls1 -key keyfile [-cert certname] Thanks. Chobin -----????----- ???: openssl-users-bounces at openssl.org [mailto:openssl-users-bounces at openssl.org] ?? Matt Caswell ????: 2020?3?3? 18:51 ???: openssl-users at openssl.org ??: Re: Ues 'openssl s_server command' to disable TLS1.0 On 03/03/2020 07:48, guoxiaobinni at 163.com wrote: > Dear All, > > > > I hit the following error when used ?openssl s_server -no_tls1? command > to disable TLS1.0 on Redhat Linux server. Your question is slightly ambiguous. It implies you expect the command to disable TLSv1.0 for all applications on your server. If that is what you meant then you will be disappointed. "openssl s_server" runs a test server to enable testing TLS connections from clients. The "-no_tls1" option disables TLSv1.0 for that test server instance only. If you really mean to start a test server then you need to additionally supply a key and certificate file. By default s_server will look for the key/cert in the file server.pem in the current working directory. Otherwise you have to explicitly state the location of these files with the "-key" and "-cert" options. Matt > It shows the openssl version > as well. > > > > ---------------------------------------------------------------------------------------------------------------------------------------------------- > > $ openssl version > > OpenSSL 1.0.1e-fips 11 Feb 2013 > > $ openssl s_server ?no_tls1 > > Error opening server certificate private key file server.pem > > 140057863432008:error:02001002:system library:fopen:No such file or > directory:bss_file.c:398:fopen(?server.pem?,?r?) > > 140057863432008:error:20074002:BIO routines:FILE_CTRL:system > lib:bss_file.c:400: > > unable to load server certificate private key file > > ----------------------------------------------------------------------------------------------------------------------------------------------------- > > > > I can?t confirm if the command format is fine or not. Would you please > help to correct me? > > > > Thanks and Regards, > > Chobin Guo > From psteuer9 at gmail.com Wed Mar 4 11:06:39 2020 From: psteuer9 at gmail.com (Patrick Steuer) Date: Wed, 4 Mar 2020 12:06:39 +0100 Subject: Problems porting Openssl 1.1.1d to zos. In-Reply-To: <1583146994563-0.post@n7.nabble.com> References: <9f376311-0608-c59b-cdf4-ff92a8b26cff@tibco.com> <1583146994563-0.post@n7.nabble.com> Message-ID: <8ffd49d6-3270-0854-1ad1-f40a5fd12303@gmail.com> > I stumbled across this mails when looking for information regarding OpenSSL > on zOS. Currently, I am working on getting OpenSSL 1.1.1c running on zOS. So > far I created my own config "target" inside 10-main.conf based on the old > configuration that was used pre OpenSSL 1.1.0. > Still, I was not able to get that far yet and was wondering how you > proceeded regarding this issue? Apart from some github issues and the likes > regarding EBCDIC patches I was unable to find much advice on how to > configure the build and how to tackle common issues. One config target for > zOS OS390 was created a while back but then removed again from OpenSSL > 1.1.1. With my config target I made it to the compile step but still face > build issues. Reaching a complete build like Wendell Nichols would already > by a great step. Regarding z/OS, the build environment is usually the hard part: We build from EBCDIC sources (gunzip the tar file, use pax to extract from tar) using xplink linkage, 64 bit and a perl version that works with EBCDIC. Relevant parts from the config files that we are using: 10-main.conf -------- "OS390-Unix" => { inherit_from => [ "BASE_unix", asm("zos_asm") ], cc => "./tools/c99.sh", cflags => "-O -Wc,dll,XPLINK,exportall,hgpr,lp64 -Wa,'GOFF,SYSPARM(USE_XPLINK)' -qlongname -qlanglvl=extc99 -DB_ENDIAN -DCHARSET_EBCDIC -DNO_SYS_PARAM_H -D_ALL_SOURCE -D_OPEN_THREADS=2 -D_POSIX_SOURCE -D_OPEN_MSGQ_EXT", module_ldflags => "-Wl,XPLINK,LP64", shared_ldflags => "-Wl,dll,XPLINK,LP64", bn_ops => "THIRTY_TWO_BIT RC4_CHAR", thread_scheme => "(unknown)", perlasm_scheme => "zOS64", }, -------- 00-base-templates.conf -------- # Either comment out all the asm below, or use a no-asm build. zos_asm => { template => 1, cpuid_asm_src => "s390xcap.c s390xcpuid.s", bn_asm_src => "bn_asm.c", # s390x-gf2m.s", ec_asm_src => "ecp_s390x_nistp.c", aes_asm_src => "aes-s390x.s aes-ctr.fake aes-xts.fake", sha1_asm_src => "sha1-s390x.s sha256-s390x.s sha512-s390x.s", rc4_asm_src => "rc4-s390x.s", modes_asm_src => "ghash-s390x.s", # chacha_asm_src => "chacha-s390x.s", # poly1305_asm_src => "poly1305-s390x.s", keccak1600_asm_src => "keccak1600-s390x.s", -------- tools/c99.sh -------- #!/bin/sh -k # # Re-order arguments so that -L comes first # opts="" lopts="" for arg in $* ; do case $arg in -L*) lopts="$lopts $arg" ;; *) opts="$opts $arg" ;; esac done c99 -Wl,dll $lopts $opts -------- > Are any of you aware of zOS specific OpenSSL development branches that I > have yet to find? Or is this mainly done in private repositories/branches > and not offered for PRs to the OpenSSL repository? We are working on porting OpenSSL for z/OS internally right now and will share the work in progress (via a PR to the OpenSSL repo) as soon as it makes sense, probably in the near future. Best, Patrick From matt at openssl.org Wed Mar 4 11:40:39 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 4 Mar 2020 11:40:39 +0000 Subject: Ues 'openssl s_server command' to disable TLS1.0 In-Reply-To: <000001d5f1ff$49276250$db7626f0$@163.com> References: <000001d5f1ff$49276250$db7626f0$@163.com> Message-ID: <1206dda7-6823-b426-a1cb-2f66d906c052@openssl.org> On 04/03/2020 08:31, guoxiaobinni at 163.com wrote: > Thanks Matt, > > As your advice, I tried to execute the following both commands to disable TLS 1.0 for Client and Server separately. Since I have no right to access private keyfile, of course they failed. Could you please correct me if the command format is fine? I then will assign them to senior colleague to execute. > > $ openssl s_server -no_tls1 -key keyfile -cert certname > $ openssl s_client -no_tls1 -key keyfile [-cert certname] The format for s_server is fine. There is no need to supply the -key and -cert options to s_client unless you are wanting to test client authentication. However, I'm still not convinced you have understood what these commands actually do. They will create a test server, and a initiate a test client to connect to it respectively - and will disable TLSv1.0 for those instances only. Typically you would only do this with test keys/certs not with production keys/certs. It will have no impact on any other servers/clients running in your environment. Matt > > Thanks. > Chobin > > -----????----- > ???: openssl-users-bounces at openssl.org [mailto:openssl-users-bounces at openssl.org] ?? Matt Caswell > ????: 2020?3?3? 18:51 > ???: openssl-users at openssl.org > ??: Re: Ues 'openssl s_server command' to disable TLS1.0 > > > > On 03/03/2020 07:48, guoxiaobinni at 163.com wrote: >> Dear All, >> >> >> >> I hit the following error when used ?openssl s_server -no_tls1? command >> to disable TLS1.0 on Redhat Linux server. > > Your question is slightly ambiguous. It implies you expect the command > to disable TLSv1.0 for all applications on your server. If that is what > you meant then you will be disappointed. "openssl s_server" runs a test > server to enable testing TLS connections from clients. The "-no_tls1" > option disables TLSv1.0 for that test server instance only. > > If you really mean to start a test server then you need to additionally > supply a key and certificate file. By default s_server will look for the > key/cert in the file server.pem in the current working directory. > Otherwise you have to explicitly state the location of these files with > the "-key" and "-cert" options. > > Matt > > > >> It shows the openssl version >> as well. >> >> >> >> ---------------------------------------------------------------------------------------------------------------------------------------------------- >> >> $ openssl version >> >> OpenSSL 1.0.1e-fips 11 Feb 2013 >> >> $ openssl s_server ?no_tls1 >> >> Error opening server certificate private key file server.pem >> >> 140057863432008:error:02001002:system library:fopen:No such file or >> directory:bss_file.c:398:fopen(?server.pem?,?r?) >> >> 140057863432008:error:20074002:BIO routines:FILE_CTRL:system >> lib:bss_file.c:400: >> >> unable to load server certificate private key file >> >> ----------------------------------------------------------------------------------------------------------------------------------------------------- >> >> >> >> I can?t confirm if the command format is fine or not. Would you please >> help to correct me? >> >> >> >> Thanks and Regards, >> >> Chobin Guo >> > > From abaci.mjm at gmail.com Wed Mar 4 12:17:52 2020 From: abaci.mjm at gmail.com (Michael Mueller) Date: Wed, 4 Mar 2020 07:17:52 -0500 Subject: Problems porting Openssl 1.1.1d to zos. In-Reply-To: <8ffd49d6-3270-0854-1ad1-f40a5fd12303@gmail.com> References: <9f376311-0608-c59b-cdf4-ff92a8b26cff@tibco.com> <1583146994563-0.post@n7.nabble.com> <8ffd49d6-3270-0854-1ad1-f40a5fd12303@gmail.com> Message-ID: This is a very helpful post. Thank you. We lacked Perl and had no clear path to getting it. Can't say this deficiency caused our project to miss generous targets, but it certainly contributed. On Wed, Mar 4, 2020, 6:07 AM Patrick Steuer wrote: > > I stumbled across this mails when looking for information regarding > OpenSSL > > on zOS. Currently, I am working on getting OpenSSL 1.1.1c running on > zOS. So > > far I created my own config "target" inside 10-main.conf based on the old > > configuration that was used pre OpenSSL 1.1.0. > > > Still, I was not able to get that far yet and was wondering how you > > proceeded regarding this issue? Apart from some github issues and the > likes > > regarding EBCDIC patches I was unable to find much advice on how to > > configure the build and how to tackle common issues. One config target > for > > zOS OS390 was created a while back but then removed again from OpenSSL > > 1.1.1. With my config target I made it to the compile step but still face > > build issues. Reaching a complete build like Wendell Nichols would > already > > by a great step. > > Regarding z/OS, the build environment is usually the hard part: > We build from EBCDIC sources (gunzip the tar file, use pax to extract > from tar) using xplink linkage, 64 bit and a perl version that works > with EBCDIC. > > Relevant parts from the config files that we are using: > > 10-main.conf > -------- > "OS390-Unix" => { > inherit_from => [ "BASE_unix", asm("zos_asm") ], > cc => "./tools/c99.sh", > cflags => "-O -Wc,dll,XPLINK,exportall,hgpr,lp64 > -Wa,'GOFF,SYSPARM(USE_XPLINK)' -qlongname -qlanglvl=extc99 -DB_ENDIAN > -DCHARSET_EBCDIC -DNO_SYS_PARAM_H -D_ALL_SOURCE -D_OPEN_THREADS=2 > -D_POSIX_SOURCE -D_OPEN_MSGQ_EXT", > module_ldflags => "-Wl,XPLINK,LP64", > shared_ldflags => "-Wl,dll,XPLINK,LP64", > bn_ops => "THIRTY_TWO_BIT RC4_CHAR", > thread_scheme => "(unknown)", > perlasm_scheme => "zOS64", > }, > -------- > > 00-base-templates.conf > -------- > # Either comment out all the asm below, or use a no-asm build. > zos_asm => { > template => 1, > cpuid_asm_src => "s390xcap.c s390xcpuid.s", > bn_asm_src => "bn_asm.c", # s390x-gf2m.s", > ec_asm_src => "ecp_s390x_nistp.c", > aes_asm_src => "aes-s390x.s aes-ctr.fake aes-xts.fake", > sha1_asm_src => "sha1-s390x.s sha256-s390x.s sha512-s390x.s", > rc4_asm_src => "rc4-s390x.s", > modes_asm_src => "ghash-s390x.s", > # chacha_asm_src => "chacha-s390x.s", > # poly1305_asm_src => "poly1305-s390x.s", > keccak1600_asm_src => "keccak1600-s390x.s", > -------- > > tools/c99.sh > -------- > #!/bin/sh -k > # > # Re-order arguments so that -L comes first > # > opts="" > lopts="" > > for arg in $* ; do > case $arg in > -L*) lopts="$lopts $arg" ;; > *) opts="$opts $arg" ;; > esac > done > > c99 -Wl,dll $lopts $opts > -------- > > > > Are any of you aware of zOS specific OpenSSL development branches that I > > have yet to find? Or is this mainly done in private repositories/branches > > and not offered for PRs to the OpenSSL repository? > > We are working on porting OpenSSL for z/OS internally right now and will > share the work in progress (via a PR to the OpenSSL repo) as soon as it > makes sense, probably in the near future. > > Best, > Patrick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.lengauer at adnovum.ch Wed Mar 4 15:27:03 2020 From: kevin.lengauer at adnovum.ch (K Lengauer) Date: Wed, 4 Mar 2020 08:27:03 -0700 (MST) Subject: Problems porting Openssl 1.1.1d to zos. In-Reply-To: <8ffd49d6-3270-0854-1ad1-f40a5fd12303@gmail.com> References: <9f376311-0608-c59b-cdf4-ff92a8b26cff@tibco.com> <1583146994563-0.post@n7.nabble.com> <8ffd49d6-3270-0854-1ad1-f40a5fd12303@gmail.com> Message-ID: <1583335623698-0.post@n7.nabble.com> Thank you very much Patrick Steuer. This certainly helps! I am now also in the progress of building OpenSSL and come across missing "cflags" and the likes so with your config I can hopefully save some time as well as verify what I already use. I will also share my config in the near future once I am getting closer to a successful build. Most of the flags I added in my "OS390-Unix" target are the same or similar to yours. Again, thank you. @Michael Mueller: The zOS system Perl was also below the minimum required Perl version but our system administrator pointed me to using rocketsoftware's Perl 5.24 which he already added to the zOS machine I am using some time ago. I hear mixed opinions regarding rocketsoftware but so far I was able to work with it. Just make sure to adjust your LIBPATH, PERL5LIB and so on to make that Perl work. Just sharing in case you did not yet try that. If you get stuck configuring the new Perl I could share my settings. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From psteuer9 at gmail.com Wed Mar 4 15:52:57 2020 From: psteuer9 at gmail.com (Patrick Steuer) Date: Wed, 4 Mar 2020 16:52:57 +0100 Subject: Problems porting Openssl 1.1.1d to zos. In-Reply-To: <1583335623698-0.post@n7.nabble.com> References: <9f376311-0608-c59b-cdf4-ff92a8b26cff@tibco.com> <1583146994563-0.post@n7.nabble.com> <8ffd49d6-3270-0854-1ad1-f40a5fd12303@gmail.com> <1583335623698-0.post@n7.nabble.com> Message-ID: <722901e3-538e-7a5a-de44-2f868ec6a14f@gmail.com> Regarding perl, this is the version which works for us : > perl -v This is perl 5, version 24, subversion 0 (v5.24.0) built for os390 Copyright 1987-2016, Larry Wall MVS (OS390) port by Mortice Kern Systems, 1997-1999 Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. From rsalz at akamai.com Wed Mar 4 16:31:52 2020 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 4 Mar 2020 16:31:52 +0000 Subject: Problems porting Openssl 1.1.1d to zos. In-Reply-To: <1583335623698-0.post@n7.nabble.com> References: <9f376311-0608-c59b-cdf4-ff92a8b26cff@tibco.com> <1583146994563-0.post@n7.nabble.com> <8ffd49d6-3270-0854-1ad1-f40a5fd12303@gmail.com> <1583335623698-0.post@n7.nabble.com> Message-ID: <36E03C4F-7A66-407B-A154-2E02F2C03021@akamai.com> Perhaps someone should writeup and submit a "NOTES.zos" file to add? From Irina.Ilina-Sidorova at ulb.ac.be Thu Mar 5 09:53:10 2020 From: Irina.Ilina-Sidorova at ulb.ac.be (iilinasi) Date: Thu, 05 Mar 2020 10:53:10 +0100 Subject: OpenSSL reports wrong TLS version to FreeRADIUS In-Reply-To: References: <953ab89f22097fcb53ede1b9f60d7a9c@imapproxy.vub.ac.be> <232ab877ff01de96c19f0b605ddf1aac@imapproxy.vub.ac.be> Message-ID: <85314e4e019f0a1d7bd484e808357cbf@imapproxy.vub.ac.be> On 03.03.2020 16:03, Alfred Arnold wrote: > Hi, > >> Alfred, I'd like to say "thanks" once more. >> >> I tried with newer ciphers and version 1.2 - and now freeradius >> (3.0.16) indeed sends me the second >> "challenge". So, it's a huge progress. > > Indeed, the capture now looks like an EAP-TLS negotiation should go > on. The server accepted the client hello, an prepared its message > flight of messages. Among them is the server's Certificate message, > which is quite huge, and so they cannot be sent in one packet. Your > client would next send an empty EAP-TLS message, thereby acknowledging > reception of this message fragment. The server would then send the > next fragment of these messages. Since the overall length of the > message flight is 3137, and FreeRADUIS decided to send ~1000 bytes per > fragment, expect another two of those 'ping-pongs' to happen until > your client is able to reassemble and process the server's messages. > Yes, this is what I'm adding to my script now. >> However it still complains on the unknown TLS version. I attach the >> server log and the packet capture, just in case. > > Well, no idea where the version 0x0304 is coming from. One would > probably have to look into the FreeRADIUS sources, or ask on the > proper FreeRADIUS mailing lists for assistance. My personal "wild > guess" is that this is some sort of 'internal default' as long as the > the EAP-TLS module hasn't yet decided about the used protocol version. > I wouldn't bother about this too much if you're interested in other > things. > > There's however one other thing I wanted to mention: The Random value > your clients sends in the Client Hello is not that random...there is > the time stamp in the first four bytes, but the remaining 28 bytes are > all-zero - they should contain data from a cryptographically safe > random number generator. > Thank you :-) Yes, I set it to zeroes as it was easier to read the packet with this big zeroed part (and also I wanted to be sure in absence of "0304"). Thanks for the reminder - I'll put there some output from /dev/urandom. > Best regards > > Alfred Arnold Have a lovely day! -- Thanks and regards, Irina Ilina-Sidorova From jetson23 at hotmail.com Thu Mar 5 14:04:27 2020 From: jetson23 at hotmail.com (Jason Schultz) Date: Thu, 5 Mar 2020 14:04:27 +0000 Subject: Peer certificate verification in verify_callback Message-ID: I have some questions about my application?s verify_callback() function and how I handle some of the OpenSSL errors. For example, if my client application is presented a self-signed certificate in the handshake, verify_callback() is called with an error, for which X509_STORE_CTX_get_error() returns 18/X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT. In this case, my application searches its trusted store for this certificate, and if it finds a match, the error is cleared and the handshake is allow to proceed. Other examples are cases where my client application is presented with a certificate chain. Let?s say the chain looks like root -> intermediate -> end-entity, but the server is configured to not send the root, so my client gets: intermediate -> end-entity in the handshake. One case is where my client is presented these certificates and has the end-entity certificate in its trusted store. In this case, the verify_callback() gets error 20/ X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY. For this error, my application will search its trusted store for the end-entity certificate, and when a match is found the error is cleared and the handshake is allowed to proceed. A slightly different case is when the client has only the intermediate certificate in its trusted store, while the server presents the intermediate -> end-entity chain. In this case, verify_callback() is called with an error, and X509_STORE_CTX_get_error() returns 2/ X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT. These last two cases seem very similar but get slightly different errors. Right now my application does not look for a match in the case of X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT. My plan is to add that error to the cases where the trusted store is searched for a match. Are there more subtle differences between these two errors that I?m missing? Or does my plan to have the application do the addition checking for this error make sense? -------------- next part -------------- An HTML attachment was scrubbed... URL: From psteuer9 at gmail.com Thu Mar 5 14:38:51 2020 From: psteuer9 at gmail.com (Patrick Steuer) Date: Thu, 5 Mar 2020 15:38:51 +0100 Subject: Problems porting Openssl 1.1.1d to zos. In-Reply-To: <36E03C4F-7A66-407B-A154-2E02F2C03021@akamai.com> References: <9f376311-0608-c59b-cdf4-ff92a8b26cff@tibco.com> <1583146994563-0.post@n7.nabble.com> <8ffd49d6-3270-0854-1ad1-f40a5fd12303@gmail.com> <1583335623698-0.post@n7.nabble.com> <36E03C4F-7A66-407B-A154-2E02F2C03021@akamai.com> Message-ID: On 3/4/20 5:31 PM, Salz, Rich via openssl-users wrote: > Perhaps someone should writeup and submit a "NOTES.zos" file to add? I could put the contents of my previous mail in a NOTES.zos file, if that would be considered helpful, knowing it works for us at the moment and might not to the trick for other build environments. Thinking of a more comprehensive guide, id prefer to invest my time in helping the ongoing porting effort instead. From jhb at FreeBSD.org Thu Mar 5 17:25:26 2020 From: jhb at FreeBSD.org (John Baldwin) Date: Thu, 5 Mar 2020 09:25:26 -0800 Subject: writev over OpenSSL In-Reply-To: References: <20200202180936.GM49778@straasha.imrryr.org> Message-ID: On 2/3/20 7:00 AM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of >> Viktor Dukhovni >> Sent: Sunday, February 02, 2020 11:10 >> >> On Sun, Feb 02, 2020 at 05:28:19PM +0000, Salz, Rich via openssl-users wrote: >> >>> TLS/TLS will take your data and wrap it inside it?s own record >>> structure. It has to, that?s the nature of the protocol. Thinking >>> that a single writev() is ?encrypt buffers and then do analogous >>> syscall? is wrong. >> >> Right, the encryption is not in place, the user's data is copied for >> encryption, by which point there's no incentive for a writev between >> OpenSSL and the socket. > > True. There's still an argument to be made for a gather-write at the application level, though. That would let the application say "here are multiple buffers of application data which should be coalesced into as few TLS records as possible, then encrypted and transmitted". It saves either a temporary buffer and memory copy prior to calling SSL_write at the application level, or sending short TLS records. > > Back in '01 I suggested it would also be useful for applications using the BIO abstraction for both TLS conversations and for plaintext stream sockets. Eighteen and a half years later, I suspect that's not a common use case. > > But in any case, as I noted in my previous message, if this enhancement is sufficiently valuable to someone they can always implement it and submit a PR. Note that kernel offloaded TLS (KTLS) changes the calculus on all of this as you could in fact do a single system call (hence SSL_sendfile()). One could perhaps have a SSL_writev() that did a single system call for KTLS and fell back to a loop of SSL_write() calls otherwise. However, you wouldn't have a SSL_readv() equivalent which might feel odd from an API perspective. -- John Baldwin From themanchicken at gmail.com Fri Mar 6 01:08:42 2020 From: themanchicken at gmail.com (Michael Stemle, Jr) Date: Thu, 5 Mar 2020 20:08:42 -0500 Subject: Issue with v1.1.1 in CentOS 8 regarding OPENSSL_CONF Message-ID: ?Hello! I?ve been troubleshooting an issue with OpenSSL in a dependency of a Perl module I maintain. It looks like the rabbitmq-c library that the module uses implemented CONF_modules_load_file(), but it seems to be causing problems and I?m not sure how to address it properly. Here?s the bug on my module as reported by the CPAN testers: https://github.com/net-amqp-rabbitmq/net-amqp-rabbitmq/issues/186 Here?s an issue I raised and have been troubleshooting with the C library which implements rabbitmq: https://github.com/alanxz/rabbitmq-c/issues/602#issuecomment-594987398 I?m not quite sure what the right path forward is here, and I would greatly appreciate some advice. Many thanks. ~ Michael D. Stemle, Jr. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kheemen at hotmail.com Fri Mar 6 03:13:26 2020 From: kheemen at hotmail.com (Hyer Low) Date: Thu, 5 Mar 2020 20:13:26 -0700 (MST) Subject: How to cleanup CRL memory used after SSL(OpenSSL) handshake has completed? Message-ID: <1583464406682-0.post@n7.nabble.com> I'm using *X509_load_cert_crl_file*(openssl) to load the CRL file into the CTX and create SSL for ssl_accept handshake. For each SSL connection that has CRL file(600KB) loaded used up 10 times memory more than SSL connection that doesn't load CRL. The system is having >300 ports that serving TLS for 300 different config, where there will be 300 different CTX created where each CTX will only serve only 1 TLS connection. That has use up most of the system memory. If the CTX is only used during the handshake, how to force the CTX to be cleanup, or at least cleanup the CRL/cert store in CTX, after the handshake completed? To optimize the server memory, can I use *SSL_CTX_set_cert_store(ssl->ctx, X509_STORE_new())* to force all X509_store to be cleanup after handshake? Will there be any side effect? /*OCSP is not an option in the server/ -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From openssl-users at dukhovni.org Fri Mar 6 03:40:29 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 5 Mar 2020 22:40:29 -0500 Subject: Issue with v1.1.1 in CentOS 8 regarding OPENSSL_CONF In-Reply-To: References: Message-ID: <20200306034029.GH7977@straasha.imrryr.org> On Thu, Mar 05, 2020 at 08:08:42PM -0500, Michael Stemle, Jr wrote: > Hello! For some reason your email client included a UTF-8 BOM at the start of the message text. Best to not do that. > I?ve been troubleshooting an issue with OpenSSL in a dependency of a > Perl module I maintain. It looks like the rabbitmq-c library that the > module uses implemented CONF_modules_load_file(), but it seems to be > causing problems and I?m not sure how to address it properly. What does "implemented" mean? > Here?s the bug on my module as reported by the CPAN testers: > https://github.com/net-amqp-rabbitmq/net-amqp-rabbitmq/issues/186 I added a comment: https://github.com/net-amqp-rabbitmq/net-amqp-rabbitmq/issues/186#issuecomment-595579659 > Here?s an issue I raised and have been troubleshooting with the C > library which implements rabbitmq: > https://github.com/alanxz/rabbitmq-c/issues/602#issuecomment-594987398 > > I?m not quite sure what the right path forward is here, and I would greatly appreciate some advice. With OpenSSL 1.1.1b and forward the correct way to initialize the SSL library with a custom application name "appname" (from some code slated to some day be integrated into Postfix) is: #if OPENSSL_VERSION_NUMBER >= 0x1010102fL OPENSSL_INIT_SETTINGS *init_settings = NULL; unsigned long init_opts = 0; unsigned long init_flags = CONF_MFLAGS_IGNORE_MISSING_FILE; if ((init_settings = OPENSSL_INIT_new()) == 0) { /* error */ ... } OPENSSL_INIT_set_config_appname(init_settings, "appname"); /* * By not including CONF_MFLAGS_IGNORE_RETURN_CODES, we get strict error * reporting. We don't insist on a match for the requested application * name, allowing fallback to the default application name, even when a * non-default application name is specified by always setting the * CONF_MFLAGS_DEFAULT_SECTION bit. */ init_flags |= CONF_MFLAGS_DEFAULT_SECTION; OPENSSL_INIT_set_config_file_flags(init_settings, init_flags); if (OPENSSL_init_ssl(init_opts, init_settings) <= 0) { /* error */ ... } #endif I don't recall whether/when it may be appropriate to call CONF_module_load_file(). That may have to be done after the library is initialized. I still don't know what all those looping libraries were, none of the sort are present on my system. -- Viktor. From iliya.yurkevic at mail.ru Fri Mar 6 08:44:40 2020 From: iliya.yurkevic at mail.ru (=?UTF-8?B?0JjQu9GM0Y8g0K7RgNC60LXQstC40YcgKElseWEgWXVya2V2aWNoKQ==?=) Date: Fri, 06 Mar 2020 11:44:40 +0300 Subject: =?UTF-8?B?U2lnbmluZyBjbXMgdXNpbmcgaGFzaCBvZiBkYXRhIGluc3RlYWQgZGF0YQ==?= In-Reply-To: <1583309912.685556862@f56.i.mail.ru> References: <1583309912.685556862@f56.i.mail.ru> Message-ID: <1583484280.202146788@f128.i.mail.ru> Hello everyone. Is it possible to create cms Signed Data using the message digest value instead of the data? What I need use? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Mar 6 10:40:55 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 6 Mar 2020 10:40:55 +0000 Subject: How to cleanup CRL memory used after SSL(OpenSSL) handshake has completed? In-Reply-To: <1583464406682-0.post@n7.nabble.com> References: <1583464406682-0.post@n7.nabble.com> Message-ID: <77f25331-17b5-28d9-a988-984b6f914ed7@openssl.org> On 06/03/2020 03:13, Hyer Low wrote: > I'm using *X509_load_cert_crl_file*(openssl) to load the CRL file into the > CTX and create SSL for ssl_accept handshake. For each SSL connection that > has CRL file(600KB) loaded used up 10 times memory more than SSL connection > that doesn't load CRL. > > The system is having >300 ports that serving TLS for 300 different config, > where there will be 300 different CTX created where each CTX will only serve > only 1 TLS connection. That has use up most of the system memory. > > If the CTX is only used during the handshake, how to force the CTX to be > cleanup, or at least cleanup the CRL/cert store in CTX, after the handshake > completed? > > To optimize the server memory, can I use *SSL_CTX_set_cert_store(ssl->ctx, > X509_STORE_new())* to force all X509_store to be cleanup after handshake? > Will there be any side effect? You can just call: SSL_CTX_set_cert_store(ctx, NULL); In general it is inadvisable to modify the SSL_CTX after SSL objects have been created because it is not thread-safe to do so. However, if the SSL_CTX and SSL are both created on the same thread and never shared with another thread then I can't think of a reason why doing this would be a problem. Another thought is that X509_STORE objects are reference counted. If at least the store is shared between all your 300 different configs then you don't have to load it 300 times. Just load it once, and up the ref count for each SSL_CTX that uses it (or just use SSL_CTX_set1_cert_store() instead of SSL_CTX_set_cert_store() - and this ups the ref count for you). Matt > > /*OCSP is not an option in the server/ > > > > -- > Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html > From kheemen at hotmail.com Fri Mar 6 10:57:06 2020 From: kheemen at hotmail.com (Hyer Low) Date: Fri, 6 Mar 2020 03:57:06 -0700 (MST) Subject: How to cleanup CRL memory used after SSL(OpenSSL) handshake has completed? In-Reply-To: <77f25331-17b5-28d9-a988-984b6f914ed7@openssl.org> References: <1583464406682-0.post@n7.nabble.com> <77f25331-17b5-28d9-a988-984b6f914ed7@openssl.org> Message-ID: <1583492226236-0.post@n7.nabble.com> All configs can have different cert being setup as well, hence each CTX cert store might also different and not to be share. Thanks. I'll try and see any possible side effect. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From matt at openssl.org Fri Mar 6 11:00:35 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 6 Mar 2020 11:00:35 +0000 Subject: How to cleanup CRL memory used after SSL(OpenSSL) handshake has completed? In-Reply-To: <1583492226236-0.post@n7.nabble.com> References: <1583464406682-0.post@n7.nabble.com> <77f25331-17b5-28d9-a988-984b6f914ed7@openssl.org> <1583492226236-0.post@n7.nabble.com> Message-ID: <7b77b6c1-ff90-0ea7-cc20-fc9f0946933b@openssl.org> One other thing does occur: if you allow renegotiation then you might need access to the cert-store after the initial handshake has completed. Matt On 06/03/2020 10:57, Hyer Low wrote: > All configs can have different cert being setup as well, hence each CTX cert > store might also different and not to be share. > > Thanks. I'll try and see any possible side effect. > > > > -- > Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html > From kheemen at hotmail.com Fri Mar 6 11:17:53 2020 From: kheemen at hotmail.com (Hyer Low) Date: Fri, 6 Mar 2020 19:17:53 +0800 Subject: How to cleanup CRL memory used after SSL(OpenSSL) handshake has completed? In-Reply-To: <7b77b6c1-ff90-0ea7-cc20-fc9f0946933b@openssl.org> Message-ID: Noted. Renegotiation has been disable. Is there anyway to clean the CTX while let SSL object itself serving the tunnel ? Or I can only depend on the CTX ref after the SSL is delete? Regards, Hyer Low > > On Mar 6, 2020 at 7:00 PM, wrote: > > > > One other thing does occur: if you allow renegotiation then you might need access to the cert-store after the initial handshake has completed. Matt On 06/03/2020 10:57, Hyer Low wrote: > All configs can have different cert being setup as well, hence each CTX cert > store might also different and not to be share. > > Thanks. I'll try and see any possible side effect. > > > > -- > Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Mar 6 11:24:06 2020 From: matt at openssl.org (Matt Caswell) Date: Fri, 6 Mar 2020 11:24:06 +0000 Subject: How to cleanup CRL memory used after SSL(OpenSSL) handshake has completed? In-Reply-To: References: Message-ID: <36cf3da7-710d-2600-f917-a546074f8c33@openssl.org> The CTX needs to be there for the whole time that the SSL is. Matt On 06/03/2020 11:17, Hyer Low wrote: > Noted.?Renegotiation has been disable. > > Is there anyway to clean the CTX while let SSL object itself serving the > tunnel ? Or I can only depend on the CTX ref after the SSL is delete? > > Regards, > Hyer Low > > >> On Mar 6, 2020 at 7:00 PM, > wrote: >> >> One other thing does occur: if you allow renegotiation then you might >> need access to the cert-store after the initial handshake has completed. >> >> Matt >> >> >> On 06/03/2020 10:57, Hyer Low wrote: >> > All configs can have different cert being setup as well, hence each CTX cert >> > store might also different and not to be share. >> > >> > Thanks. I'll try and see any possible side effect. >> > >> > >> > >> > -- >> > Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html >> > >> From kheemen at hotmail.com Fri Mar 6 11:28:48 2020 From: kheemen at hotmail.com (Hyer Low) Date: Fri, 6 Mar 2020 19:28:48 +0800 Subject: How to cleanup CRL memory used after SSL(OpenSSL) handshake has completed? In-Reply-To: <36cf3da7-710d-2600-f917-a546074f8c33@openssl.org> Message-ID: Good to know that. Regards, Kheemen > > On Mar 6, 2020 at 7:24 PM, wrote: > > > > The CTX needs to be there for the whole time that the SSL is. Matt On 06/03/2020 11:17, Hyer Low wrote: > Noted. Renegotiation has been disable. > > Is there anyway to clean the CTX while let SSL object itself serving the > tunnel ? Or I can only depend on the CTX ref after the SSL is delete? > > Regards, > Hyer Low > > >> On Mar 6, 2020 at 7:00 PM, > wrote: >> >> One other thing does occur: if you allow renegotiation then you might >> need access to the cert-store after the initial handshake has completed. >> >> Matt >> >> >> On 06/03/2020 10:57, Hyer Low wrote: >> > All configs can have different cert being setup as well, hence each CTX cert >> > store might also different and not to be share. >> > >> > Thanks. I'll try and see any possible side effect. >> > >> > >> > >> > -- >> > Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Fri Mar 6 18:07:30 2020 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 6 Mar 2020 18:07:30 +0000 Subject: Current master fails test Message-ID: <0D0BBFF9-B3C1-45D4-92D8-679A170570A3@ll.mit.edu> You probably already noticed, but if not? MacOS Mojave 10.14.6, Xcode 11.3.1. Current OpenSSL master (OpenSSL 3.0 dev) with PR 11193 applied (latest variant). Test Summary Report ------------------- 25-test_req.t (Wstat: 512 Tests: 15 Failed: 2) Failed tests: 14-15 Non-zero exit status: 2 25-test_verify_store.t (Wstat: 256 Tests: 10 Failed: 1) Failed test: 4 Non-zero exit status: 1 80-test_ca.t (Wstat: 256 Tests: 6 Failed: 1) Failed test: 4 Non-zero exit status: 1 80-test_ssl_old.t (Wstat: 1536 Tests: 6 Failed: 6) Failed tests: 1-6 Non-zero exit status: 6 Files=192, Tests=1947, 212 wallclock secs ( 2.87 usr 0.69 sys + 144.91 cusr 42.68 csys = 191.15 CPU) Result: FAIL make[1]: *** [_tests] Error 1 make: *** [tests] Error 2 -- Regards, Uri -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: From noloader at gmail.com Sun Mar 8 11:20:34 2020 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 8 Mar 2020 07:20:34 -0400 Subject: bn_ops not being used in Android recipes Message-ID: Hi Everyone, I have a custom 15-android.conf that is used with a custom setenv-android.sh. setenv-android.sh sets the environment and exports the necessary variables for a cross-compile. 15-android.conf was copied from the OpenSSL library, and then modified to avoid some problems with the one supplied with the library that leads to a failed compile under NDK-r20. #### Android... my %targets = ( "android" => { inherit_from => [ "linux-generic32" ], template => 1, bin_cflags => add("-fPIE"), bin_lflags => add("-pie"), enable => [ ], }, "android-arm" => { inherit_from => [ "android", asm("armv4_asm") ], bn_ops => add("BN_LLONG RC4_CHAR"), }, "android-arm64" => { inherit_from => [ "android", asm("aarch64_asm") ], bn_ops => add("SIXTY_FOUR_BIT_LONG RC4_CHAR"), perlasm_scheme => "linux64", }, "android-x86" => { inherit_from => [ "android", asm("x86_asm") ], CFLAGS => add(picker(release => "-fomit-frame-pointer")), bn_ops => add("BN_LLONG RC4_INT"), perlasm_scheme => "android", }, "android-x86_64" => { inherit_from => [ "android", asm("x86_64_asm") ], bn_ops => add("SIXTY_FOUR_BIT_LONG RC4_INT"), perlasm_scheme => "elf", }, ); It looks like bn_ops are not being honored. For example, OpenSSL was configured for android-x86_64, but SIXTY_FOUR_BIT_LONG and RC4_INT are missing: x86_64-linux-android23-clang -I. -Icrypto/include -Iinclude -fPIC -pthread -march=x86-64 -msse4.2 -mpopcnt -mtune=intel -funwind-tables -fexceptions --sysroot=/home/travis/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSLDIR="\"/home/travis/android23-x86_64\"" -DENGINESDIR="\"/home/travis/android23-x86_64/lib/engines-1.1\"" -DNDEBUG -D__ANDROID_API__=23 -MMD -MF crypto/bn/bn_add.d.tmp -MT crypto/bn/bn_add.o -c -o crypto/bn/bn_add.o crypto/bn/bn_add.c x86_64-linux-android23-clang -I. -Icrypto/include -Iinclude -fPIC -pthread -march=x86-64 -msse4.2 -mpopcnt -mtune=intel -funwind-tables -fexceptions --sysroot=/home/travis/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSLDIR="\"/home/travis/android23-x86_64\"" -DENGINESDIR="\"/home/travis/android23-x86_64/lib/engines-1.1\"" -DNDEBUG -D__ANDROID_API__=23 -MMD -MF crypto/bn/bn_asm.d.tmp -MT crypto/bn/bn_asm.o -c -o crypto/bn/bn_asm.o crypto/bn/bn_asm.c crypto/bn/bn_asm.c:28:9: warning: shift count >= width of type [-Wshift-count-overflow] mul_add(rp[0], ap[0], w, c1); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ crypto/bn/bn_lcl.h:475:14: note: expanded from macro 'mul_add' (c)= Hw(t); \ ^~~~~ crypto/bn/bn_lcl.h:469:36: note: expanded from macro 'Hw' # define Hw(t) (((BN_ULONG)((t)>>BN_BITS2))&BN_MASK2) The full build is available at https://travis-ci.org/noloader/unbound/jobs/659771319. How do I get the machinery to use bn_ops? Jeff From barber.m.kristin at gmail.com Mon Mar 9 04:18:17 2020 From: barber.m.kristin at gmail.com (Kristin Barber) Date: Mon, 9 Mar 2020 00:18:17 -0400 Subject: Compiling for RISC-V Message-ID: Hello, I've looked at the INSTALL docs, and it doesn't seem that RISC-V processors are supported currently as a platform. Is this correct? Is there a branch which enables configuring for a RISC-V machine that hasn't yet made it into a stable release? Any advice on where to look for information or changes to the build process in order to compile for RISC-V? -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Mar 9 07:03:26 2020 From: levitte at openssl.org (Richard Levitte) Date: Mon, 09 Mar 2020 08:03:26 +0100 Subject: Compiling for RISC-V In-Reply-To: References: Message-ID: <87tv2y6mdd.wl-levitte@openssl.org> On Mon, 09 Mar 2020 05:18:17 +0100, Kristin Barber wrote: > I've looked at the INSTALL docs, and it doesn't seem that RISC-V processors are supported > currently as a platform. Is this correct? That is correct. No one has implemented that support yet. > Is there a branch which enables configuring for a RISC-V machine that hasn't yet made it into a > stable release??? Not that I know of. Although, this same question has also been raised on github (I forget the issue number). > Any advice on where to look for information or changes to the build process in order to compile > for RISC-V? The first thing to attempt is a generic build with no assembler. There are some really simply config targets that could be a first step, one of: ./Configure cc ./Configure gcc A (pretty big) step up from that, at least if Linux is your target, would be one of these: ./Configure linux-generic32 ./Configure linux-generic64 Note that in either case, you may have to add C flags and ld flags, which you can do in one of two ways: 1) directly on the configuration command line, like this (Configure makes an educated guess on what flags go where): ./Configure linux-generic64 -m64 -DWHATEVER=value -Wl,-something 2) via "make variable" assignment: ./Configure linux-generic64 \ CPPFLAGS='-DWHATEVER=value' \ CFLAGS='-m64' \ LDFLAGS='-Wl,-something' At some point, you might find a combination that works for you. We would definitely like to know what you figure out, and it may be that the result makes it into our database of config targets (which, if you're curious, are the files Configurations/*.conf). Now, configuration is the easy bit when it comes to new CPUs, relatively speaking. I assume that part of your question is whether there is assembler support. This is the hard part in terms of effort. We currently have no such thing at all for RISC-V, and I haven't seen any attempts to start such an effort... PRs would certainly be welcome, but anyone who tries this will have to be prepared for it to take a while to get into the main source. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kevin.lengauer at adnovum.ch Mon Mar 9 16:29:50 2020 From: kevin.lengauer at adnovum.ch (K Lengauer) Date: Mon, 9 Mar 2020 09:29:50 -0700 (MST) Subject: Problems porting Openssl 1.1.1d to zos. In-Reply-To: References: <9f376311-0608-c59b-cdf4-ff92a8b26cff@tibco.com> <1583146994563-0.post@n7.nabble.com> <8ffd49d6-3270-0854-1ad1-f40a5fd12303@gmail.com> <1583335623698-0.post@n7.nabble.com> <36E03C4F-7A66-407B-A154-2E02F2C03021@akamai.com> Message-ID: <1583771390427-0.post@n7.nabble.com> Dear Patrick and co I am currently stuck during my build with the following error: IKJ56228I DATA SET CEE.SCEEBND2 NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED FSUM3052 The data definition name SYSLIB cannot be resolved. The data set was not found. Ensure that data set name CEE.SCEEBND2 is specified correctly. It seems there is some binder error. Did you face this or a similar error as well? Sadly the zOS data sets are still a bit confusing to me and I am still going through the IBM documentation to get a better understanding. I was told by a colleague to try adding some "INCLUDE"s to include various CEE.SCEELIB(*) and setting SYSLIB="//CEE.SCEEBND2" but that did not work so far. How did you configure this with respect to OpenSSL? Or is this something specific to our system? -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From Michael.Wojcik at microfocus.com Mon Mar 9 16:39:05 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 9 Mar 2020 16:39:05 +0000 Subject: Problems porting Openssl 1.1.1d to zos. In-Reply-To: <1583771390427-0.post@n7.nabble.com> References: <9f376311-0608-c59b-cdf4-ff92a8b26cff@tibco.com> <1583146994563-0.post@n7.nabble.com> <8ffd49d6-3270-0854-1ad1-f40a5fd12303@gmail.com> <1583335623698-0.post@n7.nabble.com> <36E03C4F-7A66-407B-A154-2E02F2C03021@akamai.com> , <1583771390427-0.post@n7.nabble.com> Message-ID: It's been years since I compiled C programs on z, but CEE.SCEEBND2 is the C library dataset (for AMODE 64), so it looks like the message is simply saying that it's not cataloged. That would appear to be a site-specific installation issue with the C compiler. See for example this topic from the IBM docs: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceeam00/cllexx.htm in which the JCL includes a straightforward DD card for CEE.SCEEBND2. It appears IBM expects that in a normal installation of the C compiler, that dataset will be in the catalog. That said, the specific location of the SCEEBND2 dataset appears to be a convention. The text of that topic goes on to say: "The Language Environment resident routines are contained in the SCEEBND2 library; the data set name could be CEE.SCEEBND2. If you are unsure where SCEEBND2 has been installed at your location, contact your system administrator." So, I suggest contacting your system administrator and asking where SCEEBND2 is. Or you could try searching the catalog for it using the appropriate ISPF or TSO commands. ________________________________ From: openssl-users on behalf of K Lengauer Sent: Monday, March 9, 2020 10:29 To: openssl-users at openssl.org Subject: Re: Problems porting Openssl 1.1.1d to zos. Dear Patrick and co I am currently stuck during my build with the following error: IKJ56228I DATA SET CEE.SCEEBND2 NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED FSUM3052 The data definition name SYSLIB cannot be resolved. The data set was not found. Ensure that data set name CEE.SCEEBND2 is specified correctly. It seems there is some binder error. Did you face this or a similar error as well? Sadly the zOS data sets are still a bit confusing to me and I am still going through the IBM documentation to get a better understanding. I was told by a colleague to try adding some "INCLUDE"s to include various CEE.SCEELIB(*) and setting SYSLIB="//CEE.SCEEBND2" but that did not work so far. How did you configure this with respect to OpenSSL? Or is this something specific to our system? -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From barber.m.kristin at gmail.com Mon Mar 9 19:02:35 2020 From: barber.m.kristin at gmail.com (Kristin Barber) Date: Mon, 9 Mar 2020 15:02:35 -0400 Subject: Compiling for RISC-V In-Reply-To: <87tv2y6mdd.wl-levitte@openssl.org> References: <87tv2y6mdd.wl-levitte@openssl.org> Message-ID: Hi Richard, thanks for the reply. It was helpful. You are correct, I was able to find a configuration that worked by passing the RISC-V compiler via "make variable" assignment, along with some relevant options. Things start compiling, but the build fails on what seems to be architecture-specific assembly files which are selected based on which "platform" has been configured. It did not seem to me that there were RISC-V assembly-specific files as an option here, and based on your reply, I think that is indeed the issue. Am I understanding this correctly? Thanks, Kristin On Mon, Mar 9, 2020 at 3:03 AM Richard Levitte wrote: > On Mon, 09 Mar 2020 05:18:17 +0100, > Kristin Barber wrote: > > I've looked at the INSTALL docs, and it doesn't seem that RISC-V > processors are supported > > currently as a platform. Is this correct? > > That is correct. No one has implemented that support yet. > > > Is there a branch which enables configuring for a RISC-V machine that > hasn't yet made it into a > > stable release? > > Not that I know of. Although, this same question has also been raised > on github (I forget the issue number). > > > Any advice on where to look for information or changes to the build > process in order to compile > > for RISC-V? > > The first thing to attempt is a generic build with no assembler. > There are some really simply config targets that could be a first > step, one of: > > ./Configure cc > > ./Configure gcc > > A (pretty big) step up from that, at least if Linux is your target, > would be one of these: > > ./Configure linux-generic32 > > ./Configure linux-generic64 > > Note that in either case, you may have to add C flags and ld flags, > which you can do in one of two ways: > > 1) directly on the configuration command line, like this (Configure > makes an educated guess on what flags go where): > > ./Configure linux-generic64 -m64 -DWHATEVER=value -Wl,-something > > 2) via "make variable" assignment: > > ./Configure linux-generic64 \ > CPPFLAGS='-DWHATEVER=value' \ > CFLAGS='-m64' \ > LDFLAGS='-Wl,-something' > > At some point, you might find a combination that works for you. We > would definitely like to know what you figure out, and it may be that > the result makes it into our database of config targets (which, if > you're curious, are the files Configurations/*.conf). > > Now, configuration is the easy bit when it comes to new CPUs, > relatively speaking. I assume that part of your question is whether > there is assembler support. This is the hard part in terms of > effort. We currently have no such thing at all for RISC-V, and I > haven't seen any attempts to start such an effort... PRs would > certainly be welcome, but anyone who tries this will have to be > prepared for it to take a while to get into the main source. > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott_n at xypro.com Mon Mar 9 19:12:13 2020 From: scott_n at xypro.com (Scott Neugroschl) Date: Mon, 9 Mar 2020 19:12:13 +0000 Subject: Compiling for RISC-V In-Reply-To: References: <87tv2y6mdd.wl-levitte@openssl.org> Message-ID: Is the ?no-asm? configuration option still supported? From: openssl-users On Behalf Of Kristin Barber Sent: Monday, March 9, 2020 12:03 PM To: Richard Levitte Cc: openssl-users at openssl.org Subject: Re: Compiling for RISC-V Hi Richard, thanks for the reply. It was helpful. You are correct, I was able to find a configuration that worked by passing the RISC-V compiler via "make variable" assignment, along with some relevant options. Things start compiling, but the build fails on what seems to be architecture-specific assembly files which are selected based on which "platform" has been configured. It did not seem to me that there were RISC-V assembly-specific files as an option here, and based on your reply, I think that is indeed the issue. Am I understanding this correctly? Thanks, Kristin On Mon, Mar 9, 2020 at 3:03 AM Richard Levitte > wrote: On Mon, 09 Mar 2020 05:18:17 +0100, Kristin Barber wrote: > I've looked at the INSTALL docs, and it doesn't seem that RISC-V processors are supported > currently as a platform. Is this correct? That is correct. No one has implemented that support yet. > Is there a branch which enables configuring for a RISC-V machine that hasn't yet made it into a > stable release? Not that I know of. Although, this same question has also been raised on github (I forget the issue number). > Any advice on where to look for information or changes to the build process in order to compile > for RISC-V? The first thing to attempt is a generic build with no assembler. There are some really simply config targets that could be a first step, one of: ./Configure cc ./Configure gcc A (pretty big) step up from that, at least if Linux is your target, would be one of these: ./Configure linux-generic32 ./Configure linux-generic64 Note that in either case, you may have to add C flags and ld flags, which you can do in one of two ways: 1) directly on the configuration command line, like this (Configure makes an educated guess on what flags go where): ./Configure linux-generic64 -m64 -DWHATEVER=value -Wl,-something 2) via "make variable" assignment: ./Configure linux-generic64 \ CPPFLAGS='-DWHATEVER=value' \ CFLAGS='-m64' \ LDFLAGS='-Wl,-something' At some point, you might find a combination that works for you. We would definitely like to know what you figure out, and it may be that the result makes it into our database of config targets (which, if you're curious, are the files Configurations/*.conf). Now, configuration is the easy bit when it comes to new CPUs, relatively speaking. I assume that part of your question is whether there is assembler support. This is the hard part in terms of effort. We currently have no such thing at all for RISC-V, and I haven't seen any attempts to start such an effort... PRs would certainly be welcome, but anyone who tries this will have to be prepared for it to take a while to get into the main source. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From barber.m.kristin at gmail.com Mon Mar 9 19:23:09 2020 From: barber.m.kristin at gmail.com (Kristin Barber) Date: Mon, 9 Mar 2020 15:23:09 -0400 Subject: Compiling for RISC-V In-Reply-To: References: <87tv2y6mdd.wl-levitte@openssl.org> Message-ID: I did also try configuring for "no-asm", but there still seemed to be architecture-specific issues based on which files the errors were coming from. I should probably also mention that I am attempting to cross-compile for RV64 from an x86 machine. On Mon, Mar 9, 2020 at 3:12 PM Scott Neugroschl wrote: > > > Is the ?no-asm? configuration option still supported? > > > > *From:* openssl-users *On Behalf Of *Kristin > Barber > *Sent:* Monday, March 9, 2020 12:03 PM > *To:* Richard Levitte > *Cc:* openssl-users at openssl.org > *Subject:* Re: Compiling for RISC-V > > > > Hi Richard, thanks for the reply. It was helpful. > > > > You are correct, I was able to find a configuration that worked by passing > the RISC-V compiler via "make variable" assignment, along with some > relevant options. Things start compiling, but the build fails on what > seems to be architecture-specific assembly files which are selected based > on which "platform" has been configured. It did not seem to me that there > were RISC-V assembly-specific files as an option here, and based on your > reply, I think that is indeed the issue. Am I understanding this correctly? > > > > Thanks, > > > > Kristin > > > > On Mon, Mar 9, 2020 at 3:03 AM Richard Levitte > wrote: > > On Mon, 09 Mar 2020 05:18:17 +0100, > Kristin Barber wrote: > > I've looked at the INSTALL docs, and it doesn't seem that RISC-V > processors are supported > > currently as a platform. Is this correct? > > That is correct. No one has implemented that support yet. > > > Is there a branch which enables configuring for a RISC-V machine that > hasn't yet made it into a > > stable release? > > Not that I know of. Although, this same question has also been raised > on github (I forget the issue number). > > > Any advice on where to look for information or changes to the build > process in order to compile > > for RISC-V? > > The first thing to attempt is a generic build with no assembler. > There are some really simply config targets that could be a first > step, one of: > > ./Configure cc > > ./Configure gcc > > A (pretty big) step up from that, at least if Linux is your target, > would be one of these: > > ./Configure linux-generic32 > > ./Configure linux-generic64 > > Note that in either case, you may have to add C flags and ld flags, > which you can do in one of two ways: > > 1) directly on the configuration command line, like this (Configure > makes an educated guess on what flags go where): > > ./Configure linux-generic64 -m64 -DWHATEVER=value -Wl,-something > > 2) via "make variable" assignment: > > ./Configure linux-generic64 \ > CPPFLAGS='-DWHATEVER=value' \ > CFLAGS='-m64' \ > LDFLAGS='-Wl,-something' > > At some point, you might find a combination that works for you. We > would definitely like to know what you figure out, and it may be that > the result makes it into our database of config targets (which, if > you're curious, are the files Configurations/*.conf). > > Now, configuration is the easy bit when it comes to new CPUs, > relatively speaking. I assume that part of your question is whether > there is assembler support. This is the hard part in terms of > effort. We currently have no such thing at all for RISC-V, and I > haven't seen any attempts to start such an effort... PRs would > certainly be welcome, but anyone who tries this will have to be > prepared for it to take a while to get into the main source. > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhb at FreeBSD.org Mon Mar 9 21:12:00 2020 From: jhb at FreeBSD.org (John Baldwin) Date: Mon, 9 Mar 2020 14:12:00 -0700 Subject: Compiling for RISC-V In-Reply-To: References: <87tv2y6mdd.wl-levitte@openssl.org> Message-ID: <818c87dc-c398-929a-df4a-47707c8ac8dd@FreeBSD.org> FreeBSD ships OpenSSL 1.1.1 for FreeBSD/riscv (which is RV64 only). I don't recall having to do anything unusual to get OpenSSL to build or run on RISC-V for that. On 3/9/20 12:23 PM, Kristin Barber wrote: > I did also try configuring for "no-asm", but there still seemed to be > architecture-specific issues based on which files the errors were coming > from. I should probably also mention that I am attempting to cross-compile > for RV64 from an x86 machine. > > On Mon, Mar 9, 2020 at 3:12 PM Scott Neugroschl wrote: > >> >> >> Is the ?no-asm? configuration option still supported? >> >> >> >> *From:* openssl-users *On Behalf Of *Kristin >> Barber >> *Sent:* Monday, March 9, 2020 12:03 PM >> *To:* Richard Levitte >> *Cc:* openssl-users at openssl.org >> *Subject:* Re: Compiling for RISC-V >> >> >> >> Hi Richard, thanks for the reply. It was helpful. >> >> >> >> You are correct, I was able to find a configuration that worked by passing >> the RISC-V compiler via "make variable" assignment, along with some >> relevant options. Things start compiling, but the build fails on what >> seems to be architecture-specific assembly files which are selected based >> on which "platform" has been configured. It did not seem to me that there >> were RISC-V assembly-specific files as an option here, and based on your >> reply, I think that is indeed the issue. Am I understanding this correctly? >> >> >> >> Thanks, >> >> >> >> Kristin >> >> >> >> On Mon, Mar 9, 2020 at 3:03 AM Richard Levitte >> wrote: >> >> On Mon, 09 Mar 2020 05:18:17 +0100, >> Kristin Barber wrote: >>> I've looked at the INSTALL docs, and it doesn't seem that RISC-V >> processors are supported >>> currently as a platform. Is this correct? >> >> That is correct. No one has implemented that support yet. >> >>> Is there a branch which enables configuring for a RISC-V machine that >> hasn't yet made it into a >>> stable release? >> >> Not that I know of. Although, this same question has also been raised >> on github (I forget the issue number). >> >>> Any advice on where to look for information or changes to the build >> process in order to compile >>> for RISC-V? >> >> The first thing to attempt is a generic build with no assembler. >> There are some really simply config targets that could be a first >> step, one of: >> >> ./Configure cc >> >> ./Configure gcc >> >> A (pretty big) step up from that, at least if Linux is your target, >> would be one of these: >> >> ./Configure linux-generic32 >> >> ./Configure linux-generic64 >> >> Note that in either case, you may have to add C flags and ld flags, >> which you can do in one of two ways: >> >> 1) directly on the configuration command line, like this (Configure >> makes an educated guess on what flags go where): >> >> ./Configure linux-generic64 -m64 -DWHATEVER=value -Wl,-something >> >> 2) via "make variable" assignment: >> >> ./Configure linux-generic64 \ >> CPPFLAGS='-DWHATEVER=value' \ >> CFLAGS='-m64' \ >> LDFLAGS='-Wl,-something' >> >> At some point, you might find a combination that works for you. We >> would definitely like to know what you figure out, and it may be that >> the result makes it into our database of config targets (which, if >> you're curious, are the files Configurations/*.conf). >> >> Now, configuration is the easy bit when it comes to new CPUs, >> relatively speaking. I assume that part of your question is whether >> there is assembler support. This is the hard part in terms of >> effort. We currently have no such thing at all for RISC-V, and I >> haven't seen any attempts to start such an effort... PRs would >> certainly be welcome, but anyone who tries this will have to be >> prepared for it to take a while to get into the main source. >> >> Cheers, >> Richard >> >> -- >> Richard Levitte levitte at openssl.org >> OpenSSL Project http://www.openssl.org/~levitte/ >> >> >> > -- John Baldwin From levitte at openssl.org Tue Mar 10 01:30:12 2020 From: levitte at openssl.org (Richard Levitte) Date: Tue, 10 Mar 2020 02:30:12 +0100 Subject: Compiling for RISC-V In-Reply-To: References: <87tv2y6mdd.wl-levitte@openssl.org> Message-ID: <87r1y16lp7.wl-levitte@openssl.org> Hi, when you mentioned cross compiling, that got me a bit more curious, so I went looking, and noticed that Debian [sid] (which is what I run on my laptop) has all the cross compiling tools I needed (see https://wiki.debian.org/RISC-V#Cross_compilation), so I installed them, and then tried this in my checkout of OpenSSL's master branch: ./Configure linux-generic64 no-asm no-threads \ --cross-compile-prefix=riscv64-linux-gnu- Running 'make' was a breeze, it went through flawlessly. I haven't done much further tests, though. Cheers, Richard On Mon, 09 Mar 2020 20:23:09 +0100, Kristin Barber wrote: > > > I did also try configuring for "no-asm", but there still seemed to be architecture-specific issues > based on which files the errors were coming from.? I should?probably also mention that I am > attempting to cross-compile for RV64 from an x86 machine. > > On Mon, Mar 9, 2020 at 3:12 PM Scott Neugroschl wrote: > > ? > > Is the ?no-asm? configuration option still supported? > > ? > > From: openssl-users On Behalf Of Kristin Barber > Sent: Monday, March 9, 2020 12:03 PM > To: Richard Levitte > Cc: openssl-users at openssl.org > Subject: Re: Compiling for RISC-V > > ? > > Hi Richard, thanks for the reply. It was helpful. > > ? > > You are correct, I was able to find a configuration that worked by passing the RISC-V compiler > via "make variable" assignment, along with some relevant options.? Things start compiling, but > the build fails on what seems to be architecture-specific assembly files which are selected > based on which "platform" has been configured.? It did not seem to me that there were RISC-V > assembly-specific files as an option here, and based on your reply, I think that is indeed the > issue.? Am I understanding this correctly? > > ? > > Thanks, > > ? > > Kristin > > ? > > On Mon, Mar 9, 2020 at 3:03 AM Richard Levitte wrote: > > On Mon, 09 Mar 2020 05:18:17 +0100, > Kristin Barber wrote: > > I've looked at the INSTALL docs, and it doesn't seem that RISC-V processors are > supported > > currently as a platform. Is this correct? > > That is correct.? No one has implemented that support yet. > > > Is there a branch which enables configuring for a RISC-V machine that hasn't yet made it > into a > > stable release??? > > Not that I know of.? Although, this same question has also been raised > on github (I forget the issue number). > > > Any advice on where to look for information or changes to the build process in order to > compile > > for RISC-V? > > The first thing to attempt is a generic build with no assembler. > There are some really simply config targets that could be a first > step, one of: > > ? ? ./Configure cc > > ? ? ./Configure gcc > > A (pretty big) step up from that, at least if Linux is your target, > would be one of these: > > ? ? ./Configure linux-generic32 > > ? ? ./Configure linux-generic64 > > Note that in either case, you may have to add C flags and ld flags, > which you can do in one of two ways: > > 1)? directly on the configuration command line, like this (Configure > ? ? makes an educated guess on what flags go where): > > ? ? ./Configure linux-generic64 -m64 -DWHATEVER=value -Wl,-something > > 2)? via "make variable" assignment: > > ? ? ./Configure linux-generic64 \ > ? ? ? ? ? ? ? ? CPPFLAGS='-DWHATEVER=value' \ > ? ? ? ? ? ? ? ? CFLAGS='-m64' \ > ? ? ? ? ? ? ? ? LDFLAGS='-Wl,-something' > > At some point, you might find a combination that works for you.? We > would definitely like to know what you figure out, and it may be that > the result makes it into our database of config targets (which, if > you're curious, are the files Configurations/*.conf). > > Now, configuration is the easy bit when it comes to new CPUs, > relatively speaking.? I assume that part of your question is whether > there is assembler support.? This is the hard part in terms of > effort.? We currently have no such thing at all for RISC-V, and I > haven't seen any attempts to start such an effort...? PRs would > certainly be welcome, but anyone who tries this will have to be > prepared for it to take a while to get into the main source. > > Cheers, > Richard > > -- > Richard Levitte? ? ? ? ?levitte at openssl.org > OpenSSL Project? ? ? ? ?http://www.openssl.org/~levitte/ > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kaushalshriyan at gmail.com Tue Mar 10 16:26:42 2020 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Tue, 10 Mar 2020 21:56:42 +0530 Subject: Negotiated cipher per proto (matching cipher in list missing). No further cipher order check has been done as order is determined by the client Message-ID: Hi, I have run the below tests ./testssl.sh gsmasslciphers.digitalapicraft.com > ########################################################### > testssl.sh 3.1dev from https://testssl.sh/dev/ > (e0c83b2 2020-02-24 14:21:28 -- ) > This program is free software. Distribution and > modification under GPLv2 permitted. > USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK! > Please file bugs @ https://testssl.sh/bugs/ > ########################################################### > Using "OpenSSL 1.0.2-chacha (1.0.2k-dev)" [~183 ciphers] > on Kaushals-MacBook-Pro:./bin/openssl.Darwin.x86_64 > (built: "Feb 22 09:55:43 2019", platform: "darwin64-x86_64-cc") > > Start 2020-03-10 21:50:25 -->> 13.234.216.57:443 ( > gsmasslciphers.digitalapicraft.com) <<-- > rDNS (13.234.216.57): -- > Service detected: HTTP > > Testing protocols via sockets except NPN+ALPN > SSLv2 not offered (OK) > SSLv3 not offered (OK) > TLS 1 not offered > TLS 1.1 not offered > TLS 1.2 offered (OK) > TLS 1.3 not offered and downgraded to a weaker protocol > NPN/SPDY h2, http/1.1 (advertised) > ALPN/HTTP2 h2, http/1.1 (offered) > Testing cipher categories > NULL ciphers (no encryption) not offered (OK) > Anonymous NULL Ciphers (no authentication) not offered (OK) > Export ciphers (w/o ADH+NULL) not offered (OK) > LOW: 64 Bit + DES, RC[2,4] (w/o export) not offered (OK) > Triple DES Ciphers / IDEA not offered > Obsolete: SEED + 128+256 Bit CBC cipher not offered > Strong encryption (AEAD ciphers) offered (OK) > > Testing robust (perfect) forward secrecy, (P)FS -- omitting Null > Authentication/Encryption, 3DES, RC4 > PFS is offered (OK) ECDHE-RSA-AES256-GCM-SHA384 > ECDHE-RSA-AES128-GCM-SHA256 > Elliptic curves offered: secp256k1 prime256v1 secp384r1 secp521r1 > > Testing server preferences > Has server cipher order? no (NOT ok) > Negotiated protocol TLSv1.2 > Negotiated cipher ECDHE-RSA-AES128-GCM-SHA256, 521 bit ECDH > (P-521) -- inconclusive test, matching cipher in list missing, better see > below > Negotiated cipher per proto (matching cipher in list missing) > ECDHE-RSA-AES256-GCM-SHA384: TLSv1.2 > No further cipher order check has been done as order is determined by the > client > > Testing server defaults (Server Hello) > TLS extensions (standard) "server name/#0" "renegotiation info/#65281" > "EC point formats/#11" "session ticket/#35" "heartbeat/#15" "next > protocol/#13172" "application layer protocol negotiation/#16" > Session Ticket RFC 5077 hint 86400 seconds, session tickets keys seems to > be rotated < daily > SSL Session ID support yes > Session Resumption Tickets: yes, ID: yes > TLS clock skew Random values, no fingerprinting possible > Signature Algorithm SHA256 with RSA > Server key size RSA 2048 bits > Server key usage Digital Signature, Key Encipherment > Server extended key usage TLS Web Server Authentication, TLS Web > Client Authentication > Serial / Fingerprints 03C871BF68E569B4330E4AFCFA7752AAB5D7 / SHA1 > 8874D965CB96F4A4B8B4CCAE149B6F1999399BF8 > SHA256 > BB56659442E2ED18778F7BB210823F3A81DA88F3AF79D0EE2104CE82DBB03C65 > Common Name (CN) gsmasslciphers.digitalapicraft.com > subjectAltName (SAN) gsmasslciphers.digitalapicraft.com > Issuer Let's Encrypt Authority X3 (Let's Encrypt > from US) > Trust (hostname) Ok via SAN (same w/o SNI) > Chain of trust Ok > EV cert (experimental) no > ETS/"eTLS", visibility info not present > Certificate Validity (UTC) 89 >= 30 days (2020-03-10 09:40 --> > 2020-06-08 09:40) > # of certificates provided 2 > Certificate Revocation List -- > OCSP URI http://ocsp.int-x3.letsencrypt.org > OCSP stapling not offered > OCSP must staple extension -- > DNS CAA RR (experimental) not offered > Certificate Transparency yes (certificate extension) > > Testing HTTP header response @ "/" > HTTP Status Code 200 OK > HTTP clock skew 0 sec from localtime > Strict Transport Security 730 days=63072000 s, just this domain > Public Key Pinning -- > Server banner nginx/1.16.1 > Application banner -- > Cookie(s) (none issued at "/") > Security headers -- > Reverse Proxy banner -- > > Testing vulnerabilities > Heartbleed (CVE-2014-0160) not vulnerable (OK), timed out > CCS (CVE-2014-0224) not vulnerable (OK) > Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK) > ROBOT Server does not support any > cipher suites that use RSA key transport > Secure Renegotiation (RFC 5746) supported (OK) > Secure Client-Initiated Renegotiation not vulnerable (OK) > CRIME, TLS (CVE-2012-4929) not vulnerable (OK) > BREACH (CVE-2013-3587) no HTTP compression (OK) - > only supplied "/" tested > POODLE, SSL (CVE-2014-3566) not vulnerable (OK), no SSLv3 > support > TLS_FALLBACK_SCSV (RFC 7507) No fallback possible (OK), no > protocol below TLS 1.2 offered > SWEET32 (CVE-2016-2183, CVE-2016-6329) not vulnerable (OK) > FREAK (CVE-2015-0204) not vulnerable (OK) > DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and > port (OK) > make sure you don't use this > certificate elsewhere with SSLv2 enabled services > > https://censys.io/ipv4?q=BB56659442E2ED18778F7BB210823F3A81DA88F3AF79D0EE2104CE82DBB03C65 > could help you to find out > LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH > EXPORT ciphers, no DH key detected with <= TLS 1.2 > BEAST (CVE-2011-3389) not vulnerable (OK), no SSL3 or > TLS1 > LUCKY13 (CVE-2013-0169), experimental not vulnerable (OK) > RC4 (CVE-2013-2566, CVE-2015-2808) no RC4 ciphers detected (OK) > > Testing 370 ciphers via OpenSSL plus sockets against the server, ordered > by encryption strength > Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits > Cipher Suite Name (IANA/RFC) > > ----------------------------------------------------------------------------------------------------------------------------- > xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 521 AESGCM 256 > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 521 AESGCM 128 > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > > Running client simulations (HTTP) via sockets > Android 4.4.2 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 521 bit > ECDH (P-521) > Android 5.0.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 521 bit > ECDH (P-521) > Android 6.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit > ECDH (P-256) > Android 7.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit > ECDH (P-256) > Android 8.1 (native) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit > ECDH (P-256) > Android 9.0 (native) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit > ECDH (P-256) > Android 10.0 (native) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit > ECDH (P-256) > Chrome 74 (Win 10) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit > ECDH (P-256) > Chrome 79 (Win 10) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit > ECDH (P-256) > Firefox 66 (Win 8.1/10) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit > ECDH (P-256) > Firefox 71 (Win 10) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit > ECDH (P-256) > IE 6 XP No connection > IE 8 Win 7 No connection > IE 8 XP No connection > IE 11 Win 7 No connection > IE 11 Win 8.1 No connection > IE 11 Win Phone 8.1 No connection > IE 11 Win 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit > ECDH (P-256) > Edge 15 Win 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit > ECDH (P-256) > Edge 17 (Win 10) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit > ECDH (P-256) > Opera 66 (Win 10) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit > ECDH (P-256) > Safari 9 iOS 9 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit > ECDH (P-256) > Safari 9 OS X 10.11 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit > ECDH (P-256) > Safari 10 OS X 10.12 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit > ECDH (P-256) > Safari 12.1 (iOS 12.2) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit > ECDH (P-256) > Safari 13.0 (macOS 10.14.6) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit > ECDH (P-256) > Apple ATS 9 iOS 9 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit > ECDH (P-256) > Java 6u45 No connection > Java 7u25 No connection > Java 8u161 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit > ECDH (P-256) > Java 11.0.2 (OpenJDK) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit > ECDH (P-256) > Java 12.0.1 (OpenJDK) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit > ECDH (P-256) > OpenSSL 1.0.2e TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit > ECDH (P-256) > OpenSSL 1.1.0l (Debian) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit > ECDH (P-256) > OpenSSL 1.1.1d (Debian) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit > ECDH (P-256) > Thunderbird (68.3) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit > ECDH (P-256) > Done 2020-03-10 21:52:13 [0130s] -->> 13.234.216.57:443 ( > gsmasslciphers.digitalapicraft.com) <<-- I am not sure about the below explanation as seen in the above output. Testing server preferences > Has server cipher order? no (NOT ok) > Negotiated protocol TLSv1.2 > Negotiated cipher ECDHE-RSA-AES128-GCM-SHA256, 521 bit ECDH > (P-521) -- inconclusive test, matching cipher in list missing, better see > below > Negotiated cipher per proto (matching cipher in list missing) > ECDHE-RSA-AES256-GCM-SHA384: TLSv1.2 > No further cipher order check has been done as order is determined by the > client I will appreciate if someone can help me understand it. Does it mean there is some issue? Thanks in advance and I look forward to hearing from you. Best Regards, Kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: From niki.dinsey at abingdon.org.uk Tue Mar 10 17:05:39 2020 From: niki.dinsey at abingdon.org.uk (Niki Dinsey) Date: Tue, 10 Mar 2020 17:05:39 +0000 Subject: Question about handshake error Message-ID: Hi there, I have an issue I can't seem to work out the answer to. Server: thankqcrm.accessacloud.com root at willis:~# openssl version OpenSSL 1.1.1d 10 Sep 2019 root at willis:~# openssl s_client -connect thankqcrm.accessacloud.com:443 CONNECTED(00000004) 140151269360768:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1544:SSL alert number 40 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 318 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- Works on OpenSSL 1.1.0: root at host:~# openssl version OpenSSL 1.1.0l 10 Sep 2019 root at host:~# openssl s_client -connect thankqcrm.accessacloud.com:443 CONNECTED(00000003) depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA verify return:1 depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte RSA CA 2018 verify return:1 depth=0 CN = *.accessacloud.com verify return:1 --- Certificate chain 0 s:/CN=*.accessacloud.com i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018 i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA 2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA 3 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA --- Server certificate -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- subject=/CN=*.accessacloud.com issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018 --- No client certificate CA names sent --- SSL handshake has read 4999 bytes and written 494 bytes Verification: OK --- New, TLSv1.2, Cipher is 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 : AES128-GCM-SHA256 Session-ID: 05326CD4A0D128684EA530A59504BA8D02E99746AC2E40D0DA8B9B0E18F20CF0 Session-ID-ctx: Master-Key: B423C27867FFB6A021458D860CC8A5A6D947628A8216B5F8DD8D1CF3058545398185B94F772B3A816A15D1442FFF1822 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 14400 (seconds) TLS session ticket: 0000 - e5 7b cf ea bc 3d 6b 9a-59 ec 40 63 01 19 52 6c .{...=k.Y. at c. .Rl 0010 - 72 c4 34 f0 a3 ff 37 f4-58 b1 9a bb 84 fc 94 36 r.4...7.X......6 0020 - 16 8e 39 04 94 e2 fd ae-0f 05 e7 6c 12 94 58 4a ..9........l..XJ 0030 - 09 56 e5 bd 67 d7 e7 17-d4 a8 03 ba 6e 05 be b6 .V..g.......n... 0040 - ce 5d 9a ee 81 73 97 c8-ff 9c be 6b 8f 37 cb bf .]...s.....k.7.. 0050 - 44 76 93 83 95 58 6d b8-63 f6 ba 4d 55 22 d2 14 Dv...Xm.c..MU".. 0060 - 93 09 01 46 f0 fa f1 35-5a 80 0e ab a4 ca 9e c8 ...F...5Z....... 0070 - ed 8f c8 3c 89 e8 91 b3-0e 41 a9 e4 3f 79 f6 63 ...<.....A..?y.c 0080 - e2 62 91 c9 2f 8c 5a dd-b0 a1 55 b3 86 35 62 5a .b../.Z...U..5bZ 0090 - af c2 9a 8a 35 7a 46 3b-3c 2e 24 0d 45 69 96 fc ....5zF;<.$.Ei.. Start Time: 1583859230 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- Works using 1.1.1d if I pass in -tls1_1 root at willis:~# openssl version OpenSSL 1.1.1d 10 Sep 2019 root at willis:~# openssl s_client -connect thankqcrm.accessacloud.com:443 -tls1_1 CONNECTED(00000004) depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA verify return:1 depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte RSA CA 2018 verify return:1 depth=0 CN = *.accessacloud.com verify return:1 --- Certificate chain 0 s:CN = *.accessacloud.com i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte RSA CA 2018 1 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte RSA CA 2018 i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA 2 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA 3 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA --- Server certificate -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- subject=CN = *.accessacloud.com issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte RSA CA 2018 --- No client certificate CA names sent --- SSL handshake has read 5059 bytes and written 481 bytes Verification: OK --- New, SSLv3, Cipher is AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.1 Cipher : AES128-SHA Session-ID: 9438801392B268A70F6B60C25E388481D69638ED8122A274BB0E15111BFF329B Session-ID-ctx: Master-Key: EA86A4D07020F193BC66444A2D16EC67AD9524A6A78D068542B6CAF745D0B51FBE51EA0F9E9A6557561CFD5AE9E2D986 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 14400 (seconds) TLS session ticket: 0000 - e5 7b cf ea bc 3d 6b 9a-59 ec 40 63 01 19 52 6c .{...=k.Y. at c. .Rl 0010 - 3a c0 bc fb ff 57 a2 7f-38 a9 91 64 5e 87 b4 88 :....W..8..d^... 0020 - f2 35 bc 04 b3 27 b3 fc-0f ac 3d 8a 03 a4 59 cb .5...'....=...Y. 0030 - a7 2c 8e 0f f3 a0 a2 13-50 fa 6f 2e 07 eb 1e 89 .,......P.o..... 0040 - 73 0d d0 3e d5 01 68 3a-18 56 00 71 fa 38 1e e0 s..>..h:.V.q.8.. 0050 - 87 15 68 a4 d0 d7 13 67-c7 b1 e6 45 54 fd 22 e1 ..h....g...ET.". 0060 - 65 66 40 6c e3 7e 42 f1-1a 46 32 7b b9 a1 c0 80 ef at l. ~B..F2{.... 0070 - 12 ee f1 d9 92 5f b7 3b-7b 38 66 76 cc af b1 eb ....._.;{8fv.... 0080 - 97 4c 02 af 61 9d 1b 35-c8 64 f5 ce 19 34 42 92 .L..a..5.d...4B. 0090 - a0 0e b9 51 ab de c0 cf-90 bd 65 2b 0b 08 19 3b ...Q......e+...; 00a0 - 2e fe 1f 75 1f b5 b8 48-40 8c 56 d4 dc 82 31 b0 ...u...H@ .V...1. 00b0 - 2f 52 b9 1f 11 f7 d2 63-01 c0 89 57 dd a6 53 56 /R.....c...W..SV Start Time: 1583859354 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- --------------------------------- This error started our of the blue. The vendor confirmed a change in certificate about the same time that curl/'python requests' stopped working. So it looks to me like their cert change caused the issue. Tested on Debian 10 and Ubuntu 20.04 Focal Fossa. Why does this certificate work with tls1.2 on 1.1.0 but not on 1.1.1??? I can force tls1.1, but want to inform the vendor there are problems with their new certificate but don't really understand much of this. Any help appreciated. Regards Niki -- Save the date: Abingdon's first 24hr *Giving Day - 18 March 2020*.Help support our ambition?to double the number of bursaries across the Foundation. -- Abingdon School: A company limited by guarantee Registered in England and Wales. Company No. 3625063? ? Registered Office:? Abingdon School? Park Road Abingdon? OX14 1DE? Registered Charity No. 1071298 ? All information in this message and attachments is confidential and may be legally privileged. Only intended recipients are authorised to use it. E-mail transmissions are not guaranteed to be secure or error free and the sender does not accept liability for such errors or omissions. The company will not accept any liability in respect of such communication that violates our ICT policies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Mar 10 17:25:33 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 10 Mar 2020 17:25:33 +0000 Subject: Question about handshake error In-Reply-To: References: Message-ID: On 10/03/2020 17:05, Niki Dinsey wrote: > Hi there, I have an issue I can't seem to work out the answer to. > > Server: thankqcrm.accessacloud.com > > root at willis:~# openssl version > OpenSSL 1.1.1d ?10 Sep 2019 > root at willis:~# openssl s_client -connect thankqcrm.accessacloud.com:443 > Running the exact same openssl version from my machine, and using the exact same s_client options as you, I get a successful connection. Some possibilities of what might be going wrong: 1) Is it possible there is some middlebox betwen you and the target server that is causing a problem for you on your network? Can you try connecting from s_client from a machine outside your corporate network? or 2) I have sometimes seen load balancers do strange things - where different machines in the cluster are configured differently to each other. This can mean different people see different results - or even if you run the same test at different times you see different results. This could explain why it works in 1.1.0 and not 1.1.1 (i.e. it actually is equally broken - but sometimes you hit the "right" server, and sometimes you hit the "wrong" server). You might want to try from a different machine and see if the same thing happens, and/or repeat the tests periodically (in the hope of hitting different servers in the cluster). or 3) Possibly there is some local problem with your s_client build. Does it work ok for other sites? Matt > CONNECTED(00000004) > 140151269360768:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert > handshake failure:../ssl/record/rec_layer_s3.c:1544:SSL alert number 40 > --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 7 bytes and written 318 bytes > Verification: OK > --- > New, (NONE), Cipher is (NONE) > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > No ALPN negotiated > Early data was not sent > Verify return code: 0 (ok) > --- > > Works on OpenSSL 1.1.0: > > root at host:~# openssl version > OpenSSL 1.1.0l ?10 Sep 2019 > root at host:~# openssl s_client -connect thankqcrm.accessacloud.com:443 > > CONNECTED(00000003) > depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = DigiCert Global Root CA > verify return:1 > depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = Thawte RSA CA 2018 > verify return:1 > depth=0 CN = *.accessacloud.com > verify return:1 > --- > Certificate chain > ?0 s:/CN=*.accessacloud.com > ? ?i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte > RSA CA 2018 > ?1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte > RSA CA 2018 > ? ?i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert > Global Root CA > ?2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert > Global Root CA > ? ?i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert > Global Root CA > ?3 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert > Global Root CA > ? ?i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert > Global Root CA > --- > Server certificate > -----BEGIN CERTIFICATE----- > ... > -----END CERTIFICATE----- > subject=/CN=*.accessacloud.com > issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte > RSA CA 2018 > --- > No client certificate CA names sent > --- > SSL handshake has read 4999 bytes and written 494 bytes > Verification: OK > --- > New, TLSv1.2, Cipher is 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 ? ?: AES128-GCM-SHA256 > ? ? Session-ID: > 05326CD4A0D128684EA530A59504BA8D02E99746AC2E40D0DA8B9B0E18F20CF0 > ? ? Session-ID-ctx: > ? ? Master-Key: > B423C27867FFB6A021458D860CC8A5A6D947628A8216B5F8DD8D1CF3058545398185B94F772B3A816A15D1442FFF1822 > ? ? PSK identity: None > ? ? PSK identity hint: None > ? ? SRP username: None > ? ? TLS session ticket lifetime hint: 14400 (seconds) > ? ? TLS session ticket: > ? ? 0000 - e5 7b cf ea bc 3d 6b 9a-59 ec 40 63 01 19 52 6c ? > .{...=k.Y. at c..Rl > ? ? 0010 - 72 c4 34 f0 a3 ff 37 f4-58 b1 9a bb 84 fc 94 36 ? > r.4...7.X......6 > ? ? 0020 - 16 8e 39 04 94 e2 fd ae-0f 05 e7 6c 12 94 58 4a ? > ..9........l..XJ > ? ? 0030 - 09 56 e5 bd 67 d7 e7 17-d4 a8 03 ba 6e 05 be b6 ? > .V..g.......n... > ? ? 0040 - ce 5d 9a ee 81 73 97 c8-ff 9c be 6b 8f 37 cb bf ? > .]...s.....k.7.. > ? ? 0050 - 44 76 93 83 95 58 6d b8-63 f6 ba 4d 55 22 d2 14 ? > Dv...Xm.c..MU".. > ? ? 0060 - 93 09 01 46 f0 fa f1 35-5a 80 0e ab a4 ca 9e c8 ? > ...F...5Z....... > ? ? 0070 - ed 8f c8 3c 89 e8 91 b3-0e 41 a9 e4 3f 79 f6 63 ? > ...<.....A..?y.c > ? ? 0080 - e2 62 91 c9 2f 8c 5a dd-b0 a1 55 b3 86 35 62 5a ? > .b../.Z...U..5bZ > ? ? 0090 - af c2 9a 8a 35 7a 46 3b-3c 2e 24 0d 45 69 96 fc ? > ....5zF;<.$.Ei.. > > ? ? Start Time: 1583859230 > ? ? Timeout ? : 7200 (sec) > ? ? Verify return code: 0 (ok) > ? ? Extended master secret: no > --- > > > Works using 1.1.1d if I pass in -tls1_1 > > root at willis:~# openssl version > OpenSSL 1.1.1d ?10 Sep 2019 > root at willis:~# openssl s_client -connect thankqcrm.accessacloud.com:443 > -tls1_1 > CONNECTED(00000004) > depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = DigiCert Global Root CA > verify return:1 > depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = Thawte RSA CA 2018 > verify return:1 > depth=0 CN = *.accessacloud.com > verify return:1 > --- > Certificate chain > ?0 s:CN = *.accessacloud.com > ? ?i:C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = Thawte RSA CA 2018 > ?1 s:C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = Thawte RSA CA 2018 > ? ?i:C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = DigiCert Global Root CA > ?2 s:C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = DigiCert Global Root CA > ? ?i:C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = DigiCert Global Root CA > ?3 s:C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = DigiCert Global Root CA > ? ?i:C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = DigiCert Global Root CA > --- > Server certificate > -----BEGIN CERTIFICATE----- > ... > -----END CERTIFICATE----- > subject=CN = *.accessacloud.com > > issuer=C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = Thawte RSA CA 2018 > > --- > No client certificate CA names sent > --- > SSL handshake has read 5059 bytes and written 481 bytes > Verification: OK > --- > New, SSLv3, Cipher is AES128-SHA > Server public key is 2048 bit > Secure Renegotiation IS supported > Compression: NONE > Expansion: NONE > No ALPN negotiated > SSL-Session: > ? ? Protocol ?: TLSv1.1 > ? ? Cipher ? ?: AES128-SHA > ? ? Session-ID: > 9438801392B268A70F6B60C25E388481D69638ED8122A274BB0E15111BFF329B > ? ? Session-ID-ctx: > ? ? Master-Key: > EA86A4D07020F193BC66444A2D16EC67AD9524A6A78D068542B6CAF745D0B51FBE51EA0F9E9A6557561CFD5AE9E2D986 > ? ? PSK identity: None > ? ? PSK identity hint: None > ? ? SRP username: None > ? ? TLS session ticket lifetime hint: 14400 (seconds) > ? ? TLS session ticket: > ? ? 0000 - e5 7b cf ea bc 3d 6b 9a-59 ec 40 63 01 19 52 6c ? > .{...=k.Y. at c..Rl > ? ? 0010 - 3a c0 bc fb ff 57 a2 7f-38 a9 91 64 5e 87 b4 88 ? > :....W..8..d^... > ? ? 0020 - f2 35 bc 04 b3 27 b3 fc-0f ac 3d 8a 03 a4 59 cb ? > .5...'....=...Y. > ? ? 0030 - a7 2c 8e 0f f3 a0 a2 13-50 fa 6f 2e 07 eb 1e 89 ? > .,......P.o..... > ? ? 0040 - 73 0d d0 3e d5 01 68 3a-18 56 00 71 fa 38 1e e0 ? > s..>..h:.V.q.8.. > ? ? 0050 - 87 15 68 a4 d0 d7 13 67-c7 b1 e6 45 54 fd 22 e1 ? > ..h....g...ET.". > ? ? 0060 - 65 66 40 6c e3 7e 42 f1-1a 46 32 7b b9 a1 c0 80 ? > ef at l.~B..F2{.... > ? ? 0070 - 12 ee f1 d9 92 5f b7 3b-7b 38 66 76 cc af b1 eb ? > ....._.;{8fv.... > ? ? 0080 - 97 4c 02 af 61 9d 1b 35-c8 64 f5 ce 19 34 42 92 ? > .L..a..5.d...4B. > ? ? 0090 - a0 0e b9 51 ab de c0 cf-90 bd 65 2b 0b 08 19 3b ? > ...Q......e+...; > ? ? 00a0 - 2e fe 1f 75 1f b5 b8 48-40 8c 56 d4 dc 82 31 b0 ? > ...u...H at .V...1. > ? ? 00b0 - 2f 52 b9 1f 11 f7 d2 63-01 c0 89 57 dd a6 53 56 ? > /R.....c...W..SV > > ? ? Start Time: 1583859354 > ? ? Timeout ? : 7200 (sec) > ? ? Verify return code: 0 (ok) > ? ? Extended master secret: no > --- > > > --------------------------------- > This error started our of the blue. The vendor confirmed a change in > certificate about the same time that curl/'python requests' stopped > working. So it looks to me like their cert change caused the issue. > > Tested on Debian 10 and Ubuntu 20.04 Focal Fossa. > > Why does this certificate work with tls1.2 on 1.1.0 but not on 1.1.1??? > > I can force tls1.1, but want to inform the vendor there are problems > with their new certificate but don't really understand much of this. > > Any help appreciated.? > > Regards > > Niki > > > Save the date: Abingdon's first 24hr *Giving Day - 18 March 2020*. > Help support our ambition?to double the number of bursaries across the > Foundation. > > > > > Abingdon School: A company limited by guarantee Registered in England > and Wales. Company No. 3625063? > ? > Registered Office:? > Abingdon School? > Park Road > Abingdon? > OX14 1DE? > Registered Charity No. 1071298 > ? > All information in this message and attachments is confidential and may > be legally privileged. Only intended recipients are authorised to use > it. E-mail transmissions are not guaranteed to be secure or error free > and the sender does not accept liability for such errors or omissions. > The company will not accept any liability in respect of such > communication that violates our ICT policies. From sfhacker at hotmail.com Tue Mar 10 18:03:03 2020 From: sfhacker at hotmail.com (Sergio NNX) Date: Tue, 10 Mar 2020 18:03:03 +0000 Subject: Question about handshake error In-Reply-To: References: , Message-ID: It seems to work fine here! [cid:e41cb622-8559-442b-9b65-76043c2c4b27] [cid:a3ae8ac2-646c-41c8-9842-4f9bde0aaf71] ________________________________ From: openssl-users on behalf of Matt Caswell Sent: Wednesday, 11 March 2020 4:25 AM To: Niki Dinsey ; openssl-users at openssl.org Subject: Re: Question about handshake error On 10/03/2020 17:05, Niki Dinsey wrote: > Hi there, I have an issue I can't seem to work out the answer to. > > Server: thankqcrm.accessacloud.com > > root at willis:~# openssl version > OpenSSL 1.1.1d 10 Sep 2019 > root at willis:~# openssl s_client -connect thankqcrm.accessacloud.com:443 > Running the exact same openssl version from my machine, and using the exact same s_client options as you, I get a successful connection. Some possibilities of what might be going wrong: 1) Is it possible there is some middlebox betwen you and the target server that is causing a problem for you on your network? Can you try connecting from s_client from a machine outside your corporate network? or 2) I have sometimes seen load balancers do strange things - where different machines in the cluster are configured differently to each other. This can mean different people see different results - or even if you run the same test at different times you see different results. This could explain why it works in 1.1.0 and not 1.1.1 (i.e. it actually is equally broken - but sometimes you hit the "right" server, and sometimes you hit the "wrong" server). You might want to try from a different machine and see if the same thing happens, and/or repeat the tests periodically (in the hope of hitting different servers in the cluster). or 3) Possibly there is some local problem with your s_client build. Does it work ok for other sites? Matt > CONNECTED(00000004) > 140151269360768:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert > handshake failure:../ssl/record/rec_layer_s3.c:1544:SSL alert number 40 > --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 7 bytes and written 318 bytes > Verification: OK > --- > New, (NONE), Cipher is (NONE) > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > No ALPN negotiated > Early data was not sent > Verify return code: 0 (ok) > --- > > Works on OpenSSL 1.1.0: > > root at host:~# openssl version > OpenSSL 1.1.0l 10 Sep 2019 > root at host:~# openssl s_client -connect thankqcrm.accessacloud.com:443 > > CONNECTED(00000003) > depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = DigiCert Global Root CA > verify return:1 > depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = Thawte RSA CA 2018 > verify return:1 > depth=0 CN = *.accessacloud.com > verify return:1 > --- > Certificate chain > 0 s:/CN=*.accessacloud.com > i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte > RSA CA 2018 > 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte > RSA CA 2018 > i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert > Global Root CA > 2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert > Global Root CA > i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert > Global Root CA > 3 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert > Global Root CA > i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert > Global Root CA > --- > Server certificate > -----BEGIN CERTIFICATE----- > ... > -----END CERTIFICATE----- > subject=/CN=*.accessacloud.com > issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte > RSA CA 2018 > --- > No client certificate CA names sent > --- > SSL handshake has read 4999 bytes and written 494 bytes > Verification: OK > --- > New, TLSv1.2, Cipher is 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 : AES128-GCM-SHA256 > Session-ID: > 05326CD4A0D128684EA530A59504BA8D02E99746AC2E40D0DA8B9B0E18F20CF0 > Session-ID-ctx: > Master-Key: > B423C27867FFB6A021458D860CC8A5A6D947628A8216B5F8DD8D1CF3058545398185B94F772B3A816A15D1442FFF1822 > PSK identity: None > PSK identity hint: None > SRP username: None > TLS session ticket lifetime hint: 14400 (seconds) > TLS session ticket: > 0000 - e5 7b cf ea bc 3d 6b 9a-59 ec 40 63 01 19 52 6c > .{...=k.Y. at c..Rl > 0010 - 72 c4 34 f0 a3 ff 37 f4-58 b1 9a bb 84 fc 94 36 > r.4...7.X......6 > 0020 - 16 8e 39 04 94 e2 fd ae-0f 05 e7 6c 12 94 58 4a > ..9........l..XJ > 0030 - 09 56 e5 bd 67 d7 e7 17-d4 a8 03 ba 6e 05 be b6 > .V..g.......n... > 0040 - ce 5d 9a ee 81 73 97 c8-ff 9c be 6b 8f 37 cb bf > .]...s.....k.7.. > 0050 - 44 76 93 83 95 58 6d b8-63 f6 ba 4d 55 22 d2 14 > Dv...Xm.c..MU".. > 0060 - 93 09 01 46 f0 fa f1 35-5a 80 0e ab a4 ca 9e c8 > ...F...5Z....... > 0070 - ed 8f c8 3c 89 e8 91 b3-0e 41 a9 e4 3f 79 f6 63 > ...<.....A..?y.c > 0080 - e2 62 91 c9 2f 8c 5a dd-b0 a1 55 b3 86 35 62 5a > .b../.Z...U..5bZ > 0090 - af c2 9a 8a 35 7a 46 3b-3c 2e 24 0d 45 69 96 fc > ....5zF;<.$.Ei.. > > Start Time: 1583859230 > Timeout : 7200 (sec) > Verify return code: 0 (ok) > Extended master secret: no > --- > > > Works using 1.1.1d if I pass in -tls1_1 > > root at willis:~# openssl version > OpenSSL 1.1.1d 10 Sep 2019 > root at willis:~# openssl s_client -connect thankqcrm.accessacloud.com:443 > -tls1_1 > CONNECTED(00000004) > depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = DigiCert Global Root CA > verify return:1 > depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = Thawte RSA CA 2018 > verify return:1 > depth=0 CN = *.accessacloud.com > verify return:1 > --- > Certificate chain > 0 s:CN = *.accessacloud.com > i:C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = Thawte RSA CA 2018 > 1 s:C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = Thawte RSA CA 2018 > i:C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = DigiCert Global Root CA > 2 s:C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = DigiCert Global Root CA > i:C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = DigiCert Global Root CA > 3 s:C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = DigiCert Global Root CA > i:C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = DigiCert Global Root CA > --- > Server certificate > -----BEGIN CERTIFICATE----- > ... > -----END CERTIFICATE----- > subject=CN = *.accessacloud.com > > issuer=C = US, O = DigiCert Inc, OU = www.digicert.com > , CN = Thawte RSA CA 2018 > > --- > No client certificate CA names sent > --- > SSL handshake has read 5059 bytes and written 481 bytes > Verification: OK > --- > New, SSLv3, Cipher is AES128-SHA > Server public key is 2048 bit > Secure Renegotiation IS supported > Compression: NONE > Expansion: NONE > No ALPN negotiated > SSL-Session: > Protocol : TLSv1.1 > Cipher : AES128-SHA > Session-ID: > 9438801392B268A70F6B60C25E388481D69638ED8122A274BB0E15111BFF329B > Session-ID-ctx: > Master-Key: > EA86A4D07020F193BC66444A2D16EC67AD9524A6A78D068542B6CAF745D0B51FBE51EA0F9E9A6557561CFD5AE9E2D986 > PSK identity: None > PSK identity hint: None > SRP username: None > TLS session ticket lifetime hint: 14400 (seconds) > TLS session ticket: > 0000 - e5 7b cf ea bc 3d 6b 9a-59 ec 40 63 01 19 52 6c > .{...=k.Y. at c..Rl > 0010 - 3a c0 bc fb ff 57 a2 7f-38 a9 91 64 5e 87 b4 88 > :....W..8..d^... > 0020 - f2 35 bc 04 b3 27 b3 fc-0f ac 3d 8a 03 a4 59 cb > .5...'....=...Y. > 0030 - a7 2c 8e 0f f3 a0 a2 13-50 fa 6f 2e 07 eb 1e 89 > .,......P.o..... > 0040 - 73 0d d0 3e d5 01 68 3a-18 56 00 71 fa 38 1e e0 > s..>..h:.V.q.8.. > 0050 - 87 15 68 a4 d0 d7 13 67-c7 b1 e6 45 54 fd 22 e1 > ..h....g...ET.". > 0060 - 65 66 40 6c e3 7e 42 f1-1a 46 32 7b b9 a1 c0 80 > ef at l.~B..F2{.... > 0070 - 12 ee f1 d9 92 5f b7 3b-7b 38 66 76 cc af b1 eb > ....._.;{8fv.... > 0080 - 97 4c 02 af 61 9d 1b 35-c8 64 f5 ce 19 34 42 92 > .L..a..5.d...4B. > 0090 - a0 0e b9 51 ab de c0 cf-90 bd 65 2b 0b 08 19 3b > ...Q......e+...; > 00a0 - 2e fe 1f 75 1f b5 b8 48-40 8c 56 d4 dc 82 31 b0 > ...u...H at .V...1. > 00b0 - 2f 52 b9 1f 11 f7 d2 63-01 c0 89 57 dd a6 53 56 > /R.....c...W..SV > > Start Time: 1583859354 > Timeout : 7200 (sec) > Verify return code: 0 (ok) > Extended master secret: no > --- > > > --------------------------------- > This error started our of the blue. The vendor confirmed a change in > certificate about the same time that curl/'python requests' stopped > working. So it looks to me like their cert change caused the issue. > > Tested on Debian 10 and Ubuntu 20.04 Focal Fossa. > > Why does this certificate work with tls1.2 on 1.1.0 but not on 1.1.1??? > > I can force tls1.1, but want to inform the vendor there are problems > with their new certificate but don't really understand much of this. > > Any help appreciated. > > Regards > > Niki > > > Save the date: Abingdon's first 24hr *Giving Day - 18 March 2020*. > Help support our ambition to double the number of bursaries across the > Foundation. > > > > > Abingdon School: A company limited by guarantee Registered in England > and Wales. Company No. 3625063 > > Registered Office: > Abingdon School > Park Road > Abingdon > OX14 1DE > Registered Charity No. 1071298 > > All information in this message and attachments is confidential and may > be legally privileged. Only intended recipients are authorised to use > it. E-mail transmissions are not guaranteed to be secure or error free > and the sender does not accept liability for such errors or omissions. > The company will not accept any liability in respect of such > communication that violates our ICT policies. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 6885 bytes Desc: image.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 28215 bytes Desc: image.png URL: From lear at ofcourseimright.com Tue Mar 10 19:36:40 2020 From: lear at ofcourseimright.com (Eliot Lear) Date: Tue, 10 Mar 2020 20:36:40 +0100 Subject: some testers needed for PHP CMS calls Message-ID: Hi everyone, If anyone is interested, I have attempted to port the OpenSSL CMS routines into PHP.? The code is available in a PR at https://github.com/php/php-src/pull/5251.? Comments/reviews most welcome. Eliot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From barber.m.kristin at gmail.com Tue Mar 10 20:31:29 2020 From: barber.m.kristin at gmail.com (Kristin Barber) Date: Tue, 10 Mar 2020 20:31:29 +0000 Subject: Compiling for RISC-V In-Reply-To: <87r1y16lp7.wl-levitte@openssl.org> References: <87tv2y6mdd.wl-levitte@openssl.org> <87r1y16lp7.wl-levitte@openssl.org> Message-ID: Hi Richard, You're right, in fact, some newer releases of Debian even seem to ship with Configuration files having entries for riscv platforms explicitly! I've realized that the problems I was seeing were more nuanced than I originally thought. The RISC-V toolchain actually has two flavors: one that is newlib-based and one that is linux-gnu-based. I am using the newlib toolchain, its an embedded environment, where in fact I don't expect to have any OS support at all. The errors I was seeing were the result of some extra flags needed to allow newlib to play nicely with the OpenSSL build, such as nostdlib. However, of course there are still errors associated with the syscalls that aren't implemented in this case, but I believe that is now the only remaining issue. This brings me to another point, which may be outside the scope of this thread and please let me know if I should open another one to address this: for constrained environments without an OS, is there a best practice for compiling OpenSSL? I actually don't even need *all* of OpenSSL, just the crypto, even more specifically, the RSA encrypt/decrypt. For syscall functionality, do folks typically pull them from open-source kernels as an easy way to get up-and-running? Any kind of insights on this would be great. Thanks, Kristin ?On 3/9/20, 9:30 PM, "openssl-users on behalf of Richard Levitte" wrote: Hi, when you mentioned cross compiling, that got me a bit more curious, so I went looking, and noticed that Debian [sid] (which is what I run on my laptop) has all the cross compiling tools I needed (see https://wiki.debian.org/RISC-V#Cross_compilation), so I installed them, and then tried this in my checkout of OpenSSL's master branch: ./Configure linux-generic64 no-asm no-threads \ --cross-compile-prefix=riscv64-linux-gnu- Running 'make' was a breeze, it went through flawlessly. I haven't done much further tests, though. Cheers, Richard On Mon, 09 Mar 2020 20:23:09 +0100, Kristin Barber wrote: > > > I did also try configuring for "no-asm", but there still seemed to be architecture-specific issues > based on which files the errors were coming from. I should probably also mention that I am > attempting to cross-compile for RV64 from an x86 machine. > > On Mon, Mar 9, 2020 at 3:12 PM Scott Neugroschl wrote: > > > > Is the ?no-asm? configuration option still supported? > > > > From: openssl-users On Behalf Of Kristin Barber > Sent: Monday, March 9, 2020 12:03 PM > To: Richard Levitte > Cc: openssl-users at openssl.org > Subject: Re: Compiling for RISC-V > > > > Hi Richard, thanks for the reply. It was helpful. > > > > You are correct, I was able to find a configuration that worked by passing the RISC-V compiler > via "make variable" assignment, along with some relevant options. Things start compiling, but > the build fails on what seems to be architecture-specific assembly files which are selected > based on which "platform" has been configured. It did not seem to me that there were RISC-V > assembly-specific files as an option here, and based on your reply, I think that is indeed the > issue. Am I understanding this correctly? > > > > Thanks, > > > > Kristin > > > > On Mon, Mar 9, 2020 at 3:03 AM Richard Levitte wrote: > > On Mon, 09 Mar 2020 05:18:17 +0100, > Kristin Barber wrote: > > I've looked at the INSTALL docs, and it doesn't seem that RISC-V processors are > supported > > currently as a platform. Is this correct? > > That is correct. No one has implemented that support yet. > > > Is there a branch which enables configuring for a RISC-V machine that hasn't yet made it > into a > > stable release? > > Not that I know of. Although, this same question has also been raised > on github (I forget the issue number). > > > Any advice on where to look for information or changes to the build process in order to > compile > > for RISC-V? > > The first thing to attempt is a generic build with no assembler. > There are some really simply config targets that could be a first > step, one of: > > ./Configure cc > > ./Configure gcc > > A (pretty big) step up from that, at least if Linux is your target, > would be one of these: > > ./Configure linux-generic32 > > ./Configure linux-generic64 > > Note that in either case, you may have to add C flags and ld flags, > which you can do in one of two ways: > > 1) directly on the configuration command line, like this (Configure > makes an educated guess on what flags go where): > > ./Configure linux-generic64 -m64 -DWHATEVER=value -Wl,-something > > 2) via "make variable" assignment: > > ./Configure linux-generic64 \ > CPPFLAGS='-DWHATEVER=value' \ > CFLAGS='-m64' \ > LDFLAGS='-Wl,-something' > > At some point, you might find a combination that works for you. We > would definitely like to know what you figure out, and it may be that > the result makes it into our database of config targets (which, if > you're curious, are the files Configurations/*.conf). > > Now, configuration is the easy bit when it comes to new CPUs, > relatively speaking. I assume that part of your question is whether > there is assembler support. This is the hard part in terms of > effort. We currently have no such thing at all for RISC-V, and I > haven't seen any attempts to start such an effort... PRs would > certainly be welcome, but anyone who tries this will have to be > prepared for it to take a while to get into the main source. > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From akshar.kanak1 at gmail.com Wed Mar 11 07:44:23 2020 From: akshar.kanak1 at gmail.com (Akshar Kanak) Date: Wed, 11 Mar 2020 13:14:23 +0530 Subject: [FIPS] is EVP_des_ede_ecb permitted ? Message-ID: Dear team In FIPS mode is the cipher "EVP_des_ede_ecb" permitted or not ? If i check the openssl.org fipscansitor code then in the file fips_des_selftest.c , I can see that the self test for only EVP_des_ede3_ecb is being done . In Centos openssl code (openssl-1.0.2k-19.el7.src.rpm) , in the file fips_des_selftest.c , function FIPS_selftest_des() I can see that the self test for both EVP_des_ede_ecb and EVP_des_ede3_ecb . Thanks and regards Akshar -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaushalshriyan at gmail.com Wed Mar 11 08:21:35 2020 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Wed, 11 Mar 2020 13:51:35 +0530 Subject: Negotiated cipher per proto (matching cipher in list missing). No further cipher order check has been done as order is determined by the client In-Reply-To: References: Message-ID: On Tue, Mar 10, 2020 at 9:56 PM Kaushal Shriyan wrote: > Hi, > > I have run the below tests > > ./testssl.sh gsmasslciphers.digitalapicraft.com >> ########################################################### >> testssl.sh 3.1dev from https://testssl.sh/dev/ >> (e0c83b2 2020-02-24 14:21:28 -- ) >> This program is free software. Distribution and >> modification under GPLv2 permitted. >> USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK! >> Please file bugs @ https://testssl.sh/bugs/ >> ########################################################### >> Using "OpenSSL 1.0.2-chacha (1.0.2k-dev)" [~183 ciphers] >> on Kaushals-MacBook-Pro:./bin/openssl.Darwin.x86_64 >> (built: "Feb 22 09:55:43 2019", platform: "darwin64-x86_64-cc") >> >> Start 2020-03-10 21:50:25 -->> 13.234.216.57:443 ( >> gsmasslciphers.digitalapicraft.com) <<-- >> rDNS (13.234.216.57): -- >> Service detected: HTTP >> >> Testing protocols via sockets except NPN+ALPN >> SSLv2 not offered (OK) >> SSLv3 not offered (OK) >> TLS 1 not offered >> TLS 1.1 not offered >> TLS 1.2 offered (OK) >> TLS 1.3 not offered and downgraded to a weaker protocol >> NPN/SPDY h2, http/1.1 (advertised) >> ALPN/HTTP2 h2, http/1.1 (offered) >> Testing cipher categories >> NULL ciphers (no encryption) not offered (OK) >> Anonymous NULL Ciphers (no authentication) not offered (OK) >> Export ciphers (w/o ADH+NULL) not offered (OK) >> LOW: 64 Bit + DES, RC[2,4] (w/o export) not offered (OK) >> Triple DES Ciphers / IDEA not offered >> Obsolete: SEED + 128+256 Bit CBC cipher not offered >> Strong encryption (AEAD ciphers) offered (OK) >> >> Testing robust (perfect) forward secrecy, (P)FS -- omitting Null >> Authentication/Encryption, 3DES, RC4 >> PFS is offered (OK) ECDHE-RSA-AES256-GCM-SHA384 >> ECDHE-RSA-AES128-GCM-SHA256 >> Elliptic curves offered: secp256k1 prime256v1 secp384r1 secp521r1 >> >> Testing server preferences >> Has server cipher order? no (NOT ok) >> Negotiated protocol TLSv1.2 >> Negotiated cipher ECDHE-RSA-AES128-GCM-SHA256, 521 bit ECDH >> (P-521) -- inconclusive test, matching cipher in list missing, better see >> below >> Negotiated cipher per proto (matching cipher in list missing) >> ECDHE-RSA-AES256-GCM-SHA384: TLSv1.2 >> No further cipher order check has been done as order is determined by >> the client >> >> Testing server defaults (Server Hello) >> TLS extensions (standard) "server name/#0" "renegotiation >> info/#65281" "EC point formats/#11" "session ticket/#35" "heartbeat/#15" >> "next protocol/#13172" "application layer protocol negotiation/#16" >> Session Ticket RFC 5077 hint 86400 seconds, session tickets keys seems >> to be rotated < daily >> SSL Session ID support yes >> Session Resumption Tickets: yes, ID: yes >> TLS clock skew Random values, no fingerprinting possible >> Signature Algorithm SHA256 with RSA >> Server key size RSA 2048 bits >> Server key usage Digital Signature, Key Encipherment >> Server extended key usage TLS Web Server Authentication, TLS Web >> Client Authentication >> Serial / Fingerprints 03C871BF68E569B4330E4AFCFA7752AAB5D7 / SHA1 >> 8874D965CB96F4A4B8B4CCAE149B6F1999399BF8 >> SHA256 >> BB56659442E2ED18778F7BB210823F3A81DA88F3AF79D0EE2104CE82DBB03C65 >> Common Name (CN) gsmasslciphers.digitalapicraft.com >> subjectAltName (SAN) gsmasslciphers.digitalapicraft.com >> Issuer Let's Encrypt Authority X3 (Let's Encrypt >> from US) >> Trust (hostname) Ok via SAN (same w/o SNI) >> Chain of trust Ok >> EV cert (experimental) no >> ETS/"eTLS", visibility info not present >> Certificate Validity (UTC) 89 >= 30 days (2020-03-10 09:40 --> >> 2020-06-08 09:40) >> # of certificates provided 2 >> Certificate Revocation List -- >> OCSP URI http://ocsp.int-x3.letsencrypt.org >> OCSP stapling not offered >> OCSP must staple extension -- >> DNS CAA RR (experimental) not offered >> Certificate Transparency yes (certificate extension) >> >> Testing HTTP header response @ "/" >> HTTP Status Code 200 OK >> HTTP clock skew 0 sec from localtime >> Strict Transport Security 730 days=63072000 s, just this domain >> Public Key Pinning -- >> Server banner nginx/1.16.1 >> Application banner -- >> Cookie(s) (none issued at "/") >> Security headers -- >> Reverse Proxy banner -- >> >> Testing vulnerabilities >> Heartbleed (CVE-2014-0160) not vulnerable (OK), timed out >> CCS (CVE-2014-0224) not vulnerable (OK) >> Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK) >> ROBOT Server does not support any >> cipher suites that use RSA key transport >> Secure Renegotiation (RFC 5746) supported (OK) >> Secure Client-Initiated Renegotiation not vulnerable (OK) >> CRIME, TLS (CVE-2012-4929) not vulnerable (OK) >> BREACH (CVE-2013-3587) no HTTP compression (OK) - >> only supplied "/" tested >> POODLE, SSL (CVE-2014-3566) not vulnerable (OK), no SSLv3 >> support >> TLS_FALLBACK_SCSV (RFC 7507) No fallback possible (OK), no >> protocol below TLS 1.2 offered >> SWEET32 (CVE-2016-2183, CVE-2016-6329) not vulnerable (OK) >> FREAK (CVE-2015-0204) not vulnerable (OK) >> DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host >> and port (OK) >> make sure you don't use this >> certificate elsewhere with SSLv2 enabled services >> >> https://censys.io/ipv4?q=BB56659442E2ED18778F7BB210823F3A81DA88F3AF79D0EE2104CE82DBB03C65 >> could help you to find out >> LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH >> EXPORT ciphers, no DH key detected with <= TLS 1.2 >> BEAST (CVE-2011-3389) not vulnerable (OK), no SSL3 >> or TLS1 >> LUCKY13 (CVE-2013-0169), experimental not vulnerable (OK) >> RC4 (CVE-2013-2566, CVE-2015-2808) no RC4 ciphers detected (OK) >> >> Testing 370 ciphers via OpenSSL plus sockets against the server, ordered >> by encryption strength >> Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits >> Cipher Suite Name (IANA/RFC) >> >> ----------------------------------------------------------------------------------------------------------------------------- >> xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 521 AESGCM 256 >> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >> xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 521 AESGCM 128 >> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >> >> Running client simulations (HTTP) via sockets >> Android 4.4.2 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 521 >> bit ECDH (P-521) >> Android 5.0.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 521 >> bit ECDH (P-521) >> Android 6.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 >> bit ECDH (P-256) >> Android 7.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 >> bit ECDH (P-256) >> Android 8.1 (native) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 >> bit ECDH (P-256) >> Android 9.0 (native) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 >> bit ECDH (P-256) >> Android 10.0 (native) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 >> bit ECDH (P-256) >> Chrome 74 (Win 10) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 >> bit ECDH (P-256) >> Chrome 79 (Win 10) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 >> bit ECDH (P-256) >> Firefox 66 (Win 8.1/10) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 >> bit ECDH (P-256) >> Firefox 71 (Win 10) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 >> bit ECDH (P-256) >> IE 6 XP No connection >> IE 8 Win 7 No connection >> IE 8 XP No connection >> IE 11 Win 7 No connection >> IE 11 Win 8.1 No connection >> IE 11 Win Phone 8.1 No connection >> IE 11 Win 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 >> bit ECDH (P-256) >> Edge 15 Win 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 >> bit ECDH (P-256) >> Edge 17 (Win 10) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 >> bit ECDH (P-256) >> Opera 66 (Win 10) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 >> bit ECDH (P-256) >> Safari 9 iOS 9 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 >> bit ECDH (P-256) >> Safari 9 OS X 10.11 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 >> bit ECDH (P-256) >> Safari 10 OS X 10.12 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 >> bit ECDH (P-256) >> Safari 12.1 (iOS 12.2) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 >> bit ECDH (P-256) >> Safari 13.0 (macOS 10.14.6) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 >> bit ECDH (P-256) >> Apple ATS 9 iOS 9 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 >> bit ECDH (P-256) >> Java 6u45 No connection >> Java 7u25 No connection >> Java 8u161 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 >> bit ECDH (P-256) >> Java 11.0.2 (OpenJDK) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 >> bit ECDH (P-256) >> Java 12.0.1 (OpenJDK) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 >> bit ECDH (P-256) >> OpenSSL 1.0.2e TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 >> bit ECDH (P-256) >> OpenSSL 1.1.0l (Debian) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 >> bit ECDH (P-256) >> OpenSSL 1.1.1d (Debian) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 >> bit ECDH (P-256) >> Thunderbird (68.3) TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 >> bit ECDH (P-256) >> Done 2020-03-10 21:52:13 [0130s] -->> 13.234.216.57:443 ( >> gsmasslciphers.digitalapicraft.com) <<-- > > > > I am not sure about the below explanation as seen in the above output. > > Testing server preferences >> Has server cipher order? no (NOT ok) >> Negotiated protocol TLSv1.2 >> Negotiated cipher ECDHE-RSA-AES128-GCM-SHA256, 521 bit ECDH >> (P-521) -- inconclusive test, matching cipher in list missing, better see >> below >> Negotiated cipher per proto (matching cipher in list missing) >> ECDHE-RSA-AES256-GCM-SHA384: TLSv1.2 >> No further cipher order check has been done as order is determined by >> the client > > > I will appreciate if someone can help me understand it. Does it mean there > is some issue? Thanks in advance and I look forward to hearing from you. > > Best Regards, > > Kaushal > > Hi, Checking in again if someone can pitch in for my earlier post to this mailing list. Thanks in advance and I look forward to hearing from you. Best Regards, Kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: From niki.dinsey at abingdon.org.uk Wed Mar 11 08:56:54 2020 From: niki.dinsey at abingdon.org.uk (Niki Dinsey) Date: Wed, 11 Mar 2020 08:56:54 +0000 Subject: Question about handshake error In-Reply-To: References: Message-ID: Sent this last night but got caught up for mod approval, switched images for links. ---- Thanks so much for your replies, I really appreciate being able to talk about this. I'm going to give you my full journey! My normal prod server setup is Debian 10 LXC containers on a slightly older Debian 9 host server running Proxmox 6 at OVH. This is where the problem initially arose last week. Any Debian 9 container on this server (all running 1.1.0l) connects fine: https://drive.google.com/a/abingdon.org.uk/uc?id=1dGLmmaUe7ftQ_nbKtY67vONFp1HiDB3n ...but the Debian 10 containers all fail: https://drive.google.com/a/abingdon.org.uk/uc?id=17slfkdhrSUP7Oi70KBWOBFZntJO6j-RC My first thought was can I try to reproduce this on another Debian 10 server elsewhere. I was able to reproduce this very easily using the Debian 'App' using Windows 10 built-in Windows Subsystem for Linux (WSL) All I did was install the WSL Debian app, apt update/upgrade and apt install openssl: https://drive.google.com/a/abingdon.org.uk/uc?id=1Vo0lbZqAjrDidfFGNDOKpYHGjRp6Ba6U I've also tried the Ubuntu App on WSL. Out of the box it uses 18.04 LTS and OpenSSL 1.1.1 - It works! https://drive.google.com/a/abingdon.org.uk/uc?id=1Vs8QInPE36BVz7j4G7N1wncmnrjZczax I was suspicious about this '1.1.1 11 Sep 2018', and as I'm not too sure how to upgrade this properly, I thought it was best just to upgrade the Windows App Ubuntu VM to 19.10. This time the version was 1.1.1c 28 May 2019 and is still worked! https://drive.google.com/a/abingdon.org.uk/uc?id=1h65oJB_iNAv3LW7henaV1LvLKgytV3ym Again the OpenSSL version wasn't exactly the same 1.1.1c != 1.1.1d Not really knowing how to upgrade OpenSSL without using apt, I thought I might as well try to upgrade Ubuntu 20.04 LTS which isn't fully out yet but worth a shot. Finally, this development version of Ubuntu is running the same release of OpenSSL 1.1.1d and guess what? It failed with the same error: https://drive.google.com/a/abingdon.org.uk/uc?id=1MTMiEnB2rcDMecKh2mkXg-Dd-Gl3jAq5 This is when I thought it was time to jump on the mailing list. Since you guys both mention it's working for you, I've also just ran this on a brand new bare-metal server I've got for another project hosted at OVH London. This again is Debian 10 / OpenSSL 1.1.1d and has the same result: https://drive.google.com/a/abingdon.org.uk/uc?id=1G87_F2VqwbB2H1hNkOlsK0p3Prsikl-r So in summary: openssl s_client -connect thankqcrm.accessacloud.com:443 * Debian 10 + 1.1.1d - Handshake Error * Debian 9 + 1.1.0l - Working * Ubuntu 18.04 + 1.1.1 11 Sep 2018 -Working * Ubuntu 19.10 + 1.1.1c 28 May 2019 - Working * Ubuntu 20.04 + 1.1.1d - Handshake Error The handshake errors can be bypassed using switch -tls1_1 on Debian 10 So I'm seeing a pattern here, as for what exactly I'm stumped! If anybody else can replicate using Debian 10 + 1.1.1d I'd appreciate it. But as for where to go from here I'm lost. Again, thanks for your replies and help. Niki On Tue, 10 Mar 2020 at 18:03, Sergio NNX wrote: > It seems to work fine here! > > > > > > > > > > > ------------------------------ > *From:* openssl-users on behalf of > Matt Caswell > *Sent:* Wednesday, 11 March 2020 4:25 AM > *To:* Niki Dinsey ; openssl-users at openssl.org > > *Subject:* Re: Question about handshake error > > > > On 10/03/2020 17:05, Niki Dinsey wrote: > > Hi there, I have an issue I can't seem to work out the answer to. > > > > Server: thankqcrm.accessacloud.com > > > > root at willis:~# openssl version > > OpenSSL 1.1.1d 10 Sep 2019 > > root at willis:~# openssl s_client -connect thankqcrm.accessacloud.com:443 > > > > Running the exact same openssl version from my machine, and using the > exact same s_client options as you, I get a successful connection. > > Some possibilities of what might be going wrong: > > 1) Is it possible there is some middlebox betwen you and the target > server that is causing a problem for you on your network? Can you try > connecting from s_client from a machine outside your corporate network? > > or > > 2) I have sometimes seen load balancers do strange things - where > different machines in the cluster are configured differently to each > other. This can mean different people see different results - or even if > you run the same test at different times you see different results. This > could explain why it works in 1.1.0 and not 1.1.1 (i.e. it actually is > equally broken - but sometimes you hit the "right" server, and sometimes > you hit the "wrong" server). You might want to try from a different > machine and see if the same thing happens, and/or repeat the tests > periodically (in the hope of hitting different servers in the cluster). > > or > > 3) Possibly there is some local problem with your s_client build. Does > it work ok for other sites? > > > Matt > > > > CONNECTED(00000004) > > 140151269360768:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert > > handshake failure:../ssl/record/rec_layer_s3.c:1544:SSL alert number 40 > > --- > > no peer certificate available > > --- > > No client certificate CA names sent > > --- > > SSL handshake has read 7 bytes and written 318 bytes > > Verification: OK > > --- > > New, (NONE), Cipher is (NONE) > > Secure Renegotiation IS NOT supported > > Compression: NONE > > Expansion: NONE > > No ALPN negotiated > > Early data was not sent > > Verify return code: 0 (ok) > > --- > > > > Works on OpenSSL 1.1.0: > > > > root at host:~# openssl version > > OpenSSL 1.1.0l 10 Sep 2019 > > root at host:~# openssl s_client -connect thankqcrm.accessacloud.com:443 > > > > CONNECTED(00000003) > > depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com > > , CN = DigiCert Global Root CA > > verify return:1 > > depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com > > , CN = Thawte RSA CA 2018 > > verify return:1 > > depth=0 CN = *.accessacloud.com > > verify return:1 > > --- > > Certificate chain > > 0 s:/CN=*.accessacloud.com > > i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte > > RSA CA 2018 > > 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte > > RSA CA 2018 > > i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert > > Global Root CA > > 2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert > > Global Root CA > > i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert > > Global Root CA > > 3 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert > > Global Root CA > > i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert > > Global Root CA > > --- > > Server certificate > > -----BEGIN CERTIFICATE----- > > ... > > -----END CERTIFICATE----- > > subject=/CN=*.accessacloud.com > > issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte > > RSA CA 2018 > > --- > > No client certificate CA names sent > > --- > > SSL handshake has read 4999 bytes and written 494 bytes > > Verification: OK > > --- > > New, TLSv1.2, Cipher is 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 : AES128-GCM-SHA256 > > Session-ID: > > 05326CD4A0D128684EA530A59504BA8D02E99746AC2E40D0DA8B9B0E18F20CF0 > > Session-ID-ctx: > > Master-Key: > > > B423C27867FFB6A021458D860CC8A5A6D947628A8216B5F8DD8D1CF3058545398185B94F772B3A816A15D1442FFF1822 > > PSK identity: None > > PSK identity hint: None > > SRP username: None > > TLS session ticket lifetime hint: 14400 (seconds) > > TLS session ticket: > > 0000 - e5 7b cf ea bc 3d 6b 9a-59 ec 40 63 01 19 52 6c > > .{...=k.Y. at c..Rl > > 0010 - 72 c4 34 f0 a3 ff 37 f4-58 b1 9a bb 84 fc 94 36 > > r.4...7.X......6 > > 0020 - 16 8e 39 04 94 e2 fd ae-0f 05 e7 6c 12 94 58 4a > > ..9........l..XJ > > 0030 - 09 56 e5 bd 67 d7 e7 17-d4 a8 03 ba 6e 05 be b6 > > .V..g.......n... > > 0040 - ce 5d 9a ee 81 73 97 c8-ff 9c be 6b 8f 37 cb bf > > .]...s.....k.7.. > > 0050 - 44 76 93 83 95 58 6d b8-63 f6 ba 4d 55 22 d2 14 > > Dv...Xm.c..MU".. > > 0060 - 93 09 01 46 f0 fa f1 35-5a 80 0e ab a4 ca 9e c8 > > ...F...5Z....... > > 0070 - ed 8f c8 3c 89 e8 91 b3-0e 41 a9 e4 3f 79 f6 63 > > ...<.....A..?y.c > > 0080 - e2 62 91 c9 2f 8c 5a dd-b0 a1 55 b3 86 35 62 5a > > .b../.Z...U..5bZ > > 0090 - af c2 9a 8a 35 7a 46 3b-3c 2e 24 0d 45 69 96 fc > > ....5zF;<.$.Ei.. > > > > Start Time: 1583859230 > > Timeout : 7200 (sec) > > Verify return code: 0 (ok) > > Extended master secret: no > > --- > > > > > > Works using 1.1.1d if I pass in -tls1_1 > > > > root at willis:~# openssl version > > OpenSSL 1.1.1d 10 Sep 2019 > > root at willis:~# openssl s_client -connect thankqcrm.accessacloud.com:443 > > -tls1_1 > > CONNECTED(00000004) > > depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com > > , CN = DigiCert Global Root CA > > verify return:1 > > depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com > > , CN = Thawte RSA CA 2018 > > verify return:1 > > depth=0 CN = *.accessacloud.com > > verify return:1 > > --- > > Certificate chain > > 0 s:CN = *.accessacloud.com > > i:C = US, O = DigiCert Inc, OU = www.digicert.com > > , CN = Thawte RSA CA 2018 > > 1 s:C = US, O = DigiCert Inc, OU = www.digicert.com > > , CN = Thawte RSA CA 2018 > > i:C = US, O = DigiCert Inc, OU = www.digicert.com > > , CN = DigiCert Global Root CA > > 2 s:C = US, O = DigiCert Inc, OU = www.digicert.com > > , CN = DigiCert Global Root CA > > i:C = US, O = DigiCert Inc, OU = www.digicert.com > > , CN = DigiCert Global Root CA > > 3 s:C = US, O = DigiCert Inc, OU = www.digicert.com > > , CN = DigiCert Global Root CA > > i:C = US, O = DigiCert Inc, OU = www.digicert.com > > , CN = DigiCert Global Root CA > > --- > > Server certificate > > -----BEGIN CERTIFICATE----- > > ... > > -----END CERTIFICATE----- > > subject=CN = *.accessacloud.com > > > > issuer=C = US, O = DigiCert Inc, OU = www.digicert.com > > , CN = Thawte RSA CA 2018 > > > > --- > > No client certificate CA names sent > > --- > > SSL handshake has read 5059 bytes and written 481 bytes > > Verification: OK > > --- > > New, SSLv3, Cipher is AES128-SHA > > Server public key is 2048 bit > > Secure Renegotiation IS supported > > Compression: NONE > > Expansion: NONE > > No ALPN negotiated > > SSL-Session: > > Protocol : TLSv1.1 > > Cipher : AES128-SHA > > Session-ID: > > 9438801392B268A70F6B60C25E388481D69638ED8122A274BB0E15111BFF329B > > Session-ID-ctx: > > Master-Key: > > > EA86A4D07020F193BC66444A2D16EC67AD9524A6A78D068542B6CAF745D0B51FBE51EA0F9E9A6557561CFD5AE9E2D986 > > PSK identity: None > > PSK identity hint: None > > SRP username: None > > TLS session ticket lifetime hint: 14400 (seconds) > > TLS session ticket: > > 0000 - e5 7b cf ea bc 3d 6b 9a-59 ec 40 63 01 19 52 6c > > .{...=k.Y. at c..Rl > > 0010 - 3a c0 bc fb ff 57 a2 7f-38 a9 91 64 5e 87 b4 88 > > :....W..8..d^... > > 0020 - f2 35 bc 04 b3 27 b3 fc-0f ac 3d 8a 03 a4 59 cb > > .5...'....=...Y. > > 0030 - a7 2c 8e 0f f3 a0 a2 13-50 fa 6f 2e 07 eb 1e 89 > > .,......P.o..... > > 0040 - 73 0d d0 3e d5 01 68 3a-18 56 00 71 fa 38 1e e0 > > s..>..h:.V.q.8.. > > 0050 - 87 15 68 a4 d0 d7 13 67-c7 b1 e6 45 54 fd 22 e1 > > ..h....g...ET.". > > 0060 - 65 66 40 6c e3 7e 42 f1-1a 46 32 7b b9 a1 c0 80 > > ef at l.~B..F2{.... > > 0070 - 12 ee f1 d9 92 5f b7 3b-7b 38 66 76 cc af b1 eb > > ....._.;{8fv.... > > 0080 - 97 4c 02 af 61 9d 1b 35-c8 64 f5 ce 19 34 42 92 > > .L..a..5.d...4B. > > 0090 - a0 0e b9 51 ab de c0 cf-90 bd 65 2b 0b 08 19 3b > > ...Q......e+...; > > 00a0 - 2e fe 1f 75 1f b5 b8 48-40 8c 56 d4 dc 82 31 b0 > > ...u...H at .V...1. > > 00b0 - 2f 52 b9 1f 11 f7 d2 63-01 c0 89 57 dd a6 53 56 > > /R.....c...W..SV > > > > Start Time: 1583859354 > > Timeout : 7200 (sec) > > Verify return code: 0 (ok) > > Extended master secret: no > > --- > > > > > > --------------------------------- > > This error started our of the blue. The vendor confirmed a change in > > certificate about the same time that curl/'python requests' stopped > > working. So it looks to me like their cert change caused the issue. > > > > Tested on Debian 10 and Ubuntu 20.04 Focal Fossa. > > > > Why does this certificate work with tls1.2 on 1.1.0 but not on 1.1.1??? > > > > I can force tls1.1, but want to inform the vendor there are problems > > with their new certificate but don't really understand much of this. > > > > Any help appreciated. > > > > Regards > > > > Niki > > > > > > Save the date: Abingdon's first 24hr *Giving Day - 18 March 2020*. > > Help support our ambition to double the number of bursaries across the > > Foundation. > > > > > > > > > > Abingdon School: A company limited by guarantee Registered in England > > and Wales. Company No. 3625063 > > > > Registered Office: > > Abingdon School > > Park Road > > Abingdon > > OX14 1DE > > Registered Charity No. 1071298 > > > > All information in this message and attachments is confidential and may > > be legally privileged. Only intended recipients are authorised to use > > it. E-mail transmissions are not guaranteed to be secure or error free > > and the sender does not accept liability for such errors or omissions. > > The company will not accept any liability in respect of such > > communication that violates our ICT policies. > -- Niki Dinsey IS Manager 07974 214718 01235 849061 (x261) -- Save the date: Abingdon's first 24hr *Giving Day - 18 March 2020*.Help support our ambition?to double the number of bursaries across the Foundation. -- Abingdon School: A company limited by guarantee Registered in England and Wales. Company No. 3625063? ? Registered Office:? Abingdon School? Park Road Abingdon? OX14 1DE? Registered Charity No. 1071298 ? All information in this message and attachments is confidential and may be legally privileged. Only intended recipients are authorised to use it. E-mail transmissions are not guaranteed to be secure or error free and the sender does not accept liability for such errors or omissions. The company will not accept any liability in respect of such communication that violates our ICT policies. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 6885 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 28215 bytes Desc: not available URL: From matt at openssl.org Wed Mar 11 12:15:32 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 11 Mar 2020 12:15:32 +0000 Subject: Question about handshake error In-Reply-To: References: Message-ID: On 11/03/2020 08:56, Niki Dinsey wrote: > openssl s_client -connect thankqcrm.accessacloud.com:443 > > > * Debian 10?+ 1.1.1d - Handshake Error?? > * Debian 9?+ 1.1.0l - Working > * Ubuntu 18.04 + 1.1.1? 11 Sep 2018 -Working > * Ubuntu 19.10?+ 1.1.1c? 28 May 2019 - Working > * Ubuntu 20.04?+ 1.1.1d - Handshake Error > > The handshake errors can be bypassed using switch -tls1_1 on Debian 10 > > So I'm seeing a pattern here, as for what exactly I'm stumped! If > anybody else can replicate using Debian 10?+ 1.1.1d I'd appreciate it. > But as for where to go from here I'm lost. Hi Niki I installed a Debian 10 VM and was able to reproduce this error. AFAICT, this appears to be due to a combination of a server mis-configuration, a slightly over-zealous server implementation applying the standards, and a debian specific openssl patch. I was able to isolate the difference between a successful handshake and a failing handshake. This is in the "signature algorithms" (sigalgs) extension of the ClientHello. This signals to the server what algorithms the client is willing to accept for handshake and certificate signatures. The important difference is that debian 10, by default, no longer seems to include any sigalgs that are based on SHA1 due to security concerns with that hash algorithm. Looking at the certificate chain sent by the server it does indeed include some certificates that are signed using SHA1. What is slightly odd about the certificate chain sent be the server is that it includes the root certificate - which is normally not sent (the client is expected to have that certificate already in its trust store). It is only the root certificate that is signed using SHA1. Even more strange is that the server seems to be sending 2 copies of the root cert! I *think* what is happening is the server is checking the chain it has been configured with, spotting that it includes a SHA1 based signature and therefore refusing to respond at all because the client has not indicated SHA1 support. IIRC openssl is a little less strict in this regards and would send the certificate anyway if it doesn't have a better alternative. I was able to get a successful connection from debian 10 using this command line: openssl s_client -connect thankqcrm.accessacloud.com:443 -sigalgs "RSA+SHA256:RSA+SHA1" -cipher "DEFAULT:@SECLEVEL=0" The full default sigalgs sent by a non-patched version of OpenSSL are: ecdsa_secp256r1_sha256:ecdsa_secp384r1_sha384:ecdsa_secp521r1_sha512 :ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512 :rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512 :rsa_pkcs1_sha256:rsa_pkcs1_sha384:rsa_pkcs1_sha512:ECDSA+SHA224 :ECDSA+SHA1:RSA+SHA224:RSA+SHA1:DSA+SHA224:DSA+SHA256:DSA+SHA384 :DSA+SHA512 Debian 10 omits all the SHA1 entries from the above list. Note that Debian 10 will only allow SHA1 if the security level is explicitly set to 0 (via the -cipher "DEFAULT:@SECLEVEL=0" command line arg). Probably because the debian patch is the same as this one: https://github.com/openssl/openssl/pull/10786 Which was also applied to the mainline 1.1.1 dev branch - but we already decided to revert it here: https://github.com/openssl/openssl/pull/11282 I would recommend that the server operator removes both copies of the root cert from its cert chain. Hopefully this should then mean that it does not see the SHA1 root and will therefore continue the handshake. If you can't get the server operator to make this change then, as a workaround, you'd have to change your application configuration to add back in the missing sigalgs and switch the security level to 0. Matt From Michael.Wojcik at microfocus.com Wed Mar 11 13:02:18 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 11 Mar 2020 13:02:18 +0000 Subject: Negotiated cipher per proto (matching cipher in list missing). No further cipher order check has been done as order is determined by the client In-Reply-To: References: , Message-ID: To enforce the server's cipher order, use SSL_CTX_set_options(ctx, SSL_CTX_get_options(ctx) | SSL_OP_CIPHER_SERVER_PREFERENCE). https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_set_options.html ________________________________ Testing server preferences Has server cipher order? no (NOT ok) ... No further cipher order check has been done as order is determined by the client -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Wed Mar 11 13:18:25 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 11 Mar 2020 14:18:25 +0100 Subject: Question about handshake error In-Reply-To: References: Message-ID: <20200311131825.GA3751539@roeckx.be> On Wed, Mar 11, 2020 at 12:15:32PM +0000, Matt Caswell wrote: > > I *think* what is happening is the server is checking the chain it has > been configured with, spotting that it includes a SHA1 based signature > and therefore refusing to respond at all because the client has not > indicated SHA1 support. IIRC openssl is a little less strict in this > regards and would send the certificate anyway if it doesn't have a > better alternative. That seems to be the same as: https://github.com/openssl/openssl/issues/11236 Kurt From kurt at roeckx.be Wed Mar 11 13:20:31 2020 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 11 Mar 2020 14:20:31 +0100 Subject: Question about handshake error In-Reply-To: References: Message-ID: <20200311132031.GB3751539@roeckx.be> On Wed, Mar 11, 2020 at 12:15:32PM +0000, Matt Caswell wrote: > > Debian 10 omits all the SHA1 entries from the above list. Note that > Debian 10 will only allow SHA1 if the security level is explicitly set > to 0 (via the -cipher "DEFAULT:@SECLEVEL=0" command line arg). Probably > because the debian patch is the same as this one: > > https://github.com/openssl/openssl/pull/10786 That patch is not applied. I assume that SECLEVEL=1 will allow SHA1, but the default in Debian is SECLEVEL=2 Kurt From openssl-users at dukhovni.org Wed Mar 11 15:08:11 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 11 Mar 2020 11:08:11 -0400 Subject: Question about handshake error In-Reply-To: References: Message-ID: <20200311150811.GB7977@straasha.imrryr.org> On Wed, Mar 11, 2020 at 12:15:32PM +0000, Matt Caswell wrote: > I would recommend that the server operator removes both copies of the > root cert from its cert chain. Hopefully this should then mean that it > does not see the SHA1 root and will therefore continue the handshake. If > you can't get the server operator to make this change then, as a > workaround, you'd have to change your application configuration to add > back in the missing sigalgs and switch the security level to 0. The signature algorithm security level is not expected to be enforced on self-signed certificates (root CAs). How is it happening here? -- Viktor. From matt at openssl.org Wed Mar 11 15:12:26 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 11 Mar 2020 15:12:26 +0000 Subject: Question about handshake error In-Reply-To: <20200311150811.GB7977@straasha.imrryr.org> References: <20200311150811.GB7977@straasha.imrryr.org> Message-ID: <011353ae-55bc-5fa1-4aa1-0e691f0f4c1d@openssl.org> On 11/03/2020 15:08, Viktor Dukhovni wrote: > On Wed, Mar 11, 2020 at 12:15:32PM +0000, Matt Caswell wrote: > >> I would recommend that the server operator removes both copies of the >> root cert from its cert chain. Hopefully this should then mean that it >> does not see the SHA1 root and will therefore continue the handshake. If >> you can't get the server operator to make this change then, as a >> workaround, you'd have to change your application configuration to add >> back in the missing sigalgs and switch the security level to 0. > > The signature algorithm security level is not expected to be enforced > on self-signed certificates (root CAs). How is it happening here? > It isn't. In this case the client is openssl but the server is unknown. The problem is on the server side. The server is refusing to continue a handshake where the sigalgs do not include sha1 because the server is misconfigured to include a root in the cert chain which has a SHA1 signature. The server is obviously inspecting the mis-configured chain, seeing the SHA1 signature, and giving up. This is not an OpenSSL problem. Matt From openssl-users at dukhovni.org Wed Mar 11 15:31:51 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 11 Mar 2020 11:31:51 -0400 Subject: Question about handshake error In-Reply-To: <011353ae-55bc-5fa1-4aa1-0e691f0f4c1d@openssl.org> References: <20200311150811.GB7977@straasha.imrryr.org> <011353ae-55bc-5fa1-4aa1-0e691f0f4c1d@openssl.org> Message-ID: <20200311153151.GC7977@straasha.imrryr.org> On Wed, Mar 11, 2020 at 03:12:26PM +0000, Matt Caswell wrote: > > The signature algorithm security level is not expected to be enforced > > on self-signed certificates (root CAs). How is it happening here? > > It isn't. In this case the client is openssl but the server is unknown. > The problem is on the server side. The server is refusing to continue a > handshake where the sigalgs do not include sha1 because the server is > misconfigured to include a root in the cert chain which has a SHA1 > signature. The server is obviously inspecting the mis-configured chain, > seeing the SHA1 signature, and giving up. This is not an OpenSSL problem. > I think the server could be OpenSSL, because why I made sure that self-signed CA signatures are not subjected to security levels in x509_vfy.c, the same exclusion does not appear to be present in: int ssl_security_cert(SSL *s, SSL_CTX *ctx, X509 *x, int vfy, int is_ee) { if (vfy) vfy = SSL_SECOP_PEER; if (is_ee) { if (!ssl_security_cert_key(s, ctx, x, SSL_SECOP_EE_KEY | vfy)) return SSL_R_EE_KEY_TOO_SMALL; } else { if (!ssl_security_cert_key(s, ctx, x, SSL_SECOP_CA_KEY | vfy)) return SSL_R_CA_KEY_TOO_SMALL; } if (!ssl_security_cert_sig(s, ctx, x, SSL_SECOP_CA_MD | vfy)) return SSL_R_CA_MD_TOO_WEAK; return 1; } which servers use to check *their own* chains. This function needs to exclude self-signed certificates from the final "cert_sig" check. The server's own chain is not always anchored to a root CA, so just excluding the "top" cert (as when peer certs are verified in the X.509 code) is not quite the right thing to do here, instead we should check is self-signed flag, something along the lines of: if ((X509_get_extension_flags(x) & EXFLAG_SS) == 0 && !ssl_security_cert_sig(s, ctx, x, SSL_SECOP_CA_MD | vfy)) return SSL_R_CA_MD_TOO_WEAK; -- Viktor. From openssl-users at dukhovni.org Wed Mar 11 15:32:58 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 11 Mar 2020 11:32:58 -0400 Subject: Question about handshake error In-Reply-To: <20200311153151.GC7977@straasha.imrryr.org> References: <20200311150811.GB7977@straasha.imrryr.org> <011353ae-55bc-5fa1-4aa1-0e691f0f4c1d@openssl.org> <20200311153151.GC7977@straasha.imrryr.org> Message-ID: <20200311153258.GD7977@straasha.imrryr.org> On Wed, Mar 11, 2020 at 11:31:51AM -0400, Viktor Dukhovni wrote: > I think the server could be OpenSSL, because why I made sure that s/why/while/. > self-signed CA signatures are not subjected to security levels in > x509_vfy.c, the same exclusion does not appear to be present in: > > int ssl_security_cert(SSL *s, SSL_CTX *ctx, X509 *x, int vfy, int is_ee) > [...] -- Viktor. From matt at openssl.org Wed Mar 11 15:51:56 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 11 Mar 2020 15:51:56 +0000 Subject: Forthcoming OpenSSL release Message-ID: <4ef7e5e3-c7eb-7b3c-5773-2c244e13baf7@openssl.org> The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.1e. This release will be made available on Tuesday 17th March 2020 between 1300-1700 UTC. This will contain one LOW severity fix for CVE-2019-1551 previously announced here: https://www.openssl.org/news/secadv/20191206.txt Please see the following page for further details of severity levels: https://www.openssl.org/policies/secpolicy.html Yours The OpenSSL Project Team From openssl-users at dukhovni.org Wed Mar 11 16:56:16 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 11 Mar 2020 12:56:16 -0400 Subject: Question about handshake error In-Reply-To: <20200311153258.GD7977@straasha.imrryr.org> <011353ae-55bc-5fa1-4aa1-0e691f0f4c1d@openssl.org> Message-ID: <20200311165616.GG7977@straasha.imrryr.org> On Wed, Mar 11, 2020 at 03:12:26PM +0000, Matt Caswell wrote: > > The signature algorithm security level is not expected to be enforced > > on self-signed certificates (root CAs). How is it happening here? > > It isn't. In this case the client is openssl but the server is unknown. > The problem is on the server side. The server is refusing to continue a > handshake where the sigalgs do not include sha1 because the server is > misconfigured to include a root in the cert chain which has a SHA1 > signature. The server is obviously inspecting the mis-configured chain, > seeing the SHA1 signature, and giving up. This is not an OpenSSL problem. Matt are you able to confirm whether the below is correct? Perhaps I should file a PR to address this if it is... On Wed, Mar 11, 2020 at 11:32:58AM -0400, Viktor Dukhovni wrote: > > self-signed CA signatures are not subjected to security levels in > > x509_vfy.c, the same exclusion does not appear to be present in: > > > > int ssl_security_cert(SSL *s, SSL_CTX *ctx, X509 *x, int vfy, int is_ee) > > [...] -- VIktor. From matt at openssl.org Wed Mar 11 16:57:42 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 11 Mar 2020 16:57:42 +0000 Subject: Question about handshake error In-Reply-To: <20200311165616.GG7977@straasha.imrryr.org> References: <20200311165616.GG7977@straasha.imrryr.org> Message-ID: <0f7b70fd-5880-37fa-0b8f-2ac095c4e413@openssl.org> On 11/03/2020 16:56, Viktor Dukhovni wrote: > On Wed, Mar 11, 2020 at 03:12:26PM +0000, Matt Caswell wrote: > >>> The signature algorithm security level is not expected to be enforced >>> on self-signed certificates (root CAs). How is it happening here? >> >> It isn't. In this case the client is openssl but the server is unknown. >> The problem is on the server side. The server is refusing to continue a >> handshake where the sigalgs do not include sha1 because the server is >> misconfigured to include a root in the cert chain which has a SHA1 >> signature. The server is obviously inspecting the mis-configured chain, >> seeing the SHA1 signature, and giving up. This is not an OpenSSL problem. > > Matt are you able to confirm whether the below is correct? Perhaps > I should file a PR to address this if it is... I will run some tests to confirm or deny what you think might be happening. Probably it will be tomorrow before I get to it. Matt > > On Wed, Mar 11, 2020 at 11:32:58AM -0400, Viktor Dukhovni wrote: > >>> self-signed CA signatures are not subjected to security levels in >>> x509_vfy.c, the same exclusion does not appear to be present in: >>> >>> int ssl_security_cert(SSL *s, SSL_CTX *ctx, X509 *x, int vfy, int is_ee) >>> [...] > From kaushalshriyan at gmail.com Wed Mar 11 16:57:25 2020 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Wed, 11 Mar 2020 22:27:25 +0530 Subject: Negotiated cipher per proto (matching cipher in list missing). No further cipher order check has been done as order is determined by the client In-Reply-To: References: Message-ID: On Wed, Mar 11, 2020 at 6:36 PM Michael Wojcik < Michael.Wojcik at microfocus.com> wrote: > To enforce the server's cipher order, use SSL_CTX_set_options(*ctx*, > SSL_CTX_get_options(*ctx*) | SSL_OP_CIPHER_SERVER_PREFERENCE). > > https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_set_options.html > > ------------------------------ > > > Testing server preferences > Has server cipher order? no (NOT ok) > ... > No further cipher order check has been done as order is determined by the > client > > > Hi Michael, Thanks for the email. I am not sure if i understand it completely. what does the server's cipher order mean in layman's terms? Any example regarding To enforce the server's cipher order, use SSL_CTX_set_options(ctx, SSL_CTX_get_options(ctx) | SSL_OP_CIPHER_SERVER_PREFERENCE) to set it in /etc/nginx/nginx.conf. I am running Nginx web server. I have the below settings in /etc/nginx/nginx.conf server { listen 443 ssl; ssl_protocols TLSv1.2; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; } Please suggest. I look forward to hearing from you and thanks in advance. Best Regards, Kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Mar 11 16:58:52 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 11 Mar 2020 12:58:52 -0400 Subject: Question about handshake error In-Reply-To: <0f7b70fd-5880-37fa-0b8f-2ac095c4e413@openssl.org> References: <20200311165616.GG7977@straasha.imrryr.org> <0f7b70fd-5880-37fa-0b8f-2ac095c4e413@openssl.org> Message-ID: <20200311165852.GH7977@straasha.imrryr.org> On Wed, Mar 11, 2020 at 04:57:42PM +0000, Matt Caswell wrote: > > Matt are you able to confirm whether the below is correct? Perhaps > > I should file a PR to address this if it is... > > I will run some tests to confirm or deny what you think might be > happening. Probably it will be tomorrow before I get to it. That'd be great! Thanks. -- Viktor. From niki.dinsey at abingdon.org.uk Wed Mar 11 17:08:49 2020 From: niki.dinsey at abingdon.org.uk (Niki Dinsey) Date: Wed, 11 Mar 2020 17:08:49 +0000 Subject: Question about handshake error In-Reply-To: <20200311153258.GD7977@straasha.imrryr.org> References: <20200311150811.GB7977@straasha.imrryr.org> <011353ae-55bc-5fa1-4aa1-0e691f0f4c1d@openssl.org> <20200311153151.GC7977@straasha.imrryr.org> <20200311153258.GD7977@straasha.imrryr.org> Message-ID: Thanks Matt for your reply earlier, following your advice I've edited the following line in my openssl.cnf file: CipherString = DEFAULT at SECLEVEL=1 and it now works in s_client and curl: niks at DESKTOP-O2VP5O2:/etc/ssl$ curl https://thankqcrm.accessacloud.com/ /?X-apikey= {"Status":"OK","PageIndex":1,"PageSize":15,"PageCount":1,"Columns":[{"Name":"destinationCode","DataType":"Text","MaxLength":20},{"Name":"webDescriptionOverride","DataType":"Text","MaxLength":-1}],"Rows":[{"destinationCode":"BOARDING","webDescriptionOverride":"Boarding"},{"destinationCode":"BURSARYAS","webDescriptionOverride":"Bursaries"},{"destinationCode":"GIVING DAY 2020","webDescriptionOverride":"GIVING DAY 2020"},{"destinationCode":"OTHER","webDescriptionOverride":"Other"},{"destinationCode":"PARTNER","webDescriptionOverride":"Partnerships"},{"destinationCode":"UNRESTRAS","webDescriptionOverride":"Unrestricted"}],"RecordCount":6,"RecordStartIndex":1} Thanks so much for the help resolving the issue. As for going back to the software vendor, I absolutely want to but don't hold out too much hope they will change anything. I'm basically going to say this: The certificate chain contains two redundant root certificates, these should be removed as there is no need to send root certificates and because they are signed with SHA1 stricter servers like Debian are dropping the connection. Does that sound about right? As for the conversation with Viktor, it's all over my head! Can I just ignore and get back to work? Thanks again Niki On Wed, 11 Mar 2020 at 15:33, Viktor Dukhovni wrote: > On Wed, Mar 11, 2020 at 11:31:51AM -0400, Viktor Dukhovni wrote: > > > I think the server could be OpenSSL, because why I made sure that > > s/why/while/. > > > self-signed CA signatures are not subjected to security levels in > > x509_vfy.c, the same exclusion does not appear to be present in: > > > > int ssl_security_cert(SSL *s, SSL_CTX *ctx, X509 *x, int vfy, int > is_ee) > > [...] > > -- > Viktor. > -- Niki Dinsey IS Manager 07974 214718 01235 849061 (x261) -- Save the date: Abingdon's first 24hr *Giving Day - 18 March 2020*.Help support our ambition?to double the number of bursaries across the Foundation. -- Abingdon School: A company limited by guarantee Registered in England and Wales. Company No. 3625063? ? Registered Office:? Abingdon School? Park Road Abingdon? OX14 1DE? Registered Charity No. 1071298 ? All information in this message and attachments is confidential and may be legally privileged. Only intended recipients are authorised to use it. E-mail transmissions are not guaranteed to be secure or error free and the sender does not accept liability for such errors or omissions. The company will not accept any liability in respect of such communication that violates our ICT policies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Wed Mar 11 17:20:42 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 11 Mar 2020 17:20:42 +0000 Subject: Negotiated cipher per proto (matching cipher in list missing). No further cipher order check has been done as order is determined by the client In-Reply-To: References: , Message-ID: (Please send messages to the list, not to me directly.) In TLS, the client and server negotiate the cipher suite to use. The server makes the final decision. It can pick the client's most-preferred suite from among the ones they share, or it can pick the one it prefers. The current consensus seems to be that the best practice is to pick the suite the server most prefers. You can consult other references such as Ivan Ristic's /Bulletproof SSL and TLS/ book if you want more details. Having the server pick the suite it prefers is known as enforcing the server's cipher-suite order. The test you ran is complaining that the server does not enforce its cipher-suite order. I explained how to do that in OpenSSL. How to do it in nginx is a question for the nginx project, not an OpenSSL problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Mar 11 17:27:43 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 11 Mar 2020 17:27:43 +0000 Subject: Question about handshake error In-Reply-To: References: <20200311150811.GB7977@straasha.imrryr.org> <011353ae-55bc-5fa1-4aa1-0e691f0f4c1d@openssl.org> <20200311153151.GC7977@straasha.imrryr.org> <20200311153258.GD7977@straasha.imrryr.org> Message-ID: <8c176f30-c83b-b7eb-4df5-e78306ff0d56@openssl.org> On 11/03/2020 17:08, Niki Dinsey wrote: > As for going back to the software vendor, I absolutely want to but don't > hold out too much hope they will change anything.? > I'm basically going to say this: > > The certificate chain contains two redundant root certificates, these > should be removed as there is no need to send root certificates and > because they are signed with SHA1 stricter servers like Debian are > dropping the connection. Replace "stricter servers" with "stricter clients". You might like to point them to my email explaining the issue in more detail: https://mta.openssl.org/pipermail/openssl-users/2020-March/012006.html > > Does that sound about right? > > As for the conversation with Viktor, it's all over my head! Can I just > ignore and get back to work? Thanks again Yes - ignore it. Viktor is suggesting that the unknown server that is being used might actually be OpenSSL - in which case we might want to make a change to our code so that it is more tolerant of this mis-configuration. It makes no difference to you though. Matt > > Niki?? > > On Wed, 11 Mar 2020 at 15:33, Viktor Dukhovni > > wrote: > > On Wed, Mar 11, 2020 at 11:31:51AM -0400, Viktor Dukhovni wrote: > > > I think the server could be OpenSSL, because why I made sure that > > s/why/while/. > > > self-signed CA signatures are not subjected to security levels in > > x509_vfy.c, the same exclusion does not appear to be present in: > > > >? ? ?int ssl_security_cert(SSL *s, SSL_CTX *ctx, X509 *x, int vfy, > int is_ee) > > [...] > > -- > ? ? Viktor. > > > > -- > Niki Dinsey > IS Manager > 07974 214718 > 01235 849061 (x261) > > Save the date: Abingdon's first 24hr *Giving Day - 18 March 2020*. > Help support our ambition?to double the number of bursaries across the > Foundation. > > > > > Abingdon School: A company limited by guarantee Registered in England > and Wales. Company No. 3625063? > ? > Registered Office:? > Abingdon School? > Park Road > Abingdon? > OX14 1DE? > Registered Charity No. 1071298 > ? > All information in this message and attachments is confidential and may > be legally privileged. Only intended recipients are authorised to use > it. E-mail transmissions are not guaranteed to be secure or error free > and the sender does not accept liability for such errors or omissions. > The company will not accept any liability in respect of such > communication that violates our ICT policies. From vieuxtech at gmail.com Wed Mar 11 17:42:13 2020 From: vieuxtech at gmail.com (Sam Roberts) Date: Wed, 11 Mar 2020 10:42:13 -0700 Subject: Forthcoming OpenSSL release In-Reply-To: <4ef7e5e3-c7eb-7b3c-5773-2c244e13baf7@openssl.org> References: <4ef7e5e3-c7eb-7b3c-5773-2c244e13baf7@openssl.org> Message-ID: Will it include ONLY the CVE fix, or will it include other fixes, such as to the getrandom() call on some archs? commit 4dcb150ea30f9bbfa7946e6b39c30a86aca5ed02 Author: Kurt Roeckx Date: Sat Sep 28 14:59:32 2019 +0200 Add defines for __NR_getrandom for all Linux architectures Fixes: https://github.com/openssl/openssl/issues/10015 Reviewed-by: Bernd Edlinger GH: https://github.com/openssl/openssl/pull/10044 See https://github.com/nodejs/node/pull/32002 for background. On Wed, Mar 11, 2020 at 8:53 AM Matt Caswell wrote: > > The OpenSSL project team would like to announce the forthcoming release > of OpenSSL version 1.1.1e. > > This release will be made available on Tuesday 17th March 2020 between > 1300-1700 UTC. This will contain one LOW severity fix for CVE-2019-1551 > previously announced here: > https://www.openssl.org/news/secadv/20191206.txt > > Please see the following page for further details of severity levels: > https://www.openssl.org/policies/secpolicy.html > > Yours > > The OpenSSL Project Team From matt at openssl.org Wed Mar 11 17:44:40 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 11 Mar 2020 17:44:40 +0000 Subject: Forthcoming OpenSSL release In-Reply-To: References: <4ef7e5e3-c7eb-7b3c-5773-2c244e13baf7@openssl.org> Message-ID: <711af514-0dab-4748-70b4-9ae6ce3fc346@openssl.org> On 11/03/2020 17:42, Sam Roberts wrote: > Will it include ONLY the CVE fix, or will it include other fixes, such > as to the getrandom() call on some archs? It will include all fixes currently in the 1.1.1-dev branch including commit eee565ec4 which is the 1.1.1 equivalent of the commit you mention. Matt > > commit 4dcb150ea30f9bbfa7946e6b39c30a86aca5ed02 > Author: Kurt Roeckx > Date: Sat Sep 28 14:59:32 2019 +0200 > > Add defines for __NR_getrandom for all Linux architectures > > Fixes: https://github.com/openssl/openssl/issues/10015 > > Reviewed-by: Bernd Edlinger > GH: https://github.com/openssl/openssl/pull/10044 > > See https://github.com/nodejs/node/pull/32002 for background. > > On Wed, Mar 11, 2020 at 8:53 AM Matt Caswell wrote: >> >> The OpenSSL project team would like to announce the forthcoming release >> of OpenSSL version 1.1.1e. >> >> This release will be made available on Tuesday 17th March 2020 between >> 1300-1700 UTC. This will contain one LOW severity fix for CVE-2019-1551 >> previously announced here: >> https://www.openssl.org/news/secadv/20191206.txt >> >> Please see the following page for further details of severity levels: >> https://www.openssl.org/policies/secpolicy.html >> >> Yours >> >> The OpenSSL Project Team > From matt at openssl.org Wed Mar 11 18:06:44 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 11 Mar 2020 18:06:44 +0000 Subject: Question about handshake error In-Reply-To: <20200311153151.GC7977@straasha.imrryr.org> References: <20200311150811.GB7977@straasha.imrryr.org> <011353ae-55bc-5fa1-4aa1-0e691f0f4c1d@openssl.org> <20200311153151.GC7977@straasha.imrryr.org> Message-ID: On 11/03/2020 15:31, Viktor Dukhovni wrote: > On Wed, Mar 11, 2020 at 03:12:26PM +0000, Matt Caswell wrote: > >>> The signature algorithm security level is not expected to be enforced >>> on self-signed certificates (root CAs). How is it happening here? >> >> It isn't. In this case the client is openssl but the server is unknown. >> The problem is on the server side. The server is refusing to continue a >> handshake where the sigalgs do not include sha1 because the server is >> misconfigured to include a root in the cert chain which has a SHA1 >> signature. The server is obviously inspecting the mis-configured chain, >> seeing the SHA1 signature, and giving up. This is not an OpenSSL problem. >> > > I think the server could be OpenSSL, because why I made sure that > self-signed CA signatures are not subjected to security levels in > x509_vfy.c, the same exclusion does not appear to be present in: > > int ssl_security_cert(SSL *s, SSL_CTX *ctx, X509 *x, int vfy, int is_ee) > { > if (vfy) > vfy = SSL_SECOP_PEER; > if (is_ee) { > if (!ssl_security_cert_key(s, ctx, x, SSL_SECOP_EE_KEY | vfy)) > return SSL_R_EE_KEY_TOO_SMALL; > } else { > if (!ssl_security_cert_key(s, ctx, x, SSL_SECOP_CA_KEY | vfy)) > return SSL_R_CA_KEY_TOO_SMALL; > } > if (!ssl_security_cert_sig(s, ctx, x, SSL_SECOP_CA_MD | vfy)) > return SSL_R_CA_MD_TOO_WEAK; > return 1; > } > The exclusion comes in ssl_security_cert_sig - so I think OpenSSL behaves correctly: static int ssl_security_cert_sig(SSL *s, SSL_CTX *ctx, X509 *x, int op) { /* Lookup signature algorithm digest */ int secbits, nid, pknid; /* Don't check signature if self signed */ if ((X509_get_extension_flags(x) & EXFLAG_SS) != 0) return 1; if (!X509_get_signature_info(x, &nid, &pknid, &secbits, NULL)) secbits = -1; /* If digest NID not defined use signature NID */ if (nid == NID_undef) nid = pknid; if (s) return ssl_security(s, op, secbits, nid, x); else return ssl_ctx_security(ctx, op, secbits, nid, x); } Matt > which servers use to check *their own* chains. This function needs to > exclude self-signed certificates from the final "cert_sig" check. > > The server's own chain is not always anchored to a root CA, so just > excluding the "top" cert (as when peer certs are verified in the > X.509 code) is not quite the right thing to do here, instead we > should check is self-signed flag, something along the lines of: > > if ((X509_get_extension_flags(x) & EXFLAG_SS) == 0 > && !ssl_security_cert_sig(s, ctx, x, SSL_SECOP_CA_MD | vfy)) > return SSL_R_CA_MD_TOO_WEAK; > From openssl-users at dukhovni.org Wed Mar 11 18:46:57 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 11 Mar 2020 14:46:57 -0400 Subject: Question about handshake error In-Reply-To: References: <20200311150811.GB7977@straasha.imrryr.org> <011353ae-55bc-5fa1-4aa1-0e691f0f4c1d@openssl.org> <20200311153151.GC7977@straasha.imrryr.org> Message-ID: <20200311184657.GA68408@straasha.imrryr.org> On Wed, Mar 11, 2020 at 06:06:44PM +0000, Matt Caswell wrote: > > if (!ssl_security_cert_sig(s, ctx, x, SSL_SECOP_CA_MD | vfy)) > > return SSL_R_CA_MD_TOO_WEAK; > > return 1; > > } > > The exclusion comes in ssl_security_cert_sig - so I think OpenSSL > behaves correctly: > > static int ssl_security_cert_sig(SSL *s, SSL_CTX *ctx, X509 *x, int op) > { > /* Lookup signature algorithm digest */ > int secbits, nid, pknid; > /* Don't check signature if self signed */ > if ((X509_get_extension_flags(x) & EXFLAG_SS) != 0) > return 1; So I failed to look just one more layer down the call stack. :-( Thanks for the sanity check. -- Viktor. From aerowolf at gmail.com Wed Mar 11 19:30:48 2020 From: aerowolf at gmail.com (Kyle Hamilton) Date: Wed, 11 Mar 2020 14:30:48 -0500 Subject: Negotiated cipher per proto (matching cipher in list missing). No further cipher order check has been done as order is determined by the client In-Reply-To: References: Message-ID: ssl_prefer_server_ciphers on; On Wed, Mar 11, 2020, 11:58 Kaushal Shriyan wrote: > > > On Wed, Mar 11, 2020 at 6:36 PM Michael Wojcik < > Michael.Wojcik at microfocus.com> wrote: > >> To enforce the server's cipher order, use SSL_CTX_set_options(*ctx*, >> SSL_CTX_get_options(*ctx*) | SSL_OP_CIPHER_SERVER_PREFERENCE). >> >> https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_set_options.html >> >> ------------------------------ >> >> >> Testing server preferences >> Has server cipher order? no (NOT ok) >> ... >> No further cipher order check has been done as order is determined by the >> client >> >> >> > Hi Michael, > > Thanks for the email. I am not sure if i understand it completely. what > does the server's cipher order mean in layman's terms? Any example > regarding To enforce the server's cipher order, use > SSL_CTX_set_options(ctx, SSL_CTX_get_options(ctx) | > SSL_OP_CIPHER_SERVER_PREFERENCE) to set it in /etc/nginx/nginx.conf. I am > running Nginx web server. > > I have the below settings in /etc/nginx/nginx.conf > > server { > listen 443 ssl; > ssl_protocols TLSv1.2; > ssl_ciphers > ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; > ssl_prefer_server_ciphers off; > } > > Please suggest. I look forward to hearing from you and thanks in advance. > > Best Regards, > > Kaushal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaushalshriyan at gmail.com Thu Mar 12 03:32:09 2020 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Thu, 12 Mar 2020 09:02:09 +0530 Subject: Negotiated cipher per proto (matching cipher in list missing). No further cipher order check has been done as order is determined by the client In-Reply-To: References: Message-ID: On Thu, Mar 12, 2020 at 1:01 AM Kyle Hamilton wrote: > ssl_prefer_server_ciphers on; > > On Wed, Mar 11, 2020, 11:58 Kaushal Shriyan > wrote: > >> >> >> On Wed, Mar 11, 2020 at 6:36 PM Michael Wojcik < >> Michael.Wojcik at microfocus.com> wrote: >> >>> To enforce the server's cipher order, use SSL_CTX_set_options(*ctx*, >>> SSL_CTX_get_options(*ctx*) | SSL_OP_CIPHER_SERVER_PREFERENCE). >>> >>> https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_set_options.html >>> >>> ------------------------------ >>> >>> >>> Testing server preferences >>> Has server cipher order? no (NOT ok) >>> ... >>> No further cipher order check has been done as order is determined by >>> the client >>> >>> >>> >> Hi Michael, >> >> Thanks for the email. I am not sure if i understand it completely. what >> does the server's cipher order mean in layman's terms? Any example >> regarding To enforce the server's cipher order, use >> SSL_CTX_set_options(ctx, SSL_CTX_get_options(ctx) | >> SSL_OP_CIPHER_SERVER_PREFERENCE) to set it in /etc/nginx/nginx.conf. I am >> running Nginx web server. >> >> I have the below settings in /etc/nginx/nginx.conf >> >> server { >> listen 443 ssl; >> ssl_protocols TLSv1.2; >> ssl_ciphers >> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; >> ssl_prefer_server_ciphers off; >> } >> >> Please suggest. I look forward to hearing from you and thanks in advance. >> >> Best Regards, >> >> Kaushal >> > Thanks Michael for the explanation and much appreciated. Thanks a lot, Kyle for the reply. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maoly527 at 163.com Thu Mar 12 08:03:42 2020 From: maoly527 at 163.com (maoly527 at 163.com) Date: Thu, 12 Mar 2020 16:03:42 +0800 Subject: Issue about CRL verification Message-ID: <1owt92-dwrsww1156fnw8uq2m-48p3ow8bfiui-iud398bzqy7wsc3jlg22rvwkwb743vnz244u-hzih2ip5knjmulgue1-l1rzz0uo1iwb-by4vg9-ot3zxh-yq5abh-80gxsbx2x55f-jn94rd-mj034v.1583998974754@email.android.com> An HTML attachment was scrubbed... URL: From iliya.yurkevic at mail.ru Fri Mar 13 07:19:50 2020 From: iliya.yurkevic at mail.ru (=?UTF-8?B?0JjQu9GM0Y8g0K7RgNC60LXQstC40YcgKElseWEgWXVya2V2aWNoKQ==?=) Date: Fri, 13 Mar 2020 10:19:50 +0300 Subject: =?UTF-8?B?SG93IGNyZWF0ZSBjbXMgc2lnbmVkIGRhdGEgdXNpbmcgdGhlIG1lc3NhZ2Ug?= =?UTF-8?B?ZGlnZXN0IGluc3RlYWQgb2YgYSBkYXRh?= In-Reply-To: <1583484280.202146788@f128.i.mail.ru> References: <1583309912.685556862@f56.i.mail.ru> <1583484280.202146788@f128.i.mail.ru> Message-ID: <1584083990.677499482@f537.i.mail.ru> Hello everyone. I have the?digest of a data (message digest). How I can create cms signed data using the digest instead of a data? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaushalshriyan at gmail.com Fri Mar 13 20:25:32 2020 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Sat, 14 Mar 2020 01:55:32 +0530 Subject: TLS version 1.3 in Production servers. Message-ID: Hi, I am reading this article https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3 I have a followup question regarding TLS version 1.3. Can we use it in production servers or it is good to be on TLS version 1.2? I look forward to hearing from you. Thanks in advance. Best Regards, Kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sat Mar 14 13:02:45 2020 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 14 Mar 2020 13:02:45 +0000 Subject: TLS version 1.3 in Production servers. In-Reply-To: References: Message-ID: <787035CE-573E-46B7-AF98-CA7508E7611B@akamai.com> * I am reading this article https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3 I have a followup question regarding TLS version 1.3. Can we use it in production servers or it is good to be on TLS version 1.2? I look forward to hearing from you. There are no problems with the protocol; it has had extensive analysis. There are no known implementation bugs, but of course that doesn?t mean there are none. Most browsers will use TLS 1.3 if the server supports it. Many big websites or providers use it. Go ahead. It does a smidgen more crypto work, but client/server latency is reduced. As for TLS 1.2, it has not had as much analysis, but has no known protocol flaws. It is also considered safe to use. Do not use TLS 1.1, TLS 1.0 or SSL 3. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaushalshriyan at gmail.com Sat Mar 14 13:41:49 2020 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Sat, 14 Mar 2020 19:11:49 +0530 Subject: TLS version 1.3 in Production servers. In-Reply-To: <787035CE-573E-46B7-AF98-CA7508E7611B@akamai.com> References: <787035CE-573E-46B7-AF98-CA7508E7611B@akamai.com> Message-ID: On Sat, Mar 14, 2020 at 6:32 PM Salz, Rich wrote: > > - I am reading this article > https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3 > I > have a followup question regarding TLS version 1.3. Can we use it in > production servers or it is good to be on TLS version 1.2? I look forward > to hearing from you. > > > > There are no problems with the protocol; it has had extensive analysis. > There are no known implementation bugs, but of course that doesn?t mean > there are none. Most browsers will use TLS 1.3 if the server supports it. > Many big websites or providers use it. Go ahead. It does a smidgen more > crypto work, but client/server latency is reduced. > > > > As for TLS 1.2, it has not had as much analysis, but has no known protocol > flaws. It is also considered safe to use. > > > > Do not use TLS 1.1, TLS 1.0 or SSL 3. > > > Thanks Rich Salz for the explanation and much appreciated. Please suggest me books or tutorials to understand OpenSSL and TLS cryptographic protocol in detail. I look forward to hearing from you. Thanks in advance. Best Regards, Kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sat Mar 14 13:43:30 2020 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 14 Mar 2020 13:43:30 +0000 Subject: TLS version 1.3 in Production servers. In-Reply-To: References: <787035CE-573E-46B7-AF98-CA7508E7611B@akamai.com> Message-ID: > Please suggest me books or tutorials to understand OpenSSL and TLS cryptographic protocol in detail. I look forward to hearing from you. Thanks in advance. Start with the RFC?s, then look for crypto basics ? there are free books online. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaushalshriyan at gmail.com Sat Mar 14 18:55:39 2020 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Sun, 15 Mar 2020 00:25:39 +0530 Subject: TLS 1.3 protocol question Message-ID: Hi, I have been going through RFC's regarding the TLS version 1.3 protocol. I am curious to know does it mean that the TLS version 1.3 protocol is a specification or standard to communicate between client and server? And OpenSSL is a cryptography library to implement TLS version 1.3 protocol? What is the programming language used for the specification of the TLS version 1.3 protocol? Please correct me if I am asking any questions which are irrelevant. Thanks in advance and I look forward to hearing from you. Best Regards, Kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sat Mar 14 19:53:11 2020 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 14 Mar 2020 19:53:11 +0000 Subject: TLS 1.3 protocol question In-Reply-To: References: Message-ID: <07FE4AB3-B116-49BD-9F69-1B926F812434@akamai.com> The TLS RFC describes the ?bytes on the wire? ? the syntax for how client and server communicate, and the semantics of those exchanges. Is it a specification or standard? Yup both. Is OpenSSL implementation of the spec? Yup. What language used in the spec? It?s described in the RFC; see ?presentation language? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaushalshriyan at gmail.com Sun Mar 15 04:16:17 2020 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Sun, 15 Mar 2020 09:46:17 +0530 Subject: TLS version 1.3 in Production servers. In-Reply-To: References: <787035CE-573E-46B7-AF98-CA7508E7611B@akamai.com> Message-ID: Thanks Rich Salz for the email. Further to your email, I will appreciate it if you can point me to suggested and recommended online books to understand cryptography. I look forward to hearing from you. Thanks in advance. Best Regards, On Sat, Mar 14, 2020 at 7:13 PM Salz, Rich wrote: > *>* Please suggest me books or tutorials to understand OpenSSL and TLS > cryptographic protocol in detail. I look forward to hearing from you. > Thanks in advance. > > > > Start with the RFC?s, then look for crypto basics ? there are free books > online. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaushalshriyan at gmail.com Sun Mar 15 04:16:27 2020 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Sun, 15 Mar 2020 09:46:27 +0530 Subject: TLS 1.3 protocol question In-Reply-To: <07FE4AB3-B116-49BD-9F69-1B926F812434@akamai.com> References: <07FE4AB3-B116-49BD-9F69-1B926F812434@akamai.com> Message-ID: Thank you for the clarification. On Sun, Mar 15, 2020 at 1:23 AM Salz, Rich wrote: > The TLS RFC describes the ?bytes on the wire? ? the syntax for how client > and server communicate, and the semantics of those exchanges. > > > > Is it a specification or standard? Yup both. > > > > Is OpenSSL implementation of the spec? Yup. > > > > What language used in the spec? It?s described in the RFC; see > ?presentation language? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guerinp at talasi.fr Mon Mar 16 15:43:53 2020 From: guerinp at talasi.fr (=?UTF-8?Q?Patrice_Gu=c3=a9rin?=) Date: Mon, 16 Mar 2020 16:43:53 +0100 Subject: Possible Cause of error ? Message-ID: Hello, Can anybody tell me what is a possible cause of error status 20087002 : 'BIO routines:BIO_lookup:system lib' This happens only once on Debian 9 standard OpenSSL package (1.1.0l-1~deb9u1) Thank you in advance. Kind regards, Patrice. From mahendra.sp at gmail.com Tue Mar 17 07:42:46 2020 From: mahendra.sp at gmail.com (Mahendra SP) Date: Tue, 17 Mar 2020 13:12:46 +0530 Subject: Regarding engine implementation for RSA and AES Message-ID: Hi, We are looking at implementing an engine for RSA and AES. For AES, looking at the documentation, understand that engine will get invoked only if the application or SSL library invokes EVP based calls rather than native AES calls. Is this correct ? For RSA, is it mandatory to use EVP for using engine ? Openssl version dependency: Is it a must to use latest openssl version for engine ? Reason for this question is, looking at 1.1.X code, all the calls are modified to EVP in SSL library when compared to previous versions. As understanding is, engine works with EVP, wanted to know if we need to use latest version. Thanks Mahendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From guoxiaobinni at 163.com Tue Mar 17 09:04:34 2020 From: guoxiaobinni at 163.com (guoxiaobinni at 163.com) Date: Tue, 17 Mar 2020 17:04:34 +0800 Subject: =?utf-8?Q?=E5=9B=9E=E5=A4=8D:_=3CPlease_advise=3E_Ues_'openssl?= =?utf-8?Q?_s=5Fserver_command'_to_disable_TL?= =?utf-8?Q?S1.0?= In-Reply-To: <1206dda7-6823-b426-a1cb-2f66d906c052@openssl.org> References: <000001d5f1ff$49276250$db7626f0$@163.com> <1206dda7-6823-b426-a1cb-2f66d906c052@openssl.org> Message-ID: <000001d5fc3b$14b3dee0$3e1b9ca0$@163.com> Hi Matt, I have asked senior colleague for running the following commands on Redhat Linux server. $ openssl s_server -no_tls1 -key keyfile -cert certname $ openssl s_client -no_tls1 May I know any actions will make them take effect after run? -----????----- ???: Matt Caswell ????: 2020?3?4? 19:41 ???: guoxiaobinni at 163.com; openssl-users at openssl.org ??: erik.y.h.liang at hsbc.com.cn; damontsli at hangseng.com ??: Re: Ues 'openssl s_server command' to disable TLS1.0 On 04/03/2020 08:31, guoxiaobinni at 163.com wrote: > Thanks Matt, > > As your advice, I tried to execute the following both commands to disable TLS 1.0 for Client and Server separately. Since I have no right to access private keyfile, of course they failed. Could you please correct me if the command format is fine? I then will assign them to senior colleague to execute. > > $ openssl s_server -no_tls1 -key keyfile -cert certname $ openssl > s_client -no_tls1 -key keyfile [-cert certname] The format for s_server is fine. There is no need to supply the -key and -cert options to s_client unless you are wanting to test client authentication. However, I'm still not convinced you have understood what these commands actually do. They will create a test server, and a initiate a test client to connect to it respectively - and will disable TLSv1.0 for those instances only. Typically you would only do this with test keys/certs not with production keys/certs. It will have no impact on any other servers/clients running in your environment. Matt > > Thanks. > Chobin > > -----????----- > ???: openssl-users-bounces at openssl.org > [mailto:openssl-users-bounces at openssl.org] ?? Matt Caswell > ????: 2020?3?3? 18:51 > ???: openssl-users at openssl.org > ??: Re: Ues 'openssl s_server command' to disable > TLS1.0 > > > > On 03/03/2020 07:48, guoxiaobinni at 163.com wrote: >> Dear All, >> >> >> >> I hit the following error when used ?openssl s_server -no_tls1? >> command to disable TLS1.0 on Redhat Linux server. > > Your question is slightly ambiguous. It implies you expect the command > to disable TLSv1.0 for all applications on your server. If that is > what you meant then you will be disappointed. "openssl s_server" runs > a test server to enable testing TLS connections from clients. The "-no_tls1" > option disables TLSv1.0 for that test server instance only. > > If you really mean to start a test server then you need to > additionally supply a key and certificate file. By default s_server > will look for the key/cert in the file server.pem in the current working directory. > Otherwise you have to explicitly state the location of these files > with the "-key" and "-cert" options. > > Matt > > > >> It shows the openssl version >> as well. >> >> >> >> --------------------------------------------------------------------- >> --------------------------------------------------------------------- >> ---------- >> >> $ openssl version >> >> OpenSSL 1.0.1e-fips 11 Feb 2013 >> >> $ openssl s_server ?no_tls1 >> >> Error opening server certificate private key file server.pem >> >> 140057863432008:error:02001002:system library:fopen:No such file or >> directory:bss_file.c:398:fopen(?server.pem?,?r?) >> >> 140057863432008:error:20074002:BIO routines:FILE_CTRL:system >> lib:bss_file.c:400: >> >> unable to load server certificate private key file >> >> --------------------------------------------------------------------- >> --------------------------------------------------------------------- >> ----------- >> >> >> >> I can?t confirm if the command format is fine or not. Would you >> please help to correct me? >> >> >> >> Thanks and Regards, >> >> Chobin Guo >> > > From hamedsalini6 at gmail.com Tue Mar 17 09:32:40 2020 From: hamedsalini6 at gmail.com (hamed salini) Date: Tue, 17 Mar 2020 13:02:40 +0330 Subject: No subject Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Mar 17 10:44:40 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 17 Mar 2020 10:44:40 +0000 Subject: Regarding engine implementation for RSA and AES In-Reply-To: References: Message-ID: On 17/03/2020 07:42, Mahendra SP wrote: > Hi, > > We are looking at implementing an engine for RSA and AES. > > For AES, looking at the documentation, understand that engine will get > invoked only if the application or SSL library invokes EVP based calls > rather than?native AES calls. Is this correct ? Yes. Note that the low-level AES API will be deprecated in the forthcoming OpenSSL 3.0. > > For RSA, is it mandatory to use EVP for using engine ? No. You can hook in using RSA_METHOD or EVP_PKEY_METHOD. The RSA low-level APIs (including RSA_METHOD) will also be deprecated in the forthcoming OpenSSL 3.0. > Is it a must to use latest openssl version for engine ? Reason for this > question is, looking at 1.1.X code, all the calls are modified to EVP in > SSL library when compared to previous versions. As understanding is, > engine works with EVP, wanted to know if we need to use latest version. Engines have been around for a long time. Not sure how well they worked in conjunction with libssl in previous versions. But in any case the only supported version at the moment is OpenSSL 1.1.1. All other versions are EOL. Note that Engines themselves are also being deprecated in OpenSSL 3.0. They are being replaced by the new provider interface. Depending on the the time frame that you want this functionality you might be better off writing a provider (OpenSSL 3.0 is scheduled for release in Q4 this year). Matt From hkario at redhat.com Tue Mar 17 11:01:56 2020 From: hkario at redhat.com (Hubert Kario) Date: Tue, 17 Mar 2020 12:01:56 +0100 Subject: Create p12 from a .pem with only a private key In-Reply-To: <1582187756700-0.post@n7.nabble.com> References: <51E0B7F1-26DF-4D03-BDE5-ABBDE29EBABD@webweaving.org> <1582187756700-0.post@n7.nabble.com> Message-ID: <99b47ff5-7bf2-4c00-9e50-406a6baaa9a0@redhat.com> On Thursday, 20 February 2020 09:35:56 CET, Estefania wrote: > I do not know if I explained well, i have a .pem with a private key inside > like this. > > -----BEGIN PRIVATE KEY----- > masdfasdfasdfasdfasdfasdfasdff > asdfasdfasdfasdfasdfasdfasdfasf > asdfasfasdfasdfasdfasdfasdfasdf > -----END PRIVATE KEY----- > > > and i need to convert it to .p12 > > do i need a certificate aswell? technically, no, the standard allows for storing just the key in the PKCS#12 file that being said, I can imagine many implementations tripping over such files if you have a private key in "localhost.key" you can convert it to a PKCS#12 file using the following command: openssl pkcs12 -export -out file.p12 -inkey localhost.key -nocerts -keypbe aes-128-cbc -passout pass:password > I have tried what you suggest: > $ openssl req -x509 -subj /CN=foo -keyout /dev/null -nodes | openssl pkcs12 > -out x.p12 -export -nokeys > Generating a 2048 bit RSA private key > ................+++ > .+++ > writing new private key to 'nul' > ----- > Subject does not start with '/'. > problems making Certificate Request > unable to load certificates > > Thanks! > > > > > > -- > Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html > > > -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic From hkario at redhat.com Tue Mar 17 11:10:37 2020 From: hkario at redhat.com (Hubert Kario) Date: Tue, 17 Mar 2020 12:10:37 +0100 Subject: =?utf-8?B?5Zue5aSNOiA8UGxlYXNlIGFkdmlzZT4gVWVzICdvcGVuc3NsIHNfc2VydmVyIA==?= =?utf-8?B?Y29tbWFuZCcgdG8gZGlzYWJsZSBUTFMxLjA=?= In-Reply-To: <000001d5fc3b$14b3dee0$3e1b9ca0$@163.com> References: <000001d5f1ff$49276250$db7626f0$@163.com> <1206dda7-6823-b426-a1cb-2f66d906c052@openssl.org> <000001d5fc3b$14b3dee0$3e1b9ca0$@163.com> Message-ID: On Tuesday, 17 March 2020 10:04:34 CET, guoxiaobinni at 163.com wrote: > Hi Matt, > > I have asked senior colleague for running the following > commands on Redhat Linux server. > $ openssl s_server -no_tls1 -key keyfile -cert certname > $ openssl s_client -no_tls1 > > May I know any actions will make them take effect after run? `openssl s_client` and `openssl s_server` are debugging tools any command line options passed to them affect only those tools it will not affect apache, curl, nginx, or any other application that uses the openssl library Please contact Red Hat support on how to configure specific servers or clients. You may also find the information you're looking for in the Red Hat Customer Portal: https://access.redhat.com/articles/1462183 > -----????----- > ???: Matt Caswell > ????: 2020?3?4? 19:41 > ???: guoxiaobinni at 163.com; openssl-users at openssl.org > ??: erik.y.h.liang at hsbc.com.cn; damontsli at hangseng.com > ??: Re: Ues 'openssl s_server command' to disable TLS1.0 > > > > On 04/03/2020 08:31, guoxiaobinni at 163.com wrote: >> Thanks Matt, >> >> As your advice, I tried to execute the following both commands >> to disable TLS 1.0 for Client and Server separately. Since I >> have no right to access private keyfile, of course they failed. >> Could you please correct me if the command format is fine? I >> then will assign them to senior colleague to execute. >> >> $ openssl s_server -no_tls1 -key keyfile -cert certname $ openssl >> s_client -no_tls1 -key keyfile [-cert certname] > > The format for s_server is fine. There is no need to supply the > -key and -cert options to s_client unless you are wanting to > test client authentication. > > However, I'm still not convinced you have understood what these > commands actually do. They will create a test server, and a > initiate a test client to connect to it respectively - and will > disable TLSv1.0 for those instances only. Typically you would > only do this with test keys/certs not with production > keys/certs. It will have no impact on any other servers/clients > running in your environment. > > Matt > >> Thanks. >> Chobin >> >> -----????----- >> ???: openssl-users-bounces at openssl.org >> [mailto:openssl-users-bounces at openssl.org] ?? Matt Caswell ... > > > > -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic From guoxiaobinni at 163.com Tue Mar 17 12:02:36 2020 From: guoxiaobinni at 163.com (163) Date: Tue, 17 Mar 2020 20:02:36 +0800 Subject: =?utf-8?Q?Re:_=E5=9B=9E=E5=A4=8D:__Ues_'openssl_s?= =?utf-8?Q?=5Fserver_command'_to_disable_TLS1.0?= In-Reply-To: References: <000001d5f1ff$49276250$db7626f0$@163.com> <1206dda7-6823-b426-a1cb-2f66d906c052@openssl.org> <000001d5fc3b$14b3dee0$3e1b9ca0$@163.com> Message-ID: <1D7FA605-048F-4F45-96F7-8296DD6F3D83@163.com> Hi Hubert, Sorry for unclear description. I just want to disable TLS 1.0 on Redhat Linux server. After run those both commands, then how to take them effect or no need any. May I have your more advice? Chobin > ? 2020?3?17??19:10?Hubert Kario ??? > >> On Tuesday, 17 March 2020 10:04:34 CET, guoxiaobinni at 163.com wrote: >> Hi Matt, >> >> I have asked senior colleague for running the following commands on Redhat Linux server. >> $ openssl s_server -no_tls1 -key keyfile -cert certname >> $ openssl s_client -no_tls1 >> >> May I know any actions will make them take effect after run? > > `openssl s_client` and `openssl s_server` are debugging tools > > any command line options passed to them affect only those tools > > it will not affect apache, curl, nginx, or any other application that uses > the openssl library > > Please contact Red Hat support on how to configure specific servers or clients. > You may also find the information you're looking for in the Red Hat Customer > Portal: > https://access.redhat.com/articles/1462183 > > >> -----????----- >> ???: Matt Caswell ????: 2020?3?4? 19:41 >> ???: guoxiaobinni at 163.com; openssl-users at openssl.org >> ??: erik.y.h.liang at hsbc.com.cn; damontsli at hangseng.com >> ??: Re: Ues 'openssl s_server command' to disable TLS1.0 >> >> >> >>> On 04/03/2020 08:31, guoxiaobinni at 163.com wrote: >>> Thanks Matt, >>> As your advice, I tried to execute the following both commands to disable TLS 1.0 for Client and Server separately. Since I have no right to access private keyfile, of course they failed. Could you please correct me if the command format is fine? I then will assign them to senior colleague to execute. >>> $ openssl s_server -no_tls1 -key keyfile -cert certname $ openssl s_client -no_tls1 -key keyfile [-cert certname] >> >> The format for s_server is fine. There is no need to supply the -key and -cert options to s_client unless you are wanting to test client authentication. >> >> However, I'm still not convinced you have understood what these commands actually do. They will create a test server, and a initiate a test client to connect to it respectively - and will disable TLSv1.0 for those instances only. Typically you would only do this with test keys/certs not with production keys/certs. It will have no impact on any other servers/clients running in your environment. >> >> Matt >> >>> Thanks. >>> Chobin >>> -----????----- >>> ???: openssl-users-bounces at openssl.org [mailto:openssl-users-bounces at openssl.org] ?? Matt Caswell ... >> >> >> >> > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic From lionel.monchecourt at free.fr Tue Mar 17 12:33:45 2020 From: lionel.monchecourt at free.fr (Lionel Monchecourt) Date: Tue, 17 Mar 2020 13:33:45 +0100 Subject: AD with PKI authentication - issue on cert generation Message-ID: <00aa01d5fc58$4d974ae0$e8c5e0a0$@free.fr> Hi, I'm trying to install an AD with PKI auth.I'm so referring to : https://wiki.samba.org/index.php/Samba_AD_Smart_Card_Login Let's put aside of course Samba config .. I'm now trying to generate the root CA. Using the template in the wiki , When I try to openssl req -new req -new -x509 -days 3650 -sha256 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -config /etc/ssl/openssl.cnf I get the following error : problem creating object msSmartcardLogin=1.3.6.1.4.1.311.20.2.2 140375913190464:error:08064066:object identifier routines:OBJ_create:oid exists:../crypto/objects/obj_dat.c:698: I already tried to replace scardLogin=1.3.6.1.4.1.311.20.2.2 with msSmartcardLogin=1.3.6.1.4.1.311.20.2.2 as I found in the thred but it doesn't solve my issue. I can post in SSL forum but as it is Samba specific, I'm trying here first as I guess I'm missing something basic ? Please note that I do not intend to use smartcard, but ONLY certificate, if it can help Thanks ! Lionel -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkario at redhat.com Tue Mar 17 12:35:07 2020 From: hkario at redhat.com (Hubert Kario) Date: Tue, 17 Mar 2020 13:35:07 +0100 Subject: =?utf-8?B?5Zue5aSNOiA8UGxlYXNlIGFkdmlzZT4gVWVzICdvcGVuc3NsIHNfc2VydmVyIA==?= =?utf-8?B?Y29tbWFuZCcgdG8gZGlzYWJsZSBUTFMxLjA=?= In-Reply-To: <1D7FA605-048F-4F45-96F7-8296DD6F3D83@163.com> References: <000001d5f1ff$49276250$db7626f0$@163.com> <1206dda7-6823-b426-a1cb-2f66d906c052@openssl.org> <000001d5fc3b$14b3dee0$3e1b9ca0$@163.com> <1D7FA605-048F-4F45-96F7-8296DD6F3D83@163.com> Message-ID: <744f909b-1d78-4913-bd3a-f66334509bdf@redhat.com> On Tuesday, 17 March 2020 13:02:36 CET, 163 wrote: > Hi Hubert, > > Sorry for unclear description. I just want to disable TLS 1.0 > on Redhat Linux server. After run those both commands, then how > to take them effect or no need any. May I have your more advice? there is a language barrier please contact red hat support: they can talk in Cantonese and Mandarin see https://access.redhat.com/support/contact/technicalSupport/ or open a new support case here: https://access.redhat.com/support/cases/new >> ? 2020?3?17??19:10?Hubert Kario ??? >> >>> On Tuesday, 17 March 2020 10:04:34 CET, guoxiaobinni at 163.com wrote: >>> Hi Matt, >>> >>> I have asked senior colleague for running the following >>> commands on Redhat Linux server. >>> $ openssl s_server -no_tls1 -key keyfile -cert certname >>> $ openssl s_client -no_tls1 ... >> >> `openssl s_client` and `openssl s_server` are debugging tools >> >> any command line options passed to them affect only those tools >> >> it will not affect apache, curl, nginx, or any other application that uses >> the openssl library >> >> Please contact Red Hat support on how to configure specific >> servers or clients. >> You may also find the information you're looking for in the >> Red Hat Customer >> Portal: >> https://access.redhat.com/articles/1462183 >> >> >>> -----????----- >>> ???: Matt Caswell ????: 2020?3?4? 19:41 >>> ???: guoxiaobinni at 163.com; openssl-users at openssl.org >>> ??: erik.y.h.liang at hsbc.com.cn; damontsli at hangseng.com >>> ??: Re: Ues 'openssl s_server command' to >>> disable TLS1.0 ... >> >> -- >> Regards, >> Hubert Kario >> Senior Quality Engineer, QE BaseOS Security team >> Web: www.cz.redhat.com >> Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic > > > > -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic From matt at openssl.org Tue Mar 17 13:10:04 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 17 Mar 2020 13:10:04 +0000 Subject: AD with PKI authentication - issue on cert generation In-Reply-To: <00aa01d5fc58$4d974ae0$e8c5e0a0$@free.fr> References: <00aa01d5fc58$4d974ae0$e8c5e0a0$@free.fr> Message-ID: <2a2126a0-0d00-9195-8c1c-ac58bd047329@openssl.org> On 17/03/2020 12:33, Lionel Monchecourt wrote: > I already tried to replace > > scardLogin=1.3.6.1.4.1.311.20.2.2 > > with > > msSmartcardLogin=1.3.6.1.4.1.311.20.2.2 Try removing this line altogether. OpenSSL already has a built-in object of this name with this OID so it should not be necessary. Matt > > as I found in the thred but it doesn?t solve my issue. > > I can post in SSL forum but as it is Samba specific, I?m trying here > first as I guess I?m missing something basic ? > > ? > > Please note that I do not intend to use smartcard, but ONLY certificate, > if it can help > > Thanks ! > > ? > > Lionel > > ? > > > > Virus-free. www.avast.com > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> From openssl at openssl.org Tue Mar 17 15:59:54 2020 From: openssl at openssl.org (OpenSSL) Date: Tue, 17 Mar 2020 15:59:54 +0000 Subject: OpenSSL version 1.1.1e published Message-ID: <20200317155954.GA16110@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.1e released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1e of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1e is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1e.tar.gz Size: 9792634 SHA1 checksum: e7105567d3e7e6353a0110f1adc81f69dbc8f732 SHA256 checksum: 694f61ac11cb51c9bf73f54e771ff6022b0327a43bbdfa1b2f19de1662a6dcbe The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1e.tar.gz openssl sha256 openssl-1.1.1e.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl5w3zsACgkQ2cTSbQ5g RJFdTQf+OeJkXlBCQvdJTv7ky6y7MGesCiMjcQsuFSLlWCHC6k2rNcgrZUH50vOB E6SH/VPvmreM+TNy95hP2uzGtFkpliIoZHu6NXJSo7QW9svBxzdqo8x7nYN3jhJ1 pEDjfk2vFz2Z/2uzoZdZVe4P8C4O4bFz79UmFUsXNffYcO0mDSih1jrjupASzSJH 0HB68p4lrdoJbiL6KIfGDLS5D+jn6KNU6gHT/6fhCalLQJ1StajpArrXXKrC2apP YAMTLYH5qxFReobKguOk6RwZnNI2Mdl75qWJ+Wu4PQORPryPeMJ00z82jx6Wv5zF vWQ4F8zoaiPfUSmyzOJgJQuRwrnNfg== =1uA3 -----END PGP SIGNATURE----- From lionel.monchecourt at free.fr Wed Mar 18 11:35:13 2020 From: lionel.monchecourt at free.fr (Lionel Monchecourt) Date: Wed, 18 Mar 2020 12:35:13 +0100 Subject: Connection to ADSI edit Message-ID: <017001d5fd19$4afcd130$e0f67390$@free.fr> Hi, I'm trying to get connected through the Microsoft ADSI tool to my server but get the follwing error message : Operation failed error code : 0x80090350 The System cannot contact a domain controller to service the authentication request. Please try again later. I want to set a Widows AD PKI auth and so following this documentation ( stuck in this step ) : https://wiki.samba.org/index.php/Samba_AD_Smart_Card_Login#Obtain_Each_User. 27s_User_Principal_Name_.28UPN.29_and_the_Domain_Controller.27s_GUID Please note that : - I have of course registered the computer to the domain - I'm able to get connected through Microsoft computer / user config tool and it works. - When I launch the ADSI edit tool, opposite to what is said in the doc, I must provide the server/domain to connect to ( can not leave the fault choice to "Domain or server that you logged in to ) - related ( or not ), I can not get connected through the Microsoft DNS mngt tool to my server - when I try to connect from this computer to the server with a generic ldap client, it works Any insights ? Thanks ! -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From lionel.monchecourt at free.fr Wed Mar 18 11:35:13 2020 From: lionel.monchecourt at free.fr (Lionel Monchecourt) Date: Wed, 18 Mar 2020 12:35:13 +0100 Subject: AD with PKI authentication - issue on cert generation In-Reply-To: <2a2126a0-0d00-9195-8c1c-ac58bd047329@openssl.org> References: <00aa01d5fc58$4d974ae0$e8c5e0a0$@free.fr> <2a2126a0-0d00-9195-8c1c-ac58bd047329@openssl.org> Message-ID: <017501d5fd19$4d6daa20$e848fe60$@free.fr> Hi Matt, Thanks a lot, Getting the same error for msUPN=1.3.6.1.4.1.311.20.2.3, I removed it as well is it by default in openssl as well ? btw, removing these 2, I can generate my certificate without problem -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell Sent: 17 March 2020 14:10 To: openssl-users at openssl.org Subject: Re: AD with PKI authentication - issue on cert generation On 17/03/2020 12:33, Lionel Monchecourt wrote: > I already tried to replace > > scardLogin=1.3.6.1.4.1.311.20.2.2 > > with > > msSmartcardLogin=1.3.6.1.4.1.311.20.2.2 Try removing this line altogether. OpenSSL already has a built-in object of this name with this OID so it should not be necessary. Matt > > as I found in the thred but it doesn?t solve my issue. > > I can post in SSL forum but as it is Samba specific, I?m trying here > first as I guess I?m missing something basic ? > > ? > > Please note that I do not intend to use smartcard, but ONLY certificate, > if it can help > > Thanks ! > > ? > > Lionel > > ? > > > > Virus-free. www.avast.com > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From matt at openssl.org Wed Mar 18 11:37:21 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 18 Mar 2020 11:37:21 +0000 Subject: AD with PKI authentication - issue on cert generation In-Reply-To: <017501d5fd19$4d6daa20$e848fe60$@free.fr> References: <00aa01d5fc58$4d974ae0$e8c5e0a0$@free.fr> <2a2126a0-0d00-9195-8c1c-ac58bd047329@openssl.org> <017501d5fd19$4d6daa20$e848fe60$@free.fr> Message-ID: <7a0c2e90-6bcf-0d3c-8d1d-76a9e7698686@openssl.org> On 18/03/2020 11:35, Lionel Monchecourt wrote: > Hi Matt, > Thanks a lot, > Getting the same error for > msUPN=1.3.6.1.4.1.311.20.2.3, I removed it as well > is it by default in openssl as well ? > btw, removing these 2, I can generate my certificate without problem Yes - it exists so removing it should be fine. Matt > > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of > Matt Caswell > Sent: 17 March 2020 14:10 > To: openssl-users at openssl.org > Subject: Re: AD with PKI authentication - issue on cert generation > > > > On 17/03/2020 12:33, Lionel Monchecourt wrote: > >> I already tried to replace >> >> scardLogin=1.3.6.1.4.1.311.20.2.2 >> >> with >> >> msSmartcardLogin=1.3.6.1.4.1.311.20.2.2 > > Try removing this line altogether. OpenSSL already has a built-in object > of this name with this OID so it should not be necessary. > > Matt > >> >> as I found in the thred but it doesn?t solve my issue. >> >> I can post in SSL forum but as it is Samba specific, I?m trying here >> first as I guess I?m missing something basic ? >> >> ? >> >> Please note that I do not intend to use smartcard, but ONLY certificate, >> if it can help >> >> Thanks ! >> >> ? >> >> Lionel >> >> ? >> >> >> > gn=sig-email&utm_content=emailclient> >> Virus-free. www.avast.com >> > gn=sig-email&utm_content=emailclient> >> >> >> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > From lionel.monchecourt at free.fr Wed Mar 18 11:40:24 2020 From: lionel.monchecourt at free.fr (Lionel Monchecourt) Date: Wed, 18 Mar 2020 12:40:24 +0100 Subject: AD with PKI authentication - issue on cert generation In-Reply-To: <7a0c2e90-6bcf-0d3c-8d1d-76a9e7698686@openssl.org> References: <00aa01d5fc58$4d974ae0$e8c5e0a0$@free.fr> <2a2126a0-0d00-9195-8c1c-ac58bd047329@openssl.org> <017501d5fd19$4d6daa20$e848fe60$@free.fr> <7a0c2e90-6bcf-0d3c-8d1d-76a9e7698686@openssl.org> Message-ID: <017c01d5fd1a$0522a030$0f67e090$@free.fr> Thanks Matt ! I will let you know if there are any issues further when I will use with the Samba AD server Thx -----Original Message----- From: Matt Caswell [mailto:matt at openssl.org] Sent: 18 March 2020 12:37 To: Lionel Monchecourt Cc: openssl-users at openssl.org Subject: Re: AD with PKI authentication - issue on cert generation On 18/03/2020 11:35, Lionel Monchecourt wrote: > Hi Matt, > Thanks a lot, > Getting the same error for > msUPN=1.3.6.1.4.1.311.20.2.3, I removed it as well > is it by default in openssl as well ? > btw, removing these 2, I can generate my certificate without problem Yes - it exists so removing it should be fine. Matt > > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of > Matt Caswell > Sent: 17 March 2020 14:10 > To: openssl-users at openssl.org > Subject: Re: AD with PKI authentication - issue on cert generation > > > > On 17/03/2020 12:33, Lionel Monchecourt wrote: > >> I already tried to replace >> >> scardLogin=1.3.6.1.4.1.311.20.2.2 >> >> with >> >> msSmartcardLogin=1.3.6.1.4.1.311.20.2.2 > > Try removing this line altogether. OpenSSL already has a built-in object > of this name with this OID so it should not be necessary. > > Matt > >> >> as I found in the thred but it doesn?t solve my issue. >> >> I can post in SSL forum but as it is Samba specific, I?m trying here >> first as I guess I?m missing something basic ? >> >> >> >> Please note that I do not intend to use smartcard, but ONLY certificate, >> if it can help >> >> Thanks ! >> >> >> >> Lionel >> >> >> >> >> > gn=sig-email&utm_content=emailclient> >> Virus-free. www.avast.com >> > gn=sig-email&utm_content=emailclient> >> >> >> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From Michael.Wojcik at microfocus.com Wed Mar 18 13:11:51 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 18 Mar 2020 13:11:51 +0000 Subject: Connection to ADSI edit In-Reply-To: <017001d5fd19$4afcd130$e0f67390$@free.fr> References: <017001d5fd19$4afcd130$e0f67390$@free.fr> Message-ID: This has nothing to do with OpenSSL. Neither AD nor ADSI Edit use OpenSSL. ADSI is an API on top of LDAP (and other non-LDAP "providers"), and LDAP can use TLS as a transport, so in principle you might be able to get an ADSI client such as ADSI Edit to connect to an LDAP server that uses OpenSSL for TLS. But AD does not; it uses Microsoft's SChannel, and that's what the ADSI client-side LDAP provider uses as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lionel.monchecourt at free.fr Wed Mar 18 20:37:17 2020 From: lionel.monchecourt at free.fr (Lionel Monchecourt) Date: Wed, 18 Mar 2020 21:37:17 +0100 Subject: Connection to ADSI edit In-Reply-To: References: <017001d5fd19$4afcd130$e0f67390$@free.fr> Message-ID: <01e501d5fd65$04781340$0d6839c0$@free.fr> Thanks Michael, Yes indeed, I though ssl connection was required and it was failing because of this, but it is not at all Sorry to all for the bad post Thx From: Michael Wojcik [mailto:Michael.Wojcik at microfocus.com] Sent: 18 March 2020 14:12 To: Lionel Monchecourt; openssl-users at openssl.org Subject: Re: Connection to ADSI edit This has nothing to do with OpenSSL. Neither AD nor ADSI Edit use OpenSSL. ADSI is an API on top of LDAP (and other non-LDAP "providers"), and LDAP can use TLS as a transport, so in principle you might be able to get an ADSI client such as ADSI Edit to connect to an LDAP server that uses OpenSSL for TLS. But AD does not; it uses Microsoft's SChannel, and that's what the ADSI client-side LDAP provider uses as well. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From lionel.monchecourt at free.fr Wed Mar 18 21:27:15 2020 From: lionel.monchecourt at free.fr (Lionel Monchecourt) Date: Wed, 18 Mar 2020 22:27:15 +0100 Subject: Issue generating certificate for a Samba AD - index.txt Message-ID: <000001d5fd6b$fffb1270$fff13750$@free.fr> Hi , trying to generate a certify using openssl copenssl ca -config /etc/ssl/user-openssl.cnf -in dc-req.pem -out dc-cert.pem I get the following : Using configuration from /etc/ssl/user-openssl.cnf Enter pass phrase for ./private/cakey.pem: 139946396877888:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:69:fopen('./index.txt','r') 139946396877888:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:76: I found a post saying that you just need to create the index.txt file,but it leads to "no result " Another post was saying to insert in the file "unique_subject = no" Nothing at all ( putting yes or no ), as attempts. Any insights ? Thx -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From sfhacker at hotmail.com Wed Mar 18 22:13:04 2020 From: sfhacker at hotmail.com (Sergio NNX) Date: Wed, 18 Mar 2020 22:13:04 +0000 Subject: Issue generating certificate for a Samba AD - index.txt In-Reply-To: <000001d5fd6b$fffb1270$fff13750$@free.fr> References: <000001d5fd6b$fffb1270$fff13750$@free.fr> Message-ID: We have been creating certificates (Root CA, intermediate, end user, smartcard login, etc) for ages. We have set up our own PKI infrastructure using openssl command line tool. If you email us the details/extensions you need your certificates to have, we can generate some test certs for you. How familiar are you with OpenSSL? Regards. ________________________________ From: openssl-users on behalf of Lionel Monchecourt Sent: Thursday, 19 March 2020 8:27 AM To: openssl-users at openssl.org Subject: Issue generating certificate for a Samba AD - index.txt Hi , trying to generate a certify using openssl copenssl ca -config /etc/ssl/user-openssl.cnf -in dc-req.pem -out dc-cert.pem I get the following : Using configuration from /etc/ssl/user-openssl.cnf Enter pass phrase for ./private/cakey.pem: 139946396877888:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:69:fopen('./index.txt','r') 139946396877888:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:76: I found a post saying that you just need to create the index.txt file,but it leads to ?no result ? Another post was saying to insert in the file ?unique_subject = no? Nothing at all ( putting yes or no ), as attempts? Any insights ? Thx [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif] Virus-free. www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From suvendhu at gmail.com Thu Mar 19 09:23:36 2020 From: suvendhu at gmail.com (Suvendhu Hansa) Date: Thu, 19 Mar 2020 02:23:36 -0700 (MST) Subject: Issue with recursive mutex lock in openssl-1.1.1d Message-ID: <1584609816031-0.post@n7.nabble.com> Hi team, I am upgrading to openssl-1.1.1d in vxworks6.9. In DKM mode vxworks6.9 do not have recursive mutex support. My environment is multitasking so is there any alternative for this issue? Thanks in advance. Best regards, Suvendhu -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From lionel.monchecourt at free.fr Thu Mar 19 21:07:40 2020 From: lionel.monchecourt at free.fr (Lionel Monchecourt) Date: Thu, 19 Mar 2020 22:07:40 +0100 Subject: Issue generating certificate for a Samba AD - index.txt In-Reply-To: References: <000001d5fd6b$fffb1270$fff13750$@free.fr> Message-ID: <00b701d5fe32$6f06e380$4d14aa80$@free.fr> Hi Sergio Thanks a lot My goal is to achieve a SAMBA auth using PKi ( as per ref here : https://wiki.samba.org/index.php/Samba_AD_Smart_Card_Login ) More specifically, related then to openSSL, this chapter https://wiki.samba.org/index.php/Samba_AD_Smart_Card_Login#Prerequisites sounds achievable for you ? Thanks a lot Lionel From: Sergio NNX [mailto:sfhacker at hotmail.com] Sent: 18 March 2020 23:13 To: Lionel Monchecourt; openssl-users at openssl.org Subject: Re: Issue generating certificate for a Samba AD - index.txt We have been creating certificates (Root CA, intermediate, end user, smartcard login, etc) for ages. We have set up our own PKI infrastructure using openssl command line tool. If you email us the details/extensions you need your certificates to have, we can generate some test certs for you. How familiar are you with OpenSSL? Regards. _____ From: openssl-users on behalf of Lionel Monchecourt Sent: Thursday, 19 March 2020 8:27 AM To: openssl-users at openssl.org Subject: Issue generating certificate for a Samba AD - index.txt Hi , trying to generate a certify using openssl copenssl ca -config /etc/ssl/user-openssl.cnf -in dc-req.pem -out dc-cert.pem I get the following : Using configuration from /etc/ssl/user-openssl.cnf Enter pass phrase for ./private/cakey.pem: 139946396877888:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:69:fopen('./index.txt','r') 139946396877888:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:76: I found a post saying that you just need to create the index.txt file,but it leads to "no result " Another post was saying to insert in the file "unique_subject = no" Nothing at all ( putting yes or no ), as attempts. Any insights ? Thx Virus-free. www.avast.com -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfulger at gmx.com Fri Mar 20 10:23:59 2020 From: dfulger at gmx.com (Dan Fulger) Date: Fri, 20 Mar 2020 11:23:59 +0100 Subject: An idiosyncratic port of OpenSSL 1.1.1e to OS/400 ILE Message-ID: This port is for ILE (native OS/400)?not PASE (PASE is almost like Unix, and already comes with openssl). ? The idiosynchrasies are explained in the README.as400 file in AS400patch.tar.gz. ? AS400patch.tar.gz (large patch for OpenSSL and other files): https://drive.google.com/file/d/1XT24UqC5rkPSpCwbFe2CgrTkDCCteEsM/view?usp=sharing Again, the patch is smaller than the one for 1.1.1d?one because EBCDIC?fixes in 1.1.1e?duplicated a part of my patch. ? AS400_GNU.tar.gz (source for GNU/IBM tools required to build openssl in ILE environment): https://drive.google.com/open?id=1DeKIE32nmUpvk7fvrcSYlflUn_k1CBso From jetson23 at hotmail.com Fri Mar 20 15:21:50 2020 From: jetson23 at hotmail.com (Jason Schultz) Date: Fri, 20 Mar 2020 15:21:50 +0000 Subject: OpenSSL server sending certificate chain(inc. root cert) during handshake In-Reply-To: <62B54780-8757-42BB-8C85-559C0A2DE174@dukhovni.org> References: , <62B54780-8757-42BB-8C85-559C0A2DE174@dukhovni.org> Message-ID: I apologize for bringing this old subject back up, but I'm running into something I wanted to poll the list on. Based on Victor's email below, I am doing the following in my application to set up my server to send a certificate chain *excluding* the root certificate during a handshake. status = SSL_CTX_set_mode(ctx, SSL_MODE_NO_AUTO_CHAIN); status = SSL_CTX_build_cert_chain(ctx, SSL_BUILD_CHAIN_FLAG_NO_ROOT); When I configure a certificate chain, the server sends the chain, excluding the root. The call to SSL_CTX_build_cert_chain() accomplishes this, with the "no root" flag. This works as expected. The interesting part comes in when I am configuring a self-signed certificate as the server cert. ** NOTE **: I know this isn't recommended, this is ONLY for test purposes, and our users will configure servers in this way, also ONLY for test purposes. This is why I'm testing the operation of this configuration. As Victor indicated, my EE certificate is also the entire chain; of 1 self-signed certificate. Setting the SSL_MODE_AUTO_CHAIN flag allowed me to configure a self-signed certificate on the server, the two calls above succeed, and my server sends that single, self-signed cert in the handshake. This is true for version 3 self-signed certificates, with the CA bit set. If I have a version 1 *RSA* certificate, with the CA bit NOT set(so CA:FALSE), the call to SSL_CTX_build_cert_chain() errors. I think this is the expected behavior. Does everyone agree with that? Since OpenSSL 1.1.1 is more strict regarding the CA bit, the building of the "chain" will fail because a self-signed cert MUST have CA:TRUE. The incorrect behavior I think I'm seeing is when configuring a self-signed ECDSA certificate. I'll paste the certificate below, but I would think this version 1 certificate that does NOT have CA:TRUE would error in the same was the similar RSA certificate did above. Does anyone know what could be the result of the (seemingly) different behavior? Are there any other tests I could try to lead me to an answer? Thanks, Jason TEST:/etc/ssl # openssl x509 -text -noout -in certs/ecdsacert.pem Certificate: Data: Version: 1 (0x0) Serial Number: de:6e:db:59:3a:03:e5:ac Signature Algorithm: ecdsa-with-SHA256 Issuer: C=US, ST=State, L=City, O=Company, OU=Networking, CN=COMMON-NAME/emailAddress=john.doe at example.com Validity Not Before: Mar 17 18:23:09 2020 GMT Not After : Mar 17 18:23:09 2021 GMT Subject: C=US, ST=State, L=City, O=Company, OU=Networking, CN=COMMON-NAME/emailAddress=john.doe at example.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:dc:67:d3:f5:53:0b:c9:3c:13:e9:d9:52:17:60: fb:a2:f6:ad:98:74:a4:1b:6d:57:52:81:d3:e5:8f: e9:0f:a6:32:81:8f:f6:6d:3f:f2:1c:1c:6b:a7:c6: 3a:59:a3:c8:ce:12:08:ee:5c:8c:3e:4f:52:cb:35: dc:6b:1a:de:59 ASN1 OID: prime256v1 NIST CURVE: P-256 Signature Algorithm: ecdsa-with-SHA256 30:45:02:20:66:d8:35:06:98:38:0a:88:57:c4:8d:30:02:97: 3a:e7:4f:34:4a:50:d2:5c:e7:16:61:80:b3:43:41:7f:71:42: 02:21:00:82:c2:39:b5:52:d4:e9:aa:21:d5:d1:fb:e8:01:e2: aa:81:16:75:cb:0d:2c:33:f6:34:5b:54:80:ac:82:66:4f ________________________________ From: openssl-users on behalf of Viktor Dukhovni Sent: Friday, May 31, 2019 9:44 PM To: openssl-users at openssl.org Subject: Re: OpenSSL server sending certificate chain(inc. root cert) during handshake > On May 31, 2019, at 3:20 PM, Jason Schultz wrote: > > My questions deal with #2: Why does OpenSSL include the root cert in the certificate chain? The OpenSSL SSL_CTX_build_cert_chain(3) function constructs a complete chain of trust for your certificate chain, based on the configured trust stores (CAfile and/or CApath). If you call this function, then you can control how your certificates chain is augmented. But if your EE certificate is the entire chain, then the internal automatic chain construction code will assume that the chain was not built, and will try to augment it unless you set the SSL_MODE_NO_AUTO_CHAIN flag via: SSL_CTX_set_mode(3), or SSL_set_mode(3) [ Which really ought to also document SSL_MODE_NO_AUTO_CHAIN ] > Will the root cert be included in the chain any time it's in the same directory > as the server cert? No, the chain is augmented based on the configured trust stores, and does not directly consider the directory holding the chain file. > Is there a way, via API call, configuration, etc, to force OpenSSL to NOT send the > root certificate as part of the chain in this case? You can set a CAfile/CApath that do not include the location of the root cert, or disable automatic chain construction, and build the chain just the way you like it via SSL_CTX_build_cert_chain(3), possibly passing the SSL_BUILD_CHAIN_FLAG_NO_ROOT flag. -- Viktor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Mar 20 21:12:08 2020 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 20 Mar 2020 21:12:08 +0000 Subject: 1.OU or OU.1 ? Message-ID: The doc/man5/config.pod file says to use 1.OU = ?My first OU? 2.OU = ?My second OU? But doc/man5/x509v3_config.pod says to append the numeric, as in email.1 = steve at here email.2 = steve at there I believe the second form is correct. Can anyone confirm? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirkx at webweaving.org Fri Mar 20 21:26:13 2020 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Fri, 20 Mar 2020 22:26:13 +0100 Subject: 1.OU or OU.1 ? In-Reply-To: References: Message-ID: <240C2D6E-90C9-4450-90DB-425E1E31F611@webweaving.org> > On 20 Mar 2020, at 22:12, Salz, Rich via openssl-users wrote: > > The doc/man5/config.pod file says to use > 1.OU = ?My first OU? > 2.OU = ?My second OU? > > But doc/man5/x509v3_config.pod says to append the numeric, as in > email.1 = steve at here > email.2 = steve at there > > I believe the second form is correct. Can anyone confirm? AFAIK: Either simply like (e.g. in an extension file): subjectAltName=email:foo at x,email:bar at x or more listed like your second form: [ v3_req ] subjectAltName = @extrabits [ extrabits ] email.1=foo email.2=foo or straight (ordered) directly: openssl req -x509 -subj /CN=foo/CN=bar -keyout /dev/null -nodes| openssl x509 -noout -subject Dw. From levitte at openssl.org Sat Mar 21 02:44:52 2020 From: levitte at openssl.org (Richard Levitte) Date: Sat, 21 Mar 2020 03:44:52 +0100 Subject: 1.OU or OU.1 ? In-Reply-To: References: Message-ID: <87wo7ea0kb.wl-levitte@openssl.org> The correct answer is, it depends. This is an unfortunate evolutionary artefact, and is governed by very different pieces of code. The config.pod example revolves around subject names and the config for 'openssl req'. The code that uses this is the function auto_info(), found in apps/req.c. The x509v3_config.pod example revolves around X.509 v3 extensions, and the config for those is used by diverse functions in crypto/x509v3/ (1.1.1) or crypto/x509/ (masterand upcoming 3.0), and ultimately, the key name comparison is done by name_cmp(), found in v3_utl.c. So both manuals are correct. Unfortunately... Cheers, Richard On Fri, 20 Mar 2020 22:12:08 +0100, Salz, Rich via openssl-users wrote: > > > The doc/man5/config.pod file says to use > > 1.OU = ?My first OU? > > 2.OU = ?My second OU? > > But doc/man5/x509v3_config.pod says to append the numeric, as in > > email.1 = steve at here > > email.2 = steve at there > > I believe the second form is correct. Can anyone confirm? > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Sat Mar 21 13:46:56 2020 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 21 Mar 2020 13:46:56 +0000 Subject: 1.OU or OU.1 ? In-Reply-To: <87wo7ea0kb.wl-levitte@openssl.org> References: <87wo7ea0kb.wl-levitte@openssl.org> Message-ID: <24C17691-D986-4C9C-A213-0326ED5AE4B6@akamai.com> Argh. Thanks for the detailed explanation. It seems to me that if I add suffixes ".nnn" support to auto_info() than we can move xxx.field to deprecated at some point? ?On 3/20/20, 10:45 PM, "Richard Levitte" wrote: The correct answer is, it depends. This is an unfortunate evolutionary artefact, and is governed by very different pieces of code. The config.pod example revolves around subject names and the config for 'openssl req'. The code that uses this is the function auto_info(), found in apps/req.c. The x509v3_config.pod example revolves around X.509 v3 extensions, and the config for those is used by diverse functions in crypto/x509v3/ (1.1.1) or crypto/x509/ (masterand upcoming 3.0), and ultimately, the key name comparison is done by name_cmp(), found in v3_utl.c. So both manuals are correct. Unfortunately... Cheers, Richard On Fri, 20 Mar 2020 22:12:08 +0100, Salz, Rich via openssl-users wrote: > > > The doc/man5/config.pod file says to use > > 1.OU = ?My first OU? > > 2.OU = ?My second OU? > > But doc/man5/x509v3_config.pod says to append the numeric, as in > > email.1 = steve at here > > email.2 = steve at there > > I believe the second form is correct. Can anyone confirm? > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From angus at magsys.co.uk Mon Mar 23 11:10:00 2020 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Mon, 23 Mar 2020 11:10 +0000 (GMT Standard Time) Subject: Handshake failure: TLSv1.3 early data? Message-ID: My public web servers shows several handshake failures daily due to 'TLSv1.3 early data', sometimes after a previous successful TLSv1.3 connection, but not always. I'm not currently attempting to handle any early data, I thought it was disabled by default. Is there something I should be doing like using SSL_CTX_set_allow_early_data_cb() to reject the early data? Or setting SSL_CTX_set_recv_max_early_data() to zero? Maybe these errors are the result of bad client implementations and I should just ignore them. Like all public servers, there are thousands of hacking attempts daily, and other silly accesses, like why would anyone want to negotiate protocol 0x0103 while also sending the EC Group extension? Angus From iliya.yurkevic at mail.ru Mon Mar 23 11:21:29 2020 From: iliya.yurkevic at mail.ru (ReadEye) Date: Mon, 23 Mar 2020 04:21:29 -0700 (MST) Subject: Stream filter for CMS_Sign() Message-ID: <1584962489152-0.post@n7.nabble.com> Hey! I want to use stream filter witn CMS_sign. I have a problem: my program doesn't produce cms signed data. Attaching my code and output data below. The code that follows is a fragment from my original program. void SignInit(CryptPacket &packet) //use once for initialization { if (m_cms) return; CK_ULONG certCount = NULL; std::vectorcertHandles; std::vector certValue; X509* x509Cert = nullptr; CK_SESSION_HANDLE session = NULL; CK_BYTE* p_CKA_ID; EVP_PKEY* key = NULL; try { m_pCryptoModule->Authentication(session, true); Rtk_CertInfo2* p_rtk_certinfo2_object = m_pCryptoModule->m_CertsCollection.GetCert(packet.request.senderCertId); if (!p_rtk_certinfo2_object) ca_throw_cert_need_log(packet.request.senderCertId); std::vector ckId = p_rtk_certinfo2_object->m_ckId; p_CKA_ID = new CK_BYTE[ckId.size()]; std::copy(ckId.begin(), ckId.end(), p_CKA_ID); CK_ATTRIBUTE certificateTemplate[] = CERTIFICATE_TEMPLATE(ckId, p_CKA_ID); key = GetKeyPair(ckId, session, m_pCryptoModule->m_functionList); if (!key) { ca_throw_log(RTK_E_FIND_KEY_FAILED); } if (m_pCryptoModule->m_functionList->C_FindObjectsInit(session, certificateTemplate, arraysize(certificateTemplate)) != CKR_OK) { ca_throw_log(RTK_E_FIND_OBJECTS_INIT_FAILED); } certHandles.clear(); certHandles.resize(10000); if (m_pCryptoModule->m_functionList->C_FindObjects(session, certHandles.data(), (CK_ULONG)certHandles.size(), &certCount) != CKR_OK || certCount == 0) { ca_throw_log(RTK_E_FIND_OBJECTS_FAILED); } CK_ATTRIBUTE certValueAttr = { CKA_VALUE, NULL_PTR, 0 }; if (m_pCryptoModule->m_functionList->C_GetAttributeValue(session, certHandles[0], &certValueAttr, 1) != CKR_OK) ca_throw_log(RTK_E_GET_CKA_VALUE_FAILED); certValue.resize(certValueAttr.ulValueLen); certValueAttr.pValue = certValue.data(); if (m_pCryptoModule->m_functionList->C_GetAttributeValue(session, certHandles[0], &certValueAttr, 1) != CKR_OK) ca_throw_log(RTK_E_GET_CKA_VALUE_FAILED); x509Cert = CertToX509(CertToPem(certValue)); if (!x509Cert) { ca_throw_log(RTK_E_CERT_TO_X509_FAILED); } if (m_pCryptoModule->m_functionList->C_FindObjectsFinal(session) != CKR_OK) { ca_throw_log(RTK_E_FIND_OBJECTS_FINAL_FAILED); } m_cms = CMS_sign(x509Cert, key, NULL, NULL, CMS_STREAM | CMS_BINARY); if (!m_cms) { ca_throw_log(RTK_E_ENCRYPT_FAILED); } m_input = BIO_new_CMS(m_output, m_cms); m_pCryptoModule->EndSession(session, true); X509_free(x509Cert); if (!rt_eng_invalidate_p11_ossl_evp_pkey(key)) { ca_throw_log(RTK_E_RESET_KEY_PAIR_DESCRIPTOR_FAILED); } EVP_PKEY_free(key); delete[] p_CKA_ID; } ca_catch { if (x509Cert) X509_free(x509Cert); if (key) { if (!rt_eng_invalidate_p11_ossl_evp_pkey(key)) ca_log_err(RTK_E_RESET_KEY_PAIR_DESCRIPTOR_FAILED); EVP_PKEY_free(key); } delete[] p_CKA_ID; m_pCryptoModule->EndSession(session, true); packet.response.errorCode = ex; packet.response.errorMessage = GetErrorMessage(ex); } } void Stream(CryptPacket & packet)//for multiple calls { ca_lock; try { SignInit(packet); BYTE* pbData = packet.request.GetFileData(); DWORD cbData = packet.request.GetFileDataSize(); if (BIO_write(m_input, pbData, cbData) <= 0) ca_throw_log(RTK_E_WRITE_TO_OUT_BUF_FAILED); if (packet.request.streamFinalChunk)//finalization BIO_flush(m_input); std::vector cmsBuf = ReadMemBio(m_output); if (!cmsBuf.size()) ca_throw_log(RTK_E_READ_FROM_BUF_FAILED); packet.response.SetFileData(cmsBuf.data(), cmsBuf.size());//write data to file } ca_catch { packet.response.errorCode = ex; packet.response.errorMessage = GetErrorMessage(ex); } } Data written in the file as a result: Data as input for Signing: Am I missing something? Is there another way I can achieve the same thing? Thanks for attention -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From matt at openssl.org Mon Mar 23 11:25:57 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 23 Mar 2020 11:25:57 +0000 Subject: Handshake failure: TLSv1.3 early data? In-Reply-To: References: Message-ID: <3aed90f0-b012-c22f-26c1-0f32446481d9@openssl.org> On 23/03/2020 11:09, Angus Robertson - Magenta Systems Ltd wrote: > My public web servers shows several handshake failures daily due to > 'TLSv1.3 early data', sometimes after a previous successful TLSv1.3 > connection, but not always. Do you have specific error messages? > > I'm not currently attempting to handle any early data, I thought it was > disabled by default. It is. You don't need to do anything to disable early data. > Maybe these errors are the result of bad client implementations and I > should just ignore them. Possibly - but it would be good to see error messages. Matt > > Like all public servers, there are thousands of hacking attempts daily, > and other silly accesses, like why would anyone want to negotiate > protocol 0x0103 while also sending the EC Group extension? > > Angus > From angus at magsys.co.uk Mon Mar 23 12:07:00 2020 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Mon, 23 Mar 2020 12:07 +0000 (GMT Standard Time) Subject: Handshake failure: TLSv1.3 early data? In-Reply-To: <3aed90f0-b012-c22f-26c1-0f32446481d9@openssl.org> Message-ID: > > My public web servers shows several handshake failures daily > > due to 'TLSv1.3 early data', sometimes after a previous > > successful TLSv1.3 connection, but not always. > > Do you have specific error messages? I seem to only report the state rather than an error once the socket is closed, take a few hours to get some more failures with real errors. Angus From matt at openssl.org Mon Mar 23 12:18:46 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 23 Mar 2020 12:18:46 +0000 Subject: Handshake failure: TLSv1.3 early data? In-Reply-To: References: Message-ID: On 23/03/2020 12:06, Angus Robertson - Magenta Systems Ltd wrote: >>> My public web servers shows several handshake failures daily >>> due to 'TLSv1.3 early data', sometimes after a previous >>> successful TLSv1.3 connection, but not always. >> >> Do you have specific error messages? > > I seem to only report the state rather than an error once the socket is > closed, take a few hours to get some more failures with real errors. The state machine can (briefly) transition through the early data state even though early data is not being accepted, i.e. its there long enough to say "nothing to do here". So one explanation is that you're in that state when you hit the error - even though its nothing to do with early data itself. Matt From jetson23 at hotmail.com Mon Mar 23 12:38:33 2020 From: jetson23 at hotmail.com (Jason Schultz) Date: Mon, 23 Mar 2020 12:38:33 +0000 Subject: SSL_CTX_build_cert_chain() and SSL_CTX_set_mode() In-Reply-To: References: , <62B54780-8757-42BB-8C85-559C0A2DE174@dukhovni.org>, Message-ID: Changing the subject to be more relevant to my questions. Just wanted to ping the list again. ________________________________ From: openssl-users on behalf of Jason Schultz Sent: Friday, March 20, 2020 3:21 PM To: openssl-users at openssl.org Subject: Re: OpenSSL server sending certificate chain(inc. root cert) during handshake I apologize for bringing this old subject back up, but I'm running into something I wanted to poll the list on. Based on Victor's email below, I am doing the following in my application to set up my server to send a certificate chain *excluding* the root certificate during a handshake. status = SSL_CTX_set_mode(ctx, SSL_MODE_NO_AUTO_CHAIN); status = SSL_CTX_build_cert_chain(ctx, SSL_BUILD_CHAIN_FLAG_NO_ROOT); When I configure a certificate chain, the server sends the chain, excluding the root. The call to SSL_CTX_build_cert_chain() accomplishes this, with the "no root" flag. This works as expected. The interesting part comes in when I am configuring a self-signed certificate as the server cert. ** NOTE **: I know this isn't recommended, this is ONLY for test purposes, and our users will configure servers in this way, also ONLY for test purposes. This is why I'm testing the operation of this configuration. As Victor indicated, my EE certificate is also the entire chain; of 1 self-signed certificate. Setting the SSL_MODE_AUTO_CHAIN flag allowed me to configure a self-signed certificate on the server, the two calls above succeed, and my server sends that single, self-signed cert in the handshake. This is true for version 3 self-signed certificates, with the CA bit set. If I have a version 1 *RSA* certificate, with the CA bit NOT set(so CA:FALSE), the call to SSL_CTX_build_cert_chain() errors. I think this is the expected behavior. Does everyone agree with that? Since OpenSSL 1.1.1 is more strict regarding the CA bit, the building of the "chain" will fail because a self-signed cert MUST have CA:TRUE. The incorrect behavior I think I'm seeing is when configuring a self-signed ECDSA certificate. I'll paste the certificate below, but I would think this version 1 certificate that does NOT have CA:TRUE would error in the same was the similar RSA certificate did above. Does anyone know what could be the result of the (seemingly) different behavior? Are there any other tests I could try to lead me to an answer? Thanks, Jason TEST:/etc/ssl # openssl x509 -text -noout -in certs/ecdsacert.pem Certificate: Data: Version: 1 (0x0) Serial Number: de:6e:db:59:3a:03:e5:ac Signature Algorithm: ecdsa-with-SHA256 Issuer: C=US, ST=State, L=City, O=Company, OU=Networking, CN=COMMON-NAME/emailAddress=john.doe at example.com Validity Not Before: Mar 17 18:23:09 2020 GMT Not After : Mar 17 18:23:09 2021 GMT Subject: C=US, ST=State, L=City, O=Company, OU=Networking, CN=COMMON-NAME/emailAddress=john.doe at example.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:dc:67:d3:f5:53:0b:c9:3c:13:e9:d9:52:17:60: fb:a2:f6:ad:98:74:a4:1b:6d:57:52:81:d3:e5:8f: e9:0f:a6:32:81:8f:f6:6d:3f:f2:1c:1c:6b:a7:c6: 3a:59:a3:c8:ce:12:08:ee:5c:8c:3e:4f:52:cb:35: dc:6b:1a:de:59 ASN1 OID: prime256v1 NIST CURVE: P-256 Signature Algorithm: ecdsa-with-SHA256 30:45:02:20:66:d8:35:06:98:38:0a:88:57:c4:8d:30:02:97: 3a:e7:4f:34:4a:50:d2:5c:e7:16:61:80:b3:43:41:7f:71:42: 02:21:00:82:c2:39:b5:52:d4:e9:aa:21:d5:d1:fb:e8:01:e2: aa:81:16:75:cb:0d:2c:33:f6:34:5b:54:80:ac:82:66:4f ________________________________ From: openssl-users on behalf of Viktor Dukhovni Sent: Friday, May 31, 2019 9:44 PM To: openssl-users at openssl.org Subject: Re: OpenSSL server sending certificate chain(inc. root cert) during handshake > On May 31, 2019, at 3:20 PM, Jason Schultz wrote: > > My questions deal with #2: Why does OpenSSL include the root cert in the certificate chain? The OpenSSL SSL_CTX_build_cert_chain(3) function constructs a complete chain of trust for your certificate chain, based on the configured trust stores (CAfile and/or CApath). If you call this function, then you can control how your certificates chain is augmented. But if your EE certificate is the entire chain, then the internal automatic chain construction code will assume that the chain was not built, and will try to augment it unless you set the SSL_MODE_NO_AUTO_CHAIN flag via: SSL_CTX_set_mode(3), or SSL_set_mode(3) [ Which really ought to also document SSL_MODE_NO_AUTO_CHAIN ] > Will the root cert be included in the chain any time it's in the same directory > as the server cert? No, the chain is augmented based on the configured trust stores, and does not directly consider the directory holding the chain file. > Is there a way, via API call, configuration, etc, to force OpenSSL to NOT send the > root certificate as part of the chain in this case? You can set a CAfile/CApath that do not include the location of the root cert, or disable automatic chain construction, and build the chain just the way you like it via SSL_CTX_build_cert_chain(3), possibly passing the SSL_BUILD_CHAIN_FLAG_NO_ROOT flag. -- Viktor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Mar 23 17:53:32 2020 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 23 Mar 2020 17:53:32 +0000 Subject: Handshake failure: TLSv1.3 early data? In-Reply-To: <3aed90f0-b012-c22f-26c1-0f32446481d9@openssl.org> References: <3aed90f0-b012-c22f-26c1-0f32446481d9@openssl.org> Message-ID: <795C25E2-863A-41D0-A5C7-6927CDCFC124@akamai.com> Is it possible the browsers are trying to send early data? From angus at magsys.co.uk Mon Mar 23 19:42:00 2020 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Mon, 23 Mar 2020 19:42 +0000 (GMT Standard Time) Subject: Handshake failure: TLSv1.3 early data? In-Reply-To: <795C25E2-863A-41D0-A5C7-6927CDCFC124@akamai.com> Message-ID: > Is it possible the browsers are trying to send early data? I doubt it, I was not reporting the error, trying to report errors before they disappear with clean-up code is an art, and does not always work, so mostly I now see: error:00000000:lib(0):func(0):reason(0), State: TLSv1.3 early data, connection closed unexpectedly but sometimes error:140E0197:SSL routines:SSL_shutdown:shutdown while in init, State: SSL negotiation finished successfully But only four failures are logged on the live server so far, there will be more handshake failures overnight that might be more helpful. Suspect the real issue is simply the client abandoning the connection, and different places leave different errors. Some failures are obvious like TLSv1 which is disabled on the server. But I was worried our TLSv1.3 implementation was missing something important. Read a lot about early data, but not really why anyone uses it in practice, if it is used. Quite content to continue to ignore early data. Angus From jgh at wizmail.org Mon Mar 23 23:46:43 2020 From: jgh at wizmail.org (Jeremy Harris) Date: Mon, 23 Mar 2020 23:46:43 +0000 Subject: resumption problem In-Reply-To: <2de5766b-9195-895c-a7dc-6ee432b3cd1b@wizmail.org> References: <2de5766b-9195-895c-a7dc-6ee432b3cd1b@wizmail.org> Message-ID: OpenSSL 1.1.1 on Centos 8 Ticket-based resumption I'm getting a repeatable error from a client call to SSL_connect() of "14228044:SSL routines:construct_ca_names:internal error". Packet capture shows an Alert being sent by the client before anything is received from the server. The error only occurs when the client is trying to resume a previous session, and (here's the odd part) only when the client is set up to offer a client certificate. [I can change the client config to stop it offering this client-cert, and the resumption works just fine] I *think* possibly also the precise nature of that client cert matters; a testcase I set up away from my production system failed to induce the error. The client cert is loaded using SSL_CTX_use_certificate_chain_file(); the file contains a private-key and a 3-element chain with a Lets Encrypt cert (leaf, signer, CA-root). The CA is sha1/rsa, the other two are sha256/rsa. The preceding TLS session is logged as using "TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256" Any ideas? -- Thanks, Jeremy From bkaduk at akamai.com Tue Mar 24 00:27:55 2020 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 23 Mar 2020 17:27:55 -0700 Subject: resumption problem In-Reply-To: References: <2de5766b-9195-895c-a7dc-6ee432b3cd1b@wizmail.org> Message-ID: <20200324002755.GF7971@akamai.com> On Mon, Mar 23, 2020 at 11:46:43PM +0000, Jeremy Harris wrote: > OpenSSL 1.1.1 on Centos 8 > Ticket-based resumption > > > I'm getting a repeatable error from a client call to SSL_connect() > of "14228044:SSL routines:construct_ca_names:internal error". > > Packet capture shows an Alert being sent by the client before > anything is received from the server. > > The error only occurs when the client is trying to resume > a previous session, and (here's the odd part) only when > the client is set up to offer a client certificate. > > [I can change the client config to stop it offering this > client-cert, and the resumption works just fine] > > > I *think* possibly also the precise nature of that client cert > matters; a testcase I set up away from my production > system failed to induce the error. The client cert > is loaded using SSL_CTX_use_certificate_chain_file(); > the file contains a private-key and a 3-element chain > with a Lets Encrypt cert (leaf, signer, CA-root). > The CA is sha1/rsa, the other two are sha256/rsa. Try omitting the (sha1) CA from the file? -Ben From openssl-users at dukhovni.org Tue Mar 24 00:49:01 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 23 Mar 2020 20:49:01 -0400 Subject: resumption problem In-Reply-To: References: <2de5766b-9195-895c-a7dc-6ee432b3cd1b@wizmail.org> Message-ID: <20200324004901.GB68408@straasha.imrryr.org> On Mon, Mar 23, 2020 at 11:46:43PM +0000, Jeremy Harris wrote: > OpenSSL 1.1.1 on Centos 8 > Ticket-based resumption I'm testing posttls-finger with OpenSSL 1.1.1 on FreeBSD. > > I'm getting a repeatable error from a client call to SSL_connect() > of "14228044:SSL routines:construct_ca_names:internal error". Either issues allocating space, or an explicit NULL element on the client CA list, or a DN that for some reason can't be serialized. Is there an issuer with an subject DN? > The error only occurs when the client is trying to resume > a previous session, and (here's the odd part) only when > the client is set up to offer a client certificate. My test with "posttls-finger" does not exhibit this issue: Verified TLS connection established to [...] TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 Reconnecting after 2 seconds looking for session [...] in memory cache reloaded session [...] from memory cache [...] Reusing old session Verified TLS connection established to [...] TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) > Any ideas? The entire function body is below. There are three places where that error could be raised: int construct_ca_names(SSL *s, const STACK_OF(X509_NAME) *ca_sk, WPACKET *pkt) { /* Start sub-packet for client CA list */ if (!WPACKET_start_sub_packet_u16(pkt)) { --> SSLfatal(s, SSL_AD_INTERNAL_ERROR, SSL_F_CONSTRUCT_CA_NAMES, ERR_R_INTERNAL_ERROR); return 0; } if (ca_sk != NULL) { int i; for (i = 0; i < sk_X509_NAME_num(ca_sk); i++) { unsigned char *namebytes; X509_NAME *name = sk_X509_NAME_value(ca_sk, i); int namelen; if (name == NULL || (namelen = i2d_X509_NAME(name, NULL)) < 0 || !WPACKET_sub_allocate_bytes_u16(pkt, namelen, &namebytes) || i2d_X509_NAME(name, &namebytes) != namelen) { --> SSLfatal(s, SSL_AD_INTERNAL_ERROR, SSL_F_CONSTRUCT_CA_NAMES, ERR_R_INTERNAL_ERROR); return 0; } } } if (!WPACKET_close(pkt)) { --> SSLfatal(s, SSL_AD_INTERNAL_ERROR, SSL_F_CONSTRUCT_CA_NAMES, ERR_R_INTERNAL_ERROR); return 0; } return 1; } I'm guessing it is not the first. The second would an issue with a particular issuer on the CA list (does Exim configure a list of CAs to send to the server?), or the list of CAs is too long to fit in 2^16 bytes, which might fail on the packet close if not while extending the subpacket. It'd be useful to single-step through that function with gdb and what happened. How long is the CA list? Which condition caused the error? -- Viktor. From openssl-users at dukhovni.org Tue Mar 24 00:50:28 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 23 Mar 2020 20:50:28 -0400 Subject: resumption problem In-Reply-To: <20200324002755.GF7971@akamai.com> References: <2de5766b-9195-895c-a7dc-6ee432b3cd1b@wizmail.org> <20200324002755.GF7971@akamai.com> Message-ID: <20200324005028.GC68408@straasha.imrryr.org> On Mon, Mar 23, 2020 at 05:27:55PM -0700, Benjamin Kaduk via openssl-users wrote: > > I *think* possibly also the precise nature of that client cert > > matters; a testcase I set up away from my production > > system failed to induce the error. The client cert > > is loaded using SSL_CTX_use_certificate_chain_file(); > > the file contains a private-key and a 3-element chain > > with a Lets Encrypt cert (leaf, signer, CA-root). > > The CA is sha1/rsa, the other two are sha256/rsa. > > Try omitting the (sha1) CA from the file? That's not plausibly related to a failure to construct the list of CA distinguished names. The signatures are not looked at by the function reporting the error. -- Viktor. From hamedsalini6 at gmail.com Tue Mar 24 02:42:48 2020 From: hamedsalini6 at gmail.com (hamed salini) Date: Tue, 24 Mar 2020 07:12:48 +0430 Subject: resumption problem In-Reply-To: <20200324005028.GC68408@straasha.imrryr.org> References: <2de5766b-9195-895c-a7dc-6ee432b3cd1b@wizmail.org> <20200324002755.GF7971@akamai.com> <20200324005028.GC68408@straasha.imrryr.org> Message-ID: ?? ????? ??????? ?? ???? ?????? ?:?? Viktor Dukhovni < openssl-users at dukhovni.org> ????: > On Mon, Mar 23, 2020 at 05:27:55PM -0700, Benjamin Kaduk via openssl-users > wrote: > > > > I *think* possibly also the precise nature of that client cert > > > matters; a testcase I set up away from my production > > > system failed to induce the error. The client cert > > > is loaded using SSL_CTX_use_certificate_chain_file(); > > > the file contains a private-key and a 3-element chain > > > with a Lets Encrypt cert (leaf, signer, CA-root). > > > The CA is sha1/rsa, the other two are sha256/rsa. > > > > Try omitting the (sha1) CA from the file? > > That's not plausibly related to a failure to construct > the list of CA distinguished names. The signatures > are not looked at by the function reporting the error. > > -- > Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpb5bnc at gmail.com Tue Mar 24 14:06:23 2020 From: rpb5bnc at gmail.com (Pete) Date: Tue, 24 Mar 2020 10:06:23 -0400 Subject: 3.0 FIPS related questions Message-ID: Hello, I have two questions regarding support for FIPS in 3.0.? We're currently working on early planning for our migration to OpenSSL 3.0 and we're trying to size the effort for our team.? We're also beginning to put together contingency plans in the event that dates on either side change dramatically.? I suspect I already know the answers to these questions, but I wanted to ask just to be sure so that we plan correctly. Over the years we have had requirements to include additional functionality within our FIPS boundary beyond what was in the OpenSSL based FOM.? We would start with the existing OpenSSL FOM, add in the additional functionality, and then go through a full validation with the test lab on this slightly modified FOM.? We had the impression that there are other groups that do the same.? An example of additional functionality, especially for the 3.0 FOM, might be something like the SSH KDF.? If this KDF were to not be included in the 3.0 FOM and we needed a FIPS validated version of it in our solutions, we would need to move this into the FIPS provider and then take this altered FOM through a complete FIPS validation.? If however, we were to create a 3rd party provider that only contains this supplemental FIPS functionality, we could go through an abbreviated FIPS validation of just that functionality and then have both the OpenSSL 3.0 FOM and this supplemental FOM active at the same time in our solution.? So the question is, will the OpenSSL 3.0 design allow for more than one active FIPS provider? I've made a pass through the 3.0 design specification looking specifically at FIPS provider related content but did not see an explicit statement that there can only be one FIPS provider, although, I suspect this is the case and wanted to confirm this.? If it's at all possible to have two active FIPS provider, it could make subsequent FIPS validations simpler.? On the other hand, am I completely missing some fundamental aspect of FIPS provider functionality in 3.0 and this need to add additional support into the FOM will not be as involved as it used to be? The second question is somewhat related.? Has there been a decision yet whether the FOM 3.0 will go through a 140-2 or a 140-3 validation? Thanks, Pete From matt at openssl.org Tue Mar 24 14:19:19 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 24 Mar 2020 14:19:19 +0000 Subject: 3.0 FIPS related questions In-Reply-To: References: Message-ID: <702d24bc-e0ec-251a-cf17-4532d665aa6c@openssl.org> On 24/03/2020 14:06, Pete wrote: > Hello, > > I have two questions regarding support for FIPS in 3.0.? We're currently working on early planning for our migration to OpenSSL 3.0 and we're > trying to size the effort for our team.? We're also beginning to put together contingency plans in the event that dates on either side change > dramatically.? I suspect I already know the answers to these questions, but I wanted to ask just to be sure so that we plan correctly. > > Over the years we have had requirements to include additional functionality within our FIPS boundary beyond what was in the OpenSSL > based FOM.? We would start with the existing OpenSSL FOM, add in the additional functionality, and then go through a full validation with the > test lab on this slightly modified FOM.? We had the impression that there are other groups that do the same.? An example of additional > functionality, especially for the 3.0 FOM, might be something like the SSH KDF.? If this KDF were to not be included in the 3.0 FOM and we > needed a FIPS validated version of it in our solutions, we would need to move this into the FIPS provider and then take this altered FOM through > a complete FIPS validation.? If however, we were to create a 3rd party provider that only contains this supplemental FIPS functionality, we > could go through an abbreviated FIPS validation of just that functionality and then have both the OpenSSL 3.0 FOM and this > supplemental FOM active at the same time in our solution.? So the question is, will the OpenSSL 3.0 design allow for more than one active > FIPS provider? Yes, this is possible. As far as end applications are concerned FIPS validated algorithms must be "fetched". Applications can either do this explicitly or implicitly. If done explicitly then you must specify the name of the algorithm you wish to use, and a property query string. If done implicitly then the same thing happens inside libcrypto. The name of the algorithm is inferred, and a default property query string is used (which can be set through a config file). All algorithms that exist within the FIPS provider use the property string "fips=yes". So if you only want to use FIPS validated algorithms then you just set that query string to be the default - or specify that query string explicitly if doing explicit fetching. There is nothing to stop you from having a second FIPS provider loaded with different algorithms in it. As long as you specify all the algorithms in that provider to have "fips=yes" against them, then it will appear the same as any other FIPS validated algorithm to an end application. Another way end applications can arrange things is to forget about property strings and only ever have the FIPS provider(s) loaded (ie. do not load the default provider). This means all algorithms will come from the FIPS providers. Again there is nothing to stop you from having multiple of these. > > I've made a pass through the 3.0 design specification looking specifically at FIPS provider related content but did not see an > explicit statement that there can only be one FIPS provider, although, I suspect this is the case and wanted to confirm this.? If it's at all > possible to have two active FIPS provider, it could make subsequent FIPS validations simpler.? On the other hand, am I completely missing some > fundamental aspect of FIPS provider functionality in 3.0 and this need to add additional support into the FOM will not be as involved as it > used to be? > > The second question is somewhat related.? Has there been a decision yet whether the FOM 3.0 will go through a 140-2 or a 140-3 validation? We are going through 140-2. Matt From rpb5bnc at gmail.com Tue Mar 24 14:28:15 2020 From: rpb5bnc at gmail.com (Pete) Date: Tue, 24 Mar 2020 10:28:15 -0400 Subject: 3.0 FIPS related questions In-Reply-To: <702d24bc-e0ec-251a-cf17-4532d665aa6c@openssl.org> References: <702d24bc-e0ec-251a-cf17-4532d665aa6c@openssl.org> Message-ID: <7b51a84e-1045-a300-f1bd-e0fbcf18f508@gmail.com> Hi Matt, Thanks so much for the quick and thorough response.? I had caught bits and pieces of the algorithm selection process while going through the design doc but apparently didn't catch just how flexible it really is.? As for the 140 level of testing, that's just what we expected. Thanks again, Pete On 3/24/20 10:19 AM, Matt Caswell wrote: > > On 24/03/2020 14:06, Pete wrote: >> Hello, >> >> I have two questions regarding support for FIPS in 3.0.? We're currently working on early planning for our migration to OpenSSL 3.0 and we're >> trying to size the effort for our team.? We're also beginning to put together contingency plans in the event that dates on either side change >> dramatically.? I suspect I already know the answers to these questions, but I wanted to ask just to be sure so that we plan correctly. >> >> Over the years we have had requirements to include additional functionality within our FIPS boundary beyond what was in the OpenSSL >> based FOM.? We would start with the existing OpenSSL FOM, add in the additional functionality, and then go through a full validation with the >> test lab on this slightly modified FOM.? We had the impression that there are other groups that do the same.? An example of additional >> functionality, especially for the 3.0 FOM, might be something like the SSH KDF.? If this KDF were to not be included in the 3.0 FOM and we >> needed a FIPS validated version of it in our solutions, we would need to move this into the FIPS provider and then take this altered FOM through >> a complete FIPS validation.? If however, we were to create a 3rd party provider that only contains this supplemental FIPS functionality, we >> could go through an abbreviated FIPS validation of just that functionality and then have both the OpenSSL 3.0 FOM and this >> supplemental FOM active at the sa,me time in our solution.? So the question is, will the OpenSSL 3.0 design allow for more than one active >> FIPS provider? > Yes, this is possible. As far as end applications are concerned FIPS > validated algorithms must be "fetched". Applications can either do this > explicitly or implicitly. If done explicitly then you must specify the > name of the algorithm you wish to use, and a property query string. If > done implicitly then the same thing happens inside libcrypto. The name > of the algorithm is inferred, and a default property query string is > used (which can be set through a config file). > > All algorithms that exist within the FIPS provider use the property > string "fips=yes". So if you only want to use FIPS validated algorithms > then you just set that query string to be the default - or specify that > query string explicitly if doing explicit fetching. > > There is nothing to stop you from having a second FIPS provider loaded > with different algorithms in it. As long as you specify all the > algorithms in that provider to have "fips=yes" against them, then it > will appear the same as any other FIPS validated algorithm to an end > application. > > Another way end applications can arrange things is to forget about > property strings and only ever have the FIPS provider(s) loaded (ie. do > not load the default provider). This means all algorithms will come from > the FIPS providers. Again there is nothing to stop you from having > multiple of these. > >> I've made a pass through the 3.0 design specification looking specifically at FIPS provider related content but did not see an >> explicit statement that there can only be one FIPS provider, although, I suspect this is the case and wanted to confirm this.? If it's at all >> possible to have two active FIPS provider, it could make subsequent FIPS validations simpler.? On the other hand, am I completely missing some >> fundamental aspect of FIPS provider functionality in 3.0 and this need to add additional support into the FOM will not be as involved as it >> used to be? >> >> The second question is somewhat related.? Has there been a decision yet whether the FOM 3.0 will go through a 140-2 or a 140-3 validation? > We are going through 140-2. > > Matt > From rsalz at akamai.com Tue Mar 24 15:02:08 2020 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 24 Mar 2020 15:02:08 +0000 Subject: 3.0 FIPS related questions In-Reply-To: <702d24bc-e0ec-251a-cf17-4532d665aa6c@openssl.org> References: <702d24bc-e0ec-251a-cf17-4532d665aa6c@openssl.org> Message-ID: <47235F2C-5B51-4CC8-894B-179317847246@akamai.com> > > The second question is somewhat related. Has there been a decision yet whether the FOM 3.0 will go through a 140-2 or a 140-3 validation? > We are going through 140-2. Has the list of validated platforms been made public yet? For people using a different platform, will they still be able to claim "vendor affirmed" if they follow particular build steps? From noadsplease at web.de Tue Mar 24 15:12:53 2020 From: noadsplease at web.de (Dirk Menstermann) Date: Tue, 24 Mar 2020 16:12:53 +0100 Subject: OpenSSL 111: authorityKeyIdentifier Message-ID: <4def7ea5-dc3b-7593-5611-7fa7ab9dfb2b@web.de> Hi, I?m using OpenSSL 1.1.1 to issue a certificate and include the AKI by defining authorityKeyIdentifier = keyid,issuer:always The issued certificate contains the AKI afterwards with 3 values: KeyID: issuer's key id Serial: issuer's serial Issuer: the issuer?s issuer, not the issuer?s subject! My expectation (maybe wrong) is that the serial and the issuer name belong to the same X509 certificate that the key id belongs to. The code is pretty clear: static AUTHORITY_KEYID *v2i_AUTHORITY_KEYID(X509V3_EXT_METHOD *method, X509V3_CTX *ctx, STACK_OF(CONF_VALUE) *values) { cert = ctx->issuer_cert; // Code left out if ((issuer && !ikeyid) || (issuer == 2)) { isname = X509_NAME_dup(X509_get_issuer_name(cert)); serial = ASN1_INTEGER_dup(X509_get_serialNumber(cert)); if (!isname || !serial) { X509V3err(X509V3_F_V2I_AUTHORITY_KEYID, X509V3_R_UNABLE_TO_GET_ISSUER_DETAILS); goto err; } } } Is this a bug or is my expectation wrong? Is there documented that these 3 values do not need to belong together? Thanks From angus at magsys.co.uk Tue Mar 24 15:24:00 2020 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Tue, 24 Mar 2020 15:24 +0000 (GMT Standard Time) Subject: Handshake failure: TLSv1.3 early data? In-Reply-To: Message-ID: > error:140E0197:SSL routines:SSL_shutdown:shutdown while in init, > State: SSL negotiation finished successfully And lots more similar overnight: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init, State: TLSv1.3 early data It seems some browsers open three to five sockets at the same time and then don't complete SSL negotiation on all of them, just closing them in various states. So not really negotiation failures. Angus From rsalz at akamai.com Tue Mar 24 16:03:20 2020 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 24 Mar 2020 16:03:20 +0000 Subject: Handshake failure: TLSv1.3 early data? In-Reply-To: References: Message-ID: <650456D0-2A32-4ED9-8416-17DD76C43C65@akamai.com> > It seems some browsers open three to five sockets at the same time and then don't complete SSL negotiation on all of them, just closing them in various states. Yes, this is exactly what they do. From suvendhu at gmail.com Tue Mar 24 22:17:25 2020 From: suvendhu at gmail.com (Suvendhu Hansa) Date: Tue, 24 Mar 2020 15:17:25 -0700 (MST) Subject: RAND SEED in vxworks6.9 Message-ID: <1585088245291-0.post@n7.nabble.com> Hi, I am beginner in openssl and I am porting openSSL-1.1.1d in vxWorks-6.9. So as suggested I have defined "OPENSSL_RAND_SEED_NONE" flag, as for vxWorks 'none' is only supported but after doing so I am observing "rand_pool_entropy_available()" returns 0 which further leads to failure. I came across that while NONE is set then manual seed and re-seed is must for the applications depend on random generator. I am very confused and as not having any openSSL experience I am not able to understand what needs to be done to resolve this issue. In my project many applications are using openssl APIs, So do I need to call RAND_add() in all applications where some random generation is being done? or is there anything else I can do to provide the seeds? Please help. Thanks in advance. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From Matthias.St.Pierre at ncp-e.com Tue Mar 24 22:48:57 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 24 Mar 2020 22:48:57 +0000 Subject: RAND SEED in vxworks6.9 In-Reply-To: <1585088245291-0.post@n7.nabble.com> References: <1585088245291-0.post@n7.nabble.com> Message-ID: Hi, > I am beginner in openssl and I am porting openSSL-1.1.1d in vxWorks-6.9. So > as suggested I have defined "OPENSSL_RAND_SEED_NONE" flag, as for vxWorks > 'none' is only supported but after doing so I am observing > "rand_pool_entropy_available()" returns 0 which further leads to failure. > I came across that while NONE is set then manual seed and re-seed is must > for the applications depend on random generator. Indeed, OPENSSL_RAND_SEED_NONE is the default on platforms where OpenSSL does not know how to obtain cryptographically strong randomness from a trusted entropy source. This does not mean that no such source exists, but nobody has implemented the get_entropy callback for that platform yet. > I am very confused and as not having any openSSL experience I am not able to > understand what needs to be done to resolve this issue. > > In my project many applications are using openssl APIs, So do I need to call > RAND_add() in all applications where some random generation is being done? > or is there anything else I can do to provide the seeds? Indeed, one workaround for your application would be to seed and reseed the random generator manually using RAND_bytes(), as it is explained in the `RESEEDING` section of the RAND_DRBG(7) manual page (see [1]). However, be warned that it notoriously hard to estimate the quality of a random source (a.k.a "entropy") correctly, and that a normal application developer with little knowledge of cryptography would end up with a fake sense of security because he overestimated the quality of his random seed. A better solution would be to use a trusted random source provided by the operating system or some system library and use it to implement the get_entropy callbacks for the VxWorks platform. This could even become part of the official OpenSSL distribution. (Since it's a new feature, it won't be backported to 1.1.1, but you could patch your local OpenSSL instance when the implementation is available). There was some discussion about a suitable random source for VxWorks on GitHub in issue #7946 (see [1]), but unfortunately no pull request emerged of it and the discussion has stalled some time ago. You could visit the issue's thread and try to contact Tobias Klotz (by mentioning @klotzt-draeger in the thread) to find out what the current state is. If he comes up with a pull request, I could assist with reviewing it, but I can't implement it since I don't have access to the VxWorks platform. Hope that helps, Regards, Matthias [1] https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html [2] https://github.com/openssl/openssl/issues/7946 From Matthias.St.Pierre at ncp-e.com Tue Mar 24 22:58:03 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 24 Mar 2020 22:58:03 +0000 Subject: RAND SEED in vxworks6.9 In-Reply-To: References: <1585088245291-0.post@n7.nabble.com> Message-ID: <045e409c3ca44613ba9e915287ab4a84@Ex13.ncp.local> > Indeed, one workaround for your application would be to seed and reseed > the random generator manually using RAND_bytes(), ... Correction, I meant to say ".. using RAND_add()..." > -----Original Message----- > From: openssl-users On Behalf Of Dr. Matthias St. Pierre > Sent: Tuesday, March 24, 2020 11:49 PM > To: Suvendhu Hansa ; openssl-users at openssl.org > Subject: RE: RAND SEED in vxworks6.9 > > Hi, > > > I am beginner in openssl and I am porting openSSL-1.1.1d in vxWorks-6.9. So > > as suggested I have defined "OPENSSL_RAND_SEED_NONE" flag, as for vxWorks > > 'none' is only supported but after doing so I am observing > > "rand_pool_entropy_available()" returns 0 which further leads to failure. > > I came across that while NONE is set then manual seed and re-seed is must > > for the applications depend on random generator. > > Indeed, OPENSSL_RAND_SEED_NONE is the default on platforms where OpenSSL > does not know how to obtain cryptographically strong randomness from a trusted > entropy source. This does not mean that no such source exists, but nobody has > implemented the get_entropy callback for that platform yet. > > > I am very confused and as not having any openSSL experience I am not able to > > understand what needs to be done to resolve this issue. > > > > In my project many applications are using openssl APIs, So do I need to call > > RAND_add() in all applications where some random generation is being done? > > or is there anything else I can do to provide the seeds? > > Indeed, one workaround for your application would be to seed and reseed > the random generator manually using RAND_bytes(), as it is explained in the > `RESEEDING` section of the RAND_DRBG(7) manual page (see [1]). > However, be warned that it notoriously hard to estimate the quality of a > random source (a.k.a "entropy") correctly, and that a normal application > developer with little knowledge of cryptography would end up with a fake > sense of security because he overestimated the quality of his random seed. > > A better solution would be to use a trusted random source provided by the > operating system or some system library and use it to implement the > get_entropy callbacks for the VxWorks platform. This could even become > part of the official OpenSSL distribution. (Since it's a new feature, it won't > be backported to 1.1.1, but you could patch your local OpenSSL instance > when the implementation is available). > > There was some discussion about a suitable random source for VxWorks > on GitHub in issue #7946 (see [1]), but unfortunately no pull request > emerged of it and the discussion has stalled some time ago. > > You could visit the issue's thread and try to contact Tobias Klotz > (by mentioning @klotzt-draeger in the thread) to find out what the > current state is. If he comes up with a pull request, I could assist with > reviewing it, but I can't implement it since I don't have access to the > VxWorks platform. > > Hope that helps, > > Regards, > Matthias > > > [1] https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html > [2] https://github.com/openssl/openssl/issues/7946 > From jhb at FreeBSD.org Tue Mar 24 23:35:34 2020 From: jhb at FreeBSD.org (John Baldwin) Date: Tue, 24 Mar 2020 16:35:34 -0700 Subject: New decode_errors due to EOF changes in master and 1.1.1e Message-ID: <2a53e364-e320-794d-4dae-f0e3a3d810c8@FreeBSD.org> I replied to the original commit on GH but haven't seen any responses so thought I would follow up here as well. https://github.com/openssl/openssl/pull/10907 After this PR was merged, I am now getting what look like spurious errors for a "normal" connection end. For example, if I run 'openssl s_client -msg' against an 'openssl s_server -www' instance, I now get this error at the end of the connection: .... >>> ??? [length 0005] 15 03 03 00 1a >>> TLS 1.2, Alert [length 0002], fatal decode_error 02 32 34370928640:error:14095126:SSL routines:ssl3_read_n:unexpected eof while reading:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:303: Note that unlike the description of the commit log, this is not a case of terminating the connection early via Ctrl-C. In this case, the remote end (server) has closed the connection normally after sending the requested file. The client then gets EOF when trying to read another SSL record after reading the last byte of the sent file. Is this the expected behavior? It sure gave me a head scratch as I first noticed this after rebasing a branch adding KTLS RX support for FreeBSD, and I thought it was a bug in my changes until I finally narrowed it back to this commit. It seems a bit odd for a normal close to trigger an error instead of a clean EOF back from SSL_read(). -- John Baldwin From suvendhu at gmail.com Wed Mar 25 05:31:46 2020 From: suvendhu at gmail.com (Suvendhu Hansa) Date: Tue, 24 Mar 2020 22:31:46 -0700 (MST) Subject: RAND SEED in vxworks6.9 In-Reply-To: References: <1585088245291-0.post@n7.nabble.com> Message-ID: <1585114306419-0.post@n7.nabble.com> Thanks.. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From Matthias.St.Pierre at ncp-e.com Wed Mar 25 09:14:19 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 25 Mar 2020 09:14:19 +0000 Subject: RAND SEED in vxworks6.9 In-Reply-To: <045e409c3ca44613ba9e915287ab4a84@Ex13.ncp.local> References: <1585088245291-0.post@n7.nabble.com> <045e409c3ca44613ba9e915287ab4a84@Ex13.ncp.local> Message-ID: FYI: I restarted the discussion in #7946 https://github.com/openssl/openssl/issues/7946#issuecomment-603545804 Matthias From matt at openssl.org Wed Mar 25 09:15:05 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 25 Mar 2020 09:15:05 +0000 Subject: 3.0 FIPS related questions In-Reply-To: <47235F2C-5B51-4CC8-894B-179317847246@akamai.com> References: <702d24bc-e0ec-251a-cf17-4532d665aa6c@openssl.org> <47235F2C-5B51-4CC8-894B-179317847246@akamai.com> Message-ID: <026b8c12-cf72-5dd0-af61-1c617eed0f6c@openssl.org> On 24/03/2020 15:02, Salz, Rich wrote: > >> > The second question is somewhat related. Has there been a decision yet whether the FOM 3.0 will go through a 140-2 or a 140-3 validation? > >> We are going through 140-2. > > Has the list of validated platforms been made public yet? No, not yet. Although I don't see a great reason why they shouldn't be. I'll raise it and check everyone is happy to do so. > > For people using a different platform, will they still be able to claim "vendor affirmed" if they follow particular build steps? > Yes, we believe this will remain as per the previous module. The build process will be different, but the ability to vendor affirm other platforms should remain. Matt From matt at openssl.org Wed Mar 25 09:37:18 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 25 Mar 2020 09:37:18 +0000 Subject: New decode_errors due to EOF changes in master and 1.1.1e In-Reply-To: <2a53e364-e320-794d-4dae-f0e3a3d810c8@FreeBSD.org> References: <2a53e364-e320-794d-4dae-f0e3a3d810c8@FreeBSD.org> Message-ID: There is an ongoing discussion on this issue here: https://github.com/openssl/openssl/issues/11378 In the specific case of s_client/s_server this actually uncovered a bug in s_server, which is why you see the problem there. Matt On 24/03/2020 23:35, John Baldwin wrote: > I replied to the original commit on GH but haven't seen any responses so > thought I would follow up here as well. > > https://github.com/openssl/openssl/pull/10907 > > After this PR was merged, I am now getting what look like spurious errors > for a "normal" connection end. For example, if I run 'openssl s_client -msg' > against an 'openssl s_server -www' instance, I now get this error at the > end of the connection: > > .... > > >>>> ??? [length 0005] > 15 03 03 00 1a >>>> TLS 1.2, Alert [length 0002], fatal decode_error > 02 32 > 34370928640:error:14095126:SSL routines:ssl3_read_n:unexpected eof while reading:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:303: > > Note that unlike the description of the commit log, this is not a case of > terminating the connection early via Ctrl-C. In this case, the remote > end (server) has closed the connection normally after sending the requested > file. The client then gets EOF when trying to read another SSL record after > reading the last byte of the sent file. > > Is this the expected behavior? It sure gave me a head scratch as I first > noticed this after rebasing a branch adding KTLS RX support for FreeBSD, and I > thought it was a bug in my changes until I finally narrowed it back to this > commit. It seems a bit odd for a normal close to trigger an error instead of > a clean EOF back from SSL_read(). > From christophe1993bouchard at gmail.com Wed Mar 25 10:14:49 2020 From: christophe1993bouchard at gmail.com (Christophe Bouchard) Date: Wed, 25 Mar 2020 06:14:49 -0400 Subject: =?UTF-8?Q?Ok_but_I_try_to_connect_and_it_doesn=E2=80=99t_work_=2E=2E=2E_an?= =?UTF-8?Q?d_I_try_to_ope_ssl_and_it_mantioned_Thant_I_cant_because_of_?= =?UTF-8?Q?the_reason_7?= Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Mar 25 14:31:30 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 Mar 2020 10:31:30 -0400 Subject: OpenSSL 111: authorityKeyIdentifier In-Reply-To: <4def7ea5-dc3b-7593-5611-7fa7ab9dfb2b@web.de> References: <4def7ea5-dc3b-7593-5611-7fa7ab9dfb2b@web.de> Message-ID: <533B9CB9-6C62-4F20-B572-11A145A69ED6@dukhovni.org> > On Mar 24, 2020, at 11:12 AM, Dirk Menstermann wrote: > > My expectation (maybe wrong) is that the serial and the issuer name belong to > the same X509 certificate that the key id belongs to. Your expectation is "wrong". The issuer DN in the AKID is in fact supposed to be the issuer's issuer. It would be redundant to encode the issuer DN there, it is already present in the EE certificate. -- Viktor. From jhb at FreeBSD.org Wed Mar 25 16:03:51 2020 From: jhb at FreeBSD.org (John Baldwin) Date: Wed, 25 Mar 2020 09:03:51 -0700 Subject: New decode_errors due to EOF changes in master and 1.1.1e In-Reply-To: References: <2a53e364-e320-794d-4dae-f0e3a3d810c8@FreeBSD.org> Message-ID: <7ea81d03-46d1-5210-490d-6dad41020b44@FreeBSD.org> Thanks. I'll try searching GH issues next time (or opening a new one?) rather than replying to a commit. On 3/25/20 2:37 AM, Matt Caswell wrote: > There is an ongoing discussion on this issue here: > > https://github.com/openssl/openssl/issues/11378 > > In the specific case of s_client/s_server this actually uncovered a bug > in s_server, which is why you see the problem there. > > Matt > > On 24/03/2020 23:35, John Baldwin wrote: >> I replied to the original commit on GH but haven't seen any responses so >> thought I would follow up here as well. >> >> https://github.com/openssl/openssl/pull/10907 >> >> After this PR was merged, I am now getting what look like spurious errors >> for a "normal" connection end. For example, if I run 'openssl s_client -msg' >> against an 'openssl s_server -www' instance, I now get this error at the >> end of the connection: >> >> .... >> >> >>>>> ??? [length 0005] >> 15 03 03 00 1a >>>>> TLS 1.2, Alert [length 0002], fatal decode_error >> 02 32 >> 34370928640:error:14095126:SSL routines:ssl3_read_n:unexpected eof while reading:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:303: >> >> Note that unlike the description of the commit log, this is not a case of >> terminating the connection early via Ctrl-C. In this case, the remote >> end (server) has closed the connection normally after sending the requested >> file. The client then gets EOF when trying to read another SSL record after >> reading the last byte of the sent file. >> >> Is this the expected behavior? It sure gave me a head scratch as I first >> noticed this after rebasing a branch adding KTLS RX support for FreeBSD, and I >> thought it was a bug in my changes until I finally narrowed it back to this >> commit. It seems a bit odd for a normal close to trigger an error instead of >> a clean EOF back from SSL_read(). >> -- John Baldwin From noadsplease at web.de Wed Mar 25 16:47:01 2020 From: noadsplease at web.de (Dirk) Date: Wed, 25 Mar 2020 17:47:01 +0100 Subject: OpenSSL 111: authorityKeyIdentifier In-Reply-To: <533B9CB9-6C62-4F20-B572-11A145A69ED6@dukhovni.org> References: <533B9CB9-6C62-4F20-B572-11A145A69ED6@dukhovni.org> Message-ID: <9A08501D-D71D-4E66-A688-C1C866EB3B7A@web.de> Thank you Victor. Can you point me to the rfc that defines this? Best Am 25.03.2020 um 15:32 schrieb Viktor Dukhovni : > > ? >> >> On Mar 24, 2020, at 11:12 AM, Dirk Menstermann wrote: >> >> My expectation (maybe wrong) is that the serial and the issuer name belong to >> the same X509 certificate that the key id belongs to. > > Your expectation is "wrong". The issuer DN in the AKID is in fact > supposed to be the issuer's issuer. It would be redundant to > encode the issuer DN there, it is already present in the EE > certificate. > > -- > Viktor. > From openssl-users at dukhovni.org Wed Mar 25 17:48:57 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 Mar 2020 13:48:57 -0400 Subject: OpenSSL 111: authorityKeyIdentifier In-Reply-To: <9A08501D-D71D-4E66-A688-C1C866EB3B7A@web.de> References: <533B9CB9-6C62-4F20-B572-11A145A69ED6@dukhovni.org> <9A08501D-D71D-4E66-A688-C1C866EB3B7A@web.de> Message-ID: <20200325174857.GK68408@straasha.imrryr.org> On Wed, Mar 25, 2020 at 05:47:01PM +0100, Dirk wrote: > >> My expectation (maybe wrong) is that the serial and the issuer name belong to > >> the same X509 certificate that the key id belongs to. > > > > Your expectation is "wrong". The issuer DN in the AKID is in fact > > supposed to be the issuer's issuer. It would be redundant to > > encode the issuer DN there, it is already present in the EE > > certificate. > > Thank you Victor. Can you point me to the rfc that defines this? You could just save time and take my word for it, based on the logical argument that the issuer public key is identified by the serial number and DN of the CA that signed its certificate (the combination required to be unique) and that repeating the EE issuer DN would be redundant. The text in RFC 5280 is not terribly clear, but is basically a brief restatement of X.509. If you really want to puzzle over more text see (page 24, physical page 34 of): http://handle.itu.int/11.1002/1000/9590-en?locatt=format:pdf 8.2.2.1 Authority key identifier extension This field, which may be used as either a certificate extension or CRL extension, identifies the public key to be used to verify the signature on this certificate or CRL. It enables distinct keys used by the same CA to be distinguished (e.g., as key updating occurs). This field is defined as follows: authorityKeyIdentifier EXTENSION ::= { SYNTAX AuthorityKeyIdentifier IDENTIFIED BY id-ce-authorityKeyIdentifier } AuthorityKeyIdentifier ::= SEQUENCE { keyIdentifier [0] KeyIdentifier OPTIONAL authorityCertIssuer [1] GeneralNames OPTIONAL authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } ( WITH COMPONENTS {..., authorityCertIssuer PRESENT, authorityCertSerialNumber PRESENT} | WITH COMPONENTS {..., authorityCertIssuer ABSENT, authorityCertSerialNumber ABSENT} ) KeyIdentifier ::= OCTET STRING The key may be identified by an explicit key identifier in the keyIdentifier component, by identification of a certificate for the key (giving certificate issuer in the authorityCertIssuer component and certificate serial number in the authorityCertSerialNumber component), or by both explicit key identifier and identification of a certificate for the key. If both forms of identification are used then the certificate or CRL issuer shall ensure they are consistent. A key identifier shall be unique with respect to all key identifiers for the issuing authority for the certificate or CRL containing the extension. An implementation which supports this extension is not required to be able to process all name forms in the authorityCertIssuer component. (See 8.3.2.1 for details of the GeneralNames type.) Certification authorities shall assign certificate serial numbers such that every (issuer, certificate serial number) pair uniquely identifies a single certificate. The keyIdentifier form can be used to select CA certificates during path construction. The authorityCertIssuer, authoritySerialNumber pair can only be used to provide preference to one certificate over others during path construction. This extension is always non-critical. -- Viktor. From noadsplease at web.de Wed Mar 25 19:07:19 2020 From: noadsplease at web.de (Dirk) Date: Wed, 25 Mar 2020 20:07:19 +0100 Subject: OpenSSL 111: authorityKeyIdentifier In-Reply-To: <20200325174857.GK68408@straasha.imrryr.org> References: <20200325174857.GK68408@straasha.imrryr.org> Message-ID: Makes perfectly sense. Thank you. > Am 25.03.2020 um 18:49 schrieb Viktor Dukhovni : > > ?On Wed, Mar 25, 2020 at 05:47:01PM +0100, Dirk wrote: > >>>> My expectation (maybe wrong) is that the serial and the issuer name belong to >>>> the same X509 certificate that the key id belongs to. >>> >>> Your expectation is "wrong". The issuer DN in the AKID is in fact >>> supposed to be the issuer's issuer. It would be redundant to >>> encode the issuer DN there, it is already present in the EE >>> certificate. >> >> Thank you Victor. Can you point me to the rfc that defines this? > > You could just save time and take my word for it, based on the logical > argument that the issuer public key is identified by the serial number > and DN of the CA that signed its certificate (the combination required > to be unique) and that repeating the EE issuer DN would be redundant. > The text in RFC 5280 is not terribly clear, but is basically a brief > restatement of X.509. > > If you really want to puzzle over more text see (page 24, physical page > 34 of): > > http://handle.itu.int/11.1002/1000/9590-en?locatt=format:pdf > > 8.2.2.1 Authority key identifier extension > > This field, which may be used as either a certificate extension or > CRL extension, identifies the public key to be used to verify the > signature on this certificate or CRL. It enables distinct keys used > by the same CA to be distinguished (e.g., as key updating occurs). > This field is defined as follows: > > authorityKeyIdentifier EXTENSION ::= { > SYNTAX AuthorityKeyIdentifier IDENTIFIED BY id-ce-authorityKeyIdentifier > } > > AuthorityKeyIdentifier ::= SEQUENCE { > keyIdentifier [0] KeyIdentifier OPTIONAL > authorityCertIssuer [1] GeneralNames OPTIONAL > authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } > ( WITH COMPONENTS {..., authorityCertIssuer PRESENT, authorityCertSerialNumber PRESENT} | > WITH COMPONENTS {..., authorityCertIssuer ABSENT, authorityCertSerialNumber ABSENT} ) > > KeyIdentifier ::= OCTET STRING > > The key may be identified by an explicit key identifier in the > keyIdentifier component, by identification of a certificate for the > key (giving certificate issuer in the authorityCertIssuer component > and certificate serial number in the authorityCertSerialNumber > component), or by both explicit key identifier and identification of > a certificate for the key. If both forms of identification are used > then the certificate or CRL issuer shall ensure they are consistent. > A key identifier shall be unique with respect to all key identifiers > for the issuing authority for the certificate or CRL containing the > extension. An implementation which supports this extension is not > required to be able to process all name forms in the > authorityCertIssuer component. (See 8.3.2.1 for details of the > GeneralNames type.) > > Certification authorities shall assign certificate serial numbers > such that every (issuer, certificate serial number) pair uniquely > identifies a single certificate. The keyIdentifier form can be used > to select CA certificates during path construction. The > authorityCertIssuer, authoritySerialNumber pair can only be used to > provide preference to one certificate over others during path > construction. > > This extension is always non-critical. > > -- > Viktor. From jgh at wizmail.org Thu Mar 26 00:40:08 2020 From: jgh at wizmail.org (Jeremy Harris) Date: Thu, 26 Mar 2020 00:40:08 +0000 Subject: resumption problem In-Reply-To: <20200324202530.GG68408@straasha.imrryr.org> References: <2de5766b-9195-895c-a7dc-6ee432b3cd1b@wizmail.org> <20200324004901.GB68408@straasha.imrryr.org> <20200324202530.GG68408@straasha.imrryr.org> Message-ID: On 24/03/2020 20:25, Viktor Dukhovni wrote: >>> I'm guessing it is not the first. The second would an issue with a >>> particular issuer on the CA list (does Exim configure a list of CAs to >>> send to the server?), >> >> I don't think so Looks like I'm wrong, from the behaviour. It's the second of the possible places, and "i" is 129. It appears to be failing the WPACKET_sub_allocate_bytes_u16() call. %rsi before the call, which I think should be the "namelen" arg, has value 172. -- Cheers, Jeremy From openssl-users at dukhovni.org Thu Mar 26 00:58:47 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 Mar 2020 20:58:47 -0400 Subject: resumption problem In-Reply-To: References: <2de5766b-9195-895c-a7dc-6ee432b3cd1b@wizmail.org> <20200324004901.GB68408@straasha.imrryr.org> <20200324202530.GG68408@straasha.imrryr.org> Message-ID: <20200326005847.GP68408@straasha.imrryr.org> On Thu, Mar 26, 2020 at 12:40:08AM +0000, Jeremy Harris wrote: > Looks like I'm wrong, from the behaviour. > > It's the second of the possible places, and "i" is 129. > It appears to be failing the WPACKET_sub_allocate_bytes_u16() > call. %rsi before the call, which I think should be > the "namelen" arg, has value 172. Right, you're running out of space by trying to send too many CA names. It is better to have this fail, so you can figure what is trying to dump your entire trusted CA list (of names) to the server, than to actually have that silently "work". Now you need to find out why that's happening. Perhaps your "openssl.cnf" (Linux distro mistake?) causes the damage for all applications even without explicit code to that end in Exim? Or you're calling something to make it happen. -- Viktor. From iliya.yurkevic at mail.ru Thu Mar 26 09:20:26 2020 From: iliya.yurkevic at mail.ru (RedEye) Date: Thu, 26 Mar 2020 02:20:26 -0700 (MST) Subject: SignedData is not being produced detached. BIO_new_CMS with CMS_Sign Message-ID: <1585214426197-0.post@n7.nabble.com> Hello, fellows. I am implementing a new streamer for CMS SignedData with CMS_sign. I use BIO_new_CMS. My program successfuly produces a SignedData structure in the end, but the actual data is embedded. I have passed (CMS_BINARY | CMS_DETACHED | CMS_STREAM) as flags to the initial call to CMS_sign but still the SignedData is not being produced detached. Am I missing something? Is there another way I can achieve the same thing? The code that follows is a true fragment from my original program. Thanks Have a nice day)) void SignInit(ca::CryptPacket &packet) //use once for initialization { CK_ULONG certCount = NULL; std::vectorcertHandles; std::vector certValue; X509* x509Cert = nullptr; CK_BYTE* p_CKA_ID; try { Rtk_CertInfo2* p_rtk_certinfo2_object = m_pCryptoModule->m_CertsCollection.GetCert(packet.request.senderCertId); if (!p_rtk_certinfo2_object) ca_throw_cert_need_log(packet.request.senderCertId); std::vector ckId = p_rtk_certinfo2_object->m_ckId; p_CKA_ID = new CK_BYTE[ckId.size()]; std::copy(ckId.begin(), ckId.end(), p_CKA_ID); CK_ATTRIBUTE certificateTemplate[] = CERTIFICATE_TEMPLATE(ckId, p_CKA_ID); m_key = GetKeyPair(ckId, m_session, m_pCryptoModule->m_functionList); if (!m_key) { ca_throw_log(RTK_E_FIND_KEY_FAILED); } if (m_pCryptoModule->m_functionList->C_FindObjectsInit(m_session, certificateTemplate, arraysize(certificateTemplate)) != CKR_OK) { ca_throw_log(RTK_E_FIND_OBJECTS_INIT_FAILED); } certHandles.clear(); certHandles.resize(10000); if (m_pCryptoModule->m_functionList->C_FindObjects(m_session, certHandles.data(), (CK_ULONG)certHandles.size(), &certCount) != CKR_OK || certCount == 0) { ca_throw_log(RTK_E_FIND_OBJECTS_FAILED); } if (m_pCryptoModule->m_functionList->C_FindObjectsFinal(m_session) != CKR_OK) { ca_throw_log(RTK_E_FIND_OBJECTS_FINAL_FAILED); } CK_ATTRIBUTE certValueAttr = { CKA_VALUE, NULL_PTR, 0 }; if (m_pCryptoModule->m_functionList->C_GetAttributeValue(m_session, certHandles[0], &certValueAttr, 1) != CKR_OK) ca_throw_log(RTK_E_GET_CKA_VALUE_FAILED); certValue.resize(certValueAttr.ulValueLen); certValueAttr.pValue = certValue.data(); if (m_pCryptoModule->m_functionList->C_GetAttributeValue(m_session, certHandles[0], &certValueAttr, 1) != CKR_OK) ca_throw_log(RTK_E_GET_CKA_VALUE_FAILED); x509Cert = CertToX509(CertToPem(certValue)); if (!x509Cert) { ca_throw_log(RTK_E_CERT_TO_X509_FAILED); } m_cms = CMS_sign(x509Cert, m_key, NULL, NULL, CMS_STREAM | CMS_BINARY | CMS_DETACHED); if (!m_cms) { ca_throw_log(RTK_E_SIGN_DATA_FAILED); } m_input = BIO_new_CMS(m_output, m_cms); X509_free(x509Cert); delete[] p_CKA_ID; } ca_catch { if (x509Cert) X509_free(x509Cert); delete[] p_CKA_ID; packet.response.errorCode = ex; packet.response.errorMessage = GetErrorMessage(ex); } } void CStreamSigner::Stream(ca::CryptPacket & packet) //for multiple calls { ca_lock; try { if (!m_cms) SignInit(packet); //initialization BYTE* pbData = packet.request.GetFileData(); DWORD cbData = packet.request.GetFileDataSize(); if (BIO_write(m_input, pbData, cbData) <= 0) ca_throw_log(RTK_E_WRITE_TO_OUT_BUF_FAILED); if (packet.request.streamFinalChunk) BIO_flush(m_input); std::vector cmsBuf = ReadMemBio(m_output); if (!cmsBuf.size()) ca_throw_log(RTK_E_READ_FROM_BUF_FAILED); packet.response.SetFileData(cmsBuf.data(), cmsBuf.size()); } ca_catch { packet.response.errorCode = ex; packet.response.errorMessage = GetErrorMessage(ex); } } -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From stm at pdflib.com Fri Mar 27 13:13:54 2020 From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=) Date: Fri, 27 Mar 2020 14:13:54 +0100 Subject: Explicit thread cleanup in OpenSSL 1.1.1 possible? Message-ID: Hi, with OpenSSL 1.1.1 it is possible to turn off the automatic cleanup with an atexit() handler by passing the flag OPENSSL_INIT_NO_ATEXIT to OPENSSL_init_crypto(). Is it possible to configure this also at the thread level, so that no automatic thread cleanup occurs, with the option to do an explicit per-thread cleanup? I looked at documentation and source code of OpenSSL 1.1.1 and this seems not to be possible, but I wanted to ask nevertheless. Background: We are embedding OpenSSL in a Java JNI library, and one particular JVM (IBM J9 on z/OS) loads our Java class and the JNI library in a dedicated thread. At the end of the program the JVM then unloads the the Java class and the JNI library before the thread terminates, and when the OpenSSL thread cleanup functions are called the JVM crashes because the shared library is gone from the address space. This happens because the pinning of the OpenSSL shared library does not work on z/OS. -- Stephan From Michael.Wojcik at microfocus.com Fri Mar 27 14:46:05 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 27 Mar 2020 14:46:05 +0000 Subject: Explicit thread cleanup in OpenSSL 1.1.1 possible? In-Reply-To: References: Message-ID: As a workaround, what about first making a JNI call to a trivial shared object that does an explicit dlopen of the OpenSSL shared object? The JVM wouldn't know about that load, and its subsequent unload of the shared object wouldn't remove it from the process address space, because there would still be a reference to it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stm at pdflib.com Fri Mar 27 15:59:02 2020 From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=) Date: Fri, 27 Mar 2020 16:59:02 +0100 Subject: Explicit thread cleanup in OpenSSL 1.1.1 possible? In-Reply-To: References: Message-ID: <9b966261-351b-92b7-5a3d-3744f0e0057e@pdflib.com> Hello Michael, Am 27.03.20 um 15:46 schrieb Michael Wojcik: > As a workaround, what about first making a JNI call to a trivial shared > object that does an explicit dlopen of the OpenSSL shared object? The > JVM wouldn't know about that load, and its subsequent unload of the > shared object wouldn't remove it from the process address space, because > there would still be a reference to it. thanks for the suggestion. This sounds similar to the trick that is already built into OpenSSL. Through other channels I found now two other possible solutions for the problem: 1) Use JNI_OnUnload() to call OPENSSL_cleanup() JNI_OnUnload() is called when the JVM unloads the JNI library. OPENSSL_cleanup() cleans up everything and no further per-thread cleanup happens after unloading the JNI shared library. 2) Use a C++ static object in the JNI library where the destructor calls OPENSSL_cleanup() When debugging the problem I came across this neat trick on stackoverflow: https://stackoverflow.com/a/11394263 class ResourceHolder { public: ResourceHolder() { // at start } ~ResourceHolder() { // at exit } }; ResourceHolder theHolder; I think that putting a call to OPENSSL_cleanup() into the destructor of the ResourceHolder class would also fix the problem, and it would be Java-agnostic. Approach 1) does fix the crash for me. If approach 2) works as well, I will use that one. -- Stephan From theodor.serbana96 at gmail.com Fri Mar 27 17:38:35 2020 From: theodor.serbana96 at gmail.com (George-Theodor Serbana) Date: Fri, 27 Mar 2020 19:38:35 +0200 Subject: Certificate subject match validation Message-ID: I am writing a SSL/TLS client (using Boost.Beast but underlying it's using OpenSSL) and although I have set on the SSL context the 'verify_peer' flag, there is no verification to prove the server presents an X509 which contains in the Subject Alternative Names the hostname of that server. As this is probably the dumbest type of attack someone could do (using a valid certificate with another domain name), I am thinking I'm doing something wrong. But from the documentation, I saw that using "verify_peer" should perform all the verifications... Now if not even this simple check is being done, how about expiration of the certificate, revocation status and other checks? Should they be performed manually as well? For now I am using X509_VERIFY_PARAM_set1_host with SSL_CTX_set1_param to do this specific check. Best regards, Theodor -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Mar 27 17:44:43 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 27 Mar 2020 13:44:43 -0400 Subject: Certificate subject match validation In-Reply-To: References: Message-ID: <20200327174443.GB41308@straasha.imrryr.org> On Fri, Mar 27, 2020 at 07:38:35PM +0200, George-Theodor Serbana wrote: > I am writing a SSL/TLS client (using Boost.Beast but underlying it's using > OpenSSL) and although I have set on the SSL context the 'verify_peer' flag, > there is no verification to prove the server presents an X509 which > contains in the Subject Alternative Names the hostname of that server. > > As this is probably the dumbest type of attack someone could do (using a > valid certificate with another domain name), I am thinking I'm doing > something wrong. But from the documentation, I saw that using "verify_peer" > should perform all the verifications... It verifies the trust chain. To also verify the peer name, you need to specify the peer name via: SSL_set1_host() > Now if not even this simple check is being done, how about expiration of > the certificate, revocation status and other checks? Should they be > performed manually as well? No, that's what VERIFY_PEER is for. > For now I am using X509_VERIFY_PARAM_set1_host with SSL_CTX_set1_param to > do this specific check. That's the slightly less convenient legacy API from OpenSSL 1.0.2. In 1.1.0 and later, you can use SSL_set1_host() (and in some cases also SSL_add1_host()). See the SSL_set1_host(3) manpage for details. -- Viktor. From jgh at wizmail.org Fri Mar 27 20:20:55 2020 From: jgh at wizmail.org (Jeremy Harris) Date: Fri, 27 Mar 2020 20:20:55 +0000 Subject: resumption problem In-Reply-To: <20200326005847.GP68408@straasha.imrryr.org> References: <2de5766b-9195-895c-a7dc-6ee432b3cd1b@wizmail.org> <20200324004901.GB68408@straasha.imrryr.org> <20200324202530.GG68408@straasha.imrryr.org> <20200326005847.GP68408@straasha.imrryr.org> Message-ID: On 26/03/2020 00:58, Viktor Dukhovni wrote: > On Thu, Mar 26, 2020 at 12:40:08AM +0000, Jeremy Harris wrote: > >> Looks like I'm wrong, from the behaviour. >> >> It's the second of the possible places, and "i" is 129. >> It appears to be failing the WPACKET_sub_allocate_bytes_u16() >> call. %rsi before the call, which I think should be >> the "namelen" arg, has value 172. > > Right, you're running out of space by trying to send too many > CA names. It is better to have this fail, so you can figure > what is trying to dump your entire trusted CA list (of names) > to the server, than to actually have that silently "work". It's /etc/pki/tls/certs/ca-bundle.crt (on Centos 8) and it's being loaded using SSL_CTX_set_client_CA_list() into the client, supposedly to be the acceptable CAs for the cert sent by the server. The load call doesn't have a return value to check. The list presented had 133 entries. > Perhaps your > "openssl.cnf" (Linux distro mistake?) causes the damage > for all applications even without explicit code to that > end in Exim? Or you're calling something to make it happen. The Exim config is saying to use that file, so I do have a workaround point there. However, the question is: what is [1] the proper fix? We want to accept "the usual, pretty big, set of well-known CAs". Is that an incorrect way of telling OpenSSL that list? And how come it only fails under resumption and when a client-cert is also used? 1] We also need to code to be compatible across a wide range of OpenSSL versions. Minimising #ifdeffery is a factor. -- Cheers, Jeremy From openssl-users at dukhovni.org Fri Mar 27 21:07:47 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 27 Mar 2020 17:07:47 -0400 Subject: resumption problem In-Reply-To: References: <2de5766b-9195-895c-a7dc-6ee432b3cd1b@wizmail.org> <20200324004901.GB68408@straasha.imrryr.org> <20200324202530.GG68408@straasha.imrryr.org> <20200326005847.GP68408@straasha.imrryr.org> Message-ID: <20200327210747.GC41308@straasha.imrryr.org> On Fri, Mar 27, 2020 at 08:20:55PM +0000, Jeremy Harris wrote: > > Right, you're running out of space by trying to send too many > > CA names. It is better to have this fail, so you can figure > > what is trying to dump your entire trusted CA list (of names) > > to the server, than to actually have that silently "work". > > It's /etc/pki/tls/certs/ca-bundle.crt (on Centos 8) and > it's being loaded using SSL_CTX_set_client_CA_list() > into the client, supposedly to be the acceptable CAs > for the cert sent by the server. That function should only affect the server -> client direction. Briefly, in OpenSSL 1.1.1 it affected both the client and server directions, but this was fixed in OpenSSL 1.1.1a. If the distro started with 1.1.1 and only backported security fixes, you could be running an OpenSSL version with the unintentional bidirectional setting. Another possibility is that your system-wide openssl.cnf file has a "RequestCAFile" or "ClientCAFile" setting. Both unfortunately set not only the server->client direction, but also the client->server direction. This may be a bug (oversight), the second of these should not touch the bidirectional list. "ssl/ssl_conf.c" line 500: static int cmd_RequestCAFile(SSL_CONF_CTX *cctx, const char *value) { if (cctx->canames == NULL) cctx->canames = sk_X509_NAME_new_null(); if (cctx->canames == NULL) return 0; return SSL_add_file_cert_subjects_to_stack(cctx->canames, value); } static int cmd_ClientCAFile(SSL_CONF_CTX *cctx, const char *value) { return cmd_RequestCAFile(cctx, value); } "ssl/ssl_conf.c" line 883: int SSL_CONF_CTX_finish(SSL_CONF_CTX *cctx) { ... if (cctx->canames) { if (cctx->ssl) SSL_set0_CA_list(cctx->ssl, cctx->canames); else if (cctx->ctx) SSL_CTX_set0_CA_list(cctx->ctx, cctx->canames); else sk_X509_NAME_pop_free(cctx->canames, X509_NAME_free); cctx->canames = NULL; } return 1; } Can you confirm whether any such directive is present in your system-wide openssl.cnf (possibly via .include)? > > Perhaps your "openssl.cnf" (Linux distro mistake?) causes the > > damage for all applications even without explicit code to that end > > in Exim? Or you're calling something to make it happen. > > The Exim config is saying to use that file, so I do have a workaround > point there. It is actually not easy to avoid using the system-wide config. It is loaded by default during library initialization, and you need custom initialization calls to avoid loading it. > However, the question is: what is [1] the proper fix? We want to > accept "the usual, pretty big, set of well-known CAs". Is that an > incorrect way of telling OpenSSL that list? It makes some sense to send a CA list to clients, but ideally one that is not too large. In Postfix I recommend a small or no CAfile (from which the CAlist is initialized), and the bulk of the trust store configured via a CApath (which is not used to send CA names to clients). Most clients (real MTAs, not random Java apps) handle an empty CA list just fine, and use the (at most) one client cert they have. > And how come it only fails under resumption and when a client-cert is > also used? Here, I am not sure, but perhaps this is because the extension is only valid with TLS 1.3, and on resumption we already know the server protocol version. On initial handshakes the protocol might be TLS 1.2, and perhaps as a result the list is not sent??? > 1] We also need to code to be compatible across a wide range > of OpenSSL versions. Minimising #ifdeffery is a factor. Understood, I'm in the same boat with Postfix. -- Viktor. From jgh at wizmail.org Fri Mar 27 21:25:28 2020 From: jgh at wizmail.org (Jeremy Harris) Date: Fri, 27 Mar 2020 21:25:28 +0000 Subject: resumption problem In-Reply-To: <20200327210747.GC41308@straasha.imrryr.org> References: <2de5766b-9195-895c-a7dc-6ee432b3cd1b@wizmail.org> <20200324004901.GB68408@straasha.imrryr.org> <20200324202530.GG68408@straasha.imrryr.org> <20200326005847.GP68408@straasha.imrryr.org> <20200327210747.GC41308@straasha.imrryr.org> Message-ID: On 27/03/2020 21:07, Viktor Dukhovni wrote: > That function should only affect the server -> client direction. > Briefly, in OpenSSL 1.1.1 it affected both the client and server > directions, but this was fixed in OpenSSL 1.1.1a. If Centos is following the same pattern in 8 as they did in 7, they do list the letter when there is one; I have a 7 system claiming "1.0.2k-fips". So: > If the distro started with 1.1.1 and only backported security fixes, you > could be running an OpenSSL version with the unintentional bidirectional > setting. .. either this, or even an unpatched basic 1.1.1 . A simple code addition to avoid that call in the client case sounds in order. Would the above likely explain the error I'm getting? > Another possibility is that your system-wide openssl.cnf file has a > "RequestCAFile" or "ClientCAFile" setting. Neither appears to be present in /etc/pki/tls/openssl.cnf -- Cheers, Jeremy From openssl-users at dukhovni.org Fri Mar 27 21:52:58 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 27 Mar 2020 17:52:58 -0400 Subject: resumption problem In-Reply-To: References: <2de5766b-9195-895c-a7dc-6ee432b3cd1b@wizmail.org> <20200324004901.GB68408@straasha.imrryr.org> <20200324202530.GG68408@straasha.imrryr.org> <20200326005847.GP68408@straasha.imrryr.org> <20200327210747.GC41308@straasha.imrryr.org> Message-ID: <20200327215258.GE41308@straasha.imrryr.org> On Fri, Mar 27, 2020 at 09:25:28PM +0000, Jeremy Harris wrote: > > If the distro started with 1.1.1 and only backported security fixes, you > > could be running an OpenSSL version with the unintentional bidirectional > > setting. > > .. either this, or even an unpatched basic 1.1.1 . > > A simple code addition to avoid that call in the client case sounds > in order. Would the above likely explain the error I'm getting? You could explicitly set the client CA list to an empty stack, as a final step in initializing the SSL_CTX: SSL_CTX_set0_CA_list(ctx, NULL); > > Another possibility is that your system-wide openssl.cnf file has a > > "RequestCAFile" or "ClientCAFile" setting. > > Neither appears to be present in /etc/pki/tls/openssl.cnf And neither has any ".include" directives? -- Viktor. From jgh at wizmail.org Fri Mar 27 22:10:16 2020 From: jgh at wizmail.org (Jeremy Harris) Date: Fri, 27 Mar 2020 22:10:16 +0000 Subject: resumption problem In-Reply-To: <20200327215258.GE41308@straasha.imrryr.org> References: <2de5766b-9195-895c-a7dc-6ee432b3cd1b@wizmail.org> <20200324004901.GB68408@straasha.imrryr.org> <20200324202530.GG68408@straasha.imrryr.org> <20200326005847.GP68408@straasha.imrryr.org> <20200327210747.GC41308@straasha.imrryr.org> <20200327215258.GE41308@straasha.imrryr.org> Message-ID: <2ace4dac-fe7e-b471-f6ed-53f96f18d15f@wizmail.org> On 27/03/2020 21:52, Viktor Dukhovni wrote: > On Fri, Mar 27, 2020 at 09:25:28PM +0000, Jeremy Harris wrote: > >>> If the distro started with 1.1.1 and only backported security fixes, you >>> could be running an OpenSSL version with the unintentional bidirectional >>> setting. >> >> .. either this, or even an unpatched basic 1.1.1 . >> >> A simple code addition to avoid that call in the client case sounds >> in order. Testing, it appears to work - I get resumption and not that error. And the Exim testsuite shows no regressions, at least on my laptop (which is Fedora 31, with 1.1.1d). >>> Another possibility is that your system-wide openssl.cnf file has a >>> "RequestCAFile" or "ClientCAFile" setting. >> >> Neither appears to be present in /etc/pki/tls/openssl.cnf > > And neither has any ".include" directives? One, but that file doesn't have either string, either. -- Cheers, Jeremy From openssl-users at dukhovni.org Fri Mar 27 23:38:52 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 27 Mar 2020 19:38:52 -0400 Subject: resumption problem In-Reply-To: <2ace4dac-fe7e-b471-f6ed-53f96f18d15f@wizmail.org> References: <20200324004901.GB68408@straasha.imrryr.org> <20200324202530.GG68408@straasha.imrryr.org> <20200326005847.GP68408@straasha.imrryr.org> <20200327210747.GC41308@straasha.imrryr.org> <20200327215258.GE41308@straasha.imrryr.org> <2ace4dac-fe7e-b471-f6ed-53f96f18d15f@wizmail.org> Message-ID: <20200327233852.GF41308@straasha.imrryr.org> On Fri, Mar 27, 2020 at 10:10:16PM +0000, Jeremy Harris wrote: > >> A simple code addition to avoid that call in the client case sounds > >> in order. > > Testing, it appears to work - I get resumption and not that error. > And the Exim testsuite shows no regressions, at least on my laptop > (which is Fedora 31, with 1.1.1d). On a Fedora 31 system I also don't see those directives in the system openssl.cnf or includes. Mind you, closer inspection of the code suggests that in the config file also "RequestCAPath" and "ClientCAPath" would result in setting the bidirectional CA list. But I don't find those either. > >>> Another possibility is that your system-wide openssl.cnf file has a > >>> "RequestCAFile" or "ClientCAFile" setting. > >> > >> Neither appears to be present in /etc/pki/tls/openssl.cnf > > > > And neither has any ".include" directives? So my best guess is that you were testing with approximately a stock 1.1.1 that predates 1.1.1a, modulo security fixes. Otherwise, it is unclear how the client CA list (server -> client) ended up being sent from client -> server. -- Viktor. From matt at openssl.org Sat Mar 28 11:11:49 2020 From: matt at openssl.org (Matt Caswell) Date: Sat, 28 Mar 2020 11:11:49 +0000 Subject: Forthcoming OpenSSL Release Message-ID: <1d0128a9-8d8e-a8b9-2949-7404ae287ea8@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.1f. This release will be made available on Tuesday 31st March 2020 between 1200-1600 UTC. This is a bug fix only release. Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl5/MPUACgkQ2cTSbQ5g RJGnaggAjtB2r56ufZaOUAy7/stpy+Cj7R4Jq+RZb8Ja6c9hU9FwHx5/eESxs1lC XQKr5RGcPZbIvgoDaFCBVXBswl6Ivhde/MuWLoeoag+sl4TBztx/Aash6YAT78ij h/NvRcYDn2mcBrclxJckh9sags5ei13d+GWug349X8d7dVdfHooFTBgq0Th4ehfZ UBaNgQTnqnd/8PD2paGkQtHOr8Qr2TTPH6HyQ5Vlea+x0AzjnAbWjbr/wvu0yuFE 2RqE6RnVy65M+Nx1wIXh1ZJT0EfyN4lqRFYuTWViJVPfPDT61UkIKSbxzRtVWEl8 Pu4T2r9cKHl8kFnuA0kqc0/5/jG2EQ== =KWO3 -----END PGP SIGNATURE----- From theodor.serbana96 at gmail.com Sat Mar 28 20:56:20 2020 From: theodor.serbana96 at gmail.com (George-Theodor Serbana) Date: Sat, 28 Mar 2020 22:56:20 +0200 Subject: Certificate subject match validation In-Reply-To: <20200327174443.GB41308@straasha.imrryr.org> References: <20200327174443.GB41308@straasha.imrryr.org> Message-ID: > I am writing a SSL/TLS client (using Boost.Beast but underlying it's using > OpenSSL) and although I have set on the SSL context the 'verify_peer' flag, > there is no verification to prove the server presents an X509 which > contains in the Subject Alternative Names the hostname of that server. > > As this is probably the dumbest type of attack someone could do (using a > valid certificate with another domain name), I am thinking I'm doing > something wrong. But from the documentation, I saw that using "verify_peer" > should perform all the verifications... It verifies the trust chain. To also verify the peer name, you need to specify the peer name via: SSL_set1_host() > Now if not even this simple check is being done, how about expiration of > the certificate, revocation status and other checks? Should they be > performed manually as well? No, that's what VERIFY_PEER is for. > For now I am using X509_VERIFY_PARAM_set1_host with SSL_CTX_set1_param to > do this specific check. That's the slightly less convenient legacy API from OpenSSL 1.0.2. In 1.1.0 and later, you can use SSL_set1_host() (and in some cases also SSL_add1_host()). See the SSL_set1_host(3) manpage for details. --------------------------- Indeed I re-read the docs and it says that users should not assume that hostnames are validated by default without explicitly calling the API, I must've missed that bit and thank you for letting me know. I will shift towards using the newer SSL_set1_host together with some flags (I don't want any wildcards). Now just to be extra safe I'm still asking: will the VERIFY_PEER option together with SSL_set1_host instruct OpenSSL to perform all possible checks on the certificate presented by the server such that no security breach remains at this level? Is there anything else that I should call or perform manually? -- Theodor -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sat Mar 28 22:29:38 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 28 Mar 2020 18:29:38 -0400 Subject: Certificate subject match validation In-Reply-To: References: <20200327174443.GB41308@straasha.imrryr.org> Message-ID: <20200328222938.GG41308@straasha.imrryr.org> On Sat, Mar 28, 2020 at 10:56:20PM +0200, George-Theodor Serbana wrote: > > > For now I am using X509_VERIFY_PARAM_set1_host with SSL_CTX_set1_param to > > > do this specific check. > > > > That's the slightly less convenient legacy API from OpenSSL 1.0.2. > > In 1.1.0 and later, you can use SSL_set1_host() (and in some > > cases also SSL_add1_host()). > > > > See the SSL_set1_host(3) manpage for details. > > Indeed I re-read the docs and it says that users should not assume that > hostnames are validated by default without explicitly calling the API, I > must've missed that bit and thank you for letting me know. I will shift > towards using the newer SSL_set1_host together with some flags (I don't > want any wildcards). If your needs are sufficiently narrow to rule out connecting to sites that use wildcard certificates, perhaps they're also narrow enough to rule out sites that don't have subjectAltNames, in which case the flags could be: So you'll call either of (here a NULL callback, set a non-null callback if appropriate): SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL); /* Just once */ SSL_set_verify(ssl, SSL_VERIFY_PEER, NULL); /* Per connection */ followed by (per connection): SSL_set1_host(ssl, "www.example.org"); SSL_set_hostflags(ssl, X509_CHECK_FLAG_NO_WILDCARDS | X509_CHECK_FLAG_NEVER_CHECK_SUBJECT); which also insists on a DNS subject altname (the preferred way to authenticate DNS names), and never looks at any CN field in the subject DN. > Now just to be extra safe I'm still asking: will the VERIFY_PEER option > together with SSL_set1_host instruct OpenSSL to perform all possible checks > on the certificate presented by the server such that no security breach > remains at this level? Is there anything else that I should call or perform > manually? No, the above is enough. -- Viktor. From theodor.serbana96 at gmail.com Sun Mar 29 10:00:03 2020 From: theodor.serbana96 at gmail.com (George-Theodor Serbana) Date: Sun, 29 Mar 2020 13:00:03 +0300 Subject: Certificate subject match validation In-Reply-To: <20200328222938.GG41308@straasha.imrryr.org> References: <20200327174443.GB41308@straasha.imrryr.org> <20200328222938.GG41308@straasha.imrryr.org> Message-ID: Yes, indeed I don't want to take into account the CN, only the SANs. Thanks for the extra flag and all the clarifications! Best regards, Theodor > > > > > > For now I am using X509_VERIFY_PARAM_set1_host with > SSL_CTX_set1_param to > > > > do this specific check. > > > > > > That's the slightly less convenient legacy API from OpenSSL 1.0.2. > > > In 1.1.0 and later, you can use SSL_set1_host() (and in some > > > cases also SSL_add1_host()). > > > > > > See the SSL_set1_host(3) manpage for details. > > > > Indeed I re-read the docs and it says that users should not assume that > > hostnames are validated by default without explicitly calling the API, I > > must've missed that bit and thank you for letting me know. I will shift > > towards using the newer SSL_set1_host together with some flags (I don't > > want any wildcards). > > If your needs are sufficiently narrow to rule out connecting to sites > that use wildcard certificates, perhaps they're also narrow enough to > rule out sites that don't have subjectAltNames, in which case the > flags could be: > > So you'll call either of (here a NULL callback, set a non-null callback > if appropriate): > > SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL); /* Just once */ > SSL_set_verify(ssl, SSL_VERIFY_PEER, NULL); /* Per connection > */ > > followed by (per connection): > > SSL_set1_host(ssl, "www.example.org"); > SSL_set_hostflags(ssl, X509_CHECK_FLAG_NO_WILDCARDS > | X509_CHECK_FLAG_NEVER_CHECK_SUBJECT); > > which also insists on a DNS subject altname (the preferred way to > authenticate DNS names), and never looks at any CN field in the subject > DN. > > > Now just to be extra safe I'm still asking: will the VERIFY_PEER option > > together with SSL_set1_host instruct OpenSSL to perform all possible > checks > > on the certificate presented by the server such that no security breach > > remains at this level? Is there anything else that I should call or > perform > > manually? > > No, the above is enough. > > -- > Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nojztrade at gmail.com Mon Mar 30 07:04:50 2020 From: nojztrade at gmail.com (Seller Steam) Date: Mon, 30 Mar 2020 09:04:50 +0200 Subject: Slow DTLS handshake in case of packet loss Message-ID: Hi, I implemented a DTLS server using openssl. (I have an udp socket and I am using a memory bio to communicate with openssl.) However if there is packet loss the DTLS handshake could take 1-2 seconds, which is a lot in my case. The normal flow when there is no packet loss: (few milliseconds) Client Hello -------------------------> <------------------------- Server Hello Rest of the handshake ----------> <---------- Rest of the handshake The flow I am experiencing: (few seconds) Client Hello -------------------------> <-------(lost)----------- Server Hello Client Hello -------------------------> Client Hello -------------------------> Client Hello -------------------------> <------------------------- Server Hello Rest of the handshake ----------> <---------- Rest of the handshake I can easily reproduce it even in local environment directly dropping the first Server Hello. I am curious why the server does not respond to some several upcoming Client Hello's. If it would answer the handshake could complete well below 1 second but this way it takes up 1-2 seconds, when it finally answers again for later Client Hello's. How could I make the DTLS handshake complete faster? (by enabling answer for all Client Hello's for example, is there a way?) Thanks in advance and best regards, nojz -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfulger at gmx.com Mon Mar 30 07:41:00 2020 From: dfulger at gmx.com (Dan Fulger) Date: Mon, 30 Mar 2020 09:41:00 +0200 Subject: resumption problem Message-ID: An HTML attachment was scrubbed... URL: From jgh at wizmail.org Mon Mar 30 08:37:51 2020 From: jgh at wizmail.org (Jeremy Harris) Date: Mon, 30 Mar 2020 09:37:51 +0100 Subject: resumption problem In-Reply-To: References: Message-ID: <91828219-f717-886a-dbb7-aae03c7acee0@wizmail.org> On 30/03/2020 08:41, Dan Fulger wrote: > Indeed, CentOS 8.0 has OpenSSL 1.1.1 with very few updates. > But CentOS 8.1 was released in January, with OpenSSL 1.1.1c. Fortunately, with Viktor's help, the application fix is a one-liner and is compatible across versions. -- Cheers, Jeremy From openssl-users at dukhovni.org Mon Mar 30 09:12:58 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 30 Mar 2020 05:12:58 -0400 Subject: resumption problem In-Reply-To: <91828219-f717-886a-dbb7-aae03c7acee0@wizmail.org> References: <91828219-f717-886a-dbb7-aae03c7acee0@wizmail.org> Message-ID: <20200330091258.GQ41308@straasha.imrryr.org> On Mon, Mar 30, 2020 at 09:37:51AM +0100, Jeremy Harris wrote: > On 30/03/2020 08:41, Dan Fulger wrote: > > Indeed, CentOS 8.0 has OpenSSL 1.1.1 with very few updates. > > But CentOS 8.1 was released in January, with OpenSSL 1.1.1c. > > Fortunately, with Viktor's help, the application fix is a > one-liner and is compatible across versions. I am glad you have a work-around, but remain puzzled. On a FreeBSD 12.1 system with OpenSSL 1.1.1d, I just built a version of "posttls-finger" patched (hastily, with inadequate error checks) to also load a client CA list into the client->server SSL context: --- a/src/tls/tls_client.c +++ b/src/tls/tls_client.c @@ -432,6 +432,18 @@ TLS_APPL_STATE *tls_client_init(const TLS_CLIENT_INIT_PROPS *props) SSL_CTX_free(client_ctx); /* 200411 */ return (0); } + if (props->CAfile) { + STACK_OF(X509_NAME) *calist = SSL_load_client_CA_file(props->CAfile); + + SSL_CTX_set_client_CA_list(client_ctx, calist); + msg_info("loaded %d CA names", sk_X509_NAME_num(calist)); + } /* * We do not need a client certificate, so the certificates are only When I run this, and resume a TLS 1.3 session, it logs that 150 CA names have been loaded, but none are sent in the resumption client hello, which remains modestly sized: posttls-finger: loaded 150 CA names posttls-finger: SSL_connect:before SSL initialization posttls-finger: write to 80127A100 [80136B000] (517 bytes => 517 (0x205)) posttls-finger: SSL_connect:SSLv3/TLS write client hello posttls-finger: SSL_connect:SSLv3/TLS write client hello posttls-finger: SSL_connect:SSLv3/TLS read server hello posttls-finger: SSL_connect:TLSv1.3 read encrypted extensions posttls-finger: SSL_connect:SSLv3/TLS read server certificate posttls-finger: SSL_connect:TLSv1.3 read server certificate verify posttls-finger: SSL_connect:SSLv3/TLS read finished posttls-finger: SSL_connect:SSLv3/TLS write change cipher spec posttls-finger: write to 80127A100 [80136B000] (80 bytes => 80 (0x50)) posttls-finger: SSL_connect:SSLv3/TLS write finished posttls-finger: SSL_connect:SSL negotiation finished successfully posttls-finger: SSL_connect:SSL negotiation finished successfully posttls-finger: save session ... to memory cache posttls-finger: SSL_connect:SSLv3/TLS read server session ticket posttls-finger: reloaded session ... from memory cache posttls-finger: SSL_connect:before SSL initialization posttls-finger: write to 80127A100 [80136B000] (638 bytes => 638 (0x27E)) posttls-finger: SSL_connect:SSLv3/TLS write client hello posttls-finger: SSL_connect:SSLv3/TLS write client hello posttls-finger: SSL_connect:SSLv3/TLS read server hello posttls-finger: SSL_connect:TLSv1.3 read encrypted extensions posttls-finger: SSL_connect:SSLv3/TLS read finished posttls-finger: SSL_connect:SSLv3/TLS write change cipher spec posttls-finger: write to 80127A100 [80136B000] (80 bytes => 80 (0x50)) posttls-finger: SSL_connect:SSLv3/TLS write finished posttls-finger: Untrusted TLS connection established to ... TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) As expected, CA names loaded via SSL_CTX_set_client_CA_list() are not sent in the client->server direction, either initially, or on resumption. -- Viktor. From balazs.horvath.email at gmail.com Mon Mar 30 15:00:37 2020 From: balazs.horvath.email at gmail.com (=?UTF-8?B?QmFsw6F6cyBIb3J2w6F0aA==?=) Date: Mon, 30 Mar 2020 17:00:37 +0200 Subject: New inlcudes needed for OpenSSL V1.1.1 sockets Message-ID: Hi, in out project we compile OpenSSL V1.0.2p for MIPS and Linux under Linux. For MIPS we use GCC, and we use sockets for both MIPS and Linux. Now we want to upgrade to 1.1.1d, and want to use sockets, but MIPS fails, because it needs extra includes from the socket parts of OpenSSL. Following extra includes are needed: arpa/inet.h netinet/tcp.h netinet/in.h strings.h netdb.h sys/socket.h sys/ioctl.h sys/un.h For Linux the includes under /usr/include work, but for MIPS they give compile errors. What should we use for MIPS? Should we adjust the headers for MIPS or the OpenSSL sources? Why are these headers needed in the new version, if they were not in the old one? Thanks, Balazs -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Mar 30 15:23:02 2020 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 30 Mar 2020 15:23:02 +0000 Subject: 1.OU or OU.1 ? In-Reply-To: <24C17691-D986-4C9C-A213-0326ED5AE4B6@akamai.com> References: <87wo7ea0kb.wl-levitte@openssl.org> <24C17691-D986-4C9C-A213-0326ED5AE4B6@akamai.com> Message-ID: <5E4670DE-9B6D-42FC-8BFA-BEBCF68D1323@akamai.com> Just to close the loop: I decided better documentation is the only answer for now: https://github.com/openssl/openssl/pull/11431 I'll copy the info below into a new issue. ?On 3/21/20, 9:47 AM, "Salz, Rich via openssl-users" wrote: Argh. Thanks for the detailed explanation. It seems to me that if I add suffixes ".nnn" support to auto_info() than we can move xxx.field to deprecated at some point? On 3/20/20, 10:45 PM, "Richard Levitte" wrote: The correct answer is, it depends. This is an unfortunate evolutionary artefact, and is governed by very different pieces of code. The config.pod example revolves around subject names and the config for 'openssl req'. The code that uses this is the function auto_info(), found in apps/req.c. The x509v3_config.pod example revolves around X.509 v3 extensions, and the config for those is used by diverse functions in crypto/x509v3/ (1.1.1) or crypto/x509/ (masterand upcoming 3.0), and ultimately, the key name comparison is done by name_cmp(), found in v3_utl.c. So both manuals are correct. Unfortunately... Cheers, Richard On Fri, 20 Mar 2020 22:12:08 +0100, Salz, Rich via openssl-users wrote: > > > The doc/man5/config.pod file says to use > > 1.OU = ?My first OU? > > 2.OU = ?My second OU? > > But doc/man5/x509v3_config.pod says to append the numeric, as in > > email.1 = steve at here > > email.2 = steve at there > > I believe the second form is correct. Can anyone confirm? > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From jetson23 at hotmail.com Mon Mar 30 16:01:38 2020 From: jetson23 at hotmail.com (Jason Schultz) Date: Mon, 30 Mar 2020 16:01:38 +0000 Subject: Peer certificate verification in verify_callback In-Reply-To: References: Message-ID: Just wanted to bring this up again as I didn't get any responses initially. Has anyone dealt with this or similar issues with OpenSSL 1.1.1? ________________________________ From: openssl-users on behalf of Jason Schultz Sent: Thursday, March 5, 2020 2:04 PM To: openssl-users at openssl.org Subject: Peer certificate verification in verify_callback I have some questions about my application?s verify_callback() function and how I handle some of the OpenSSL errors. For example, if my client application is presented a self-signed certificate in the handshake, verify_callback() is called with an error, for which X509_STORE_CTX_get_error() returns 18/X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT. In this case, my application searches its trusted store for this certificate, and if it finds a match, the error is cleared and the handshake is allow to proceed. Other examples are cases where my client application is presented with a certificate chain. Let?s say the chain looks like root -> intermediate -> end-entity, but the server is configured to not send the root, so my client gets: intermediate -> end-entity in the handshake. One case is where my client is presented these certificates and has the end-entity certificate in its trusted store. In this case, the verify_callback() gets error 20/ X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY. For this error, my application will search its trusted store for the end-entity certificate, and when a match is found the error is cleared and the handshake is allowed to proceed. A slightly different case is when the client has only the intermediate certificate in its trusted store, while the server presents the intermediate -> end-entity chain. In this case, verify_callback() is called with an error, and X509_STORE_CTX_get_error() returns 2/ X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT. These last two cases seem very similar but get slightly different errors. Right now my application does not look for a match in the case of X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT. My plan is to add that error to the cases where the trusted store is searched for a match. Are there more subtle differences between these two errors that I?m missing? Or does my plan to have the application do the addition checking for this error make sense? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgh at wizmail.org Mon Mar 30 16:29:16 2020 From: jgh at wizmail.org (Jeremy Harris) Date: Mon, 30 Mar 2020 17:29:16 +0100 Subject: Peer certificate verification in verify_callback In-Reply-To: References: Message-ID: <22ec19ba-29dc-6644-f19f-3c92c2b127a5@wizmail.org> On 30/03/2020 17:01, Jason Schultz wrote: > For example, if my client application is presented a self-signed certificate in the handshake, verify_callback() is called with an error, for which X509_STORE_CTX_get_error() returns 18/X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT. In this case, my application searches its trusted store for this certificate, and if it finds a match, the error is cleared and the handshake is allow to proceed. If you don't care that the cert is verifiable, tell OpenSSL that before connection? SSL_CTX_set_verify !SSL_VERIFY_FAIL_IF_NO_PEER_CERT > Other examples are cases where my client application is presented with a certificate chain. Let?s say the chain looks like root -> intermediate -> end-entity, but the server is configured to not send the root, so my client gets: intermediate -> end-entity in the handshake. > > > > One case is where my client is presented these certificates and has the end-entity certificate in its trusted store. In this case, the verify_callback() gets error 20/ X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY. For this error, my application will search its trusted store for the end-entity certificate, and when a match is found the error is cleared and the handshake is allowed to proceed. Tell OpenSSL the root(s) you trust before connecting -- Cheers, Jeremy From openssl-users at dukhovni.org Mon Mar 30 18:17:23 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 30 Mar 2020 14:17:23 -0400 Subject: Peer certificate verification in verify_callback In-Reply-To: References: Message-ID: <20200330181723.GR41308@straasha.imrryr.org> On Thu, Mar 05, 2020 at 02:04:27PM +0000, Jason Schultz wrote: > I have some questions about my application?s verify_callback() function and how I handle some of the OpenSSL errors. You're going about this the wrong way. Instead of tryign (likely insecurely) to patch up verification errors in a verify callback, if you have a certificate store that is not directly supported by OpenSSL, you need to implement your own custom X509_STORE type, associate that store with the SSL_CTX and have OpenSSL's built-in certificate verification search that store for you. If you also want to directly trust intermediate certificates that are not self-signed roots, you can either set the "partial chain" flag, or load into your store intermediate certificates with auxiliary trust settings (aka "TRUSTED CERTIFICATES"), which will then be trusted without chaining to a root, but simpler to just add the roots to the store. -- Viktor. From Michael.Wojcik at microfocus.com Mon Mar 30 18:17:06 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 30 Mar 2020 18:17:06 +0000 Subject: New inlcudes needed for OpenSSL V1.1.1 sockets In-Reply-To: References: Message-ID: From: openssl-users on behalf of Bal?zs Horv?th Sent: Monday, March 30, 2020 10:00 > Following extra includes are needed: > arpa/inet.h > netinet/tcp.h > netinet/in.h > strings.h > netdb.h > sys/socket.h > sys/ioctl.h > sys/un.h These are system headers, not OpenSSL headers. OpenSSL has no control over them. > For Linux the includes under /usr/include work, but for MIPS they give?compile errors. Then you're using the wrong headers for the MIPS compilation. To be honest, it's not clear to me what you're doing, because Linux is an operating system (or more precisely a kernel), and MIPS is a processor family. > What should we use for MIPS? This is not an OpenSSL question. It's a cross-compilation question (I think, since I'm not sure what you're actually trying to do), and so depends on your cross-compilation toolchain. From openssl-users at dukhovni.org Mon Mar 30 18:49:02 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 30 Mar 2020 14:49:02 -0400 Subject: resumption problem In-Reply-To: References: <91828219-f717-886a-dbb7-aae03c7acee0@wizmail.org> <20200330091258.GQ41308@straasha.imrryr.org> Message-ID: > On Mar 30, 2020, at 6:12 AM, Jeremy Harris wrote: > > On 30/03/2020 10:12, Viktor Dukhovni wrote: >> On Mon, Mar 30, 2020 at 09:37:51AM +0100, Jeremy Harris wrote: >> >>> On 30/03/2020 08:41, Dan Fulger wrote: >>>> Indeed, CentOS 8.0 has OpenSSL 1.1.1 with very few updates. >>>> But CentOS 8.1 was released in January, with OpenSSL 1.1.1c. >>> >>> Fortunately, with Viktor's help, the application fix is a >>> one-liner and is compatible across versions. >> >> I am glad you have a work-around, but remain puzzled. On a FreeBSD 12.1 >> system with OpenSSL 1.1.1d > 1.1.1d != 1.1.1 Yes, if it was truly 1.1.1 without the 1.1.1a patches, then your symptoms are expected. The message from Dan Fulger suggested that perhaps it was 1.1.1c, but maybe that's a different system than the one on which you observed the problem. Likely you're all set. Good luck. -- Viktor. From jetson23 at hotmail.com Mon Mar 30 21:02:47 2020 From: jetson23 at hotmail.com (Jason Schultz) Date: Mon, 30 Mar 2020 21:02:47 +0000 Subject: Peer certificate verification in verify_callback In-Reply-To: <20200330181723.GR41308@straasha.imrryr.org> References: , <20200330181723.GR41308@straasha.imrryr.org> Message-ID: Victor, Jeremy- Thanks for your responses. It sounds like I should maybe take a step back and describe what I'm doing and how. I'm possibly doing things fundamentally wrong, maybe because the way I'm doing them is based originally on OpenSSL 0.9.8. I'm currently moving from 1.0.2 to 1.1.1, which is why the questions are coming up. I won't get into the details of my application as it's complex, but it can act as a client or a server. The case we are worried about is obviously when it's acting as a client. I thought the standard way of dealing with these type of errors was with setting a verify_callback() function, which is part of the description below. I set up an X509_STORE object and then cycle through all of the certificate files in /etc/ssl/certs/, open them, and call PEM_read_X509() to get an X509 (certificate) object and then call X509_STORE_add_cert(x509_stor, certificate) to read the certificates into my trusted store, X509_store object. Then when I create an SSL CTX, I call SSL_CTX_set_cert_store() to set the X509_store object for the CTX. I also call SSL_set_verify( ,SSL_VERIFY_PEER,verify_callback) with the SSL object created from that CTX to set the verify_callback() function for each user that will act as a client. If the user of this CTX is acting as a client and the server presents a certificate chain, and my trusted store has the root, the connection will work, as the chain is verified and trusted. If the server presents a self-signed certificate, the verify_callback() function is invoked with the error 18/X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT, but if I search for and find the self-signed cert in my trusted store, I clear the error and let the connection proceed. The scenario is very similar for the case I asked about, the only difference is I'm presented a 2 certs in a chain, and I have the intermediate cert in my store. My understanding was the verify_callback() is the correct place to handle these cases. >From Victor's response, I don't know what a custom X509_STORE type is or how to set one up. Likewise, I don't know how to use the "partial chain" flag and what API I need to load intermediate certificates into my trusted store(other than what I describe above). Because of the way certificates are distributed, I can't always rely on having the root in the trusted store, so I'll need to trust some intermediate certs, provided they are valid, actually signed the end-entity cert, etc. Let me know if I am off track, and if so, what APIs I should be looking at, especially if there are been changes in this area. Thanks. ________________________________ From: openssl-users on behalf of Viktor Dukhovni Sent: Monday, March 30, 2020 6:17 PM To: openssl-users at openssl.org Subject: Re: Peer certificate verification in verify_callback On Thu, Mar 05, 2020 at 02:04:27PM +0000, Jason Schultz wrote: > I have some questions about my application?s verify_callback() function and how I handle some of the OpenSSL errors. You're going about this the wrong way. Instead of tryign (likely insecurely) to patch up verification errors in a verify callback, if you have a certificate store that is not directly supported by OpenSSL, you need to implement your own custom X509_STORE type, associate that store with the SSL_CTX and have OpenSSL's built-in certificate verification search that store for you. If you also want to directly trust intermediate certificates that are not self-signed roots, you can either set the "partial chain" flag, or load into your store intermediate certificates with auxiliary trust settings (aka "TRUSTED CERTIFICATES"), which will then be trusted without chaining to a root, but simpler to just add the roots to the store. -- Viktor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Mar 30 21:19:03 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 30 Mar 2020 17:19:03 -0400 Subject: Peer certificate verification in verify_callback In-Reply-To: References: <20200330181723.GR41308@straasha.imrryr.org> Message-ID: <20200330211903.GU41308@straasha.imrryr.org> On Mon, Mar 30, 2020 at 09:02:47PM +0000, Jason Schultz wrote: > I won't get into the details of my application as it's complex, but it > can act as a client or a server. The case we are worried about is > obviously when it's acting as a client. I thought the standard way of > dealing with these type of errors was with setting a verify_callback() > function, which is part of the description below. The verify callback is mostly for logging and error reporting. It is not intended to supplant the built-in verification logic. While it can be used to ignore some errors, that's generally quite risky and difficult to do correctly. You should strive to arrange for the built-in verification to succeed, rather than attempt to work around the resulting errors when it does not. > I set up an X509_STORE object and then cycle through all of the > certificate files in /etc/ssl/certs/, open them, and call > PEM_read_X509() to get an X509 (certificate) object and then call > X509_STORE_add_cert(x509_stor, certificate) to read the certificates > into my trusted store, X509_store object. It would be far simpler to concatenate them into a single CAfile, or use "c_rehash" to create the symlinks need to make the directory into a workable CApath. You should not have to manually load them into your own store, although doing the latter potentially gives you the opportunity to decorate them with auxiliary trust EKUs. > If the user of this CTX is acting as a client and the server presents > a certificate chain, and my trusted store has the root, the connection > will work, as the chain is verified and trusted. With the partial chain flag it can also work when the EE cert is present (verbatim) in the store, or an intermediate CA is present in the store. > If the server presents a self-signed certificate, the > verify_callback() function is invoked with the error > > 18/X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT, but if I search for and find the self-signed cert in my trusted store, I clear the error and let the > connection proceed. With 1.0.2 and later, the partial chain flag makes this work-around unnecessary. > The scenario is very similar for the case I asked about, the only difference is I'm presented a 2 certs in a chain, and I have the > intermediate cert in my store. My understanding was the verify_callback() is the correct place to handle these cases. No, it is not. > From Victor's response, I don't know what a custom X509_STORE type is > or how to set one up. You're already populating a custom store (though not a store type, which it does not look like you need since your store is just a directory full of PEM files). > Likewise, I don't know how to use the "partial chain" flag See X509_VERIFY_PARAM_set_flags(3). > and what API I need to load intermediate certificates into my trusted > store(other than what I describe above). Because of the way > certificates are distributed, I can't always rely on having the root > in the trusted store, so I'll need to trust some intermediate certs, > provided they are valid, actually signed the end-entity cert, etc. You just need to add them to the store, simplest is a CAfile or a hashed CApath. -- Viktor. From jetson23 at hotmail.com Mon Mar 30 21:51:15 2020 From: jetson23 at hotmail.com (Jason Schultz) Date: Mon, 30 Mar 2020 21:51:15 +0000 Subject: Peer certificate verification in verify_callback In-Reply-To: <20200330211903.GU41308@straasha.imrryr.org> References: <20200330181723.GR41308@straasha.imrryr.org> , <20200330211903.GU41308@straasha.imrryr.org> Message-ID: Thanks Victor. I need to look at X509_VERIFY_PARAM_set_flags() a little closer, but I think I understand what I need to do. I also can't concatenate all my trusted certificates into a single file, there are dozens of certificates in the trusted store. Our users can also manipulate the trusted store, so the trusted certificates will always be in PEM files in /etc/ssl/certs/. It sounds like that's not going to hold me back from accomplishing what I need to do though, but I'll pursue this and let the list know if I run into any other issues. Thanks again, Jason ________________________________ From: openssl-users on behalf of Viktor Dukhovni Sent: Monday, March 30, 2020 9:19 PM To: openssl-users at openssl.org Subject: Re: Peer certificate verification in verify_callback On Mon, Mar 30, 2020 at 09:02:47PM +0000, Jason Schultz wrote: > I won't get into the details of my application as it's complex, but it > can act as a client or a server. The case we are worried about is > obviously when it's acting as a client. I thought the standard way of > dealing with these type of errors was with setting a verify_callback() > function, which is part of the description below. The verify callback is mostly for logging and error reporting. It is not intended to supplant the built-in verification logic. While it can be used to ignore some errors, that's generally quite risky and difficult to do correctly. You should strive to arrange for the built-in verification to succeed, rather than attempt to work around the resulting errors when it does not. > I set up an X509_STORE object and then cycle through all of the > certificate files in /etc/ssl/certs/, open them, and call > PEM_read_X509() to get an X509 (certificate) object and then call > X509_STORE_add_cert(x509_stor, certificate) to read the certificates > into my trusted store, X509_store object. It would be far simpler to concatenate them into a single CAfile, or use "c_rehash" to create the symlinks need to make the directory into a workable CApath. You should not have to manually load them into your own store, although doing the latter potentially gives you the opportunity to decorate them with auxiliary trust EKUs. > If the user of this CTX is acting as a client and the server presents > a certificate chain, and my trusted store has the root, the connection > will work, as the chain is verified and trusted. With the partial chain flag it can also work when the EE cert is present (verbatim) in the store, or an intermediate CA is present in the store. > If the server presents a self-signed certificate, the > verify_callback() function is invoked with the error > > 18/X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT, but if I search for and find the self-signed cert in my trusted store, I clear the error and let the > connection proceed. With 1.0.2 and later, the partial chain flag makes this work-around unnecessary. > The scenario is very similar for the case I asked about, the only difference is I'm presented a 2 certs in a chain, and I have the > intermediate cert in my store. My understanding was the verify_callback() is the correct place to handle these cases. No, it is not. > From Victor's response, I don't know what a custom X509_STORE type is > or how to set one up. You're already populating a custom store (though not a store type, which it does not look like you need since your store is just a directory full of PEM files). > Likewise, I don't know how to use the "partial chain" flag See X509_VERIFY_PARAM_set_flags(3). > and what API I need to load intermediate certificates into my trusted > store(other than what I describe above). Because of the way > certificates are distributed, I can't always rely on having the root > in the trusted store, so I'll need to trust some intermediate certs, > provided they are valid, actually signed the end-entity cert, etc. You just need to add them to the store, simplest is a CAfile or a hashed CApath. -- Viktor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Pleger at cs.uni-dortmund.de Tue Mar 31 09:27:27 2020 From: Christoph.Pleger at cs.uni-dortmund.de (Christoph Pleger) Date: Tue, 31 Mar 2020 11:27:27 +0200 Subject: Program works with older libssl, but not with newer Message-ID: <24780758.vnQNS8qAr1@superstar> Hello, I have here a self-written server program and the corresponding self-written client program. These run well together with libssl 1.1.0l, but with libssl 1.1.1d, the same programs give errors SSL_ERROR_SYSCALL in SSL_read(), no matter if I recompile the programs and then run them, or just replace libssl with the newer version. So, I want to ask if there are any known incompabilities in the libssl versions that require me to change the code of the programs, or if there is any known bug in libssl1.1.1d that may cause the mentioned errors. Regards Christoph From balazs.horvath.email at gmail.com Tue Mar 31 09:56:03 2020 From: balazs.horvath.email at gmail.com (=?UTF-8?B?QmFsw6F6cyBIb3J2w6F0aA==?=) Date: Tue, 31 Mar 2020 11:56:03 +0200 Subject: New inlcudes needed for OpenSSL V1.1.1 sockets In-Reply-To: References: Message-ID: Thanks for Your answer! I was not clearly describing our problem, sorry! Our project is for embedded devices running on MIPS processors. The system has a special OS, not Linux. The development system is under Linux, and we are compiling OpenSSL with cross compile option for MIPS. We also compile the code for Linux, so that we have a simulation of the embedded system, that can be easily debugged under Linux. Our problem is, that the OpenSSL V1.1.1d needs includes, that are nonexistent for MIPS in our development system. These headers were not needed for 1.0.2. My question is not a 100% OpenSSL question. But I think, as OpenSSL is widely used on non-Linux/Windows/? systems, the question is legitime to ask, what to use on special systems? Or why are these headers needed now? The programmer, who changed the code, probably had an idea about that. Best regards, Balazs Michael Wojcik ezt ?rta (id?pont: 2020. m?rc. 30., H, 20:20): > From: openssl-users on behalf of > Bal?zs Horv?th > Sent: Monday, March 30, 2020 10:00 > > > Following extra includes are needed: > > arpa/inet.h > > netinet/tcp.h > > netinet/in.h > > strings.h > > netdb.h > > sys/socket.h > > sys/ioctl.h > > sys/un.h > > These are system headers, not OpenSSL headers. OpenSSL has no control over > them. > > > For Linux the includes under /usr/include work, but for MIPS they > give compile errors. > > Then you're using the wrong headers for the MIPS compilation. To be > honest, it's not clear to me what you're doing, because Linux is an > operating system (or more precisely a kernel), and MIPS is a processor > family. > > > What should we use for MIPS? > > This is not an OpenSSL question. It's a cross-compilation question (I > think, since I'm not sure what you're actually trying to do), and so > depends on your cross-compilation toolchain. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Mar 31 09:58:00 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 31 Mar 2020 05:58:00 -0400 Subject: Program works with older libssl, but not with newer In-Reply-To: <24780758.vnQNS8qAr1@superstar> References: <24780758.vnQNS8qAr1@superstar> Message-ID: <20200331095800.GZ41308@straasha.imrryr.org> On Tue, Mar 31, 2020 at 11:27:27AM +0200, Christoph Pleger wrote: > I have here a self-written server program and the corresponding self-written > client program. These run well together with libssl 1.1.0l, but with libssl > 1.1.1d, the same programs give errors SSL_ERROR_SYSCALL in SSL_read(), no > matter if I recompile the programs and then run them, or just replace libssl > with the newer version. OpenSSL 1.1.1 supports TLS 1.3, which OpenSSL 1.1.0 did not. > So, I want to ask if there are any known incompabilities in the libssl > versions that require me to change the code of the programs, or if there is > any known bug in libssl1.1.1d that may cause the mentioned errors. Use of TLS 1.3 changes the communication patterns of the TLS protocol in some non-trivial ways, and, if your application were fragile, it might have gotten by with TLS 1.2, but the latent bugs could show up with TLS 1.3. You can test with TLS 1.3 disabled and see whether the makes a difference. If it does, you will then need to debug your program and see where it fails with TLS 1.3. There are other improvements and bug fixes, but no known fundamental obstacles to running robustly implemented clients built for 1.1.0 against 1.1.1 libraries. -- Viktor. From paul.dale at oracle.com Tue Mar 31 10:07:27 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Tue, 31 Mar 2020 20:07:27 +1000 Subject: New inlcudes needed for OpenSSL V1.1.1 sockets In-Reply-To: References: Message-ID: All of the include files mentioned are standard ones which have always been used. You are building 1.1.1 differently to 1.0.2. Debug your build environment first. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 31 Mar 2020, at 7:56 pm, Bal?zs Horv?th wrote: > > Thanks for Your answer! > > I was not clearly describing our problem, sorry! Our project is for embedded devices running on MIPS processors. The system has a special OS, not Linux. > The development system is under Linux, and we are compiling OpenSSL with cross compile option for MIPS. We also compile the code for Linux, so that we have a simulation of the embedded system, that can be easily debugged under Linux. > Our problem is, that the OpenSSL V1.1.1d needs includes, that are nonexistent for MIPS in our development system. These headers were not needed for 1.0.2. > > My question is not a 100% OpenSSL question. But I think, as OpenSSL is widely used on non-Linux/Windows/? systems, the question is legitime to ask, what to use on special systems? Or why are these headers needed now? > The programmer, who changed the code, probably had an idea about that. > > Best regards, > Balazs > > Michael Wojcik > ezt ?rta (id?pont: 2020. m?rc. 30., H, 20:20): > From: openssl-users > on behalf of Bal?zs Horv?th > > Sent: Monday, March 30, 2020 10:00 > > > Following extra includes are needed: > > arpa/inet.h > > netinet/tcp.h > > netinet/in.h > > strings.h > > netdb.h > > sys/socket.h > > sys/ioctl.h > > sys/un.h > > These are system headers, not OpenSSL headers. OpenSSL has no control over them. > > > For Linux the includes under /usr/include work, but for MIPS they give compile errors. > > Then you're using the wrong headers for the MIPS compilation. To be honest, it's not clear to me what you're doing, because Linux is an operating system (or more precisely a kernel), and MIPS is a processor family. > > > What should we use for MIPS? > > This is not an OpenSSL question. It's a cross-compilation question (I think, since I'm not sure what you're actually trying to do), and so depends on your cross-compilation toolchain. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Tue Mar 31 12:57:30 2020 From: openssl at openssl.org (OpenSSL) Date: Tue, 31 Mar 2020 12:57:30 +0000 Subject: OpenSSL version 1.1.1f published Message-ID: <20200331125730.GA13462@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.1f released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1f of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1f is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1f.tar.gz Size: 9792828 SHA1 checksum: 238e001ea1fbf19ede43e36209c37c1a636bb51f SHA256 checksum: 186c6bfe6ecfba7a5b48c47f8a1673d0f3b0e5ba2e25602dd23b629975da3f35 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1f.tar.gz openssl sha256 openssl-1.1.1f.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6DNO8ACgkQ2cTSbQ5g RJFAHAf/c5tRSC8FNTAwXj8pEniovI/XeIHgyJG37mKXt2V5ziXwCaJCTs6Tdvth b7nGgcqHWmqTdDlYdOzhexWOESfCTEhipmh1E9wHX/fntadHn0LwzfXBIbE6CsW5 ksn2bXXHTLuY3E8GWzmdcDDZ6sjsAYCsfE6rnJqgPKl8+XqZsjlrMBLc1iXa7pvR CMNmJ5ITo98OlqtFRsmR0G7nXCwm4NLGCv9DojfR5gfyoUWZZXInyZZ3RReZEwoH fGRObO3/5E80+TxFJda8uDM0dSHUPzXJ7JA+h+uQRG+PGwXe4R8jZ8BJfjfVvmuk d72zRaRwkGrHvCo93S8xI8W2jBAqHQ== =TvT8 -----END PGP SIGNATURE----- From rsalz at akamai.com Tue Mar 31 14:21:53 2020 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 31 Mar 2020 14:21:53 +0000 Subject: Program works with older libssl, but not with newer In-Reply-To: <20200331095800.GZ41308@straasha.imrryr.org> References: <24780758.vnQNS8qAr1@superstar> <20200331095800.GZ41308@straasha.imrryr.org> Message-ID: Isn't this the SSL EOF thing? From matt at openssl.org Tue Mar 31 14:31:20 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 31 Mar 2020 15:31:20 +0100 Subject: Program works with older libssl, but not with newer In-Reply-To: References: <24780758.vnQNS8qAr1@superstar> <20200331095800.GZ41308@straasha.imrryr.org> Message-ID: On 31/03/2020 15:21, Salz, Rich via openssl-users wrote: > Isn't this the SSL EOF thing? No. In older OpenSSL's SSL_read() would return SSL_ERROR_SYSCALL on EOF with an errno of 0. This was "fixed" in 1.1.1e to return SSL_ERROR_SSL with an entry on the error stack. And unfixed in 1.1.1f to revert to the old behaviour (but 3.0 still does this). So - if it was due to "the SSL EOF thing" then you would be seeing SSL_ERROR_SSL. Matt From Christoph.Pleger at cs.uni-dortmund.de Tue Mar 31 14:51:32 2020 From: Christoph.Pleger at cs.uni-dortmund.de (Christoph Pleger) Date: Tue, 31 Mar 2020 16:51:32 +0200 Subject: Program works with older libssl, but not with newer In-Reply-To: <20200331095800.GZ41308@straasha.imrryr.org> References: <24780758.vnQNS8qAr1@superstar> <20200331095800.GZ41308@straasha.imrryr.org> Message-ID: <32365563.SdEH99cIJO@superstar> Hello, > > I have here a self-written server program and the corresponding > > self-written client program. These run well together with libssl 1.1.0l, > > but with libssl 1.1.1d, the same programs give errors SSL_ERROR_SYSCALL > > in SSL_read(), no matter if I recompile the programs and then run them, > > or just replace libssl with the newer version. > > OpenSSL 1.1.1 supports TLS 1.3, which OpenSSL 1.1.0 did not. > > > So, I want to ask if there are any known incompabilities in the libssl > > versions that require me to change the code of the programs, or if there > > is > > any known bug in libssl1.1.1d that may cause the mentioned errors. > > Use of TLS 1.3 changes the communication patterns of the TLS protocol in > some non-trivial ways, and, if your application were fragile, it might > have gotten by with TLS 1.2, but the latent bugs could show up with TLS > 1.3. Now, I replaced TLS_server_method() and TLS_client_method() with TLSv1_2_server_method() and TLSv1_2_client_method() respectively, and the same error occurs. Regards Christoph From openssl-users at dukhovni.org Tue Mar 31 17:42:09 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 31 Mar 2020 13:42:09 -0400 Subject: Program works with older libssl, but not with newer In-Reply-To: <32365563.SdEH99cIJO@superstar> References: <24780758.vnQNS8qAr1@superstar> <20200331095800.GZ41308@straasha.imrryr.org> <32365563.SdEH99cIJO@superstar> Message-ID: <20200331174209.GA41308@straasha.imrryr.org> On Tue, Mar 31, 2020 at 04:51:32PM +0200, Christoph Pleger wrote: > > > I have here a self-written server program and the corresponding > > > self-written client program. These run well together with libssl 1.1.0l, > > > but with libssl 1.1.1d, the same programs give errors SSL_ERROR_SYSCALL > > > in SSL_read(), no matter if I recompile the programs and then run them, > > > or just replace libssl with the newer version. > > > > OpenSSL 1.1.1 supports TLS 1.3, which OpenSSL 1.1.0 did not. > > > > > So, I want to ask if there are any known incompabilities in the libssl > > > versions that require me to change the code of the programs, or if there > > > is > > > any known bug in libssl1.1.1d that may cause the mentioned errors. > > > > Use of TLS 1.3 changes the communication patterns of the TLS protocol in > > some non-trivial ways, and, if your application were fragile, it might > > have gotten by with TLS 1.2, but the latent bugs could show up with TLS > > 1.3. > > Now, I replaced TLS_server_method() and TLS_client_method() with > TLSv1_2_server_method() and TLSv1_2_client_method() respectively, and the same > error occurs. Well, in that case, you need to provide more detail. Does the handshake complete? If not, at what stage does it fail? A PCAP file may be needed. And you need to explain what operation fails with SSL_ERROR_SYSCALL, and do an "strace" or equivalent to understand what the relevant socket read calls returned. -- Viktor.