From mann.patidar at gmail.com Thu Jan 2 04:11:58 2020 From: mann.patidar at gmail.com (Manish Patidar) Date: Thu, 2 Jan 2020 09:41:58 +0530 Subject: Doubts between libfips.a and fips.so in openssl3.0 Message-ID: Hi What is the difference in libfips.a and fips.so.? Selftest.c and fipsprov.c is extra in fips.so library compilation. Does it mean that it just add provider entry function and self test, which is required for fips certification.? Once openssl3.0 is fips certified, can we use libfips.a directly ? My requirement is to use fips certified algorithm but environment may not have capability to load dynamic library, so just thinking how openssl3.0 should be used? Regards Manish -------------- next part -------------- An HTML attachment was scrubbed... URL: From hareesh.sai at gmail.com Thu Jan 2 05:11:04 2020 From: hareesh.sai at gmail.com (Hareesh D) Date: Thu, 2 Jan 2020 10:41:04 +0530 Subject: openssl-fips-2.0.16 : RSA key generation !! In-Reply-To: References: Message-ID: Hi, In the openssl-fips-2.0.16 version, I see that some validations are missing (generating probable primes P, Q as part of RSA key generation) which are mentioned in NIST.FIPS.186-4.pdf. B.3.3 -> Process : Points 4.4, 4.7, 5.4, 5.5 and 5.8. Can someone please confirm this behaviour. Thanks !! -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Thu Jan 2 07:32:51 2020 From: paul.dale at oracle.com (Dr Paul Dale) Date: Thu, 2 Jan 2020 17:32:51 +1000 Subject: openssl-fips-2.0.16 : RSA key generation !! In-Reply-To: References: Message-ID: <588CD5CF-D8E7-4DC0-9D4A-F41BBA1D54D5@oracle.com> There are transitions ahead to remove FIPS 186-2 as a standard. At the moment all is good, later in this year some things will disappear and be invalid. The OpenSSL project is aware of the situation but has not yet made a decision about the path to follow. One thing we can say is that the old FOM will not be revalidated. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 2 Jan 2020, at 3:11 pm, Hareesh D wrote: > > Hi, > > In the openssl-fips-2.0.16 version, I see that some validations are missing (generating probable primes P, Q as part of RSA key generation) which are mentioned in NIST.FIPS.186-4.pdf. > > B.3.3 -> Process : Points 4.4, 4.7, 5.4, 5.5 and 5.8. > > Can someone please confirm this behaviour. > > Thanks !! -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jan 2 09:57:52 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 2 Jan 2020 09:57:52 +0000 Subject: Doubts between libfips.a and fips.so in openssl3.0 In-Reply-To: References: Message-ID: <8b0ba322-23e3-fa91-ab23-d0224c81a358@openssl.org> On 02/01/2020 04:11, Manish Patidar wrote: > Hi > > What is the difference in libfips.a and fips.so.?? > Selftest.c and fipsprov.c is extra in fips.so library compilation.? Does > it mean that it just add provider entry function and self test, which is > required for fips certification.? libfips.a is just an internal build artifact. The actual module itself is fips.so. > Once openssl3.0 is fips certified,? can we use libfips.a directly ? No. Applications will use libcrypto/libssl, and OpenSSL will internally load fips.so as required. > My requirement is to use fips certified algorithm but environment may > not have capability to load dynamic library, so just thinking how > openssl3.0 should be used? Unfortunately in the 3.0 design you *must* use dynamic libraries. Static linking for fips usage will not be possible. Matt From hkario at redhat.com Thu Jan 2 10:21:11 2020 From: hkario at redhat.com (Hubert Kario) Date: Thu, 02 Jan 2020 11:21:11 +0100 Subject: X25519 Unlisted by =?iso-8859-1?Q?-list=5Fcurves_and_Any_Trusted_Python_Code_for_X, _Y_Coordi?= =?iso-8859-1?Q?nates?= In-Reply-To: <94DF060A-2079-4E2A-9CBB-3067590FCEA1@akamai.com> References: <329198284.2186653.1577245769159.ref@mail.yahoo.com> <329198284.2186653.1577245769159@mail.yahoo.com> <94DF060A-2079-4E2A-9CBB-3067590FCEA1@akamai.com> Message-ID: <660e9bf6-d318-4eef-972e-b9fa0554f10f@redhat.com> On Thursday, 26 December 2019 00:50:29 CET, Salz, Rich via openssl-users wrote: > * I want to us ECDSA for my Web server's SSL certificate > via an ACME client to Let's Encrypt and maybe later BuyPass. > > That?s fine. > > > * I thought that EC is better than RSA, but now I don't > think so. The answer seems to be: it depends. > > There are trade-offs. The biggest one is that EC gives > equivalent security with a much smaller keysize. > > > * Safe Curves (SafeCurves: > Introduction) > says ? > > FWIW, SafeCurves is mostly the guy behind 25519 :) This is not > a slam against djb, who?s kinda brilliant. > > If you?re not sure what to do, perhaps follow what the browsers > do. That way if something?s wrong you?ll just be going up in > flames with the rest of the world. > > If you don?t trust the NSA and therefore don?t trust NIST, do > you accept AES? What about when they approve 25519? there's also the difference between a "is the curve a safe generic cryptographic primitive?" and "is the curve safe when used in X.509 and TLS?" -- 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 bkaduk at akamai.com Fri Jan 3 19:48:49 2020 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 3 Jan 2020 11:48:49 -0800 Subject: SSL_set_client_CA_list(ssl, NULL) problem? In-Reply-To: <20191124110534.GA57849@kiel.esmtp.org> References: <20191121193703.GA99944@kiel.esmtp.org> <20191124110534.GA57849@kiel.esmtp.org> Message-ID: <20200103194848.GF21740@akamai.com> Sorry for the very late response... On Sun, Nov 24, 2019 at 12:05:34PM +0100, Claus Assmann wrote: > Seems it is impossible to override the list with NULL for SSL, as > the code will then use the list from CTX (if my limited understanding > of the code is correct): > > STACK_OF(X509_NAME) *SSL_get_client_CA_list(const SSL *s) > { > ... > if (s->client_CA != NULL) > return (s->client_CA); > else > return (s->ctx->client_CA); > > Is this intentional? The man pages says: Yes. > SSL_set_client_CA_list() sets the list of CAs sent to the client when > requesting a client certificate for the chosen ssl, overriding the > setting valid for ssl's SSL_CTX object. > > > IMHO there should be some indication (flag) that the value from SSL > should be used (to distinguish between the ways NULL is used: "this > is NULL because of the initialization" and "this is explicitly set > to NULL"). You should be able to set a "zero-length list" (which is a non-NULL pointer value) in order to get your desired behavior. -Ben From jblaz2019 at gmail.com Tue Jan 7 13:21:54 2020 From: jblaz2019 at gmail.com (Jerry Blasdel) Date: Tue, 7 Jan 2020 07:21:54 -0600 Subject: intermittent Apache/OpenSSL error hangs server Message-ID: I have several servers configured the same, running Apache 2.4X/OpenSSL1.02 fips-enabled. On one server we periodically get the following errors in the Apache logs: SSL Library Error: error:xxxxxx:FIPS_drbg_generate:selftest failed. In some cases, the server continues to service requests, but in other cases the server hangs and will not process requests until the worker pid receiving the error is killed, or a kill -HUP is issues on the Apache root pid. I see someone else had a similar issue but I can't find any resolution. https://mta.openssl.org/pipermail/openssl-users/2016-October/004657.html Other information... We have looked at the entropy on the server when it is working properly vs when it hangs and could not find any big differences. Also, SSLRandomSeed is configured for startup and connect in Apache. Any help would be appreciated. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From ca+ssl-users at esmtp.org Thu Jan 9 05:52:05 2020 From: ca+ssl-users at esmtp.org (Claus Assmann) Date: Thu, 9 Jan 2020 06:52:05 +0100 Subject: SSL_set_client_CA_list(ssl, NULL) problem? In-Reply-To: <20200103194848.GF21740@akamai.com> References: <20191121193703.GA99944@kiel.esmtp.org> <20191124110534.GA57849@kiel.esmtp.org> <20200103194848.GF21740@akamai.com> Message-ID: <20200109055205.GA78845@kiel.esmtp.org> On Fri, Jan 03, 2020, Benjamin Kaduk via openssl-users wrote: > On Sun, Nov 24, 2019 at 12:05:34PM +0100, Claus Assmann wrote: > > Seems it is impossible to override the list with NULL for SSL, as > > the code will then use the list from CTX (if my limited understanding > > Is this intentional? The man pages says: > Yes. Then it would be nice to document this in the man page by adding some text based on this: > You should be able to set a "zero-length list" (which is a non-NULL pointer > value) in order to get your desired behavior. to it, e.g., SSL_set_client_CA_list() sets the list of CAs sent to the client when requesting a client certificate for the chosen ssl, overriding the setting valid for ssl's SSL_CTX object. Note: to clear the CA list an empty stack must be passed as argument (not NULL), e.g., STACK_OF(X509_NAME) *certs; certs = sk_X509_NAME_new_null(); /* handle NULL result */ SSL_CTX_set_client_CA_list(ssl, certs ; I did a brief test and it seems to work, thanks! From Chethan.Kumar at toshiba-tsip.com Thu Jan 9 06:42:36 2020 From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar) Date: Thu, 9 Jan 2020 06:42:36 +0000 Subject: Default certificate path taken by openssl Message-ID: <936e1e4959cc4c31be4ba2ad096bba27@toshiba-tsip.com> Hi all, Need your help in quesry related to certificate used by openssl. In Linux, if any application which uses openssl does not specify the path from which certificates should be read by openssl, does openssl try to read from default path or something? Need help in this as there is one ca-bundle.crt(\usr\lib\ssl\certs\ca-bundle.crt)" file in machine and we use our own ca-bundle.crt in another path. Is it ok to remove \usr\lib\ssl\certs\ca-bundle.crt file if we don't use this? Thanks in advance, Chethan Kumar The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Jan 9 07:04:33 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 9 Jan 2020 02:04:33 -0500 Subject: Default certificate path taken by openssl In-Reply-To: <936e1e4959cc4c31be4ba2ad096bba27@toshiba-tsip.com> References: <936e1e4959cc4c31be4ba2ad096bba27@toshiba-tsip.com> Message-ID: <20200109070433.GC73491@straasha.imrryr.org> On Thu, Jan 09, 2020 at 06:42:36AM +0000, Chethan Kumar wrote: > In Linux, if any application which uses openssl does not specify the > path from which certificates should be read by openssl, does openssl > try to read from default path or something? OpenSSL has a default cert store path, but it is up to applications to request use of the default paths for certificate validation. Many do, some don't. > Need help in this as there is one > ca-bundle.crt(\usr\lib\ssl\certs\ca-bundle.crt)" file in machine and > we use our own ca-bundle.crt in another path. Is this a Linux machine or a Windows machine? You're using backslash as a path separator, which is not something that Works on POSIX systems (e.g. Linux). > Is it ok to remove \usr\lib\ssl\certs\ca-bundle.crt file if we don't use this? You can remove whatever you want, but if it is installed by an OS package, something might break if you do. This question is best asked of your Linux vendor, the upstream OpenSSL project does not bundle any trusted certificates. -- Viktor. From Chethan.Kumar at toshiba-tsip.com Thu Jan 9 08:49:37 2020 From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar) Date: Thu, 9 Jan 2020 08:49:37 +0000 Subject: Default certificate path taken by openssl In-Reply-To: <20200109070433.GC73491@straasha.imrryr.org> References: <936e1e4959cc4c31be4ba2ad096bba27@toshiba-tsip.com> <20200109070433.GC73491@straasha.imrryr.org> Message-ID: <22335720d00f401494f4a358de3cde2e@toshiba-tsip.com> Hi Viktor, Thank you for the information. It was helpful. With Regards, Chethan Kumar -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Thursday, January 9, 2020 12:35 PM To: openssl-users at openssl.org Subject: Re: Default certificate path taken by openssl On Thu, Jan 09, 2020 at 06:42:36AM +0000, Chethan Kumar wrote: > In Linux, if any application which uses openssl does not specify the > path from which certificates should be read by openssl, does openssl > try to read from default path or something? OpenSSL has a default cert store path, but it is up to applications to request use of the default paths for certificate validation. Many do, some don't. > Need help in this as there is one > ca-bundle.crt(\usr\lib\ssl\certs\ca-bundle.crt)" file in machine and > we use our own ca-bundle.crt in another path. Is this a Linux machine or a Windows machine? You're using backslash as a path separator, which is not something that Works on POSIX systems (e.g. Linux). > Is it ok to remove \usr\lib\ssl\certs\ca-bundle.crt file if we don't use this? You can remove whatever you want, but if it is installed by an OS package, something might break if you do. This question is best asked of your Linux vendor, the upstream OpenSSL project does not bundle any trusted certificates. -- Viktor. The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use. From engr.abhiarora at gmail.com Thu Jan 9 13:57:25 2020 From: engr.abhiarora at gmail.com (Abhi Arora) Date: Thu, 9 Jan 2020 19:27:25 +0530 Subject: Fwd: Disabling SSL Issue Date Validation In-Reply-To: References: Message-ID: I am trying to disable Server's Certificate Issue Date Validation in libcurl. For that, I have registered a own_verify_callback function by calling SSL_CTX_set_verify in sslContextVerify callback (set via curl_easy_setopt(curl, CURLOPT_SSL_CTX_FUNCTION, sslContextVerify)). The "own_verify_callback" gets called (I have print in this function and they are printed on console) and it returns 1 but still curl connection fails (i.e., curl_easy_perform returns with an error) with error "SSL certificate verify result: certificate is not yet valid (9)". However, it should allow the connection. I have set the system's date and time to 1990 and I was testing the Issue Date Validation. Looks like there is a bug in libcurl or I am missing something important?. Is there something I am doing wrong or is it a well-known bug? My code is below: https://stackoverflow.com/questions/59662414/disabling-ssl-issue-date-validation-in-libcurl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jblaz2019 at gmail.com Thu Jan 9 16:42:47 2020 From: jblaz2019 at gmail.com (Jerry Blasdel) Date: Thu, 9 Jan 2020 10:42:47 -0600 Subject: intermittent Apache/OpenSSL error hangs server In-Reply-To: References: Message-ID: Here is more information. On the server that is having this issue, prior to the FIPS_drbg_generate errors (these show up every time that worker pid is selected to serve a request) we have a single OpenSSL error that shows up in the logs. SSL Library Error: error:2D06A07F: FIPS routines: FIPS_CHECK_EC:pairwise test failed Once we get that error, every time we try to serve a request in Apache using that pid, it errors out. So, it seems like something randomly corrupts that PID. Can someone provide some information about FIPS_CHECK_EC: pairwise test failed. Thanks On Tue, Jan 7, 2020 at 7:21 AM Jerry Blasdel wrote: > I have several servers configured the same, running Apache > 2.4X/OpenSSL1.02 fips-enabled. > > On one server we periodically get the following errors in the Apache logs: > > SSL Library Error: error:xxxxxx:FIPS_drbg_generate:selftest failed. In > some cases, the server continues to service requests, but in other cases > the server hangs and will not process requests until the worker pid > receiving the error is killed, or a kill -HUP is issues on the Apache root > pid. > > I see someone else had a similar issue but I can't find any resolution. > > https://mta.openssl.org/pipermail/openssl-users/2016-October/004657.html > > Other information... > > We have looked at the entropy on the server when it is working properly vs > when it hangs and could not find any big differences. > > Also, SSLRandomSeed is configured for startup and connect in Apache. > > Any help would be appreciated. > > Thanks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Jan 9 18:00:53 2020 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 9 Jan 2020 18:00:53 +0000 Subject: intermittent Apache/OpenSSL error hangs server In-Reply-To: References: Message-ID: <7B0AB543-8856-4C0D-A1BF-44CDA942E5AC@akamai.com> >Once we get that error, every time we try to serve a request in Apache using that pid, it errors out. So, it seems like something randomly corrupts that PID. Can someone provide some information about FIPS_CHECK_EC: pairwise test failed. Once FIPS detects an error, it will stay stuck in error-state until you re-initialize. Sorry, can?t provide more details about the specific test that?s failing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkario at redhat.com Thu Jan 9 18:48:22 2020 From: hkario at redhat.com (Hubert Kario) Date: Thu, 09 Jan 2020 19:48:22 +0100 Subject: intermittent Apache/OpenSSL error hangs server In-Reply-To: References: Message-ID: <6fe025f8-ccee-4382-9f62-8de1ac8bcc64@redhat.com> On Thursday, 9 January 2020 17:42:47 CET, Jerry Blasdel wrote: > Here is more information. On the server that is having this issue, prior > to the FIPS_drbg_generate errors (these show up every time that worker pid > is selected to serve a request) we have a single OpenSSL error that shows > up in the logs. > > SSL Library Error: error:2D06A07F: FIPS routines: FIPS_CHECK_EC:pairwise > test failed > > Once we get that error, every time we try to serve a request in Apache > using that pid, it errors out. So, it seems like something randomly > corrupts that PID. Can someone provide some information about > FIPS_CHECK_EC: pairwise test failed. I would try to eliminate hardware issue as a possible cause: run memcheck, cpu stress tests, etc. > Thanks > > On Tue, Jan 7, 2020 at 7:21 AM Jerry Blasdel wrote: > >> I have several servers configured the same, running Apache >> 2.4X/OpenSSL1.02 fips-enabled. >> >> On one server we periodically get the following errors in the Apache logs: >> >> SSL Library Error: error:xxxxxx:FIPS_drbg_generate:selftest failed. In >> some cases, the server continues to service requests, but in >> other cases ... > > -- 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 openssl-dev at ml.breakpoint.cc Fri Jan 10 22:41:20 2020 From: openssl-dev at ml.breakpoint.cc (Sebastian Andrzej Siewior) Date: Fri, 10 Jan 2020 23:41:20 +0100 Subject: Enforcing group / key_share order in TLS1.3 Message-ID: <20200110224120.aqeldlex7dv3sw4j@flow> Hi, gnutls-cli sends by default (in the supported groups extension) `secp256r1' first and later `x25519'. The key_share extension contains a key for both types. The server has both types configured both groups and `x25519' comes first. The handshake however ends up with `secp256r1'. Is there a way to tell openssl to prefer `x25519' over `secp256r1'? Sebastian From andras at frontfoo.com Sat Jan 11 16:15:15 2020 From: andras at frontfoo.com (Andras Horvath) Date: Sat, 11 Jan 2020 16:15:15 +0000 Subject: Socket timeout in OpenSSL / Ruby Message-ID: <_7zb_5GLzn82wtZOQ3iiSbD39QgKF9xtoSSkFdyUp9MkSZGW8NV5xcC2JPKDRIBWycTJ8-2ZjA7RJksQ7JO5tFj_NEjcYfVeDdAq4zw86Zs=@frontfoo.com> Dear All, I've been having issues doing a longer post request to a server through SSL. See the full story here: https://stackoverflow.com/questions/59664079/socket-timeout-in-ruby Any ideas are highly appreciated. Thank you, Andras -------------- next part -------------- An HTML attachment was scrubbed... URL: From phani2004 at gmail.com Mon Jan 13 06:20:18 2020 From: phani2004 at gmail.com (Phani 2004) Date: Mon, 13 Jan 2020 11:50:18 +0530 Subject: Query regarding adding support aes-cbc-hmac-sha1 on non x86 platform through engine Message-ID: Hi Team, I am trying to add support on an hardware engine for aes-cbc-hmac-sha1. I have observed that currently aes-cbc-hmac-sha1 is supported only for x86 architecture. "EVP_aes_128_cbc_hmac_sha1" api returns NULL for non-x86 platforms. The openssl speed app calls the "EVP_get_cipherbyname" call when it tries to parse the given arguments. It calls the above API and it returns NULL for the non-x86 platforms. How do we enable/add support for aes-cbc-hmac-sha1 on non-x86 platforms. I mean in the release version and not some local changes in my copy. Is this on the roadmap? I am currently using openssl-1.1.1a version. Regards Phani -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Jan 13 11:23:35 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 13 Jan 2020 11:23:35 +0000 Subject: Enforcing group / key_share order in TLS1.3 In-Reply-To: <20200110224120.aqeldlex7dv3sw4j@flow> References: <20200110224120.aqeldlex7dv3sw4j@flow> Message-ID: On 10/01/2020 22:41, Sebastian Andrzej Siewior wrote: > gnutls-cli sends by default (in the supported groups extension) > `secp256r1' first and later `x25519'. The key_share extension contains a > key for both types. The server has both types configured both groups and > `x25519' comes first. > The handshake however ends up with `secp256r1'. Is there a way to tell > openssl to prefer `x25519' over `secp256r1'? The current behaviour is that the first key share we see that also exists in our supported groups list is the one that we use. There isn't a way at the moment to configure things in order to specify a preference order. https://github.com/openssl/openssl/blob/bbe486cf6154df3d3aaedbae6c5b82d4ed31a5f8/ssl/statem/extensions_srvr.c#L662-L720 It wouldn't be too difficult to amend the above logic to select the key share that is highest in the server's supported group list. But that would be a new feature and wouldn't be backported to 1.1.1. PRs to make that change welcome. Matt From matt at openssl.org Mon Jan 13 12:23:12 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 13 Jan 2020 12:23:12 +0000 Subject: Query regarding adding support aes-cbc-hmac-sha1 on non x86 platform through engine In-Reply-To: References: Message-ID: <257770e2-bde8-0186-4fc3-020bd27e9408@openssl.org> On 13/01/2020 06:20, Phani 2004 wrote: > Hi Team, > > I am trying to add support on an hardware engine for aes-cbc-hmac-sha1. > I have observed that currently aes-cbc-hmac-sha1 is supported only for > x86 architecture.? > "EVP_aes_128_cbc_hmac_sha1" api returns NULL for non-x86 platforms. The > openssl speed app calls the "EVP_get_cipherbyname" call when it tries to > parse the given arguments.? > It calls the above API and it returns NULL for the non-x86 platforms.? > How do we enable/add support for aes-cbc-hmac-sha1 on non-x86 platforms. > I mean in the release version and not some local changes in my copy. > Is this on the roadmap? I am currently using openssl-1.1.1a version. This is an interesting problem. In order use an ENGINE implementation of a cipher, your application has to have a non-NULL EVP_CIPHER object to start with. This particular cipher is a highly specialised one only used by libssl. There are a handful of other similar ones. I can't actually think of a way around this problem in 1.1.1. In 3.0 it will be very different. You will be able to use the EVP_CIPHER_fetch() API to ask for a cipher implementation even for ciphers that aren't available from the built-in providers. So, yes, in a way this is on the roadmap - although you will have to implement your custom cipher via a provider rather than an engine. Matt From hkario at redhat.com Mon Jan 13 13:47:50 2020 From: hkario at redhat.com (Hubert Kario) Date: Mon, 13 Jan 2020 14:47:50 +0100 Subject: Enforcing group / =?iso-8859-1?Q?key=5Fshare_order_in_TLS1.3?= In-Reply-To: <20200110224120.aqeldlex7dv3sw4j@flow> References: <20200110224120.aqeldlex7dv3sw4j@flow> Message-ID: On Friday, 10 January 2020 23:41:20 CET, Sebastian Andrzej Siewior wrote: > Hi, > > gnutls-cli sends by default (in the supported groups extension) > `secp256r1' first and later `x25519'. The key_share extension contains a > key for both types. The server has both types configured both groups and > `x25519' comes first. > The handshake however ends up with `secp256r1'. Is there a way to tell > openssl to prefer `x25519' over `secp256r1'? use the server preference setting? for s_server it's the -serverpref switch -- 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 openssl-dev at ml.breakpoint.cc Mon Jan 13 22:21:37 2020 From: openssl-dev at ml.breakpoint.cc (Sebastian Andrzej Siewior) Date: Mon, 13 Jan 2020 23:21:37 +0100 Subject: Enforcing group / key_share order in TLS1.3 In-Reply-To: References: <20200110224120.aqeldlex7dv3sw4j@flow> Message-ID: <20200113222137.cf35ub7qbf3bt66u@flow> On 2020-01-13 11:23:35 [+0000], Matt Caswell wrote: > The current behaviour is that the first key share we see that also > exists in our supported groups list is the one that we use. There isn't > a way at the moment to configure things in order to specify a preference > order. > > https://github.com/openssl/openssl/blob/bbe486cf6154df3d3aaedbae6c5b82d4ed31a5f8/ssl/statem/extensions_srvr.c#L662-L720 Okay so there isn't a knob yet. Thank you for confirming. > It wouldn't be too difficult to amend the above logic to select the key > share that is highest in the server's supported group list. But that > would be a new feature and wouldn't be backported to 1.1.1. > > PRs to make that change welcome. Thanks, done. > Matt > Sebastian From mann.patidar at gmail.com Tue Jan 14 04:51:26 2020 From: mann.patidar at gmail.com (Manish Patidar) Date: Tue, 14 Jan 2020 10:21:26 +0530 Subject: Using EVP api in fips mode (openssl3.0) Message-ID: Hi Can any guide me how to use fips api in openssl? I try to use like below but it always returns null. ctx = EVP_CIPHER_CTX_new() ; ciph = EVP_CIPHER_fetch(NULL, "aes-128-cbc", "fips=yes") ; I am doubting fips provider is not loaded. Regards Manish -------------- next part -------------- An HTML attachment was scrubbed... URL: From phani2004 at gmail.com Tue Jan 14 07:42:20 2020 From: phani2004 at gmail.com (Phani 2004) Date: Tue, 14 Jan 2020 13:12:20 +0530 Subject: Query regarding adding support aes-cbc-hmac-sha1 on non x86 platform through engine In-Reply-To: <257770e2-bde8-0186-4fc3-020bd27e9408@openssl.org> References: <257770e2-bde8-0186-4fc3-020bd27e9408@openssl.org> Message-ID: Thanks for the quick response Matt. Is there any specific reason why it was designed that way in 1.1.1? It looks little odd that we need a non-NULL EVP_cipher object even though we do not use it/need it. I am looking for support for ARM architecture. I can't wait till 3.0. Is there any chance we may get support for this on ARM any sooner? Any patches available on 1.1.1a? Thanks in advance. Regards Phani On Mon, Jan 13, 2020 at 5:53 PM Matt Caswell wrote: > > > On 13/01/2020 06:20, Phani 2004 wrote: > > Hi Team, > > > > I am trying to add support on an hardware engine for aes-cbc-hmac-sha1. > > I have observed that currently aes-cbc-hmac-sha1 is supported only for > > x86 architecture. > > "EVP_aes_128_cbc_hmac_sha1" api returns NULL for non-x86 platforms. The > > openssl speed app calls the "EVP_get_cipherbyname" call when it tries to > > parse the given arguments. > > It calls the above API and it returns NULL for the non-x86 platforms. > > How do we enable/add support for aes-cbc-hmac-sha1 on non-x86 platforms. > > I mean in the release version and not some local changes in my copy. > > Is this on the roadmap? I am currently using openssl-1.1.1a version. > > This is an interesting problem. In order use an ENGINE implementation of > a cipher, your application has to have a non-NULL EVP_CIPHER object to > start with. This particular cipher is a highly specialised one only used > by libssl. There are a handful of other similar ones. > > I can't actually think of a way around this problem in 1.1.1. In 3.0 it > will be very different. You will be able to use the EVP_CIPHER_fetch() > API to ask for a cipher implementation even for ciphers that aren't > available from the built-in providers. > > So, yes, in a way this is on the roadmap - although you will have to > implement your custom cipher via a provider rather than an engine. > > Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Jan 14 11:51:26 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 14 Jan 2020 11:51:26 +0000 Subject: Query regarding adding support aes-cbc-hmac-sha1 on non x86 platform through engine In-Reply-To: References: <257770e2-bde8-0186-4fc3-020bd27e9408@openssl.org> Message-ID: On 14/01/2020 07:42, Phani 2004 wrote: > Thanks for the quick response Matt. > Is there any specific reason why it was designed that way in 1.1.1? These ciphers are really quite unusual. Normally we have an implementation of ciphers on all platforms. These are the exception and were added much later than when the ENGINE code went in. I suspect no-one considered the scenario when ENGINEs was developed that we might have a cipher that is NULL on some platforms. > It looks little odd that we need a non-NULL EVP_cipher object even > though we do not use it/need it. > > I am looking for support for ARM architecture. I can't wait till 3.0. > Is there any chance we may get support for this on ARM any sooner? > Any patches available on 1.1.1a? I don't see a way around this for 1.1.1 unfortunately. Maybe other people might have suggestions. Matt > > Thanks in advance. > > Regards > Phani > > On Mon, Jan 13, 2020 at 5:53 PM Matt Caswell > wrote: > > > > On 13/01/2020 06:20, Phani 2004 wrote: > > Hi Team, > > > > I am trying to add support on an hardware engine for > aes-cbc-hmac-sha1. > > I have observed that currently aes-cbc-hmac-sha1 is supported only for > > x86 architecture.? > > "EVP_aes_128_cbc_hmac_sha1" api returns NULL for non-x86 > platforms. The > > openssl speed app calls the "EVP_get_cipherbyname" call when it > tries to > > parse the given arguments.? > > It calls the above API and it returns NULL for the non-x86 platforms.? > > How do we enable/add support for aes-cbc-hmac-sha1 on non-x86 > platforms. > > I mean in the release version and not some local changes in my copy. > > Is this on the roadmap? I am currently using openssl-1.1.1a version. > > This is an interesting problem. In order use an ENGINE implementation of > a cipher, your application has to have a non-NULL EVP_CIPHER object to > start with. This particular cipher is a highly specialised one only used > by libssl. There are a handful of other similar ones. > > I can't actually think of a way around this problem in 1.1.1. In 3.0 it > will be very different. You will be able to use the EVP_CIPHER_fetch() > API to ask for a cipher implementation even for ciphers that aren't > available from the built-in providers. > > So, yes, in a way this is on the roadmap - although you will have to > implement your custom cipher via a provider rather than an engine. > > Matt > From matt at openssl.org Thu Jan 16 14:59:06 2020 From: matt at openssl.org (Matt Caswell) Date: Thu, 16 Jan 2020 14:59:06 +0000 Subject: Using EVP api in fips mode (openssl3.0) In-Reply-To: References: Message-ID: On 14/01/2020 04:51, Manish Patidar wrote: > Hi > > Can any guide me how to use fips api in openssl? > > I try to use like below but it always returns null.? > > ctx = EVP_CIPHER_CTX_new() ; > ciph = EVP_CIPHER_fetch(NULL, "aes-128-cbc", "fips=yes") ; > > I am doubting fips provider is not loaded.?? Right - the FIPS provider does not get loaded by default. First set some environment variables which will make the whole process a bit easier. The OpenSSL libraries read these to locate the various files: export OPENSSL_CONF_INCLUDE=/path/to/include/dir export OPENSSL_MODULES=/path/to/providers/dir export OPENSSL_CONF=/path/to/fips.cnf Next you will need to "install" the FIPS module. This will create a fipsinstall.conf file: openssl fipsinstall -out $OPENSSL_CONF_INCLUDE/fipsinstall.conf -module $OPENSSL_MODULES/fips.so -provider_name fips -mac_name HMAC -macopt 'digest:SHA256' -macopt 'hexkey:00' -section_name fips_sect (Aside: probably we should do the above as part of "make install", but we don't do that AFAIK at the moment) Now create a config file to automatically load the FIPS module when OpenSSL starts. Store it in the file pointed to by $OPENSSL_CONF openssl_conf = openssl_init .include fipsinstall.conf [openssl_init] providers = provider_sect [provider_sect] fips = fips_sect This will have the effect of automatically loading the FIPS provider *and no others*. In this case you don't need the "fips=yes" in your EVP_CIPHER_fetch() call because there are no other providers loaded (although it does no harm). Alternatively you can load both the default and FIPS providers at the same time: openssl_conf = openssl_init .include fipsinstall.conf [openssl_init] providers = provider_sect [provider_sect] default = default_sect fips = fips_sect [default_sect] activate = 1 In this case you will need to specify "fips=yes" in the fetch to disambiguate which implementation you want. Hope that helps, Matt From dougbmorris at yahoo.com Sun Jan 19 02:51:53 2020 From: dougbmorris at yahoo.com (Douglas Morris) Date: Sun, 19 Jan 2020 02:51:53 +0000 (UTC) Subject: OpenSSL Selection of Text Encoding for the -out and -text Options References: <1110155634.860118.1579402313962.ref@mail.yahoo.com> Message-ID: <1110155634.860118.1579402313962@mail.yahoo.com> I'm working on an ACME client written in Python3. I expect the certificate sent by the ACME server will be in utf-8 per RFC 8555, sec. 5. It seems from Python Standard Library function sys.getfilesystemencoding() that a filesystem has a particular encoding for filesystem names (which is not an explicit default for text files). I wonder if OpenSSL (and generally other software) automatically uses the filesystem name encoding by default for all text output. I don't see anything about text encoding on the "Compilation and Installation" wiki page. I have OpenSSL from a Debian package. I don't see anything about text encoding in the configuration file /etc/ssl/openssl.cnf. What is/are and how does OpenSSL choose the text encodings for -out and -text, respectively. Information about line encoding selection would be a nice bonus. I would guess that line encoding is determined by the OS target and is essentially hardcoded to the package or source code distribution. I would like to have all my related domain certification files in the same text encoding and to decode the -text output into a string value as reliably (and as transparently to the user) as possible. My fallback position is of course to just hardcode utf-8. I would like to avoid that unless it's the smart thing to do. (I don't follow Windows but know is used to favor utf-16.) Thanks. Douglas Morris -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sun Jan 19 05:30:08 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 19 Jan 2020 00:30:08 -0500 Subject: OpenSSL Selection of Text Encoding for the -out and -text Options In-Reply-To: <1110155634.860118.1579402313962@mail.yahoo.com> References: <1110155634.860118.1579402313962.ref@mail.yahoo.com> <1110155634.860118.1579402313962@mail.yahoo.com> Message-ID: <20200119053008.GB73491@straasha.imrryr.org> On Sun, Jan 19, 2020 at 02:51:53AM +0000, Douglas Morris via openssl-users wrote: > I'm working on an ACME client written in Python3. I expect the > certificate sent by the ACME server will be in utf-8 per RFC 8555, > sec. 5. Certificates are in DER or PEM form, not utf-8. Some strings in the certificate might be UTF-8, but that does not look relevant here. > It seems from Python Standard Library function > sys.getfilesystemencoding() that a filesystem has a particular > encoding for filesystem names (which is not an explicit default for > text files). File system metadata (file names, ...) is distinct from file content. > I wonder if OpenSSL (and generally other software) automatically uses > the filesystem name encoding by default for all text output. This makes no sense. OpenSSL does not display filenames, it reads data from files given to it via API calls and command-line options. > I don't see anything about text encoding on the "Compilation and > Installation" wiki page. I have OpenSSL from a Debian package. I don't > see anything about text encoding in the configuration file > /etc/ssl/openssl.cnf. The issue does not come up. OpenSSL functions that take filename arguments use the the verbatim C-character arrays passed to them in API calls. The names are byte arrays not strings subject to encoding and decoding. > What is/are and how does OpenSSL choose the text encodings for -out > and -text, respectively. No encoding at all. > Information about line encoding selection would be a nice bonus. DER files are binary, and PEM files are text files. The platform's C library normally determines how line-oriented data is written to files. OpenSSL's BIO abstraction over files generally uses STDIO to perform the underlying I/O. So line endings are a feature of the C-library, not OpenSSL. > I would like to have all my related domain certification files in the > same text encoding and to decode the -text output into a string value > as reliably (and as transparently to the user) as possible. My > fallback position is of course to just hardcode utf-8. Here, you seem to be confusing file name encodings with file content. PEM files are base64-encoded ASCII. As for the output of "x509 -text", there are various options to control the output format. At this time, you really should be using UTF-8 unconditionally. -- Viktor. From s.peillon at caenlamer.fr Sat Jan 25 18:50:19 2020 From: s.peillon at caenlamer.fr (PEILLON Stephane) Date: Sat, 25 Jan 2020 18:50:19 +0000 Subject: Generate nomative certificate from wildcard certificate Message-ID: Hello I have a wildcard certificate to implement https on our websites via sub domains. is it possible to generate a nominative certificate from this certificate with openssl? (with an attribute of the type uid, name and function ...). I would like to be able to distribute certificates to each agent of the company to authenticate on our websso portal or electronically sign internal documents. thank you in advance Regard St?phane [http://disclaimer.caenlamer.fr/img/bandeau.jpg] -------------- next part -------------- An HTML attachment was scrubbed... URL: From aerowolf at gmail.com Sat Jan 25 22:43:09 2020 From: aerowolf at gmail.com (Kyle Hamilton) Date: Sat, 25 Jan 2020 16:43:09 -0600 Subject: Generate nomative certificate from wildcard certificate In-Reply-To: References: Message-ID: No, it's not possible,to use a webserver certificate to issue other certificates of any kind. (Oh, it is technically possible with openssl to create certificates which might seem valid on the surface -- just use the webserver key to generate a self-signed CA certificate with the same Subject as is contained within your webserver certificate -- but such certificates are actually invalid and will not work.) See, the issue is that you need to use a CA to issue certificates, and all publicly trusted web server certificates issued in the last 25+ years have an extension called BasicConstraints which says that they are not CAs. So, all software which correctly validates certificates will immediately fail the authentication process when presented with certificates which attempt to chain through such webserver certificates. Fortunately, this is not exactly an impediment to your proposed use case -- your webSSO portal software (and your webservers themselves, and your internal document signature verification software itself, for that matter) can be configured to accept authentication via certificates from any particular CA, not merely any CA which has been publicly trusted by web browsers. What this means is that you can create your own CA to issue the certificates to your webSSO portal users, with the caveat that they cannot use those certificates to sign documents which must be authenticated externally. The necessary security analysis is the same whether you were to issue user certificates using the webserver certificate or a certificate identifying your own CA. Among other things, you need to think about where and how the keys are stored (not just for your CA but also for your users), how they're generated, how the CA links each public key to the user it's linked to, how users are prevented from using keys belonging to other users, what happens when you need to make changes to the infrastructure [no infrastructute ever remains static], what services will be accessible via the keys, what operations can be performed by the holders of the keys, what happens when an inevitable compromise happens (including but not limited to 'CA is completely compromised and its private key learned by anyone who is unauthorized', 'CA misissues a certificate', 'some user's certificate is used by someone other than the user it identifies', 'employee a certificate was issued to is terminated', and 'employee who knew the CA's private key is terminated'), and whether the protections you bake into the key infrastructure are sufficient to support those uses without giving rise to liability for your organization. And make sure you write down the limits of what you're comfortable with in your infrastructure and why those are the limits, so that they can be referred to down the road. (No CA should ever have its private key accessible from a world-accessible machine like a webserver, because it increases the risk of that private key being discovered by any hacker in the world. This is one of the primary reasons why webserver keys should never be also used as CA keys.) In an ideal world, organizations would have X.500 Directory instances which would be identified and authenticated by some trustworthy external identity verifier, and which could issue certificates for their employees to be trusted by external relying parties. That's possibly what you're asking for, by asking to use an externally-signed webserver certificate as your issuer. Unfortunately, that is not how our world currently exists (except in the US military and aerospace contract space, to my knowledge, and possibly in diplomatic channels and anything that other nations may have done), and so we are basically in a position where companies must create their own CAs by essentially saying "I am me" and building their own internal infrastructures to trust those kinds of statement. (And, potentially, to then cross-certify other entities who make the same type of assertion in a manner that they trust, which usually involves contracts and due diligence -- but only so their infrastructures can trust those other entities' users to do things that those contracts specify they need to do.) Please note that I do not have direct knowledge of France's or the EU's legal climate. You may wish to inquire if such company certification services do exist from your register of corporations. But do not be discouraged if they do not. You can still accomplish your stated purposes without such services being provided. Good luck! -Kyle H On Sat, Jan 25, 2020, 12:50 PEILLON Stephane wrote: > Hello > > I have a wildcard certificate to implement https on our websites via sub > domains. > > is it possible to generate a nominative certificate from this certificate > with openssl? (with an attribute of the type uid, name and function ...). > > I would like to be able to distribute certificates to each agent of the > company to authenticate on our websso portal or electronically sign > internal documents. > > thank you in advance > Regard > St?phane > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougbmorris at yahoo.com Sun Jan 26 04:58:42 2020 From: dougbmorris at yahoo.com (Douglas Morris) Date: Sun, 26 Jan 2020 04:58:42 +0000 (UTC) Subject: Thanks for Encoding Clarification References: <791238297.11590163.1580014722271.ref@mail.yahoo.com> Message-ID: <791238297.11590163.1580014722271@mail.yahoo.com> Viktor, Thanks for meticulously answering my questions. I know the file name encoding is not necessarily the file content encoding. If a Python program were on a Windows computer, it might show a file name encoding of UTC-16, which would make UTC-16 a good guess for what openssl -text would output as bytes to be converted (the way what I'm doing works with Python's subprocess module). That was my conjectural thinking and a heuristic I though might be useful. I could get the name of the operating system from Python and map that to a 'native' encoding I suppose, but that's too much work for dubious gain. I'm not testing on Windows. It is enough to know that there is no easy and obvious way to accommodate -text bytes on various OSes, supposing they would be different. Maybe there is no difference. I expect think there should be on older WIndows and Apple OSes. Yes, I could be wrong. I'll just go with what I knowledge I have, accept the uncertainty, and concentrate on the OS that I'm using, which is Linux. I could always extract public key parameters and expiration dates from the OS-consistent PEM form, not that I want to try. So DER is binary and PEM is ASCII text (which means utf-8 and not utf-16). Going by RFC 1421 via herongyang.com, the MS line breaks are a nice touch. I got the info I need to program something and troubleshoot any encoding problems from -text output bytes that might arise. I can see that 'openssl req -in -outform DER' outputs bytes that are not to be changed. I suppose the same is true of -outform PEM. That's good to know because I was 'fixing' the received certificate (in PEM I believe) by normalizing line breaks to '\n' and then trusting Python's universal newlines mode to write out the big string in a variable to a file with the native OS-line-break encoding. I think I'll just write out the raw bytes as received. Funny, but I ran openssl x509 -text on the one test/staging certificate I saved to file only hours ago, and with the aforesaid 'normalization', and it displayed correctly. I know that doesn't prove that such treatment for a real certificate will work correctly for the Web server when the time comes, but my program is coming along and I know a little more about what's going on. Thanks. Douglas Morris -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Sun Jan 26 21:03:50 2020 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 26 Jan 2020 16:03:50 -0500 Subject: What option is not recognized by OpenSSL 1.1.1d? Message-ID: I'm trying to convert some scripts from OpenSSL 1.0.2 to OpenSSL 1.1.1d. Configure is dying: ***** Unsupported options: no-comp --prefix=/home/jwalton/tmp/build-test --libdir=/home/jwalton/tmp/build-test/lib According to INSTALL at https://github.com/openssl/openssl/blob/master/INSTALL, all the options are supported. Which option is not recognized by OpenSSL 1.1.1d? Thanks in advance. From matt at openssl.org Mon Jan 27 08:40:59 2020 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 Jan 2020 08:40:59 +0000 Subject: What option is not recognized by OpenSSL 1.1.1d? In-Reply-To: References: Message-ID: <8a3bdb62-5ef6-3fd4-2cb0-108d5b0ebdbb@openssl.org> On 26/01/2020 21:03, Jeffrey Walton wrote: > I'm trying to convert some scripts from OpenSSL 1.0.2 to OpenSSL 1.1.1d. > > Configure is dying: > > ***** Unsupported options: no-comp > --prefix=/home/jwalton/tmp/build-test > --libdir=/home/jwalton/tmp/build-test/lib > > According to INSTALL at > https://github.com/openssl/openssl/blob/master/INSTALL, all the > options are supported. > > Which option is not recognized by OpenSSL 1.1.1d? That is strange: > ***** Unsupported options: no-comp "no-comp" *is* supported in 1.1.1! E.g $ perl Configure linux-x86_64 no-comp Configuring OpenSSL version 1.1.1e-dev (0x10101050L) for linux-x86_64 Using os-specific seed configuration Creating configdata.pm Creating Makefile ********************************************************************** *** *** *** OpenSSL has been successfully configured *** *** *** *** If you encounter a problem while building, please open an *** *** issue on GitHub *** *** and include the output from the following command: *** *** *** *** perl configdata.pm --dump *** *** *** *** (If you are new to OpenSSL, you might want to consult the *** *** 'Troubleshooting' section in the INSTALL file first) *** *** *** ********************************************************************** What was your full "Configure" line? I don't recall there being any options that we removed in 1.1.x compared to 1.0.2...or if we did we made them no-ops or something. Matt From eran.borovik at gmail.com Mon Jan 27 14:06:36 2020 From: eran.borovik at gmail.com (Eran Borovik) Date: Mon, 27 Jan 2020 16:06:36 +0200 Subject: Determine that there is no forward progress with non blocking SSL socket Message-ID: Hi all, My application is using non-blocking sockets to send and receive data. To avoid issues, my code guarantees that a specific socket is always owned by a specific thread, thus preventing any issues or races from concurrently running send and receive at the same time on the same socket. I've read thoroughly the lists regarding the best way to use non blocking sockets with SSL. The common wisdom I gathered was: -It is allowed to interleave SSL_read and SSL_write, meaning that SSL_read doesn't have to complete successfully before issuing SSL_write( this makes sense otherwise full-duplex doesn't work). -SSL socket has a global state. So return value from one call negates a previous return value from other call. My question is how to determine that forward progress isn't possible and to return to epoll. Suppose I have a main-loop that deals with all the pending receives and sends for a specific socket. For simplicity, assume that I try to SSL_receive until I get some kind of an error (WANT_READ or WANT_WRITE). Then I try to issue SSL_send until I get error as well, but if I read correctly the group, the new error negates previous errors so prior receives must be retried. When do I stop? what is the best way to actually determine there can be no more forward progress both on the send and the receive side, and epoll must be used? I can think on the following "algorithm" but I am not sure if it makes sense: -Receive until you get an Error X. -Send. If I receive a return value that isn't X, it means receive will have to be retried. If I immediately receive a return value that is X, it means that no more progress is possible and I need to wait with epoll. Problem with the above algorithm, is that I am afraid that if the send buffer is full and there is nothing to receive, I will keep getting WANT_READ for receive, and WANT_WRITE for send until actual data arrives or can be sent which defeats the purpose of epoll. I've been banging my head here for several days. Any help here will be much appreciated. Thx, Eran -------------- next part -------------- An HTML attachment was scrubbed... URL: From dheinz at softwarekey.com Mon Jan 27 18:20:27 2020 From: dheinz at softwarekey.com (Dan Heinz) Date: Mon, 27 Jan 2020 18:20:27 +0000 Subject: Decryption slower in 1.1.1 branch? Message-ID: I upgraded a library that used OpenSSL 1.0.2 to the OpenSSL 1.1.1d. On Windows, I have found that the time to decrypt had doubled. After a bit of timestamp logging, I found the RSA_private_decrypt function is taking twice as long with 1.1.1d as it did with 1.0.2t. This is being called from a Windows 64-bit DLL. For example, decrypting 8680 bytes of data averages about .3 seconds with the OpenSSL 1.0.2t library (statically linked). Decrypting the same data with the OpenSSL 1.1.1d library averages about .6 seconds. I'm wondering if perhaps my build configuration is incorrect or missing something for the 1.1.1d build. Here are the configuration parameters for the 64-bit build: Configure VC-WIN64A --prefix=%RootPath_ThirdParty%\%OPENSSL_VERSION% -DPURIFY -DOPENSSL_NO_COMP -D_USING_V110_SDK71_ no-shared no-asm no-idea no-mdc2 no-rc5 no-ssl2 no-ssl3 no-zlib no-comp no-pinshared I logged things granular enough to see the speed difference was in RSA_private_decrypt, but I'm not sure why it is so much slower with 1.1.1d. Any help or ideas would be appreciated! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafab969 at gmail.com Mon Jan 27 18:44:20 2020 From: rafab969 at gmail.com (RUBEN BARAINCA) Date: Mon, 27 Jan 2020 19:44:20 +0100 Subject: openssl-users Digest, Vol 62, Issue 6 References: Message-ID: <-6bjizb-4vazeg-v7uf8hrjbfdzcsg2tv-9rglpt-5g351n-ubt4bjv6juhu-p852l8bpbqpi2g3tngdvfdwzpxcn2tj6v9cj-pgwrm9-flboj746i4602clj3ngwtv73-loyfnv-11j09j7xt2j0-81dpyr.1580150608317@email.android.com> An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Jan 27 19:03:08 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 27 Jan 2020 14:03:08 -0500 Subject: Decryption slower in 1.1.1 branch? In-Reply-To: References: Message-ID: <20200127190308.GT73491@straasha.imrryr.org> On Mon, Jan 27, 2020 at 06:20:27PM +0000, Dan Heinz wrote: > I upgraded a library that used OpenSSL 1.0.2 to the OpenSSL 1.1.1d. > On Windows, I have found that the time to decrypt had doubled. After > a bit of timestamp logging, I found the RSA_private_decrypt function > is taking twice as long with 1.1.1d as it did with 1.0.2t. This is > being called from a Windows 64-bit DLL. RSA is not intended for bulk data decryption, its intended uses are key transport and signing. Bulk data decryption is done via AES or similar. > For example, decrypting 8680 bytes of data averages about .3 seconds > with the OpenSSL 1.0.2t library (statically linked). Decrypting the > same data with the OpenSSL 1.1.1d library averages about .6 seconds. Are you sure that's seconds and not milliseconds? These are absurdly long times, almost certainly dominated by factors other than the encryption algorithms. On my 2015 laptop (MacOS) I get: OpenSSL 1.0.2h: options:bn(64,64) rc4(ptr,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) compiler: cc -I. -I.. -I../include -fPIC -fno-common -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM sign verify sign/s verify/s rsa 2048 bits 0.000883s 0.000027s 1132.3 37397.7 OpenSSL 1.1.1a: options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: cc -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG -DOPENSSL_API_COMPAT=0x10100000L sign verify sign/s verify/s rsa 2048 bits 0.000883s 0.000026s 1132.8 38377.8 Which shows an RSA 2048-bit signature (private key decrypt operation) taking less than 1ms, and not materially different between 1.0.2 and 1.1.1. > I'm wondering if perhaps my build configuration is incorrect or > missing something for the 1.1.1d build. Here are the configuration > parameters for the 64-bit build: There's probably a deeper issue with what you're doing, you need to be much more specific about what you're measuring. Is this SMIME? CMS? What is the RSA key size? What is the bulk encryption cipher? > Configure VC-WIN64A --prefix=%RootPath_ThirdParty%\%OPENSSL_VERSION% > -DPURIFY -DOPENSSL_NO_COMP -D_USING_V110_SDK71_ no-shared no-asm > no-idea no-mdc2 no-rc5 no-ssl2 no-ssl3 no-zlib no-comp no-pinshared PURIFY must not be enabled in production builds, it is only for memory allocation/safety debugging. You've also disabled assembly optimizations, which reduces side-channel resistance and hurts performance. > I logged things granular enough to see the speed difference was in > RSA_private_decrypt, but I'm not sure why it is so much slower with > 1.1.1d. Any help or ideas would be appreciated! At 600ms for 8KB, it is not plausible that the time is spend doing cryptography. That's barely fast enough to feed a 1980's modem. -- Viktor. From Michael.Wojcik at microfocus.com Mon Jan 27 19:03:10 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 27 Jan 2020 19:03:10 +0000 Subject: Determine that there is no forward progress with non blocking SSL socket In-Reply-To: References: Message-ID: From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Eran Borovik Sent: Monday, January 27, 2020 07:07 > When do I stop? what is the best way to actually determine there can > be no more forward progress both on the send and the receive side, and > epoll must be used? ... > I am afraid that if the send buffer is full and there is nothing to receive, > I will keep getting WANT_READ for receive, and WANT_WRITE for send until > actual data arrives or can be sent which defeats the purpose of epoll. The following is untested and off the top of my head. Think of it this way. You have these possible states: 1. You don't want to do anything with the conversation. It can be closed. 2. You want to receive. There are three possible causes: - You'd like to receive data (or close/error indication) from the peer. - SSL_send returned WANT_READ. - Both of the above are true. 3. You want to send. There are three possible causes: - You have buffered outbound application data (or shutdown/close) which you haven't been able to send yet. - SSL_receive returned WANT_WRITE. - Both of the above are true. 4. You want to receive and to send. So, keep track of the above using a per-conversation pair of want_to_send and want_to_receive variables and use the following algorithm: /* any time we buffer outbound data, set want_to_send = 1 */ want_to_receive = 1 /* at start of conversation, we want data from peer */ while want_to_send or want_to_receive { /* Wait until we can do something we want to do */ do_recv = false, do_send = false if want_to_send and want_to_receive { epoll until socket is readable or writable do_recv = readable do_send = writable } else if want_to_send { epoll until socket is writable do_send = true } else if want_to_receive { epoll until socket is readable do_recv = true } /* Now perform I/O */ if do_recv { SSL_read(...) if WANT_WRITE want_to_send = true else if WANT_READ want_to_receive = true /* couldn't send enough to clear WANT_WRITE */ else if error ... else want_to_receive = false /* maybe, depending on application */ process_received_data(...) } if do_send { SSL_write(...) if WANT_READ want_to_receive = true else if WANT_WRITE want_to_send = true /* couldn't send enough to clear WANT_WRITE */ else if error ... else { update send buffer info if all buffered data sent want_to_send = false /* any pending WANT_WRITE should now be clear */ } } } close conversation Now, in practice, you probably always want to poll on readability even if you're not expecting data from the peer, because you'll want to be notified of peer close. And you may want to be able to break out of an epoll for readability only in order to send data, depending on your application design and requirements. You can do that using a timeout and polling the want_to_send state variable, or using an internal channel such as a pipe or socket which the polling thread adds to the epoll readable-descriptor set, and the sending thread writes a wakeup message to. It's an open design question if you want to set want_to_receive to false in the do_recv body, as I have it above, and then set it back to true if you decide you're not done with the conversation in process_received_data; or leave it set to true and set it to false only when you've received a close indication from the peer; or possibly some other behavior that's appropriate for your application. In brief: at the top of the loop, figure out if you want to try to send, receive, or both. The types of I/O you want to do is the union of the application state and the OpenSSL WANT_* state. Then poll for all the types of I/O you want, and when the socket is available for any of them, attempt that type. Deal with any successful operation, and loop. In the "problem case" you described above, this code will discover that you want to receive and to send, so it will first poll for either type of availability on the socket. If the socket ends up readable, you'll do a receive, which may succeed or may return WANT_WRITE or may indicate a peer close or may indicate an error. It could also return WANT_READ if it's not able to receive enough TLS data to satisfy a pending WANT_READ. In that case we keep want_to_receive set and go around the loop again. And if the socket is writable (regardless of whether it's also readable), it will try to send some of your application data; that will also try to handle any pending WANT_WRITE condition. The result might be sending all the application data, sending some or none of the application data, satisfying a WANT_WRITE condition, failing to send enough to satisfy the WANT_WRITE, getting an error, etc. If we do send some application data, we can assume any pending WANT_WRITE from the previous receive operation was satisfied. -- Michael Wojcik Distinguished Engineer, Micro Focus From Matthias.St.Pierre at ncp-e.com Mon Jan 27 21:33:29 2020 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 27 Jan 2020 21:33:29 +0000 Subject: openssl-users Digest, Vol 62, Issue 6 In-Reply-To: <-6bjizb-4vazeg-v7uf8hrjbfdzcsg2tv-9rglpt-5g351n-ubt4bjv6juhu-p852l8bpbqpi2g3tngdvfdwzpxcn2tj6v9cj-pgwrm9-flboj746i4602clj3ngwtv73-loyfnv-11j09j7xt2j0-81dpyr.1580150608317@email.android.com> References: <-6bjizb-4vazeg-v7uf8hrjbfdzcsg2tv-9rglpt-5g351n-ubt4bjv6juhu-p852l8bpbqpi2g3tngdvfdwzpxcn2tj6v9cj-pgwrm9-flboj746i4602clj3ngwtv73-loyfnv-11j09j7xt2j0-81dpyr.1580150608317@email.android.com> Message-ID: <16d88b8b572a4339a6551534c7dc2c8e@Ex13.ncp.local> Hi, in the body of the message you just sent us, you find a detailed description how to unsubscribe: To subscribe or unsubscribe via the World Wide Web, visit https://mta.openssl.org/mailman/listinfo/openssl-users or, via email, send a message with subject or body 'help' to openssl-users-request at openssl.org Regards, Matthias From: openssl-users On Behalf Of RUBEN BARAINCA Sent: Monday, January 27, 2020 7:44 PM To: openssl-users at openssl.org Subject: Re:openssl-users Digest, Vol 62, Issue 6 Importance: High Hi!! I want to unsubscribe. -------- Original message -------- From: openssl-users-request at openssl.org Date: Mon, Jan 27, 2020, 7:20 PM To: openssl-users at openssl.org Subject: openssl-users Digest, Vol 62, Issue 6 Send openssl-users mailing list submissions to openssl-users at openssl.org To subscribe or unsubscribe via the World Wide Web, visit https://mta.openssl.org/mailman/listinfo/openssl-users or, via email, send a message with subject or body 'help' to openssl-users-request at openssl.org You can reach the person managing the list at openssl-users-owner at openssl.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openssl-users digest..." Today's Topics: 1. Thanks for Encoding Clarification (Douglas Morris) 2. What option is not recognized by OpenSSL 1.1.1d? (Jeffrey Walton) 3. Re: What option is not recognized by OpenSSL 1.1.1d? (Matt Caswell) 4. Determine that there is no forward progress with non blocking SSL socket (Eran Borovik) 5. Decryption slower in 1.1.1 branch? (Dan Heinz) ---------------------------------------------------------------------- Message: 1 Date: Sun, 26 Jan 2020 04:58:42 +0000 (UTC) From: Douglas Morris > To: "openssl-users at openssl.org" > Subject: Thanks for Encoding Clarification Message-ID: <791238297.11590163.1580014722271 at mail.yahoo.com> Content-Type: text/plain; charset="utf-8" Viktor, Thanks for meticulously answering my questions. I know the file name encoding is not necessarily the file content encoding. If a Python program were on a Windows computer, it might show a file name encoding of UTC-16, which would make UTC-16 a good guess for what openssl -text would output as bytes to be converted (the way what I'm doing works with Python's subprocess module). That was my conjectural thinking and a heuristic I though might be useful. I could get the name of the operating system from Python and map that to a 'native' encoding I suppose, but that's too much work for dubious gain. I'm not testing on Windows. It is enough to know that there is no easy and obvious way to accommodate -text bytes on various OSes, supposing they would be different. Maybe there is no difference. I expect think there should be on older WIndows and Apple OSes. Yes, I could be wrong. I'll just go with what I knowledge I have, accept the uncertainty, and concentrate on the OS that I' m using, which is Linux. I could always extract public key parameters and expiration dates from the OS-consistent PEM form, not that I want to try. So DER is binary and PEM is ASCII text (which means utf-8 and not utf-16). Going by RFC 1421 via herongyang.com, the MS line breaks are a nice touch. I got the info I need to program something and troubleshoot any encoding problems from -text output bytes that might arise. I can see that 'openssl req -in -outform DER' outputs bytes that are not to be changed. I suppose the same is true of -outform PEM. That's good to know because I was 'fixing' the received certificate (in PEM I believe) by normalizing line breaks to '\n' and then trusting Python's universal newlines mode to write out the big string in a variable to a file with the native OS-line-break encoding. I think I'll just write out the raw bytes as received. Funny, but I ran openssl x509 -text on the one test/staging certificate I saved to file only hours ago, and with the aforesaid 'normalization', and it displayed correctly. I know that doesn't prove that such treatment for a real certificate will work correctly for t he Web server when the time comes, but my program is coming along and I know a little more about what's going on. Thanks. Douglas Morris -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Sun, 26 Jan 2020 16:03:50 -0500 From: Jeffrey Walton > To: OpenSSL Users > Subject: What option is not recognized by OpenSSL 1.1.1d? Message-ID: > Content-Type: text/plain; charset="UTF-8" I'm trying to convert some scripts from OpenSSL 1.0.2 to OpenSSL 1.1.1d. Configure is dying: ***** Unsupported options: no-comp --prefix=/home/jwalton/tmp/build-test --libdir=/home/jwalton/tmp/build-test/lib According to INSTALL at https://github.com/openssl/openssl/blob/master/INSTALL, all the options are supported. Which option is not recognized by OpenSSL 1.1.1d? Thanks in advance. ------------------------------ Message: 3 Date: Mon, 27 Jan 2020 08:40:59 +0000 From: Matt Caswell > To: openssl-users at openssl.org Subject: Re: What option is not recognized by OpenSSL 1.1.1d? Message-ID: <8a3bdb62-5ef6-3fd4-2cb0-108d5b0ebdbb at openssl.org> Content-Type: text/plain; charset=utf-8 On 26/01/2020 21:03, Jeffrey Walton wrote: > I'm trying to convert some scripts from OpenSSL 1.0.2 to OpenSSL 1.1.1d. > > Configure is dying: > > ***** Unsupported options: no-comp > --prefix=/home/jwalton/tmp/build-test > --libdir=/home/jwalton/tmp/build-test/lib > > According to INSTALL at > https://github.com/openssl/openssl/blob/master/INSTALL, all the > options are supported. > > Which option is not recognized by OpenSSL 1.1.1d? That is strange: > ***** Unsupported options: no-comp "no-comp" *is* supported in 1.1.1! E.g $ perl Configure linux-x86_64 no-comp Configuring OpenSSL version 1.1.1e-dev (0x10101050L) for linux-x86_64 Using os-specific seed configuration Creating configdata.pm Creating Makefile ********************************************************************** *** *** *** OpenSSL has been successfully configured *** *** *** *** If you encounter a problem while building, please open an *** *** issue on GitHub *** *** and include the output from the following command: *** *** *** *** perl configdata.pm --dump *** *** *** *** (If you are new to OpenSSL, you might want to consult the *** *** 'Troubleshooting' section in the INSTALL file first) *** *** *** ********************************************************************** What was your full "Configure" line? I don't recall there being any options that we removed in 1.1.x compared to 1.0.2...or if we did we made them no-ops or something. Matt ------------------------------ Message: 4 Date: Mon, 27 Jan 2020 16:06:36 +0200 From: Eran Borovik > To: openssl-users at openssl.org Subject: Determine that there is no forward progress with non blocking SSL socket Message-ID: > Content-Type: text/plain; charset="utf-8" Hi all, My application is using non-blocking sockets to send and receive data. To avoid issues, my code guarantees that a specific socket is always owned by a specific thread, thus preventing any issues or races from concurrently running send and receive at the same time on the same socket. I've read thoroughly the lists regarding the best way to use non blocking sockets with SSL. The common wisdom I gathered was: -It is allowed to interleave SSL_read and SSL_write, meaning that SSL_read doesn't have to complete successfully before issuing SSL_write( this makes sense otherwise full-duplex doesn't work). -SSL socket has a global state. So return value from one call negates a previous return value from other call. My question is how to determine that forward progress isn't possible and to return to epoll. Suppose I have a main-loop that deals with all the pending receives and sends for a specific socket. For simplicity, assume that I try to SSL_receive until I get some kind of an error (WANT_READ or WANT_WRITE). Then I try to issue SSL_send until I get error as well, but if I read correctly the group, the new error negates previous errors so prior receives must be retried. When do I stop? what is the best way to actually determine there can be no more forward progress both on the send and the receive side, and epoll must be used? I can think on the following "algorithm" but I am not sure if it makes sense: -Receive until you get an Error X. -Send. If I receive a return value that isn't X, it means receive will have to be retried. If I immediately receive a return value that is X, it means that no more progress is possible and I need to wait with epoll. Problem with the above algorithm, is that I am afraid that if the send buffer is full and there is nothing to receive, I will keep getting WANT_READ for receive, and WANT_WRITE for send until actual data arrives or can be sent which defeats the purpose of epoll. I've been banging my head here for several days. Any help here will be much appreciated. Thx, Eran -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Mon, 27 Jan 2020 18:20:27 +0000 From: Dan Heinz > To: "openssl-users at openssl.org" > Subject: Decryption slower in 1.1.1 branch? Message-ID: > Content-Type: text/plain; charset="us-ascii" I upgraded a library that used OpenSSL 1.0.2 to the OpenSSL 1.1.1d. On Windows, I have found that the time to decrypt had doubled. After a bit of timestamp logging, I found the RSA_private_decrypt function is taking twice as long with 1.1.1d as it did with 1.0.2t. This is being called from a Windows 64-bit DLL. For example, decrypting 8680 bytes of data averages about .3 seconds with the OpenSSL 1.0.2t library (statically linked). Decrypting the same data with the OpenSSL 1.1.1d library averages about .6 seconds. I'm wondering if perhaps my build configuration is incorrect or missing something for the 1.1.1d build. Here are the configuration parameters for the 64-bit build: Configure VC-WIN64A --prefix=%RootPath_ThirdParty%\%OPENSSL_VERSION% -DPURIFY -DOPENSSL_NO_COMP -D_USING_V110_SDK71_ no-shared no-asm no-idea no-mdc2 no-rc5 no-ssl2 no-ssl3 no-zlib no-comp no-pinshared I logged things granular enough to see the speed difference was in RSA_private_decrypt, but I'm not sure why it is so much slower with 1.1.1d. Any help or ideas would be appreciated! -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ openssl-users mailing list openssl-users at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-users ------------------------------ End of openssl-users Digest, Vol 62, Issue 6 ******************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougbmorris at yahoo.com Tue Jan 28 02:17:21 2020 From: dougbmorris at yahoo.com (Douglas Morris) Date: Tue, 28 Jan 2020 02:17:21 +0000 (UTC) Subject: How text-ish are PEM files? References: <931767802.105891.1580177841869.ref@mail.yahoo.com> Message-ID: <931767802.105891.1580177841869@mail.yahoo.com> I expect from RFC 8555 that an ACME server issues a full chain certificate as a reply body in the PEM format. The media type is 'application/pem-certificate-chain'. I can only guess from RFC 1421, sec. 4.3.1 that the byte encoding of the certificate necessarily uses line breaks. I get US-ASCII from encguess .pem.? Paging PEM files with less does NOT show ^M at the end of each or any line. Are PEM files, e.g. the private key pair files and certificate files needed by Web servers, necessarily in US-ASCII? Are PEM files typically/conventionally stored in the line break encoding of the native operating system? Should PEM files always or normally be transmitted with the line break encoding? Douglas Morris -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Jan 28 02:43:09 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 27 Jan 2020 21:43:09 -0500 Subject: How text-ish are PEM files? In-Reply-To: <931767802.105891.1580177841869@mail.yahoo.com> References: <931767802.105891.1580177841869.ref@mail.yahoo.com> <931767802.105891.1580177841869@mail.yahoo.com> Message-ID: <20200128024309.GU73491@straasha.imrryr.org> On Tue, Jan 28, 2020 at 02:17:21AM +0000, Douglas Morris via openssl-users wrote: > I expect from RFC 8555 that an ACME server issues a full chain > certificate as a reply body in the PEM format. The media type is > 'application/pem-certificate-chain'. https://www.iana.org/assignments/media-types/application/pem-certificate-chain Encoding considerations: 7bit https://tools.ietf.org/html/rfc8555#section-9 A file of this type contains one or more certificates encoded with the PEM textual encoding, according to [RFC7468]. The textual encoding of certificates in this file MUST use the strict encoding and MUST NOT include explanatory text. The ABNF for this format is as follows, where "stricttextualmsg" and "eol" are as defined in Section 3 of RFC 7468: certchain = stricttextualmsg *(eol stricttextualmsg) https://tools.ietf.org/html/rfc7468#section-3 eol = CRLF / CR / LF > I can only guess from RFC 1421, sec. 4.3.1 that the byte encoding of > the certificate necessarily uses line breaks. The canonical format of a MIME media type on the wire need not match its local representation on disk. For example, HTTP transmits textual content with CRLF line endings, but user agents generally store text with using host platform's line endings. > I get US-ASCII from encguess .pem. No need to guess, it is just the base64 (ASCII) payload beween a simple ASCII preamble and postamble. > Paging PEM files with less > does NOT show ^M at the end of each or any line. None are expected on a Unix system, and on Windows you'd need to elect to view the content as a binary file. > Are PEM files, e.g. the private key pair files and certificate files > needed by Web servers, necessarily in US-ASCII? See above, but note that "explanatory text" can contain data in some unspecified local encoding, e.g. UTF-8. https://tools.ietf.org/html/rfc7468#section-5.2 > Are PEM files typically/conventionally stored in the line break > encoding of the native operating system? Yes. > Should PEM files always or normally be transmitted with the > line break encoding? The spec seems to allow any of CRLF/LF/CR, but my guess is that CRL is safest for the wire form. -- Viktor. From hari-sahaya.tiwari at hpe.com Tue Jan 28 14:03:09 2020 From: hari-sahaya.tiwari at hpe.com (Tiwari, Hari Sahaya) Date: Tue, 28 Jan 2020 14:03:09 +0000 Subject: SSL_connect fails on systemd socket Message-ID: Hi, I am trying to implement a client server program over SSL through systemd. Here I have a TCP systemd socket (listening on a predefined port) and its associated service. systemd socket file:- # cat /usr/lib/systemd/system/test_ssl.socket [Unit] Description=Test socket [Socket] ListenStream=2000 Accept=true MaxConnections=900 [Install] WantedBy=sockets.target systemd service file:- # cat /usr/lib/systemd/system/test_ssl at .service [Unit] Description= Test Service Requires=test_ssl.socket [Service] ExecStart=/home/SSL/server StandardInput=socket KillMode=process [Install] WantedBy=multi-user.target The service file invoke the binary /home/SSL/server. Here is it a very simple client server program, where 1. Server binds and listens on a port number. 2. Client first connects to server with normal connect (server will do accept) 3. Once it gets the fd, client does the SSL_connect over same connection. (server will do SSL_accept) 4. After that it will be SSL_read & SSL_write. Once, I start the systemd socket I can see the systemd starts listening on port 2000. # systemctl start test_ssl.socket # netstat -an | grep 2000 tcp6 0 0 :::2000 :::* LISTEN Post than when executing client, SSL_conect fails. # ./client localhost 2000 OpenConnection succedeed. << normal connect succeeds. SSL_connect failed. 140691172779952:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:365: Here client is able to do normal connect, post that SSL_connect fails. This client server program works well outside of systemd. Do I need to add some extra steps to get this working? Any help or reference would be appreciated. Thanks & Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From jqian at tibco.com Tue Jan 28 14:33:02 2020 From: jqian at tibco.com (Jason Qian) Date: Tue, 28 Jan 2020 09:33:02 -0500 Subject: help on openssl api for encryption Message-ID: Hi, Tried the example on: https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption On the Linux platform, when I set plaintext to "jason", it works fine. When I set it to "Jason", it returns an empty string. It works fine on windows platform for both cases. Thanks for your help, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Jan 28 14:57:03 2020 From: matt at openssl.org (Matt Caswell) Date: Tue, 28 Jan 2020 14:57:03 +0000 Subject: SSL_connect fails on systemd socket In-Reply-To: References: Message-ID: <22131c8a-cd80-a66a-ccfd-4bd0e1aa7867@openssl.org> On 28/01/2020 14:03, Tiwari, Hari Sahaya wrote: > 140691172779952:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong > version number:s3_pkt.c:365: You don't say, but from the reference to s3_pkt.c above I assume you are using OpenSSL 1.0.2 This error means that the server has received a record that has the wrong protocol version number in it. It has progressed far enough along the line that it has already processed the initial ClientHello from the client and is now trying to read some later record from the client. Because it has already processed the initial ClientHello we have already determined which protocol version is in use, so all records should use that protocol version in their headers. In the case of this error we've received something other than that version. This usually occurs because of some corruption of the data. Are you also using OpenSSL 1.0.2 on the client? Matt > > Here client is able to do normal connect, post that SSL_connect fails. > > ? > > This client server program works well outside of systemd. > > ? > > Do I need to add some extra steps to get this working? > > Any help or reference would be appreciated. > > ? > > Thanks & Regards, > > ? > > ? > From dheinz at softwarekey.com Tue Jan 28 18:24:06 2020 From: dheinz at softwarekey.com (Dan Heinz) Date: Tue, 28 Jan 2020 18:24:06 +0000 Subject: Decryption slower in 1.1.1 branch? In-Reply-To: <20200127190308.GT73491@straasha.imrryr.org> References: <20200127190308.GT73491@straasha.imrryr.org> Message-ID: Thank you for the information, Victor. >> I upgraded a library that used OpenSSL 1.0.2 to the OpenSSL 1.1.1d. >> On Windows, I have found that the time to decrypt had doubled. After >> a bit of timestamp logging, I found the RSA_private_decrypt function >> is taking twice as long with 1.1.1d as it did with 1.0.2t. This is >> being called from a Windows 64-bit DLL. >RSA is not intended for bulk data decryption, its intended uses are key transport and signing. Bulk data decryption is done via AES or similar. >> For example, decrypting 8680 bytes of data averages about .3 seconds >> with the OpenSSL 1.0.2t library (statically linked). Decrypting the >> same data with the OpenSSL 1.1.1d library averages about .6 seconds. >Are you sure that's seconds and not milliseconds? These are absurdly long times, almost certainly dominated by factors other than the encryption algorithms. On my 2015 laptop (MacOS) I get: Yes, it is seconds. Our library source is cross-platform and I tested on Linux with execution times around 20 milliseconds. This was with a static build rather than shared on Linux. I'm running the Linux tests on a VM on the same machine I am testing the Windows builds. Yet, the Windows build is much slower. Same source code. That's why I initially thought it was something in my OpenSSL configure parameters. While I'm ok with the execution speed with OpenSSL 1.0.2, I'd like to figure out why the times doubled with OpenSSL 1.1.1. I'm logging times before and after the calls to RSA_private_decrypt. With OpenSSL 1.0.2 it takes on average about 4-8 milliseconds for each RSA_private_decrypt call. With OpenSSL 1.1.1d, it takes 10-15 milliseconds for each RSA_private_decrypt call. No code changes other than what was needed such as changing the direct calls to the RSA structure fields. >> I'm wondering if perhaps my build configuration is incorrect or >> missing something for the 1.1.1d build. Here are the configuration >> parameters for the 64-bit build: >There's probably a deeper issue with what you're doing, you need to be much more specific about what you're measuring. Is this SMIME? CMS? >What is the RSA key size? What is the bulk encryption cipher? The data being decrypted is local on the client machine and is just an XML file. RSA key is 1024 bits. I'm using OAEP padding. > Configure VC-WIN64A --prefix=%RootPath_ThirdParty%\%OPENSSL_VERSION% > -DPURIFY -DOPENSSL_NO_COMP -D_USING_V110_SDK71_ no-shared no-asm > no-idea no-mdc2 no-rc5 no-ssl2 no-ssl3 no-zlib no-comp no-pinshared >PURIFY must not be enabled in production builds, it is only for memory allocation/safety debugging. You've also disabled assembly optimizations, which reduces side-channel resistance and hurts performance. Thank you for the information. I removed it from the configuration parameters. I didn't really notice a difference in execution time though. I also removed the no-asm parameter, setup nasm, and rebuilt with no noticeable changes. > I logged things granular enough to see the speed difference was in > RSA_private_decrypt, but I'm not sure why it is so much slower with > 1.1.1d. Any help or ideas would be appreciated! >At 600ms for 8KB, it is not plausible that the time is spend doing cryptography. That's barely fast enough to feed a 1980's modem. I would expect the execution times to be more in line with what I saw with Linux for both 1.0.2 and 1.1.1. But even so, I do not understand why just upgrading to 1.1.1 causes the RSA_private_decrypt calls to double in execution time from what they were with 1.0.2? From rsalz at akamai.com Tue Jan 28 19:20:19 2020 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 28 Jan 2020 19:20:19 +0000 Subject: Poll on manpages Message-ID: The next release of OpenSSL splits the ?help? for commands into sections, like this: ; ./apps/openssl rehash --help Usage: rehash [options] [directory...] General options: -help Display this summary -h Display this summary -compat Create both new- and old-style hash links -old Use old-style hash to generate links -n Do not remove existing links Output options: -v Verbose output Parameters: directory One or more directories to process (optional) Should the order of options in the manpages follow this layout? Should there be a blank line (in the SYNOPSIS section!) between the option sections? Please take a look at https://github.com/openssl/openssl/pull/10885 which does this for s_client. You can see just the changed file here: https://github.com/openssl/openssl/blob/71d8c19554a65cf0717f6b7e7b34849456e76888/doc/man1/openssl-s_client.pod.in Replies to me will be summarized for the list. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan.rahn at gmail.com Tue Jan 28 19:28:27 2020 From: ethan.rahn at gmail.com (Ethan Rahn) Date: Tue, 28 Jan 2020 11:28:27 -0800 Subject: Poll on manpages In-Reply-To: References: Message-ID: Rich, If no-one else tells you, keeping the docs up to date is amazing work and thank you for it. My general thought is that all docs should be consistent with one another for ease of cross referncing and skimming and the manpages should follow the same layout. Cheers, Ethan On Tue, Jan 28, 2020 at 11:21 AM Salz, Rich via openssl-users < openssl-users at openssl.org> wrote: > The next release of OpenSSL splits the ?help? for commands into sections, > like this: > > > > ; ./apps/openssl rehash --help > > Usage: rehash [options] [directory...] > > > > General options: > > -help Display this summary > > -h Display this summary > > -compat Create both new- and old-style hash links > > -old Use old-style hash to generate links > > -n Do not remove existing links > > > > Output options: > > -v Verbose output > > > > Parameters: > > directory One or more directories to process (optional) > > > > Should the order of options in the manpages follow this layout? Should > there be a blank line (in the SYNOPSIS section!) between the option > sections? Please take a look at > https://github.com/openssl/openssl/pull/10885 which does this for > s_client. You can see just the changed file here: > https://github.com/openssl/openssl/blob/71d8c19554a65cf0717f6b7e7b34849456e76888/doc/man1/openssl-s_client.pod.in > > > > Replies to me will be summarized for the list. Thanks! > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Jan 28 20:34:27 2020 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 28 Jan 2020 15:34:27 -0500 Subject: Decryption slower in 1.1.1 branch? In-Reply-To: References: <20200127190308.GT73491@straasha.imrryr.org> Message-ID: <20200128203427.GY73491@straasha.imrryr.org> On Tue, Jan 28, 2020 at 06:24:06PM +0000, Dan Heinz wrote: > >RSA is not intended for bulk data decryption, its intended uses are > >key transport and signing. Bulk data decryption is done via AES or > >similar. It sounds like you're directly encrypting data with RSA. That's a mistake. RSA is for decrypting a symmetric algorithm key, that then decrypts the data. > >Are you sure that's seconds and not milliseconds? These are absurdly > >long times, almost certainly dominated by factors other than the > >encryption algorithms. On my 2015 laptop (MacOS) I get: > > Yes, it is seconds. Sorry, 0.6 seconds for a single 1024-bit RSA_private_decrypt() (128 bytes of data) is not plausible, but you say you have just over 8KB of data, which would take ~65 calls to RSA_private_decrypt() to decrypt piecewise. It sure looks like you're measuring something other than what you claim to be measuring, or not describing it accurately. OpenSSL 1.1.1c-dev xx XXX xxxx options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: cc -fPIC -arch x86_64 -g -O0 -Wall -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT sign verify sign/s verify/s rsa 1024 bits 0.000135s 0.000013s 7414.8 78566.9 On my laptop RSA_private_decrypt (aka sign) takes 135 microseconds. You claim 600 milliseconds for perhaps ~60 calls, which might be 10ms each, but that still is about two orders of magnitude too slow. So, sorry whatever you're measuring, it is not the performance of RSA_private_decrypt(). > While I'm ok with the execution speed with OpenSSL 1.0.2, I'd like to > figure out why the times doubled with OpenSSL 1.1.1. Neither is a reasonable performance level, but also it is not reasonable to use RSA for bulk data encryption. > I'm logging times before and after the calls to RSA_private_decrypt. How many calls? What else is happening to feed the data into the decryption algorithm, and reassemble the output? > With OpenSSL 1.0.2 it takes on average about 4-8 milliseconds for each > RSA_private_decrypt call. With OpenSSL 1.1.1d, it takes 10-15 > milliseconds for each RSA_private_decrypt call. Now we see that you're in fact chunking data for multiple calls to "decrypt" via RSA. That's a fatal design flaw. This is not a valid operating mode for RSA. You MUST NOT do this. > >> I'm wondering if perhaps my build configuration is incorrect or > >> missing something for the 1.1.1d build. Here are the configuration > >> parameters for the 64-bit build: You have a deeper problem, your use of RSA is broken. > The data being decrypted is local on the client machine and is just an XML file. > RSA key is 1024 bits. > I'm using OAEP padding. This is a mistake, for asymmetric encryption you should be using CMS. > Thank you for the information. I removed it from the configuration > parameters. I didn't really notice a difference in execution time > though. I also removed the no-asm parameter, setup nasm, and rebuilt > with no noticeable changes. Likely the time is dominated by something other than the RSA operations, but since those are mistake anyway, it hardly matters. > > I logged things granular enough to see the speed difference was in > > RSA_private_decrypt, but I'm not sure why it is so much slower with > > 1.1.1d. Any help or ideas would be appreciated! STOP. Fix your design to use CMS. Report any performance differences in CMS between 1.0.2 and 1.1.1 when built correctly with asm support. > >At 600ms for 8KB, it is not plausible that the time is spend doing > >cryptography. That's barely fast enough to feed a 1980's modem. > > I would expect the execution times to be more in line with what I saw > with Linux for both 1.0.2 and 1.1.1. But even so, I do not understand > why just upgrading to 1.1.1 causes the RSA_private_decrypt calls to > double in execution time from what they were with 1.0.2? I would expect execution times that are 2 to 3 orders of magnitude faster, especially if you were using sound cryptographic primitives. -- Viktor. From Michael.Wojcik at microfocus.com Wed Jan 29 16:03:35 2020 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 29 Jan 2020 16:03:35 +0000 Subject: Determine that there is no forward progress with non blocking SSL socket In-Reply-To: References: Message-ID: > From: Eran Borovik [mailto:eran.borovik at gmail.com] > Sent: Wednesday, January 29, 2020 07:32 Please respond to the list rather than directly to me, since the subject may be of interest to other readers. I'm including the list in this response. > The only thing that still confuses me is that if I am reading the docs > correctly, SSL_read may return SSL_WANT_WRITE and SSL_write may return > SSL_WANT_READ even when they don't encounter a blocking condition, but > because of negotiation. Right. > Now, I use edge triggered polling with Epoll (EPOLLET), which means > that if SSL_read/write decides to give me an WANT* status when the > socket doesn't have a blocking condition, then epoll will never wake > and I am stuck (unless I understand that this is the case and retry > immediately). Is there a way to actually understand that there is a > blocking condition in the socket from OpenSSL or do I need to use > select with zero timeout to realize what is the correct condition of > the socket after each time SSL gives me SSL_WANT*? Yes, I think you need to test for readability / writability at some point. You can do that immediately when you get a WANT_*, or you can have your epoll time out periodically and test then if you have pending I/O. Personally, I'm leery of edge-triggered activation for this reason. It's too easy to miss some race condition or other case where you might end up blocked forever. I'd always have epoll time out so you can do a level-poll of all sockets that have pending operations; that turns a failure mode into one that simply has suboptimal performance, at a small resource cost. -- Michael Wojcik Distinguished Engineer, Micro Focus From eran.borovik at gmail.com Wed Jan 29 16:50:46 2020 From: eran.borovik at gmail.com (Eran Borovik) Date: Wed, 29 Jan 2020 18:50:46 +0200 Subject: Determine that there is no forward progress with non blocking SSL socket In-Reply-To: References: Message-ID: Hi, Excellent, so I think I am finally understanding this correctly. And yes, we do have epoll timeouts to clean up all sort of missed race conditions and bugs (either in kernel or user mode). For performance reasons, EDGE trigger is a must for my application. What if instead of using select to understand the socket status (big hammer), I will simple retry the call? For example, if SSL_read returns WANT_*, I do another SSL_read. On the low chance that this is a negotiation, there will be forward progress and I am fine. If not, I know that the socket is blocked. It is too bad that I cannot differentiate between the two states without going to kernel space. I wish there were some way by just querying SSL. I see that there is a family of SSL_want* methods. Can these be of use? Regards, Eran. On Wed, Jan 29, 2020 at 6:12 PM Michael Wojcik < Michael.Wojcik at microfocus.com> wrote: > > From: Eran Borovik [mailto:eran.borovik at gmail.com] > > Sent: Wednesday, January 29, 2020 07:32 > > Please respond to the list rather than directly to me, since the subject > may be of interest to other readers. I'm including the list in this > response. > > > The only thing that still confuses me is that if I am reading the docs > > correctly, SSL_read may return SSL_WANT_WRITE and SSL_write may return > > SSL_WANT_READ even when they don't encounter a blocking condition, but > > because of negotiation. > > Right. > > > Now, I use edge triggered polling with Epoll (EPOLLET), which means > > that if SSL_read/write decides to give me an WANT* status when the > > socket doesn't have a blocking condition, then epoll will never wake > > and I am stuck (unless I understand that this is the case and retry > > immediately). Is there a way to actually understand that there is a > > blocking condition in the socket from OpenSSL or do I need to use > > select with zero timeout to realize what is the correct condition of > > the socket after each time SSL gives me SSL_WANT*? > > Yes, I think you need to test for readability / writability at some > point. You can do that immediately when you get a WANT_*, or you can > have your epoll time out periodically and test then if you have > pending I/O. > > Personally, I'm leery of edge-triggered activation for this reason. > It's too easy to miss some race condition or other case where you > might end up blocked forever. I'd always have epoll time out so you > can do a level-poll of all sockets that have pending operations; > that turns a failure mode into one that simply has suboptimal > performance, at a small resource cost. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hari-sahaya.tiwari at hpe.com Wed Jan 29 17:28:20 2020 From: hari-sahaya.tiwari at hpe.com (Tiwari, Hari Sahaya) Date: Wed, 29 Jan 2020 17:28:20 +0000 Subject: SSL_connect fails on systemd socket In-Reply-To: <22131c8a-cd80-a66a-ccfd-4bd0e1aa7867@openssl.org> References: <22131c8a-cd80-a66a-ccfd-4bd0e1aa7867@openssl.org> Message-ID: Yes, client is also on same version 1.0.2 In this case SSL handshake(SSL_connect & SSL_accept) is done through systemd socket/service, which is failing. Any references around it will be very helpful. Regards, Hari. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Tuesday, January 28, 2020 8:27 PM To: openssl-users at openssl.org Subject: Re: SSL_connect fails on systemd socket On 28/01/2020 14:03, Tiwari, Hari Sahaya wrote: > 140691172779952:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong > version number:s3_pkt.c:365: You don't say, but from the reference to s3_pkt.c above I assume you are using OpenSSL 1.0.2 This error means that the server has received a record that has the wrong protocol version number in it. It has progressed far enough along the line that it has already processed the initial ClientHello from the client and is now trying to read some later record from the client. Because it has already processed the initial ClientHello we have already determined which protocol version is in use, so all records should use that protocol version in their headers. In the case of this error we've received something other than that version. This usually occurs because of some corruption of the data. Are you also using OpenSSL 1.0.2 on the client? Matt > > Here client is able to do normal connect, post that SSL_connect fails. > > ? > > This client server program works well outside of systemd. > > ? > > Do I need to add some extra steps to get this working? > > Any help or reference would be appreciated. > > ? > > Thanks & Regards, > > ? > > ? > From matt at openssl.org Wed Jan 29 17:43:37 2020 From: matt at openssl.org (Matt Caswell) Date: Wed, 29 Jan 2020 17:43:37 +0000 Subject: SSL_connect fails on systemd socket In-Reply-To: References: <22131c8a-cd80-a66a-ccfd-4bd0e1aa7867@openssl.org> Message-ID: On 29/01/2020 17:28, Tiwari, Hari Sahaya wrote: > Yes, client is also on same version 1.0.2 > In this case SSL handshake(SSL_connect & SSL_accept) is done through systemd socket/service, which is failing. > Any references around it will be very helpful. What kind of BIO are you using for reading the data in the server? Is it possible to get a wireshark trace of the failing handshake? Matt > > Regards, > Hari. > > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell > Sent: Tuesday, January 28, 2020 8:27 PM > To: openssl-users at openssl.org > Subject: Re: SSL_connect fails on systemd socket > > > > On 28/01/2020 14:03, Tiwari, Hari Sahaya wrote: >> 140691172779952:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong >> version number:s3_pkt.c:365: > > You don't say, but from the reference to s3_pkt.c above I assume you are using OpenSSL 1.0.2 > > This error means that the server has received a record that has the wrong protocol version number in it. It has progressed far enough along the line that it has already processed the initial ClientHello from the client and is now trying to read some later record from the client. > Because it has already processed the initial ClientHello we have already determined which protocol version is in use, so all records should use that protocol version in their headers. In the case of this error we've received something other than that version. > > This usually occurs because of some corruption of the data. > > Are you also using OpenSSL 1.0.2 on the client? > > Matt > >> >> Here client is able to do normal connect, post that SSL_connect fails. >> >> ? >> >> This client server program works well outside of systemd. >> >> ? >> >> Do I need to add some extra steps to get this working? >> >> Any help or reference would be appreciated. >> >> ? >> >> Thanks & Regards, >> >> ? >> >> ? >> > From beldmit at gmail.com Thu Jan 30 12:28:21 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 30 Jan 2020 15:28:21 +0300 Subject: TLS 1.3 limiting SignatureScheme Message-ID: Hello, How can I limit SignatureScheme ( https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme) announced by client when using TLS 1.3? I'm interested in a solution either for 1.1.1 (preferred) or 3. Many thanks! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Thu Jan 30 13:48:32 2020 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 30 Jan 2020 16:48:32 +0300 Subject: TLS 1.3 limiting SignatureScheme In-Reply-To: References: Message-ID: Hello, -sigalgs does the trick. On Thu, Jan 30, 2020 at 3:28 PM Dmitry Belyavsky wrote: > Hello, > > How can I limit SignatureScheme ( > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme) > announced by client when using TLS 1.3? > > I'm interested in a solution either for 1.1.1 (preferred) or 3. > > Many thanks! > > -- > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougbmorris at yahoo.com Thu Jan 30 20:03:06 2020 From: dougbmorris at yahoo.com (Douglas Morris) Date: Thu, 30 Jan 2020 20:03:06 +0000 (UTC) Subject: And that's how text-ish PEM files are. References: <1719590614.372761.1580414586413.ref@mail.yahoo.com> Message-ID: <1719590614.372761.1580414586413@mail.yahoo.com> Victor, Thanks for that walk-through explanation. I probably get it even. I should have followed the reference for the definition of eol in Section 3 of RFC 7468. It was only one more human stack call. I appreciate the clarification on the valid text encoding of explanatory text and of the header and footer lines (the not safe base64 stuff with is obvious enough). I will endeavor to send on wire with but not expect that to come back. For all I know, Python will do or already does that for me. I'll have to figure that out. Douglas Morris -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougbmorris at yahoo.com Thu Jan 30 20:38:25 2020 From: dougbmorris at yahoo.com (Douglas Morris) Date: Thu, 30 Jan 2020 20:38:25 +0000 (UTC) Subject: Cloning a CSR or Cert. for a new CSR with a new key? References: <1630650518.390012.1580416705766.ref@mail.yahoo.com> Message-ID: <1630650518.390012.1580416705766@mail.yahoo.com> I am trying to implement automated domain certificate renewal. A certificate signing request is sent to an ACME server and on success a certificate is returned. I'd like to be able to call OpenSSL to make a new key and then make a new certificate signing request just like the old one except for the replacement key pair file. I suppose the complete information beyond the new key data is available both in the old crs and the old certificate. I'm looking at the manpages of OpenSSL subcommands 'req' and 'x509'. The openssl x509 option '-x509toreq' gave me a momentary rush of hope, but then I read about the '-signkey' option, which seems to be exclusively about self-signing. Is 'cloning' the csr or cert. information semantically logical? Is it possible with OpenSSL? If I can't reliably extract the relevant data from the old csr or old certification, I suppose I must do it as usual with a dedicated config file and the '-batch' option:???? openssl req -key -new -config -outform PEM -out -batch Any do's or don't on managing the input data of a signing request for automatic renewal (non-interactive execution)? I'm trying to minimize the file management requirements without losing generality. Douglas Morris -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirkx at webweaving.org Thu Jan 30 20:50:13 2020 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Thu, 30 Jan 2020 21:50:13 +0100 Subject: Cloning a CSR or Cert. for a new CSR with a new key? In-Reply-To: <1630650518.390012.1580416705766@mail.yahoo.com> References: <1630650518.390012.1580416705766.ref@mail.yahoo.com> <1630650518.390012.1580416705766@mail.yahoo.com> Message-ID: <9FD2B9B3-2A02-4B62-A131-30BF66EA97E5@webweaving.org> > On 30 Jan 2020, at 21:38, Douglas Morris via openssl-users wrote: > > I am trying to implement automated domain certificate renewal. A certificate signing request is sent to an ACME server and on success a certificate is returned. I'd like to be able to call OpenSSL to make a new key and then make a new certificate signing request just like the old one except for the replacement key pair file. > > I suppose the complete information beyond the new key data is available both in the old crs and the old certificate. I'm looking at the manpages of OpenSSL subcommands 'req' and 'x509'. The openssl x509 option '-x509toreq' gave me a momentary rush of hope, but then I read about the '-signkey' option, which seems to be exclusively about self-signing. > > Is 'cloning' the csr or cert. information semantically logical? Is it possible with OpenSSL? > > If I can't reliably extract the relevant data from the old csr or old certification, I suppose I must do it as usual with a dedicated config file and the '-batch' option: > openssl req -key -new -config -outform PEM -out -batch openssl x509 -x509toreq should do the trick E.g. # generate test cert openssl req -x509 -new -subj /CN=foo -nodes -keyout x.key > x.crt openssl x509 -in x.crt -noout -text # turn test cert in a request openssl x509 -x509toreq -signkey x.key < x.crt Dw -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougbmorris at yahoo.com Fri Jan 31 00:25:38 2020 From: dougbmorris at yahoo.com (Douglas Morris) Date: Fri, 31 Jan 2020 00:25:38 +0000 (UTC) Subject: Cloning a CSR or Cert. for a new CSR with a new key? In-Reply-To: <9FD2B9B3-2A02-4B62-A131-30BF66EA97E5@webweaving.org> References: <1630650518.390012.1580416705766.ref@mail.yahoo.com> <1630650518.390012.1580416705766@mail.yahoo.com> <9FD2B9B3-2A02-4B62-A131-30BF66EA97E5@webweaving.org> Message-ID: <651488668.460532.1580430338217@mail.yahoo.com> Thanks, Dw. Interesting. I think I misunderstood this explanation about the -signkey option: "This option causes the input file to be self signed using the supplied private key." Your input has me thinking that a certificate signing request is in fact self-signed like a self-signed certificate is self-signed. I think I mistakenly supposed any self-signing meant acting like a "mini CA". I shall give those two x509 options, '-x509toreq' and '-signkey', a try. Douglas Morris On Thursday, January 30, 2020, 3:51:45 PM EST, Dirk-Willem van Gulik wrote: On 30 Jan 2020, at 21:38, Douglas Morris via openssl-users wrote: I am trying to implement automated domain certificate renewal. A certificate signing request is sent to an ACME server and on success a certificate is returned. I'd like to be able to call OpenSSL to make a new key and then make a new certificate signing request just like the old one except for the replacement key pair file. I suppose the complete information beyond the new key data is available both in the old crs and the old certificate. I'm looking at the manpages of OpenSSL subcommands 'req' and 'x509'. The openssl x509 option '-x509toreq' gave me a momentary rush of hope, but then I read about the '-signkey' option, which seems to be exclusively about self-signing. Is 'cloning' the csr or cert. information semantically logical? Is it possible with OpenSSL? If I can't reliably extract the relevant data from the old csr or old certification, I suppose I must do it as usual with a dedicated config file and the '-batch' option:???? openssl req -key -new -config -outform PEM -out -batch openssl x509 -x509toreq should do the trick E.g. # generate test cert openssl req -x509 -new -subj /CN=foo -nodes -keyout x.key > x.crt openssl x509 -in x.crt -noout -text # turn test cert in a request openssl x509 -x509toreq -signkey x.key < x.crt Dw -------------- next part -------------- An HTML attachment was scrubbed... URL: From hari-sahaya.tiwari at hpe.com Fri Jan 31 06:47:50 2020 From: hari-sahaya.tiwari at hpe.com (Tiwari, Hari Sahaya) Date: Fri, 31 Jan 2020 06:47:50 +0000 Subject: SSL_connect fails on systemd socket In-Reply-To: References: <22131c8a-cd80-a66a-ccfd-4bd0e1aa7867@openssl.org> Message-ID: Hi Matt, I got it working through systemd. My server program needed some modifications to properly respond to SSL_connect. Thanks for your assistance. Regards, Hari. -----Original Message----- From: Matt Caswell [mailto:matt at openssl.org] Sent: Wednesday, January 29, 2020 11:14 PM To: Tiwari, Hari Sahaya ; openssl-users at openssl.org Subject: Re: SSL_connect fails on systemd socket On 29/01/2020 17:28, Tiwari, Hari Sahaya wrote: > Yes, client is also on same version 1.0.2 In this case SSL > handshake(SSL_connect & SSL_accept) is done through systemd socket/service, which is failing. > Any references around it will be very helpful. What kind of BIO are you using for reading the data in the server? Is it possible to get a wireshark trace of the failing handshake? Matt > > Regards, > Hari. > > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Matt Caswell > Sent: Tuesday, January 28, 2020 8:27 PM > To: openssl-users at openssl.org > Subject: Re: SSL_connect fails on systemd socket > > > > On 28/01/2020 14:03, Tiwari, Hari Sahaya wrote: >> 140691172779952:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong >> version number:s3_pkt.c:365: > > You don't say, but from the reference to s3_pkt.c above I assume you > are using OpenSSL 1.0.2 > > This error means that the server has received a record that has the wrong protocol version number in it. It has progressed far enough along the line that it has already processed the initial ClientHello from the client and is now trying to read some later record from the client. > Because it has already processed the initial ClientHello we have already determined which protocol version is in use, so all records should use that protocol version in their headers. In the case of this error we've received something other than that version. > > This usually occurs because of some corruption of the data. > > Are you also using OpenSSL 1.0.2 on the client? > > Matt > >> >> Here client is able to do normal connect, post that SSL_connect fails. >> >> ? >> >> This client server program works well outside of systemd. >> >> ? >> >> Do I need to add some extra steps to get this working? >> >> Any help or reference would be appreciated. >> >> ? >> >> Thanks & Regards, >> >> ? >> >> ? >> > From aerowolf at gmail.com Fri Jan 31 07:14:00 2020 From: aerowolf at gmail.com (Kyle Hamilton) Date: Fri, 31 Jan 2020 01:14:00 -0600 Subject: Cloning a CSR or Cert. for a new CSR with a new key? In-Reply-To: <651488668.460532.1580430338217@mail.yahoo.com> References: <1630650518.390012.1580416705766.ref@mail.yahoo.com> <1630650518.390012.1580416705766@mail.yahoo.com> <9FD2B9B3-2A02-4B62-A131-30BF66EA97E5@webweaving.org> <651488668.460532.1580430338217@mail.yahoo.com> Message-ID: A CSR is self-signed to provide what's called "proof of possession" -- that is, proof that the requester possesses the private key to the claimed public key. It doesn't act as a CA in that case, because the CSR is not an actual Certificate structure. -Kyle H On Thu, Jan 30, 2020, 18:26 Douglas Morris via openssl-users < openssl-users at openssl.org> wrote: > Thanks, Dw. > > Interesting. I think I misunderstood this explanation about the -signkey > option: "This option causes the input file to be self signed using > the supplied private key." > > Your input has me thinking that a certificate signing request is in fact > self-signed like a self-signed certificate is self-signed. I think I > mistakenly supposed any self-signing meant acting like a "mini CA". I shall > give those two x509 options, '-x509toreq' and '-signkey', a try. > > Douglas Morris > > > On Thursday, January 30, 2020, 3:51:45 PM EST, Dirk-Willem van Gulik < > dirkx at webweaving.org> wrote: > > > > > On 30 Jan 2020, at 21:38, Douglas Morris via openssl-users < > openssl-users at openssl.org> wrote: > > I am trying to implement automated domain certificate renewal. A > certificate signing request is sent to an ACME server and on success a > certificate is returned. I'd like to be able to call OpenSSL to make a new > key and then make a new certificate signing request just like the old one > except for the replacement key pair file. > > I suppose the complete information beyond the new key data is available > both in the old crs and the old certificate. I'm looking at the manpages of > OpenSSL subcommands 'req' and 'x509'. The openssl x509 option '-x509toreq' > gave me a momentary rush of hope, but then I read about the '-signkey' > option, which seems to be exclusively about self-signing. > > Is 'cloning' the csr or cert. information semantically logical? Is it > possible with OpenSSL? > > If I can't reliably extract the relevant data from the old csr or old > certification, I suppose I must do it as usual with a dedicated config file > and the '-batch' option: > openssl req -key -new -config -outform PEM -out > -batch > > > openssl x509 -x509toreq should do the trick > > E.g. > > # generate test cert > openssl req -x509 -new -subj /CN=foo -nodes -keyout x.key > x.crt > openssl x509 -in x.crt -noout -text > > # turn test cert in a request > openssl x509 -x509toreq -signkey x.key < x.crt > > Dw > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirkx at webweaving.org Fri Jan 31 09:39:53 2020 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Fri, 31 Jan 2020 10:39:53 +0100 Subject: Cloning a CSR or Cert. for a new CSR with a new key? In-Reply-To: <651488668.460532.1580430338217@mail.yahoo.com> References: <1630650518.390012.1580416705766.ref@mail.yahoo.com> <1630650518.390012.1580416705766@mail.yahoo.com> <9FD2B9B3-2A02-4B62-A131-30BF66EA97E5@webweaving.org> <651488668.460532.1580430338217@mail.yahoo.com> Message-ID: <84358599-502B-42BE-8522-203F82E61FE8@webweaving.org> On 31 Jan 2020, at 01:25, Douglas Morris > wrote: > Interesting. I think I misunderstood this explanation about the -signkey option: "This option causes the input file to be self signed using the supplied private key." > > Your input has me thinking that a certificate signing request is in fact self-signed like a self-signed certificate is self-signed. I think I mistakenly supposed any self-signing meant acting like a "mini CA". I shall give those two x509 options, '-x509toreq' and '-signkey', a try. Correct - a CSR is generally signed by the party submitting it - thus proving that he or she has access to their own private key. Dw. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougbmorris at yahoo.com Fri Jan 31 18:59:42 2020 From: dougbmorris at yahoo.com (Douglas Morris) Date: Fri, 31 Jan 2020 18:59:42 +0000 (UTC) Subject: Cloning a CSR or Cert. for a new CSR with a new key? In-Reply-To: <84358599-502B-42BE-8522-203F82E61FE8@webweaving.org> References: <1630650518.390012.1580416705766.ref@mail.yahoo.com> <1630650518.390012.1580416705766@mail.yahoo.com> <9FD2B9B3-2A02-4B62-A131-30BF66EA97E5@webweaving.org> <651488668.460532.1580430338217@mail.yahoo.com> <84358599-502B-42BE-8522-203F82E61FE8@webweaving.org> Message-ID: <1024005125.792283.1580497182822@mail.yahoo.com> Thanks everyone for the replies and the community support. I don't think I got across what I am trying to do. I have experimented with subcommands req and x509. The openssl x509 -in -x509toreq -signkey does *NOT* do what I want (I'm pretty sure). openssl x509 -x509toreq may sign a certificate signing request (csr) with a different key, but (as far as I can tell via the -text output) it does not change the public key documented (does not change the RSA Public key modulus) in the output request to match the private signature file.? The -text output from the input and output csr's are identical. Neither do I see how a request (csr) could be provided to the subcommand x509 -x509toreq or to subcommand req to alter an existing csr to have a new domain authentication key (the documented public key). The req subcommand seems completely irrelevant to what I'd like to do. Is this an unusual use case? I believe I will have to use a config file via the -config option to support the creation of a new request with a new domain authentication key. Do I want to change my architecture to support that? No, cause it's working well from the given crs file, but I want domain key rollover on automatic renewal. If I must create a new csr from scratch to support domain key replacement, the csr is not a viable starting point, and neither is the certificate file from the CA. Is there a flaw in my logic? Douglas Morris On Friday, January 31, 2020, 4:42:21 AM EST, Dirk-Willem van Gulik wrote: On 31 Jan 2020, at 01:25, Douglas Morris wrote: Interesting. I think I misunderstood this explanation about the -signkey option: "This option causes the input file to be self signed using the supplied private key." Your input has me thinking that a certificate signing request is in fact self-signed like a self-signed certificate is self-signed. I think I mistakenly supposed any self-signing meant acting like a "mini CA". I shall give those two x509 options, '-x509toreq' and '-signkey', a try. Correct - a CSR is generally signed by the party submitting it - thus proving that he or she has access to their own private key. Dw. -------------- next part -------------- An HTML attachment was scrubbed... URL: