From arcbhat1234 at gmail.com Mon Mar 1 15:51:29 2021 From: arcbhat1234 at gmail.com (Archana) Date: Mon, 1 Mar 2021 21:21:29 +0530 Subject: Query on SSL Mutual Authentication on Server Message-ID: I am new to SSL programming. On our SSL Server implementation, we are trying to enforce Mutual Authentication. Is it Mandatory to provide a user defined Callback using SSL_ctx_setverify() If yes, Is it expected to do the IP or hostname validation? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Mar 1 16:28:28 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 1 Mar 2021 11:28:28 -0500 Subject: Query on SSL Mutual Authentication on Server In-Reply-To: References: Message-ID: On Mon, Mar 01, 2021 at 09:21:29PM +0530, Archana wrote: > I am new to SSL programming. On our SSL Server implementation, we are > trying to enforce Mutual Authentication. Is it Mandatory to provide a user > defined Callback using SSL_ctx_setverify() No callback is required (callbacks are primarily useful for logging, though they can also, with care, be used to make chain verification more "permissive", but there be dragons). However, you must then still call: int mode = SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT | SSL_VERIFY_CLIENT_ONCE; SSL_CTX_set_verify(ctx, mode, NULL); to set the verification mode to request (and enforce) the presence of a client certificate. Depending on the client, you may also need to make sure to provide a non-empty list of client CA hints that includes all the trust-anchor CAs from which you'll accept client certificate chains. (Clients using Java SSL APIs typically require that to be the case). This can be done via: const char *CAfile = "/your/CA/file"; STACK_OF(X509_NAME) *calist = SSL_load_client_CA_file(CAfile); if (calist == NULL) { /* log error loading client CA names */ } SSL_CTX_set_client_CA_list(server_ctx, calist); > If yes, Is it expected to do the IP or hostname validation? Neither, authorization of the client is up to you. OpenSSL will check the dates, validity of the signatures, ... in the clients certificate chain, but checking whether any of the subject names in the client certificate are allowed to access your server is up to you. There is no prior expectation that the client's certificate is specifically related to its IP address or hostname. You may in fact, depending on the structure of your code, be able to configure the expected client name prior to the SSL handshake with SSL_accept(3), but after accepting the client TCP connection. To set the expected hostname(s), see the documentation of: int SSL_set1_host(SSL *s, const char *hostname); int SSL_add1_host(SSL *s, const char *hostname); For IP addresses, there's a slightly lower-level interface: X509_VERIFY_PARAM *SSL_CTX_get0_param(SSL_CTX *ctx); int X509_VERIFY_PARAM_set1_ip(X509_VERIFY_PARAM *param, const unsigned char *ip, size_t iplen); int X509_VERIFY_PARAM_set1_ip_asc(X509_VERIFY_PARAM *param, const char *ipasc); or after the handshake completes, you can call one of: int X509_check_host(X509 *, const char *name, size_t namelen, unsigned int flags, char **peername); int X509_check_email(X509 *, const char *address, size_t addresslen, unsigned int flags); int X509_check_ip(X509 *, const unsigned char *address, size_t addresslen, unsigned int flags); int X509_check_ip_asc(X509 *, const char *address, unsigned int flags); -- Viktor. From jb-openssl at wisemo.com Tue Mar 2 08:08:30 2021 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 2 Mar 2021 09:08:30 +0100 Subject: Query on SSL Mutual Authentication on Server In-Reply-To: References: Message-ID: On 2021-03-01 17:28, Viktor Dukhovni wrote: > On Mon, Mar 01, 2021 at 09:21:29PM +0530, Archana wrote: > >> I am new to SSL programming. On our SSL Server implementation, we are >> trying to enforce Mutual Authentication. Is it Mandatory to provide a user >> defined Callback using SSL_ctx_setverify() > No callback is required (callbacks are primarily useful for logging, > though they can also, with care, be used to make chain verification > more "permissive", but there be dragons). However, you must then > still call: > > int mode = SSL_VERIFY_PEER > | SSL_VERIFY_FAIL_IF_NO_PEER_CERT > | SSL_VERIFY_CLIENT_ONCE; > > SSL_CTX_set_verify(ctx, mode, NULL); > > to set the verification mode to request (and enforce) the presence of a > client certificate. Depending on the client, you may also need to make > sure to provide a non-empty list of client CA hints that includes all > the trust-anchor CAs from which you'll accept client certificate chains. > (Clients using Java SSL APIs typically require that to be the case). > > This can be done via: > > const char *CAfile = "/your/CA/file"; > STACK_OF(X509_NAME) *calist = SSL_load_client_CA_file(CAfile); > > if (calist == NULL) { > /* log error loading client CA names */ > } > SSL_CTX_set_client_CA_list(server_ctx, calist); > >> If yes, Is it expected to do the IP or hostname validation? > Neither, authorization of the client is up to you. OpenSSL will check > the dates, validity of the signatures, ... in the clients certificate > chain, but checking whether any of the subject names in the client > certificate are allowed to access your server is up to you. > > There is no prior expectation that the client's certificate is > specifically related to its IP address or hostname. > > You may in fact, depending on the structure of your code, be able to > configure the expected client name prior to the SSL handshake > with SSL_accept(3), but after accepting the client TCP connection. > > To set the expected hostname(s), see the documentation of: > > int SSL_set1_host(SSL *s, const char *hostname); > int SSL_add1_host(SSL *s, const char *hostname); > > For IP addresses, there's a slightly lower-level interface: > > X509_VERIFY_PARAM *SSL_CTX_get0_param(SSL_CTX *ctx); > > int X509_VERIFY_PARAM_set1_ip(X509_VERIFY_PARAM *param, > const unsigned char *ip, size_t iplen); > int X509_VERIFY_PARAM_set1_ip_asc(X509_VERIFY_PARAM *param, const char *ipasc); > > or after the handshake completes, you can call one of: > > int X509_check_host(X509 *, const char *name, size_t namelen, > unsigned int flags, char **peername); > int X509_check_email(X509 *, const char *address, size_t addresslen, > unsigned int flags); > int X509_check_ip(X509 *, const unsigned char *address, size_t addresslen, > unsigned int flags); > int X509_check_ip_asc(X509 *, const char *address, unsigned int flags); > Just out of curiousity: What is the recommended way to check the authenticated e-mail and/or DN of the client certificate, given that those are the most common identities in such certificates (except in server-to-server scenarios). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From sanjurohayami at hotmail.com Wed Mar 3 01:56:31 2021 From: sanjurohayami at hotmail.com (Yang Rong) Date: Wed, 3 Mar 2021 01:56:31 +0000 Subject: Question: How to using cert files on Android platform? Message-ID: Hello, I am new to OpenSSL. I am working on a project using JNI+ OpenSSL on an Android App. My task is to create a client to access some web services. Currently, I am able to use the default trust store (/etc/ssl/certs) on Ubuntu18.04 to access the web services. But based on https://stackoverflow.com/questions/15375577/how-to-point-openssl-to-the-root-certificates-on-an-android-device The OpenSSL is not able to use certs in the Android trust store. That is an old thread. Do we have a way to use the Android trust store in 2021? The target API level of the Android App is 28. If OpenSSL is still not able to use the Android default trust stores nowadays. I would like to copy the certs from Ubuntu to the Android app. But I need to figure out which pem file is used to establish connections. Is there a way any OpenSSL command line cmd is able to do that? Thanks Rong r0nG Auckland, New Zealand -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Mar 3 05:34:13 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 3 Mar 2021 00:34:13 -0500 Subject: Question: How to using cert files on Android platform? In-Reply-To: References: Message-ID: On Wed, Mar 03, 2021 at 01:56:31AM +0000, Yang Rong wrote: > I am new to OpenSSL. I am working on a project using JNI+ OpenSSL on > an Android App. Can you briefly explain your motivation for using OpenSSL via JNI, rather than just use the native android TLS APIs, which then just use the Android trust store? > The OpenSSL is not able to use certs in the Android trust store. The Android trust store is likely more fine-grained than you'd naively expect. Not all the trusted certificates are necessarily trusted for the same purposes. If you just extract the certificates, without the associated trust settings, you may well end up undermining some of the expected security properties, because some restricted use certificates may then lose their associated restrictions. > Do we have a way to use the Android trust store in 2021? The simplest and generally most appropriate answer is: via the Android APIs, and without JNI into OpenSSL. If you have a compelling reason to use OpenSSL, you'll probably need to provision a dedicated trust store of known to be appropriate trust anchors. > The target API level of the Android App is 28. If OpenSSL is > still not able to use the Android default trust stores nowadays. I > would like to copy the certs from Ubuntu to the Android app. If it is appropriate to trust the same root CAs (something probably along the lines of the Mozilla cert bundle), then you could do that, but why is this necessary? > But I need to figure out which pem file is used to establish > connections. Now it seems that you're not well versed in OpenSSL, which strongly suggests that it is really best to stick to the provided APIs, and not roll your own security toolkit. > Is there a way any OpenSSL command line cmd is able to do > that? Almost certainly, but your question is rather oddly phrased and not completely clear. PEM files don't establish connections. Are you looking to capture the entire Ubuntu trust store, or just the specific trust-anchor that is *currently* the ultimate issuer of the server's certificate chain? Do you have good reason to believe that the server will continue to use the same root CAs indefinitely? ... If your reasons for not using the Android APIs are not absolutely compelling, your best bet is to use those, despite whatever non-critical disadvantages are driving you to consider OpenSSL instead. -- Viktor. From vadivel86 at gmail.com Wed Mar 3 10:44:17 2021 From: vadivel86 at gmail.com (Vadivel P) Date: Wed, 3 Mar 2021 16:14:17 +0530 Subject: Fwd: Requesting to share OpenSSL commands to increase G Pramaeter length in DHE Cipher. In-Reply-To: References: Message-ID: Hi OpenSSL team, We are looking for the command line option or any other way to increase the DHE G Parameter length to 256 bytes, by default it's 2 now, we need to modify it as 256 byte on the server side for our testing either by command line or with any other option.we need it for our local server bring up. Please support us. Example: [image: image.png] Regards, Vadivel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 74468 bytes Desc: not available URL: From hkario at redhat.com Wed Mar 3 12:26:19 2021 From: hkario at redhat.com (Hubert Kario) Date: Wed, 03 Mar 2021 13:26:19 +0100 Subject: Fwd: Requesting to share OpenSSL commands to increase G =?iso-8859-1?Q?Pramaeter_length_in_DHE_Cipher.?= In-Reply-To: References: Message-ID: <4e20515c-106c-4a9e-9169-d5f41e60d13e@redhat.com> On Wednesday, 3 March 2021 11:44:17 CET, Vadivel P wrote: > Hi OpenSSL team, > > We are looking for the command line option or any other way to increase the > DHE G Parameter length to 256 bytes, by default it's 2 now, we need to > modify it as 256 byte on the server side for our testing either by command > line or with any other option.we need it for our local server bring up. > Please support us. why? size of g has no impact on security of the DHE key agreement what so ever... you really should use parameters defined in RFC 7919 and not some custom ones -- 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 kurt at roeckx.be Wed Mar 3 16:08:31 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 3 Mar 2021 17:08:31 +0100 Subject: Fwd: Requesting to share OpenSSL commands to increase G Pramaeter length in DHE Cipher. In-Reply-To: References: Message-ID: On Wed, Mar 03, 2021 at 04:14:17PM +0530, Vadivel P wrote: > Hi OpenSSL team, > > We are looking for the command line option or any other way to increase the > DHE G Parameter length to 256 bytes, by default it's 2 now, we need to > modify it as 256 byte on the server side for our testing either by command > line or with any other option.we need it for our local server bring up. > Please support us. The default generator is the value 2, not 2 bytes. And if you really need to generate your own DHE keys, using the generator 2 makes perfect sense. Using a larger generator does not add any security, it just makes it slower. But I really suggest that you use standardized parameters like the ones from RFC7919. Note that all the generators in that RFC also use 2 as the generator. OpenSSL has no support for generating safe primes with a 256 byte/2048 bit generator. From sanjurohayami at hotmail.com Thu Mar 4 06:57:10 2021 From: sanjurohayami at hotmail.com (Yang Rong) Date: Thu, 4 Mar 2021 06:57:10 +0000 Subject: =?gb2312?B?u9i4tDogUXVlc3Rpb246IEhvdyB0byB1c2luZyBjZXJ0IGZpbGVzIG9uIEFu?= =?gb2312?Q?droid_platform=3F?= In-Reply-To: References: , Message-ID: Hello Viktor, Thanks for your reply. The reason that I am trying to use the OpenSSL instead of using a library like Volley on Android is: The original environment of the project is in a private network. Our network provider shells all threats for us. So our app is installed on devices that are only required unsecured connections between devices and servers. Now we need some features from the original firmware for a new android app. The app users are going to use the internet. So the secured connections are required. If we can use OpenSSL to handle handshake and certificate verification the same code can be reused on firmware and potentially allowing our devices to use the internet in the future. > Almost certainly, but your question is rather oddly phrased and notcompletely clear. PEM files don't establish connections. Instead of using all certs in the trust store, I was trying to use as few cert files as possible. And you are right PEM files do not establish connections. I need cert file to verify the server's certs before establishing connections. Currently, I know the URL of our web service. I created a client then I tried to copy some certs from the Ubuntu trust store. Found the cert `09789157.0` is able to verify our test servers' certs. Then, I copied the text from the file 09789157.0, hard-coded the content of the file in the code, created an X509 object based on the text, and using `X509_STORE_add_cert` to add the cert to a store in a SSL_CTX. It works on Android. But I am thinking I might just do what you mentioned: "If you just extract the certificates, without the associated trust settings, you may well end up undermining some of the expected security properties, because some restricted use certificates may then lose their associated restrictions." So, my question is what should I do to find out the "associated trust settings" and include those settings? Thanks for your help r0nG Auckland, New Zealand ________________________________ ???: openssl-users ?? Viktor Dukhovni ????: 2021?3?3? 5:34 ???: openssl-users at openssl.org ??: Re: Question: How to using cert files on Android platform? On Wed, Mar 03, 2021 at 01:56:31AM +0000, Yang Rong wrote: > I am new to OpenSSL. I am working on a project using JNI+ OpenSSL on > an Android App. Can you briefly explain your motivation for using OpenSSL via JNI, rather than just use the native android TLS APIs, which then just use the Android trust store? > The OpenSSL is not able to use certs in the Android trust store. The Android trust store is likely more fine-grained than you'd naively expect. Not all the trusted certificates are necessarily trusted for the same purposes. If you just extract the certificates, without the associated trust settings, you may well end up undermining some of the expected security properties, because some restricted use certificates may then lose their associated restrictions. > Do we have a way to use the Android trust store in 2021? The simplest and generally most appropriate answer is: via the Android APIs, and without JNI into OpenSSL. If you have a compelling reason to use OpenSSL, you'll probably need to provision a dedicated trust store of known to be appropriate trust anchors. > The target API level of the Android App is 28. If OpenSSL is > still not able to use the Android default trust stores nowadays. I > would like to copy the certs from Ubuntu to the Android app. If it is appropriate to trust the same root CAs (something probably along the lines of the Mozilla cert bundle), then you could do that, but why is this necessary? > But I need to figure out which pem file is used to establish > connections. Now it seems that you're not well versed in OpenSSL, which strongly suggests that it is really best to stick to the provided APIs, and not roll your own security toolkit. > Is there a way any OpenSSL command line cmd is able to do > that? Almost certainly, but your question is rather oddly phrased and not completely clear. PEM files don't establish connections. Are you looking to capture the entire Ubuntu trust store, or just the specific trust-anchor that is *currently* the ultimate issuer of the server's certificate chain? Do you have good reason to believe that the server will continue to use the same root CAs indefinitely? ... If your reasons for not using the Android APIs are not absolutely compelling, your best bet is to use those, despite whatever non-critical disadvantages are driving you to consider OpenSSL instead. -- Viktor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vijayakumariparthasarathy at gmail.com Fri Mar 5 09:27:03 2021 From: vijayakumariparthasarathy at gmail.com (Vijayakumari Parthasarathy) Date: Fri, 5 Mar 2021 10:27:03 +0100 Subject: PKSC7 encryption In-Reply-To: References: Message-ID: > Hello > > Am new to work on encryption in Peoplesoft. We have PSPETSSL library that > support Algorithm of AES and PKSC7 . > > Problem is PKSC7 Encryption while testing it says missing config file . I > even placed correct CNF file not sure still what is missing . please advise > us how to ensure that configuration for PKSC7 exist. > > Kind regards > Vijaya > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ompushkara12345 at gmail.com Fri Mar 5 18:42:25 2021 From: ompushkara12345 at gmail.com (om pushkara) Date: Sat, 6 Mar 2021 00:12:25 +0530 Subject: Fwd: Openssl - 1.1.1g disconnection and reconnection In-Reply-To: References: Message-ID: Hi, I have been trying to implement TLS using OpenSSL libraries in C++. I was able to successfully connect to a TLS server. But our software requires it to disconnect and reconnect if i use the reconnect option . It doesn't reconnect well after the 2nd attempt . Is there any generalised code available in C++ to check whether i have deallocated resources well before reconnecting coz i am guessing that should be the problem. Thanks much in advance Ompushkaradeep -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.farrell at cs.tcd.ie Mon Mar 8 02:23:36 2021 From: stephen.farrell at cs.tcd.ie (Stephen Farrell) Date: Mon, 8 Mar 2021 02:23:36 +0000 Subject: OpenSSL 3.0.0 APIs for creating an EVP_PKEY from a p256 private key octet string Message-ID: <1295f861-434d-32c9-1f3b-1a8dd4b3a216@cs.tcd.ie> Hiya, My question: how does one setup an EVP_PKEY for a NIST curve (e.g. p256) key pair when one has the private key in an octet string using the latest OpenSSL 3.0.0 high level APIs? I'm trying to get rid of deprecation warnings from my code for HPKE [1] when dealing with NIST curves using the new (I guess?) OSSL_PARAM_* approach. I'm failing at the moment;-) So, given an octet string from a set of test vectors (e.g. [2]) what's the proper way to setup an EVP_PKEY for that to allow one to validate the test vectors? Happy to try produce a stand-alone example for this in the next few days if one doesn't exist (I've not found one so far). Thanks, Stephen. [1] https://github.com/sftcd/happykey/blob/7d52d34c516ab58ca1433004ff82b2a6a82eea4c/hpke.c#L1263 [2] https://github.com/cfrg/draft-irtf-cfrg-hpke -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x5AB2FAF17B172BEA.asc Type: application/pgp-keys Size: 10689 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From bkaduk at akamai.com Mon Mar 8 02:37:14 2021 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Sun, 7 Mar 2021 18:37:14 -0800 Subject: OpenSSL 3.0.0 APIs for creating an EVP_PKEY from a p256 private key octet string In-Reply-To: <1295f861-434d-32c9-1f3b-1a8dd4b3a216@cs.tcd.ie> References: <1295f861-434d-32c9-1f3b-1a8dd4b3a216@cs.tcd.ie> Message-ID: <20210308023713.GB25665@akamai.com> Hi Stephen :) The API you'll want to use is EVP_PKEY_fromdata(); there's a stubbed out example of using it to make an EVP_PKEY with EC group parameters at https://github.com/openssl/openssl/issues/14258#issuecomment-783351031 but the translation to also specify OSSL_PKEY_PARAM_PRIV_KEY (and possibly OSSL_PKEY_PARAM_PUB_KEY; I forget if you need to pass both) should be fairly straightforward. Let us know if you run into trouble with that route. -Ben On Mon, Mar 08, 2021 at 02:23:36AM +0000, Stephen Farrell wrote: > > Hiya, > > My question: how does one setup an EVP_PKEY for a NIST > curve (e.g. p256) key pair when one has the private key > in an octet string using the latest OpenSSL 3.0.0 high > level APIs? > > I'm trying to get rid of deprecation warnings from my > code for HPKE [1] when dealing with NIST curves using > the new (I guess?) OSSL_PARAM_* approach. I'm failing > at the moment;-) > > So, given an octet string from a set of test vectors > (e.g. [2]) what's the proper way to setup an EVP_PKEY > for that to allow one to validate the test vectors? > > Happy to try produce a stand-alone example for this > in the next few days if one doesn't exist (I've not > found one so far). > > Thanks, > Stephen. > > [1] https://github.com/sftcd/happykey/blob/7d52d34c516ab58ca1433004ff82b2a6a82eea4c/hpke.c#L1263 > [2] https://github.com/cfrg/draft-irtf-cfrg-hpke pub RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) > sub RSA 4096/36CB8BB6 2017-12-22 > From bradley at bradleygannon.com Tue Mar 9 00:48:06 2021 From: bradley at bradleygannon.com (Bradley Gannon) Date: Mon, 08 Mar 2021 19:48:06 -0500 Subject: Cross-Compiling w/ FIPS Support from Linux to Windows Message-ID: <374cc7d695526e5f8b8f24ca765300ee25be11d2.camel@bradleygannon.com> Hi there: I'm trying to cross-compile FIPS-capable OpenSSL from Linux to Windows. I already have a working native Linux build system, and I want to extend it to support Windows targets without standing up a new host. My cross-compile process follows the FOM User Guide to the best of my understanding: ``` export MACHINE="MINGW64" export SYSTEM="mingw64" export CROSS_COMPILE="x86_64-w64-mingw32-" export HOSTCC="gcc" export FIPS_SIG="${FIPS_HOME}/src/util/msincore" # build FIPS Object Module cd ${FIPS_HOME}/src ./config make make install # build OpenSSL cd ${OPENSSL_HOME}/src ./config fips --prefix=${OPENSSL_FIPS} --with-fipsdir=${OPENSSL_FIPS} make depend make make install ``` `FIPS_HOME`, `OPENSSL_HOME`, and `OPENSSL_FIPS` are the locations of the FOM source tree, the OpenSSL source tree, and the output directory, respectively. The first failure occurs during the FOM `make install` step. The error is: ``` cp: cannot stat 'fips_standalone_sha1': No such file or directory ``` It turns out that the build steps I've written above produce `fips_standalone_sha1.exe`, which `make install` can't find. That's a problem for me, because I know it's against the FIPS certification to modify anything in the work area, but I can't seem to proceed without changing that file name. Just to expose another issue let me violate the certification temporarily to bypass the problem. When I insert this command before `make install`: ``` mv ./fips/fips_standalone_sha1.exe ./fips/fips_standalone_sha1 ``` the build continues through the FOM and into OpenSSL. In fact, it seems to get either nearly or completely through `make` before failing at the incore digest step: ``` no fipstx section at ${FIPS_HOME}/src/util/msincore line 132. ``` This seems to indicate that `msincore` is not getting the kind of executable it expects, but I'm not sure how to resolve that. I can't turn up anything interesting on the Web, since most cross-compilation discussions seem to target Android or iOS. If anyone has any guidance, I'd appreciate it. Thank you, Bradley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part URL: From stephen.farrell at cs.tcd.ie Tue Mar 9 02:44:20 2021 From: stephen.farrell at cs.tcd.ie (Stephen Farrell) Date: Tue, 9 Mar 2021 02:44:20 +0000 Subject: OpenSSL 3.0.0 APIs for creating an EVP_PKEY from a p256 private key octet string In-Reply-To: <20210308023713.GB25665@akamai.com> References: <1295f861-434d-32c9-1f3b-1a8dd4b3a216@cs.tcd.ie> <20210308023713.GB25665@akamai.com> Message-ID: <8b49078a-6704-56e2-2597-a15f6be1651d@cs.tcd.ie> Hiya, On 08/03/2021 02:37, Benjamin Kaduk wrote: > Hi Stephen :) > > The API you'll want to use is EVP_PKEY_fromdata(); there's > a stubbed out example of using it to make an EVP_PKEY with > EC group parameters at > https://github.com/openssl/openssl/issues/14258#issuecomment-783351031 > but the translation to also specify OSSL_PKEY_PARAM_PRIV_KEY > (and possibly OSSL_PKEY_PARAM_PUB_KEY; I forget if you need > to pass both) should be fairly straightforward. Thanks for that! I worked around a few things and still need to tidy-up but got things working that way without any more deprecation warnings. > > Let us know if you run into trouble with that route. One outstanding issue is that I still need different code paths for NIST curves vs. 25519 & 448 - is that just me (quite likely:-) or should these new APIs hide differences between those different curves? Thanks again, S. > > -Ben > > On Mon, Mar 08, 2021 at 02:23:36AM +0000, Stephen Farrell wrote: >> >> Hiya, >> >> My question: how does one setup an EVP_PKEY for a NIST >> curve (e.g. p256) key pair when one has the private key >> in an octet string using the latest OpenSSL 3.0.0 high >> level APIs? >> >> I'm trying to get rid of deprecation warnings from my >> code for HPKE [1] when dealing with NIST curves using >> the new (I guess?) OSSL_PARAM_* approach. I'm failing >> at the moment;-) >> >> So, given an octet string from a set of test vectors >> (e.g. [2]) what's the proper way to setup an EVP_PKEY >> for that to allow one to validate the test vectors? >> >> Happy to try produce a stand-alone example for this >> in the next few days if one doesn't exist (I've not >> found one so far). >> >> Thanks, >> Stephen. >> >> [1] https://github.com/sftcd/happykey/blob/7d52d34c516ab58ca1433004ff82b2a6a82eea4c/hpke.c#L1263 >> [2] https://github.com/cfrg/draft-irtf-cfrg-hpke > > pub RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) >> sub RSA 4096/36CB8BB6 2017-12-22 >> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x5AB2FAF17B172BEA.asc Type: application/pgp-keys Size: 10689 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From bkaduk at akamai.com Tue Mar 9 03:09:51 2021 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 8 Mar 2021 19:09:51 -0800 Subject: OpenSSL 3.0.0 APIs for creating an EVP_PKEY from a p256 private key octet string In-Reply-To: <8b49078a-6704-56e2-2597-a15f6be1651d@cs.tcd.ie> References: <1295f861-434d-32c9-1f3b-1a8dd4b3a216@cs.tcd.ie> <20210308023713.GB25665@akamai.com> <8b49078a-6704-56e2-2597-a15f6be1651d@cs.tcd.ie> Message-ID: <20210309030950.GF25665@akamai.com> On Tue, Mar 09, 2021 at 02:44:20AM +0000, Stephen Farrell wrote: > > Hiya, > > On 08/03/2021 02:37, Benjamin Kaduk wrote: > > Hi Stephen :) > > > > The API you'll want to use is EVP_PKEY_fromdata(); there's > > a stubbed out example of using it to make an EVP_PKEY with > > EC group parameters at > > https://github.com/openssl/openssl/issues/14258#issuecomment-783351031 > > but the translation to also specify OSSL_PKEY_PARAM_PRIV_KEY > > (and possibly OSSL_PKEY_PARAM_PUB_KEY; I forget if you need > > to pass both) should be fairly straightforward. > > Thanks for that! I worked around a few things and still need > to tidy-up but got things working that way without any more > deprecation warnings. > > > > > Let us know if you run into trouble with that route. > > One outstanding issue is that I still need different code > paths for NIST curves vs. 25519 & 448 - is that just me > (quite likely:-) or should these new APIs hide differences > between those different curves? I would have expected that the API should hide the differences other than the group name ... but these APIs are still pretty new to me, too. If you can point me at your code I might have more to say. -Ben From bhat.jayalakshmi at gmail.com Tue Mar 9 07:25:59 2021 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Tue, 9 Mar 2021 12:55:59 +0530 Subject: Query on engine support in OpenSSL 1.0.2h Message-ID: Hi All, We currently use OpenSSL 1.0.2h, we are in the process of upgrading to OpenSSL 1.1.1. To address some legacy functionalities we are planning to write engines for OpenSSL 1.0.2h offload crypto operation to external components. We have few queries regarding the same 1. Can we offload all crypto operations (Digest, Encryption/decryption, RSA, ECDSA, DRBG etc) using Engines in OpenSSL 1.0.2h 2. If not, is it must to upgrade to OpenSSL 1.1.1 to achieve the same? Regards, Jayalakshmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.farrell at cs.tcd.ie Tue Mar 9 10:37:17 2021 From: stephen.farrell at cs.tcd.ie (Stephen Farrell) Date: Tue, 9 Mar 2021 10:37:17 +0000 Subject: OpenSSL 3.0.0 APIs for creating an EVP_PKEY from a p256 private key octet string In-Reply-To: <20210309030950.GF25665@akamai.com> References: <1295f861-434d-32c9-1f3b-1a8dd4b3a216@cs.tcd.ie> <20210308023713.GB25665@akamai.com> <8b49078a-6704-56e2-2597-a15f6be1651d@cs.tcd.ie> <20210309030950.GF25665@akamai.com> Message-ID: <126764f0-7445-5f3d-5d6d-0323503433e7@cs.tcd.ie> Hiya, On 09/03/2021 03:09, Benjamin Kaduk wrote: > I would have expected that the API should hide the differences > other than the group name ... but these APIs are still pretty > new to me, too. If you can point me at your code I might have > more to say. Will check it out some more, tidy the code up and get back later/tomorrow, Cheers, S. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x5AB2FAF17B172BEA.asc Type: application/pgp-keys Size: 10689 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From realburner at gmx.de Tue Mar 9 17:36:34 2021 From: realburner at gmx.de (Robert Burner Schadek) Date: Tue, 9 Mar 2021 18:36:34 +0100 Subject: Envelope problem Message-ID: Hello all, I'm trying to follow the guide shown in https://wiki.openssl.org/index.php/EVP_Asymmetric_Encryption_and_Decryption_of_an_Envelope But for the life of me I can't figure out how to do the following: ``` struct Data { ??? unsigned char* data; ??? unsigned long length; }; struct KeyArray { ??? EVP_PKEY** keys; ??? unsigned long numberKeys; }; /* When Data is written to disk the openssl cli should be ?* able to decrypt the resulting file with something like ?* $ openssl rsautl -decrypt -in ENCRYPTED -out PLAINTEXT -inkey keys/privkey.pem ?*/ Data encryptWithMultiplePublicKeys(Data input, KeyArray keys) { ??? // WHAT GOES HERE? } Data decryptWithSinglePublicKey(Data input, EVP_PKEY* key) { ??? // WHAT GOES HERE? } int main() { ??? unsigned char* dataToEncrypt = (unsigned char*)"whatever"; ??? Data data; ??? data.data = dataToEncrypt; ??? dtat.length = strlen(dataToEncrypt); ??? KeyArray ka = fillKeyArrayFromSomewhere(); ??? ??? Data encryptedData = encryptWithMultiplePublicKeys(data, kArray); ??? // see the requirement for this file in the comment above ??? FILE* f = fopen("ENCRYPTED", "w"); ??? fwrite(encryptedData, 1, encryptedData.length, f); ??? fclose(f); ??? Data decryptedData = decryptWithSinglePublicKey(encryptedData, ka.keys[rand() % ka.numberKeys]); ??? // this assert should be true ??? assert(strcmp(dataToEncrypt, decryptedData.data)); ??? return 0; } ``` The parts I can't figure out are the contents of the two empty functions in the example. I tried working out how the openssl cli does this, but I couldn't. Help would be much appreciated. Best regards Robert From stephen.farrell at cs.tcd.ie Wed Mar 10 00:53:31 2021 From: stephen.farrell at cs.tcd.ie (Stephen Farrell) Date: Wed, 10 Mar 2021 00:53:31 +0000 Subject: OpenSSL 3.0.0 APIs for creating an EVP_PKEY from a p256 private key octet string In-Reply-To: <20210309030950.GF25665@akamai.com> References: <1295f861-434d-32c9-1f3b-1a8dd4b3a216@cs.tcd.ie> <20210308023713.GB25665@akamai.com> <8b49078a-6704-56e2-2597-a15f6be1651d@cs.tcd.ie> <20210309030950.GF25665@akamai.com> Message-ID: <0271bd36-e91e-3d00-a167-0184396571b1@cs.tcd.ie> Hiya, On 09/03/2021 03:09, Benjamin Kaduk wrote: > I would have expected that the API should hide the differences > other than the group name ... but these APIs are still pretty > new to me, too. If you can point me at your code I might have > more to say. So again it's probably my fault but I'm still not seeing the same behaviour for NIST and non-NIST curves. I made up what I hope is a fairly simple bit of test code [1] so that might help clarify where I'm wrong or (less likely) where a change in the library might be useful. As I build the test code, the p256 cases seem to work, with or without the public key, but both 25519 cases fail. In my (still untidy:-) HPKE code EVP_PKEY_new_raw_private_key for the non-NIST curves works, but not for NIST curves. So I have an ok workaround, even if the fault's not mine, which it of course probably is:-) Cheers, S. [1] https://github.com/sftcd/happykey/blob/master/test2evp.c -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x5AB2FAF17B172BEA.asc Type: application/pgp-keys Size: 10689 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From ompushkara12345 at gmail.com Wed Mar 10 06:37:25 2021 From: ompushkara12345 at gmail.com (om pushkara) Date: Wed, 10 Mar 2021 12:07:25 +0530 Subject: Openssl library- 1.1.1g C++ disconnection and reconnection Message-ID: Hi, I have been trying to implement TLS using OpenSSL libraries in C++. I was able to successfully connect to a TLS server. But our software requires it to disconnect and reconnect if i use the reconnect option . It doesn't reconnect well after the 2nd attempt . Is there any generalised code available in C++ to check whether i have deallocated resources well before reconnecting coz i am guessing that should be the problem. Thanks much in advance Ompushkaradeep -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at openssl.org Wed Mar 10 07:49:35 2021 From: tomas at openssl.org (Tomas Mraz) Date: Wed, 10 Mar 2021 08:49:35 +0100 Subject: OpenSSL 3.0.0 APIs for creating an EVP_PKEY from a p256 private key octet string In-Reply-To: <0271bd36-e91e-3d00-a167-0184396571b1@cs.tcd.ie> References: <1295f861-434d-32c9-1f3b-1a8dd4b3a216@cs.tcd.ie> <20210308023713.GB25665@akamai.com> <8b49078a-6704-56e2-2597-a15f6be1651d@cs.tcd.ie> <20210309030950.GF25665@akamai.com> <0271bd36-e91e-3d00-a167-0184396571b1@cs.tcd.ie> Message-ID: <6983c4dfd2df5d483f86a0b0c6213a0e1ab53758.camel@openssl.org> On Wed, 2021-03-10 at 00:53 +0000, Stephen Farrell wrote: > Hiya, > > On 09/03/2021 03:09, Benjamin Kaduk wrote: > > I would have expected that the API should hide the differences > > other than the group name ... but these APIs are still pretty > > new to me, too. If you can point me at your code I might have > > more to say. > > So again it's probably my fault but I'm still not seeing the > same behaviour for NIST and non-NIST curves. I made up what > I hope is a fairly simple bit of test code [1] so that might > help clarify where I'm wrong or (less likely) where a change > in the library might be useful. > > As I build the test code, the p256 cases seem to work, with > or without the public key, but both 25519 cases fail. In my > (still untidy:-) HPKE code EVP_PKEY_new_raw_private_key > for the non-NIST curves works, but not for NIST curves. So I > have an ok workaround, even if the fault's not mine, which > it of course probably is:-) Not sure if there are any other issues, but the public key parameter should be "encoded-pub-key" AFAIK. Tomas Mraz From matt at openssl.org Wed Mar 10 09:12:27 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 10 Mar 2021 09:12:27 +0000 Subject: OpenSSL 3.0.0 APIs for creating an EVP_PKEY from a p256 private key octet string In-Reply-To: <0271bd36-e91e-3d00-a167-0184396571b1@cs.tcd.ie> References: <1295f861-434d-32c9-1f3b-1a8dd4b3a216@cs.tcd.ie> <20210308023713.GB25665@akamai.com> <8b49078a-6704-56e2-2597-a15f6be1651d@cs.tcd.ie> <20210309030950.GF25665@akamai.com> <0271bd36-e91e-3d00-a167-0184396571b1@cs.tcd.ie> Message-ID: On 10/03/2021 00:53, Stephen Farrell wrote: > > Hiya, > > On 09/03/2021 03:09, Benjamin Kaduk wrote: >> I would have expected that the API should hide the differences >> other than the group name ... but these APIs are still pretty >> new to me, too.? If you can point me at your code I might have >> more to say. > > So again it's probably my fault but I'm still not seeing the > same behaviour for NIST and non-NIST curves. I made up what > I hope is a fairly simple bit of test code [1] so that might > help clarify where I'm wrong or (less likely) where a change > in the library might be useful. > > As I build the test code, the p256 cases seem to work, with > or without the public key, but both 25519 cases fail. In my > (still untidy:-) HPKE code EVP_PKEY_new_raw_private_key > for the non-NIST curves works, but not for NIST curves. So I > have an ok workaround, even if the fault's not mine, which > it of course probably is:-) Hi Stephen There are two important things to understand that your code was not quite handling correctly: 1) X25519/X448/ED25519/ED448 are treated as different key types to "traditional" EC. They really are very different things: different OIDs, different standards, different file formats, different key formats etc. So while the "traditional" EC curves have the key type "EC", we have separate key types of "X25519", "X448", "ED25519" and "ED448" 2) The type of the parameters is dependent on the key type. So a private key in "EC" is an integer. But a private key for "X25519" is an octet string. Refer to: https://www.openssl.org/docs/manmaster/man7/EVP_PKEY-EC.html https://www.openssl.org/docs/manmaster/man7/EVP_PKEY-X25519.html I made these changes to your test code to get it to work: $ diff -u test2evp.c test2evp2.c --- test2evp.c 2021-03-10 08:47:59.467451154 +0000 +++ test2evp2.c 2021-03-10 09:03:47.258657721 +0000 @@ -29,6 +29,7 @@ #include int bufs2evp( + const char *keytype, char *groupname, unsigned char *privbuf, size_t privbuflen, unsigned char *pubuf, size_t pubuflen, @@ -41,38 +42,38 @@ OSSL_PARAM_BLD *param_bld=NULL;; OSSL_PARAM *params = NULL; - priv = BN_bin2bn(privbuf, privbuflen, NULL); - if (!priv) { - erv=__LINE__; goto err; - } param_bld = OSSL_PARAM_BLD_new(); if (!param_bld) { erv=__LINE__; goto err; } if (pubuf && pubuflen>0) { - if (OSSL_PARAM_BLD_push_utf8_string(param_bld, "group", groupname,0)!=1) { - erv=__LINE__; goto err; - } - if (OSSL_PARAM_BLD_push_BN(param_bld, "priv", priv)!=1) { - erv=__LINE__; goto err; - } if (OSSL_PARAM_BLD_push_octet_string(param_bld, "pub", pubuf, pubuflen)!=1) { erv=__LINE__; goto err; } params = OSSL_PARAM_BLD_to_param(param_bld); - } else { - if (OSSL_PARAM_BLD_push_utf8_string(param_bld, "group", groupname,0)!=1) { + } + if (groupname != NULL && OSSL_PARAM_BLD_push_utf8_string(param_bld, "group", groupname,0)!=1) { + erv=__LINE__; goto err; + } + if (strcmp(keytype, "EC") == 0) { + priv = BN_bin2bn(privbuf, privbuflen, NULL); + if (!priv) { erv=__LINE__; goto err; - } + } if (OSSL_PARAM_BLD_push_BN(param_bld, "priv", priv)!=1) { erv=__LINE__; goto err; } - params = OSSL_PARAM_BLD_to_param(param_bld); + } else { + if (OSSL_PARAM_BLD_push_octet_string(param_bld, "priv", privbuf, privbuflen)!=1) { + erv=__LINE__; goto err; + } } + params = OSSL_PARAM_BLD_to_param(param_bld); + if (!params) { erv=__LINE__; goto err; } - ctx = EVP_PKEY_CTX_new_from_name(NULL,"EC", NULL); + ctx = EVP_PKEY_CTX_new_from_name(NULL,keytype, NULL); if (ctx == NULL) { erv=__LINE__; goto err; } @@ -167,7 +168,7 @@ * First do a p-256 one that works, then an x25519 one that does not. */ - rv=bufs2evp("P-256",nprivbuf,nprivlen,npubbuf,npublen,&retkey); + rv=bufs2evp("EC","P-256",nprivbuf,nprivlen,npubbuf,npublen,&retkey); if (rv==1) { printf("P-256 with key pair worked\n"); } else { @@ -175,7 +176,7 @@ } EVP_PKEY_free(retkey);retkey=NULL; - rv=bufs2evp("P-256",nprivbuf,nprivlen,NULL,0,&retkey); + rv=bufs2evp("EC","P-256",nprivbuf,nprivlen,NULL,0,&retkey); if (rv==1) { printf("P-256 with just private key worked\n"); } else { @@ -183,7 +184,7 @@ } EVP_PKEY_free(retkey);retkey=NULL; - rv=bufs2evp("X25519",xprivbuf,xprivlen,xpubbuf,xpublen,&retkey); + rv=bufs2evp("X25519",NULL,xprivbuf,xprivlen,xpubbuf,xpublen,&retkey); if (rv==1) { printf("X25519 with key pair worked\n"); } else { @@ -191,7 +192,7 @@ } EVP_PKEY_free(retkey);retkey=NULL; - rv=bufs2evp("X25519",xprivbuf,xprivlen,NULL,0,&retkey); + rv=bufs2evp("X25519",NULL,xprivbuf,xprivlen,NULL,0,&retkey); if (rv==1) { printf("X25519 with just private key worked\n"); } else { Matt From stephen.farrell at cs.tcd.ie Wed Mar 10 12:08:09 2021 From: stephen.farrell at cs.tcd.ie (Stephen Farrell) Date: Wed, 10 Mar 2021 12:08:09 +0000 Subject: OpenSSL 3.0.0 APIs for creating an EVP_PKEY from a p256 private key octet string In-Reply-To: References: <1295f861-434d-32c9-1f3b-1a8dd4b3a216@cs.tcd.ie> <20210308023713.GB25665@akamai.com> <8b49078a-6704-56e2-2597-a15f6be1651d@cs.tcd.ie> <20210309030950.GF25665@akamai.com> <0271bd36-e91e-3d00-a167-0184396571b1@cs.tcd.ie> Message-ID: <9241cce1-b07d-5b51-8521-4e7abac52087@cs.tcd.ie> Thanks Matt, On 10/03/2021 09:12, Matt Caswell wrote: > > > On 10/03/2021 00:53, Stephen Farrell wrote: >> >> Hiya, >> >> On 09/03/2021 03:09, Benjamin Kaduk wrote: >>> I would have expected that the API should hide the differences >>> other than the group name ... but these APIs are still pretty >>> new to me, too.? If you can point me at your code I might have >>> more to say. >> >> So again it's probably my fault but I'm still not seeing the >> same behaviour for NIST and non-NIST curves. I made up what >> I hope is a fairly simple bit of test code [1] so that might >> help clarify where I'm wrong or (less likely) where a change >> in the library might be useful. >> >> As I build the test code, the p256 cases seem to work, with >> or without the public key, but both 25519 cases fail. In my >> (still untidy:-) HPKE code EVP_PKEY_new_raw_private_key >> for the non-NIST curves works, but not for NIST curves. So I >> have an ok workaround, even if the fault's not mine, which >> it of course probably is:-) > > Hi Stephen > > There are two important things to understand that your code was not > quite handling correctly: > > 1) X25519/X448/ED25519/ED448 are treated as different key types to > "traditional" EC. They really are very different things: different OIDs, > different standards, different file formats, different key formats etc. > So while the "traditional" EC curves have the key type "EC", we have > separate key types of "X25519", "X448", "ED25519" and "ED448" > > 2) The type of the parameters is dependent on the key type. So a private > key in "EC" is an integer. But a private key for "X25519" is an octet > string. I had tried all those, but not in the right combination, so thanks! My test code works now with your changes. (It's still at [1] and feel free to use as an example if that's useful.) It seems a pity that one has to special case in two ways there (both keytype and groupname) but I can live with it, Thanks again, S. [1] https://github.com/sftcd/happykey/blob/master/test2evp.c > > Refer to: > > https://www.openssl.org/docs/manmaster/man7/EVP_PKEY-EC.html > https://www.openssl.org/docs/manmaster/man7/EVP_PKEY-X25519.html > > > I made these changes to your test code to get it to work: > > $ diff -u test2evp.c test2evp2.c > --- test2evp.c??? 2021-03-10 08:47:59.467451154 +0000 > +++ test2evp2.c??? 2021-03-10 09:03:47.258657721 +0000 > @@ -29,6 +29,7 @@ > ?#include > > ?int bufs2evp( > +??????? const char *keytype, > ???????? char *groupname, > ???????? unsigned char *privbuf, size_t privbuflen, > ???????? unsigned char *pubuf, size_t pubuflen, > @@ -41,38 +42,38 @@ > ???? OSSL_PARAM_BLD *param_bld=NULL;; > ???? OSSL_PARAM *params = NULL; > > -??? priv = BN_bin2bn(privbuf, privbuflen, NULL); > -??? if (!priv) { > -??????? erv=__LINE__; goto err; > -??? } > ???? param_bld = OSSL_PARAM_BLD_new(); > ???? if (!param_bld) { > ???????? erv=__LINE__; goto err; > ???? } > ???? if (pubuf && pubuflen>0) { > -??????? if (OSSL_PARAM_BLD_push_utf8_string(param_bld, "group", > groupname,0)!=1) { > -??????????? erv=__LINE__; goto err; > -??????? } > -??????? if (OSSL_PARAM_BLD_push_BN(param_bld, "priv", priv)!=1) { > -??????????? erv=__LINE__; goto err; > -??????? } > ???????? if (OSSL_PARAM_BLD_push_octet_string(param_bld, "pub", pubuf, > pubuflen)!=1) { > ???????????? erv=__LINE__; goto err; > ???????? } > ???????? params = OSSL_PARAM_BLD_to_param(param_bld); > -??? } else { > -??????? if (OSSL_PARAM_BLD_push_utf8_string(param_bld, "group", > groupname,0)!=1) { > +??? } > +??? if (groupname != NULL && OSSL_PARAM_BLD_push_utf8_string(param_bld, > "group", groupname,0)!=1) { > +??????? erv=__LINE__; goto err; > +??? } > +??? if (strcmp(keytype, "EC") == 0) { > +??????? priv = BN_bin2bn(privbuf, privbuflen, NULL); > +??????? if (!priv) { > ???????????? erv=__LINE__; goto err; > -??????? } > +??????? } > ???????? if (OSSL_PARAM_BLD_push_BN(param_bld, "priv", priv)!=1) { > ???????????? erv=__LINE__; goto err; > ???????? } > -??????? params = OSSL_PARAM_BLD_to_param(param_bld); > +??? } else { > +??????? if (OSSL_PARAM_BLD_push_octet_string(param_bld, "priv", > privbuf, privbuflen)!=1) { > +??????????? erv=__LINE__; goto err; > +??????? } > ???? } > +??? params = OSSL_PARAM_BLD_to_param(param_bld); > + > ???? if (!params) { > ???????? erv=__LINE__; goto err; > ???? } > -??? ctx = EVP_PKEY_CTX_new_from_name(NULL,"EC", NULL); > +??? ctx = EVP_PKEY_CTX_new_from_name(NULL,keytype, NULL); > ???? if (ctx == NULL) { > ???????? erv=__LINE__; goto err; > ???? } > @@ -167,7 +168,7 @@ > ????? * First do a p-256 one that works, then an x25519 one that does not. > ????? */ > > -??? rv=bufs2evp("P-256",nprivbuf,nprivlen,npubbuf,npublen,&retkey); > +??? rv=bufs2evp("EC","P-256",nprivbuf,nprivlen,npubbuf,npublen,&retkey); > ???? if (rv==1) { > ???????? printf("P-256 with key pair worked\n"); > ???? } else { > @@ -175,7 +176,7 @@ > ???? } > ???? EVP_PKEY_free(retkey);retkey=NULL; > > -??? rv=bufs2evp("P-256",nprivbuf,nprivlen,NULL,0,&retkey); > +??? rv=bufs2evp("EC","P-256",nprivbuf,nprivlen,NULL,0,&retkey); > ???? if (rv==1) { > ???????? printf("P-256 with just private key worked\n"); > ???? } else { > @@ -183,7 +184,7 @@ > ???? } > ???? EVP_PKEY_free(retkey);retkey=NULL; > > -??? rv=bufs2evp("X25519",xprivbuf,xprivlen,xpubbuf,xpublen,&retkey); > +??? rv=bufs2evp("X25519",NULL,xprivbuf,xprivlen,xpubbuf,xpublen,&retkey); > ???? if (rv==1) { > ???????? printf("X25519 with key pair worked\n"); > ???? } else { > @@ -191,7 +192,7 @@ > ???? } > ???? EVP_PKEY_free(retkey);retkey=NULL; > > -??? rv=bufs2evp("X25519",xprivbuf,xprivlen,NULL,0,&retkey); > +??? rv=bufs2evp("X25519",NULL,xprivbuf,xprivlen,NULL,0,&retkey); > ???? if (rv==1) { > ???????? printf("X25519 with just private key worked\n"); > ???? } else { > > > Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x5AB2FAF17B172BEA.asc Type: application/pgp-keys Size: 10689 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From matt at openssl.org Wed Mar 10 12:11:14 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 10 Mar 2021 12:11:14 +0000 Subject: OpenSSL 3.0.0 APIs for creating an EVP_PKEY from a p256 private key octet string In-Reply-To: <9241cce1-b07d-5b51-8521-4e7abac52087@cs.tcd.ie> References: <1295f861-434d-32c9-1f3b-1a8dd4b3a216@cs.tcd.ie> <20210308023713.GB25665@akamai.com> <8b49078a-6704-56e2-2597-a15f6be1651d@cs.tcd.ie> <20210309030950.GF25665@akamai.com> <0271bd36-e91e-3d00-a167-0184396571b1@cs.tcd.ie> <9241cce1-b07d-5b51-8521-4e7abac52087@cs.tcd.ie> Message-ID: <810c65c7-5f41-be63-738d-aa75f9a42d21@openssl.org> On 10/03/2021 12:08, Stephen Farrell wrote: > It seems a pity that one has to special case in two ways > there (both keytype and groupname) but I can live with it, For X25519 you can actually pass a groupname of "x25519" through if you want to keep everything consistent. But it's not strictly necessary since that is the only group supported by that keytype. Matt From harishvk27 at gmail.com Wed Mar 10 13:14:57 2021 From: harishvk27 at gmail.com (Harish Kulkarni) Date: Wed, 10 Mar 2021 18:44:57 +0530 Subject: Dumping key to file Message-ID: Hello All, My application is built along with openssl library source code. We want to dump keys to a file for decrypting TLS flows from network captures.. is there any flag or environment variable which we can set during building application or while running application. -thanks harish -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgh at wizmail.org Wed Mar 10 13:35:44 2021 From: jgh at wizmail.org (Jeremy Harris) Date: Wed, 10 Mar 2021 13:35:44 +0000 Subject: Dumping key to file In-Reply-To: References: Message-ID: On 10/03/2021 13:14, Harish Kulkarni wrote: > My application is built along with openssl library source code. We want to > dump keys to a file for decrypting TLS flows from network captures.. is > there any flag or environment variable which we can set during building > application or while running application. Env var SSLKEYLOGFILE -- Cheers, Jeremy From matt at openssl.org Wed Mar 10 14:28:51 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 10 Mar 2021 14:28:51 +0000 Subject: Dumping key to file In-Reply-To: References: Message-ID: On 10/03/2021 13:35, Jeremy Harris wrote: > On 10/03/2021 13:14, Harish Kulkarni wrote: >> My application is built along with openssl library source code. We >> want to >> dump keys to a file for decrypting TLS flows from network captures.. is >> there any flag or environment variable which we can set during building >> application or while running application. > > Env var SSLKEYLOGFILE That is not an OpenSSL environment variable (I think that's an NSS thing). In order to log keys you need to set the key logging callback via SSL_CTX_set_keylog_callback. The callback needs to look like this: typedef void (*SSL_CTX_keylog_cb_func)(const SSL *ssl, const char *line); It should write the data provided in "line" to wherever you want to store the key data. See: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_keylog_callback.html If you are using the OpenSSL command line then you can use the "-keylogfile" option to s_client or s_server to specify the filename for where you want keys logged. Matt From harishvk27 at gmail.com Thu Mar 11 05:34:55 2021 From: harishvk27 at gmail.com (Harish Kulkarni) Date: Thu, 11 Mar 2021 11:04:55 +0530 Subject: Dumping key to file In-Reply-To: References: Message-ID: Thank you all.. i will try and write back. -thanks harish On Wed, Mar 10, 2021 at 7:59 PM Matt Caswell wrote: > > > On 10/03/2021 13:35, Jeremy Harris wrote: > > On 10/03/2021 13:14, Harish Kulkarni wrote: > >> My application is built along with openssl library source code. We > >> want to > >> dump keys to a file for decrypting TLS flows from network captures.. is > >> there any flag or environment variable which we can set during building > >> application or while running application. > > > > Env var SSLKEYLOGFILE > > That is not an OpenSSL environment variable (I think that's an NSS thing). > > In order to log keys you need to set the key logging callback via > SSL_CTX_set_keylog_callback. > > The callback needs to look like this: > > typedef void (*SSL_CTX_keylog_cb_func)(const SSL *ssl, const char *line); > > It should write the data provided in "line" to wherever you want to > store the key data. > > See: > https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_keylog_callback.html > > If you are using the OpenSSL command line then you can use the > "-keylogfile" option to s_client or s_server to specify the filename for > where you want keys logged. > > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From madhumitha.penmetsa at excent.co.uk Thu Mar 11 09:54:47 2021 From: madhumitha.penmetsa at excent.co.uk (Madhumitha Penmetsa) Date: Thu, 11 Mar 2021 15:24:47 +0530 Subject: couldnot upload OBWAC and OBSEAl for openbanking Message-ID: I am trying to generate a csr file using the config file for openbanking in openssl(1.1.1.j) in windows10 . In newer openssl version OID 2.5.4.97 is reserved for organizationIdentifier, so you can change your obwac.conf by removing the OID and it should work. with OID we are unable to generate the csr file.so by removing the OID i m able to generate the csr file.But as OID is a mandatory in the CSR ,the openbanking is not accepting the certificate.Can some one help?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Thu Mar 11 14:19:58 2021 From: openssl at openssl.org (OpenSSL) Date: Thu, 11 Mar 2021 14:19:58 +0000 Subject: OpenSSL version 3.0.0-alpha13 published Message-ID: <20210311141958.GA6775@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.0 alpha 13 released ===================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 13 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha13.tar.gz Size: 14211501 SHA1 checksum: 754aab6dc677668255fec676c6340a3a191e8135 SHA256 checksum: c88cbb9d330b4daa3dbb5af1ed511d5062253291a56e09fd17e9ac013a20f8a3 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha13.tar.gz openssl sha256 openssl-3.0.0-alpha13.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmBKH2UACgkQ2cTSbQ5g RJGU0gf9F6POd8koanFFrOBR9BlnlZyhFqYgn0s0404f4FIv0ntX9ClJ/GU4CruD hch4riFzD4uGtX9vpEHMs6cdWmMQmaoQendH0kIbHqLubxm3R51S8L5sIxQRnc0B pXDEteafEPd8jQyZmcg5Hd0aQI1Ju7hw3B9H/0C8JkPbSyfP7XOanWJJh9dinOEb HpswBhQWNmY6OwyIv9mmJQ+BtEbTXrADpMTsBWH1s84oQ8xT64e3Jzkwyx4DDnBi dKDYJjhjAV6mm7GVTBgT3nier3p9CgvbmViMRf1RNbwOpX7lhd+VgWN0QfvOF2dT rKbOZXDnSjbTt2lDr4VvOY+8B870/g== =1LTf -----END PGP SIGNATURE----- From bradley at bradleygannon.com Thu Mar 11 14:39:56 2021 From: bradley at bradleygannon.com (Bradley Gannon) Date: Thu, 11 Mar 2021 09:39:56 -0500 Subject: Cross-Compiling w/ FIPS Support from Linux to Windows In-Reply-To: References: Message-ID: I'm still struggling with this problem, but I have a little more information. I learned from a close reading of `INSTALL.W32` and `.W64` that support for 64-bit Windows is not stable, but support for 32-bit Windows is okay, and that cross-compilation from Linux is possible. An example given in `INSTALL.W32` seems to confirm that my environment variables are close to correct, except for the 32/64-bit differences. I made another attempt, this time targetting 32-bit Windows. Everything is the same as my first message, except the environment variables: ``` export MACHINE="MINGW" export SYSTEM="mingw" export CROSS_COMPILE="i686-w64-mingw32-" export HOSTCC="gcc" export FIPS_SIG="${FIPS_HOME}/src/util/msincore" ``` The FOM build completes as expected, but I encountered [this problem][0] having to do with multiple definitions. I applied the fix that the OP describes there (i.e. renaming the offending symbols), and the build continued. Unfortunately, it seems like nothing has changed, because I still get the same error as before: ``` no fipstx section at ${FIPS_HOME}/src/util/msincore line 132. ``` If anyone has any information at all about this problem, I would appreciate it if you sent it along. Thank you, Bradley [0]: http://openssl.6102.n7.nabble.com/OpenSSL-1-0-1e-build-failure-using-MinGW-multiple-definition-of-OPENSSL-Uplink-td46492.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part URL: From hightronicdesign at gmail.com Thu Mar 11 16:16:06 2021 From: hightronicdesign at gmail.com (Robert Ionescu) Date: Thu, 11 Mar 2021 17:16:06 +0100 Subject: Client certificate authentication Message-ID: Hi, I am searching for the functions in openssl used to verify the clients certificate when using mutual authentication. My intention is to find a way to log a wrong user certificate directly inside the openssl source. Any help would be highly appreciated _______________________________________________________________________________ Robert Ionescu *The information contained in this message is confidential and may be legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Mar 11 17:39:14 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 11 Mar 2021 15:39:14 -0200 Subject: Client certificate authentication In-Reply-To: References: Message-ID: <891537D4-F8AF-436C-A40F-CC3FB9C81039@dukhovni.org> > On Mar 11, 2021, at 2:16 PM, Robert Ionescu wrote: > > I am searching for the functions in openssl used to verify the clients > certificate when using mutual authentication. The same code verifies peer certificate chains, whether client or server. > My intention is to find a way to log a wrong user certificate directly inside > the openssl source. What does "wrong" mean? OpenSSL is a library, it has no business making decisions like writing log entries, that's an application prerogative, and any logging of diagnostic or audit trail events should in application code, not in OpenSSL library code. -- Viktor. From aerowolf at gmail.com Thu Mar 11 19:19:17 2021 From: aerowolf at gmail.com (Kyle Hamilton) Date: Thu, 11 Mar 2021 13:19:17 -0600 Subject: Client certificate authentication In-Reply-To: <891537D4-F8AF-436C-A40F-CC3FB9C81039@dukhovni.org> References: <891537D4-F8AF-436C-A40F-CC3FB9C81039@dukhovni.org> Message-ID: If he's trying to muck with the library, he's probably struggling with a precompiled binary he doesn't have the source code to. -Kyle H On Thu, Mar 11, 2021, 11:48 Viktor Dukhovni wrote: > > On Mar 11, 2021, at 2:16 PM, Robert Ionescu > wrote: > > > > I am searching for the functions in openssl used to verify the clients > > certificate when using mutual authentication. > > The same code verifies peer certificate chains, whether client or server. > > > My intention is to find a way to log a wrong user certificate directly > inside > > the openssl source. > > What does "wrong" mean? OpenSSL is a library, it has no business making > decisions like writing log entries, that's an application prerogative, and > any logging of diagnostic or audit trail events should in application code, > not in OpenSSL library code. > > -- > Viktor. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Thu Mar 11 19:39:08 2021 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 11 Mar 2021 19:39:08 +0000 Subject: Client certificate authentication In-Reply-To: <891537D4-F8AF-436C-A40F-CC3FB9C81039@dukhovni.org> References: <891537D4-F8AF-436C-A40F-CC3FB9C81039@dukhovni.org> Message-ID: > From: openssl-users On Behalf Of Viktor > Dukhovni > Sent: Thursday, 11 March, 2021 10:39 > To: openssl-users at openssl.org > Subject: Re: Client certificate authentication > > > On Mar 11, 2021, at 2:16 PM, Robert Ionescu > wrote: > > > > I am searching for the functions in openssl used to verify the clients > > certificate when using mutual authentication. > > My intention is to find a way to log a wrong user certificate directly > inside > > the openssl source. > > What does "wrong" mean? This is an important question. PKIX does not specify the interpretation of the client certificate. While chain construction and most of validity checks (signature, validity dates, basic constraints, KU and EKU, etc) apply, the association between the identity claimed by the certificate and the client is not determined by the standard. Even the form of that association and what is being identified are up to the application. Conventionally, I believe these options are most commonly used: 1. The client certificate identifies the peer system, i.e. the network node that the server is communicating with. This might look symmetric with the client's identification of the server, but it isn't, because a client specifies a server identity (e.g. by hostname) and then verifies that using the server certificate; but in the normal use case, the server has no prior notion of the client system's identity. So the server might get the peer IP address from the stack and then look for an IPADDR SAN in the client's certificate which matches that, for example. The server might also attempt reverse DNS (PTR record) resolution from the IP address to a hostname or FQDN and look for a corresponding DNS SAN or Subject CN, though that option is fraught with potential for abuse. 2. The client certificate identifies the user. Here the certificate is issued to, and identifies, a person or other actor (e.g. the peer application) rather than a network identity. What the server application does with this information is a further question. 3. The client certificate matches a preconfigured allow list: The server application just has some list of "permit any client identified by one of these certificates". 4. The client certificate is validated but beyond that is used as an opaque reference to some other database. This is a variation on #3. IBM's CICS Web Interface provides this mode, where clients can send arbitrary certificates as long as they're valid and belong to a chain that terminates in one of the configured trust anchors. The handshake is completed. Then the system will look that certificate up in the security database to see if it's known and associated with a user identity. If not, the application (or more properly the CWI subsystem) prompts for user credentials using HTTP Basic Authentication (over the TLS channel); if that's successful, the association between client certificate and user account is recorded and the conversation continues. 5. No further vetting of the certificate is done. Essentially the client authentication serves simply as a generic gatekeeper, so that only clients possessing an acceptable certificate are allowed to establish a TLS connection to the server. Any authentication beyond that is handled by the application using other means. So a client certificate can be "wrong" in the basic PKIX sense of "invalid certificate" or "can't build a path", but beyond that the interpretation is up to the server-side application. -- Michael Wojcik From hightronicdesign at gmail.com Fri Mar 12 08:06:57 2021 From: hightronicdesign at gmail.com (Robert Ionescu) Date: Fri, 12 Mar 2021 09:06:57 +0100 Subject: Client certificate authentication In-Reply-To: References: <891537D4-F8AF-436C-A40F-CC3FB9C81039@dukhovni.org> Message-ID: With "wrong" certificate I meant "invalid certificate". So the idea was in a bigger environment with a lot of certificates, to make the invalid certificate debugging easier by getting more information from openssl to identify the invalid certificate easier. My research is based on this reported issue https://github.com/haproxy/haproxy/issues/693 _______________________________________________________________________________ Robert Ionescu *The information contained in this message is confidential and may be legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.* On Thu, Mar 11, 2021 at 8:40 PM Michael Wojcik < Michael.Wojcik at microfocus.com> wrote: > > From: openssl-users On Behalf Of > Viktor > > Dukhovni > > Sent: Thursday, 11 March, 2021 10:39 > > To: openssl-users at openssl.org > > Subject: Re: Client certificate authentication > > > > > On Mar 11, 2021, at 2:16 PM, Robert Ionescu < > hightronicdesign at gmail.com> > > wrote: > > > > > > I am searching for the functions in openssl used to verify the clients > > > certificate when using mutual authentication. > > > My intention is to find a way to log a wrong user certificate directly > > inside > > > the openssl source. > > > > What does "wrong" mean? > > This is an important question. PKIX does not specify the interpretation of > the client certificate. While chain construction and most of validity > checks (signature, validity dates, basic constraints, KU and EKU, etc) > apply, the association between the identity claimed by the certificate and > the client is not determined by the standard. > > Even the form of that association and what is being identified are up to > the application. Conventionally, I believe these options are most commonly > used: > > 1. The client certificate identifies the peer system, i.e. the network > node that the server is communicating with. This might look symmetric with > the client's identification of the server, but it isn't, because a client > specifies a server identity (e.g. by hostname) and then verifies that using > the server certificate; but in the normal use case, the server has no prior > notion of the client system's identity. So the server might get the peer IP > address from the stack and then look for an IPADDR SAN in the client's > certificate which matches that, for example. The server might also attempt > reverse DNS (PTR record) resolution from the IP address to a hostname or > FQDN and look for a corresponding DNS SAN or Subject CN, though that option > is fraught with potential for abuse. > > 2. The client certificate identifies the user. Here the certificate is > issued to, and identifies, a person or other actor (e.g. the peer > application) rather than a network identity. What the server application > does with this information is a further question. > > 3. The client certificate matches a preconfigured allow list: The server > application just has some list of "permit any client identified by one of > these certificates". > > 4. The client certificate is validated but beyond that is used as an > opaque reference to some other database. This is a variation on #3. IBM's > CICS Web Interface provides this mode, where clients can send arbitrary > certificates as long as they're valid and belong to a chain that terminates > in one of the configured trust anchors. The handshake is completed. Then > the system will look that certificate up in the security database to see if > it's known and associated with a user identity. If not, the application (or > more properly the CWI subsystem) prompts for user credentials using HTTP > Basic Authentication (over the TLS channel); if that's successful, the > association between client certificate and user account is recorded and the > conversation continues. > > 5. No further vetting of the certificate is done. Essentially the client > authentication serves simply as a generic gatekeeper, so that only clients > possessing an acceptable certificate are allowed to establish a TLS > connection to the server. Any authentication beyond that is handled by the > application using other means. > > So a client certificate can be "wrong" in the basic PKIX sense of "invalid > certificate" or "can't build a path", but beyond that the interpretation is > up to the server-side application. > > -- > Michael Wojcik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1nagarjun1 at gmail.com Fri Mar 12 13:49:08 2021 From: 1nagarjun1 at gmail.com (Nagarjun J) Date: Fri, 12 Mar 2021 19:19:08 +0530 Subject: FIPS compliance with openssl-1.1.1j Message-ID: Hi, How to be FIPS compliance with openssl-1.1.1j version , as does not have fips object module, is they any ways? Regards Nagarjun -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Mar 12 14:39:40 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 12 Mar 2021 09:39:40 -0500 Subject: Client certificate authentication In-Reply-To: References: <891537D4-F8AF-436C-A40F-CC3FB9C81039@dukhovni.org> Message-ID: On Fri, Mar 12, 2021 at 09:06:57AM +0100, Robert Ionescu wrote: > With "wrong" certificate I meant "invalid certificate". So the idea > was in a bigger environment with a lot of certificates, to make the > invalid certificate debugging easier by getting more information from > openssl to identify the invalid certificate easier. Informal words like "wrong" or "invalid" still don't convey the actual meaning you have in mind, but in any case, the OpenSSL library provides callbacks that you can use to track the progress of and report errors in the certificate verification process. SSL_CTX_set_verify(3) SSL_set_verify(3) -- Viktor. From Michael.Wojcik at microfocus.com Fri Mar 12 15:24:39 2021 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 12 Mar 2021 15:24:39 +0000 Subject: FIPS compliance with openssl-1.1.1j In-Reply-To: References: Message-ID: > From: openssl-users On Behalf Of Nagarjun J > Sent: Friday, 12 March, 2021 06:49 > How to be FIPS compliance with openssl-1.1.1j version , as does not have fips > object module, is they any ways? It's possible, in theory; it's even been done. But it's almost certainly not feasible for your organization. You can port the OpenSSL 1.0.2 FOM to work with 1.1.1; Red Hat and SUSE both did that. Or write your own FIPS-140-compliant crypto layer. Then there's just the small matter of getting it validated, which involves some expense (tens of thousands of dollars) and delay (the CMVP is booked solid for the rest of the year, I hear); and the CMVP probably aren't going to do any more FIPS 140-2 validations after the current batch, now that FIPS 140-3 is here. If you did get the 1.0.2 FOM working with 1.1.1, it's possible you'd be able to convince some customers to accept a self-validation based on the existing OpenSSL validation. Of course the OpenSSL validation for the existing FOM is on the Historical list, which means it's not supposed to be used for new procurements anyway. So, in practice, no. Unless you're on Red Hat Enterprise Linux or SUSE Enterprise Linux and can use the FIPS-validated OpenSSL 1.1.1 they supply, I guess. (I assume that's available in some RHEL and SLES releases -- I haven't actually checked. I just know that Red Hat announced they'd done it, and SUSE actually published their patches.) If it's any consolation, many organizations are in the same boat. We have products which are still shipping FIPS, but that's with an OpenSSL 1.0.2 with Premium Support and in some cases with a substitute FIPS module that we developed years ago and got our own validations for. That's not an option for most people. (I don't blame openssl.org for this state of affairs -- FIPS validations are expensive and resource-intensive, and few OpenSSL consumers support the project. Yes, 3.0 has slipped its original schedule by quite a lot, but better to get it right.) -- Michael Wojcik From jmr_sultan at hotmail.com Sun Mar 14 10:35:17 2021 From: jmr_sultan at hotmail.com (=?iso-8859-1?Q?Jes=FAs_Molina_Rold=E1n?=) Date: Sun, 14 Mar 2021 10:35:17 +0000 Subject: modern algorithms performance in TLS 1.3 Message-ID: Dear, Actually I'm doing the final project degree about modern algorithms performance in TLS 1.3. I would like to know if you can confirm some questions: -The calculation of the shared secret of ECDH/DH for TLS 1.3 in the library openssl is calculated in the function ssl_derive from the class s3_lib.c in the part of the code: if (EVP_PKEY_derive(pctx, pms, &pmslen) <= 0) { SSLfatal(s, SSL_AD_INTERNAL_ERROR, SSL_F_SSL_DERIVE, ERR_R_INTERNAL_ERROR); goto err; } Is it correct to calculate the keygen performance using the EVP_PKEY_keygen function? Is it correct to calculate the performance of signing and verifying using EVP_PKEY_verify and EVP_PKEY_sign function? And in the case of ED25519 using ED25519_sign and ED25519_verify from curve25519.c? Thanks for all. Jesus -------------- next part -------------- An HTML attachment was scrubbed... URL: From hightronicdesign at gmail.com Mon Mar 15 11:23:54 2021 From: hightronicdesign at gmail.com (Robert Ionescu) Date: Mon, 15 Mar 2021 12:23:54 +0100 Subject: Client certificate authentication In-Reply-To: References: <891537D4-F8AF-436C-A40F-CC3FB9C81039@dukhovni.org> Message-ID: I already found the callbacks for the verification process and I am still trying to figure it out if it is possible to change them in a way that they will print some certificate information to determine which certificate was used? _______________________________________________________________________________ Robert Ionescu *The information contained in this message is confidential and may be legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.* On Fri, Mar 12, 2021 at 3:39 PM Viktor Dukhovni wrote: > On Fri, Mar 12, 2021 at 09:06:57AM +0100, Robert Ionescu wrote: > > > With "wrong" certificate I meant "invalid certificate". So the idea > > was in a bigger environment with a lot of certificates, to make the > > invalid certificate debugging easier by getting more information from > > openssl to identify the invalid certificate easier. > > Informal words like "wrong" or "invalid" still don't convey the actual > meaning you have in mind, but in any case, the OpenSSL library provides > callbacks that you can use to track the progress of and report errors > in the certificate verification process. > > SSL_CTX_set_verify(3) > SSL_set_verify(3) > > -- > Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Mar 15 11:38:03 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 15 Mar 2021 07:38:03 -0400 Subject: Client certificate authentication In-Reply-To: References: <891537D4-F8AF-436C-A40F-CC3FB9C81039@dukhovni.org> Message-ID: On Mon, Mar 15, 2021 at 12:23:54PM +0100, Robert Ionescu wrote: > I already found the callbacks for the verification process and I am > still trying to figure it out if it is possible to change them in a > way that they will print some certificate information to determine > which certificate was used? What do you mean "change them"? These are callbacks, you register the callback function in the application, and then do whatever you want in that function, including print certificate information, if that's your goal. There's nothing to "change". The verification Postfix uses for optional certificate verification verbosity is at: https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_verify.c#L139-L185 -- Viktor. From hightronicdesign at gmail.com Mon Mar 15 23:05:35 2021 From: hightronicdesign at gmail.com (Robert Ionescu) Date: Tue, 16 Mar 2021 00:05:35 +0100 Subject: Client certificate authentication In-Reply-To: References: <891537D4-F8AF-436C-A40F-CC3FB9C81039@dukhovni.org> Message-ID: Hmm ok I get it. So, to be able to get the fingerprint for the used certificates during a TLS handshake is possible by using the SSL_set_verify callbacks in the application or is the mentioned postfix useful for this purpose? _______________________________________________________________________________ Robert Ionescu *The information contained in this message is confidential and may be legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.* On Mon, Mar 15, 2021 at 12:46 PM Viktor Dukhovni wrote: > On Mon, Mar 15, 2021 at 12:23:54PM +0100, Robert Ionescu wrote: > > > I already found the callbacks for the verification process and I am > > still trying to figure it out if it is possible to change them in a > > way that they will print some certificate information to determine > > which certificate was used? > > What do you mean "change them"? These are callbacks, you register the > callback function in the application, and then do whatever you want in > that function, including print certificate information, if that's your > goal. There's nothing to "change". > > The verification Postfix uses for optional certificate verification > verbosity is at: > > > https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_verify.c#L139-L185 > > -- > Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomiii at tomiii.com Mon Mar 15 23:53:54 2021 From: tomiii at tomiii.com (Thomas Dwyer III) Date: Mon, 15 Mar 2021 16:53:54 -0700 Subject: Is SSL_CTX_set_tmp_rsa_callback() only for small keys? Message-ID: I'm porting some very old code from 1.0.2 to 3.0 (but it still has to compile for both) and I'm trying to understand it's use of SSL_CTX_set_tmp_rsa_callback(). It looks like this was removed in 1.1.0 but it's not obvious to me why it was necessary in the first place. My read of the 1.0.2 man page suggests that the callback is only invoked for very small key sizes in order to comply with US export restrictions from decades ago, but I'm having trouble confirming this via code inspection. Is my understanding correct and, given that this code will never see RSA keys smaller than 2048 bits, I can just delete the callback rather than add a bunch of: #if OPENSSL_VERSION_NUMBER < 0x10100000L ... #endif Or is there some fundamental difference between the way key exchange works in 1.0.2 compared to later versions that makes the callback in 1.0.2 still necessary? Thanks, Tom.III -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Mar 16 00:15:49 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 16 Mar 2021 00:15:49 +0000 Subject: Is SSL_CTX_set_tmp_rsa_callback() only for small keys? In-Reply-To: References: Message-ID: On 15/03/2021 23:53, Thomas Dwyer III wrote: > I'm porting some very old code from 1.0.2 to 3.0 (but it still has to > compile for both) and I'm trying to understand it's use of > SSL_CTX_set_tmp_rsa_callback(). It looks like this was removed in 1.1.0 > but it's not obvious to me why it was necessary in the first place. My > read of the 1.0.2 man page suggests that the callback is only invoked > for very small key sizes in order to comply with US export restrictions > from decades ago, but I'm having trouble confirming this via code > inspection. Is my understanding correct and, given that this code will > never see RSA keys smaller than 2048 bits, I can just delete the > callback rather than add a bunch of: > > #if OPENSSL_VERSION_NUMBER < 0x10100000L > ... > #endif > > Or is there some fundamental difference between the way key exchange > works in 1.0.2 compared to later versions that makes the callback in > 1.0.2 still necessary? You are correct. Just delete the code. Matt From kan.chen at huawei.com Tue Mar 16 03:30:14 2021 From: kan.chen at huawei.com (Chenxinping) Date: Tue, 16 Mar 2021 03:30:14 +0000 Subject: Why legacy implement still linked in the libcrypto? Message-ID: <5df26658a3ec4517a9a56197a63f8a2c@huawei.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhat.jayalakshmi at gmail.com Tue Mar 16 05:49:04 2021 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Tue, 16 Mar 2021 11:19:04 +0530 Subject: Question on RSA engine and Key strength Message-ID: Hi All, We are writing a RSA engine for OpenSSL library to handle certificates up to 4096 bytes strength. We do support certificates up to 8k. How to we make engine to handle certificates only up to 4K and others handled by OpenSSL itself. Any help, inputs are appreciated. Thanks and Regards, Jayalakshmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgm at htt-consult.com Wed Mar 17 21:50:41 2021 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 17 Mar 2021 17:50:41 -0400 Subject: Creating an X25519 client certificate Message-ID: <5538d449-6799-6278-7e62-c8abe998902f@htt-consult.com> I have created my X25519 pub/priv keypair with: openssl genpkey -algorithm X25519\ ??? -out $dir/private/$clientemail-X.key.$format And displays properly with: openssl pkey -in $dir/private/$clientemail-X.key.$format -text -noout So now to make the csr with: openssl req -config $dir/openssl-intermediate.cnf\ ??? -key $dir/private/$clientemail-X.key.$format \ ??? -subj "$DN" -new -out $dir/csr/$clientemail-X.csr.$format which is what I used for ED25519 client certs.? But I get an error: 140487683954496:error:0608D096:digital envelope routines:EVP_PKEY_sign_init:operation not supported for this keytype:crypto/evp/pmeth_fn.c:39: I can't figure out from my config file why this error.? and googling the error has not helped.? yet. Can someone point me to what I am missing? Oh, and I am ASSuMEing that a CA cert of ED25519 signs an X25519 client cert.? Haven't found instructions on this, but it seems reasonable... thanks From openssl-users at dukhovni.org Wed Mar 17 23:22:03 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 17 Mar 2021 19:22:03 -0400 Subject: Creating an X25519 client certificate In-Reply-To: <5538d449-6799-6278-7e62-c8abe998902f@htt-consult.com> References: <5538d449-6799-6278-7e62-c8abe998902f@htt-consult.com> Message-ID: On Wed, Mar 17, 2021 at 05:50:41PM -0400, Robert Moskowitz wrote: > I have created my X25519 pub/priv keypair with: > > openssl genpkey -algorithm X25519\ > ??? -out $dir/private/$clientemail-X.key.$format Are you sure you didn't want ed25519 instead? X25519 is a key agreement menthod, not a signature method. > openssl req -config $dir/openssl-intermediate.cnf\ > ??? -key $dir/private/$clientemail-X.key.$format \ > ??? -subj "$DN" -new -out $dir/csr/$clientemail-X.csr.$format > > which is what I used for ED25519 client certs.? But I get an error: > > 140487683954496:error:0608D096:digital envelope > routines:EVP_PKEY_sign_init:operation not supported for this > keytype:crypto/evp/pmeth_fn.c:39: Not surprising, why do you expect this to work? > Can someone point me to what I am missing? > > Oh, and I am ASSuMEing that a CA cert of ED25519 signs an X25519 client > cert.? Haven't found instructions on this, but it seems reasonable... https://crypto.stackexchange.com/questions/27866/why-curve25519-for-encryption-but-ed25519-for-signatures -- Viktor. From rgm at htt-consult.com Wed Mar 17 23:44:05 2021 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 17 Mar 2021 19:44:05 -0400 Subject: Creating an X25519 client certificate In-Reply-To: References: <5538d449-6799-6278-7e62-c8abe998902f@htt-consult.com> Message-ID: On 3/17/21 7:22 PM, Viktor Dukhovni wrote: > On Wed, Mar 17, 2021 at 05:50:41PM -0400, Robert Moskowitz wrote: > >> I have created my X25519 pub/priv keypair with: >> >> openssl genpkey -algorithm X25519\ >> ??? -out $dir/private/$clientemail-X.key.$format > Are you sure you didn't want ed25519 instead? X25519 is a key agreement > menthod, not a signature method. My limited understanding is that for encrypted S/MIME, and ECDH cert is needed.? Thus if ED25519 is used for signing said S/MIME, X25519 is used for encrypting. I have seen CA Cert policies for "Device Encryption Certificates" that use:? id-ecPublicKey {1 2 840 10045 2 1}; I need to talk to the CP author more about this and what he sees the equiv Edward cert would look like. > >> openssl req -config $dir/openssl-intermediate.cnf\ >> ??? -key $dir/private/$clientemail-X.key.$format \ >> ??? -subj "$DN" -new -out $dir/csr/$clientemail-X.csr.$format >> >> which is what I used for ED25519 client certs.? But I get an error: >> >> 140487683954496:error:0608D096:digital envelope >> routines:EVP_PKEY_sign_init:operation not supported for this >> keytype:crypto/evp/pmeth_fn.c:39: > Not surprising, why do you expect this to work? Shooting from the hip, a bit.? If I am going to have an X25519 cert, then I need a csr and this is the command to make one.? So try it and see what it does.? Not too well, it turns out. > >> Can someone point me to what I am missing? >> >> Oh, and I am ASSuMEing that a CA cert of ED25519 signs an X25519 client >> cert.? Haven't found instructions on this, but it seems reasonable... > https://crypto.stackexchange.com/questions/27866/why-curve25519-for-encryption-but-ed25519-for-signatures > very familiar with this point and did look at this response during my searches today. I quite understand in TLS the use of EdDSA certs that allow keyEncipherment and ?dataEncipherment? to permit an ECDHE exchange. but my limited research claims that for S/MIME you can have an X25519 cert for static ECDH, rather than ephemeral, saving supposedly the exchange of keys before sending encrypted S/MIME. From openssl-users at dukhovni.org Thu Mar 18 00:17:29 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 17 Mar 2021 20:17:29 -0400 Subject: Creating an X25519 client certificate In-Reply-To: References: <5538d449-6799-6278-7e62-c8abe998902f@htt-consult.com> Message-ID: On Wed, Mar 17, 2021 at 07:44:05PM -0400, Robert Moskowitz wrote: > >> I have created my X25519 pub/priv keypair with: > >> > >> openssl genpkey -algorithm X25519\ > >> ??? -out $dir/private/$clientemail-X.key.$format > > > Are you sure you didn't want ed25519 instead? X25519 is a key agreement > > menthod, not a signature method. > > My limited understanding is that for encrypted S/MIME, and ECDH cert > is needed.? Thus if ED25519 is used for signing said S/MIME, X25519 is > used for encrypting. I see, this is for CMS, so you're trying to support: https://tools.ietf.org/html/draft-ietf-curdle-cms-ecdh-new-curves-10 > >> openssl req -config $dir/openssl-intermediate.cnf\ > >> ??? -key $dir/private/$clientemail-X.key.$format \ > >> ??? -subj "$DN" -new -out $dir/csr/$clientemail-X.csr.$format > >> > >> which is what I used for ED25519 client certs.? But I get an error: > >> > >> 140487683954496:error:0608D096:digital envelope > >> routines:EVP_PKEY_sign_init:operation not supported for this > >> keytype:crypto/evp/pmeth_fn.c:39: > > Not surprising, why do you expect this to work? > > Shooting from the hip, a bit.? If I am going to have an X25519 cert, > then I need a csr and this is the command to make one.? So try it and > see what it does.? Not too well, it turns out. Well, CSRs are self-signed, and X25519 does not support signing, so you CANNOT have an X25519 CSR. You can however create an X25519 certificate directly for a given key: https://crypto.stackexchange.com/questions/19452/static-dh-static-ecdh-certificate-using-openssl with other details (names, extensions, ...) pulled from a CSR. What can't get is proof of posession. > >> Oh, and I am ASSuMEing that a CA cert of ED25519 signs an X25519 client > >> cert.? Haven't found instructions on this, but it seems reasonable... > > https://crypto.stackexchange.com/questions/27866/why-curve25519-for-encryption-but-ed25519-for-signatures Well the CA can use any algorithm that supports signing, and is widely supported. It does not have to be Ed25519. -- Viktor. From rgm at htt-consult.com Thu Mar 18 01:22:24 2021 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 17 Mar 2021 21:22:24 -0400 Subject: Creating an X25519 client certificate In-Reply-To: References: <5538d449-6799-6278-7e62-c8abe998902f@htt-consult.com> Message-ID: <0f17dc4f-cf26-22ce-5c4d-67caf570cee4@htt-consult.com> On 3/17/21 8:17 PM, Viktor Dukhovni wrote: > On Wed, Mar 17, 2021 at 07:44:05PM -0400, Robert Moskowitz wrote: > >>>> I have created my X25519 pub/priv keypair with: >>>> >>>> openssl genpkey -algorithm X25519\ >>>> ??? -out $dir/private/$clientemail-X.key.$format >>> Are you sure you didn't want ed25519 instead? X25519 is a key agreement >>> menthod, not a signature method. >> My limited understanding is that for encrypted S/MIME, and ECDH cert >> is needed.? Thus if ED25519 is used for signing said S/MIME, X25519 is >> used for encrypting. > I see, this is for CMS, so you're trying to support: > > https://tools.ietf.org/html/draft-ietf-curdle-cms-ecdh-new-curves-10 > >>>> openssl req -config $dir/openssl-intermediate.cnf\ >>>> ??? -key $dir/private/$clientemail-X.key.$format \ >>>> ??? -subj "$DN" -new -out $dir/csr/$clientemail-X.csr.$format >>>> >>>> which is what I used for ED25519 client certs.? But I get an error: >>>> >>>> 140487683954496:error:0608D096:digital envelope >>>> routines:EVP_PKEY_sign_init:operation not supported for this >>>> keytype:crypto/evp/pmeth_fn.c:39: >>> Not surprising, why do you expect this to work? >> Shooting from the hip, a bit.? If I am going to have an X25519 cert, >> then I need a csr and this is the command to make one.? So try it and >> see what it does.? Not too well, it turns out. > Well, CSRs are self-signed, and X25519 does not support signing, so > you CANNOT have an X25519 CSR. Slap myself on the forehead.... Of course I know that.? But did not stop to think this through.?? :( Will read through all this and get back here.... > You can however create an X25519 > certificate directly for a given key: > > https://crypto.stackexchange.com/questions/19452/static-dh-static-ecdh-certificate-using-openssl > > with other details (names, extensions, ...) pulled from a CSR. > What can't get is proof of posession. > >>>> Oh, and I am ASSuMEing that a CA cert of ED25519 signs an X25519 client >>>> cert.? Haven't found instructions on this, but it seems reasonable... >>> https://crypto.stackexchange.com/questions/27866/why-curve25519-for-encryption-but-ed25519-for-signatures > Well the CA can use any algorithm that supports signing, and is widely > supported. It does not have to be Ed25519. > From tincanteksup at gmail.com Thu Mar 18 01:48:26 2021 From: tincanteksup at gmail.com (tincanteksup) Date: Thu, 18 Mar 2021 01:48:26 +0000 Subject: Creating an X25519 client certificate In-Reply-To: <0f17dc4f-cf26-22ce-5c4d-67caf570cee4@htt-consult.com> References: <5538d449-6799-6278-7e62-c8abe998902f@htt-consult.com> <0f17dc4f-cf26-22ce-5c4d-67caf570cee4@htt-consult.com> Message-ID: <39f16618-b118-99d9-1c12-ee20ed195780@gmail.com> On 18/03/2021 01:22, Robert Moskowitz wrote: > > > On 3/17/21 8:17 PM, Viktor Dukhovni wrote: >> Well, CSRs are self-signed, and X25519 does not support signing, so >> you CANNOT have an X25519 CSR. > > Slap myself on the forehead.... > > Of course I know that.? But did not stop to think this through.?? :( > > Will read through all this and get back here.... > Wait until you spend 3 days waiting for an answer about Firefox which I accidentally asked in #VBox .. My forehead still bears the palm print and smarts! I think it was the 'ox' which blinded me for so long. ;-) From rgm at htt-consult.com Thu Mar 18 14:43:06 2021 From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 18 Mar 2021 10:43:06 -0400 Subject: Creating an X25519 client certificate In-Reply-To: <39f16618-b118-99d9-1c12-ee20ed195780@gmail.com> References: <5538d449-6799-6278-7e62-c8abe998902f@htt-consult.com> <0f17dc4f-cf26-22ce-5c4d-67caf570cee4@htt-consult.com> <39f16618-b118-99d9-1c12-ee20ed195780@gmail.com> Message-ID: <7e296cf5-a741-49ca-f417-b3e88575ef1d@htt-consult.com> On 3/17/21 9:48 PM, tincanteksup wrote: > > > On 18/03/2021 01:22, Robert Moskowitz wrote: >> >> >> On 3/17/21 8:17 PM, Viktor Dukhovni wrote: >>> Well, CSRs are self-signed, and X25519 does not support signing, so >>> you CANNOT have an X25519 CSR. >> >> Slap myself on the forehead.... >> >> Of course I know that.? But did not stop to think this through.?? :( >> >> Will read through all this and get back here.... >> > > Wait until you spend 3 days waiting for an answer about Firefox > which I accidentally asked in #VBox .. > > My forehead still bears the palm print and smarts! > I think it was the 'ox' which blinded me for so long. ;-) I will have to discuss this with Russ... A quick 'solution' to proof of ownership COULD be achieved IF: The CA has an ECDH cert signed with its signing cert. The client uses this to create a shared secret to KMAC the CSR. The devil is in the details and I have other fish to fry... From dv at vollmann.ch Thu Mar 18 20:07:20 2021 From: dv at vollmann.ch (Detlef Vollmann) Date: Thu, 18 Mar 2021 21:07:20 +0100 Subject: OCSP verification in a non-blocking environment Message-ID: <68912769-b851-fe8b-77b4-21bbbceeb95f@vollmann.ch> I have a non-blocking DTLS server and use SSL_VERIFY_PEER. Now I'd like to use the verify_callback that I set with SSL_CTX_set_verify() to check via OCSP for revocation. This works fine in a simple blocking test program, where I can just wait for the OCSP reply and then return 0 or 1 from my verify_callback function dependent on this reply. But in a non-blocking program I can't wait for the OCSP reply, but I also can't return -1 from my verify_callback function to tell the handshake code to call the callback again. Am I right that I can only do a non-blocking OCSP check after the handshake has finished? Detlef From matt at openssl.org Mon Mar 22 09:18:12 2021 From: matt at openssl.org (Matt Caswell) Date: Mon, 22 Mar 2021 09:18:12 +0000 Subject: Forthcoming OpenSSL release Message-ID: <25278da8-52f1-d282-5767-24beddb72254@openssl.org> The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.1k. This release will be made available on Thursday 25th March 2021 between 1300-1700 UTC. OpenSSL 1.1.1k is a security-fix release. The highest severity issue fixed in this release is HIGH: https://www.openssl.org/policies/secpolicy.html#high Yours The OpenSSL Project Team From realburner at gmx.de Mon Mar 22 14:18:19 2021 From: realburner at gmx.de (Robert Burner Schadek) Date: Mon, 22 Mar 2021 15:18:19 +0100 Subject: Envelope problem In-Reply-To: References: Message-ID: Well, I used the openssl cli program, and cut everything out that wasn't required. The results can be seen here. https://gist.github.com/burner/4d87d1421e39627f84316bc2892e6103 From lists at optimcloud.com Tue Mar 23 02:37:04 2021 From: lists at optimcloud.com (Embedded Devel) Date: Tue, 23 Mar 2021 09:37:04 +0700 Subject: ssl client write / server accept seems broken Message-ID: I have an application previously written for us 10+ years ago that no longer seems to be happy and the original dev is no? longer available, so who can i pay to bang this out and make it happy, or who can guide me through getting it functional... basic info below. I have a client process which is supposed to speak to a server via ssl, and then send data Ive created a "CA" and generated the CSR / and certs for both the client and the server. when i run the client - i get an error on the client side Tue Mar 23 02:13:58 2021 user.err : ac_ssl_client_write(): Error SSL_ERROR_SSL - return code: -1. Tue Mar 23 02:13:58 2021 user.info : ac_send_init(): Error here is the specific snippt of c thats failing int ac_ssl_client_write(ac_ssl_conn_t *ssl_con, void *buf, int buf_len) { ??????? fd_set write_fds; ??????? struct timeval tv; ??????? int rc = -1; ??????? tv.tv_sec = TIMEOUT_WRITE; ??????? tv.tv_usec = 0; ??????? FD_ZERO(&write_fds); ??????? FD_SET(ssl_con->socket, &write_fds); ??????? if ((rc = select(ssl_con->socket + 1, NULL, &write_fds, NULL, &tv)) == 1) { ??????????????? if (FD_ISSET(ssl_con->socket, &write_fds)) { ??????????????????????? rc = SSL_write(ssl_con->ssl, buf, buf_len); ??????????????????????? if(ac_ssl_handle_err(ssl_con, rc, "ac_ssl_client_write()", "") != 0) ??????????????????????????????? return -1; ??????????????? } ??????? } ??????? FD_CLR(ssl_con->socket, &write_fds); ??????? return rc; } and like wise i get this error on the server side Mar 23 03:13:58 optim04 ac_server[597280]: ac_ssl_server_accept(): Error SSL_ERROR_SYSCALL - return code: -1. SSL_accept() Mar 23 03:13:58 optim04 ac_server[597280]: ac_ssl_server_accept(): Error code: -3 which ive located in this snippet of code /* Accept SSL Connection */ int ac_ssl_server_accept(ac_ssl_conn_t *ssl_con) { ??????? int rc = -1; ??????? /* Load Key and Certficates */ ??????? if ((rc = ac_ssl_server_certs(ssl_con)) != 0) { ??????????????? LOG(LOG_ERR, "ac_ssl_server_certs(): Error code %d\n", rc); ??????????????? return -1; ??????? } ??????? if ((ssl_con->ssl = SSL_new(ssl_con->ctx)) == NULL) { ??????????????? LOG(LOG_ERR, "SSL_new(): Error\n"); ??????????????? close(ssl_con->socket); ??????????????? if (ssl_con->ctx != NULL) ??????????????????????? SSL_CTX_free(ssl_con->ctx); ??????????????? return -2; ??????? } ??????? SSL_set_fd(ssl_con->ssl, ssl_con->socket); ??????? SSL_set_accept_state(ssl_con->ssl); ??????? rc = SSL_accept(ssl_con->ssl); ??????? if(ac_ssl_handle_err(ssl_con, rc, "ac_ssl_server_accept()", "SSL_accept()") == 1) ??????????????? return -3; ??????? return 0; } From matt at openssl.org Tue Mar 23 14:31:00 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 23 Mar 2021 14:31:00 +0000 Subject: ssl client write / server accept seems broken In-Reply-To: References: Message-ID: <16b17ec9-784d-96d1-50df-32aea3d174bb@openssl.org> On 23/03/2021 02:37, Embedded Devel wrote: > I have an application previously written for us 10+ years ago that no > longer seems to be happy Has something happened that might have caused this? Did you upgrade OpenSSL, or do some other kind of update to your code? Which version of OpenSSL are you using? > > and the original dev is no? longer available, so who can i pay to bang > this out and make it happy, or who can guide me through getting it > functional... basic info below. > > I have a client process which is supposed to speak to a server via ssl, > and then send data > > Ive created a "CA" and generated the CSR / and certs for both the client > and the server. What kind of certs did you generate? How big are the keys? Are you able to share the certs (not the keys)? > > when i run the client - i get an error on the client side > > Tue Mar 23 02:13:58 2021 user.err : ac_ssl_client_write(): Error > SSL_ERROR_SSL - return code: -1. > Tue Mar 23 02:13:58 2021 user.info : ac_send_init(): Error It would be useful to see any errors on the OpenSSL error stack which might provide more details about specifically what has failed. For example you can call the `ERR_print_errors_fp` function to dump the error stack to a `FILE *`. Or alternatively use the `ERR_*` functions to examine the stack and print it to your log: https://www.openssl.org/docs/man1.1.1/man3/ Matt From lists at optimcloud.com Tue Mar 23 15:02:55 2021 From: lists at optimcloud.com (Embedded Devel) Date: Tue, 23 Mar 2021 22:02:55 +0700 Subject: ssl client write / server accept seems broken In-Reply-To: <16b17ec9-784d-96d1-50df-32aea3d174bb@openssl.org> References: <16b17ec9-784d-96d1-50df-32aea3d174bb@openssl.org> Message-ID: On 3/23/21 9:31 PM, Matt Caswell wrote: > > > On 23/03/2021 02:37, Embedded Devel wrote: >> I have an application previously written for us 10+ years ago that no >> longer seems to be happy > > Has something happened that might have caused this? Did you upgrade > OpenSSL, or do some other kind of update to your code? > > Which version of OpenSSL are you using? surely an openssl upgrade, this code is maybe 7-8 years old OpenSSL 1.1.1g FIPS? 21 Apr 2020 Centos 7 > > >> >> and the original dev is no? longer available, so who can i pay to >> bang this out and make it happy, or who can guide me through getting >> it functional... basic info below. >> >> I have a client process which is supposed to speak to a server via >> ssl, and then send data >> >> Ive created a "CA" and generated the CSR / and certs for both the >> client and the server. > > What kind of certs did you generate? How big are the keys? Are you > able to share the certs (not the keys)? original expired certs -rw-r--r-- 1 root root 1424 Mar 22 16:59 ac_ca_cert.pem -rw-r--r-- 1 root root 1675 Mar 22 16:59 ac_ca_key.pem -rw-r--r-- 1 root root 1168 Mar 22 16:59 ac_client_cert.pem -rw-r--r-- 1 root root 1675 Mar 22 16:59 ac_client_key.pem -rw-r--r-- 1 root root 1168 Mar 22 16:59 ac_server_cert.pem -rw-r--r-- 1 root root 1675 Mar 22 16:59 ac_server_key.pem -rw------- 1 root root 1204 Mar 22 18:24 ca.crt -rw------- 1 root root 1766 Mar 22 18:23 ca.key new certs -rw-r--r-- 1 root root 1529 Mar 22 17:45 myCA.pem -rw-r--r-- 1 root root 1566 Mar 22 18:04 portaladmin.domain.com.crt -rw-r--r-- 1 root root 1115 Mar 22 18:04 portaladmin.domain.com.csr -rw-r--r-- 1 root root? 216 Mar 22 18:04 portaladmin.domain.com.ext -rw------- 1 root root 1675 Mar 22 18:04 portaladmin.domain.com.key i can share the certs -----BEGIN CERTIFICATE----- MIIEVjCCAz6gAwIBAgIUUfHyC4C5rTOHqYIC2WAmV7t06jowDQYJKoZIhvcNAQEL BQAwga0xCzAJBgNVBAYTAk5MMRUwEwYDVQQIDAxTJ0dyYXZlbmhhZ2UxFDASBgNV BAcMC1NHcmF2ZW5oYWdlMR0wGwYDVQQKDBRPcHRpbSBFbnRlcnByaXNlcyBCVjER MA8GA1UECwwIV2lyZWxlc3MxGjAYBgNVBAMMEWNhLm9wdGltY2xvdWQuY29tMSMw IQYJKoZIhvcNAQkBFhRhZG1pbkBvcHRpbWNsb3VkLmNvbTAeFw0yMTAzMjIxNzA0 MDlaFw0yMzA2MjUxNzA0MDlaMIG3MQswCQYDVQQGEwJOTDEVMBMGA1UECAwMUydH cmF2ZW5oYWdlMRUwEwYDVQQHDAxTJ0dyYXZlbmhhZ2UxHTAbBgNVBAoMFE9wdGlt IEVudGVycHJpc2VzIEJWMREwDwYDVQQLDAhXaXJlbGVzczEjMCEGA1UEAwwacG9y dGFsYWRtaW4ub3B0aW1jbG91ZC5jb20xIzAhBgkqhkiG9w0BCQEWFGFkbWluQG9w dGltY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuUqI 0sHGKXuSMuEVOvJzPDmMX8HLhIA1qXlBbanEMfdMMTwXelZrQYMYj0D9eiuXfWLE ddawppFbhFgLpVBG4sG0G9Asm92Knk/9XCONqblvTSIWL1b24LiGQ45At/IeQE7j UVXoCsivZds2rUQFIWa6ctXZBBCDxBp/RmHZYvaNKuP21mapRh7//eWmzrA5kSgG 4YhGUys38bqsuTJu7I5lDxT1FcJKpYlQn6EZyGPlplYI6JindGUNZVbvHKQlaQ/a Mom+nJDcbl01G4+AukKcu+AXBCFAA0FDax64bu3EX5phmSSPZymX+RcmJUEU/kxb /sRUcCwHxtgLXOGwrQIDAQABo2IwYDAfBgNVHSMEGDAWgBSyC0km1cK4ENeQhkI5 VN/hEFcBVDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIE8DAlBgNVHREEHjAcghpwb3J0 YWxhZG1pbi5vcHRpbWNsb3VkLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAEto6D/Gt rTR6Qf3cCrwosI9PpnIRD+Sp3QceMTevuajdCKGU58dTG0MNvqAmr/CmJ4ih9UBi IBAyR+QxT47PC8bZFSJMI6a3FesTEpAkQnmwkEr3dZ1zns0+651HwsUMuOkAKnYr 4JId48f8NAuSnDKUZeUytAr7lJ+DN32Qa8HQXb78bXuElMjYzUwapMNwJ9NrQjIQ bUbvByGHFq67maP+/UuxnIJB7vIs9W1Krxx9ewXdKdDpHCyWynnxnWvefVx6aBFR eIOySv/Wf2rjFvRRS/kdYKXbzj5eUzdRVrka21AfpBqB/ZHFCHCy47PyUYurln30 hd/EInnSdA1pmg== -----END CERTIFICATE----- IM inclined top think the code for the certs is ok, but? can really say, and im not an openssl programmer by any means... just need someone to put eyes on the code and fix it really. >> >> when i run the client - i get an error on the client side >> >> Tue Mar 23 02:13:58 2021 user.err : ac_ssl_client_write(): Error >> SSL_ERROR_SSL - return code: -1. >> Tue Mar 23 02:13:58 2021 user.info : ac_send_init(): Error > > > It would be useful to see any errors on the OpenSSL error stack which > might provide more details about specifically what has failed. For > example you can call the `ERR_print_errors_fp` function to dump the > error stack to a `FILE *`. Or alternatively use the `ERR_*` functions > to examine the stack and print it to your log: Yupp above my head.... :( and lastly if it helps ? openssl s_client -connect 46.23.86.244:3490 CONNECTED(00000003) Can't use SSL_get_servername depth=1 C = NL, ST = S'Gravenhage, L = SGravenhage, O = Optim Enterprises BV, OU = Wireless, CN = ca.optimcloud.com, emailAddress = admin at optimcloud.com verify error:num=19:self signed certificate in certificate chain verify return:1 depth=1 C = NL, ST = S'Gravenhage, L = SGravenhage, O = Optim Enterprises BV, OU = Wireless, CN = ca.optimcloud.com, emailAddress = admin at optimcloud.com verify return:1 depth=0 C = NL, ST = S'Gravenhage, L = S'Gravenhage, O = Optim Enterprises BV, OU = Wireless, CN = portaladmin.optimcloud.com, emailAddress = admin at optimcloud.com verify return:1 --- Certificate chain ?0 s:C = NL, ST = S'Gravenhage, L = S'Gravenhage, O = Optim Enterprises BV, OU = Wireless, CN = portaladmin.optimcloud.com, emailAddress = admin at optimcloud.com ?? i:C = NL, ST = S'Gravenhage, L = SGravenhage, O = Optim Enterprises BV, OU = Wireless, CN = ca.optimcloud.com, emailAddress = admin at optimcloud.com ?1 s:C = NL, ST = S'Gravenhage, L = SGravenhage, O = Optim Enterprises BV, OU = Wireless, CN = ca.optimcloud.com, emailAddress = admin at optimcloud.com ?? i:C = NL, ST = S'Gravenhage, L = SGravenhage, O = Optim Enterprises BV, OU = Wireless, CN = ca.optimcloud.com, emailAddress = admin at optimcloud.com --- Server certificate -----BEGIN CERTIFICATE----- MIIEVjCCAz6gAwIBAgIUUfHyC4C5rTOHqYIC2WAmV7t06jowDQYJKoZIhvcNAQEL BQAwga0xCzAJBgNVBAYTAk5MMRUwEwYDVQQIDAxTJ0dyYXZlbmhhZ2UxFDASBgNV BAcMC1NHcmF2ZW5oYWdlMR0wGwYDVQQKDBRPcHRpbSBFbnRlcnByaXNlcyBCVjER MA8GA1UECwwIV2lyZWxlc3MxGjAYBgNVBAMMEWNhLm9wdGltY2xvdWQuY29tMSMw IQYJKoZIhvcNAQkBFhRhZG1pbkBvcHRpbWNsb3VkLmNvbTAeFw0yMTAzMjIxNzA0 MDlaFw0yMzA2MjUxNzA0MDlaMIG3MQswCQYDVQQGEwJOTDEVMBMGA1UECAwMUydH cmF2ZW5oYWdlMRUwEwYDVQQHDAxTJ0dyYXZlbmhhZ2UxHTAbBgNVBAoMFE9wdGlt IEVudGVycHJpc2VzIEJWMREwDwYDVQQLDAhXaXJlbGVzczEjMCEGA1UEAwwacG9y dGFsYWRtaW4ub3B0aW1jbG91ZC5jb20xIzAhBgkqhkiG9w0BCQEWFGFkbWluQG9w dGltY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuUqI 0sHGKXuSMuEVOvJzPDmMX8HLhIA1qXlBbanEMfdMMTwXelZrQYMYj0D9eiuXfWLE ddawppFbhFgLpVBG4sG0G9Asm92Knk/9XCONqblvTSIWL1b24LiGQ45At/IeQE7j UVXoCsivZds2rUQFIWa6ctXZBBCDxBp/RmHZYvaNKuP21mapRh7//eWmzrA5kSgG 4YhGUys38bqsuTJu7I5lDxT1FcJKpYlQn6EZyGPlplYI6JindGUNZVbvHKQlaQ/a Mom+nJDcbl01G4+AukKcu+AXBCFAA0FDax64bu3EX5phmSSPZymX+RcmJUEU/kxb /sRUcCwHxtgLXOGwrQIDAQABo2IwYDAfBgNVHSMEGDAWgBSyC0km1cK4ENeQhkI5 VN/hEFcBVDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIE8DAlBgNVHREEHjAcghpwb3J0 YWxhZG1pbi5vcHRpbWNsb3VkLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAEto6D/Gt rTR6Qf3cCrwosI9PpnIRD+Sp3QceMTevuajdCKGU58dTG0MNvqAmr/CmJ4ih9UBi IBAyR+QxT47PC8bZFSJMI6a3FesTEpAkQnmwkEr3dZ1zns0+651HwsUMuOkAKnYr 4JId48f8NAuSnDKUZeUytAr7lJ+DN32Qa8HQXb78bXuElMjYzUwapMNwJ9NrQjIQ bUbvByGHFq67maP+/UuxnIJB7vIs9W1Krxx9ewXdKdDpHCyWynnxnWvefVx6aBFR eIOySv/Wf2rjFvRRS/kdYKXbzj5eUzdRVrka21AfpBqB/ZHFCHCy47PyUYurln30 hd/EInnSdA1pmg== -----END CERTIFICATE----- subject=C = NL, ST = S'Gravenhage, L = S'Gravenhage, O = Optim Enterprises BV, OU = Wireless, CN = portaladmin.optimcloud.com, emailAddress = admin at optimcloud.com issuer=C = NL, ST = S'Gravenhage, L = SGravenhage, O = Optim Enterprises BV, OU = Wireless, CN = ca.optimcloud.com, emailAddress = admin at optimcloud.com --- No client certificate CA names sent Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224:ECDSA+SHA1:RSA+SHA1 Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512 Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 2835 bytes and written 395 bytes Verification error: self signed certificate in certificate chain --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 19 (self signed certificate in certificate chain) --- --- Post-Handshake New Session Ticket arrived: SSL-Session: ??? Protocol? : TLSv1.3 ??? Cipher??? : TLS_AES_256_GCM_SHA384 ??? Session-ID: DD66A51F2DFECA0871494BC94CA8208FE65C188491878CA035FE88D8961F18F6 ??? Session-ID-ctx: ??? Resumption PSK: 87400DD8AA4AB035B526CA3C938E76E3E38694A2B3D710FB13215EF20B993F01787C96480C433DB24C435CB4EB4D902B ??? PSK identity: None ??? PSK identity hint: None ??? SRP username: None ??? TLS session ticket lifetime hint: 7200 (seconds) ??? TLS session ticket: ??? 0000 - 6b be a1 84 a0 c7 b0 04-6c ef 5b a6 ec a3 63 08 k.......l.[...c. ??? 0010 - da e0 d4 6d 0a 5e 55 6e-c7 aa 97 87 60 57 58 18 ...m.^Un....`WX. ??? 0020 - 57 5b 35 1a 7f 85 93 e6-c7 85 ac d7 1c ca ba 7b W[5............{ ??? 0030 - 9d 91 ca b8 e6 af 46 86-04 c2 ef 47 f1 03 46 30 ......F....G..F0 ??? 0040 - be b1 6f b2 43 59 51 07-cb ca da 41 99 85 38 a0 ..o.CYQ....A..8. ??? 0050 - 16 e2 ed ed 5e ad 03 2f-60 2e 34 df d3 7b c0 09 ....^../`.4..{.. ??? 0060 - cb f6 ef ec 82 82 da 3d-b5 ed d4 7d 7a a1 16 e6 .......=...}z... ??? 0070 - d9 71 03 74 72 bb a2 2a-29 fd e8 23 10 f8 32 fa .q.tr..*)..#..2. ??? 0080 - 9d e9 d8 01 c4 0b d7 12-43 7d 2a 8b 7e fa b6 51 ........C}*.~..Q ??? 0090 - f4 35 64 42 41 08 39 ef-3e a0 1e 48 db 92 11 c7 .5dBA.9.>..H.... ??? 00a0 - 0d 99 d9 0c 66 fa dd ba-ec f3 b2 d3 de 77 cf 9e ....f........w.. ??? 00b0 - 44 77 14 be 76 9a 9b cb-23 20 1d a4 d7 f9 92 ee Dw..v...# ...... ??? Start Time: 1616511716 ??? Timeout?? : 7200 (sec) ??? Verify return code: 19 (self signed certificate in certificate chain) ??? Extended master secret: no ??? Max Early Data: 0 --- read R BLOCK --- Post-Handshake New Session Ticket arrived: SSL-Session: ??? Protocol? : TLSv1.3 ??? Cipher??? : TLS_AES_256_GCM_SHA384 ??? Session-ID: 1330829E9B218CE0A1DA23896CBE83F117A9A79DFECE0D1F0D37B4DD7010DE9A ??? Session-ID-ctx: ??? Resumption PSK: DDE3C443AE436A6AD1C3DE7D9F18D4D28BAF0920E199CCF3B44715897E7A1FA375C087FF2BF23F7C85750297F513234A ??? PSK identity: None ??? PSK identity hint: None ??? SRP username: None ??? TLS session ticket lifetime hint: 7200 (seconds) ??? TLS session ticket: ??? 0000 - 6b be a1 84 a0 c7 b0 04-6c ef 5b a6 ec a3 63 08 k.......l.[...c. ??? 0010 - 97 08 a5 e3 40 05 dc 94-21 61 3a 8c cb 55 81 62 .... at ...!a:..U.b ??? 0020 - 0d 3a 3f 95 4a 23 8e ee-6a f2 a4 b1 61 27 d8 2a .:?.J#..j...a'.* ??? 0030 - 64 19 16 b6 ae 61 9c 92-0b c3 f0 0a d2 31 8d bb d....a.......1.. ??? 0040 - 2a c6 8c 8b fc a2 ff ab-f4 85 9f 22 ac b6 9b 89 *..........".... ??? 0050 - b9 76 e5 c5 b1 3c 76 3e-8e 36 c7 22 f9 91 a6 fa .v....6.".... ??? 0060 - ea 47 38 62 87 cd ff 92-db c4 77 97 10 03 63 7f .G8b......w...c. ??? 0070 - e1 f3 e3 c0 99 4d fe 0b-0c 1c 74 3f 84 ce 77 b8 .....M....t?..w. ??? 0080 - 73 04 ae 84 a0 88 6a f1-27 2f 08 e3 2c 32 fb 12 s.....j.'/..,2.. ??? 0090 - 33 c0 4d 54 e1 d1 ee 6e-23 a6 56 79 60 3b 71 6a 3.MT...n#.Vy`;qj ??? 00a0 - 49 b4 d1 7d 99 6b 77 1f-96 30 20 26 e4 ba f1 5f I..}.kw..0 &..._ ??? 00b0 - 2c 20 00 15 5a 9e 61 d1-5e f9 14 75 69 7d e2 b1?? , ..Z.a.^..ui}.. ??? Start Time: 1616511717 ??? Timeout?? : 7200 (sec) ??? Verify return code: 19 (self signed certificate in certificate chain) ??? Extended master secret: no ??? Max Early Data: 0 --- read R BLOCK ACP/1.0 Method: IGNORE closed > https://www.openssl.org/docs/man1.1.1/man3/ > > Matt From matt at openssl.org Tue Mar 23 15:32:24 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 23 Mar 2021 15:32:24 +0000 Subject: ssl client write / server accept seems broken In-Reply-To: References: <16b17ec9-784d-96d1-50df-32aea3d174bb@openssl.org> Message-ID: On 23/03/2021 15:02, Embedded Devel wrote: > > > IM inclined top think the code for the certs is ok, but? can really say, > and im not an openssl programmer by any means... just need someone to > put eyes on the code and fix it really. The cert looks ok - at least nothing obviously wrong. 2048 bit RSA key. > > >>> >>> when i run the client - i get an error on the client side >>> >>> Tue Mar 23 02:13:58 2021 user.err : ac_ssl_client_write(): Error >>> SSL_ERROR_SSL - return code: -1. >>> Tue Mar 23 02:13:58 2021 user.info : ac_send_init(): Error >> >> >> It would be useful to see any errors on the OpenSSL error stack which >> might provide more details about specifically what has failed. For >> example you can call the `ERR_print_errors_fp` function to dump the >> error stack to a `FILE *`. Or alternatively use the `ERR_*` functions >> to examine the stack and print it to your log: > > Yupp above my head.... :( Ah. That's a shame - we could really use understanding the real error behind this. "SSL_ERROR_SSL" just means "libssl encountered an error". You have to modify your code to print more detailed error information There doesn't look to be anything obviously wrong from the snippets of code that you have shared. I suspect some kind of config issue - but without more detailed error information its difficult to say for sure. Would you be able to get a packet capture of a failing connection? That might give us some kind of clue. Do you know if your application is statically linked or dynamically linked to OpenSSL? > > and lastly if it helps > Unfortunately, not really. This appears to show a working TLSv1.3 connection. Matt From lists at optimcloud.com Tue Mar 23 15:47:21 2021 From: lists at optimcloud.com (Embedded Devel) Date: Tue, 23 Mar 2021 22:47:21 +0700 Subject: ssl client write / server accept seems broken In-Reply-To: References: <16b17ec9-784d-96d1-50df-32aea3d174bb@openssl.org> Message-ID: IM inclined top think the code for the certs is ok, but? can really say, and im not an openssl programmer by any means... just need someone to put eyes on the code and fix it really. The cert looks ok - at least nothing obviously wrong. 2048 bit RSA key. yes freshly generated >> when i run the client - i get an error on the client side Tue Mar 23 >> 02:13:58 2021 user.err : ac_ssl_client_write(): Error SSL_ERROR_SSL - >> return code: -1. Tue Mar 23 02:13:58 2021 user.info : ac_send_init(): >> Error >> It would be useful to see any errors on the OpenSSL error stack which >> might provide more details about specifically what has failed. For >> example you can call the `ERR_print_errors_fp` function to dump the >> error stack to a `FILE *`. Or alternatively use the `ERR_*` functions >> to examine the stack and print it to your log: >> >> Yupp above my head.... :( > > Ah. That's a shame - we could really use understanding the real error > behind this. "SSL_ERROR_SSL" just means "libssl encountered an error". > You have to modify your code to print more detailed error information > > There doesn't look to be anything obviously wrong from the snippets of > code that you have shared. I suspect some kind of config issue - but > without more detailed error information its difficult to say for sure. > > Would you be able to get a packet capture of a failing connection? > That might give us some kind of clue. > > Do you know if your application is statically linked or dynamically > linked to OpenSSL? Ive attached the code in question if it helps just compiled with gcc, i see no -lstatic in the makefile ... ive attached the ssl .c and .h files in question if you want to see them as for a packet capture i can try, they are both remote systems > >> >> and lastly if it helps >> > > Unfortunately, not really. This appears to show a working TLSv1.3 > connection. > > Matt > -------------- next part -------------- A non-text attachment was scrubbed... Name: ac_ssl.c Type: text/x-csrc Size: 1697 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ac_ssl.h Type: text/x-chdr Size: 1294 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ac_ssl_client.c Type: text/x-csrc Size: 4877 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ac_ssl_server.c Type: text/x-csrc Size: 4118 bytes Desc: not available URL: From matt at openssl.org Tue Mar 23 16:06:22 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 23 Mar 2021 16:06:22 +0000 Subject: ssl client write / server accept seems broken In-Reply-To: References: <16b17ec9-784d-96d1-50df-32aea3d174bb@openssl.org> Message-ID: <7877a21a-d656-b63d-4976-4a8a7594b118@openssl.org> On 23/03/2021 15:47, Embedded Devel wrote: >> Do you know if your application is statically linked or dynamically >> linked to OpenSSL? > Ive attached the code in question if it helps > Looks like the original developer already tried to print the contents of the OpenSSL error stack: case SSL_ERROR_SSL: LOG(LOG_ERR, "%s: Error SSL_ERROR_SSL - return code: %d. %s\n", custom_prefix, ret_val, custom_msg); break; } ERR_print_errors_fp(stderr);fflush(stderr); The errors seem to be going to "stderr" rather than via your "LOG" function. You don't show what "LOG" does but if it goes somewhere other than stderr then the errors are going somewhere different to your log file. Are you able to show us the stderr output from running your application? > just compiled with gcc, i see no -lstatic in the makefile ... ive > attached the ssl .c and .h files in question if you want to see them What does "ldd" show you for the application binary? i.e. ldd name-of-you-binary-here Matt From lists at optimcloud.com Tue Mar 23 16:15:28 2021 From: lists at optimcloud.com (Embedded Devel) Date: Tue, 23 Mar 2021 23:15:28 +0700 Subject: ssl client write / server accept seems broken In-Reply-To: <7877a21a-d656-b63d-4976-4a8a7594b118@openssl.org> References: <16b17ec9-784d-96d1-50df-32aea3d174bb@openssl.org> <7877a21a-d656-b63d-4976-4a8a7594b118@openssl.org> Message-ID: On 3/23/21 11:06 PM, Matt Caswell wrote: > > > On 23/03/2021 15:47, Embedded Devel wrote: >>> Do you know if your application is statically linked or dynamically >>> linked to OpenSSL? >> Ive attached the code in question if it helps >> > > > Looks like the original developer already tried to print the contents > of the OpenSSL error stack: > > ??????? case SSL_ERROR_SSL: > ??????????? LOG(LOG_ERR, "%s: Error SSL_ERROR_SSL - return code: %d. > %s\n", custom_prefix, ret_val, custom_msg); > ??????????? break; > ????} > > ????ERR_print_errors_fp(stderr);fflush(stderr); > > The errors seem to be going to "stderr" rather than via your "LOG" > function. You don't show what "LOG" does but if it goes somewhere > other than stderr then the errors are going somewhere different to > your log file. Are you able to show us the stderr output from running > your application? logread Tue Mar 23 16:09:43 2021 user.err : ac_ssl_client_write(): Error SSL_ERROR_SSL - return code: -1. Tue Mar 23 16:09:44 2021 user.info : ac_send_init(): Error Tue Mar 23 16:09:46 2021 user.err : ac_ssl_client_write(): Error SSL_ERROR_SSL - return code: -1. Tue Mar 23 16:09:46 2021 user.info : ac_send_init(): Error Tue Mar 23 16:09:49 2021 user.err : ac_ssl_client_write(): Error SSL_ERROR_SSL - return code: -1. Tue Mar 23 16:09:49 2021 user.info : ac_send_init(): Error Tue Mar 23 16:09:54 2021 user.err : ac_ssl_client_write(): Error SSL_ERROR_SSL - return code: -1. Tue Mar 23 16:09:54 2021 user.info : ac_send_init(): Error Tue Mar 23 16:09:59 2021 user.err : ac_ssl_client_write(): Error SSL_ERROR_SSL - return code: -1. Tue Mar 23 16:09:59 2021 user.info : ac_send_init(): Error Tue Mar 23 16:10:05 2021 user.err : ac_ssl_client_write(): Error SSL_ERROR_SSL - return code: -1. Tue Mar 23 16:10:05 2021 user.info : ac_send_init(): Error client side console 2011704912:error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call:ssl/ssl_lib.c:3690: 2011704912:error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call:ssl/ssl_lib.c:3690: 2011704912:error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call:ssl/ssl_lib.c:3690: 2011704912:error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call:ssl/ssl_lib.c:3690: 2011704912:error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call:ssl/ssl_lib.c:3690: 2011704912:error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call:ssl/ssl_lib.c:3690: 2011704912:error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call:ssl/ssl_lib.c:3690: 2011704912:error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call:ssl/ssl_lib.c:3690: 2011704912:error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call:ssl/ssl_lib.c:3690: 2011704912:error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call:ssl/ssl_lib.c:3690: 2011704912:error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call:ssl/ssl_lib.c:3690: 2011704912:error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call:ssl/ssl_lib.c:3690: nothing on console / server side /var/log/message Mar 23 17:09:54 optim04 ac_server[617182]: ac_ssl_server_accept(): Error SSL_ERROR_SYSCALL - return code: -1. SSL_accept() Mar 23 17:09:54 optim04 ac_server[617182]: ac_ssl_server_accept(): Error code: -3 Mar 23 17:09:59 optim04 ac_server[617182]: ac_ssl_server_accept(): Error SSL_ERROR_SYSCALL - return code: -1. SSL_accept() Mar 23 17:09:59 optim04 ac_server[617182]: ac_ssl_server_accept(): Error code: -3 Mar 23 17:10:05 optim04 ac_server[617182]: ac_ssl_server_accept(): Error SSL_ERROR_SYSCALL - return code: -1. SSL_accept() Mar 23 17:10:05 optim04 ac_server[617182]: ac_ssl_server_accept(): Error code: -3 [root at optim04 ~]# >> just compiled with gcc, i see no -lstatic in the makefile ... ive >> attached the ssl .c and .h files in question if you want to see them > > What does "ldd" show you for the application binary? i.e. > > ldd name-of-you-binary-here client root at OpenWrt:~# ldd /usr/sbin/ac_client ??? /lib/ld-musl-mips-sf.so.1 (0x77e20000) ??? libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x77da0000) ??? libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x77bc6000) ??? libaxl.so.0 => /usr/lib/libaxl.so.0 (0x77b6e000) ??? libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x77b4a000) ??? libc.so => /lib/ld-musl-mips-sf.so.1 (0x77e20000) server ldd /usr/bin/ac_server ??? linux-vdso.so.1 (0x00007fff2bd99000) ??? libmariadb.so.3 => /lib64/libmariadb.so.3 (0x00007f9e81fbb000) ??? libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9e81d9b000) ??? libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f9e81b07000) ??? libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f9e81621000) ??? libaxl.so.0 => /lib64/libaxl.so.0 (0x00007f9e813ef000) ??? libc.so.6 => /lib64/libc.so.6 (0x00007f9e8102c000) ??? libz.so.1 => /lib64/libz.so.1 (0x00007f9e80e15000) ??? libdl.so.2 => /lib64/libdl.so.2 (0x00007f9e80c11000) ??? libm.so.6 => /lib64/libm.so.6 (0x00007f9e8088f000) ??? /lib64/ld-linux-x86-64.so.2 (0x00007f9e82210000) > > > Matt From pawan0462 at gmail.com Wed Mar 24 04:03:23 2021 From: pawan0462 at gmail.com (Vuthur Pavankumar) Date: Wed, 24 Mar 2021 09:33:23 +0530 Subject: How to store openSSL EVP_MD and EVP_MD_CTX in local buffers Message-ID: Hi All, I was implementing SHA3 multi-call as below using openSSL version openssl-1.1.1j init: const EVP_MD *evpmd = EVP_sha3_256(); EVP_MD_CTX *ctx = EVP_MD_CTX_new() EVP_DigestInit_ex(ctx, evpmd, NULL); store ctx and evpmd in local buffer. and reuse it for update and final EVP_MD_CTX_free(ctx) update: get ctx and evpmd from local buffer and update ctx with evpmd and pass it to EVP_DigestUpdate method EVP_DigestUpdate(ctx, msg, msg_len); -> get ctx from local buffer Final: get ctx and evpmd from local buffer and update ctx with evpmd and pass it to EVP_DigestUpdate method if(shake) EVP_DigestFinalXOF(ctx, md , mdlen); -> get ctx from local buffer else EVP_DigestFinal_ex(ctx, md, &mdlen) Note: some buggy applications may not call the final call and the memory allocated using OpenSSL in Digest init may not be freed. to avoid it I want to store EVP_MD_CTX and EVP_MD data in a local buffer and reuse it instead of storing *ctx and freeing in the final call. the problem I am facing: 1.declaring below struct and compiling resulted in an error. error: field 'evpmd_ctx' has incomplete type error: field 'evpmd' has incomplete type typedef struct { uint16_t abc; uint16_t xyz; uint16_t reserved1; uint16_t reserved2; EVP_MD_CTX evpmd_ctx; EVP_MD evpmd; } SHA3Data; 2.same error for sizeof(EVP_MD_CTX ) and sizeof(EVP_MD ) looks like EVP_MD_CTX and EVP_MD data are opaque to applications. *Do we have any other means to store EVP_MD_CTX and EVP_MD data in local buffers and reuse them in update and Final calls?* Thanks, Pavan -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauli at openssl.org Wed Mar 24 05:09:45 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Wed, 24 Mar 2021 15:09:45 +1000 Subject: How to store openSSL EVP_MD and EVP_MD_CTX in local buffers In-Reply-To: References: Message-ID: Structures are opaque after OpenSSL 1.0.? There is no way to do what you want. The recommended path is to call EVP_MD_CTX_dup() to create a copy of the context and use that the second time around. Pauli On 24/3/21 2:03 pm, Vuthur Pavankumar wrote: > Hi All, > > I was implementing SHA3 multi-call as below using openSSL version > openssl-1.1.1j > > init: > const EVP_MD *evpmd = EVP_sha3_256(); > EVP_MD_CTX *ctx = EVP_MD_CTX_new() > EVP_DigestInit_ex(ctx, evpmd, NULL); > store ctx and evpmd in local buffer. and reuse it for update and final > EVP_MD_CTX_free(ctx) > > update: > get ctx and evpmd from local buffer and update ctx with evpmd and pass > it to ?EVP_DigestUpdate method > > EVP_DigestUpdate(ctx, msg, msg_len); -> get ctx from ?local buffer > > Final: > get ctx and evpmd from local buffer and update ctx with evpmd and pass > it to ?EVP_DigestUpdate method > if(shake) > EVP_DigestFinalXOF(ctx, md , mdlen); -> get ctx from ?local buffer > else > EVP_DigestFinal_ex(ctx, md, &mdlen) > > Note: > some buggy applications may not call the final call and the memory > allocated using OpenSSL in Digest init may not be freed. > to avoid it I want to store EVP_MD_CTX and EVP_MD data in a local > buffer and reuse it instead of storing *ctx and freeing in the final call. > > the problem I am facing: > 1.declaring below struct and compiling resulted in an error. > error: field 'evpmd_ctx' has incomplete type > error: field 'evpmd' has incomplete type > > typedef struct { > uint16_t abc; > uint16_t xyz; > uint16_t reserved1; > uint16_t reserved2; > EVP_MD_CTX evpmd_ctx; > EVP_MD evpmd; > } SHA3Data; > > 2.same error for sizeof(EVP_MD_CTX ) and sizeof(EVP_MD ) > > looks like EVP_MD_CTX and EVP_MD data are opaque to applications. > > *Do we have any other means to store ?EVP_MD_CTX and EVP_MD data in > local buffers and reuse?them in update and Final calls?* > > Thanks, > Pavan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From b_duvvuri at yahoo.com Wed Mar 24 06:14:20 2021 From: b_duvvuri at yahoo.com (Bala Duvvuri) Date: Wed, 24 Mar 2021 06:14:20 +0000 (UTC) Subject: OpenSSL 3.0 - providing entropy to EVP_RAND ? References: <1644797849.3514421.1616566460759.ref@mail.yahoo.com> Message-ID: <1644797849.3514421.1616566460759@mail.yahoo.com> Hi All, In OpenSSL 1.1.1 version, we were using RAND_DRBG for random number generation. Using "RAND_DRBG_set_callbacks", we were able to call into our custom API for entropy and nonce generation. How can this be achieved with EVP_RAND implementation i.e. does it allow entropy to be provided? Thanks Bala From pauli at openssl.org Wed Mar 24 06:25:00 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Wed, 24 Mar 2021 16:25:00 +1000 Subject: OpenSSL 3.0 - providing entropy to EVP_RAND ? In-Reply-To: <1644797849.3514421.1616566460759@mail.yahoo.com> References: <1644797849.3514421.1616566460759.ref@mail.yahoo.com> <1644797849.3514421.1616566460759@mail.yahoo.com> Message-ID: <1da19067-8dbb-f832-f3bc-79dbd7b84eb8@openssl.org> RAND_add() forces a reseed to the DRBGs and uses the passed material (not as entropy but as additional input). EVP_RAND_reseed() is a more direct interface but remember that the built in DRBGs are free to ignore what the user claims is /entropy/. History has shown us time and again that /entropy/ is often anything but. The *best* way to do this, is to create a provider which acts as a seed source and to then use this as the parent of the primary DRBG.? See, for example, test/testutil/fakerandom.c for how to do this.? The key is to set up the seed source before the RNG subsystem is first used. If you simply want to replace the built-in DRBGs with a real random source, create a provider and set the appropriate environment/config variables. Pauli On 24/3/21 4:14 pm, Bala Duvvuri via openssl-users wrote: > Hi All, > > In OpenSSL 1.1.1 version, we were using RAND_DRBG for random number generation. > > Using "RAND_DRBG_set_callbacks", we were able to call into our custom API for entropy and nonce generation. > > How can this be achieved with EVP_RAND implementation i.e. does it allow entropy to be provided? > > Thanks > Bala > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at optimcloud.com Wed Mar 24 14:53:33 2021 From: lists at optimcloud.com (Embedded Devel) Date: Wed, 24 Mar 2021 21:53:33 +0700 Subject: ssl client write / server accept seems broken In-Reply-To: <7877a21a-d656-b63d-4976-4a8a7594b118@openssl.org> References: <16b17ec9-784d-96d1-50df-32aea3d174bb@openssl.org> <7877a21a-d656-b63d-4976-4a8a7594b118@openssl.org> Message-ID: On 3/23/21 11:06 PM, Matt Caswell wrote: > > > On 23/03/2021 15:47, Embedded Devel wrote: >>> Do you know if your application is statically linked or dynamically >>> linked to OpenSSL? >> Ive attached the code in question if it helps original code was deprecated, and changed from /*????? if ((ssl_con->ctx = SSL_CTX_new(TLSv1_server_method())) == NULL) { */ ??????? if ((ssl_con->ctx = SSL_CTX_new(TLS_server_method())) == NULL) { which also got added to the client side yet should have been client should be if ((ssl_con->ctx = SSL_CTX_new(TLS_client_method())) == NULL) { not if ((ssl_con->ctx = SSL_CTX_new(TLS_server_method())) == NULL) { > > Looks like the original developer already tried to print the contents > of the OpenSSL error stack: > > ??????? case SSL_ERROR_SSL: > ??????????? LOG(LOG_ERR, "%s: Error SSL_ERROR_SSL - return code: %d. > %s\n", custom_prefix, ret_val, custom_msg); > ??????????? break; > ????} > > ????ERR_print_errors_fp(stderr);fflush(stderr); > > The errors seem to be going to "stderr" rather than via your "LOG" > function. You don't show what "LOG" does but if it goes somewhere > other than stderr then the errors are going somewhere different to > your log file. Are you able to show us the stderr output from running > your application? > > >> just compiled with gcc, i see no -lstatic in the makefile ... ive >> attached the ssl .c and .h files in question if you want to see them > > What does "ldd" show you for the application binary? i.e. > > ldd name-of-you-binary-here > > > Matt From ask.pleaze at gmail.com Wed Mar 24 15:00:00 2021 From: ask.pleaze at gmail.com (JONATHAN PELAEZ) Date: Wed, 24 Mar 2021 23:00:00 +0800 Subject: ssl client write / server accept seems broken In-Reply-To: References: <16b17ec9-784d-96d1-50df-32aea3d174bb@openssl.org> <7877a21a-d656-b63d-4976-4a8a7594b118@openssl.org> Message-ID: On Wed, Mar 24, 2021, 10:54 PM Embedded Devel wrote: > > On 3/23/21 11:06 PM, Matt Caswell wrote: > > > > > > On 23/03/2021 15:47, Embedded Devel wrote: > >>> Do you know if your application is statically linked or dynamically > >>> linked to OpenSSL? > >> Ive attached the code in question if it helps > > original code was deprecated, and changed from > > /* if ((ssl_con->ctx = SSL_CTX_new(TLSv1_server_method())) == NULL) > { */ > if ((ssl_con->ctx = SSL_CTX_new(TLS_server_method())) == NULL) { > > which also got added to the client side yet should have been > > client should be > > if ((ssl_con->ctx = SSL_CTX_new(TLS_client_method())) == NULL) { > > not > > if ((ssl_con->ctx = SSL_CTX_new(TLS_server_method())) == NULL) { > > > > > > Looks like the original developer already tried to print the contents > > of the OpenSSL error stack: > > > > case SSL_ERROR_SSL: > > LOG(LOG_ERR, "%s: Error SSL_ERROR_SSL - return code: %d. > > %s\n", custom_prefix, ret_val, custom_msg); > > break; > > } > > > > ERR_print_errors_fp(stderr);fflush(stderr); > > > > The errors seem to be going to "stderr" rather than via your "LOG" > > function. You don't show what "LOG" does but if it goes somewhere > > other than stderr then the errors are going somewhere different to > > your log file. Are you able to show us the stderr output from running > > your application? > > > > > >> just compiled with gcc, i see no -lstatic in the makefile ... ive > >> attached the ssl .c and .h files in question if you want to see them > > > > What does "ldd" show you for the application binary? i.e. > > > > ldd name-of-you-binary-here > > > > > > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at optimcloud.com Wed Mar 24 16:58:50 2021 From: lists at optimcloud.com (Embedded Devel) Date: Wed, 24 Mar 2021 23:58:50 +0700 Subject: ssl client write / server accept seems broken In-Reply-To: References: <16b17ec9-784d-96d1-50df-32aea3d174bb@openssl.org> <7877a21a-d656-b63d-4976-4a8a7594b118@openssl.org> Message-ID: <80f1761b-3043-4563-4d42-d605b18cab2b@optimcloud.com> On 3/24/21 9:53 PM, Embedded Devel wrote: > > On 3/23/21 11:06 PM, Matt Caswell wrote: >> >> >> On 23/03/2021 15:47, Embedded Devel wrote: >>>> Do you know if your application is statically linked or dynamically >>>> linked to OpenSSL? >>> Ive attached the code in question if it helps and nope still have the errors > > original code was deprecated, and changed from > > /*????? if ((ssl_con->ctx = SSL_CTX_new(TLSv1_server_method())) == > NULL) { */ > ??????? if ((ssl_con->ctx = SSL_CTX_new(TLS_server_method())) == NULL) { > > which also got added to the client side yet should have been > > client should be > > if ((ssl_con->ctx = SSL_CTX_new(TLS_client_method())) == NULL) { > > not > > if ((ssl_con->ctx = SSL_CTX_new(TLS_server_method())) == NULL) { > > >> >> Looks like the original developer already tried to print the contents >> of the OpenSSL error stack: >> >> ??????? case SSL_ERROR_SSL: >> ??????????? LOG(LOG_ERR, "%s: Error SSL_ERROR_SSL - return code: %d. >> %s\n", custom_prefix, ret_val, custom_msg); >> ??????????? break; >> ????} >> >> ????ERR_print_errors_fp(stderr);fflush(stderr); >> >> The errors seem to be going to "stderr" rather than via your "LOG" >> function. You don't show what "LOG" does but if it goes somewhere >> other than stderr then the errors are going somewhere different to >> your log file. Are you able to show us the stderr output from running >> your application? >> >> >>> just compiled with gcc, i see no -lstatic in the makefile ... ive >>> attached the ssl .c and .h files in question if you want to see them >> >> What does "ldd" show you for the application binary? i.e. >> >> ldd name-of-you-binary-here >> >> >> Matt From lists at optimcloud.com Thu Mar 25 02:02:04 2021 From: lists at optimcloud.com (Embedded Devel) Date: Thu, 25 Mar 2021 09:02:04 +0700 Subject: openssl development work / paid Message-ID: <88307274-9f51-65a4-724c-12e766143d14@optimcloud.com> I tried to get through this on my own, not being a openssl developer, made progress but still no joy so we had an app that was written some 8-10 years ago, which worked fine for client/server tls update to today, no longer functional, deprecations in openssl cause errors it is not a large app, and i believe if someone were to resolve the openssl issues it would work again whos up for making some money ? Thanks From thomas_floodeenjr at mentor.com Thu Mar 25 12:58:15 2021 From: thomas_floodeenjr at mentor.com (Floodeenjr, Thomas) Date: Thu, 25 Mar 2021 12:58:15 +0000 Subject: openssl development work / paid In-Reply-To: <88307274-9f51-65a4-724c-12e766143d14@optimcloud.com> References: <88307274-9f51-65a4-724c-12e766143d14@optimcloud.com> Message-ID: If your problem is the migration from 1.0.2 to 1.1.1, I have attached my porting notes, if that helps. -Tom -----Original Message----- From: openssl-users On Behalf Of Embedded Devel Sent: Wednesday, March 24, 2021 8:02 PM To: openssl-users at openssl.org Subject: openssl development work / paid I tried to get through this on my own, not being a openssl developer, made progress but still no joy so we had an app that was written some 8-10 years ago, which worked fine for client/server tls update to today, no longer functional, deprecations in openssl cause errors it is not a large app, and i believe if someone were to resolve the openssl issues it would work again whos up for making some money ? Thanks -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: OpeSSL 1.1.1 Porting Changes.txt URL: From openssl at openssl.org Thu Mar 25 13:57:18 2021 From: openssl at openssl.org (OpenSSL) Date: Thu, 25 Mar 2021 13:57:18 +0000 Subject: OpenSSL version 1.1.1k published Message-ID: <20210325135718.GA5803@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.1k released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1k of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1k is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1k.tar.gz Size: 9823400 SHA1 checksum: bad9dc4ae6dcc1855085463099b5dacb0ec6130b SHA256 checksum: 892a0875b9872acd04a9fde79b1f943075d5ea162415de3047c327df33fbaee5 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1k.tar.gz openssl sha256 openssl-1.1.1k.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmBckA0ACgkQ2cTSbQ5g RJE5lwgArWHJ+bjtnno8MtRH22cC4YjvDvTtwKsm2ESDKPnNMtMVDM/GUF3g9R5L 4H5WTWNCGFiQ/GqCIsty0tcV3NFMqKLBtl/5rm4+SQ+EG6oyKvjDBOOhwOoVS6Wy Kam+sM+6u444JY0GjKxjXKwFLGZKhtetXH1kMbi5rZw/5ln+DOh+NfyAN6YxPfOD KSV5K3sEA98ppeyE4ac+06lllXOZ8LfTGSxRojiQ08e6MkXDkWC2Vq5C963mm4Tk 1rmJTN3w3DoFh0IuZdTiCQzqUmam+jb3g8S95yKR7pjfydfbCtmkgIVAXFJ2UJR2 rUu1Sv19POSyy39WUnNb9s2PtoviTw== =f54Z -----END PGP SIGNATURE----- From openssl at openssl.org Thu Mar 25 14:03:24 2021 From: openssl at openssl.org (OpenSSL) Date: Thu, 25 Mar 2021 14:03:24 +0000 Subject: OpenSSL Security Advisory Message-ID: <20210325140324.GA8266@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL Security Advisory [25 March 2021] ========================================= CA certificate check bypass with X509_V_FLAG_X509_STRICT (CVE-2021-3450) ======================================================================== Severity: High The X509_V_FLAG_X509_STRICT flag enables additional security checks of the certificates present in a certificate chain. It is not set by default. Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check. An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates. If a "purpose" has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named "purpose" values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verification routines, but it can be overridden or removed by an application. In order to be affected, an application must explicitly set the X509_V_FLAG_X509_STRICT verification flag and either not set a purpose for the certificate verification or, in the case of TLS client or server applications, override the default purpose. OpenSSL versions 1.1.1h and newer are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. This issue was reported to OpenSSL on 18th March 2021 by Benjamin Kaduk from Akamai and was discovered by Xiang Ding and others at Akamai. The fix was developed by Tom?? Mr?z. NULL pointer deref in signature_algorithms processing (CVE-2021-3449) ===================================================================== Severity: High An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue. All OpenSSL 1.1.1 versions are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. This issue was reported to OpenSSL on 17th March 2021 by Nokia. The fix was developed by Peter K?stle and Samuel Sapalski from Nokia. Note ==== OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. The impact of these issues on OpenSSL 1.1.0 has not been analysed. Users of these versions should upgrade to OpenSSL 1.1.1. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20210325.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmBcl6sACgkQ2cTSbQ5g RJGvnAgAtG6I7rfokDC9E5yB26KC3k0Vasfq5iH/aZz0CNRyOokWJBUyyNIVjqr0 2eZP7VsQT7zRM+tgh9c8MwH3FIghtpwJRJls4qZDHKoXts7JH4Ul4NLPd546x7xA GcKNwTD4NkZbTqtZ72NTgliInzrj0MCC8jqQrIIkcAIleGNzvZ0f64jdE+vBXoqX M2FOhWiA/JkAKtB3W7pthIt25qkOwHbrpTy+UUp/S5QD779NJ/EOYcsOFBRfLZiP gA6QILuW2L55lhG6Y2u+nVE3UI2hqd2hGgSAvDIPr2lVJxq0LQpgHca7Gj5bfIRo GLDz7n0FhN6n7NBqetP+nlHmYivcSg== =XIXK -----END PGP SIGNATURE----- From hkario at redhat.com Thu Mar 25 17:05:02 2021 From: hkario at redhat.com (Hubert Kario) Date: Thu, 25 Mar 2021 18:05:02 +0100 Subject: OpenSSL Security Advisory In-Reply-To: <20210325140324.GA8266@openssl.org> References: <20210325140324.GA8266@openssl.org> Message-ID: <7403024e-20a3-43ed-81f1-0f30aeb6f580@redhat.com> On Thursday, 25 March 2021 15:03:24 CET, OpenSSL wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > OpenSSL Security Advisory [25 March 2021] > ========================================= > > NULL pointer deref in signature_algorithms processing (CVE-2021-3449) > ===================================================================== > > Severity: High > > An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation > ClientHello message from a client. If a TLSv1.2 renegotiation > ClientHello omits > the signature_algorithms extension (where it was present in the initial > ClientHello), but includes a signature_algorithms_cert extension then a NULL > pointer dereference will result, leading to a crash and a denial of service > attack. > > A server is only vulnerable if it has TLSv1.2 and renegotiation > enabled (which > is the default configuration). OpenSSL TLS clients are not impacted by this > issue. > > All OpenSSL 1.1.1 versions are affected by this issue. Users of > these versions > should upgrade to OpenSSL 1.1.1k. > > OpenSSL 1.0.2 is not impacted by this issue. > > This issue was reported to OpenSSL on 17th March 2021 by Nokia. The fix was > developed by Peter K?stle and Samuel Sapalski from Nokia. I've created a stand-alone reproducer for it using tlsfuzzer: git clone https://github.com/tlsfuzzer/tlsfuzzer.git cd tlsfuzzer # won't be necessary after https://github.com/tlsfuzzer/tlsfuzzer/pull/748 is merged: git checkout sig-algs-tests # install dependencies: python3 -m venv py3-venv py3-venv/bin/pip install --pre tlslite-ng # run the reproducer: PYTHONPATH=. py3-venv/bin/python3 scripts/test-sig-algs-renegotiation-resumption.py -h -p In case the server has renegotiation disabled, use the --no-renego option. In case the server doesn't require presence of signature_algorithms extension when signature_algorithms_cert are present (like in case of OpenSSL 1.0.2), use the --sig-algs-drop-ok option. If everything went fine, and the server didn't crash, the test will print summary like this: ==================== TOTAL: 12 SKIP: 0 PASS: 12 XFAIL: 0 FAIL: 0 XPASS: 0 ==================== It's not necessary to install dependencies to a virtual environment, but that setup is described in the official docs: https://tlsfuzzer.readthedocs.io/en/latest/quickstart.html -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic From marc.balemboy at csgroup.eu Thu Mar 25 17:56:53 2021 From: marc.balemboy at csgroup.eu (mbalembo) Date: Thu, 25 Mar 2021 18:56:53 +0100 Subject: [openssl CMP with pkcs11 engine] Message-ID: <24f54f69-276f-2727-94b9-3d9304df8571@csgroup.eu> Hello all, I'm trying to do a CMP request using openssl with a private key inside a pkcs11 device (on linux). So i'm using opsenssl 3.0.0 alpha 13. I did compile fine (./config --prefix=/opt/openssl enable-deprecated --openssldir=/usr/local/ssl -Wl,-rpath=/opt/openssl/lib), but i ran into trouble when compiling libp11 to get my pkcs11 engine. (i had a similar issue while trying to use tpm2-tss-engine) I can't find a way to build openssl with ERR_put_error() symbol. I know it's deprecated so i changed the code in libp11 to use ERR_raise() instead, but again the symbol is also missing. I ended up removing the function call in the engine as a dirty fix, but i'd like to have a better solution. So, with everything compiled, I tried to use the engine only and create a CSR first. # /opt/openssl/bin/openssl req -new -engine pkcs11 -keyform engine -key "pkcs11:model=SLB9670;manufacturer=Infineon;serial=0000000000000000;token=tpm2-token;id=%c1%b2%36%b2%eb%53%f0%4f%ea%24%1a%4d%01%ac%d1%9e%fe%11%19%6d;object=test;type=private;pin-value=000000" -subj "" -out testpkcs11.csr and, everything works so far ! Hello all, I'm trying to do a CMP request using openssl with a private key inside a pkcs11 device (on linux). So i'm using opsenssl 3.0.0 alpha 13. I did compile fine (./config --prefix=/opt/openssl enable-deprecated --openssldir=/usr/local/ssl -Wl,-rpath=/opt/openssl/lib), but i ran into trouble when compiling libp11 to get my pkcs11 engine. (i had a similar issue while trying to use tpm2-tss-engine) I can't find a way to build openssl with ERR_put_error() symbol. I know it's deprecated so i changed the code in libp11 to use ERR_raise() instead, but again the symbol is also missing. I ended up removing the function call in the engine as a dirty fix, but i'd like to have a better solution. So, with everything compiled, I tried to use the engine only and create a CSR first. # /opt/openssl/bin/openssl req -new -engine pkcs11 -keyform engine -key "pkcs11:model=SLB9670;manufacturer=Infineon;serial=0000000000000000;token=tpm2-token;id=%c1%b2%36%b2%eb%53%f0%4f%ea%24%1a%4d%01%ac%d1%9e%fe%11%19%6d;object=test;type=private;pin-value=000000" -subj "" -out testpkcs11.csr and, everything works so far ! but i get errors when trying to do a CMP request with the engine, thing is, i'm not so sure of the command. # /opt/openssl/bin/openssl cmp -cmd ir -engine pkcs11 -server :8080 -path ejbca/publicweb/cmp/WKS-RA-Bootstrap_auth -cert -key file: -keypass file: -keyform engine -newkey "pkcs11:model=SLB9670;manufacturer=Infineon;serial=0000000000000000;token=tpm2-token;id=%c1%b2%36%b2%eb%53%f0%4f%ea%24%1a%4d%01%ac%d1%9e%fe%11%19%6d;object=test;type=private;pin-value=000000" -subject '' -certout testcmppkcs11.pem -trusted <> my root CA> -reqexts san -config /opt/conf/openssl_reqext.cnf i get the following error : cmp_main:apps/cmp.c:2728:CMP info: using section(s) 'cmp' of OpenSSL configuration file '/opt/conf/openssl_reqext.cnf' cmp_main:apps/cmp.c:2737:CMP info: no [cmp] section found in config file '/opt/conf/openssl_reqext.cnf'; will thus use just [default] and unnamed section if present Engine "pkcs11" set. Format not recognized! The key ID is not a valid PKCS#11 URI The PKCS#11 URI format is defined by RFC7512 The legacy ENGINE_pkcs11 ID format is also still accepted for now Format not recognized! The key ID is not a valid PKCS#11 URI The PKCS#11 URI format is defined by RFC7512 The legacy ENGINE_pkcs11 ID format is also still accepted for now PKCS11_get_private_key returned NULL Could not read private key for CMP client certificate from org.openssl.engine:pkcs11:file:/foo/usine.boot.key.pem 00E01783A47F0000:error:13000080:engine routines:ENGINE_load_private_key:failed loading private key:crypto/engine/eng_pkey.c:78: cmp_main:apps/cmp.c:2879:CMP error: cannot set up CMP context I'm quite confuse about the PKCS11 error since i know from the req command that openssl rsa show that the passphrase for the CMP client certificate is good. my URI is good and openssl rsa show that the passphrase for the CMP client certificate is good. I've tried various modification of the command, mostly removing the "keyform engine" and using just 'newkey "pkcs11:(...)" ' with no succes. Maybe openssl is mixing engine format for everything and not just for the newkey ? Thanks, Marc but i get errors when trying to do a CMP request with the engine, thing is, i'm not so sure of the command. # /opt/openssl/bin/openssl cmp -cmd ir -engine pkcs11 -server :8080 -path ejbca/publicweb/cmp/WKS-RA-Bootstrap_auth -cert -key file: -keypass file: -keyform engine -newkey "pkcs11:model=SLB9670;manufacturer=Infineon;serial=0000000000000000;token=tpm2-token;id=%c1%b2%36%b2%eb%53%f0%4f%ea%24%1a%4d%01%ac%d1%9e%fe%11%19%6d;object=test;type=private;pin-value=000000" -subject '' -certout testcmppkcs11.pem -trusted <> my root CA> -reqexts san -config /opt/conf/openssl_reqext.cnf i get the following error : cmp_main:apps/cmp.c:2728:CMP info: using section(s) 'cmp' of OpenSSL configuration file '/opt/conf/openssl_reqext.cnf' cmp_main:apps/cmp.c:2737:CMP info: no [cmp] section found in config file '/opt/conf/openssl_reqext.cnf'; will thus use just [default] and unnamed section if present Engine "pkcs11" set. Format not recognized! The key ID is not a valid PKCS#11 URI The PKCS#11 URI format is defined by RFC7512 The legacy ENGINE_pkcs11 ID format is also still accepted for now Format not recognized! The key ID is not a valid PKCS#11 URI The PKCS#11 URI format is defined by RFC7512 The legacy ENGINE_pkcs11 ID format is also still accepted for now PKCS11_get_private_key returned NULL Could not read private key for CMP client certificate from org.openssl.engine:pkcs11:file:/foo/usine.boot.key.pem 00E01783A47F0000:error:13000080:engine routines:ENGINE_load_private_key:failed loading private key:crypto/engine/eng_pkey.c:78: cmp_main:apps/cmp.c:2879:CMP error: cannot set up CMP context I'm quite confuse about the PKCS11 error since i know from the req command that openssl rsa show that the passphrase for the CMP client certificate is good. my URI is good and openssl rsa show that the passphrase for the CMP client certificate is good. I've tried various modification of the command, mostly removing the "keyform engine" and using just 'newkey "pkcs11:(...)" ' with no succes. Maybe openssl is mixing engine format for everything and not just for the newkey ? Thanks, Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrshaun13 at gmail.com Thu Mar 25 21:59:32 2021 From: mrshaun13 at gmail.com (Shaun Robbins) Date: Thu, 25 Mar 2021 14:59:32 -0700 Subject: Mismatch between renegotiation reported vs functional Message-ID: While trying to disable renegotiation the response from openssl reads "Secure Renegotiation IS supported" even though renegotiation is failing. OpenSSL Config: SSL_set_options(ssl_conn, SSL_OP_NO_RENEGOTIATION); ] $openssl s_client -connect localhost:443 -tls1_2 [SNIP] New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit *Secure Renegotiation IS supported*Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: [SNIP] --- HEAD / HTTP/1.1 R RENEGOTIATING 139845827855680:error:14094153:SSL routines:ssl3_read_bytes:no renegotiation:../ssl/record/rec_layer_s3.c:1560: This article refers to this same problem with some screen shots under section "Eliminating a false positive": https://www.mcafee.com/blogs/enterprise/tips-securing-ssl-renegotiation/ Thanks! -- Shaun Robbins -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at ddvo.net Fri Mar 26 07:46:14 2021 From: dev at ddvo.net (David von Oheimb) Date: Fri, 26 Mar 2021 08:46:14 +0100 Subject: Version compatibility issues - Re: openssl development work / paid In-Reply-To: References: <88307274-9f51-65a4-724c-12e766143d14@optimcloud.com> Message-ID: <83cb5811-d075-22b6-b6c8-f5f202e52ed8@ddvo.net> Embedded Devel, my sympathy - I know this can be painful and frustrating. >From which old OpenSSL version to which target version do you need to get the code updated? And as info to whoever may be considering picking up this task: which is your timeline for that? Within OpenSSL we are currently discussing how to handle version compatibility issues with the upcoming version 3.0 at https://github.com/openssl/openssl/issues/14628. Can you give some concrete typical examples which exact issues you are facing? ??? David On 25.03.21 13:58, Floodeenjr, Thomas wrote: > If your problem is the migration from 1.0.2 to 1.1.1, I have attached my porting notes, if that helps. > > -Tom > > -----Original Message----- > From: openssl-users On Behalf Of Embedded Devel > Sent: Wednesday, March 24, 2021 8:02 PM > To: openssl-users at openssl.org > Subject: openssl development work / paid > > I tried to get through this on my own, not being a openssl developer, made progress but still no joy > > so we had an app that was written some 8-10 years ago, which worked fine for client/server tls > > update to today, no longer functional, deprecations in openssl cause errors > > it is not a large app, and i believe if someone were to resolve the openssl issues it would work again > > whos up for making some money ? > > > Thanks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at optimcloud.com Fri Mar 26 08:51:43 2021 From: lists at optimcloud.com (Embedded Devel) Date: Fri, 26 Mar 2021 15:51:43 +0700 Subject: Version compatibility issues - Re: openssl development work / paid In-Reply-To: <83cb5811-d075-22b6-b6c8-f5f202e52ed8@ddvo.net> References: <88307274-9f51-65a4-724c-12e766143d14@optimcloud.com> <83cb5811-d075-22b6-b6c8-f5f202e52ed8@ddvo.net> Message-ID: On 3/26/21 2:46 PM, David von Oheimb wrote: > > Embedded Devel, > > my sympathy - I know this can be painful and frustrating. > > From which old OpenSSL version to which target version do you need to > get the code updated? > And as info to whoever may be considering picking up this task: which > is your timeline for that? > > Within OpenSSL we are currently discussing how to handle version > compatibility issues > with the upcoming version 3.0 at > https://github.com/openssl/openssl/issues/14628 > . > > Can you give some concrete typical examples which exact issues you are > facing? > > ??? David > i believe this was all from back in the 0.9x days, the code in question is close to 10+/- years old if everyone would look at the email thread? re: "ssl client write / server accept seems broken" some might see more of the issue i am facing, i have has 1 person look at this and he believes quote " This looks like using *very* outdated OpenSSL API. Hence the SSL client (and server) code needs to ported to work with more recent versions OpenSSL and make use of TLS methods instead of SSL methods. For testing you could try to build OpenSSL with the old SSL3 support enabled (we don't even support that at all in OpenWrt any longer, but should work to build manually). Because ssl_undefined_function is most likely a result of: Disabled features: ... ? ? ssl3? ? ? ? ? ? ? ? ? ? [default] OPENSSL_NO_SSL3 ? ? ssl3-method? ? ? ? ? ? ?[default] OPENSSL_NO_SSL3_METHOD ... If you find someone very familiar with OpenSSLs API (I've used it, more than once, but it's not what I'm doing every day), this can be done in a few days. I'd probably need a week for this and I'm not particularly keen on it, there are things I'm better with which are waiting as well." i now have a second developer looking at this, so hoping he can sort it all out. > On 25.03.21 13:58, Floodeenjr, Thomas wrote: >> If your problem is the migration from 1.0.2 to 1.1.1, I have attached my porting notes, if that helps. >> >> -Tom >> >> -----Original Message----- >> From: openssl-users On Behalf Of Embedded Devel >> Sent: Wednesday, March 24, 2021 8:02 PM >> To:openssl-users at openssl.org >> Subject: openssl development work / paid >> >> I tried to get through this on my own, not being a openssl developer, made progress but still no joy >> >> so we had an app that was written some 8-10 years ago, which worked fine for client/server tls >> >> update to today, no longer functional, deprecations in openssl cause errors >> >> it is not a large app, and i believe if someone were to resolve the openssl issues it would work again >> >> whos up for making some money ? >> >> >> Thanks >> From b_duvvuri at yahoo.com Fri Mar 26 10:47:55 2021 From: b_duvvuri at yahoo.com (Bala Duvvuri) Date: Fri, 26 Mar 2021 10:47:55 +0000 (UTC) Subject: libcrypto.a and FIPs module in OpenSSL 3.0 References: <1177921885.453798.1616755675814.ref@mail.yahoo.com> Message-ID: <1177921885.453798.1616755675814@mail.yahoo.com> Hi All, We build the "crypto" code in OpenSSL to generate "libcrypto.a" for MIPs platform. Our application links statically with "libcrypto.a" and uses the OpenSSL crypto API's accordingly. With this compilation model, will it be feasible to integrate with the FIPs object module in OpenSSL 3.0? How can we load the FIPS provider in our application? (I have gone through the section about the FIPs module installation in https://wiki.openssl.org/index.php/OpenSSL_3.0#Platforms) Any insight will be helpful to me. Thanks Bala From matt at openssl.org Fri Mar 26 11:01:35 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 26 Mar 2021 11:01:35 +0000 Subject: libcrypto.a and FIPs module in OpenSSL 3.0 In-Reply-To: <1177921885.453798.1616755675814@mail.yahoo.com> References: <1177921885.453798.1616755675814.ref@mail.yahoo.com> <1177921885.453798.1616755675814@mail.yahoo.com> Message-ID: On 26/03/2021 10:47, Bala Duvvuri via openssl-users wrote: > Hi All, > > We build the "crypto" code in OpenSSL to generate "libcrypto.a" for MIPs platform. > > Our application links statically with "libcrypto.a" and uses the OpenSSL crypto API's accordingly. > > With this compilation model, will it be feasible to integrate with the FIPs object module in OpenSSL 3.0? > > How can we load the FIPS provider in our application? > > (I have gone through the section about the FIPs module installation in https://wiki.openssl.org/index.php/OpenSSL_3.0#Platforms) > > Any insight will be helpful to me. It is still possible to use the 3.0 FIPS module even if you use static linking to link to libcrypto. However the FIPS module itself is always a dynamically loaded shared object (i.e. a .so file). So, you statically link your application to libcrypto.a. When needed (either as a result of config, or an explicit call to OSSL_PROVIDER_load()), then the FIPS module fips.so file will be dynamically loaded at runtime by libcrypto. How libcrypto is linked to the application does not impact its ability to dynamically load the FIPS module at runtime. Matt From lists at optimcloud.com Fri Mar 26 11:35:46 2021 From: lists at optimcloud.com (Embedded Devel) Date: Fri, 26 Mar 2021 18:35:46 +0700 Subject: Version compatibility issues - Re: openssl development work / paid - SSL now FIXED In-Reply-To: References: <88307274-9f51-65a4-724c-12e766143d14@optimcloud.com> <83cb5811-d075-22b6-b6c8-f5f202e52ed8@ddvo.net> Message-ID: This has now been fixed.... SSL is working On 3/26/21 3:51 PM, Embedded Devel wrote: > > On 3/26/21 2:46 PM, David von Oheimb wrote: >> >> Embedded Devel, >> >> my sympathy - I know this can be painful and frustrating. >> >> From which old OpenSSL version to which target version do you need to >> get the code updated? >> And as info to whoever may be considering picking up this task: which >> is your timeline for that? >> >> Within OpenSSL we are currently discussing how to handle version >> compatibility issues >> with the upcoming version 3.0 at >> https://github.com/openssl/openssl/issues/14628 >> . >> >> Can you give some concrete typical examples which exact issues you >> are facing? >> >> ??? David >> > i believe this was all from back in the 0.9x days, the code in > question is close to 10+/- years old > > if everyone would look at the email thread? re: "ssl client write / > server accept seems broken" > > some might see more of the issue i am facing, i have has 1 person look > at this and he believes > > quote " > > This looks like using *very* outdated OpenSSL API. Hence the SSL > client (and server) code needs to ported to work with more recent > versions OpenSSL and make use of TLS methods instead of SSL methods. > > For testing you could try to build OpenSSL with the old SSL3 support > enabled (we don't even support that at all in OpenWrt any longer, but > should work to build manually). > Because ssl_undefined_function is most likely a result of: > Disabled features: > ... > ? ? ssl3? ? ? ? ? ? ? ? ? ? [default] OPENSSL_NO_SSL3 > ? ? ssl3-method? ? ? ? ? ? ?[default] OPENSSL_NO_SSL3_METHOD > ... > > If you find someone very familiar with OpenSSLs API (I've used it, more > than once, but it's not what I'm doing every day), this can be done in > a few days. I'd probably need a week for this and I'm not particularly > keen on it, there are things I'm better with which are waiting as well." > > i now have a second developer looking at this, so hoping he can sort > it all out. > > >> On 25.03.21 13:58, Floodeenjr, Thomas wrote: >>> If your problem is the migration from 1.0.2 to 1.1.1, I have >>> attached my porting notes, if that helps. >>> >>> -Tom >>> >>> -----Original Message----- >>> From: openssl-users On Behalf Of >>> Embedded Devel >>> Sent: Wednesday, March 24, 2021 8:02 PM >>> To:openssl-users at openssl.org >>> Subject: openssl development work / paid >>> >>> I tried to get through this on my own, not being a openssl >>> developer, made progress but still no joy >>> >>> so we had an app that was written some 8-10 years ago, which worked >>> fine for client/server tls >>> >>> update to today, no longer functional, deprecations in openssl cause >>> errors >>> >>> it is not a large app, and i believe if someone were to resolve the >>> openssl issues it would work again >>> >>> whos up for making some money ? >>> >>> >>> Thanks >>> From Sunil.Paramashivaiah at rbbn.com Fri Mar 26 12:18:27 2021 From: Sunil.Paramashivaiah at rbbn.com (Paramashivaiah, Sunil) Date: Fri, 26 Mar 2021 12:18:27 +0000 Subject: 'RSA' does not name a type Message-ID: Hi All, While migrating from 1.0.2 to 3.0 we are getting errors like below error: 'RSA' does not name a type We have included header "#include " in the application code but still where ever RSA is used, compiler is unable to identify it as a type. Please suggest how to resolve these kind of errors. Thanks and Regards, Sunil Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Mar 26 12:18:48 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 26 Mar 2021 12:18:48 +0000 Subject: Mismatch between renegotiation reported vs functional In-Reply-To: References: Message-ID: <323b2560-eaed-b6b9-fec9-de7fc1492211@openssl.org> On 25/03/2021 21:59, Shaun Robbins wrote: > While trying to disable renegotiation the response from openssl reads > "Secure Renegotiation IS supported"?even though renegotiation?is failing. Up until 2009 we just had "Renegotiation" as a concept. Then along came a man-in-the-middle attack on such renegotiation. For example see: https://blog.qualys.com/product-tech/2009/11/05/ssl-and-tls-authentication-gap-vulnerability-discovered The problem was a fundamental flaw in the design of renegotiation. So then RFC5746 was written in order to address this problem. Clients/Servers that support RFC5746 are said to support "Secure Renegotiation". Support for secure renegotiation can be indicated via the use of a special ciphersuite, or through the use of extensions. The "Secure Renegotiation IS supported" message means that both peers have indicated support for RFC5746. This is entirely independent of whether a server will actually *allow* any renegotiation at all. In fact it is impossible for the client to know this. The server does not indicate it in any way. So the problem here is a misunderstanding about what this message *means*, i.e. it means both peers have indicated support for RFC5746 (known as "secure renegotiation"). It doesn't tell you whether renegotiation will actually work. Matt > > OpenSSL Config: > SSL_set_options(ssl_conn, SSL_OP_NO_RENEGOTIATION); > > > ] $openssl s_client -connect localhost:443 -tls1_2 > [SNIP] > New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 > Server public key is 2048 bit > *Secure Renegotiation IS supported > *Compression: NONE > Expansion: NONE > No ALPN negotiated > SSL-Session: > [SNIP] > --- > HEAD / HTTP/1.1 > R > RENEGOTIATING > 139845827855680:error:14094153:SSL routines:ssl3_read_bytes:no > renegotiation:../ssl/record/rec_layer_s3.c:1560: > > This article refers to this same problem with some screen shots under > section "Eliminating a false positive": > > https://www.mcafee.com/blogs/enterprise/tips-securing-ssl-renegotiation/ > > > Thanks! > -- > Shaun Robbins From mrshaun13 at gmail.com Fri Mar 26 17:22:38 2021 From: mrshaun13 at gmail.com (Shaun Robbins) Date: Fri, 26 Mar 2021 10:22:38 -0700 Subject: Mismatch between renegotiation reported vs functional In-Reply-To: <323b2560-eaed-b6b9-fec9-de7fc1492211@openssl.org> References: <323b2560-eaed-b6b9-fec9-de7fc1492211@openssl.org> Message-ID: Matt, Thanks a ton for this intel and taking time to provide this answer! This is great backstory and information on what the message actually is telling me. Cheers and happy Friday! On Fri, Mar 26, 2021 at 5:19 AM Matt Caswell wrote: > > > On 25/03/2021 21:59, Shaun Robbins wrote: > > While trying to disable renegotiation the response from openssl reads > > "Secure Renegotiation IS supported" even though renegotiation is failing. > > Up until 2009 we just had "Renegotiation" as a concept. Then along came > a man-in-the-middle attack on such renegotiation. For example see: > > > https://blog.qualys.com/product-tech/2009/11/05/ssl-and-tls-authentication-gap-vulnerability-discovered > > The problem was a fundamental flaw in the design of renegotiation. So > then RFC5746 was written in order to address this problem. > Clients/Servers that support RFC5746 are said to support "Secure > Renegotiation". > > Support for secure renegotiation can be indicated via the use of a > special ciphersuite, or through the use of extensions. > > The "Secure Renegotiation IS supported" message means that both peers > have indicated support for RFC5746. This is entirely independent of > whether a server will actually *allow* any renegotiation at all. In fact > it is impossible for the client to know this. The server does not > indicate it in any way. > > So the problem here is a misunderstanding about what this message > *means*, i.e. it means both peers have indicated support for RFC5746 > (known as "secure renegotiation"). It doesn't tell you whether > renegotiation will actually work. > > Matt > > > > > > OpenSSL Config: > > SSL_set_options(ssl_conn, SSL_OP_NO_RENEGOTIATION); > > > > > > ] $openssl s_client -connect localhost:443 -tls1_2 > > [SNIP] > > New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 > > Server public key is 2048 bit > > *Secure Renegotiation IS supported > > *Compression: NONE > > Expansion: NONE > > No ALPN negotiated > > SSL-Session: > > [SNIP] > > --- > > HEAD / HTTP/1.1 > > R > > RENEGOTIATING > > 139845827855680:error:14094153:SSL routines:ssl3_read_bytes:no > > renegotiation:../ssl/record/rec_layer_s3.c:1560: > > > > This article refers to this same problem with some screen shots under > > section "Eliminating a false positive": > > > > https://www.mcafee.com/blogs/enterprise/tips-securing-ssl-renegotiation/ > > < > https://www.mcafee.com/blogs/enterprise/tips-securing-ssl-renegotiation/> > > > > Thanks! > > -- > > Shaun Robbins > -- -- Shaun Robbins -------------- next part -------------- An HTML attachment was scrubbed... URL: From preethi.kavi17 at gmail.com Sun Mar 28 07:40:32 2021 From: preethi.kavi17 at gmail.com (preethi teekaraman) Date: Sun, 28 Mar 2021 13:10:32 +0530 Subject: How to establish a connection with self signed certificate Message-ID: Hi I'm using latest version 1.1.1i 8 Dec 2020 openssl version to create self signed certificate with sha256 algorithm. I tried loading the certs in device and in server side. The client sends "hello packet" to server and server refused to connect with an error " alert internal error ". The handshake failing between server (nginx load balancer) and client with latest openssl certificate. Any idea to resolve this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From preethi.kavi17 at gmail.com Sun Mar 28 07:41:35 2021 From: preethi.kavi17 at gmail.com (preethi teekaraman) Date: Sun, 28 Mar 2021 13:11:35 +0530 Subject: Openssl - G and P params value increase in DHE cipher Message-ID: Hi Openssl, I'm using the latest version of openssl to create a self -signed certificate. My request is like, we need to observe G and P Param to 256 as value but we could see only 2 as value while a handshake happens between server & client. is there any option or command based solution to increase the G and P parameters? Regards, Preethi Teekaraman -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmr_sultan at hotmail.com Sun Mar 28 09:41:51 2021 From: jmr_sultan at hotmail.com (=?iso-8859-1?Q?Jes=FAs_Molina_Rold=E1n?=) Date: Sun, 28 Mar 2021 09:41:51 +0000 Subject: openssl speed ecdh Message-ID: I would like to know if there is a way to calculate the time spend in generate a key pair and in compute the shared secret for the ecdh algorithm. "openssl speed ecdh" only calculate the number of operations in 10s. Jesus Molina -------------- next part -------------- An HTML attachment was scrubbed... URL: From b_duvvuri at yahoo.com Sun Mar 28 13:05:08 2021 From: b_duvvuri at yahoo.com (Bala Duvvuri) Date: Sun, 28 Mar 2021 13:05:08 +0000 (UTC) Subject: FIPs algorithm code vs default implementation References: <547459569.513482.1616936708595.ref@mail.yahoo.com> Message-ID: <547459569.513482.1616936708595@mail.yahoo.com> Hi All, This is a basic question regarding FIPs algorithm code in OpenSSL 3.0, can you kindly let me know: 1> Can you please help to understand the differences in the FIPs algorithm implementation code vs default? Are there additional validations performed in FIPs code? Can you point to any API (FIPs and non FIPs version) to make this clear? 2> In normal code, EVP_DigestFinal_ex->HASH_FINAL Which API is equivalent to HASH_FINAL in FIPs code? How can we navigate to the FIPs code path? 3> When does "FIPS_MODULE" get defined? Thanks Bala From a.chaouche at algerian-radio.dz Sun Mar 28 13:20:50 2021 From: a.chaouche at algerian-radio.dz (Yassine Chaouche) Date: Sun, 28 Mar 2021 14:20:50 +0100 Subject: Version compatibility issues - Re: openssl development work / paid - SSL now FIXED In-Reply-To: References: <88307274-9f51-65a4-724c-12e766143d14@optimcloud.com> <83cb5811-d075-22b6-b6c8-f5f202e52ed8@ddvo.net> Message-ID: <0af8e656-4ee6-42b9-569a-3cadb5bbec05@algerian-radio.dz> Le 3/26/21 ? 12:35 PM, Embedded Devel a ?crit?: > This has now been fixed.... SSL is working > In a few hours ? From beldmit at gmail.com Sun Mar 28 14:44:35 2021 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Sun, 28 Mar 2021 16:44:35 +0200 Subject: How to establish a connection with self signed certificate In-Reply-To: References: Message-ID: Hello, As you control both the server keypair and client, I'd suggest you to use the openssl s_server/s_client application to debug the connection. On Sun, Mar 28, 2021 at 9:41 AM preethi teekaraman wrote: > Hi > > I'm using latest version 1.1.1i 8 Dec 2020 openssl version to create self > signed certificate with sha256 algorithm. > > I tried loading the certs in device and in server side. The client sends > "hello packet" to server and server refused to connect with an error " > alert internal error ". The handshake failing between server (nginx load > balancer) and client with latest openssl certificate. > > Any idea to resolve this? > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauli at openssl.org Sun Mar 28 23:02:08 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Mon, 29 Mar 2021 09:02:08 +1000 Subject: FIPs algorithm code vs default implementation In-Reply-To: <547459569.513482.1616936708595@mail.yahoo.com> References: <547459569.513482.1616936708595.ref@mail.yahoo.com> <547459569.513482.1616936708595@mail.yahoo.com> Message-ID: <5522360c-0360-dbef-7d18-4176c7d244d6@openssl.org> > 1> Can you please help to understand the differences in the FIPs algorithm implementation code vs default? > > Are there additional validations performed in FIPs code? There are some additional validations, there are other differences. Grep the source code for FIPS_MODULE to find all the code differences.? There are other differences.? The FIPS provider offers a cut down selection of algorithsm, look at providers/fips/fipsprov.c for these.? The FIPS provider also has to run power up selt tests, these are in the providers/fips directory. > Can you point to any API (FIPs and non FIPs version) to make this clear? One example is for AES XTS mode where the two keys are confirmed to be different: Lines 54 - 63 of providers/implementations/ciphers/cipher_aes_xts.c.? There are plenty of others, grep for FIPS_MODULE. > > 2> In normal code, EVP_DigestFinal_ex->HASH_FINAL > > Which API is equivalent to HASH_FINAL in FIPs code? How can we navigate to the FIPs code path? EVP_DisgestFinal_ex is the equivalent.? The decision to use FIPS or not is made when fetching the algorithm not when using it.? In use FIPS and non-FIPS algorithms are accessed identically. I'd suggest having a look at the 3.0 design document: https://www.openssl.org/docs/OpenSSL300Design.html and the 3.0 wiki page: https://wiki.openssl.org/index.php/OpenSSL_3.0. > 3> When does "FIPS_MODULE" get defined? When OpenSSL is being build and a FIPS relevant file is being compiled.? This symbol is never defined for you when you build your application. Pauli From janjust at nikhef.nl Mon Mar 29 07:30:13 2021 From: janjust at nikhef.nl (Jan Just Keijser) Date: Mon, 29 Mar 2021 09:30:13 +0200 Subject: Version compatibility issues - Re: openssl development work / paid - SSL now FIXED In-Reply-To: <0af8e656-4ee6-42b9-569a-3cadb5bbec05@algerian-radio.dz> References: <88307274-9f51-65a4-724c-12e766143d14@optimcloud.com> <83cb5811-d075-22b6-b6c8-f5f202e52ed8@ddvo.net> <0af8e656-4ee6-42b9-569a-3cadb5bbec05@algerian-radio.dz> Message-ID: On 28/03/21 15:20, Yassine Chaouche wrote: > > Le 3/26/21 ? 12:35 PM, Embedded Devel a ?crit?: >> This has now been fixed.... SSL is working >> > In a few hours ? > Yup, took me about 4 hours to understand the problem and get a working fix - there wasn't much wrong with the code itself, but I suspect a weird interaction/build issue with the OpenWRT build of OpenSSL 1.1.1j. JJK From tomas at openssl.org Mon Mar 29 10:38:57 2021 From: tomas at openssl.org (Tomas Mraz) Date: Mon, 29 Mar 2021 12:38:57 +0200 Subject: openssl speed ecdh In-Reply-To: References: Message-ID: On Sun, 2021-03-28 at 09:41 +0000, Jes?s Molina Rold?n wrote: > I would like to know if there is a way to calculate the time spend in > generate a key pair and in compute the shared secret for the ecdh > algorithm. > > "openssl speed ecdh" only calculate the number of operations in 10s. It is not possible with the openssl speed application. You would have to modify its source code to get such numbers. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From b_duvvuri at yahoo.com Tue Mar 30 14:29:26 2021 From: b_duvvuri at yahoo.com (Bala Duvvuri) Date: Tue, 30 Mar 2021 14:29:26 +0000 (UTC) Subject: Unable to load the FIPs config file OpenSSL 3.0 References: <1736802971.1482009.1617114566711.ref@mail.yahoo.com> Message-ID: <1736802971.1482009.1617114566711@mail.yahoo.com> Hi All, Can you kindly help me with this error while running the below program that tries to load the configuration which has the FIPs provider? The program is built on build machine and to be run on linux MIPS platform and below error is seen: #include main () { OSSL_LIB_CTX *libctx; libctx = OSSL_LIB_CTX_new(); OSSL_PROVIDER_set_default_search_path(libctx, "./providers"); if (!OSSL_LIB_CTX_load_config(libctx, "openssl.cnf")) { fputs("ERROR: OSSL_LIB_CTX_load_config()\n", stderr); ERR_print_errors_fp(stderr); } fprintf(stdout, "Version: %s\n", OpenSSL_version(OPENSSL_VERSION)); } ERROR: OSSL_LIB_CTX_load_config() 000000FFF2406000:error:12800067:DSO support routines:(unknown function):could not load the shared library:crypto/dso/dso_dlfcn.c:118:filename(./providers/fips.so): ./providers/fips.so: cannot open shared object file: No such file or directory 000000FFF2406000:error:12800067:DSO support routines:(unknown function):could not load the shared library:crypto/dso/dso_lib.c:162: 000000FFF2406000:error:078C0105:common libcrypto routines:(unknown function):init fail:crypto/provider_core.c:557:name=fips 000000FFF2406000:error:0700006D:configuration file routines:(unknown function):module initialization error:crypto/conf/conf_mod.c:242:module=providers, value=provider_sect retcode=-1 Version: OpenSSL 3.0.0-alpha13 11 Mar 2021 ~ # ls -lrt providers/ -rwxrwxrwx 1 root root 1748513 Mar 30 13:24 fips.so ~ # echo $LD_LIBRARY_PATH ~ # Steps done: 1>On build machine, build OpenSSL for the target architecture, Linux MIPs, and copy the required binaries on the Linux MIPs box. 2>On Linux MIPs box, run ./openssl fipsinstall -out fipsmod.cnf -module fips.so HMAC : (Module_Integrity) : Pass SHA1 : (KAT_Digest) : Pass SHA2 : (KAT_Digest) : Pass SHA3 : (KAT_Digest) : Pass TDES : (KAT_Cipher) : Pass AES_GCM : (KAT_Cipher) : Pass RSA : (KAT_Signature) : RNG : (Continuous_RNG_Test) : Pass Pass ECDSA : (KAT_Signature) : Pass DSA : (KAT_Signature) : Pass TLS12_PRF : (KAT_KDF) : Pass PBKDF2 : (KAT_KDF) : Pass SSHKDF : (KAT_KDF) : Pass KBKDF : (KAT_KDF) : Pass HKDF : (KAT_KDF) : Pass SSKDF : (KAT_KDF) : Pass X963KDF : (KAT_KDF) : Pass X942KDF : (KAT_KDF) : Pass HASH : (DRBG) : Pass CTR : (DRBG) : Pass HMAC : (DRBG) : Pass DH : (KAT_KA) : Pass ECDH : (KAT_KA) : Pass RSA_Encrypt : (KAT_AsymmetricCipher) : Pass RSA_Decrypt : (KAT_AsymmetricCipher) : Pass RSA_Decrypt : (KAT_AsymmetricCipher) : Pass INSTALL PASSED ~ # cat fipsmod.cnf [fips_sect] activate = 1 install-version = 1 conditional-errors = 1 security-checks = 1 module-mac = 60:26:6C:C9:2D:86:A2:25:86:44:67:DC:EE:95:8F:1F:A1:84:4E:42:C4:E6:1F:6A:12:24:A3:29:72:58:A4:0E install-mac = 41:9C:38:C2:8F:59:09:43:2C:AA:2F:58:36:2D:D9:04:F9:6C:56:8B:09:E0:18:3A:2E:D6:CC:69:05:04:E1:11 install-status = INSTALL_SELF_TEST_KATS_RUN 3>In the build machine, modify the contents of "openssl.cnf" with above output, and build the test program linking with crypto library. cat openssl-3.0.0-alpha13/apps/openssl.cnf 1 openssl_conf = openssl_init 2 3 [fips_sect] 4 activate = 1 5 install-version = 1 6 conditional-errors = 1 7 security-checks = 1 8 module-mac = 60:26:6C:C9:2D:86:A2:25:86:44:67:DC:EE:95:8F:1F:A1:84:4E:42:C4:E6:1F:6A:12:24:A3:29:72:58:A4:0E 9 install-mac = 41:9C:38:C2:8F:59:09:43:2C:AA:2F:58:36:2D:D9:04:F9:6C:56:8B:09:E0:18:3A:2E:D6:CC:69:05:04:E1:11 10 install-status = INSTALL_SELF_TEST_KATS_RUN 11 12 [openssl_init] 13 providers = provider_sect 14 alg_section = algorithm_sect 15 16 [provider_sect] 17 default = default_sect 18 fips = fips_sect 19 20 [default_sect] 21 activate = 1 22 23 [algorithm_sect] 24 default_properties = fips=yes 4>Copy the openssl.cnf to the Linux box to "/" and also executed "export OPENSSL_CONF=/" 4>Now on executing the test program on Linux box, observing the load error. Do we need to set any environ variable to get the load working or is any step missing/wrong? This test program has worked fine on my build machine when I build, fipsinstall and rebuild my test program and run the test on the build machine. Your input will help me. Thanks Bala From rkundla at gmail.com Tue Mar 30 18:58:32 2021 From: rkundla at gmail.com (Ron Kundla) Date: Tue, 30 Mar 2021 14:58:32 -0400 Subject: Compute HMAC using nCipher ENGINE and HSM-based symmetric key Message-ID: Hello! I have a requirement to generate a HMAC value using a secret/symmetric key inside the HSM. I have seen examples that use public/private keys to do such a thing, but nothing that would use an AES or a nCipher-specific HMAC key. Does OpenSSL support this function using the ENGINE subsystem? Thanks, Ron From janjust at nikhef.nl Tue Mar 30 21:04:19 2021 From: janjust at nikhef.nl (Jan Just Keijser) Date: Tue, 30 Mar 2021 23:04:19 +0200 Subject: Compute HMAC using nCipher ENGINE and HSM-based symmetric key In-Reply-To: References: Message-ID: Hi, On 30/03/21 20:58, Ron Kundla wrote: > Hello! > > I have a requirement to generate a HMAC value using a secret/symmetric > key inside the HSM. I have seen examples that use public/private keys > to do such a thing, but nothing that would use an AES or a > nCipher-specific HMAC key. > > Does OpenSSL support this function using the ENGINE subsystem? > > OpenSSL supports this, but not many HSMs do; you can take a look at the /dev/crypto engine for an example;? the corresponding bits in the OpenSSL source code are in .../engine/crypto/eng_devcrypto.c I have never seen a PKCS#11 device that support symmetric keys though - but there will be plenty of SSL accelerator cards out there that do (but I would not call them HSMs). HTH, JJK From pauli at openssl.org Wed Mar 31 00:16:52 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Wed, 31 Mar 2021 10:16:52 +1000 Subject: Unable to load the FIPs config file OpenSSL 3.0 In-Reply-To: <1736802971.1482009.1617114566711@mail.yahoo.com> References: <1736802971.1482009.1617114566711.ref@mail.yahoo.com> <1736802971.1482009.1617114566711@mail.yahoo.com> Message-ID: Our general suggestion is to keep the FIPS configuration in it's own file and include that -- this helps when updating. Does a full path to the providers directory help? Could you try a build with debugging symbols so it's possible to see what's going on better? Set a breakpoint on OSSL_PROVIDER_load() and see what's happening? Pauli On 31/3/21 12:29 am, Bala Duvvuri via openssl-users wrote: > Hi All, > > Can you kindly help me with this error while running the below program that tries to load the configuration which has the FIPs provider? > > The program is built on build machine and to be run on linux MIPS platform and below error is seen: > > #include > main () { > OSSL_LIB_CTX *libctx; > libctx = OSSL_LIB_CTX_new(); > OSSL_PROVIDER_set_default_search_path(libctx, "./providers"); > if (!OSSL_LIB_CTX_load_config(libctx, "openssl.cnf")) { > fputs("ERROR: OSSL_LIB_CTX_load_config()\n", stderr); > ERR_print_errors_fp(stderr); > } > fprintf(stdout, "Version: %s\n", OpenSSL_version(OPENSSL_VERSION)); > } > > ERROR: OSSL_LIB_CTX_load_config() > 000000FFF2406000:error:12800067:DSO support routines:(unknown function):could not load the shared library:crypto/dso/dso_dlfcn.c:118:filename(./providers/fips.so): ./providers/fips.so: cannot open shared object file: No such file or directory > 000000FFF2406000:error:12800067:DSO support routines:(unknown function):could not load the shared library:crypto/dso/dso_lib.c:162: > 000000FFF2406000:error:078C0105:common libcrypto routines:(unknown function):init fail:crypto/provider_core.c:557:name=fips > 000000FFF2406000:error:0700006D:configuration file routines:(unknown function):module initialization error:crypto/conf/conf_mod.c:242:module=providers, value=provider_sect retcode=-1 > Version: OpenSSL 3.0.0-alpha13 11 Mar 2021 > > ~ # ls -lrt providers/ > -rwxrwxrwx 1 root root 1748513 Mar 30 13:24 fips.so > > ~ # echo $LD_LIBRARY_PATH > ~ # > > Steps done: > 1>On build machine, build OpenSSL for the target architecture, Linux MIPs, and copy the required binaries on the Linux MIPs box. > 2>On Linux MIPs box, run ./openssl fipsinstall -out fipsmod.cnf -module fips.so > HMAC : (Module_Integrity) : Pass > SHA1 : (KAT_Digest) : Pass > SHA2 : (KAT_Digest) : Pass > SHA3 : (KAT_Digest) : Pass > TDES : (KAT_Cipher) : Pass > AES_GCM : (KAT_Cipher) : Pass > RSA : (KAT_Signature) : RNG : (Continuous_RNG_Test) : Pass > Pass > ECDSA : (KAT_Signature) : Pass > DSA : (KAT_Signature) : Pass > TLS12_PRF : (KAT_KDF) : Pass > PBKDF2 : (KAT_KDF) : Pass > SSHKDF : (KAT_KDF) : Pass > KBKDF : (KAT_KDF) : Pass > HKDF : (KAT_KDF) : Pass > SSKDF : (KAT_KDF) : Pass > X963KDF : (KAT_KDF) : Pass > X942KDF : (KAT_KDF) : Pass > HASH : (DRBG) : Pass > CTR : (DRBG) : Pass > HMAC : (DRBG) : Pass > DH : (KAT_KA) : Pass > ECDH : (KAT_KA) : Pass > RSA_Encrypt : (KAT_AsymmetricCipher) : Pass > RSA_Decrypt : (KAT_AsymmetricCipher) : Pass > RSA_Decrypt : (KAT_AsymmetricCipher) : Pass > INSTALL PASSED > > ~ # cat fipsmod.cnf > [fips_sect] > activate = 1 > install-version = 1 > conditional-errors = 1 > security-checks = 1 > module-mac = 60:26:6C:C9:2D:86:A2:25:86:44:67:DC:EE:95:8F:1F:A1:84:4E:42:C4:E6:1F:6A:12:24:A3:29:72:58:A4:0E > install-mac = 41:9C:38:C2:8F:59:09:43:2C:AA:2F:58:36:2D:D9:04:F9:6C:56:8B:09:E0:18:3A:2E:D6:CC:69:05:04:E1:11 > install-status = INSTALL_SELF_TEST_KATS_RUN > > 3>In the build machine, modify the contents of "openssl.cnf" with above output, and build the test program linking with crypto library. > > cat openssl-3.0.0-alpha13/apps/openssl.cnf > 1 openssl_conf = openssl_init > 2 > 3 [fips_sect] > 4 activate = 1 > 5 install-version = 1 > 6 conditional-errors = 1 > 7 security-checks = 1 > 8 module-mac = 60:26:6C:C9:2D:86:A2:25:86:44:67:DC:EE:95:8F:1F:A1:84:4E:42:C4:E6:1F:6A:12:24:A3:29:72:58:A4:0E > 9 install-mac = 41:9C:38:C2:8F:59:09:43:2C:AA:2F:58:36:2D:D9:04:F9:6C:56:8B:09:E0:18:3A:2E:D6:CC:69:05:04:E1:11 > 10 install-status = INSTALL_SELF_TEST_KATS_RUN > 11 > 12 [openssl_init] > 13 providers = provider_sect > 14 alg_section = algorithm_sect > 15 > 16 [provider_sect] > 17 default = default_sect > 18 fips = fips_sect > 19 > 20 [default_sect] > 21 activate = 1 > 22 > 23 [algorithm_sect] > 24 default_properties = fips=yes > > 4>Copy the openssl.cnf to the Linux box to "/" and also executed "export OPENSSL_CONF=/" > > 4>Now on executing the test program on Linux box, observing the load error. > > Do we need to set any environ variable to get the load working or is any step missing/wrong? > > This test program has worked fine on my build machine when I build, fipsinstall and rebuild my test program and run the test on the build machine. > > Your input will help me. > > Thanks > Bala > From openssl at foocrypt.net Wed Mar 31 03:29:09 2021 From: openssl at foocrypt.net (openssl at foocrypt.net) Date: Tue, 30 Mar 2021 21:29:09 -0600 Subject: Australia's DTCA/DSGL Criminalisation of Encryption based Technologies. Message-ID: <56bec78ea64b8f9781c53905c389a18b@foocrypt.net> G?Day from Down Under and to quell the conspiracy theorists & April Fools Day pranks.... Despite the coincidental reference to being officially launched on the 1st of April, 2021 to match the 5th anniversary of the criminalisation of encryption based technologies under the DTCA/DSGL.......I do actually have Australian Department of Defence, Defence Export Control, approval for FooStegCypher. ? FooCrypt.6.0.0.Core provides you with the total peace of mind over the SECURITY & PRIVACY of YOUR DATA. FooCrypt.6.0.0.OpenSSL utilises OpenSSL 1.1.1(a-k) & 3.0.0.Alpha13 Checkout the latest White Paper and Documentation @ https://foocrypt.net FooStegCypher, Maximum Obfuscation Bit Strength of One hundred twenty quadrillion. https://foocrypt.net/media-release-foocrypt-6-0-0-core-20210401 -- Regards, Mark A. Lane ? Mark A. Lane 1980 - 2021, All Rights Reserved. ? FooCrypt 1980 - 2021, All Rights Reserved. ? FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2021, All Rights Reserved. ? Cryptopocalypse 1980 - 2021, All Rights Reserved. From xiaonan830818 at gmail.com Wed Mar 31 05:49:31 2021 From: xiaonan830818 at gmail.com (Nan Xiao) Date: Wed, 31 Mar 2021 13:49:31 +0800 Subject: Why does OpenSSL report google's certificate is "self-signed"? Message-ID: Hi OpenSSL users, Greetings from me! I am using the master branch of OpenSSL and testing client-arg program (in demos/bio) with "google.com:443": # LD_LIBRARY_PATH=/root/openssl/build gdb --args ./client-arg -connect "google.com:443" ...... (gdb) 91 if (BIO_do_connect(sbio) <= 0) { (gdb) 97 if (BIO_do_handshake(sbio) <= 0) { (gdb) p ssl->verify_result $1 = 18 The connection is successful, but the ssl->verify_result is 18, i.e., X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT. I am a little confused why OpenSSL reports google's certificate is "self-signed"? And it should be not. The following result is from "openssl s_client": # openssl s_client -connect google.com:443 CONNECTED(00000003) depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign verify return:1 depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.google.com verify return:1 --- Certificate chain 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.google.com i:C = US, O = Google Trust Services, CN = GTS CA 1O1 1 s:C = US, O = Google Trust Services, CN = GTS CA 1O1 i:OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign --- Anyone can give some clues? Thanks very much in advance! Best Regards Nan Xiao From hkario at redhat.com Wed Mar 31 13:14:48 2021 From: hkario at redhat.com (Hubert Kario) Date: Wed, 31 Mar 2021 15:14:48 +0200 Subject: Openssl - G and P params value increase in DHE cipher In-Reply-To: References: Message-ID: On Sunday, 28 March 2021 09:41:35 CEST, preethi teekaraman wrote: > Hi Openssl, > > I'm using the latest version of openssl to create a self -signed > certificate. > > My request is like, we need to observe G and P Param to 256 as value but we > could see only 2 as value while a handshake happens between server & > client. > > is there any option or command based solution to increase the G and P > parameters? no and it's not something that should be done, see https://tools.ietf.org/html/rfc7919 and appendinx D of https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf -- 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-users at dukhovni.org Wed Mar 31 16:30:53 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 31 Mar 2021 12:30:53 -0400 Subject: Why does OpenSSL report google's certificate is "self-signed"? In-Reply-To: References: Message-ID: > On Mar 31, 2021, at 1:49 AM, Nan Xiao wrote: > > The connection is successful, but the ssl->verify_result is 18, i.e., > X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT. I am a little confused why > OpenSSL reports google's certificate is "self-signed"? And it should > be not. Most likely you haven't configured a suitable CAfile and/or CApath, which contains the root CA that ultimately issued Google's certificate. It looks like Google includes a self-signed root CA in the wire certificate chain, and if no match is found in the trust store, you'll get the reported error. -- Viktor. From Michael.Wojcik at microfocus.com Wed Mar 31 17:43:26 2021 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 31 Mar 2021 17:43:26 +0000 Subject: Why does OpenSSL report google's certificate is "self-signed"? In-Reply-To: References: Message-ID: > From: openssl-users On Behalf Of Viktor > Dukhovni > Sent: Wednesday, 31 March, 2021 10:31 > To: openssl-users at openssl.org > Subject: Re: Why does OpenSSL report google's certificate is "self-signed"? > > It looks like Google includes a self-signed root CA in the wire > certificate chain, and if no match is found in the trust store, > you'll get the reported error. What do people think about this practice of including the root in the chain? As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline Requirements say anything about the practice, though I may have missed something. I had a vague memory that some standard or "best practice" guideline somewhere said the server should send the chain up to but not including the root, but I don't know what that might have been. On the one hand, including the root doesn't help with path validation: either some certificate along the chain is a trust anchor already, in which case there's no need to include the root; or it isn't, in which case the peer has no reason to trust the chain. On the other, it's useful for debugging, and perhaps for quickly finding whether the highest intermediate in the chain is signed by a trusted root if that intermediate is missing an AKID (though we'd hope that isn't the case). I can also see an application deferring trust to the user in this case: "this chain ends in this root, which you don't currently trust, but maybe you'd like to add it?". Which doesn't seem like a great plan either -- and PKIX says trust anchors should be added using a trustworthy out-of-band procedure, which this is not -- but I suppose it's a conceivable use case. -- Michael Wojcik From openssl-users at dukhovni.org Wed Mar 31 17:48:40 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 31 Mar 2021 13:48:40 -0400 Subject: Why does OpenSSL report google's certificate is "self-signed"? In-Reply-To: References: Message-ID: > On Mar 31, 2021, at 1:43 PM, Michael Wojcik wrote: > > As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline Requirements say anything about the practice, though I may have missed something. I had a vague memory that some standard or "best practice" guideline somewhere said the server should send the chain up to but not including the root, but I don't know what that might have been. Inclusion of the self-signed root is harmless. The only case that I know of where this is actually necessary is with DANE-TA(2) when the TLSA RRset has a hash of the trusted root cert or public key. -- Viktor. From uri at ll.mit.edu Wed Mar 31 18:01:05 2021 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 31 Mar 2021 18:01:05 +0000 Subject: Why does OpenSSL report google's certificate is "self-signed"? In-Reply-To: References: Message-ID: For a Web GUI with the user at the console (e.g., a Web browser), it might be OK. For my needs (devices talking to each other over austere links), sending the root CA very is both useless and wasteful. One you factor in the sizes of Post-Quantum keys and signatures - you?ll start disliking this idea even more. Regards, Uri > On Mar 31, 2021, at 13:49, Viktor Dukhovni wrote: > > ? >> >> On Mar 31, 2021, at 1:43 PM, Michael Wojcik wrote: >> >> As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline Requirements say anything about the practice, though I may have missed something. I had a vague memory that some standard or "best practice" guideline somewhere said the server should send the chain up to but not including the root, but I don't know what that might have been. > > Inclusion of the self-signed root is harmless. The only case that > I know of where this is actually necessary is with DANE-TA(2) when > the TLSA RRset has a hash of the trusted root cert or public key. > > -- > Viktor. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5819 bytes Desc: not available URL: From Walter.H at mathemainzel.info Wed Mar 31 18:04:15 2021 From: Walter.H at mathemainzel.info (Walter H.) Date: Wed, 31 Mar 2021 20:04:15 +0200 Subject: Why does OpenSSL report google's certificate is "self-signed"? In-Reply-To: References: Message-ID: <3faae6a2-5a6f-6ab2-32ce-5009cd881817@mathemainzel.info> On 31.03.2021 19:48, Viktor Dukhovni wrote: >> On Mar 31, 2021, at 1:43 PM, Michael Wojcik wrote: >> >> As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline Requirements say anything about the practice, though I may have missed something. I had a vague memory that some standard or "best practice" guideline somewhere said the server should send the chain up to but not including the root, but I don't know what that might have been. > Inclusion of the self-signed root is harmless. do some admins this really? I have more often the problem, that just the end SSL certificate is sent, and without the intermediate certificate any validation is impossible; in such case I download the intermediate just to complete the chain; > The only case that > I know of where this is actually necessary is with DANE-TA(2) when > the TLSA RRset has a hash of the trusted root cert or public key. > this case is history, there doesn't exist any user agent, which has implemented this; -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3550 bytes Desc: S/MIME Cryptographic Signature URL: From openssl-users at dukhovni.org Wed Mar 31 18:09:29 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 31 Mar 2021 14:09:29 -0400 Subject: Why does OpenSSL report google's certificate is "self-signed"? In-Reply-To: <3faae6a2-5a6f-6ab2-32ce-5009cd881817@mathemainzel.info> References: <3faae6a2-5a6f-6ab2-32ce-5009cd881817@mathemainzel.info> Message-ID: <5E4DBCD4-496A-4275-944A-5F21EFBF03D0@dukhovni.org> > On Mar 31, 2021, at 2:04 PM, Walter H. wrote: > > On 31.03.2021 19:48, Viktor Dukhovni wrote: >>> On Mar 31, 2021, at 1:43 PM, Michael Wojcik wrote: >>> >>> As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline Requirements say anything about the practice, though I may have missed something. I had a vague memory that some standard or "best practice" guideline somewhere said the server should send the chain up to but not including the root, but I don't know what that might have been. >> Inclusion of the self-signed root is harmless. > > do some admins this really? Since it is possible to do, inevitably some will do it. >> The only case that >> I know of where this is actually necessary is with DANE-TA(2) when >> the TLSA RRset has a hash of the trusted root cert or public key. >> > this case is history, there doesn't exist any user agent, which has implemented this; Well, that's false, just because you're not familiar with it, does not mean it does not exist. OpenSSL, Postfix, Exim, Halon MTA, Cisco ESA, PowerMTA, ... all support DANE, including DANE-TA(2). Yes, no major browsers as yet supports DANE. But not all TLS is HTTPS and not all HTTPS is browsers viewing websites. -- Viktor. From openssl-users at dukhovni.org Wed Mar 31 18:14:15 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 31 Mar 2021 14:14:15 -0400 Subject: Why does OpenSSL report google's certificate is "self-signed"? In-Reply-To: References: Message-ID: <746F65E3-C06A-4A25-9D15-1E5041481AB2@dukhovni.org> > On Mar 31, 2021, at 2:01 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > For a Web GUI with the user at the console (e.g., a Web browser), it might be OK. > > For my needs (devices talking to each other over austere links), sending the root CA very is both useless and wasteful. One you factor in the sizes of Post-Quantum keys and signatures - you?ll start disliking this idea even more. There's no urgency in post-quantum keys for CA signatures in TLS. Their future weakness does not compromise today's traffic. Until actual scalable QCs start cracking RSA and ECDSA in near real-time only the ephemeral key agreement algorithm needs to be PQ-resistant now to future-proof session confidentiality. So certificates can continue to use RSA and ECDSA for quite some time. -- Viktor. From uri at ll.mit.edu Wed Mar 31 18:42:31 2021 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 31 Mar 2021 18:42:31 +0000 Subject: Why does OpenSSL report google's certificate is "self-signed"? In-Reply-To: <746F65E3-C06A-4A25-9D15-1E5041481AB2@dukhovni.org> References: <746F65E3-C06A-4A25-9D15-1E5041481AB2@dukhovni.org> Message-ID: You are right - there?s no urgency in PQ signatures. However, PQ KEM keys aren?t small. And, as I said, f?r austere links every unnecessary byte of crap hurts. Also, sending root certs seems (marginally) useful only when the recipient is a Web browser. And even then I assume most of the IT people would want to block the ability of a ?mere? user to add an ?unblessed? trusted root. Regards, Uri > On Mar 31, 2021, at 14:15, Viktor Dukhovni wrote: > > ? >> >> On Mar 31, 2021, at 2:01 PM, Blumenthal, Uri - 0553 - MITLL wrote: >> >> For a Web GUI with the user at the console (e.g., a Web browser), it might be OK. >> >> For my needs (devices talking to each other over austere links), sending the root CA very is both useless and wasteful. One you factor in the sizes of Post-Quantum keys and signatures - you?ll start disliking this idea even more. > > There's no urgency in post-quantum keys for CA signatures in TLS. Their > future weakness does not compromise today's traffic. Until actual scalable > QCs start cracking RSA and ECDSA in near real-time only the ephemeral key > agreement algorithm needs to be PQ-resistant now to future-proof session > confidentiality. > > So certificates can continue to use RSA and ECDSA for quite some time. > > -- > Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5819 bytes Desc: not available URL: From openssl-users at dukhovni.org Wed Mar 31 18:45:56 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 31 Mar 2021 14:45:56 -0400 Subject: Why does OpenSSL report google's certificate is "self-signed"? In-Reply-To: References: <746F65E3-C06A-4A25-9D15-1E5041481AB2@dukhovni.org> Message-ID: <6DBC713B-C453-427D-A7EB-E566A58FA6E1@dukhovni.org> > On Mar 31, 2021, at 2:42 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > You are right - there?s no urgency in PQ signatures. > > However, PQ KEM keys aren?t small. And, as I said, f?r austere links every unnecessary byte of crap hurts. > > Also, sending root certs seems (marginally) useful only when the recipient is a Web browser. And even then I assume most of the IT people would want to block the ability of a ?mere? user to add an ?unblessed? trusted root. I am not trying to suggest that including the root CA in the server's chain is a best practice. I am sticking with mostly harmless. And even with DANE, my recommendation is to use an intermediate CA with the DANE-TA(2) records, and not rely on the root CA being part of the transmitted chain. -- Viktor.