From pkudingping at gmail.com  Fri Jan  1 07:07:47 2021
From: pkudingping at gmail.com (=?UTF-8?B?5a6a5bmz6KKB?=)
Date: Fri, 1 Jan 2021 15:07:47 +0800
Subject: Directly trusted self-issued end-entity certs - Re: How to rotate
 cert when only first matching cert been verified
In-Reply-To: <47058390-b956-16d4-f15f-c839e4272f9d@ddvo.net>
References: <mailman.161.1608764215.20353.openssl-users@openssl.org>
 <1bc0d4a9-7a71-1cd6-5d85-ea4e9e70bda4@binect.de>
 <CABYODQ9r0NhEoh=ANJXyZn1o1-SudeAEarCxPQWWBcga=4iCtA@mail.gmail.com>
 <47058390-b956-16d4-f15f-c839e4272f9d@ddvo.net>
Message-ID: <CABYODQ9qnvoH3pBdZYAs9WUXKTY3Hw4AWajeXBQ_okctGJvcRQ@mail.gmail.com>

@David von Oheimb <dev at ddvo.net>
Thank you so much for your deep investigation!
With subjectKeyIdentifier and authorityKeyIdentifier extensions, it works
like a charm!

So, the former statements I found on this page
<https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_load_verify_locations.html>
only applies to CA cert, not EE cert.
How to pick up cert from trust store(or cert container as you say)
is decided by different implementation themselves, do I understand
correctly?

Since GnuTls and golang could pick up the right cert in this kind of
scenario,
they must implement their own logic to pick up the right cert, do you think
OpenSSL
will implement this logic too? Or it's a more appropriate approach to just
use the extensions you suggested?

Regards,
Dingping

David von Oheimb <dev at ddvo.net> ?2020?12?26??? ??5:17???

> On 25.12.20 00:35, ??? wrote:
>
> @David von Oheimb <dev at ddvo.net> I will update to a new version and try
> again.
>
> Good. Ideally try also a current 3.0.0 alpha release because there have
> been some changes to cert chain building and verification recently.
>
> To append cert is to make sure new cert and old cert both exist in trust
> store, thus when server switches cert, it can be trusted by client.
>
> Understood, but my point was on a different aspect:
> The chain building will take the first matching cert, so if you want to
> prefer the new cert, it must be in the list *before* the old one -
> in other words, prepend the new cert to the list rather than appending to
> it.
>
> @Jochen actually, the certs have different SN, which indeed is not
> consistent with the man doc
>
> Different certs with the same issuer indeed *must* have different SNs
> (except in the special case I mention below).
> See also RFC 5280 section 4.1.2.2
> https://tools.ietf.org/html/rfc5280#section-4.1.2.2:
>
>   It MUST be unique for each certificate issued by a given CA
>      (i.e., the issuer name and serial number identify a unique certificate).
>
>
> Yet there is a different inconsistency in what you write:
>
> The thing that confuses me is that CURL (compiled with gnutls) and Golang
> works.
> below is my ca.crt file, I am not sure where it went wrong, maybe just my
> wrong behavior?
>
> You refer to them as CA certs, but they are not: they do no have a
> basicConstraints field with the cA bit set.
> And as far as I understand your scenario, they are not used to issue other
> certs but by some (TLS) server,
> so they really are end-entity (EE) certs, not CA certs, and it looks like
> this is correct in your application scenario.
>
> Directly trusted self-issued EE certs (which may be self-signed or not)
> are a special situation.
> This has been clarified in RFC 6818 (which updates RFC 5280)
> https://tools.ietf.org/html/rfc6818#section-2:
>
> | Consistent with Section 3.4.61 <https://tools.ietf.org/html/rfc6818#section-3.4.61> of X.509 (11/2008) [X.509 <https://tools.ietf.org/html/rfc6818#ref-X.509>], we note
> | that use of self-issued certificates and self-signed certificates
> | issued by entities other than CAs are outside the scope of this
> | specification.  Thus, for example, a web server or client might
> | generate a self-signed certificate to identify itself.  These
> | certificates and how a relying party uses them to authenticate
> | asserted identities are both outside the scope of RFC 5280 <https://tools.ietf.org/html/rfc5280>.
>
> So the path building and verification, as well as other checks defined RFC
> 5280, does not apply to them at all!
> They are essentially just a convenient container for a public key, where
> it is optional to check expiration etc.
>
>
> Unfortunately, when using such certs for TLS connections etc., still
> verification is done on them, which may fail.
> After renaming your ca.crt file to ee.crt for clarity and extracting the
> first cert in ee1.crt and the second one in ee2.crt,
> when verifying these directly trusted certs one gets the problem you
> reported:
>
> openssl verify -x509_strict -trusted ee.crt ee1.crt
> ee1.crt: OK
>
> openssl verify -x509_strict -trusted ee.crt ee2.crt
> C = US, ST = CA, L = Palo Alto, O = VMware, CN =
> nsxmanager.pks.vmware.local
> error 18 at 0 depth lookup: self signed certificate
> error ee2.crt: verification failed
>
> So as I wrote before, unfortunately the path building picks up the first
> matching cert from ee.crt,
> which is the one in ee1.crt (i.e., your old one), and does not try the
> second one (i.e., your new one).
> This happens also with the latest OpenSSL pre-3.0.0 master.
>
>
> A solution is to add both the subjectKeyIdentifier and
> authorityKeyIdentifier extensions to your certs,
> for instance like this:
>
> echo >ee.cnf "
> prompt = no
> distinguished_name = my_server
> x509_extensions = my_exts
> [my_server]
> commonName = test
> [my_exts]
> basicConstraints = CA:false
> subjectKeyIdentifier=hash
> authorityKeyIdentifier = keyid"
>
> openssl req -config ee.cnf -new -x509 -out ee1.crt -nodes -keyout ee1.pem
> openssl req -config ee.cnf -new -x509 -out ee2.crt -nodes -keyout ee2.pem
> cat ee1.crt ee2.crt >ee.crt
>
> The subjectKeyIdentifier and authorityKeyIdentifier extensions are
> generally recommend
> (and actually required to add for certs that are RFC 5280 compliant)
> because they help for correct chain building, and indeed also in this case
> they do:
>
> openssl verify -x509_strict -trusted ee.crt ee1.crt
> ee1.crt: OK
> openssl verify -x509_strict -trusted ee.crt ee2.crt
> ee2.crt: OK
>
> Regards,
>
>     David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210101/11d377e0/attachment-0001.html>

From pkudingping at gmail.com  Fri Jan  1 11:32:08 2021
From: pkudingping at gmail.com (=?UTF-8?B?5a6a5bmz6KKB?=)
Date: Fri, 1 Jan 2021 19:32:08 +0800
Subject: openssl-users Digest, Vol 73, Issue 29
In-Reply-To: <DM6PR18MB270049C7B3A1C88FAECA0243F9D91@DM6PR18MB2700.namprd18.prod.outlook.com>
References: <mailman.189.1608852959.20353.openssl-users@openssl.org>
 <2bad4f90-d40a-f9e3-2317-f0166514132d@binect.de>
 <DM6PR18MB270049C7B3A1C88FAECA0243F9D91@DM6PR18MB2700.namprd18.prod.outlook.com>
Message-ID: <CABYODQ97rqk6XQYz2yC_VDYs9ud7GF=wh1MPp8vHPNmtphYyMA@mail.gmail.com>

@Jochen Bern <Jochen.Bern at binect.de>
Thanks for your reply!

I didn't describe the problem clearly due to lack of tls domain knowledge.
Now I know my cert is self-signed end entity cert, and the statement I
found
on openssl website does not apply to me. The behavior is similar(Actually
not the same,
since my two certs have different serial number, at first I did not notice
this, mistakenly thought my
two certs are the same) is just because I hit another
unofficial/non-standard support like you and David pointed out.

The way you suggested to add timestamp to OU definitely works, because in
my test
I actually noticed this result(different certs can be distinguished
correctly), but I'm just not sure
if it is acceptable to my current case, but anyway David's solution works
for me.

@Michael Wojcik <Michael.Wojcik at microfocus.com> Thanks again for your help!
in my case, the CN and sAN part are easy, since we only need to support one
FQDN, it does not change.

Looks like I missed this email since the title changed.

Regards,
Dingping


Michael Wojcik <Michael.Wojcik at microfocus.com> ?2020?12?29??? ??7:16???

> > From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of
> Jochen
> > Bern
> > Sent: Friday, 25 December, 2020 03:37
>
> I believe David von Oheimb has already provided a solution for the
> original problem in this thread (setting subjectKeyIdentifier and
> authorityKeyIdentifer lets OpenSSL pick the right certificate from the
> trust-anchor collection). I wanted to comment on this tangential point:
>
> > For server
> > certs, where you need the CN to match the FQDN, you might want to add an
> > OU with a timestamp so as to have the *DN* as a whole differ ...
>
> If your entity certificate is X.509v3 and the client complies with RFC
> 5280, the CN of the Subject DN shouldn't matter, as long as the server name
> *as expected by the peer* appears in a subjectAlternativeName extension.
>
> That is, if the client wants to connect to "www.foo.com", the server's
> certificate should have a DNS-type sAN with the value "www.foo.com". If
> the client wants to connect to the unqualified hostname "foo", the server's
> certificate should have a DNS-type sAN with the value "foo". If the client
> wants to connect to "192.168.2.1", the server's certificate should have an
> IPADR-type sAN with that value. And so on. If any sANs are present, the CN
> (if any) of the Subject DN should be ignored.
>
> Here "wants to connect" is defined by the application and/or its TLS
> implementation. The implementation may provide a way for a client to
> specify the subject-name it wants to find in the entity certificate, or it
> may simply take whatever hostname or IP address string it's asked to
> connect to, and use that.
>
> Also remember that OpenSSL prior to 1.0.2 didn't have support for checking
> hostnames at all. With 1.0.2 you have to make some non-obvious calls to set
> the expected name, and with 1.1.0 and later you need to use SSL_set1_host
> (or the 1.0.2 method); there's a page on the OpenSSL wiki for this. I don't
> remember if this has changed again in 3.0.
>
> --
> Michael Wojcik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210101/ae3080dd/attachment.html>

From Michael.Wojcik at microfocus.com  Fri Jan  1 18:06:47 2021
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 1 Jan 2021 18:06:47 +0000
Subject: Directly trusted self-issued end-entity certs - Re: How to rotate
 cert when only first matching cert been verified
In-Reply-To: <CABYODQ9qnvoH3pBdZYAs9WUXKTY3Hw4AWajeXBQ_okctGJvcRQ@mail.gmail.com>
References: <mailman.161.1608764215.20353.openssl-users@openssl.org>
 <1bc0d4a9-7a71-1cd6-5d85-ea4e9e70bda4@binect.de>
 <CABYODQ9r0NhEoh=ANJXyZn1o1-SudeAEarCxPQWWBcga=4iCtA@mail.gmail.com>
 <47058390-b956-16d4-f15f-c839e4272f9d@ddvo.net>
 <CABYODQ9qnvoH3pBdZYAs9WUXKTY3Hw4AWajeXBQ_okctGJvcRQ@mail.gmail.com>
Message-ID: <DM6PR18MB2700122DB52AD88C2A23E7B0F9D51@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of ???
> Sent: Friday, 1 January, 2021 00:08

> How to pick up cert from trust store(or cert container as you say)
> is decided by different implementation themselves, do I understand correctly?

Yes, in some cases under partial or complete control by the application. Some APIs, including OpenSSL, give the application a lot of control over the building of the chain; others don't.

And almost everyone does it incorrectly. See for example:

https://duo.com/labs/research/chain-of-fools

https://nakedsecurity.sophos.com/2020/06/02/the-mystery-of-the-expiring-sectigo-web-certificate/

https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html

https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/CPT/CPT_Tool_Test-Report_Findings.pdf

(There was another article published not that long ago that surveyed a number of TLS implementations and how they built chains, pointing out how they failed to follow various requirements of PKIX, and what kinds of errors and failures they were prone to. It's similar to the CPT paper linked above, but included comparisons of different OpenSSL versions. I can't seem to find it at the moment.)

The path-validation algorithm in RFC 5280 and the path-building algorithm from RFC 4158 are agonizingly complex. Note, for example, that the description of the path-building algorithm in 4158 is 20 pages, without including the preliminary material or the longer section on optimizations.

TLS simplifies the general problem of X.509 chain construction by limiting what entities are supposed to send (X.509 lets you send any random collection of certificates, or for that matter any other data, in addition to the entity certificate; TLS says "send just a single chain from entity to root or to a certificate signed by the root"). But it's still awful, particularly when things like expiration and cross-signing come into play, and no version of OpenSSL (or any other popular library, as far as I remember) gets it entirely right for all cases.

In practice, if you use a supported OpenSSL release at the latest fix level (that means 1.1.1i at the moment), and you follow good advice about how to use it, and your use case isn't too complex, you provably achieve reasonable security under a typical application threat model. You'll want to make it relatively straightforward to update your trust-anchor collection. If you have to support an environment where things like cross-signing and multiple validation paths become important, that makes things harder. If you have stringent security requirements, that makes things harder. On the other hand, there are so many applications which fail to do even minimal certificate validation, so you can take comfort in knowing you're better than them, anyway.

--
Michael Wojcik


From dev at ddvo.net  Fri Jan  1 21:16:57 2021
From: dev at ddvo.net (David von Oheimb)
Date: Fri, 1 Jan 2021 22:16:57 +0100
Subject: Directly trusted self-issued end-entity certs - Re: How to rotate
 cert when only first matching cert been verified
In-Reply-To: <CABYODQ9qnvoH3pBdZYAs9WUXKTY3Hw4AWajeXBQ_okctGJvcRQ@mail.gmail.com>
References: <mailman.161.1608764215.20353.openssl-users@openssl.org>
 <1bc0d4a9-7a71-1cd6-5d85-ea4e9e70bda4@binect.de>
 <CABYODQ9r0NhEoh=ANJXyZn1o1-SudeAEarCxPQWWBcga=4iCtA@mail.gmail.com>
 <47058390-b956-16d4-f15f-c839e4272f9d@ddvo.net>
 <CABYODQ9qnvoH3pBdZYAs9WUXKTY3Hw4AWajeXBQ_okctGJvcRQ@mail.gmail.com>
Message-ID: <fa231f04-7e10-f87e-8a31-7971ab0f6b93@ddvo.net>

On 01.01.21 08:07, ??? wrote:
> @David von Oheimb <mailto:dev at ddvo.net>
> Thank you so much for your deep investigation!
My pleasure!

> With subjectKeyIdentifier and authorityKeyIdentifier extensions, it
> works like a charm!
Good to hear.
I've meanwhile submitted a pull request that fixed the behavior also? in
case no SKID and AKID are included in the certs
and briefly mentioned your use case there:
https://github.com/openssl/openssl/pull/13748

> So, the former statements I found on this page
> <https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_load_verify_locations.html>
> only applies to CA cert, not EE cert.
> How to pick up cert from trust store(or cert container as you say)
> is decided by different implementation themselves, do I understand
> correctly?
It looks like my explanations were a bit mistakable.
Although self-signed (and more generally, self-issued) EE certs are out
of scope of RFC 5280, OpenSSL still tries to build a cert chain for them
and then to verify it.
Please also note that I did not write "cert container", but that these
certs are essentially just a convenient container /for a public key/.
In other words, they have the /format/ of an X.509 certificate, but the
only thing that really matters in such a cert is the public key.
Yet since they look like a certificate, they can be used where a
certificate is expected, e.g., in TLS handshake and in trust stores.

> Since GnuTls and golang could pick up the right cert in this kind of
> scenario,
> they must implement their own logic to pick up the right cert, do you
> think OpenSSL
> will implement this logic too? Or it's a more appropriate approach to
> just
> use the extensions you suggested?
With the fix mentioned above, chain building and verification will
always succeed,
regardless how the cert looks like because in this case it is sufficient
to find the target certificate in the trust store,
without having to check and further data that may be included in it.
Although not required by RFC 5280 for such a cert, OpenSSL does check
for its expiration
(and may check policy restrictions etc.) because this is helpful in most
application scenarios.

Regards,

??? David


> David von Oheimb <dev at ddvo.net <mailto:dev at ddvo.net>> ?2020?12?26???
> ??5:17???
>
>     On 25.12.20 00:35, ??? wrote:
>>     @David von Oheimb <mailto:dev at ddvo.net> I will update to a new
>>     version and try again.
>
>     Good. Ideally try also a current 3.0.0 alpha release because there
>     have been some changes to cert chain building and verification
>     recently.
>
>>     To append cert is to make sure new cert and old cert both exist
>>     in trust store, thus when server switches cert, it can be trusted
>>     by client.
>     Understood, but my point was on a different aspect:
>     The chain building will take the first matching cert, so if you
>     want to prefer the new cert, it must be in the list *before* the
>     old one -
>     in other words, prepend the new cert to the list rather than
>     appending to it.
>
>>     @Jochen actually, the certs have different SN, which indeed is
>>     not consistent with the man doc
>
>     Different certs with the same issuer indeed *must* have different
>     SNs (except in the special case I mention below).
>     See also RFC 5280 section 4.1.2.2
>     https://tools.ietf.org/html/rfc5280#section-4.1.2.2:
>
>       It MUST be unique for each certificate issued by a given CA
>          (i.e., the issuer name and serial number identify a unique certificate). 
>
>
>     Yet there is a different inconsistency in what you write:
>
>>     The thing that confuses me is that CURL (compiled with gnutls)
>>     and Golang works.
>>     below is my ca.crt file, I am not sure where it went wrong, maybe
>>     just my wrong behavior?
>     You refer to them as CA certs, but they are not: they do no have a
>     basicConstraints field with the cA bit set.
>     And as far as I understand your scenario, they are not used to
>     issue other certs but by some (TLS) server,
>     so they really are end-entity (EE) certs, not CA certs, and it
>     looks like this is correct in your application scenario.
>
>     Directly trusted self-issued EE certs (which may be self-signed or
>     not) are a special situation.
>     This has been clarified in RFC 6818 (which updates RFC 5280)
>     https://tools.ietf.org/html/rfc6818#section-2:
>
>     | Consistent with Section 3.4.61 <https://tools.ietf.org/html/rfc6818#section-3.4.61> of X.509 (11/2008) [X.509 <https://tools.ietf.org/html/rfc6818#ref-X.509>], we note
>     | that use of self-issued certificates and self-signed certificates
>     | issued by entities other than CAs are outside the scope of this
>     | specification.  Thus, for example, a web server or client might
>     | generate a self-signed certificate to identify itself.  These
>     | certificates and how a relying party uses them to authenticate
>     | asserted identities are both outside the scope of RFC 5280 <https://tools.ietf.org/html/rfc5280>.
>
>     So the path building and verification, as well as other checks
>     defined RFC 5280, does not apply to them at all!
>     They are essentially just a convenient container for a public key,
>     where it is optional to check expiration etc.
>
>
>     Unfortunately, when using such certs for TLS connections etc.,
>     still verification is done on them, which may fail.
>     After renaming your ca.crt file to ee.crt for clarity and
>     extracting the first cert in ee1.crt and the second one in ee2.crt,
>     when verifying these directly trusted certs one gets the problem
>     you reported:
>
>     openssl verify -x509_strict -trusted ee.crt ee1.crt
>     ee1.crt: OK
>
>     openssl verify -x509_strict -trusted ee.crt ee2.crt
>     C = US, ST = CA, L = Palo Alto, O = VMware, CN =
>     nsxmanager.pks.vmware.local
>     error 18 at 0 depth lookup: self signed certificate
>     error ee2.crt: verification failed
>
>     So as I wrote before, unfortunately the path building picks up the
>     first matching cert from ee.crt,
>     which is the one in ee1.crt (i.e., your old one), and does not try
>     the second one (i.e., your new one).
>     This happens also with the latest OpenSSL pre-3.0.0 master.
>
>
>     A solution is to add both the subjectKeyIdentifier and
>     authorityKeyIdentifier extensions to your certs,
>     for instance like this:
>
>     echo >ee.cnf "
>     prompt = no
>     distinguished_name = my_server
>     x509_extensions = my_exts
>     [my_server]
>     commonName = test
>     [my_exts]
>     basicConstraints = CA:false
>     subjectKeyIdentifier=hash
>     authorityKeyIdentifier = keyid"
>
>     openssl req -config ee.cnf -new -x509 -out ee1.crt -nodes -keyout
>     ee1.pem
>     openssl req -config ee.cnf -new -x509 -out ee2.crt -nodes -keyout
>     ee2.pem
>     cat ee1.crt ee2.crt >ee.crt
>
>     The subjectKeyIdentifier and authorityKeyIdentifier extensions are
>     generally recommend
>     (and actually required to add for certs that are RFC 5280 compliant)
>     because they help for correct chain building, and indeed also in
>     this case they do:
>
>     openssl verify -x509_strict -trusted ee.crt ee1.crt
>     ee1.crt: OK
>     openssl verify -x509_strict -trusted ee.crt ee2.crt
>     ee2.crt: OK
>
>     Regards,
>
>     ??? David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210101/09e2d3c4/attachment-0001.html>

From pkudingping at gmail.com  Sat Jan  2 06:53:56 2021
From: pkudingping at gmail.com (=?UTF-8?B?5a6a5bmz6KKB?=)
Date: Sat, 2 Jan 2021 14:53:56 +0800
Subject: Directly trusted self-issued end-entity certs - Re: How to rotate
 cert when only first matching cert been verified
In-Reply-To: <fa231f04-7e10-f87e-8a31-7971ab0f6b93@ddvo.net>
References: <mailman.161.1608764215.20353.openssl-users@openssl.org>
 <1bc0d4a9-7a71-1cd6-5d85-ea4e9e70bda4@binect.de>
 <CABYODQ9r0NhEoh=ANJXyZn1o1-SudeAEarCxPQWWBcga=4iCtA@mail.gmail.com>
 <47058390-b956-16d4-f15f-c839e4272f9d@ddvo.net>
 <CABYODQ9qnvoH3pBdZYAs9WUXKTY3Hw4AWajeXBQ_okctGJvcRQ@mail.gmail.com>
 <fa231f04-7e10-f87e-8a31-7971ab0f6b93@ddvo.net>
Message-ID: <CABYODQ-m5EX7NS0Y2mqk78yy2OmbsyASeeC+Pk31bShsHvYeyQ@mail.gmail.com>

@Michael Wojcik <Michael.Wojcik at microfocus.com>
Thanks for your reply! It makes sense more that you said, the RFC pages are
indeed hard to read...

@David von Oheimb <dev at ddvo.net>
thanks for the clarification! Sorry for my misunderstanding, also thanks
for your fix, I will follow up on that too.

BTW,  OpenSSL is such a friendly community.

Regards,
Dingping

David von Oheimb <dev at ddvo.net> ?2021?1?2??? ??5:17???

> On 01.01.21 08:07, ??? wrote:
>
> @David von Oheimb <dev at ddvo.net>
> Thank you so much for your deep investigation!
>
> My pleasure!
>
> With subjectKeyIdentifier and authorityKeyIdentifier extensions, it works
> like a charm!
>
> Good to hear.
> I've meanwhile submitted a pull request that fixed the behavior also  in
> case no SKID and AKID are included in the certs
> and briefly mentioned your use case there:
> https://github.com/openssl/openssl/pull/13748
>
> So, the former statements I found on this page
> <https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_load_verify_locations.html>
> only applies to CA cert, not EE cert.
> How to pick up cert from trust store(or cert container as you say)
> is decided by different implementation themselves, do I understand
> correctly?
>
> It looks like my explanations were a bit mistakable.
> Although self-signed (and more generally, self-issued) EE certs are out of
> scope of RFC 5280, OpenSSL still tries to build a cert chain for them and
> then to verify it.
> Please also note that I did not write "cert container", but that these
> certs are essentially just a convenient container *for a public key*.
> In other words, they have the *format* of an X.509 certificate, but the
> only thing that really matters in such a cert is the public key.
> Yet since they look like a certificate, they can be used where a
> certificate is expected, e.g., in TLS handshake and in trust stores.
>
> Since GnuTls and golang could pick up the right cert in this kind of
> scenario,
> they must implement their own logic to pick up the right cert, do you
> think OpenSSL
> will implement this logic too? Or it's a more appropriate approach to just
> use the extensions you suggested?
>
> With the fix mentioned above, chain building and verification will always
> succeed,
> regardless how the cert looks like because in this case it is sufficient
> to find the target certificate in the trust store,
> without having to check and further data that may be included in it.
> Although not required by RFC 5280 for such a cert, OpenSSL does check for
> its expiration
> (and may check policy restrictions etc.) because this is helpful in most
> application scenarios.
>
> Regards,
>
>     David
>
>
> David von Oheimb <dev at ddvo.net> ?2020?12?26??? ??5:17???
>
>> On 25.12.20 00:35, ??? wrote:
>>
>> @David von Oheimb <dev at ddvo.net> I will update to a new version and try
>> again.
>>
>> Good. Ideally try also a current 3.0.0 alpha release because there have
>> been some changes to cert chain building and verification recently.
>>
>> To append cert is to make sure new cert and old cert both exist in trust
>> store, thus when server switches cert, it can be trusted by client.
>>
>> Understood, but my point was on a different aspect:
>> The chain building will take the first matching cert, so if you want to
>> prefer the new cert, it must be in the list *before* the old one -
>> in other words, prepend the new cert to the list rather than appending to
>> it.
>>
>> @Jochen actually, the certs have different SN, which indeed is not
>> consistent with the man doc
>>
>> Different certs with the same issuer indeed *must* have different SNs
>> (except in the special case I mention below).
>> See also RFC 5280 section 4.1.2.2
>> https://tools.ietf.org/html/rfc5280#section-4.1.2.2:
>>
>>   It MUST be unique for each certificate issued by a given CA
>>      (i.e., the issuer name and serial number identify a unique certificate).
>>
>>
>> Yet there is a different inconsistency in what you write:
>>
>> The thing that confuses me is that CURL (compiled with gnutls) and Golang
>> works.
>> below is my ca.crt file, I am not sure where it went wrong, maybe just my
>> wrong behavior?
>>
>> You refer to them as CA certs, but they are not: they do no have a
>> basicConstraints field with the cA bit set.
>> And as far as I understand your scenario, they are not used to issue
>> other certs but by some (TLS) server,
>> so they really are end-entity (EE) certs, not CA certs, and it looks like
>> this is correct in your application scenario.
>>
>> Directly trusted self-issued EE certs (which may be self-signed or not)
>> are a special situation.
>> This has been clarified in RFC 6818 (which updates RFC 5280)
>> https://tools.ietf.org/html/rfc6818#section-2:
>>
>> | Consistent with Section 3.4.61 <https://tools.ietf.org/html/rfc6818#section-3.4.61> of X.509 (11/2008) [X.509 <https://tools.ietf.org/html/rfc6818#ref-X.509>], we note
>> | that use of self-issued certificates and self-signed certificates
>> | issued by entities other than CAs are outside the scope of this
>> | specification.  Thus, for example, a web server or client might
>> | generate a self-signed certificate to identify itself.  These
>> | certificates and how a relying party uses them to authenticate
>> | asserted identities are both outside the scope of RFC 5280 <https://tools.ietf.org/html/rfc5280>.
>>
>> So the path building and verification, as well as other checks defined
>> RFC 5280, does not apply to them at all!
>> They are essentially just a convenient container for a public key, where
>> it is optional to check expiration etc.
>>
>>
>> Unfortunately, when using such certs for TLS connections etc., still
>> verification is done on them, which may fail.
>> After renaming your ca.crt file to ee.crt for clarity and extracting the
>> first cert in ee1.crt and the second one in ee2.crt,
>> when verifying these directly trusted certs one gets the problem you
>> reported:
>>
>> openssl verify -x509_strict -trusted ee.crt ee1.crt
>> ee1.crt: OK
>>
>> openssl verify -x509_strict -trusted ee.crt ee2.crt
>> C = US, ST = CA, L = Palo Alto, O = VMware, CN =
>> nsxmanager.pks.vmware.local
>> error 18 at 0 depth lookup: self signed certificate
>> error ee2.crt: verification failed
>>
>> So as I wrote before, unfortunately the path building picks up the first
>> matching cert from ee.crt,
>> which is the one in ee1.crt (i.e., your old one), and does not try the
>> second one (i.e., your new one).
>> This happens also with the latest OpenSSL pre-3.0.0 master.
>>
>>
>> A solution is to add both the subjectKeyIdentifier and
>> authorityKeyIdentifier extensions to your certs,
>> for instance like this:
>>
>> echo >ee.cnf "
>> prompt = no
>> distinguished_name = my_server
>> x509_extensions = my_exts
>> [my_server]
>> commonName = test
>> [my_exts]
>> basicConstraints = CA:false
>> subjectKeyIdentifier=hash
>> authorityKeyIdentifier = keyid"
>>
>> openssl req -config ee.cnf -new -x509 -out ee1.crt -nodes -keyout ee1.pem
>> openssl req -config ee.cnf -new -x509 -out ee2.crt -nodes -keyout ee2.pem
>> cat ee1.crt ee2.crt >ee.crt
>>
>> The subjectKeyIdentifier and authorityKeyIdentifier extensions are
>> generally recommend
>> (and actually required to add for certs that are RFC 5280 compliant)
>> because they help for correct chain building, and indeed also in this
>> case they do:
>>
>> openssl verify -x509_strict -trusted ee.crt ee1.crt
>> ee1.crt: OK
>> openssl verify -x509_strict -trusted ee.crt ee2.crt
>> ee2.crt: OK
>>
>> Regards,
>>
>>     David
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210102/e3997099/attachment.html>

From andrew1193 at aim.com  Tue Jan  5 00:42:27 2021
From: andrew1193 at aim.com (Andrew)
Date: Mon, 4 Jan 2021 19:42:27 -0500
Subject: URI with commas in crlDistributionPoints
References: <d26c1eea-954d-7a60-3ae6-52748f5fcdd1.ref@aim.com>
Message-ID: <d26c1eea-954d-7a60-3ae6-52748f5fcdd1@aim.com>

I'm following a procedure for generating an offline CA for use with Microsoft
Active Directory Certificate Services for my own internal use, with instructions
available here:

https://www.altaro.com/hyper-v/wsl-offline-root-certificate-authority-windows-pki/

I am, however, using a different computer with OpenSSL 1.1.1i for root CA key
generation and intermediate CA signing, not WSL.

I'm trying to sign the intermediate certificate, but I get this error:

$ openssl ca -batch -in subca.req -extensions v3_subca -config ca.conf

Using configuration from ca.conf
Error Loading extension section v3_subca
4583112192:error:22075075:X509 V3 routines:v2i_GENERAL_NAME_ex:unsupported 
option:crypto/x509v3/v3_alt.c:548:name=crlDistributionPoints
4583112192:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in 
extension:crypto/x509v3/v3_conf.c:47:name=crlDistributionPoints, value=@crl_section

This is the contents of ca.conf. I have removed the full pathnames in
[ CA_default ] and my actual domain for privacy:

---------------
rootcaname=Domain Root Certification Authority

rootcaissuerssite=ldap:///CN=Domain Root Certification 
Authority,CN=Certification Authorities,CN=Public Key 
Services,CN=Services,CN=Configuration,DC=ad,DC=domain,DC=local?cACertificate

rootcrldistributionpoint=ldap:///CN=Domain Root Certification 
Authority,CN=DC,CN=CDP,CN=Public Key 
Services,CN=Services,CN=Configuration,DC=ad,DC=domain,DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint

[ ca ]
default_ca = CA_default

[ CA_default ]
dir = /ca
certs = /ca/certs
crl_dir = /ca/crl
database = /ca/index.txt
new_certs_dir = /ca/certs
certificate = /ca/ca.crt
serial = /ca/serial
crlnumber = /ca/crlnumber
crl = /ca/crl/$rootcaname.crl
crl_extensions = crl_ext
private_key = /ca/ca.key
#RANDFILE = /ca/.rand
name_opt = ca_default
cert_opt = ca_default
default_days = 1825
default_crl_days = 365
default_md = sha256
preserve = no
policy = policy_match
email_in_dn = no
rand_serial = yes

[ policy_match ]
commonName = supplied

[ req ]
default_bits = 3072
distinguished_name = req_distinguished_name
x509_extensions = v3_ca
string_mask = utf8only

[ req_distinguished_name ]
commonName = Domain Intermediate Certification Authority
commonName_max = 64

[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
basicConstraints=critical,CA:true
keyUsage=critical,digitalSignature,cRLSign,keyCertSign

[ v3_subca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
basicConstraints=critical,CA:true
keyUsage=critical,digitalSignature,cRLSign,keyCertSign
authorityInfoAccess = @v3_root_aia
crlDistributionPoints = @crl_section

[ v3_root_aia ]
caIssuers;URI=$rootcaissuerssite
#OCSP;URI=$rootocspsite

[ crl_ext ]
authorityKeyIdentifier=keyid:always
issuerAltName=issuer:copy

[crl_section]
crlDistributionPoints = URI:$rootcrldistributionpoint
---------------

I think the problem is with the commas in the URI I want to use for 
crlDistributionPoints:

ldap:///CN=Domain Root Certification Authority,CN=DC,CN=CDP,CN=Public Key 
Services,CN=Services,CN=Configuration,DC=ad,DC=domain,DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint

How can I properly include this URI in the certificate?

Thanks!

From whippet0 at gmail.com  Tue Jan  5 06:39:36 2021
From: whippet0 at gmail.com (George)
Date: Tue, 5 Jan 2021 01:39:36 -0500
Subject: private key not available for client_cert_cb
In-Reply-To: <471b029c-420c-e45e-d827-ba0576f22847@nikhef.nl>
References: <292d3b25-9197-4977-a406-0a19abc15a0d@gmail.com>
 <bfd6c62b-a628-a59c-5980-07468b47775b@nikhef.nl>
 <ea3444ef-17d8-7c6d-d448-a42776cd8509@gmail.com>
 <BN8PR18MB2692D804F062DDDCA66D3D24F9C70@BN8PR18MB2692.namprd18.prod.outlook.com>
 <57a1488f-cc91-4c3a-5cee-4ad6c24565d6@gmail.com>
 <BN8PR18MB269202BE32C14ACB482E015DF9C70@BN8PR18MB2692.namprd18.prod.outlook.com>
 <7a3428c6-04ab-672e-b738-67680f9fc036@gmail.com>
 <e015a686-88b2-e483-a7da-53e9efabd9fc@nikhef.nl>
 <30032dde-70d1-d438-86ae-77f04a8179cf@gmail.com>
 <2495b1de-13d0-8777-56b0-46ac80cd0203@nikhef.nl>
 <5887cae2-1ecb-4081-1ee9-bcf566a88afe@gmail.com>
 <8011726e-0a7a-a753-983d-b89a24e3e225@nikhef.nl>
 <ab55a9e8-8bd3-c353-3922-1cae88349cb8@gmail.com>
 <8038268f-fd47-1ef8-7dec-ce365b0d453e@nikhef.nl>
 <00492ef8-67aa-8848-97fe-65cf2ba3b38f@gmail.com>
 <e8d14828-97aa-a1ee-52e2-36e124978cc6@nikhef.nl>
 <3e6e027f-812a-ea2d-2d2e-435ad52852b1@gmail.com>
 <471b029c-420c-e45e-d827-ba0576f22847@nikhef.nl>
Message-ID: <1b20aba6-b88f-2ee1-af0d-23ae19c0746f@gmail.com>

Hi,

 ??? I was looking at the? code in 
https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c and 
realized I forgot to call ENGINE_ctrl_cmd(...) to setup 
"LOAD_CERT_CTRL". However, when I do this, the callback function is no 
longer being called during the mutual authentication handshake. I'm 
wondering if I have the parameter "cert_info.s_slot_cert_id" incorrectly 
configured. Here is what my code looks like:

    struct
    {
     ?? const char* s_slot_cert_id;
     ?? X509* cert;
    } cert_info;
    *cert_info.s_slot_cert_id =
    "a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45";*
    cert_info.cert = NULL;

    *ENGINE_ctrl_cmd(engine, "LOAD_CERT_CTRL", 0, &cert_info, NULL, 0);*
    *SSL_CTX_use_certificate(sslContext, cert_info.cert);*


I tried manually using LOAD_CERT_CTRL in the openssl shell but I cannot 
seem to get it to work and cannot find any examples of how to use it.? 
Is the syntax for *LOAD_CERT_CTRL* correct? I am 
using***"LOAD_CERT_CTRL:<certificate Object ID>".*

    OpenSSL> engine -vvvv -t dynamic -pre
    "SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll"
    -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre
    "MODULE_PATH:C:\Program Files (x86)\HID
    Global\ActivClient\\acpkcs211.dll" -pre PIN:123456 -pre FORCE_LOGIN
    *-pre
    "LOAD_CERT_CTRL:a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45"

    *(dynamic) Dynamic engine loading support
    [Success]:
    SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll
    [Success]: ID:pkcs11
    [Success]: LIST_ADD:1
    [Success]: LOAD
    [Success]: MODULE_PATH:C:\Program Files (x86)\HID
    Global\ActivClient\\acpkcs211.dll
    [Success]: PIN:123456
    [Success]: FORCE_LOGIN
    *[Failure]:
    LOAD_CERT_CTRL:a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45**
    **4196:error:260AB086:engine routines:ENGINE_ctrl_cmd_string:cmd not
    executable:.\crypto\engine\eng_ctrl.c:316:*
    Loaded: (pkcs11) pkcs11 engine
     ???? [ available ]
     ???? SO_PATH: Specifies the path to the 'pkcs11' engine shared library
     ????????? (input flags): STRING
     ???? MODULE_PATH: Specifies the path to the PKCS#11 module shared
    library
     ????????? (input flags): STRING
     ???? PIN: Specifies the pin code
     ????????? (input flags): STRING
     ???? VERBOSE: Print additional details
     ????????? (input flags): NO_INPUT
     ???? QUIET: Remove additional details
     ????????? (input flags): NO_INPUT
    *LOAD_CERT_CTRL: Get the certificate from card**
    **????????? (input flags): [Internal]*
     ???? INIT_ARGS: Specifies additional initialization arguments to
    the PKCS#11 module
     ????????? (input flags): STRING
     ???? SET_USER_INTERFACE: Set the global user interface (internal)
     ????????? (input flags): [Internal]
     ???? SET_CALLBACK_DATA: Set the global user interface extra data
    (internal)
     ????????? (input flags): [Internal]
     ???? FORCE_LOGIN: Force login to the PKCS#11 module
     ????????? (input flags): NO_INPUT
    OpenSSL>


I'm using the certificate object ID 
"a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45" for 
LOAD_CERT_CTRL. Is this right? (I also tried adding "0:" in front of it 
to indicate slot 0, but that did not work either.

    C:\Program Files\OpenSC Project\OpenSC\tools>pkcs11-tool
    --module="C:\Program Files\HID Global\ActivClient/acpkcs211.dll" -l -O
    Using slot 0 with a present token (0x0)
    .
    .
    .
    Certificate Object; type = X.509 cert
     ? label:????? Card Authentication - PIVKey
    E7F4FBE4644BA647ADDBE261BE596757
     ? subject:??? DN: CN=PIVKey E7F4FBE4644BA647ADDBE261BE596757
    *ID: a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45*




Thanks,
George


On 2020-12-23 6:00 a.m., Jan Just Keijser wrote:
> Hi,
>
> On 20/12/20 09:39, George wrote:
>> Hi,
>>
>> ?? I tried running the "s_client" command and it appears to be working.
>>
>> I guess there must be something wrong in my code.
>
> it is good news that the s_client command is working - it means there 
> is something wrong with your code but you have everything at hand to 
> fix it: download the openssl 1.0.2 tarball / zip file and look for the 
> files
> ? apps/s_client.c
> ? apps/apps.c
>
> that contains all of the code that the 's_client' command uses to make 
> a connection and my bet is that is also does not call ENGINE_init
>> My crash occurs when I call
>>
>>     ENGINE_init(pkey_engine);
>>
>> I notice your code does not call this function.? Is this needed 
>> needed? If so, when/where should it be called?
>>
> tbh,? I don't know - look through the openssl sources to see what it 
> does, exactly.
>
>> What exactly is the definition of "pkey_identifier" in
>>
>>     ENGINE_load_private_key(pkey_engine, *pkey_identifier*,
>>     transfer_pin, &cb_data) ?
>>
>>
>> I'm not clear on what this value should be. Can you give an example 
>> of what it would look like?
>>
>> I have the following on my smart card:
>>
>>     Private Key Object; RSA
>>     ? label:????? Authentication - *
>>     *ID:**2b2586c684d69b670c0a805edf514e720f2b757d8e2faa0b3a7ff23d1ccfc7ba*
>>     ? Usage:????? unwrap
>>     ? Access:???? sensitive, never extractable
>>     ? Allowed mechanisms: RSA-PKCS,RSA-X-509
>>
>>
>> Would the *pkey_identifier* be the *ID* in the above?
>>
> yes, although if you have multiple smartcards inserted at the same 
> time then it helps to add the slot number, e.g.
> ? 0:<ID>
>
>
>>
>> What exactly is "prompt_info" in the structure PW_CB_DATA?
>> i.e.
>> typedef struct pw_cb_data {
>> ??? const void* password;
>> ??? const char* *prompt_info;*
>> } PW_CB_DATA;
>> Can you give an example of what it might look like?
>>
>> Is the value of cb_data populated by the transfer_pin callback 
>> functions, or should it already contain a value when 
>> ENGINE_load_private_key is called?
>>
>> Is there a way to skip the callback transfer_pin and use a hard coded 
>> pin for test purposes when calling ENGINE_load_private_key(...)?
>>
> my eap-tls code does just that: if the password is specified in the 
> ppp config file then the user is not prompted:
>
> ??? if (pkey_engine)
> ??? {
> ??????? EVP_PKEY?? *pkey = NULL;
> ??????? PW_CB_DATA? cb_data;
> ??????? UI_METHOD* transfer_pin = NULL;
>
> ??????? cb_data.password = passwd;
> ??????? cb_data.prompt_info = pkey_identifier;
>
>
> HTH,
>
> JJK
>>
>> On 2020-12-19 8:05 p.m., Jan Just Keijser wrote:
>>>
>>> I'd say no engine/pkcs11 module should trigger exceptions - that's 
>>> an error in the pkcs11 module.
>>>
>>> Something you can try is this:
>>>
>>> run the 'openssl.exe' command:
>>>
>>> openssl engine -t dynamic -pre 
>>> "SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll" 
>>> -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre 
>>> "MODULE_PATH:C:\Program Files (x86)\HID 
>>> Global\ActivClient\\acpkcs211.dll"
>>>
>>> then on the OpenSSL prompt , try
>>>
>>> ? s_client -keyform engine -key 0:<key-id>? -cert "clientcert.pem"? 
>>> -connect remote_host:remote_port
>>>
>>> that should start a TLS connection and use the pcks11 engine to ask 
>>> for the key , identified by <key-id> in slot 0 (adjust the slot 
>>> number if your smart card starts at number 1 etc.
>>>
>>> HTH,
>>>
>>> JJK
>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210105/a624173a/attachment.html>

From yvasavi at gmail.com  Tue Jan  5 11:41:54 2021
From: yvasavi at gmail.com (y vasavi)
Date: Tue, 5 Jan 2021 17:11:54 +0530
Subject: openssl fips patch for RSA Key Gen (186-4)
Message-ID: <CABkp7nAm_0DirCpf3QdZYkPzw1jyOcU1cKvadeqK54SgbRMzZQ@mail.gmail.com>

Hi All,

We currently FOM 2.0 module for FIPS certification.
It doesn't have support for RSA Key generation(186-4)

Are there any patches available ?

Thanks,
Vasavi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210105/3bc849d3/attachment-0001.html>

From a.chaouche at algerian-radio.dz  Tue Jan  5 12:43:12 2021
From: a.chaouche at algerian-radio.dz (Yassine Chaouche)
Date: Tue, 5 Jan 2021 13:43:12 +0100
Subject: Verify a certificate
Message-ID: <54948e45-a975-ad3a-8529-120dd6185aa5@algerian-radio.dz>

Dear list,

I would like to learn how to use openssl tools to make sure
a chained certificate is valid ?

example :

Let's say I got the Cert certificate signed by Intermdiate
X, but by making the full chain certificate I inadvertly
inserted Intermediate Y instead of X. The (broken)
certificate chain inside Cert would be :

Cert < Intermediate Y < Root X

How do I detect this error with openssl tools ? are there
tools that print issuer and subject of each certificate in
a chain ?

Thanks for your guidance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210105/88f769a9/attachment.html>

From openssl-users at dukhovni.org  Tue Jan  5 12:52:20 2021
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 5 Jan 2021 07:52:20 -0500
Subject: Verify a certificate
In-Reply-To: <54948e45-a975-ad3a-8529-120dd6185aa5@algerian-radio.dz>
References: <54948e45-a975-ad3a-8529-120dd6185aa5@algerian-radio.dz>
Message-ID: <X/RhBNpH9vj9EEgK@straasha.imrryr.org>

On Tue, Jan 05, 2021 at 01:43:12PM +0100, Yassine Chaouche wrote:

> How do I detect this error with openssl tools ? are there
> tools that print issuer and subject of each certificate in
> a chain ?

If, by chain, you mean a PEM file with one or more X509 certificates,
then yes.  Suppose the file is "certs.pem":

    $ openssl crl2pkcs7 -nocrl -certfile certs.pem |
        openssl pkcs7 -print_certs -noout -subject -issuer

If you want to instead verify the chain, against some root CA in some
file (perhaps the very same file, just use certs.pem instead of
roots.pem):

    $ openssl verify -untrusted certs.pem -trusted roots.pem certs.pem

You can also check for the expected hostname with

    $ openssl verify -untrusted certs.pem -trusted roots.pem \
        -verify_hostname www.example.com certs.pem

-- 
    Viktor.

From ted at convey.de  Tue Jan  5 13:11:42 2021
From: ted at convey.de (=?UTF-8?Q?Bernhard_Fr=c3=b6hlich?=)
Date: Tue, 5 Jan 2021 14:11:42 +0100
Subject: Verify a certificate
In-Reply-To: <54948e45-a975-ad3a-8529-120dd6185aa5@algerian-radio.dz>
References: <54948e45-a975-ad3a-8529-120dd6185aa5@algerian-radio.dz>
Message-ID: <ffab4fcb-cb3f-e32d-6778-c262923699b9@convey.de>

Hello,

just in case you want to check a webserver installation (which is not 
explicitly mentioned in Viktor's answer) I want to add this...

In this case (IMHO) the s_client tool of openssl can do what you need. Try

 ??? openssl s_client -connect yourhost.example.org:443 -CAfile 
SpecialCAFile.pem

where "SpecialCAFile.pem" only contains the root certificate of your 
"Root X" CA. This gives quite a bit of text as output. Look for a line 
"Verification: OK" in this output (usually after the PEM-encoded server 
certificate), if you can find it the certificate chain should be OK. 
Otherwise you'll find something like "Verification error: unable to get 
local issuer certificate"

Hope this helps,
Ted
;)

On 2021-01-05 13:43, Yassine Chaouche wrote:
> Dear list,
>
> I would like to learn how to use openssl tools to make sure
> a chained certificate is valid ?
>
> example :
>
> Let's say I got the Cert certificate signed by Intermdiate
> X, but by making the full chain certificate I inadvertly
> inserted Intermediate Y instead of X. The (broken)
> certificate chain inside Cert would be :
>
> Cert < Intermediate Y < Root X
>
> How do I detect this error with openssl tools ? are there
> tools that print issuer and subject of each certificate in
> a chain ?
>
> Thanks for your guidance.



From matt at openssl.org  Tue Jan  5 16:34:36 2021
From: matt at openssl.org (Matt Caswell)
Date: Tue, 5 Jan 2021 16:34:36 +0000
Subject: openssl fips patch for RSA Key Gen (186-4)
In-Reply-To: <CABkp7nAm_0DirCpf3QdZYkPzw1jyOcU1cKvadeqK54SgbRMzZQ@mail.gmail.com>
References: <CABkp7nAm_0DirCpf3QdZYkPzw1jyOcU1cKvadeqK54SgbRMzZQ@mail.gmail.com>
Message-ID: <9e83f3d1-cb4d-5dd2-c4d1-3487886440b5@openssl.org>



On 05/01/2021 11:41, y vasavi wrote:
> 
> Hi All,
> 
> We currently FOM 2.0 module for FIPS certification.
> It doesn't have support for RSA Key generation(186-4)
> 
> Are there any patches available ?

Definitely there are no official ones (I'm also not aware of any
unofficial ones).

The 3.0 module which will be part of OpenSSL 3.0 when it is released
supports 186-4 RSA Key gen.

Matt



> 
> Thanks,
> Vasavi.

From janjust at nikhef.nl  Tue Jan  5 16:51:02 2021
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Tue, 5 Jan 2021 17:51:02 +0100
Subject: private key not available for client_cert_cb
In-Reply-To: <1b20aba6-b88f-2ee1-af0d-23ae19c0746f@gmail.com>
References: <292d3b25-9197-4977-a406-0a19abc15a0d@gmail.com>
 <ea3444ef-17d8-7c6d-d448-a42776cd8509@gmail.com>
 <BN8PR18MB2692D804F062DDDCA66D3D24F9C70@BN8PR18MB2692.namprd18.prod.outlook.com>
 <57a1488f-cc91-4c3a-5cee-4ad6c24565d6@gmail.com>
 <BN8PR18MB269202BE32C14ACB482E015DF9C70@BN8PR18MB2692.namprd18.prod.outlook.com>
 <7a3428c6-04ab-672e-b738-67680f9fc036@gmail.com>
 <e015a686-88b2-e483-a7da-53e9efabd9fc@nikhef.nl>
 <30032dde-70d1-d438-86ae-77f04a8179cf@gmail.com>
 <2495b1de-13d0-8777-56b0-46ac80cd0203@nikhef.nl>
 <5887cae2-1ecb-4081-1ee9-bcf566a88afe@gmail.com>
 <8011726e-0a7a-a753-983d-b89a24e3e225@nikhef.nl>
 <ab55a9e8-8bd3-c353-3922-1cae88349cb8@gmail.com>
 <8038268f-fd47-1ef8-7dec-ce365b0d453e@nikhef.nl>
 <00492ef8-67aa-8848-97fe-65cf2ba3b38f@gmail.com>
 <e8d14828-97aa-a1ee-52e2-36e124978cc6@nikhef.nl>
 <3e6e027f-812a-ea2d-2d2e-435ad52852b1@gmail.com>
 <471b029c-420c-e45e-d827-ba0576f22847@nikhef.nl>
 <1b20aba6-b88f-2ee1-af0d-23ae19c0746f@gmail.com>
Message-ID: <640febc7-2499-2284-6625-b7a899ad66ea@nikhef.nl>

Hi,

On 05/01/21 07:39, George wrote:
> Hi,
>
> ??? I was looking at the? code in 
> https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c and 
> realized I forgot to call ENGINE_ctrl_cmd(...) to setup 
> "LOAD_CERT_CTRL". However, when I do this, the callback function is no 
> longer being called during the mutual authentication handshake. I'm 
> wondering if I have the parameter "cert_info.s_slot_cert_id" 
> incorrectly configured. Here is what my code looks like:
>
>     struct
>     {
>     ?? const char* s_slot_cert_id;
>     ?? X509* cert;
>     } cert_info;
>     *cert_info.s_slot_cert_id =
>     "a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45";*
>     cert_info.cert = NULL;
>
>     *ENGINE_ctrl_cmd(engine, "LOAD_CERT_CTRL", 0, &cert_info, NULL, 0);*
>     *SSL_CTX_use_certificate(sslContext, cert_info.cert);*
>
>
> I tried manually using LOAD_CERT_CTRL in the openssl shell but I 
> cannot seem to get it to work and cannot find any examples of how to 
> use it.? Is the syntax for *LOAD_CERT_CTRL* correct? I am 
> using***"LOAD_CERT_CTRL:<certificate Object ID>".*
>
>     OpenSSL> engine -vvvv -t dynamic -pre
>     "SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll"
>     -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre
>     "MODULE_PATH:C:\Program Files (x86)\HID
>     Global\ActivClient\\acpkcs211.dll" -pre PIN:123456 -pre
>     FORCE_LOGIN *-pre
>     "LOAD_CERT_CTRL:a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45"
>
>     *(dynamic) Dynamic engine loading support
>     [Success]:
>     SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll
>     [Success]: ID:pkcs11
>     [Success]: LIST_ADD:1
>     [Success]: LOAD
>     [Success]: MODULE_PATH:C:\Program Files (x86)\HID
>     Global\ActivClient\\acpkcs211.dll
>     [Success]: PIN:123456
>     [Success]: FORCE_LOGIN
>     *[Failure]:
>     LOAD_CERT_CTRL:a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45**
>     **4196:error:260AB086:engine routines:ENGINE_ctrl_cmd_string:cmd
>     not executable:.\crypto\engine\eng_ctrl.c:316:*
>     Loaded: (pkcs11) pkcs11 engine
>     ???? [ available ]
>     ???? SO_PATH: Specifies the path to the 'pkcs11' engine shared library
>     ????????? (input flags): STRING
>     ???? MODULE_PATH: Specifies the path to the PKCS#11 module shared
>     library
>     ????????? (input flags): STRING
>     ???? PIN: Specifies the pin code
>     ????????? (input flags): STRING
>     ???? VERBOSE: Print additional details
>     ????????? (input flags): NO_INPUT
>     ???? QUIET: Remove additional details
>     ????????? (input flags): NO_INPUT
>     *LOAD_CERT_CTRL: Get the certificate from card**
>     **????????? (input flags): [Internal]*
>     ???? INIT_ARGS: Specifies additional initialization arguments to
>     the PKCS#11 module
>     ????????? (input flags): STRING
>     ???? SET_USER_INTERFACE: Set the global user interface (internal)
>     ????????? (input flags): [Internal]
>     ???? SET_CALLBACK_DATA: Set the global user interface extra data
>     (internal)
>     ????????? (input flags): [Internal]
>     ???? FORCE_LOGIN: Force login to the PKCS#11 module
>     ????????? (input flags): NO_INPUT
>     OpenSSL>
>
>
> I'm using the certificate object ID 
> "a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45" for 
> LOAD_CERT_CTRL. Is this right? (I also tried adding "0:" in front of 
> it to indicate slot 0, but that did not work either.


this has little to do with OpenSSL at the moment and more with libp11 - 
perhaps someone more knowledgable on the libp11 mailing list can help you.

I'd try to use
 ? -post LOAD_CERT_CTRL
instead of '-pre', as you want this done after the engine has been loaded.

The cert ID does look OK. Note that if you want to use the s_client 
command that you canNOT specify the certificate form '-certform engine' 
as the code does not grok that.

HTH,

JJK

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210105/efd7fb5a/attachment-0001.html>

From meissner at suse.de  Tue Jan  5 16:56:04 2021
From: meissner at suse.de (Marcus Meissner)
Date: Tue, 5 Jan 2021 17:56:04 +0100
Subject: openssl fips patch for RSA Key Gen (186-4)
In-Reply-To: <9e83f3d1-cb4d-5dd2-c4d1-3487886440b5@openssl.org>
References: <CABkp7nAm_0DirCpf3QdZYkPzw1jyOcU1cKvadeqK54SgbRMzZQ@mail.gmail.com>
 <9e83f3d1-cb4d-5dd2-c4d1-3487886440b5@openssl.org>
Message-ID: <20210105165603.GO29806@suse.de>

On Tue, Jan 05, 2021 at 04:34:36PM +0000, Matt Caswell wrote:
> 
> 
> On 05/01/2021 11:41, y vasavi wrote:
> > 
> > Hi All,
> > 
> > We currently FOM 2.0 module for FIPS certification.
> > It doesn't have support for RSA Key generation(186-4)
> > 
> > Are there any patches available ?
> 
> Definitely there are no official ones (I'm also not aware of any
> unofficial ones).

In some vendor FIPS patch sets (e.g. Redhat or SUSE) there are RSA Key
generation methods meeting FIPS 186-4, for 1.0 and 1.1 based openssls.
 
Ciao, Marcus

From Michael.Wojcik at microfocus.com  Tue Jan  5 17:11:58 2021
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 5 Jan 2021 17:11:58 +0000
Subject: openssl fips patch for RSA Key Gen (186-4)
In-Reply-To: <9e83f3d1-cb4d-5dd2-c4d1-3487886440b5@openssl.org>
References: <CABkp7nAm_0DirCpf3QdZYkPzw1jyOcU1cKvadeqK54SgbRMzZQ@mail.gmail.com>
 <9e83f3d1-cb4d-5dd2-c4d1-3487886440b5@openssl.org>
Message-ID: <DM6PR18MB27005188E3391F714B9F5848F9D11@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt
> Caswell
> Sent: Tuesday, 5 January, 2021 09:35
>
> On 05/01/2021 11:41, y vasavi wrote:
> >
> > We currently FOM 2.0 module for FIPS certification.
> > It doesn't have support for RSA Key generation(186-4)
> >
> > Are there any patches available ?
>
> Definitely there are no official ones (I'm also not aware of any
> unofficial ones).

And such a patched module would no longer be FIPS 140 validated.

I know of at least one commercial, proprietary fork of the OpenSSL FOM 2.0 with 186-4 support. It has its own validations, obtained by the vendor. It's part of a commercial software package and not available for use by other software.

If memory serves, SUSE also implemented 186-4 when they ported the FOM 2.0 to OpenSSL 1.1.1. SUSE open-sourced their changes - you can find the diffs on one of the SUSE sites - but again, they had to get a new validation. It applies only to their module when used on SLES. (Red Hat similarly did their own ports and got their own validations for RHEL. I don't know whether they published their changes.)

So it's possible, but as usual with FIPS 140, you have the time and expense of validation. That's even more complicated now than it has been in past years, thanks in part to the transition from FIPS 140-2 to 140-3. I've heard from people with contacts in the CMVP that "the queue is full" for the year, and anyone not already in line will be waiting even longer than usual for a validation.

--
Michael Wojcik


From gimhanieuthpala at gmail.com  Wed Jan  6 17:10:19 2021
From: gimhanieuthpala at gmail.com (Gimhani Uthpala)
Date: Wed, 6 Jan 2021 22:40:19 +0530
Subject: Random and rare Seg faults at openssl library level
Message-ID: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>

Dear team,
I'm running an application which uses openssl for secure communication
between processes. I am getting seg-faults at openssl level. This only
occurred very randomly and the following are stacks that seg faults  at
openssl level in the given 2 cases. We are using openssl 1.0.2k.

Went through the security vulnerabilities list for this version but
couldn't find a clue. Running valgrind too didn't give an exact clue
related to the issue. Can you please guide me how can I find the exact root
cause for the seg fault?

I am calling SSL_do_handshake(ssl_ctx) from my code level and both the
below seg faults are occuring from it's inside.

#0  0x00007fd64cdabdd3 in ASN1_item_verify () from /lib64/libcrypto.so.10
#1  0x00007fd64cdcac58 in internal_verify () from /lib64/libcrypto.so.10
#2  0x00007fd64cdccaef in X509_verify_cert () from /lib64/libcrypto.so.10
#3  0x00007fd64d111c68 in ssl_verify_cert_chain () from /lib64/libssl.so.10
#4  0x00007fd64d0e8cc6 in ssl3_get_client_certificate () from
/lib64/libssl.so.10
*#5  0x00007fd64d0ea3f8 in ssl3_accept () from /lib64/libssl.so.10*


 #0 0x00007ffb65529854 in RSA_verify () from /usr/lib64/libcrypto.so.10
 #1 0x00007ffb6552f1fc in pkey_rsa_verify () from /usr/lib64/libcrypto.so.10
 #2 0x00007ffb65561877 in EVP_DigestVerifyFinal () from
/usr/lib64/libcrypto.so.10
 #3 0x00007ffb6556af25 in ASN1_item_verify () from
/usr/lib64/libcrypto.so.10
 #4 0x00007ffb65589c58 in internal_verify () from /usr/lib64/libcrypto.so.10
 #5 0x00007ffb6558baef in X509_verify_cert () from
/usr/lib64/libcrypto.so.10
 #6 0x00007ffb658d1417 in ssl_add_cert_chain () from /usr/lib64/libssl.so.10
 #7 0x00007ffb658b6095 in ssl3_output_cert_chain () from
/usr/lib64/libssl.so.10
 #8 0x00007ffb658ae894 in ssl3_send_client_certificate () from
/usr/lib64/libssl.so.10

* #9 0x00007ffb658aeecf in ssl3_connect () from /usr/lib64/libssl.so.10 #10
0x00007ffb658b8e7e in ssl23_connect () from /usr/lib64/libssl.so.10*

  I am setting context to use SSLv23_method() s. However, I can see ssl3_
methods being called. Is there any issue with that?

Given below is SSL* object passed to SSL_do_handshake method.

(gdb) p *p_SSLCtx
$2 = {version = 771, type = 4096, method = 0x7ffb65af3320, rbio =
0x7ffb5819e140, wbio = 0x7ffb58193570, bbio = 0x7ffb58193570, rwstate = 1,
in_handshake = 2, *handshake_func = 0x7ffb658aea30 <ssl3_connect>*, server
= 0, new_session = 0, quiet_shutdown = 0, shutdown = 0, state = 4467,
  rstate = 240, init_buf = 0x7ffb581934b0, init_msg = 0x7ffb581e10d4,
init_num = 0, init_off = 0, *packet = 0x7ffb581e6633 "\026\003\003",
packet_length = 0*, s2 = 0x0, s3 = 0x7ffb58195ee0, d1 = 0x0, read_ahead =
0, msg_callback = 0x0, msg_callback_arg = 0x0, hit = 0, param =
0x7ffb581933f0,
  cipher_list = 0x0, cipher_list_by_id = 0x0, mac_flags = 0, enc_read_ctx =
0x0, read_hash = 0x0, expand = 0x0, enc_write_ctx = 0x0, write_hash = 0x0,
compress = 0x0, cert = 0x7ffb58195ba0, sid_ctx_length = 0, sid_ctx = '\000'
<repeats 31 times>, session = 0x7ffb58198100,
  generate_session_id = 0x0,......



-- 
*Gimhani Uthpala Kankanamge*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210106/421fa8e5/attachment.html>

From Michael.Wojcik at microfocus.com  Wed Jan  6 20:57:41 2021
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 6 Jan 2021 20:57:41 +0000
Subject: Random and rare Seg faults at openssl library level
In-Reply-To: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
References: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
Message-ID: <DM6PR18MB2700EABD3C5F9F445D0D69CDF9D09@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Gimhani Uthpala
> Sent: Wednesday, 6 January, 2021 10:10

> I'm running an application which uses openssl for secure communication between
> processes. I am getting seg-faults at openssl level. This only occurred very
> randomly and the following are stacks that seg faults  at openssl level in the
> given 2 cases.

> We are using openssl 1.0.2k.

Sometimes you see a question that nearly answers itself.

You're using a release that's approaching four years old, and which is unsupported, unless you have a premium support contract from openssl.org or similar through another vendor. If you do, that's whom you should ask.

In any case, why are you using 1.0.2k? At the very least you should be using the final 1.0.2 release -- and then only if you absolutely can't move to 1.1.1 (generally because you need FIPS validation, but you don't mention FIPS). And then you need a premium support contract, if this is a commercial product. Particularly these days it's very hard to forgive a commercial-software vendor using an outdated, unsupported third-party component.

The most recent version of 1.0.2 that I happen to have lying around is 1.0.2n, and there's nothing in the changelog between 1.0.2k and 1.0.2n which looks likely to cause this particular problem (though CVE-2017-3735 is a slight contender). But that just means the cause isn't anything obvious between k and n.

> Went through the security vulnerabilities list for this version but couldn't
> find a clue. Running valgrind too didn't give an exact clue related to the issue.
> Can you please guide me how can I find the exact root cause for the seg fault?

The same way you'd track down an intermittent cause of Undefined Behavior in any other program: some combination of dynamic monitoring, symbolic execution, static code analysis, source code review, testing variants, tracing, fuzzing, post-mortem analysis, and so on. This isn't specific to OpenSSL.

But you're asking the wrong question. The correct question is: Why are you using an outdated version of OpenSSL?

--
Michael Wojcik

From tincanteksup at gmail.com  Wed Jan  6 21:10:40 2021
From: tincanteksup at gmail.com (tincanteksup)
Date: Wed, 6 Jan 2021 21:10:40 +0000
Subject: Random and rare Seg faults at openssl library level
In-Reply-To: <DM6PR18MB2700EABD3C5F9F445D0D69CDF9D09@DM6PR18MB2700.namprd18.prod.outlook.com>
References: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
 <DM6PR18MB2700EABD3C5F9F445D0D69CDF9D09@DM6PR18MB2700.namprd18.prod.outlook.com>
Message-ID: <36ad30cc-c7e0-6a4e-0f91-42b598b9b584@gmail.com>



On 06/01/2021 20:57, Michael Wojcik wrote:

> 
> But you're asking the wrong question. The correct question is: Why are you using an outdated version of OpenSSL?
> 
> --
> Michael Wojcik
> 

:whip-crack: !


From kgoldman at us.ibm.com  Wed Jan  6 21:37:36 2021
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Wed, 6 Jan 2021 16:37:36 -0500
Subject: Random and rare Seg faults at openssl library level
In-Reply-To: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
References: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
Message-ID: <5d6e7fe5-c3a6-34ff-b66f-31c54f187ac1@us.ibm.com>

On 1/6/2021 12:10 PM, Gimhani Uthpala wrote:

> I am getting seg-faults at openssl level. This only occurred?very randomly and the following are stacks that seg faults? at openssl level in the given 2 cases. We are using openssl 1.0.2k.

The usual cause is that you are compiling with one version of openssl and (static or dynamic) linking with a different one.
The cause of that is typically that you have more than one version of openssl installed.

If this is a 3rd party application, not one you're building, you have to find out what version of openssl they expect.



From janjust at nikhef.nl  Thu Jan  7 08:21:26 2021
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Thu, 7 Jan 2021 09:21:26 +0100
Subject: Random and rare Seg faults at openssl library level
In-Reply-To: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
References: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
Message-ID: <d90f02e2-fae8-a713-e143-42ba8a8e1c18@nikhef.nl>

Hi,

On 06/01/21 18:10, Gimhani Uthpala wrote:
> Dear team,
> I'm running an application which uses openssl for secure communication 
> between processes. I am getting seg-faults at openssl level. This only 
> occurred?very randomly and the following are stacks that seg faults? 
> at openssl level in the given 2 cases. We are using openssl 1.0.2k.
>
version 1.0.2k suggests you are using RHEL7/CentOS 7, correct?
> Went through the security vulnerabilities list for this version but 
> couldn't find a clue. Running valgrind too didn't give an exact clue 
> related to the issue. Can you please guide me how can I find the exact 
> root cause for the seg fault?
>
> I am calling SSL_do_handshake(ssl_ctx) from my code level and both the 
> below seg faults are occuring from it's inside.
>
> #0 ?0x00007fd64cdabdd3 in ASN1_item_verify () from /lib64/libcrypto.so.10
> #1 ?0x00007fd64cdcac58 in internal_verify () from /lib64/libcrypto.so.10
> #2 ?0x00007fd64cdccaef in X509_verify_cert () from /lib64/libcrypto.so.10
> #3 ?0x00007fd64d111c68 in ssl_verify_cert_chain () from 
> /lib64/libssl.so.10
> #4 ?0x00007fd64d0e8cc6 in ssl3_get_client_certificate () from 
> /lib64/libssl.so.10
> *#5 ?0x00007fd64d0ea3f8 in ssl3_accept () from /lib64/libssl.so.10*
>
>
so the segfault occurs inside ASN1_item_verify () when verifying the 
certificate - it could be a malformed certificate with invalid ASN1 
encoding; do you have the certificate that causes the segfault?

If you do not, then it is worthwhile recording/storing all certificates 
until you find the one that causes the segfault and then examine it.


HTH,

JJK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210107/c3cbe3b7/attachment.html>

From janjust at nikhef.nl  Thu Jan  7 08:22:51 2021
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Thu, 7 Jan 2021 09:22:51 +0100
Subject: Random and rare Seg faults at openssl library level
In-Reply-To: <DM6PR18MB2700EABD3C5F9F445D0D69CDF9D09@DM6PR18MB2700.namprd18.prod.outlook.com>
References: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
 <DM6PR18MB2700EABD3C5F9F445D0D69CDF9D09@DM6PR18MB2700.namprd18.prod.outlook.com>
Message-ID: <38c4bb35-437e-04dc-4139-d4a826b71ac5@nikhef.nl>

On 06/01/21 21:57, Michael Wojcik wrote:
>
> The same way you'd track down an intermittent cause of Undefined Behavior in any other program: some combination of dynamic monitoring, symbolic execution, static code analysis, source code review, testing variants, tracing, fuzzing, post-mortem analysis, and so on. This isn't specific to OpenSSL.
>
> But you're asking the wrong question. The correct question is: Why are you using an outdated version of OpenSSL?

possibly because:

$ cat /etc/redhat-release && openssl version
CentOS Linux release 7.9.2009 (Core)
OpenSSL 1.0.2k-fips? 26 Jan 2017

?



From john.wasilewski at gmail.com  Thu Jan  7 08:24:31 2021
From: john.wasilewski at gmail.com (John Wasilewski)
Date: Thu, 7 Jan 2021 03:24:31 -0500
Subject: Random and rare Seg faults at openssl library level
In-Reply-To: <38c4bb35-437e-04dc-4139-d4a826b71ac5@nikhef.nl>
References: <38c4bb35-437e-04dc-4139-d4a826b71ac5@nikhef.nl>
Message-ID: <6E4BAC50-403B-440A-8AA8-292A616AE167@gmail.com>

Please remove my email

> On Jan 7, 2021, at 3:23 AM, Jan Just Keijser <janjust at nikhef.nl> wrote:
> 
> ?On 06/01/21 21:57, Michael Wojcik wrote:
>> 
>> The same way you'd track down an intermittent cause of Undefined Behavior in any other program: some combination of dynamic monitoring, symbolic execution, static code analysis, source code review, testing variants, tracing, fuzzing, post-mortem analysis, and so on. This isn't specific to OpenSSL.
>> 
>> But you're asking the wrong question. The correct question is: Why are you using an outdated version of OpenSSL?
> 
> possibly because:
> 
> $ cat /etc/redhat-release && openssl version
> CentOS Linux release 7.9.2009 (Core)
> OpenSSL 1.0.2k-fips  26 Jan 2017
> 
> ?
> 
> 

From matt at openssl.org  Thu Jan  7 08:48:05 2021
From: matt at openssl.org (Matt Caswell)
Date: Thu, 7 Jan 2021 08:48:05 +0000
Subject: Random and rare Seg faults at openssl library level
In-Reply-To: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
References: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
Message-ID: <f3f34617-a116-03ed-927a-5e4d2b419723@openssl.org>



On 06/01/2021 17:10, Gimhani Uthpala wrote:
> ? I am setting context to use SSLv23_method() s. However, I can see
> ssl3_ methods being called. Is there any issue with that???

Just answering this one side question: no, this is normal behaviour.

Matt


From openssl at openssl.org  Thu Jan  7 14:08:05 2021
From: openssl at openssl.org (OpenSSL)
Date: Thu, 7 Jan 2021 14:08:05 +0000
Subject: OpenSSL version 3.0.0-alpha10 published
Message-ID: <20210107140805.GA26451@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 3.0 alpha 10 released
   =====================================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   OpenSSL 3.0 is currently in alpha.

   OpenSSL 3.0 alpha 10 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-alpha10.tar.gz
      Size: 14084047
      SHA1 checksum:  dfeb99f9bdb270d11f723039d07fda1478a31219
      SHA256 checksum:  b1699acf2148db31f12edf5ebfdf12a92bfd3f0e60538d169710408a3cd3b138

   The checksums were calculated using the following commands:

    openssl sha1 openssl-3.0.0-alpha10.tar.gz
    openssl sha256 openssl-3.0.0-alpha10.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-----

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl/3ESsACgkQ2cTSbQ5g
RJErmQgAj74iDsxOIigH87UxtnKLUqZc7ewbyZxM41XK52G/OPAzqSzGlMxhsYit
gvN7k+4qHWGuzyP5UGoTnxued/eG3tggUJh/WeuTmZ8DdrdV4C8Mhfb9ZkocDZZj
/wCnVGfb4xS5SPVnHU0qqtn0bWrltddjvdAzmuKvzQmyhftH6d/+VyUA9b9oUTkr
ygAvJYI6sJ/WBBSbRzONhwO16GKiLi5AzpPTuW9z7ZJS3YdZCCFFCYKPO255To9y
1GgxhGns9VksvN6NR3AFeTKMQyet3Uo2tRmigtRYZvaJDCE4am40zSuhdFmujwMA
HFVox7b+u1PJrUdxzOGJe+A+1I0R9A==
=yDQs
-----END PGP SIGNATURE-----

From john.wasilewski at gmail.com  Thu Jan  7 14:23:15 2021
From: john.wasilewski at gmail.com (John Wasilewski)
Date: Thu, 7 Jan 2021 09:23:15 -0500
Subject: OpenSSL version 3.0.0-alpha10 published
In-Reply-To: <20210107140805.GA26451@openssl.org>
References: <20210107140805.GA26451@openssl.org>
Message-ID: <5754479C-0E60-4CE6-AE1F-5BAA56A82086@gmail.com>

Please remove my email from your distribution

> On Jan 7, 2021, at 9:08 AM, OpenSSL <openssl at openssl.org> wrote:
> 
> ?-----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> 
>   OpenSSL version 3.0 alpha 10 released
>   =====================================
> 
>   OpenSSL - The Open Source toolkit for SSL/TLS
>   https://www.openssl.org/
> 
>   OpenSSL 3.0 is currently in alpha.
> 
>   OpenSSL 3.0 alpha 10 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-alpha10.tar.gz
>      Size: 14084047
>      SHA1 checksum:  dfeb99f9bdb270d11f723039d07fda1478a31219
>      SHA256 checksum:  b1699acf2148db31f12edf5ebfdf12a92bfd3f0e60538d169710408a3cd3b138
> 
>   The checksums were calculated using the following commands:
> 
>    openssl sha1 openssl-3.0.0-alpha10.tar.gz
>    openssl sha256 openssl-3.0.0-alpha10.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-----
> 
> iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl/3ESsACgkQ2cTSbQ5g
> RJErmQgAj74iDsxOIigH87UxtnKLUqZc7ewbyZxM41XK52G/OPAzqSzGlMxhsYit
> gvN7k+4qHWGuzyP5UGoTnxued/eG3tggUJh/WeuTmZ8DdrdV4C8Mhfb9ZkocDZZj
> /wCnVGfb4xS5SPVnHU0qqtn0bWrltddjvdAzmuKvzQmyhftH6d/+VyUA9b9oUTkr
> ygAvJYI6sJ/WBBSbRzONhwO16GKiLi5AzpPTuW9z7ZJS3YdZCCFFCYKPO255To9y
> 1GgxhGns9VksvN6NR3AFeTKMQyet3Uo2tRmigtRYZvaJDCE4am40zSuhdFmujwMA
> HFVox7b+u1PJrUdxzOGJe+A+1I0R9A==
> =yDQs
> -----END PGP SIGNATURE-----

From Michael.Wojcik at microfocus.com  Thu Jan  7 15:11:05 2021
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 7 Jan 2021 15:11:05 +0000
Subject: Random and rare Seg faults at openssl library level
In-Reply-To: <38c4bb35-437e-04dc-4139-d4a826b71ac5@nikhef.nl>
References: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
 <DM6PR18MB2700EABD3C5F9F445D0D69CDF9D09@DM6PR18MB2700.namprd18.prod.outlook.com>
 <38c4bb35-437e-04dc-4139-d4a826b71ac5@nikhef.nl>
Message-ID: <DM6PR18MB270029B7E032A006E313B615F9AF9@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: Jan Just Keijser <janjust at nikhef.nl>
> Sent: Thursday, 7 January, 2021 01:23
>
> On 06/01/21 21:57, Michael Wojcik wrote:
> >
> >
> > But you're asking the wrong question. The correct question is: Why are you
> > using an outdated version of OpenSSL?
>
> possibly because:
>
> $ cat /etc/redhat-release && openssl version
> CentOS Linux release 7.9.2009 (Core)
> OpenSSL 1.0.2k-fips  26 Jan 2017

Ugh. Well, OP should have made that clear in the original message.

And this is one of the problems with using an OpenSSL supplied by the OS vendor.

--
Michael Wojcik

From kgoldman at us.ibm.com  Thu Jan  7 17:05:23 2021
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Thu, 7 Jan 2021 12:05:23 -0500
Subject: Random and rare Seg faults at openssl library level
In-Reply-To: <DM6PR18MB270029B7E032A006E313B615F9AF9@DM6PR18MB2700.namprd18.prod.outlook.com>
References: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
 <DM6PR18MB2700EABD3C5F9F445D0D69CDF9D09@DM6PR18MB2700.namprd18.prod.outlook.com>
 <38c4bb35-437e-04dc-4139-d4a826b71ac5@nikhef.nl>
 <DM6PR18MB270029B7E032A006E313B615F9AF9@DM6PR18MB2700.namprd18.prod.outlook.com>
Message-ID: <16677a8f-c185-fa03-bbce-0d59bfdb65d3@us.ibm.com>

On 1/7/2021 10:11 AM, Michael Wojcik wrote:
>>
>> $ cat /etc/redhat-release && openssl version
>> CentOS Linux release 7.9.2009 (Core)
>> OpenSSL 1.0.2k-fips  26 Jan 2017
> 
> Ugh. Well, OP should have made that clear in the original message.
> 
> And this is one of the problems with using an OpenSSL supplied by the OS vendor.

In defense of "the OS vendor", meaning the distro, it's a big task to
upgrade to a new openssl major release.  Because there is often not ABI
compatibility, every package has to be ported, built, and tested.
A distro release that is in long term support doesn't do that often.



From Matthias.St.Pierre at ncp-e.com  Thu Jan  7 17:15:18 2021
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Thu, 7 Jan 2021 17:15:18 +0000
Subject: OpenSSL version 3.0.0-alpha10 published
In-Reply-To: <5754479C-0E60-4CE6-AE1F-5BAA56A82086@gmail.com>
References: <20210107140805.GA26451@openssl.org>
 <5754479C-0E60-4CE6-AE1F-5BAA56A82086@gmail.com>
Message-ID: <561871009089426f83e65c6a2f4ad971@ncp-e.com>

John,

I guess you received this mail because you are subscribed to the openssl-users mailing list.
(You might also be subscribed to the openssl-announce mailing list, but that's less likely.)

To unregister from the list, please visit

https://mta.openssl.org/mailman/listinfo/openssl-users  resp.
https://mta.openssl.org/mailman/listinfo/openssl-announce


and follow the instructions for unsubscribing.

Regards,
Matthias



> -----Original Message-----
> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of John Wasilewski
> Sent: Thursday, January 7, 2021 3:23 PM
> To: openssl at openssl.org
> Cc: OpenSSL Announce ML <openssl-announce at openssl.org>; OpenSSL User Support ML <openssl-users at openssl.org>; openssl-
> project at openssl.org
> Subject: Re: OpenSSL version 3.0.0-alpha10 published
> 
> Please remove my email from your distribution
> 
> > On Jan 7, 2021, at 9:08 AM, OpenSSL <openssl at openssl.org> wrote:
> >
> > ?-----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> >
> >   OpenSSL version 3.0 alpha 10 released
> >   =====================================
> >
> >   OpenSSL - The Open Source toolkit for SSL/TLS
> >   https://www.openssl.org/
> >
> >   OpenSSL 3.0 is currently in alpha.
> >
> >   OpenSSL 3.0 alpha 10 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-alpha10.tar.gz
> >      Size: 14084047
> >      SHA1 checksum:  dfeb99f9bdb270d11f723039d07fda1478a31219
> >      SHA256 checksum:  b1699acf2148db31f12edf5ebfdf12a92bfd3f0e60538d169710408a3cd3b138
> >
> >   The checksums were calculated using the following commands:
> >
> >    openssl sha1 openssl-3.0.0-alpha10.tar.gz
> >    openssl sha256 openssl-3.0.0-alpha10.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-----
> >
> > iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl/3ESsACgkQ2cTSbQ5g
> > RJErmQgAj74iDsxOIigH87UxtnKLUqZc7ewbyZxM41XK52G/OPAzqSzGlMxhsYit
> > gvN7k+4qHWGuzyP5UGoTnxued/eG3tggUJh/WeuTmZ8DdrdV4C8Mhfb9ZkocDZZj
> > /wCnVGfb4xS5SPVnHU0qqtn0bWrltddjvdAzmuKvzQmyhftH6d/+VyUA9b9oUTkr
> > ygAvJYI6sJ/WBBSbRzONhwO16GKiLi5AzpPTuW9z7ZJS3YdZCCFFCYKPO255To9y
> > 1GgxhGns9VksvN6NR3AFeTKMQyet3Uo2tRmigtRYZvaJDCE4am40zSuhdFmujwMA
> > HFVox7b+u1PJrUdxzOGJe+A+1I0R9A==
> > =yDQs
> > -----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7494 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210107/20a97f48/attachment-0001.bin>

From gimhanieuthpala at gmail.com  Thu Jan  7 22:49:03 2021
From: gimhanieuthpala at gmail.com (Gimhani Uthpala)
Date: Fri, 8 Jan 2021 04:19:03 +0530
Subject: Random and rare Seg faults at openssl library level
In-Reply-To: <d90f02e2-fae8-a713-e143-42ba8a8e1c18@nikhef.nl>
References: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
 <d90f02e2-fae8-a713-e143-42ba8a8e1c18@nikhef.nl>
Message-ID: <CAJ1bD4_h-JPARda6-yVswNRGiKeLLBbPueVzE4+BxFg06tKa2Q@mail.gmail.com>

On Thu, Jan 7, 2021 at 1:51 PM Jan Just Keijser <janjust at nikhef.nl> wrote:

> Hi,
>
> On 06/01/21 18:10, Gimhani Uthpala wrote:
>
> Dear team,
> I'm running an application which uses openssl for secure communication
> between processes. I am getting seg-faults at openssl level. This only
> occurred very randomly and the following are stacks that seg faults  at
> openssl level in the given 2 cases. We are using openssl 1.0.2k.
>
> version 1.0.2k suggests you are using RHEL7/CentOS 7, correct?
>

Yes, I am using RHEL7 and using its openssl version 1.0.2k-fips.


> Went through the security vulnerabilities list for this version but
> couldn't find a clue. Running valgrind too didn't give an exact clue
> related to the issue. Can you please guide me how can I find the exact root
> cause for the seg fault?
>
> I am calling SSL_do_handshake(ssl_ctx) from my code level and both the
> below seg faults are occuring from it's inside.
>
> #0  0x00007fd64cdabdd3 in ASN1_item_verify () from /lib64/libcrypto.so.10
> #1  0x00007fd64cdcac58 in internal_verify () from /lib64/libcrypto.so.10
> #2  0x00007fd64cdccaef in X509_verify_cert () from /lib64/libcrypto.so.10
> #3  0x00007fd64d111c68 in ssl_verify_cert_chain () from /lib64/libssl.so.10
> #4  0x00007fd64d0e8cc6 in ssl3_get_client_certificate () from
> /lib64/libssl.so.10
> *#5  0x00007fd64d0ea3f8 in ssl3_accept () from /lib64/libssl.so.10*
>
>
> so the segfault occurs inside ASN1_item_verify () when verifying the
> certificate - it could be a malformed certificate with invalid ASN1
> encoding; do you have the certificate that causes the segfault?
>

> If you do not, then it is worthwhile recording/storing all certificates
> until you find the one that causes the segfault and then examine it.
>

I do not have access to the certificate that caused segfault. Will try to
record all certs to check this, Thanks.


>
>
> HTH,
>
> JJK
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210108/d1c14c12/attachment.html>

From gimhanieuthpala at gmail.com  Thu Jan  7 22:50:21 2021
From: gimhanieuthpala at gmail.com (Gimhani Uthpala)
Date: Fri, 8 Jan 2021 04:20:21 +0530
Subject: Random and rare Seg faults at openssl library level
In-Reply-To: <38c4bb35-437e-04dc-4139-d4a826b71ac5@nikhef.nl>
References: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
 <DM6PR18MB2700EABD3C5F9F445D0D69CDF9D09@DM6PR18MB2700.namprd18.prod.outlook.com>
 <38c4bb35-437e-04dc-4139-d4a826b71ac5@nikhef.nl>
Message-ID: <CAJ1bD48yMCdTU4+535Px1yBT1jmORG6jdZutJ=dT5hM-dzLvgg@mail.gmail.com>

On Thu, Jan 7, 2021 at 1:53 PM Jan Just Keijser <janjust at nikhef.nl> wrote:

> On 06/01/21 21:57, Michael Wojcik wrote:
> >
> > The same way you'd track down an intermittent cause of Undefined
> Behavior in any other program: some combination of dynamic monitoring,
> symbolic execution, static code analysis, source code review, testing
> variants, tracing, fuzzing, post-mortem analysis, and so on. This isn't
> specific to OpenSSL.
> >
> > But you're asking the wrong question. The correct question is: Why are
> you using an outdated version of OpenSSL?
>
> possibly because:
>
> $ cat /etc/redhat-release && openssl version
> CentOS Linux release 7.9.2009 (Core)
> OpenSSL 1.0.2k-fips  26 Jan 2017
>
> ?
>
>
>
Yes, using this openssl version coming with the OS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210108/ba05f3f9/attachment.html>

From gimhanieuthpala at gmail.com  Thu Jan  7 22:53:18 2021
From: gimhanieuthpala at gmail.com (Gimhani Uthpala)
Date: Fri, 8 Jan 2021 04:23:18 +0530
Subject: Random and rare Seg faults at openssl library level
In-Reply-To: <5d6e7fe5-c3a6-34ff-b66f-31c54f187ac1@us.ibm.com>
References: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
 <5d6e7fe5-c3a6-34ff-b66f-31c54f187ac1@us.ibm.com>
Message-ID: <CAJ1bD4_HY=dZgB0Es=x44Gkz4bhnD65VFb+6gjyX0dqs8qF2rw@mail.gmail.com>

On Thu, Jan 7, 2021 at 3:08 AM Ken Goldman <kgoldman at us.ibm.com> wrote:

> On 1/6/2021 12:10 PM, Gimhani Uthpala wrote:
>
> > I am getting seg-faults at openssl level. This only occurred very
> randomly and the following are stacks that seg faults  at openssl level in
> the given 2 cases. We are using openssl 1.0.2k.
>
> The usual cause is that you are compiling with one version of openssl and
> (static or dynamic) linking with a different one.
> The cause of that is typically that you have more than one version of
> openssl installed.
>
> If this is a 3rd party application, not one you're building, you have to
> find out what version of openssl they expect.
>
>
>
I only have this 1.0.2.k-fips one version installed in both compiling and
running machines. However, I am compiling the application in RH7.4 and
running in RH7.8 linking to openssl library dynamically. I assume no issue
with that as I am using the same version of openssl in both.

-Gimhani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210108/1470368f/attachment.html>

From mathias.ricken at oracle.com  Fri Jan  8 00:59:17 2021
From: mathias.ricken at oracle.com (Mathias Ricken)
Date: Thu, 07 Jan 2021 16:59:17 -0800
Subject: How to set amount of salt for PBKDF2/PKCS8 keys?
Message-ID: <DA1B71C2-E4FC-49E1-AAA4-3A7F15550571@oracle.com>

Hi,

 

I?m trying to use passphrase-protected keys with BC-FIPS, but whatever I do, I get an exception complaining about not enough salt.

 

Exception in thread "main" org.bouncycastle.crypto.fips.FipsUnapprovedOperationError: salt must be at least 128 bits

??? at org.bouncycastle.crypto.fips.FipsPBKD$Parameters.<init>(Unknown Source)

??? at org.bouncycastle.crypto.fips.FipsPBKD$Parameters.withSalt(Unknown Source)

??? at org.bouncycastle.jcajce.provider.ProvPBEPBKDF2$BasePBKDF2.engineGenerateSecret(Unknown Source)

??? ?

??? at org.bouncycastle.pkcs.PKCS8EncryptedPrivateKeyInfo.decryptPrivateKeyInfo(PKCS8EncryptedPrivateKeyInfo.java:75)

 

I?ve tried several ways to create the keys:

 

openssl genrsa -out ~/.oci/oci_api_key_passphrase.pem -aes128 2048

openssl pkcs8 -topk8 -v2 aes128 -in ~/.oci/oci_api_key_passphrase.pem -out ~/.oci/oci_api_key_passphrase_pk8.pem

 

or 

 

openssl genpkey -aes-256-cbc -algorithm RSA-PSS -pkeyopt rsa_keygen_bits:2048 \

???????? -pkeyopt rsa_keygen_pubexp:65537 -pkeyopt rsa_pss_keygen_md:sha256 \

???????? -pkeyopt rsa_pss_keygen_mgf1_md:sha256 -pkeyopt rsa_pss_keygen_saltlen:32 \

??? ?????-out oci_api_key_passphrase.pem

openssl pkcs8 -topk8 -v2 aes128 -in ~/.oci/oci_api_key_passphrase.pem -out ~/.oci/oci_api_key_passphrase_pk8.pem

 

or

 

openssl genrsa -out oci_api_key_passphrase.pem -aes128 2048 -S 123456789012345678901234567890

openssl pkcs8 -topk8 -v2 aes128 -in ~/.oci/oci_api_key_passphrase.pem -out ~/.oci/oci_api_key_passphrase_pk8.pem

 

or

 

openssl genrsa -out oci_api_key_passphrase.pem -aes128 2048 -salt -s 123456789012345678901234567890

openssl pkcs8 -topk8 -v2 aes128 -in ~/.oci/oci_api_key_passphrase.pem -out ~/.oci/oci_api_key_passphrase_pk8.pem

 

But no matter what I do, when I try to use the key with BC-FIPS, I get the error about not enough salt, and when I use openssl asn1parse, I can see that the octet string is only 64 bit:

 

openssl asn1parse -in oci_api_key_passphrase2_pk8.pem

?

?? 21:d=4? hl=2 l=?? 9 prim: OBJECT??????????? :PBKDF2

?? 32:d=4? hl=2 l=? 28 cons: SEQUENCE

?? 34:d=5? hl=2 l=?? 8 prim: OCTET STRING????? [HEX DUMP]:65A4890CBC5ED23C

?

 

and when I set a breakpoint in BC-FIPS, I see that 65A4890CBC5ED23C is the octet string that is being loaded as salt, and it?s 8 bytes = 64 bits.

 

I?ve tried this both with

 

$ openssl version

LibreSSL 2.8.3

 

and

 

$ /usr/local/opt/openssl at 1.1/bin/openssl version

OpenSSL 1.1.1i? 8 Dec 2020

 

How do I sell openssl to use more salt when generating the private key?

 

Thanks,

 

--Mathias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210107/a8563f78/attachment-0001.html>

From quanah at symas.com  Fri Jan  8 01:10:29 2021
From: quanah at symas.com (Quanah Gibson-Mount)
Date: Thu, 07 Jan 2021 17:10:29 -0800
Subject: no suitable signature algorithm during handshake failure
Message-ID: <9E4638FBE468D8E17C07505F@[192.168.1.156]>

Working on a migration for an application (OpenLDAP) where the old version 
is linked to OpenSSL 1.0.2 to where the new version is linked to OpenSSL 
1.1.1h.

Most client applications are working without issue.  However, one Windows 
client application consistently fails to connect to the OpenSSL 1.1.1h 
linked slapd with an error of no suitable signature algorithm during the 
handshake.

Using wireshark, we can see the following signature algorithms are offered 
from the client side (which uses TLSv1.2) for both the working and failing 
servers:

0x0403 ECDSA-SHA256
0x0503 ECDSA-SHA384
0x0603 ECDSA-SHA512
0x0401 RSA-SHA256
0x0501 RSA-SHA384
0x0601 RSA-SHA512
0x0402 DSA-SHA256
0x0203 ECDSA-SHA1
0x0201 RSA-SHA1
0x0202 DSA-SHA1

If I test connecting on the command line to the server in question, I can 
connect using any of RSA+SHA256, RSA+SHA384, and RSA+SHA512 from the above 
signature algorithms without issue, like:

openssl s_client -connect <host:636> -tls1_2 -sigalgs RSA+SHA256

Any suggestions as to why the windows client is unable to negotiate with a 
new version of OpenSSL?

The error in the log is:

error: 14201076:SSL routines:tls_choose_sigalg:no suitable signature 
algorithm.

Thanks,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>

From openssl-users at dukhovni.org  Fri Jan  8 01:56:15 2021
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 7 Jan 2021 20:56:15 -0500
Subject: no suitable signature algorithm during handshake failure
In-Reply-To: <9E4638FBE468D8E17C07505F@[192.168.1.156]>
References: <9E4638FBE468D8E17C07505F@[192.168.1.156]>
Message-ID: <X/e7v34PREGwfQJW@straasha.imrryr.org>

On Thu, Jan 07, 2021 at 05:10:29PM -0800, Quanah Gibson-Mount wrote:

> Using wireshark, we can see the following signature algorithms are offered 
> from the client side (which uses TLSv1.2) for both the working and failing 
> servers:
> 
> 0x0403 ECDSA-SHA256
> 0x0503 ECDSA-SHA384
> 0x0603 ECDSA-SHA512
> 0x0401 RSA-SHA256
> 0x0501 RSA-SHA384
> 0x0601 RSA-SHA512
> 0x0402 DSA-SHA256
> 0x0203 ECDSA-SHA1
> 0x0201 RSA-SHA1
> 0x0202 DSA-SHA1

You're leaving out too much detail.  Post the full client hello decoded
by "tshark":

    https://www.spinics.net/lists/openssl-users/msg05623.html

> If I test connecting on the command line to the server in question, I can 
> connect using any of RSA+SHA256, RSA+SHA384, and RSA+SHA512 from the above 
> signature algorithms without issue, like:

What sort of certificate does the server have.  Are there any ssl module
settings in its openssl.cnf file?

-- 
    Viktor.

From matt at openssl.org  Fri Jan  8 09:11:17 2021
From: matt at openssl.org (Matt Caswell)
Date: Fri, 8 Jan 2021 09:11:17 +0000
Subject: How to set amount of salt for PBKDF2/PKCS8 keys?
In-Reply-To: <DA1B71C2-E4FC-49E1-AAA4-3A7F15550571@oracle.com>
References: <DA1B71C2-E4FC-49E1-AAA4-3A7F15550571@oracle.com>
Message-ID: <674940ed-d3b1-7ff4-253b-a60af5e5b5e8@openssl.org>



On 08/01/2021 00:59, Mathias Ricken wrote:
> How do I sell openssl to use more salt when generating the private key?

Unfortunately the pkcs8 tool does not support setting a custom salt
length and always uses the default length of 64 bits.

The best I can offer you is a hack of the tool to change the default to
128 bits (16 bytes):

diff --git a/apps/pkcs8.c b/apps/pkcs8.c
index 205536560a..14700e5d12 100644
--- a/apps/pkcs8.c
+++ b/apps/pkcs8.c
@@ -229,7 +229,7 @@ int pkcs8_main(int argc, char **argv)
                                                 scrypt_N, scrypt_r,
scrypt_p);
                 else
 #endif
-                    pbe = PKCS5_pbe2_set_iv(cipher, iter, NULL, 0, NULL,
+                    pbe = PKCS5_pbe2_set_iv(cipher, iter, NULL, 16, NULL,
                                             pbe_nid);
             } else {
                 pbe = PKCS5_pbe_set(pbe_nid, iter, NULL, 0);



Matt


From kgoldman at us.ibm.com  Fri Jan  8 13:29:52 2021
From: kgoldman at us.ibm.com (Kenneth Goldman)
Date: Fri, 8 Jan 2021 08:29:52 -0500
Subject: Random and rare Seg faults at openssl library level
In-Reply-To: <CAJ1bD4_HY=dZgB0Es=x44Gkz4bhnD65VFb+6gjyX0dqs8qF2rw@mail.gmail.com>
References: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
 <5d6e7fe5-c3a6-34ff-b66f-31c54f187ac1@us.ibm.com>
 <CAJ1bD4_HY=dZgB0Es=x44Gkz4bhnD65VFb+6gjyX0dqs8qF2rw@mail.gmail.com>
Message-ID: <OF1406E918.202588EC-ON00258657.0049C985-85258657.004A257E@notes.na.collabserv.com>






From:	Gimhani Uthpala <gimhanieuthpala at gmail.com>
To:	Ken Goldman <kgoldman at us.ibm.com>
Cc:	openssl-users at openssl.org
Date:	01/07/2021 05:53 PM
Subject:	[EXTERNAL] Re: Random and rare Seg faults at openssl library
            level



I only?have this 1.0.2.k-fips one version installed in both compiling and
running machines. However, I am compiling the application in RH7.4 and
running in RH7.8 linking to openssl library dynamically. I assume no issue
with that as I am using the same version of openssl in both.

You are having a problem, and that is a typical cause.  Try compiling and
running on the exact same OS.

If you installed openssl yourself, not using the RHEL yum installer, I
would expect random and rare issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210108/060f3f8b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210108/060f3f8b/attachment.gif>

From jb-openssl at wisemo.com  Fri Jan  8 14:55:50 2021
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 8 Jan 2021 15:55:50 +0100
Subject: Random and rare Seg faults at openssl library level
In-Reply-To: <16677a8f-c185-fa03-bbce-0d59bfdb65d3@us.ibm.com>
References: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
 <DM6PR18MB2700EABD3C5F9F445D0D69CDF9D09@DM6PR18MB2700.namprd18.prod.outlook.com>
 <38c4bb35-437e-04dc-4139-d4a826b71ac5@nikhef.nl>
 <DM6PR18MB270029B7E032A006E313B615F9AF9@DM6PR18MB2700.namprd18.prod.outlook.com>
 <16677a8f-c185-fa03-bbce-0d59bfdb65d3@us.ibm.com>
Message-ID: <8210fdee-80a7-9ec8-6a02-8968edc53aa2@wisemo.com>

On 2021-01-07 18:05, Ken Goldman wrote:
> On 1/7/2021 10:11 AM, Michael Wojcik wrote:
>>>
>>> $ cat /etc/redhat-release && openssl version
>>> CentOS Linux release 7.9.2009 (Core)
>>> OpenSSL 1.0.2k-fips? 26 Jan 2017
>>
>> Ugh. Well, OP should have made that clear in the original message.
>>
>> And this is one of the problems with using an OpenSSL supplied by the 
>> OS vendor.
>
> In defense of "the OS vendor", meaning the distro, it's a big task to
> upgrade to a new openssl major release.? Because there is often not ABI
> compatibility, every package has to be ported, built, and tested.
> A distro release that is in long term support doesn't do that often.
>
>

In defense of long term support distros, until a few years ago, no one 
suspected that OpenSSL would come under a new leadership that actively 
did everything to make it near-impossible to maintain backported 
security patches for a typical 5+ year distro lifecycle (with 
OpenSSL-independent start date).

Until 1.0.2, all OpenSSL releases were incremental patch-steps from the 
old 0.9.x series, allowing distro maintainers to manually cherry pick 
changes for doing ABI-compatible patches for whichever 1.0.x or 0.9.x 
was current at the start of their lifecycle.? Then the new leadership 
started to restructure the code even in supposedly patch-level releases.

A lot of long term support distros are now firmly stuck with unsupported 
OpenSSL 1.0.2 and/or short life cycle 1.1.1.

Not all long term distros are run by rich companies like IBM/RedHat that 
can purchase support plans, resulting in further popularity of OpenSSL 
forks.

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 quanah at symas.com  Fri Jan  8 20:05:26 2021
From: quanah at symas.com (Quanah Gibson-Mount)
Date: Fri, 08 Jan 2021 12:05:26 -0800
Subject: no suitable signature algorithm during handshake failure
In-Reply-To: <X/e7v34PREGwfQJW@straasha.imrryr.org>
References: <9E4638FBE468D8E17C07505F@[192.168.1.156]>
 <X/e7v34PREGwfQJW@straasha.imrryr.org>
Message-ID: <FA609BEBBD8DB0BF6D3D9FF9@[192.168.1.156]>



--On Thursday, January 7, 2021 8:56 PM -0500 Viktor Dukhovni 
<openssl-users at dukhovni.org> wrote:

> You're leaving out too much detail.  Post the full client hello decoded
> by "tshark":
>
>     https://www.spinics.net/lists/openssl-users/msg05623.html

Thanks Viktor.  Mainly, I wasn't sure what specific information would be 
necessary.  Here's what wireshark shows (IP addresses obfuscated):

No.     Time           UTC                           Source 
Length Destination           Protocol Info
      1 0.000000       2021-01-07 21:19:53.417328    255.255.255.223 
68     255.255.255.198       TCP      51466?636 [SYN, ECN, CWR] Seq=0 
Win=8192 Len=0 MSS=1380 WS=256 SACK_PERM=1

Frame 1: 68 bytes on wire (544 bits), 68 bytes captured (544 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 255.255.255.223, Dst: 255.255.255.198
Transmission Control Protocol, Src Port: 51466, Dst Port: 636, Seq: 0, Len: 
0

No.     Time           UTC                           Source 
Length Destination           Protocol Info
      2 0.000081       2021-01-07 21:19:53.417409    255.255.255.198 
68     255.255.255.223        TCP      636?51466 [SYN, ACK] Seq=0 Ack=1 
Win=64240 Len=0 MSS=1460 SACK_PERM=1 WS=128

Frame 2: 68 bytes on wire (544 bits), 68 bytes captured (544 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 255.255.255.198, Dst: 255.255.255.223
Transmission Control Protocol, Src Port: 636, Dst Port: 51466, Seq: 0, Ack: 
1, Len: 0

No.     Time           UTC                           Source 
Length Destination           Protocol Info
      3 0.000462       2021-01-07 21:19:53.417790    255.255.255.223 
62     255.255.255.198       TCP      51466?636 [ACK] Seq=1 Ack=1 
Win=2097408 Len=0

Frame 3: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 255.255.255.223, Dst: 255.255.255.198
Transmission Control Protocol, Src Port: 51466, Dst Port: 636, Seq: 1, Ack: 
1, Len: 0
VSS-Monitoring ethernet trailer, Source Port: 0

No.     Time           UTC                           Source 
Length Destination           Protocol Info
      4 0.004053       2021-01-07 21:19:53.421381    255.255.255.223 
484    255.255.255.198       TLSv1.2  Client Hello

Frame 4: 484 bytes on wire (3872 bits), 484 bytes captured (3872 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 255.255.255.223, Dst: 255.255.255.198
Transmission Control Protocol, Src Port: 51466, Dst Port: 636, Seq: 1, Ack: 
1, Len: 428
Secure Sockets Layer
    TLSv1.2 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 423
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 419
            Version: TLS 1.2 (0x0303)
            Random
                GMT Unix Time: Oct  2, 2014 19:22:16.000000000 MDT
                Random Bytes: 
3226c3627d2ba7c967ce2cf097e616d9cbe45d1bb1cc21f4...
            Session ID Length: 32
            Session ID: bde8c16349a08e56a121b6e7aa1f317acf42186ba79b134d...
            Cipher Suites Length: 88
            Cipher Suites (44 suites)
                Cipher Suite: Unknown (0x1301)
                Cipher Suite: Unknown (0x1302)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 
(0xc02c)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 
(0xc02b)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
                Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
                Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 
(0xc02e)
                Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (0xc032)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
                Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
                Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 
(0xc02d)
                Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 
(0xc024)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
                Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 
(0xc026)
                Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)
                Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 
(0xc023)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
                Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 
(0xc025)
                Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)
                Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
            Compression Methods Length: 1
            Compression Methods (1 method)
            Extensions Length: 258
            Extension: server_name
                Type: server_name (0x0000)
                Length: 35
                Server Name Indication extension
                    Server Name list length: 33
                    Server Name Type: host_name (0)
                    Server Name length: 30
                    Server Name: directory.srv.TEST.ualberta.ca
            Extension: status_request
                Type: status_request (0x0005)
                Length: 5
                Certificate Status Type: OCSP (1)
                Responder ID list Length: 0
                Request Extensions Length: 0
            Extension: elliptic_curves
                Type: elliptic_curves (0x000a)
                Length: 32
                Elliptic Curves Length: 30
                Elliptic curves (15 curves)
            Extension: ec_point_formats
                Type: ec_point_formats (0x000b)
                Length: 2
                EC point formats Length: 1
                Elliptic curves point formats (1)
            Extension: signature_algorithms
                Type: signature_algorithms (0x000d)
                Length: 22
                Signature Hash Algorithms Length: 20
                Signature Hash Algorithms (10 algorithms)
                    Signature Hash Algorithm: 0x0403
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Hash Algorithm: 0x0503
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Hash Algorithm: 0x0603
                        Signature Hash Algorithm Hash: SHA512 (6)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Hash Algorithm: 0x0401
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Hash Algorithm: 0x0501
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Hash Algorithm: 0x0601
                        Signature Hash Algorithm Hash: SHA512 (6)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Hash Algorithm: 0x0402
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: DSA (2)
                    Signature Hash Algorithm: 0x0203
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Hash Algorithm: 0x0201
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Hash Algorithm: 0x0202
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: DSA (2)
            Extension: Unknown 50
                Type: Unknown (0x0032)
                Length: 22
                Data (22 bytes)
            Extension: status_request_v2
                Type: status_request_v2 (0x0011)
                Length: 9
                Certificate Status Type: OCSP Multi (2)
                Certificate Status Length: 4
                Responder ID list Length: 0
                Request Extensions Length: 0
            Extension: Extended Master Secret
                Type: Extended Master Secret (0x0017)
                Length: 0
            Extension: Unknown 43
                Type: Unknown (0x002b)
                Length: 9
                Data (9 bytes)
            Extension: Unknown 45
                Type: Unknown (0x002d)
                Length: 2
                Data (2 bytes)
            Extension: Unknown 51
                Type: Unknown (0x0033)
                Length: 71
                Data (71 bytes)
            Extension: renegotiation_info
                Type: renegotiation_info (0xff01)
                Length: 1
                Renegotiation Info extension
                    Renegotiation info extension length: 0

No.     Time           UTC                           Source 
Length Destination           Protocol Info
      5 0.004070       2021-01-07 21:19:53.421398    255.255.255.198 
56     255.255.255.223        TCP      636?51466 [ACK] Seq=1 Ack=429 
Win=64128 Len=0

Frame 5: 56 bytes on wire (448 bits), 56 bytes captured (448 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 255.255.255.198, Dst: 255.255.255.223
Transmission Control Protocol, Src Port: 636, Dst Port: 51466, Seq: 1, Ack: 
429, Len: 0

No.     Time           UTC                           Source 
Length Destination           Protocol Info
      6 0.004332       2021-01-07 21:19:53.421660    255.255.255.198 
63     255.255.255.223        TLSv1.2  Alert (Level: Fatal, Description: 
Handshake Failure)

Frame 6: 63 bytes on wire (504 bits), 63 bytes captured (504 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 255.255.255.198, Dst: 255.255.255.223
Transmission Control Protocol, Src Port: 636, Dst Port: 51466, Seq: 1, Ack: 
429, Len: 7
Secure Sockets Layer
    TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake 
Failure)
        Content Type: Alert (21)
        Version: TLS 1.2 (0x0303)
        Length: 2
        Alert Message
            Level: Fatal (2)
            Description: Handshake Failure (40)



And here's the output from tshark:

0000  00 00 00 01 00 06 a2 01 00 00 01 6a 00 00 08 00   ...........j....
0010  45 02 00 34 27 36 40 00 7e 06 e2 fd FF FF FF df   E..4'6 at .~.....a.
0020  FF FF FF c6 c9 0a 02 7c f9 79 74 f4 00 00 00 00   ..r....|.yt.....
0030  80 c2 20 00 22 1d 00 00 02 04 05 64 01 03 03 08   .. ."......d....
0040  01 01 04 02                                       ....

0000  00 04 00 01 00 06 00 50 56 a2 57 0e 00 00 08 00   .......PV.W.....
0010  45 00 00 34 00 00 40 00 40 06 48 36 FF FF FF c6   E..4.. at .@.H6..r.
0020  FF FF FF df 02 7c c9 0a 23 63 fa 85 f9 79 74 f5   ..a..|..#c...yt.
0030  80 12 fa f0 f2 b4 00 00 02 04 05 b4 01 01 04 02   ................
0040  01 03 03 07                                       ....

0000  00 00 00 01 00 06 a2 01 00 00 01 6a 00 00 08 00   ...........j....
0010  45 00 00 28 27 37 40 00 7e 06 e3 0a FF FF FF df   E..('7 at .~.....a.
0020  FF FF FF c6 c9 0a 02 7c f9 79 74 f5 23 63 fa 86   ..r....|.yt.#c..
0030  50 10 20 01 45 65 00 00 00 00 00 00 00 00         P. .Ee........

0000  00 00 00 01 00 06 a2 01 00 00 01 6a 00 00 08 00   ...........j....
0010  45 00 01 d4 27 38 40 00 7e 06 e1 5d FF FF FF df   E...'8 at .~..]..a.
0020  FF FF FF c6 c9 0a 02 7c f9 79 74 f5 23 63 fa 86   ..r....|.yt.#c..
0030  50 18 20 01 49 33 00 00 16 03 03 01 a7 01 00 01   P. .I3..........
0040  a3 03 03 54 2d fa 48 32 26 c3 62 7d 2b a7 c9 67   ...T-.H2&.b}+..g
0050  ce 2c f0 97 e6 16 d9 cb e4 5d 1b b1 cc 21 f4 6d   .,.......]...!.m
0060  8d c3 96 20 bd e8 c1 63 49 a0 8e 56 a1 21 b6 e7   ... ...cI..V.!..
0070  aa 1f 31 7a cf 42 18 6b a7 9b 13 4d d3 aa 55 01   ..1z.B.k...M..U.
0080  d0 e3 a0 c9 00 58 13 01 13 02 c0 2c c0 2b c0 30   .....X.....,.+.0
0090  00 9d c0 2e c0 32 00 9f 00 a3 c0 2f 00 9c c0 2d   .....2...../...-
00a0  c0 31 00 9e 00 a2 c0 24 c0 28 00 3d c0 26 c0 2a   .1.....$.(.=.&.*
00b0  00 6b 00 6a c0 0a c0 14 00 35 c0 05 c0 0f 00 39   .k.j.....5.....9
00c0  00 38 c0 23 c0 27 00 3c c0 25 c0 29 00 67 00 40   .8.#.'.<.%.).g.@
00d0  c0 09 c0 13 00 2f c0 04 c0 0e 00 33 00 32 01 00   ...../.....3.2..
00e0  01 02 00 00 00 23 00 21 00 00 1e 64 69 72 65 63   .....#.!...direc
00f0  74 6f 72 79 2e 73 72 76 2e 54 45 53 54 2e 75 61   tory.srv.TEST.ua
0100  6c 62 65 72 74 61 2e 63 61 00 05 00 05 01 00 00   lberta.ca.......
0110  00 00 00 0a 00 20 00 1e 00 17 00 18 00 19 00 09   ..... ..........
0120  00 0a 00 0b 00 0c 00 0d 00 0e 00 16 01 00 01 01   ................
0130  01 02 01 03 01 04 00 0b 00 02 01 00 00 0d 00 16   ................
0140  00 14 04 03 05 03 06 03 04 01 05 01 06 01 04 02   ................
0150  02 03 02 01 02 02 00 32 00 16 00 14 04 03 05 03   .......2........
0160  06 03 04 01 05 01 06 01 04 02 02 03 02 01 02 02   ................
0170  00 11 00 09 00 07 02 00 04 00 00 00 00 00 17 00   ................
0180  00 00 2b 00 09 08 03 04 03 03 03 02 03 01 00 2d   ..+............-
0190  00 02 01 01 00 33 00 47 00 45 00 17 00 41 04 04   .....3.G.E...A..
01a0  c8 eb 79 4d 02 24 a3 68 25 9d 5a 07 77 bf bb 06   ..yM.$.h%.Z.w...
01b0  c8 36 c0 96 1a 5c 88 e2 8a dd a9 17 4a 6c d6 c5   .6...\......Jl..
01c0  71 f5 f0 43 d7 d2 c1 67 95 d9 75 b9 4f f1 e2 8d   q..C...g..u.O...
01d0  40 23 d0 02 39 f7 83 f5 b8 05 75 a2 f3 3d ae ff   @#..9.....u..=..
01e0  01 00 01 00                                       ....

0000  00 04 00 01 00 06 00 50 56 a2 57 0e 00 00 08 00   .......PV.W.....
0010  45 00 00 28 9b 8c 40 00 40 06 ac b5 FF FF FF c6   E..(.. at .@.....r.
0020  FF FF FF df 02 7c c9 0a 23 63 fa 86 f9 79 76 a1   ..a..|..#c...yv.
0030  50 10 01 f5 f2 a8 00 00                           P.......

0000  00 04 00 01 00 06 00 50 56 a2 57 0e 00 00 08 00   .......PV.W.....
0010  45 00 00 2f 9b 8d 40 00 40 06 ac ad FF FF FF c6   E../.. at .@.....r.
0020  FF FF FF df 02 7c c9 0a 23 63 fa 86 f9 79 76 a1   ..a..|..#c...yv.
0030  50 18 01 f5 f2 af 00 00 15 03 03 00 02 02 28      P.............(


>> If I test connecting on the command line to the server in question, I
>> can  connect using any of RSA+SHA256, RSA+SHA384, and RSA+SHA512 from
>> the above  signature algorithms without issue, like:
>
> What sort of certificate does the server have.  Are there any ssl module
> settings in its openssl.cnf file?

no module settings for openssl.cnf.

For the server with the non-working cert, this is the x509 text output:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ---
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign RSA OV SSL CA 2018
        Validity
            Not Before: Mar 26 17:49:45 2020 GMT
            Not After : Apr 30 21:21:03 2022 GMT
        Subject: C=CA, ST=Alberta, L=---
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:be:7a:f2:f6:aa:17:97:ec:06:d7:9f:ff:55:01:
                    4d:e9:97:50:99:3a:db:50:07:c2:7a:f5:23:b3:d1:
                    fe:f9:69:03:a8:74:d8:f3:6c:cc:e9:3b:ec:4e:48:
                    15:ac:d7:91:19:c7:e4:ad:0b:b0:52:58:4d:68:e8:
                    77:89:ae:ee:72:56:dd:72:8a:71:bf:de:0e:79:6d:
                    6d:e9:fb:a8:16:78:3f:eb:a0:a7:dc:ee:2e:b9:02:
                    94:86:8a:f9:ee:31:ab:39:11:aa:9e:83:12:d7:92:
                    5b:3e:99:45:44:dd:b4:4b:ca:4d:90:37:18:1c:1e:
                    a7:50:22:bf:c2:b5:0c:06:0b:c6:7e:81:0c:6a:43:
                    ee:69:f7:7b:3d:21:16:c6:3f:b2:33:a7:bd:15:0d:
                    df:c4:a4:c6:bb:3e:be:0e:6d:ef:2c:fa:1e:3c:0c:
                    1b:73:4f:80:79:8f:39:c9:38:93:c8:5d:b9:fb:0b:
                    62:86:b8:bd:31:fb:6f:1b:8b:55:0a:9d:4d:74:13:
                    6b:4e:90:6a:4b:56:71:d0:d4:97:b1:6c:dd:be:64:
                    ad:2b:f4:91:6a:9e:f8:73:5e:cb:b5:0b:e5:c9:c4:
                    85:a2:8b:2a:75:1f:b2:25:ad:4d:7c:21:41:76:8c:
                    e5:3e:28:7e:ac:39:ff:99:4f:66:e0:27:e5:b9:4f:
                    b6:5a:37:46:0d:5f:12:e3:f0:cc:04:28:48:f3:0c:
                    c5:32:76:99:40:58:c0:eb:ca:b5:22:00:c7:d3:93:
                    c4:9e:a6:20:25:ac:f8:9d:a0:02:c6:b6:23:02:e0:
                    77:3c:de:68:12:10:7f:9d:7e:70:f4:cf:49:b3:03:
                    9a:bc:20:87:85:b3:9f:27:08:02:16:f5:62:4b:b9:
                    ac:0a:2f:d9:de:f5:ef:64:51:2a:e1:5e:ed:10:15:
                    ff:91:c4:13:a6:ae:2f:88:9e:29:01:1d:f4:db:c1:
                    a4:e8:3c:74:97:59:2f:df:45:c1:2c:10:5e:b7:7c:
                    ab:ff:cc:a3:eb:a3:ec:e6:f7:e4:12:c2:1a:06:f2:
                    fb:ec:d4:50:f5:50:66:92:9d:96:e7:34:ab:8c:42:
                    dd:a8:ba:83:8a:9e:88:bd:0d:e7:fe:07:9f:50:c8:
                    db:34:e2:35:1a:10:2d:a5:b6:be:88:4c:f2:42:31:
                    35:83:b4:e2:9e:52:7f:db:5a:25:7d:82:f9:31:c0:
                    19:f3:bf:06:a3:44:ba:ff:6f:c2:3a:0c:72:82:f8:
                    30:ba:41:da:c0:49:0e:07:aa:83:c7:89:91:f3:02:
                    fc:1d:64:3b:7e:ec:60:9f:ef:21:bd:3f:e7:90:91:
                    73:60:48:98:08:28:6c:72:03:40:6b:1d:72:01:09:
                    97:f9:e9
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            Authority Information Access:
                CA Issuers - 
URI:http://secure.globalsign.com/cacert/gsrsaovsslca2018.crt
                OCSP - URI:http://ocsp.globalsign.com/gsrsaovsslca2018

            X509v3 Certificate Policies:
                Policy: 1.3.6.1.4.1.4146.1.20
                  CPS: https://www.globalsign.com/repository/
                Policy: 2.23.140.1.2.2

            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.globalsign.com/gsrsaovsslca2018.crl

            X509v3 Subject Alternative Name:
                DNS:---
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Authority Key Identifier:
 
keyid:F8:EF:7F:F2:CD:78:67:A8:DE:6F:8F:24:8D:88:F1:87:03:02:B3:EB

            X509v3 Subject Key Identifier:
                ---
            1.3.6.1.4.1.11129.2.4.2: ---
    Signature Algorithm: sha256WithRSAEncryption
         99:3e:bd:18:22:63:b0:45:5a:9d:e0:9a:30:36:18:5c:c4:a6:
         72:d8:a7:b0:5f:c6:61:14:66:74:2b:0d:63:2c:57:04:05:a6:
         48:f7:19:09:3b:4e:20:70:54:92:30:77:b4:c0:3f:4d:d4:3f:
         fc:e0:ee:fb:5a:4b:7a:a9:3f:08:d7:f3:59:a9:10:0b:a7:88:
         10:4a:cd:a6:ae:8b:44:00:b7:bd:9e:29:ce:51:63:fe:82:ca:
         e2:4d:88:b0:ab:ff:dc:24:fe:a7:3e:7e:ea:78:3c:ea:fa:20:
         f0:37:72:33:cd:1d:fd:21:ae:35:d8:c8:f2:6c:e9:d6:88:d9:
         2e:6d:7b:46:49:be:7d:d4:ab:be:21:47:1a:95:ab:e2:31:e7:
         7f:50:19:41:22:18:2c:f0:53:7a:00:ca:c6:17:12:92:d8:ec:
         88:cf:87:ee:04:fd:89:71:61:08:4e:75:23:2b:6f:d6:ed:00:
         ae:9d:c2:16:b7:31:97:92:fc:88:86:e6:8a:3b:d8:19:42:f5:
         8b:52:03:0a:17:35:d2:e6:b1:f0:80:bf:fc:29:a7:42:72:67:
         9b:00:49:17:30:19:d2:6c:53:15:d2:73:1c:9f:5e:d7:c0:07:
         47:67:75:63:bf:4c:a6:32:22:f3:e3:5a:0b:15:ed:1c:56:79:
         78:d1:1d:63


For the working server,
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ---
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign RSA OV SSL CA 2018
        Validity
            Not Before: Aug  7 16:46:05 2019 GMT
            Not After : Oct 13 14:46:02 2021 GMT
        Subject: C=CA, ST=Alberta, L=---
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:a0:cb:85:09:24:5f:d4:11:67:fc:4b:08:15:31:
                    14:8c:1f:01:ed:fe:e1:f3:b1:95:7a:31:a7:90:5e:
                    61:9d:47:fc:41:08:86:de:77:c3:18:18:d6:23:8d:
                    44:21:b1:f2:12:29:0d:85:e7:be:e2:ae:f8:de:ac:
                    a6:5c:36:f4:fc:be:cf:eb:28:a5:bf:9b:5b:32:c7:
                    96:1f:c6:41:7b:19:0f:39:ec:00:b2:50:f4:de:64:
                    33:55:71:81:ab:99:00:14:32:d9:65:9c:9b:ba:52:
                    a5:62:80:75:f4:ae:ed:65:70:77:ca:76:4d:b5:94:
                    ab:89:88:ef:2e:2c:db:54:15:e7:5d:05:c4:bb:46:
                    df:1b:6d:e2:60:70:f0:ea:08:d1:92:4f:5f:76:d0:
                    64:7a:2f:f4:a0:19:c8:d1:20:e6:59:8a:a1:90:76:
                    70:0c:48:5f:32:b7:66:77:c4:de:08:1c:9d:0c:f4:
                    f9:e1:88:02:90:c1:6f:46:c4:88:ae:91:18:08:04:
                    5f:e4:c6:ce:d6:f2:c1:23:31:61:7c:2c:cf:dc:2c:
                    17:b0:b5:b4:a9:24:c3:a5:c5:c9:04:38:63:e6:88:
                    79:88:0c:66:f5:f8:b5:d5:7f:b9:de:97:6d:2c:7d:
                    5b:33:ba:52:30:9f:0b:d7:16:8d:0c:69:36:5a:a2:
                    4c:41:99:c6:82:d4:cf:29:6e:a5:c0:91:c3:0a:6b:
                    57:6d:f3:ba:d4:74:d0:59:3b:a0:f2:79:18:54:8e:
                    f8:4f:18:75:7b:d9:d5:a9:56:c8:af:8a:5f:ce:93:
                    a7:c3:88:53:03:54:6d:4d:2a:36:d9:ee:0d:6d:9b:
                    72:6a:f3:d2:81:b3:0c:ad:1b:f8:0c:f6:1a:c0:bb:
                    23:f3:55:92:8d:31:bc:01:75:d1:f0:d9:cd:41:3a:
                    1f:d9:7a:3b:6c:17:e4:c8:91:eb:81:82:7f:01:1e:
                    f2:cf:77:44:e2:8f:97:d9:c6:f1:99:7a:58:7c:c1:
                    c1:9c:43:c6:89:9f:2c:ec:67:33:ef:66:36:c7:b7:
                    b9:db:f2:b5:f9:e7:6e:84:ec:44:95:e6:23:f6:fa:
                    d0:91:69:72:57:a1:23:8d:56:76:a7:5f:f2:f1:4a:
                    a6:d0:70:c5:d1:e1:4c:5f:c8:6c:34:94:42:ed:f6:
                    c8:36:db:5b:15:7f:4c:66:50:dc:d2:8c:45:5d:fc:
                    dd:67:20:e8:55:f3:84:5d:88:18:c8:c4:1b:c6:d6:
                    de:d0:dd:38:fb:4c:ac:68:9d:73:5e:52:c6:cf:50:
                    ca:1b:e9:b7:f7:50:c9:a5:27:df:d6:09:18:72:a3:
                    5a:5f:47:22:d5:e1:56:ae:9c:20:cd:c3:58:e6:ae:
                    b7:24:89
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            Authority Information Access:
                CA Issuers - 
URI:http://secure.globalsign.com/cacert/gsrsaovsslca2018.crt
                OCSP - URI:http://ocsp.globalsign.com/gsrsaovsslca2018

            X509v3 Certificate Policies:
                Policy: 1.3.6.1.4.1.4146.1.20
                  CPS: https://www.globalsign.com/repository/
                Policy: 2.23.140.1.2.2

            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.globalsign.com/gsrsaovsslca2018.crl

            X509v3 Subject Alternative Name:
                DNS:---
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Authority Key Identifier:
 
keyid:F8:EF:7F:F2:CD:78:67:A8:DE:6F:8F:24:8D:88:F1:87:03:02:B3:EB

            X509v3 Subject Key Identifier:
                ---
            1.3.6.1.4.1.11129.2.4.2: ---
    Signature Algorithm: sha256WithRSAEncryption
         5a:80:48:10:86:0d:f9:66:d3:bc:7b:35:a8:7b:20:8c:6c:c9:
         ca:ad:62:72:24:20:35:59:ba:aa:38:4e:c0:89:75:b9:ce:3d:
         b2:61:35:e9:4e:d8:bc:7b:8a:ee:23:2c:cc:ae:0a:12:2d:bc:
         27:c5:f6:13:3c:5d:1a:d9:83:4c:7c:bc:4e:f7:fd:f4:cf:77:
         3b:f1:be:6c:be:c0:8b:0c:4f:f2:3f:1f:c8:8d:8e:28:a2:af:
         17:bf:63:c0:60:25:96:b3:65:4c:8a:7e:6a:c1:8f:bc:48:b6:
         e7:85:89:a5:d2:96:98:c9:62:53:fd:12:1c:37:ce:b2:de:54:
         78:37:9a:a7:c3:65:1d:bd:65:bd:55:ac:72:bc:4a:43:41:ee:
         37:8a:e9:13:9e:56:34:35:f1:e0:72:0d:67:1f:52:ee:81:8d:
         86:d6:62:86:19:cd:5e:88:1e:7e:d0:c1:30:1b:39:bc:cf:b2:
         81:f3:73:af:72:6d:8a:fb:be:5c:c2:de:10:f5:ae:10:e4:d6:
         6b:cd:04:10:55:f2:81:71:a5:bb:6a:fc:b2:05:91:9a:33:2e:
         74:85:e2:58:78:56:a8:76:89:d6:05:38:dc:58:25:70:e0:49:
         44:b8:45:97:c5:42:c0:3c:ff:d8:a5:7d:60:b6:dd:fc:3d:69:
         d6:d1:31:82


Thanks!

Regards,
Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>

From whippet0 at gmail.com  Fri Jan  8 21:35:05 2021
From: whippet0 at gmail.com (George)
Date: Fri, 8 Jan 2021 16:35:05 -0500
Subject: private key not available for client_cert_cb
In-Reply-To: <640febc7-2499-2284-6625-b7a899ad66ea@nikhef.nl>
References: <292d3b25-9197-4977-a406-0a19abc15a0d@gmail.com>
 <BN8PR18MB2692D804F062DDDCA66D3D24F9C70@BN8PR18MB2692.namprd18.prod.outlook.com>
 <57a1488f-cc91-4c3a-5cee-4ad6c24565d6@gmail.com>
 <BN8PR18MB269202BE32C14ACB482E015DF9C70@BN8PR18MB2692.namprd18.prod.outlook.com>
 <7a3428c6-04ab-672e-b738-67680f9fc036@gmail.com>
 <e015a686-88b2-e483-a7da-53e9efabd9fc@nikhef.nl>
 <30032dde-70d1-d438-86ae-77f04a8179cf@gmail.com>
 <2495b1de-13d0-8777-56b0-46ac80cd0203@nikhef.nl>
 <5887cae2-1ecb-4081-1ee9-bcf566a88afe@gmail.com>
 <8011726e-0a7a-a753-983d-b89a24e3e225@nikhef.nl>
 <ab55a9e8-8bd3-c353-3922-1cae88349cb8@gmail.com>
 <8038268f-fd47-1ef8-7dec-ce365b0d453e@nikhef.nl>
 <00492ef8-67aa-8848-97fe-65cf2ba3b38f@gmail.com>
 <e8d14828-97aa-a1ee-52e2-36e124978cc6@nikhef.nl>
 <3e6e027f-812a-ea2d-2d2e-435ad52852b1@gmail.com>
 <471b029c-420c-e45e-d827-ba0576f22847@nikhef.nl>
 <1b20aba6-b88f-2ee1-af0d-23ae19c0746f@gmail.com>
 <640febc7-2499-2284-6625-b7a899ad66ea@nikhef.nl>
Message-ID: <95f017bb-6946-f37d-e585-05367f0e2da7@gmail.com>

Hi,

 ?? I have been trying to setup mutual authentication using a smart card 
but I can't seem to get the OpenSSL Engine to send a response back to 
the server containing client's certificate from the smart card.

I'm using the following to configure the certificate and private key:

 ??? ENGINE_ctrl_cmd(engine, "LOAD_CERT_CTRL", 0, &cert_info, NULL, 0);
 ??? SSL_CTX_use_certificate(sslContext, cert_info.cert);

 ??? EVP_PKEY* privateKey = ENGINE_load_private_key(engine, 
"2b2586c684d69b670c0a805edf514e720f2b757d8e2faa0b3a7ff23d1ccfc7ba", 
transfer_pin, &cb_data);
 ??? SSL_CTX_use_PrivateKey(sslContext, privateKey);

(I have been using the code in 
https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c? as a guide.)

This seems be successful. However, when I start the mutual 
authentication with
SSL_connect(ssl)
, the mutual authentications handshake fails. I can see the server 
requesting the certificate from the client and the client sends back an 
ACK for this message. However, the client does not send the certificate 
to the server.

I was looking through the OpenSSL code openssl-1.0.2u\ssl\ssl_rsa.c and 
noticed something interesting. The comment indicates that the flag 
*RSA_METHOD_FLAG_NO_CHECK* should be set for smart cards:

static int ssl_set_pkey(CERT *c, EVP_PKEY *pkey)
{
 ?. . .
#ifndef OPENSSL_NO_RSA
*?? /***
**???????? * Don't check the public/private key, this is mostly for smart**
**???????? * cards.**
**???????? */*
 ??????? if ((pkey->type == EVP_PKEY_RSA) &&
 ??????????? (RSA_flags(pkey->pkey.rsa) & RSA_METHOD_FLAG_NO_CHECK)) ;
 ??????? else
#endif
. . .
}

However, it is not actually set when I use a debugger to inspect the 
flag. Does it need to be set? If so, how is this done? I could not find 
anything related to this in
https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c




Thanks,
George


On 2021-01-05 11:51 a.m., Jan Just Keijser wrote:
> Hi,
>
> On 05/01/21 07:39, George wrote:
>> Hi,
>>
>> ??? I was looking at the? code in 
>> https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c and 
>> realized I forgot to call ENGINE_ctrl_cmd(...) to setup 
>> "LOAD_CERT_CTRL". However, when I do this, the callback function is 
>> no longer being called during the mutual authentication handshake. 
>> I'm wondering if I have the parameter "cert_info.s_slot_cert_id" 
>> incorrectly configured. Here is what my code looks like:
>>
>>     struct
>>     {
>>     ?? const char* s_slot_cert_id;
>>     ?? X509* cert;
>>     } cert_info;
>>     *cert_info.s_slot_cert_id =
>>     "a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45";*
>>     cert_info.cert = NULL;
>>
>>     *ENGINE_ctrl_cmd(engine, "LOAD_CERT_CTRL", 0, &cert_info, NULL, 0);*
>>     *SSL_CTX_use_certificate(sslContext, cert_info.cert);*
>>
>>
>> I tried manually using LOAD_CERT_CTRL in the openssl shell but I 
>> cannot seem to get it to work and cannot find any examples of how to 
>> use it.? Is the syntax for *LOAD_CERT_CTRL* correct? I am 
>> using***"LOAD_CERT_CTRL:<certificate Object ID>".*
>>
>>     OpenSSL> engine -vvvv -t dynamic -pre
>>     "SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll"
>>     -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre
>>     "MODULE_PATH:C:\Program Files (x86)\HID
>>     Global\ActivClient\\acpkcs211.dll" -pre PIN:123456 -pre
>>     FORCE_LOGIN *-pre
>>     "LOAD_CERT_CTRL:a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45"
>>
>>     *(dynamic) Dynamic engine loading support
>>     [Success]:
>>     SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll
>>     [Success]: ID:pkcs11
>>     [Success]: LIST_ADD:1
>>     [Success]: LOAD
>>     [Success]: MODULE_PATH:C:\Program Files (x86)\HID
>>     Global\ActivClient\\acpkcs211.dll
>>     [Success]: PIN:123456
>>     [Success]: FORCE_LOGIN
>>     *[Failure]:
>>     LOAD_CERT_CTRL:a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45**
>>     **4196:error:260AB086:engine routines:ENGINE_ctrl_cmd_string:cmd
>>     not executable:.\crypto\engine\eng_ctrl.c:316:*
>>     Loaded: (pkcs11) pkcs11 engine
>>     ???? [ available ]
>>     ???? SO_PATH: Specifies the path to the 'pkcs11' engine shared
>>     library
>>     ????????? (input flags): STRING
>>     ???? MODULE_PATH: Specifies the path to the PKCS#11 module shared
>>     library
>>     ????????? (input flags): STRING
>>     ???? PIN: Specifies the pin code
>>     ????????? (input flags): STRING
>>     ???? VERBOSE: Print additional details
>>     ????????? (input flags): NO_INPUT
>>     ???? QUIET: Remove additional details
>>     ????????? (input flags): NO_INPUT
>>     *LOAD_CERT_CTRL: Get the certificate from card**
>>     **????????? (input flags): [Internal]*
>>     ???? INIT_ARGS: Specifies additional initialization arguments to
>>     the PKCS#11 module
>>     ????????? (input flags): STRING
>>     ???? SET_USER_INTERFACE: Set the global user interface (internal)
>>     ????????? (input flags): [Internal]
>>     ???? SET_CALLBACK_DATA: Set the global user interface extra data
>>     (internal)
>>     ????????? (input flags): [Internal]
>>     ???? FORCE_LOGIN: Force login to the PKCS#11 module
>>     ????????? (input flags): NO_INPUT
>>     OpenSSL>
>>
>>
>> I'm using the certificate object ID 
>> "a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45" 
>> for LOAD_CERT_CTRL. Is this right? (I also tried adding "0:" in front 
>> of it to indicate slot 0, but that did not work either.
>
>
> this has little to do with OpenSSL at the moment and more with libp11 
> - perhaps someone more knowledgable on the libp11 mailing list can 
> help you.
>
> I'd try to use
> ? -post LOAD_CERT_CTRL
> instead of '-pre', as you want this done after the engine has been loaded.
>
> The cert ID does look OK. Note that if you want to use the s_client 
> command that you canNOT specify the certificate form '-certform 
> engine' as the code does not grok that.
>
> HTH,
>
> JJK
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210108/38ba9a5d/attachment.html>

From openssl-users at dukhovni.org  Fri Jan  8 21:44:34 2021
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 8 Jan 2021 16:44:34 -0500
Subject: no suitable signature algorithm during handshake failure
In-Reply-To: <FA609BEBBD8DB0BF6D3D9FF9@[192.168.1.156]>
References: <9E4638FBE468D8E17C07505F@[192.168.1.156]>
 <X/e7v34PREGwfQJW@straasha.imrryr.org>
 <FA609BEBBD8DB0BF6D3D9FF9@[192.168.1.156]>
Message-ID: <X/jSQgZIvC8kQUIB@straasha.imrryr.org>

On Fri, Jan 08, 2021 at 12:05:26PM -0800, Quanah Gibson-Mount wrote:

> >     https://www.spinics.net/lists/openssl-users/msg05623.html
> 
> Thanks Viktor.  Mainly, I wasn't sure what specific information would be 
> necessary.  Here's what wireshark shows (IP addresses obfuscated):

It would be really helpful (also to you) if you install a more
up-to-date version of tshark, or copy the pcap file to a machine
that already has one.  The version used below fails to understand
many relevant modern TLS extensions/features.

See annotations added:

> Secure Sockets Layer
>     TLSv1.2 Record Layer: Handshake Protocol: Client Hello
>         Content Type: Handshake (22)
>         Version: TLS 1.2 (0x0303)
>         Length: 423
>         Handshake Protocol: Client Hello
>             Handshake Type: Client Hello (1)
>             Length: 419
>             Version: TLS 1.2 (0x0303)
>             Random
>                 GMT Unix Time: Oct  2, 2014 19:22:16.000000000 MDT
>                 Random Bytes: 3226c3627d2ba7c967ce2cf097e616d9cbe45d1bb1cc21f4...
>             Session ID Length: 32
>             Session ID: bde8c16349a08e56a121b6e7aa1f317acf42186ba79b134d...
>             Cipher Suites Length: 88
>             Cipher Suites (44 suites)
> -->             Cipher Suite: Unknown (0x1301)        -- i.e. TLS_AES_128_GCM_SHA256
> -->             Cipher Suite: Unknown (0x1302)        -- i.e. TLS_AES_256_GCM_SHA384
>                 Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
>                 Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
>                 Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
>                 Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
>                 Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02e)
>                 Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (0xc032)
>                 Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
>                 Cipher Suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3)
>                 Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
>                 Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
>                 Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02d)
>                 Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031)
>                 Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
>                 Cipher Suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2)
>                 Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
>                 Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
>                 Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
>                 Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026)
>                 Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a)
>                 Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
>                 Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
>                 Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
>                 Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
>                 Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
>                 Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)
>                 Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)
>                 Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
>                 Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
>                 Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
>                 Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
>                 Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
>                 Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025)
>                 Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029)
>                 Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
>                 Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
>                 Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
>                 Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
>                 Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
>                 Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)
>                 Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)
>                 Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
>                 Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
>             Compression Methods Length: 1
>             Compression Methods (1 method)
>             Extensions Length: 258
>             Extension: server_name
>                 Type: server_name (0x0000)
>                 Length: 35
>                 Server Name Indication extension
>                     Server Name list length: 33
>                     Server Name Type: host_name (0)
>                     Server Name length: 30
>                     Server Name: directory.srv.TEST.ualberta.ca
>             Extension: status_request
>                 Type: status_request (0x0005)
>                 Length: 5
>                 Certificate Status Type: OCSP (1)
>                 Responder ID list Length: 0
>                 Request Extensions Length: 0
>             Extension: elliptic_curves
>                 Type: elliptic_curves (0x000a)
>                 Length: 32
>                 Elliptic Curves Length: 30
>                 Elliptic curves (15 curves)
>             Extension: ec_point_formats
>                 Type: ec_point_formats (0x000b)
>                 Length: 2
>                 EC point formats Length: 1
>                 Elliptic curves point formats (1)
>             Extension: signature_algorithms
>                 Type: signature_algorithms (0x000d)
>                 Length: 22
>                 Signature Hash Algorithms Length: 20
>                 Signature Hash Algorithms (10 algorithms)
>                     Signature Hash Algorithm: 0x0403
>                         Signature Hash Algorithm Hash: SHA256 (4)
>                         Signature Hash Algorithm Signature: ECDSA (3)
>                     Signature Hash Algorithm: 0x0503
>                         Signature Hash Algorithm Hash: SHA384 (5)
>                         Signature Hash Algorithm Signature: ECDSA (3)
>                     Signature Hash Algorithm: 0x0603
>                         Signature Hash Algorithm Hash: SHA512 (6)
>                         Signature Hash Algorithm Signature: ECDSA (3)
>                     Signature Hash Algorithm: 0x0401
>                         Signature Hash Algorithm Hash: SHA256 (4)
>                         Signature Hash Algorithm Signature: RSA (1)
>                     Signature Hash Algorithm: 0x0501
>                         Signature Hash Algorithm Hash: SHA384 (5)
>                         Signature Hash Algorithm Signature: RSA (1)
>                     Signature Hash Algorithm: 0x0601
>                         Signature Hash Algorithm Hash: SHA512 (6)
>                         Signature Hash Algorithm Signature: RSA (1)
>                     Signature Hash Algorithm: 0x0402
>                         Signature Hash Algorithm Hash: SHA256 (4)
>                         Signature Hash Algorithm Signature: DSA (2)
>                     Signature Hash Algorithm: 0x0203
>                         Signature Hash Algorithm Hash: SHA1 (2)
>                         Signature Hash Algorithm Signature: ECDSA (3)
>                     Signature Hash Algorithm: 0x0201
>                         Signature Hash Algorithm Hash: SHA1 (2)
>                         Signature Hash Algorithm Signature: RSA (1)
>                     Signature Hash Algorithm: 0x0202
>                         Signature Hash Algorithm Hash: SHA1 (2)
>                         Signature Hash Algorithm Signature: DSA (2)
>             Extension: Unknown 50
>                 Type: Unknown (0x0032)
>                 Length: 22
>                 Data (22 bytes)
>             Extension: status_request_v2
>                 Type: status_request_v2 (0x0011)
>                 Length: 9
>                 Certificate Status Type: OCSP Multi (2)
>                 Certificate Status Length: 4
>                 Responder ID list Length: 0
>                 Request Extensions Length: 0
>             Extension: Extended Master Secret
>                 Type: Extended Master Secret (0x0017)
>                 Length: 0
> ! --->      Extension: Unknown 43         -- i.e. supported_versions!
>                 Type: Unknown (0x002b)    -- Almost certainly w/ TLS 1.3
>                 Length: 9
>                 Data (9 bytes)
> ! --->      Extension: Unknown 45         -- psk_key_exchange_modes
>                 Type: Unknown (0x002d)    -- a TLS 1.3 feature
>                 Length: 2
>                 Data (2 bytes)
> ! --->      Extension: Unknown 51         -- key_share
>                 Type: Unknown (0x0033)    -- a TLS 1.3 feature
>                 Length: 71
>                 Data (71 bytes)
>             Extension: renegotiation_info
>                 Type: renegotiation_info (0xff01)
>                 Length: 1
>                 Renegotiation Info extension
>                     Renegotiation info extension length: 0

The client almost certainly offered TLS 1.3 (via supported_versions),
but failed to offer a TLS 1.3-compatible RSA signature algorithm.

    https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme

Among the signature algorithms offered by the client:

>                     Signature Hash Algorithm: 0x02,01 -- rsa_pkcs1_sha1
>                     Signature Hash Algorithm: 0x04,01 -- rsa_pkcs1_sha256
>                     Signature Hash Algorithm: 0x05,01 -- rsa_pkcs1_sha384
>                     Signature Hash Algorithm: 0x06,01 -- rsa_pkcs1_sha512
>                     Signature Hash Algorithm: 0x02,02 -- dsa_sha1
>                     Signature Hash Algorithm: 0x04,02 -- dsa_sha256
>                     Signature Hash Algorithm: 0x02,03 -- ecdsa_sha1
>                     Signature Hash Algorithm: 0x04,03 -- ecdsa_secp256r1_sha256
>                     Signature Hash Algorithm: 0x05,03 -- ecdsa_secp256r1_sha384
>                     Signature Hash Algorithm: 0x06,03 -- ecdsa_secp256r1_sha512

None were PSS, and RFC 8446 says:

   In addition, the signature algorithm MUST be compatible with the key
   in the sender's end-entity certificate.  RSA signatures MUST use an
   RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5
   algorithms appear in "signature_algorithms".  The SHA-1 algorithm
   MUST NOT be used in any signatures of CertificateVerify messages.

> > What sort of certificate does the server have.  Are there any ssl module
> > settings in its openssl.cnf file?
> 
> no module settings for openssl.cnf.
> 
> For the server with the non-working cert, this is the x509 text output:
> 
> Certificate:
>     Data:
>         Version: 3 (0x2)
>         Serial Number:
>             ---
>     Signature Algorithm: sha256WithRSAEncryption
>         Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign RSA OV SSL CA 2018
>         Validity
>             Not Before: Mar 26 17:49:45 2020 GMT
>             Not After : Apr 30 21:21:03 2022 GMT
>         Subject: C=CA, ST=Alberta, L=---
>         Subject Public Key Info:
>             Public Key Algorithm: rsaEncryption

The certificate does not require PSS, but TLS 1.3 does.

-- 
    Viktor.

From Michael.Wojcik at microfocus.com  Fri Jan  8 23:32:59 2021
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 8 Jan 2021 23:32:59 +0000
Subject: private key not available for client_cert_cb
In-Reply-To: <95f017bb-6946-f37d-e585-05367f0e2da7@gmail.com>
References: <292d3b25-9197-4977-a406-0a19abc15a0d@gmail.com>
 <BN8PR18MB2692D804F062DDDCA66D3D24F9C70@BN8PR18MB2692.namprd18.prod.outlook.com>
 <57a1488f-cc91-4c3a-5cee-4ad6c24565d6@gmail.com>
 <BN8PR18MB269202BE32C14ACB482E015DF9C70@BN8PR18MB2692.namprd18.prod.outlook.com>
 <7a3428c6-04ab-672e-b738-67680f9fc036@gmail.com>
 <e015a686-88b2-e483-a7da-53e9efabd9fc@nikhef.nl>
 <30032dde-70d1-d438-86ae-77f04a8179cf@gmail.com>
 <2495b1de-13d0-8777-56b0-46ac80cd0203@nikhef.nl>
 <5887cae2-1ecb-4081-1ee9-bcf566a88afe@gmail.com>
 <8011726e-0a7a-a753-983d-b89a24e3e225@nikhef.nl>
 <ab55a9e8-8bd3-c353-3922-1cae88349cb8@gmail.com>
 <8038268f-fd47-1ef8-7dec-ce365b0d453e@nikhef.nl>
 <00492ef8-67aa-8848-97fe-65cf2ba3b38f@gmail.com>
 <e8d14828-97aa-a1ee-52e2-36e124978cc6@nikhef.nl>
 <3e6e027f-812a-ea2d-2d2e-435ad52852b1@gmail.com>
 <471b029c-420c-e45e-d827-ba0576f22847@nikhef.nl>
 <1b20aba6-b88f-2ee1-af0d-23ae19c0746f@gmail.com>
 <640febc7-2499-2284-6625-b7a899ad66ea@nikhef.nl>
 <95f017bb-6946-f37d-e585-05367f0e2da7@gmail.com>
Message-ID: <DM6PR18MB2700D51CA007871717F6C533F9AE9@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of George
> Sent: Friday, 8 January, 2021 14:35

> The comment indicates that the flag RSA_METHOD_FLAG_NO_CHECK should be set
> for smart cards[...]

> However, it is not actually set when I use a debugger to inspect the flag.
> Does it need to be set? If so, how is this done?

If memory serves, the PKCS#11 implementation invoked by the pkcs11 engine is supposed to set it.

See for example this patch to OpenSC's pkcs11-helper library:

https://github.com/OpenSC/pkcs11-helper/commit/5198bb1e557dfd4109bea41c086825bf6ebdd9f3

(That patch actually is to set a different flag, but it shows the code in question.)

I know, that's probably not terribly helpful.

If you do a web search for something like

        pkcs11 "RSA_METHOD_FLAG_NO_CHECK"

you'll probably find a number of hits where other people ran into similar problems.

Isn't PKCS#11 grand? If you're bored with all the interoperability problems of X.509, PKIX, and TLS, we have good news!

--
Michael Wojcik

From quanah at symas.com  Fri Jan  8 23:56:55 2021
From: quanah at symas.com (Quanah Gibson-Mount)
Date: Fri, 08 Jan 2021 15:56:55 -0800
Subject: no suitable signature algorithm during handshake failure
In-Reply-To: <X/jSQgZIvC8kQUIB@straasha.imrryr.org>
References: <9E4638FBE468D8E17C07505F@[192.168.1.156]>
 <X/e7v34PREGwfQJW@straasha.imrryr.org>
 <FA609BEBBD8DB0BF6D3D9FF9@[192.168.1.156]>
 <X/jSQgZIvC8kQUIB@straasha.imrryr.org>
Message-ID: <54AAACC734593F80D2267FDE@[192.168.1.156]>



--On Friday, January 8, 2021 4:44 PM -0500 Viktor Dukhovni 
<openssl-users at dukhovni.org> wrote:

Hi Viktor,

> On Fri, Jan 08, 2021 at 12:05:26PM -0800, Quanah Gibson-Mount wrote:
>
>> >     https://www.spinics.net/lists/openssl-users/msg05623.html
>>
>> Thanks Viktor.  Mainly, I wasn't sure what specific information would be
>> necessary.  Here's what wireshark shows (IP addresses obfuscated):
>
> It would be really helpful (also to you) if you install a more
> up-to-date version of tshark, or copy the pcap file to a machine
> that already has one.  The version used below fails to understand
> many relevant modern TLS extensions/features.

I've relayed this to our client. ;)

>> ! --->      Extension: Unknown 43         -- i.e. supported_versions!
>>                 Type: Unknown (0x002b)    -- Almost certainly w/ TLS 1.3
>>                 Length: 9
>>                 Data (9 bytes)
>> ! --->      Extension: Unknown 45         -- psk_key_exchange_modes
>>                 Type: Unknown (0x002d)    -- a TLS 1.3 feature
>>                 Length: 2
>>                 Data (2 bytes)
>> ! --->      Extension: Unknown 51         -- key_share
>>                 Type: Unknown (0x0033)    -- a TLS 1.3 feature


I ran their pcap through my own updated version of tshark, and indeed:

            Extension: status_request_v2 (len=9)
                Type: status_request_v2 (17)
                Length: 9
                Certificate Status List Length: 7
                Certificate Status Type: OCSP Multi (2)
                Certificate Status Length: 4
                Responder ID list Length: 0
                Request Extensions Length: 0
            Extension: extended_master_secret (len=0)
                Type: extended_master_secret (23)
                Length: 0
            Extension: supported_versions (len=9)
                Type: supported_versions (43)
                Length: 9
                Supported Versions length: 8
                Supported Version: TLS 1.3 (0x0304)
                Supported Version: TLS 1.2 (0x0303)
                Supported Version: TLS 1.1 (0x0302)
                Supported Version: TLS 1.0 (0x0301)
            Extension: psk_key_exchange_modes (len=2)
                Type: psk_key_exchange_modes (45)
                Length: 2
                PSK Key Exchange Modes Length: 1
                PSK Key Exchange Mode: PSK with (EC)DHE key establishment 
(psk_dhe_ke) (1)
            Extension: key_share (len=71)
                Type: key_share (51)
                Length: 71
                Key Share extension
                    Client Key Share Length: 69
                    Key Share Entry: Group: secp256r1, Key Exchange length: 
65
                        Group: secp256r1 (23)
                        Key Exchange Length: 65
                        Key Exchange: 
04524e56171cf3e75903228cf4cc02687df2698bd43d167f?


> None were PSS, and RFC 8446 says:
>
>    In addition, the signature algorithm MUST be compatible with the key
>    in the sender's end-entity certificate.  RSA signatures MUST use an
>    RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5
>    algorithms appear in "signature_algorithms".  The SHA-1 algorithm
>    MUST NOT be used in any signatures of CertificateVerify messages.
>
>> > What sort of certificate does the server have.  Are there any ssl
>> > module settings in its openssl.cnf file?

> The certificate does not require PSS, but TLS 1.3 does.

Great, thanks so much for the help! I learned some along the way, which is 
always a good thing. :)

Regards,
Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>

From steffen at sdaoden.eu  Sat Jan  9 23:24:36 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sun, 10 Jan 2021 00:24:36 +0100
Subject: SSL_CONF_cmd(): SecurityLevel keyword, by chance?
Message-ID: <20210109232436.EqSFj%steffen@sdaoden.eu>

Hello.

I do use SSL_CONF_cmd() (and modules) possibility if it exists,
since it allow users to simply use the features of the newest
OpenSSL library without any code changes on my side.
This is great, and i think i applauded in the past.

I discovered security_level(), needless to say i thought
@SECLEVEL= of ciphers(1) was broken until i discovered -s is
required to make it functional (..and do not get me started on
-ciphersuites..).

Wouldn't it make sense to offer SecurityLevel as a keyword for
SSL_CONF_cmd(), and therefore also SSL_CTX_config(), too -- since
it seems (from the manual) to extend to more than what i would
assume to be covered by a @SECLEVEL member of CipherString aka
..Ciphersuites...?

This seems desirable to me.  For now i will not offer
security_level because i would have to implement a special code
path to bypass SSL_CONF_cmd/SSL_CTX_config, which is used
exclusively if available.

Ciao and a good Sunday from Germany i wish,

(P.S.: i have not github account.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From jgh at wizmail.org  Sun Jan 10 14:44:38 2021
From: jgh at wizmail.org (Jeremy Harris)
Date: Sun, 10 Jan 2021 14:44:38 +0000
Subject: Fwd: channel binding
In-Reply-To: <53ac6b34-a380-047b-7fb2-5b8a6914963f@wizmail.org>
References: <53ac6b34-a380-047b-7fb2-5b8a6914963f@wizmail.org>
Message-ID: <51a518c5-330d-ac65-1da0-33d30192eba9@wizmail.org>

Hi,

What is the status of SSL_get_finidhed() / SSL_get_peer_finished() ?

I do not find them documented at
   https://www.openssl.org/docs/manmaster/man3/

but they are exported by the library and seem to be required, for
application channel-binding.
-- 
Cheers,
   Jeremy

From richard.simard at groupesti.com  Sun Jan 10 17:21:35 2021
From: richard.simard at groupesti.com (Richard Simard)
Date: Sun, 10 Jan 2021 17:21:35 +0000
Subject: Certificates Transparency list 
Message-ID: <QB1PR01MB34443FAEE29CEE92CEB8E13788AC0@QB1PR01MB3444.CANPRD01.PROD.OUTLOOK.COM>

I would like to know if among you, if anyone would have a good example in order to integrate a Certificates Transparency list into my certificates.

Tank You!
Richard Simard


From felipe at felipegasper.com  Sun Jan 10 18:04:20 2021
From: felipe at felipegasper.com (Felipe Gasper)
Date: Sun, 10 Jan 2021 13:04:20 -0500
Subject: Certificates Transparency list 
In-Reply-To: <QB1PR01MB34443FAEE29CEE92CEB8E13788AC0@QB1PR01MB3444.CANPRD01.PROD.OUTLOOK.COM>
References: <QB1PR01MB34443FAEE29CEE92CEB8E13788AC0@QB1PR01MB3444.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <42BAF80F-A8D8-45A7-8145-3F3758A14951@felipegasper.com>

In addition to however OpenSSL does it, you can see how it?s done here:

https://metacpan.org/release/Crypt-Perl/source/lib/Crypt/Perl/X509/Extension/ct_precert_scts.pm

https://metacpan.org/release/Crypt-Perl/source/lib/Crypt/Perl/X509/Extension/ct_precert_poison.pm

-F


> On Jan 10, 2021, at 12:21 PM, Richard Simard <richard.simard at groupesti.com> wrote:
> 
> I would like to know if among you, if anyone would have a good example in order to integrate a Certificates Transparency list into my certificates.
> 
> Tank You!
> Richard Simard
> 


From whippet0 at gmail.com  Mon Jan 11 04:01:28 2021
From: whippet0 at gmail.com (George)
Date: Sun, 10 Jan 2021 23:01:28 -0500
Subject: private key not available for client_cert_cb
In-Reply-To: <DM6PR18MB2700D51CA007871717F6C533F9AE9@DM6PR18MB2700.namprd18.prod.outlook.com>
References: <292d3b25-9197-4977-a406-0a19abc15a0d@gmail.com>
 <BN8PR18MB269202BE32C14ACB482E015DF9C70@BN8PR18MB2692.namprd18.prod.outlook.com>
 <7a3428c6-04ab-672e-b738-67680f9fc036@gmail.com>
 <e015a686-88b2-e483-a7da-53e9efabd9fc@nikhef.nl>
 <30032dde-70d1-d438-86ae-77f04a8179cf@gmail.com>
 <2495b1de-13d0-8777-56b0-46ac80cd0203@nikhef.nl>
 <5887cae2-1ecb-4081-1ee9-bcf566a88afe@gmail.com>
 <8011726e-0a7a-a753-983d-b89a24e3e225@nikhef.nl>
 <ab55a9e8-8bd3-c353-3922-1cae88349cb8@gmail.com>
 <8038268f-fd47-1ef8-7dec-ce365b0d453e@nikhef.nl>
 <00492ef8-67aa-8848-97fe-65cf2ba3b38f@gmail.com>
 <e8d14828-97aa-a1ee-52e2-36e124978cc6@nikhef.nl>
 <3e6e027f-812a-ea2d-2d2e-435ad52852b1@gmail.com>
 <471b029c-420c-e45e-d827-ba0576f22847@nikhef.nl>
 <1b20aba6-b88f-2ee1-af0d-23ae19c0746f@gmail.com>
 <640febc7-2499-2284-6625-b7a899ad66ea@nikhef.nl>
 <95f017bb-6946-f37d-e585-05367f0e2da7@gmail.com>
 <DM6PR18MB2700D51CA007871717F6C533F9AE9@DM6PR18MB2700.namprd18.prod.outlook.com>
Message-ID: <6ea69357-8457-32f4-8803-162c7ec3a29c@gmail.com>

Hi,

 ??? I had a look at the pkcs11-helper and can see where the 
RSA_METHOD_FLAG_NO_CHECK is being set. It's using a session object 
called pkcs11h_openssl_session_t, which I do not see in the libp11 or 
openSC code.

Right now I am using the "libp11" DLL (i.e. 
libp11-libp11-0.4.11\src\pkcs11.dll) with my PKCS11 smart card 
middleware DLL. Should I be using the OpenSC pkcs11 DLL instead of my 
middleware DLL if I am using libp1?

Do you know if it is normal to see exceptions related to the PKCS11 
function calls in the libp11 code? For example, I can see the following 
function generate an exception on C_GetSlotList(...) multiple times but 
it eventually is successful.? Is this normal behaviour?

int pkcs11_enumerate_slots(PKCS11_CTX *ctx, PKCS11_SLOT **slotp, 
unsigned int *countp)
{
. . .
 ??? rv = cpriv->method->C_GetSlotList(FALSE, NULL_PTR, &nslots);
. . .
}


Thanks,
George



On 2021-01-08 6:32 p.m., Michael Wojcik wrote:
>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of George
>> Sent: Friday, 8 January, 2021 14:35
>> The comment indicates that the flag RSA_METHOD_FLAG_NO_CHECK should be set
>> for smart cards[...]
>> However, it is not actually set when I use a debugger to inspect the flag.
>> Does it need to be set? If so, how is this done?
> If memory serves, the PKCS#11 implementation invoked by the pkcs11 engine is supposed to set it.
>
> See for example this patch to OpenSC's pkcs11-helper library:
>
> https://github.com/OpenSC/pkcs11-helper/commit/5198bb1e557dfd4109bea41c086825bf6ebdd9f3
>
> (That patch actually is to set a different flag, but it shows the code in question.)
>
> I know, that's probably not terribly helpful.
>
> If you do a web search for something like
>
>          pkcs11 "RSA_METHOD_FLAG_NO_CHECK"
>
> you'll probably find a number of hits where other people ran into similar problems.
>
> Isn't PKCS#11 grand? If you're bored with all the interoperability problems of X.509, PKIX, and TLS, we have good news!
>
> --
> Michael Wojcik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210110/081812a9/attachment.html>

From bkaduk at akamai.com  Mon Jan 11 08:20:38 2021
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Mon, 11 Jan 2021 00:20:38 -0800
Subject: Fwd: channel binding
In-Reply-To: <51a518c5-330d-ac65-1da0-33d30192eba9@wizmail.org>
References: <53ac6b34-a380-047b-7fb2-5b8a6914963f@wizmail.org>
 <51a518c5-330d-ac65-1da0-33d30192eba9@wizmail.org>
Message-ID: <20210111082038.GD9776@akamai.com>

On Sun, Jan 10, 2021 at 02:44:38PM +0000, Jeremy Harris wrote:
> Hi,
> 
> What is the status of SSL_get_finidhed() / SSL_get_peer_finished() ?
> 
> I do not find them documented at
>   https://urldefense.com/v3/__https://www.openssl.org/docs/manmaster/man3/__;!!GjvTz_vk!FUYwEktTkE4ZmFeJKSFeBQe32kr0I0dcFxh_MkPMjns_JZ71rpQTYGbTm08g6w$
> 
> but they are exported by the library and seem to be required, for
> application channel-binding.

Current recommendations are not to use the finished message as the channel
binding but instead to define key exporter label for the given usage
(see https://tools.ietf.org/html/rfc8446#section-7.5), using SSL_export_keying_material().

-Ben

From matt at openssl.org  Mon Jan 11 09:24:19 2021
From: matt at openssl.org (Matt Caswell)
Date: Mon, 11 Jan 2021 09:24:19 +0000
Subject: SSL_CONF_cmd(): SecurityLevel keyword, by chance?
In-Reply-To: <20210109232436.EqSFj%steffen@sdaoden.eu>
References: <20210109232436.EqSFj%steffen@sdaoden.eu>
Message-ID: <eea19b85-2030-15ed-c1d0-d8594c8cd097@openssl.org>



On 09/01/2021 23:24, Steffen Nurpmeso wrote:
> Hello.
> 
> I do use SSL_CONF_cmd() (and modules) possibility if it exists,
> since it allow users to simply use the features of the newest
> OpenSSL library without any code changes on my side.
> This is great, and i think i applauded in the past.
> 
> I discovered security_level(), needless to say i thought
> @SECLEVEL= of ciphers(1) was broken until i discovered -s is
> required to make it functional (..and do not get me started on
> -ciphersuites..).
> 
> Wouldn't it make sense to offer SecurityLevel as a keyword for
> SSL_CONF_cmd(), and therefore also SSL_CTX_config(), too -- since
> it seems (from the manual) to extend to more than what i would
> assume to be covered by a @SECLEVEL member of CipherString aka
> ..Ciphersuites...?

This is probably a good idea. I'd support it if someone wanted to add that.

Matt


From Michael.Wojcik at microfocus.com  Mon Jan 11 14:41:01 2021
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Mon, 11 Jan 2021 14:41:01 +0000
Subject: private key not available for client_cert_cb
In-Reply-To: <6ea69357-8457-32f4-8803-162c7ec3a29c@gmail.com>
References: <292d3b25-9197-4977-a406-0a19abc15a0d@gmail.com>
 <BN8PR18MB269202BE32C14ACB482E015DF9C70@BN8PR18MB2692.namprd18.prod.outlook.com>
 <7a3428c6-04ab-672e-b738-67680f9fc036@gmail.com>
 <e015a686-88b2-e483-a7da-53e9efabd9fc@nikhef.nl>
 <30032dde-70d1-d438-86ae-77f04a8179cf@gmail.com>
 <2495b1de-13d0-8777-56b0-46ac80cd0203@nikhef.nl>
 <5887cae2-1ecb-4081-1ee9-bcf566a88afe@gmail.com>
 <8011726e-0a7a-a753-983d-b89a24e3e225@nikhef.nl>
 <ab55a9e8-8bd3-c353-3922-1cae88349cb8@gmail.com>
 <8038268f-fd47-1ef8-7dec-ce365b0d453e@nikhef.nl>
 <00492ef8-67aa-8848-97fe-65cf2ba3b38f@gmail.com>
 <e8d14828-97aa-a1ee-52e2-36e124978cc6@nikhef.nl>
 <3e6e027f-812a-ea2d-2d2e-435ad52852b1@gmail.com>
 <471b029c-420c-e45e-d827-ba0576f22847@nikhef.nl>
 <1b20aba6-b88f-2ee1-af0d-23ae19c0746f@gmail.com>
 <640febc7-2499-2284-6625-b7a899ad66ea@nikhef.nl>
 <95f017bb-6946-f37d-e585-05367f0e2da7@gmail.com>
 <DM6PR18MB2700D51CA007871717F6C533F9AE9@DM6PR18MB2700.namprd18.prod.outlook.com>
 <6ea69357-8457-32f4-8803-162c7ec3a29c@gmail.com>
Message-ID: <DM6PR18MB270035C69BEEB9E0DBAFE706F9AB9@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of George
> Sent: Sunday, 10 January, 2021 21:01

> Right now I am using the "libp11" DLL (i.e. libp11-libp11-0.4.11\src\pkcs11.dll)
> with my PKCS11 smart card middleware DLL. Should I be using the OpenSC pkcs11 DLL
> instead of my middleware DLL if I am using libp1?

Honestly, I have no idea. It's been years since I worked with PKCS#11, and then I was using a single piece of test hardware. I got it working with OpenSSL using the OpenSC modules, but that may have been specific to my case.

> Do you know if it is normal to see exceptions related to the PKCS11 function calls
> in the libp11 code? For example, I can see  the following function generate an
> exception on C_GetSlotList(...) multiple times but it eventually is successful.
> Is this normal behaviour?

What sort of "exception"? A Windows exception? UNIX signal? C++ exception?

My initial guess would be that this is a timing issue - maybe the device needs some time to become available, for example. But that's just a guess. Maybe someone with more experience with a variety of HSMs and PKCS#11 will weigh in.

--
Michael Wojcik

From janjust at nikhef.nl  Mon Jan 11 16:01:56 2021
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Mon, 11 Jan 2021 17:01:56 +0100
Subject: private key not available for client_cert_cb
In-Reply-To: <95f017bb-6946-f37d-e585-05367f0e2da7@gmail.com>
References: <292d3b25-9197-4977-a406-0a19abc15a0d@gmail.com>
 <57a1488f-cc91-4c3a-5cee-4ad6c24565d6@gmail.com>
 <BN8PR18MB269202BE32C14ACB482E015DF9C70@BN8PR18MB2692.namprd18.prod.outlook.com>
 <7a3428c6-04ab-672e-b738-67680f9fc036@gmail.com>
 <e015a686-88b2-e483-a7da-53e9efabd9fc@nikhef.nl>
 <30032dde-70d1-d438-86ae-77f04a8179cf@gmail.com>
 <2495b1de-13d0-8777-56b0-46ac80cd0203@nikhef.nl>
 <5887cae2-1ecb-4081-1ee9-bcf566a88afe@gmail.com>
 <8011726e-0a7a-a753-983d-b89a24e3e225@nikhef.nl>
 <ab55a9e8-8bd3-c353-3922-1cae88349cb8@gmail.com>
 <8038268f-fd47-1ef8-7dec-ce365b0d453e@nikhef.nl>
 <00492ef8-67aa-8848-97fe-65cf2ba3b38f@gmail.com>
 <e8d14828-97aa-a1ee-52e2-36e124978cc6@nikhef.nl>
 <3e6e027f-812a-ea2d-2d2e-435ad52852b1@gmail.com>
 <471b029c-420c-e45e-d827-ba0576f22847@nikhef.nl>
 <1b20aba6-b88f-2ee1-af0d-23ae19c0746f@gmail.com>
 <640febc7-2499-2284-6625-b7a899ad66ea@nikhef.nl>
 <95f017bb-6946-f37d-e585-05367f0e2da7@gmail.com>
Message-ID: <1b5335f6-0350-1acc-e019-cc58f50f5043@nikhef.nl>

Hi,

On 08/01/21 22:35, George wrote:
> Hi,
>
> ?? I have been trying to setup mutual authentication using a smart 
> card but I can't seem to get the OpenSSL Engine to send a response 
> back to the server containing client's certificate from the smart card.
>
> I'm using the following to configure the certificate and private key:
>
> ??? ENGINE_ctrl_cmd(engine, "LOAD_CERT_CTRL", 0, &cert_info, NULL, 0);
> ??? SSL_CTX_use_certificate(sslContext, cert_info.cert);
>
> ??? EVP_PKEY* privateKey = ENGINE_load_private_key(engine, 
> "2b2586c684d69b670c0a805edf514e720f2b757d8e2faa0b3a7ff23d1ccfc7ba", 
> transfer_pin, &cb_data);
> ??? SSL_CTX_use_PrivateKey(sslContext, privateKey);
>
> (I have been using the code in 
> https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c as a guide.)
>
> This seems be successful. However, when I start the mutual 
> authentication with
> SSL_connect(ssl)
> , the mutual authentications handshake fails. I can see the server 
> requesting the certificate from the client and the client sends back 
> an ACK for this message. However, the client does not send the 
> certificate to the server.
>
> I was looking through the OpenSSL code openssl-1.0.2u\ssl\ssl_rsa.c 
> and noticed something interesting. The comment indicates that the flag 
> *RSA_METHOD_FLAG_NO_CHECK* should be set for smart cards:
>
> static int ssl_set_pkey(CERT *c, EVP_PKEY *pkey)
> {
> ?. . .
> #ifndef OPENSSL_NO_RSA
> *?? /***
> **???????? * Don't check the public/private key, this is mostly for 
> smart**
> **???????? * cards.**
> **???????? */*
> ??????? if ((pkey->type == EVP_PKEY_RSA) &&
> ??????????? (RSA_flags(pkey->pkey.rsa) & RSA_METHOD_FLAG_NO_CHECK)) ;
> ??????? else
> #endif
> . . .
> }
>
> However, it is not actually set when I use a debugger to inspect the 
> flag. Does it need to be set? If so, how is this done? I could not 
> find anything related to this in
> https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c


if you read through the code blob that Michael pointed you to, you will 
find that this flag needs to be set *under certain circumstances* when 
using smartcards. It has to do mostly with the situation where
- private key is on the smart card
- the public key/certificate is NOT on the smart card
- you ask OpenSSL to verify the private key without explicitly providing 
a public key.

I've never run into this issue, but then again, I have not tested very 
often the case where the certificate was not present on the HSM/smart 
card but the private key is.? YMMV.

As for using pksc11helper versus using libp11: that is just a matter of 
taste. I used the engine_pkcs11 + libp11 route for the eap-tls code , 
mostly because it was the first "working" set of tools I found at the time.

You can also take the "pkcs11helper" route, which is what OpenVPN does 
(see https://github.com/openvpn).? Both methods have pro's and con's.

Do you run into problems if you DO not set the RSA_METHOD_FLAG_NO_CHECK 
flag?? All that flag does is to stop OpenSSL from verifying that a 
public key/cert and private key match/belong together for RSA keys only; 
if your smartcard supports EC keys then this flag will do you no good.

HTH,

JJK

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210111/4880dcd6/attachment.html>

From tiolangit at outlook.com  Mon Jan 11 17:56:19 2021
From: tiolangit at outlook.com (Timo Lange)
Date: Mon, 11 Jan 2021 17:56:19 +0000
Subject: Sign without having the private key
Message-ID: <DB8PR04MB56733EE962D7392D49E54819FDAB0@DB8PR04MB5673.eurprd04.prod.outlook.com>

Hey all,

I have a question similar to http://openssl.6102.n7.nabble.com/private-key-not-available-for-client-cert-cb-td79369.html, that I am actively following, but though it differs in detail.

What I want to achieve is the following:
My client applications runs inside a container and needs to establish a mutual TLS connection to a server.
The client certificate is available in the container.
The root certificate, as well as the client private key is not available inside the container, but stored in a HSM.
For sure the private key may never leave the HSM and also the root certificate should not.

The application cannot directly interfere with the HSM through standardized mechanisms as it is not accessible from inside the container.
For doing so a proprietary interprocess-communication is required.

I now want something like a "verify callback" and a "sign callback".

The "verify callback" would be needed in order to verify the server certificate against the root certificate. It seems to be easy using: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_cert_verify_callback.html

I need the same, something like a "sign callback" also for the private key, when a signature is required during handshake. Such that requests from openSSL to sign something can be forwarded through the inter-process-communication into the HSM. So that the actual signing happens there.
This would only be required during handshake. For the actual encryption symmetric keys can be used, such that the encryption takes place in the openSSL library, not in the HSM.

I assume I need to write a custom ENGINE, but failed with all my approaches.

Can someone give me brief hint on where to start and which API to look at first?

Thanks a lot!
Timo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210111/11ebb7b3/attachment.html>

From beldmit at gmail.com  Mon Jan 11 18:00:25 2021
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Mon, 11 Jan 2021 19:00:25 +0100
Subject: Sign without having the private key
In-Reply-To: <DB8PR04MB56733EE962D7392D49E54819FDAB0@DB8PR04MB5673.eurprd04.prod.outlook.com>
References: <DB8PR04MB56733EE962D7392D49E54819FDAB0@DB8PR04MB5673.eurprd04.prod.outlook.com>
Message-ID: <CADqLbz+xG4rWcoNpKkz0Ec9SYL8Y0cwa_HOrR4zNdPpJkUtX0Q@mail.gmail.com>

Dear Timo,

For 1.0* versions it was possible to provide custom RSA_METHOD and
EC_METHOD and implement an IPC callback.
I think it still should work for 1.1.1

It may be also useful to take a look at the async API.

On Mon, Jan 11, 2021 at 6:56 PM Timo Lange <tiolangit at outlook.com> wrote:

> Hey all,
>
> I have a question similar to
> http://openssl.6102.n7.nabble.com/private-key-not-available-for-client-cert-cb-td79369.html,
> that I am actively following, but though it differs in detail.
>
> What I want to achieve is the following:
> My client applications runs inside a container and needs to establish a
> mutual TLS connection to a server.
> The client certificate is available in the container.
> The root certificate, as well as the client private key is not available
> inside the container, but stored in a HSM.
> For sure the private key may never leave the HSM and also the root
> certificate should not.
>
> The application cannot directly interfere with the HSM through
> standardized mechanisms as it is not accessible from inside the container.
> For doing so a proprietary interprocess-communication is required.
>
> I now want something like a "verify callback" and a "sign callback".
>
> The "verify callback" would be needed in order to verify the server
> certificate against the root certificate. It seems to be easy using:
> https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_cert_verify_callback.html
>
> I need the same, something like a "sign callback" also for the private
> key, when a signature is required during handshake. Such that requests from
> openSSL to sign something can be forwarded through the
> inter-process-communication into the HSM. So that the actual signing
> happens there.
> This would only be required during handshake. For the actual encryption
> symmetric keys can be used, such that the encryption takes place in the
> openSSL library, not in the HSM.
>
> I assume I need to write a custom ENGINE, but failed with all my
> approaches.
>
> Can someone give me brief hint on where to start and which API to look at
> first?
>
> Thanks a lot!
> Timo
>
>

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210111/fbf9a5bd/attachment-0001.html>

From Michael.Wojcik at microfocus.com  Mon Jan 11 18:26:06 2021
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Mon, 11 Jan 2021 18:26:06 +0000
Subject: Sign without having the private key
In-Reply-To: <DB8PR04MB56733EE962D7392D49E54819FDAB0@DB8PR04MB5673.eurprd04.prod.outlook.com>
References: <DB8PR04MB56733EE962D7392D49E54819FDAB0@DB8PR04MB5673.eurprd04.prod.outlook.com>
Message-ID: <DM6PR18MB27005247C39EF4D416394052F9AB9@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Timo Lange
> Sent: Monday, 11 January, 2021 10:56

> The root certificate, as well as the client private key is not available inside
> the container, but stored in a HSM.
> For sure the private key may never leave the HSM

OK.

> and also the root certificate should not.

This doesn't make any sense. Certificates are not sensitive data, and it's inconvenient, if not impossible (depending on application software and HSM firmware) to split certificate chain validation across the host machine and the HSM.

Using the HSM as a certificate trust anchor *store* might make sense, depending on the use case. But the certificate would have to be extracted from the HSM by the application at runtime and made available to OpenSSL (or whatever's handling chain validation) so the peer's entity certificate can be verified.

> The application cannot directly interfere with the HSM through standardized mechanisms
> as it is not accessible from inside the container.
> For doing so a proprietary interprocess-communication is required.

That certainly seems like unnecessary complexity, but I'll assume there's some valid justification for it.

> I assume I need to write a custom ENGINE, but failed with all my approaches.

You *could* write a custom engine, which you'd then have to rewrite as a custom provider when support for OpenSSL 1.1.1 ends and you need to move to OpenSSL 3.0 or its successor.

However, you could also hide your IPC mechanism under a PKCS#11 implementation, and just use OpenSSL's PKCS#11 engine. PKCS#11 is the standard mechanism for talking to an HSM, and nothing says it can't involve IPC in the middle.

That is: OpenSSL -> pkcs11 engine -> your IPC client (written as a PKCS#11 library) -> some communications channel -> your IPC server -> real PKCS#11 library for your HSM. You could implement the IPC client and server using an open-source PKCS#11 shim such as pkcs11-helper. This area has been discussed recently on this list.

However, now you have the problem of securing the IPC channel. This is an architecture I'd be reluctant to endorse, given the complexity and attack surface.

--
Michael Wojcik

From mark.godfrey at thalesgroup.com  Mon Jan 11 19:09:42 2021
From: mark.godfrey at thalesgroup.com (GODFREY Mark)
Date: Mon, 11 Jan 2021 19:09:42 +0000
Subject: Offloading EC_POINT_mul via engine
Message-ID: <MRXP264MB03413AA6067B04628839E54892AB0@MRXP264MB0341.FRAP264.PROD.OUTLOOK.COM>

I have successfully been able to offload specific ECC functionality via my own engine.  For example, I have been able to offload sign, verify and compute_key methods. My latest task is now to offload, specifically, ECC point multiplication.  I am having a hard go at this. Really looking for guidance as to how to accomplish this.  I originally started by trying to create my own EC_METHOD that has a function pointer to my own point multiplication function, but that does not compile as EC_METHOD is now not accessible (in OpenSSL 1.1.1).  What I am looking to do is every time EC_POINT_mul is called to call my homegrown function.  Is this even possible?  Any guidance or reading materials would be helpful.  Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210111/3ef637f6/attachment.html>

From jgh at wizmail.org  Mon Jan 11 21:05:36 2021
From: jgh at wizmail.org (Jeremy Harris)
Date: Mon, 11 Jan 2021 21:05:36 +0000
Subject: Fwd: channel binding
In-Reply-To: <20210111082038.GD9776@akamai.com>
References: <53ac6b34-a380-047b-7fb2-5b8a6914963f@wizmail.org>
 <51a518c5-330d-ac65-1da0-33d30192eba9@wizmail.org>
 <20210111082038.GD9776@akamai.com>
Message-ID: <e3bd51c1-50d7-fb60-5383-bcadd6d8cc2b@wizmail.org>

On 11/01/2021 08:20, Benjamin Kaduk wrote:
>> What is the status of SSL_get_finidhed() / SSL_get_peer_finished() ?
>>
>> I do not find them documented at
>>    https://urldefense.com/v3/__https://www.openssl.org/docs/manmaster/man3/__;!!GjvTz_vk!FUYwEktTkE4ZmFeJKSFeBQe32kr0I0dcFxh_MkPMjns_JZ71rpQTYGbTm08g6w$
>>
>> but they are exported by the library and seem to be required, for
>> application channel-binding.
> 
> Current recommendations are not to use the finished message as the channel
> binding but instead to define key exporter label for the given usage
> (see https://tools.ietf.org/html/rfc8446#section-7.5), using SSL_export_keying_material().

Looking at the implementation, SSL_export_keying_material() only
functions for TLS 1.3 .  This is not documented.  Is this a bug?

"Only defined for TLS 1.0 and above" says the docs; I can live
with that.   But if 1.2 doesn't working with it, will SSL_get_finished()
do so  (I an enforcing Extended-Master-Secret or not-Resumption) ?
-- 
Cheers,
   Jeremy

From jgh at wizmail.org  Mon Jan 11 21:26:30 2021
From: jgh at wizmail.org (Jeremy Harris)
Date: Mon, 11 Jan 2021 21:26:30 +0000
Subject: Fwd: channel binding
In-Reply-To: <20210111082038.GD9776@akamai.com>
References: <53ac6b34-a380-047b-7fb2-5b8a6914963f@wizmail.org>
 <51a518c5-330d-ac65-1da0-33d30192eba9@wizmail.org>
 <20210111082038.GD9776@akamai.com>
Message-ID: <fc647fff-7d4f-8af9-1459-c0f7e4f7afe5@wizmail.org>

On 11/01/2021 08:20, Benjamin Kaduk wrote:
> Current recommendations are not to use the finished message as the channel
> binding but instead to define key exporter label for the given usage
> (see https://tools.ietf.org/html/rfc8446#section-7.5), using SSL_export_keying_material().

Follow-on question on SSL_export_keying_material() -
what "label" should I supply?

I need to interwork with other implementations that are using
SSL_get_finished() (client side) / SSL_get_peer_finished() (server side).
Does that imply I should use "client finished"
(per
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels
)
as the label?   Does the label length for the SSL_export_keying_material()
call include the terminating NUL or not?
-- 
Cheers,
   Jeremy

From bkaduk at akamai.com  Mon Jan 11 22:07:35 2021
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Mon, 11 Jan 2021 14:07:35 -0800
Subject: Fwd: channel binding
In-Reply-To: <fc647fff-7d4f-8af9-1459-c0f7e4f7afe5@wizmail.org>
References: <53ac6b34-a380-047b-7fb2-5b8a6914963f@wizmail.org>
 <51a518c5-330d-ac65-1da0-33d30192eba9@wizmail.org>
 <20210111082038.GD9776@akamai.com>
 <fc647fff-7d4f-8af9-1459-c0f7e4f7afe5@wizmail.org>
Message-ID: <20210111220735.GF9776@akamai.com>

On Mon, Jan 11, 2021 at 09:26:30PM +0000, Jeremy Harris wrote:
> On 11/01/2021 08:20, Benjamin Kaduk wrote:
> > Current recommendations are not to use the finished message as the channel
> > binding but instead to define key exporter label for the given usage
> > (see https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8446*section-7.5__;Iw!!GjvTz_vk!B3BtBNIxiZ3RH6J7rY957VPTQl8bbpbD0JFcnI7yROvCOorpGCJtgFcao40Dug$ ), using SSL_export_keying_material().


> Looking at the implementation, SSL_export_keying_material() only
> functions for TLS 1.3 .  This is not documented.  Is this a bug?

Are you looking at SSL_export_keying_material() or SSL_export_keying_material_early()?
For the latter, the man page says:

% SSL_export_keying_material_early() is only usable with TLSv1.3, and derives
% keying material using the F<early_exporter_master_secret> (as defined in the
% TLS 1.3 RFC).

I did try to check that the implementation was available for TLS 1.0 before
recommending it, but only halfheartedly.

> "Only defined for TLS 1.0 and above" says the docs; I can live
> with that.   But if 1.2 doesn't working with it, will SSL_get_finished()
> do so  (I an enforcing Extended-Master-Secret or not-Resumption) ?

> Follow-on question on SSL_export_keying_material() -
> what "label" should I supply?
> 
> I need to interwork with other implementations that are using
> SSL_get_finished() (client side) / SSL_get_peer_finished() (server side).
> Does that imply I should use "client finished"
> (per
> https://urldefense.com/v3/__https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml*exporter-labels__;Iw!!GjvTz_vk!B3BtBNIxiZ3RH6J7rY957VPTQl8bbpbD0JFcnI7yROvCOorpGCJtgFcXtzE4eg$
> )
> as the label?   Does the label length for the SSL_export_keying_material()
> call include the terminating NUL or not?

If you need to interwork with other implementations/an existing protocol,
you have to stick with the Finished-based channel bindings; the exporter
interface is a new protocol mechanism and the whole protocol/ecosystem has
to be expecting to use it.

With TLS 1.2 and extended master secret this is not known to be broken (and
yes, that is a very carefully phrased statement).

And, for completeness, you generally won't include the terminating NUL
in the label length argument, but that will be defined by the protocol spec
that defines the exporter label.

-Ben

From steffen at sdaoden.eu  Mon Jan 11 22:19:30 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 11 Jan 2021 23:19:30 +0100
Subject: SSL_CONF_cmd(): SecurityLevel keyword, by chance?
In-Reply-To: <eea19b85-2030-15ed-c1d0-d8594c8cd097@openssl.org>
References: <20210109232436.EqSFj%steffen@sdaoden.eu>
 <eea19b85-2030-15ed-c1d0-d8594c8cd097@openssl.org>
Message-ID: <20210111221930.UhA3Y%steffen@sdaoden.eu>

Hello.

Matt Caswell wrote in
 <eea19b85-2030-15ed-c1d0-d8594c8cd097 at openssl.org>:
 |On 09/01/2021 23:24, Steffen Nurpmeso wrote:
 |> Hello.
 |>
 |> I do use SSL_CONF_cmd() (and modules) possibility if it exists,
 |> since it allow users to simply use the features of the newest
 |> OpenSSL library without any code changes on my side.
 |> This is great, and i think i applauded in the past.
 |>
 |> I discovered security_level(), needless to say i thought
 |> @SECLEVEL= of ciphers(1) was broken until i discovered -s is
 |> required to make it functional (..and do not get me started on
 |> -ciphersuites..).
 |>
 |> Wouldn't it make sense to offer SecurityLevel as a keyword for
 |> SSL_CONF_cmd(), and therefore also SSL_CTX_config(), too -- since
 |> it seems (from the manual) to extend to more than what i would
 |> assume to be covered by a @SECLEVEL member of CipherString aka
 |> ..Ciphersuites...?
 |
 |This is probably a good idea. I'd support it if someone wanted to add that.

Please find a simple add-on attached, it could be it ("having no
idea of the codebase"..).  It compiles, but when linking against
678cae0295e3f (master from today) plus the patch i get errors:

  In file included from /home/steffen/src/nail.git/src/mx/xtls.c:60:
  /home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected declaration specifiers or '...' before 'ossl_check_const_GENERAL_NAME_sk_type'
    402 |    DEFINE_STACK_OF(GENERAL_NAME)
        |    ^~~~~~~~~~~~~~~
  /home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected ')' before '*' token
    402 |    DEFINE_STACK_OF(GENERAL_NAME)
        |    ^~~~~~~~~~~~~~~
  /home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected ')' before 'OPENSSL_sk_value'
    402 |    DEFINE_STACK_OF(GENERAL_NAME)
        |    ^~~~~~~~~~~~~~~
  In file included from /home/steffen/usr-kent-linux-x86_64/opt/.ossl3/include/openssl/crypto.h:35,
                   from /home/steffen/src/nail.git/src/mx/xtls.c:53:
  /home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected identifier or '(' before 'struct'
    402 |    DEFINE_STACK_OF(GENERAL_NAME)
        |    ^~~~~~~~~~~~~~~
  In file included from /home/steffen/src/nail.git/src/mx/xtls.c:60:
  /home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected ')' before 'OPENSSL_sk_new'
    402 |    DEFINE_STACK_OF(GENERAL_NAME)
        |    ^~~~~~~~~~~~~~~
  /home/steffen/src/nail.git/src/mx/xtls.c:402:1: error: macro "sk_GENERAL_NAME_new_null" passed 1 arguments, but takes just 0
    402 |    DEFINE_STACK_OF(GENERAL_NAME)
        | ^  ~~~~~~~~~~~~~~~~~~~~~
  In file included from /home/steffen/src/nail.git/src/mx/xtls.c:60:
  /home/steffen/usr-kent-linux-x86_64/opt/.ossl3/include/openssl/x509v3.h:225: note: macro "sk_GENERAL_NAME_new_null" defined here
    225 | #define sk_GENERAL_NAME_new_null() ((STACK_OF(GENERAL_NAME) *)OPENSSL_sk_new_null())
        |

I have not tested OpenSSL 3.0 for a while, but it was clean when
i tried it last, my last commit was "Be truly
OPENSSL_NO_DEPRECATED_3_0 clean" on 2020-07-19.  I used

  ./config --prefix=/home/steffen/usr-kent-linux-x86_64/opt/.ossl3 \
    zlib-dynamic shared no-deprecated no-async threads no-tests \
    -Wl,-rpath,'$(LIBRPATH)'

on a current glibc Linux (CRUX-Linux 3.6).

Ciao from Germany,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ossl3-conf-seclvl.patch
Type: text/x-diff
Size: 4020 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210111/cbd4dadc/attachment.patch>

From jgh at wizmail.org  Mon Jan 11 22:31:01 2021
From: jgh at wizmail.org (Jeremy Harris)
Date: Mon, 11 Jan 2021 22:31:01 +0000
Subject: Fwd: channel binding
In-Reply-To: <20210111220735.GF9776@akamai.com>
References: <53ac6b34-a380-047b-7fb2-5b8a6914963f@wizmail.org>
 <51a518c5-330d-ac65-1da0-33d30192eba9@wizmail.org>
 <20210111082038.GD9776@akamai.com>
 <fc647fff-7d4f-8af9-1459-c0f7e4f7afe5@wizmail.org>
 <20210111220735.GF9776@akamai.com>
Message-ID: <020dc7c4-a7fe-7fc7-fb3c-aae2fb7cfbca@wizmail.org>

On 11/01/2021 22:07, Benjamin Kaduk wrote:
>> Looking at the implementation, SSL_export_keying_material() only
>> functions for TLS 1.3 .  This is not documented.  Is this a bug?
> Are you looking at SSL_export_keying_material() or SSL_export_keying_material_early()?

Doh.  I was looking at the wrong routine; thanks.
But, per below, now moot.

> If you need to interwork with other implementations/an existing protocol,
> you have to stick with the Finished-based channel bindings; the exporter
> interface is a new protocol mechanism and the whole protocol/ecosystem has
> to be expecting to use it.

Right. So we have implementations out there using it; will the OpenSSL
project consider promoting it to supported status so that it doesn't
disappear in some future release?

> With TLS 1.2 and extended master secret this is not known to be broken (and
> yes, that is a very carefully phrased statement).

Understood :)   Like all crypto...
-- 
Cheers,
   Jeremy

From bkaduk at akamai.com  Mon Jan 11 22:38:53 2021
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Mon, 11 Jan 2021 14:38:53 -0800
Subject: Fwd: channel binding
In-Reply-To: <020dc7c4-a7fe-7fc7-fb3c-aae2fb7cfbca@wizmail.org>
References: <53ac6b34-a380-047b-7fb2-5b8a6914963f@wizmail.org>
 <51a518c5-330d-ac65-1da0-33d30192eba9@wizmail.org>
 <20210111082038.GD9776@akamai.com>
 <fc647fff-7d4f-8af9-1459-c0f7e4f7afe5@wizmail.org>
 <20210111220735.GF9776@akamai.com>
 <020dc7c4-a7fe-7fc7-fb3c-aae2fb7cfbca@wizmail.org>
Message-ID: <20210111223853.GG9776@akamai.com>

On Mon, Jan 11, 2021 at 10:31:01PM +0000, Jeremy Harris wrote:
> On 11/01/2021 22:07, Benjamin Kaduk wrote:
> > > Looking at the implementation, SSL_export_keying_material() only
> > > functions for TLS 1.3 .  This is not documented.  Is this a bug?
> > Are you looking at SSL_export_keying_material() or SSL_export_keying_material_early()?
> 
> Doh.  I was looking at the wrong routine; thanks.
> But, per below, now moot.
> 
> > If you need to interwork with other implementations/an existing protocol,
> > you have to stick with the Finished-based channel bindings; the exporter
> > interface is a new protocol mechanism and the whole protocol/ecosystem has
> > to be expecting to use it.
> 
> Right. So we have implementations out there using it; will the OpenSSL
> project consider promoting it to supported status so that it doesn't
> disappear in some future release?

I think you should treat them as if they are supported interfaces.
They're present in the list of "things that aren't documented but should be",
and do have some documentation-ish commentary in the public header file.

Any API change or removal would be against our support policy (and patches
to add man pages for them would also be welcome).

> > With TLS 1.2 and extended master secret this is not known to be broken (and
> > yes, that is a very carefully phrased statement).
> 
> Understood :)   Like all crypto...

Yes ... though some we are more confident in than others :)

-Ben

From gimhanieuthpala at gmail.com  Tue Jan 12 04:23:09 2021
From: gimhanieuthpala at gmail.com (Gimhani Uthpala)
Date: Tue, 12 Jan 2021 09:53:09 +0530
Subject: Random and rare Seg faults at openssl library level
In-Reply-To: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
References: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
Message-ID: <CAJ1bD4-w99KZU2S16=sAU+-O3gihVC0yb9voGzm23SQ0o+zVog@mail.gmail.com>

Hi team,
https://www.openssl.org/docs/man1.0.2/man3/CRYPTO_set_locking_callback.html
:  From this , learnt that for openssl multi-threaded applications to be
run safely, the callback functions to be implemented.

I am using this in a multi-threaded application and Above scenario was
again recreated and in that case 2 threads were calling RSA_verify (same
stack above). However, for SSL_do_handshake, SSL* objects are given
separately and they are not shared between threads. So, we have not
implemented callback functions.

Could you please clarify whether we need to implement locking callbacks for
multi-threaded applications  even if the ssl objects we supply are provided
separately for threads?

Many thanks.

On Wed, Jan 6, 2021 at 10:40 PM Gimhani Uthpala <gimhanieuthpala at gmail.com>
wrote:

> Dear team,
> I'm running an application which uses openssl for secure communication
> between processes. I am getting seg-faults at openssl level. This only
> occurred very randomly and the following are stacks that seg faults  at
> openssl level in the given 2 cases. We are using openssl 1.0.2k.
>
> Went through the security vulnerabilities list for this version but
> couldn't find a clue. Running valgrind too didn't give an exact clue
> related to the issue. Can you please guide me how can I find the exact root
> cause for the seg fault?
>
> I am calling SSL_do_handshake(ssl_ctx) from my code level and both the
> below seg faults are occuring from it's inside.
>
> #0  0x00007fd64cdabdd3 in ASN1_item_verify () from /lib64/libcrypto.so.10
> #1  0x00007fd64cdcac58 in internal_verify () from /lib64/libcrypto.so.10
> #2  0x00007fd64cdccaef in X509_verify_cert () from /lib64/libcrypto.so.10
> #3  0x00007fd64d111c68 in ssl_verify_cert_chain () from /lib64/libssl.so.10
> #4  0x00007fd64d0e8cc6 in ssl3_get_client_certificate () from
> /lib64/libssl.so.10
> *#5  0x00007fd64d0ea3f8 in ssl3_accept () from /lib64/libssl.so.10*
>
>
>  #0 0x00007ffb65529854 in RSA_verify () from /usr/lib64/libcrypto.so.10
>  #1 0x00007ffb6552f1fc in pkey_rsa_verify () from
> /usr/lib64/libcrypto.so.10
>  #2 0x00007ffb65561877 in EVP_DigestVerifyFinal () from
> /usr/lib64/libcrypto.so.10
>  #3 0x00007ffb6556af25 in ASN1_item_verify () from
> /usr/lib64/libcrypto.so.10
>  #4 0x00007ffb65589c58 in internal_verify () from
> /usr/lib64/libcrypto.so.10
>  #5 0x00007ffb6558baef in X509_verify_cert () from
> /usr/lib64/libcrypto.so.10
>  #6 0x00007ffb658d1417 in ssl_add_cert_chain () from
> /usr/lib64/libssl.so.10
>  #7 0x00007ffb658b6095 in ssl3_output_cert_chain () from
> /usr/lib64/libssl.so.10
>  #8 0x00007ffb658ae894 in ssl3_send_client_certificate () from
> /usr/lib64/libssl.so.10
>
> * #9 0x00007ffb658aeecf in ssl3_connect () from
> /usr/lib64/libssl.so.10 #10 0x00007ffb658b8e7e in ssl23_connect () from
> /usr/lib64/libssl.so.10*
>
>   I am setting context to use SSLv23_method() s. However, I can see ssl3_
> methods being called. Is there any issue with that?
>
> Given below is SSL* object passed to SSL_do_handshake method.
>
> (gdb) p *p_SSLCtx
> $2 = {version = 771, type = 4096, method = 0x7ffb65af3320, rbio =
> 0x7ffb5819e140, wbio = 0x7ffb58193570, bbio = 0x7ffb58193570, rwstate = 1,
> in_handshake = 2, *handshake_func = 0x7ffb658aea30 <ssl3_connect>*,
> server = 0, new_session = 0, quiet_shutdown = 0, shutdown = 0, state = 4467,
>   rstate = 240, init_buf = 0x7ffb581934b0, init_msg = 0x7ffb581e10d4,
> init_num = 0, init_off = 0, *packet = 0x7ffb581e6633 "\026\003\003",
> packet_length = 0*, s2 = 0x0, s3 = 0x7ffb58195ee0, d1 = 0x0, read_ahead =
> 0, msg_callback = 0x0, msg_callback_arg = 0x0, hit = 0, param =
> 0x7ffb581933f0,
>   cipher_list = 0x0, cipher_list_by_id = 0x0, mac_flags = 0, enc_read_ctx
> = 0x0, read_hash = 0x0, expand = 0x0, enc_write_ctx = 0x0, write_hash =
> 0x0, compress = 0x0, cert = 0x7ffb58195ba0, sid_ctx_length = 0, sid_ctx =
> '\000' <repeats 31 times>, session = 0x7ffb58198100,
>   generate_session_id = 0x0,......
>
>
>
> --
> *Gimhani Uthpala Kankanamge*
>
>

-- 
*Gimhani Uthpala Kankanamge*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210112/fa7e0c60/attachment.html>

From whippet0 at gmail.com  Tue Jan 12 06:01:19 2021
From: whippet0 at gmail.com (George)
Date: Tue, 12 Jan 2021 01:01:19 -0500
Subject: private key not available for client_cert_cb
In-Reply-To: <1b5335f6-0350-1acc-e019-cc58f50f5043@nikhef.nl>
References: <292d3b25-9197-4977-a406-0a19abc15a0d@gmail.com>
 <57a1488f-cc91-4c3a-5cee-4ad6c24565d6@gmail.com>
 <BN8PR18MB269202BE32C14ACB482E015DF9C70@BN8PR18MB2692.namprd18.prod.outlook.com>
 <7a3428c6-04ab-672e-b738-67680f9fc036@gmail.com>
 <e015a686-88b2-e483-a7da-53e9efabd9fc@nikhef.nl>
 <30032dde-70d1-d438-86ae-77f04a8179cf@gmail.com>
 <2495b1de-13d0-8777-56b0-46ac80cd0203@nikhef.nl>
 <5887cae2-1ecb-4081-1ee9-bcf566a88afe@gmail.com>
 <8011726e-0a7a-a753-983d-b89a24e3e225@nikhef.nl>
 <ab55a9e8-8bd3-c353-3922-1cae88349cb8@gmail.com>
 <8038268f-fd47-1ef8-7dec-ce365b0d453e@nikhef.nl>
 <00492ef8-67aa-8848-97fe-65cf2ba3b38f@gmail.com>
 <e8d14828-97aa-a1ee-52e2-36e124978cc6@nikhef.nl>
 <3e6e027f-812a-ea2d-2d2e-435ad52852b1@gmail.com>
 <471b029c-420c-e45e-d827-ba0576f22847@nikhef.nl>
 <1b20aba6-b88f-2ee1-af0d-23ae19c0746f@gmail.com>
 <640febc7-2499-2284-6625-b7a899ad66ea@nikhef.nl>
 <95f017bb-6946-f37d-e585-05367f0e2da7@gmail.com>
 <1b5335f6-0350-1acc-e019-cc58f50f5043@nikhef.nl>
Message-ID: <9ad47445-b7e9-14f5-1319-592b0822ad17@gmail.com>

I found out what my problem is! I'm running it in FIPS mode and this 
causes the PKCS11 engine to fail during mutual authentication. I 
eventually traced the problem to the following issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1827535

It looks like there is a bug in libp11. Once I made the suggested 
workaround, it worked.
My original code, which is based on
https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c
worked perfectly after I added in the libp11 fix.? :)


Thanks!
George


On 2021-01-11 11:01 a.m., Jan Just Keijser wrote:
> Hi,
>
> On 08/01/21 22:35, George wrote:
>> Hi,
>>
>> ?? I have been trying to setup mutual authentication using a smart 
>> card but I can't seem to get the OpenSSL Engine to send a response 
>> back to the server containing client's certificate from the smart card.
>>
>> I'm using the following to configure the certificate and private key:
>>
>> ??? ENGINE_ctrl_cmd(engine, "LOAD_CERT_CTRL", 0, &cert_info, NULL, 0);
>> ??? SSL_CTX_use_certificate(sslContext, cert_info.cert);
>>
>> ??? EVP_PKEY* privateKey = ENGINE_load_private_key(engine, 
>> "2b2586c684d69b670c0a805edf514e720f2b757d8e2faa0b3a7ff23d1ccfc7ba", 
>> transfer_pin, &cb_data);
>> ??? SSL_CTX_use_PrivateKey(sslContext, privateKey);
>>
>> (I have been using the code in 
>> https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c as a guide.)
>>
>> This seems be successful. However, when I start the mutual 
>> authentication with
>> SSL_connect(ssl)
>> , the mutual authentications handshake fails. I can see the server 
>> requesting the certificate from the client and the client sends back 
>> an ACK for this message. However, the client does not send the 
>> certificate to the server.
>>
>> I was looking through the OpenSSL code openssl-1.0.2u\ssl\ssl_rsa.c 
>> and noticed something interesting. The comment indicates that the 
>> flag *RSA_METHOD_FLAG_NO_CHECK* should be set for smart cards:
>>
>> static int ssl_set_pkey(CERT *c, EVP_PKEY *pkey)
>> {
>> ?. . .
>> #ifndef OPENSSL_NO_RSA
>> *?? /***
>> **???????? * Don't check the public/private key, this is mostly for 
>> smart**
>> **???????? * cards.**
>> **???????? */*
>> ??????? if ((pkey->type == EVP_PKEY_RSA) &&
>> ??????????? (RSA_flags(pkey->pkey.rsa) & RSA_METHOD_FLAG_NO_CHECK)) ;
>> ??????? else
>> #endif
>> . . .
>> }
>>
>> However, it is not actually set when I use a debugger to inspect the 
>> flag. Does it need to be set? If so, how is this done? I could not 
>> find anything related to this in
>> https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c
>
>
> if you read through the code blob that Michael pointed you to, you 
> will find that this flag needs to be set *under certain circumstances* 
> when using smartcards. It has to do mostly with the situation where
> - private key is on the smart card
> - the public key/certificate is NOT on the smart card
> - you ask OpenSSL to verify the private key without explicitly 
> providing a public key.
>
> I've never run into this issue, but then again, I have not tested very 
> often the case where the certificate was not present on the HSM/smart 
> card but the private key is.? YMMV.
>
> As for using pksc11helper versus using libp11: that is just a matter 
> of taste. I used the engine_pkcs11 + libp11 route for the eap-tls code 
> , mostly because it was the first "working" set of tools I found at 
> the time.
>
> You can also take the "pkcs11helper" route, which is what OpenVPN does 
> (see https://github.com/openvpn). Both methods have pro's and con's.
>
> Do you run into problems if you DO not set the 
> RSA_METHOD_FLAG_NO_CHECK flag?? All that flag does is to stop OpenSSL 
> from verifying that a public key/cert and private key match/belong 
> together for RSA keys only; if your smartcard supports EC keys then 
> this flag will do you no good.
>
> HTH,
>
> JJK
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210112/cd38a4d0/attachment-0001.html>

From whippet0 at gmail.com  Tue Jan 12 07:17:33 2021
From: whippet0 at gmail.com (George)
Date: Tue, 12 Jan 2021 02:17:33 -0500
Subject: private key not available for client_cert_cb
In-Reply-To: <DM6PR18MB270035C69BEEB9E0DBAFE706F9AB9@DM6PR18MB2700.namprd18.prod.outlook.com>
References: <292d3b25-9197-4977-a406-0a19abc15a0d@gmail.com>
 <e015a686-88b2-e483-a7da-53e9efabd9fc@nikhef.nl>
 <30032dde-70d1-d438-86ae-77f04a8179cf@gmail.com>
 <2495b1de-13d0-8777-56b0-46ac80cd0203@nikhef.nl>
 <5887cae2-1ecb-4081-1ee9-bcf566a88afe@gmail.com>
 <8011726e-0a7a-a753-983d-b89a24e3e225@nikhef.nl>
 <ab55a9e8-8bd3-c353-3922-1cae88349cb8@gmail.com>
 <8038268f-fd47-1ef8-7dec-ce365b0d453e@nikhef.nl>
 <00492ef8-67aa-8848-97fe-65cf2ba3b38f@gmail.com>
 <e8d14828-97aa-a1ee-52e2-36e124978cc6@nikhef.nl>
 <3e6e027f-812a-ea2d-2d2e-435ad52852b1@gmail.com>
 <471b029c-420c-e45e-d827-ba0576f22847@nikhef.nl>
 <1b20aba6-b88f-2ee1-af0d-23ae19c0746f@gmail.com>
 <640febc7-2499-2284-6625-b7a899ad66ea@nikhef.nl>
 <95f017bb-6946-f37d-e585-05367f0e2da7@gmail.com>
 <DM6PR18MB2700D51CA007871717F6C533F9AE9@DM6PR18MB2700.namprd18.prod.outlook.com>
 <6ea69357-8457-32f4-8803-162c7ec3a29c@gmail.com>
 <DM6PR18MB270035C69BEEB9E0DBAFE706F9AB9@DM6PR18MB2700.namprd18.prod.outlook.com>
Message-ID: <8ef3d5ac-0279-744c-f5d0-8ded0bc3bd7d@gmail.com>

I'm running this in Windows 10 and when I load the smart card middleware 
PKCS11 DLL, I see the exception:

    Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++
    exception: unsigned long at memory location 0x07FCFA00.


During mutual authentication, I also see alot of other exceptions such as:

    Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++
    exception: AI::Middleware::CMWException at memory location 0x032FD2D0.


I traced them down to various PKCS11 calls on the card in libp11.
e.g.
the function call to C_GetSlotList(...) in the file p11_slot.c triggers 
an exception:

    int pkcs11_enumerate_slots(PKCS11_CTX *ctx, PKCS11_SLOT **slotp,
    unsigned int *countp)
    {
    . . .
    *rv = cpriv->method->C_GetSlotList(FALSE, NULL_PTR, &nslots);*
    . . .
    }


It is interesting to note that this function seems to get called 
multiple times and it eventually works. I do not fully understand 
how/why the code does that and if this is the design intent. The 
exceptions don't seem to have any effect on the functionality, but I 
still need to understand why they are occurring.

It looks like someone else using a smart card has also encountered 
similar problems in Windows but there is no real answer as to why they 
are occurring:
https://www.codeproject.com/Questions/1254182/Smart-card-apis-throw-first-chance-exceptions-but



Thanks,
George


On 2021-01-11 9:41 a.m., Michael Wojcik wrote:
>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of George
>> Sent: Sunday, 10 January, 2021 21:01
>> Right now I am using the "libp11" DLL (i.e. libp11-libp11-0.4.11\src\pkcs11.dll)
>> with my PKCS11 smart card middleware DLL. Should I be using the OpenSC pkcs11 DLL
>> instead of my middleware DLL if I am using libp1?
> Honestly, I have no idea. It's been years since I worked with PKCS#11, and then I was using a single piece of test hardware. I got it working with OpenSSL using the OpenSC modules, but that may have been specific to my case.
>
>> Do you know if it is normal to see exceptions related to the PKCS11 function calls
>> in the libp11 code? For example, I can see  the following function generate an
>> exception on C_GetSlotList(...) multiple times but it eventually is successful.
>> Is this normal behaviour?
> What sort of "exception"? A Windows exception? UNIX signal? C++ exception?
>
> My initial guess would be that this is a timing issue - maybe the device needs some time to become available, for example. But that's just a guess. Maybe someone with more experience with a variety of HSMs and PKCS#11 will weigh in.
>
> --
> Michael Wojcik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210112/01573f1c/attachment.html>

From janjust at nikhef.nl  Tue Jan 12 10:21:03 2021
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Tue, 12 Jan 2021 11:21:03 +0100
Subject: Random and rare Seg faults at openssl library level
In-Reply-To: <CAJ1bD4_HY=dZgB0Es=x44Gkz4bhnD65VFb+6gjyX0dqs8qF2rw@mail.gmail.com>
References: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
 <5d6e7fe5-c3a6-34ff-b66f-31c54f187ac1@us.ibm.com>
 <CAJ1bD4_HY=dZgB0Es=x44Gkz4bhnD65VFb+6gjyX0dqs8qF2rw@mail.gmail.com>
Message-ID: <aa8c5946-0d77-95f2-837a-c43fbbf9dd02@nikhef.nl>

Hi,

On 07/01/21 23:53, Gimhani Uthpala wrote:
>
>
> On Thu, Jan 7, 2021 at 3:08 AM Ken Goldman <kgoldman at us.ibm.com 
> <mailto:kgoldman at us.ibm.com>> wrote:
>
>     On 1/6/2021 12:10 PM, Gimhani Uthpala wrote:
>
>     > I am getting seg-faults at openssl level. This only
>     occurred?very randomly and the following are stacks that seg
>     faults? at openssl level in the given 2 cases. We are using
>     openssl 1.0.2k.
>
>     The usual cause is that you are compiling with one version of
>     openssl and (static or dynamic) linking with a different one.
>     The cause of that is typically that you have more than one version
>     of openssl installed.
>
>     If this is a 3rd party application, not one you're building, you
>     have to find out what version of openssl they expect.
>
>
>
> I only?have this 1.0.2.k-fips one version installed in both compiling 
> and running machines. However, I am compiling the application in RH7.4 
> and running in RH7.8 linking to openssl library dynamically. I assume 
> no issue with that as I am using the same version of openssl in both.
>
actually - there could be an issue with that, as RedHat has this 
tendency to patch openssl between releases (mostly backporting security 
fixes from openssl 1.1.x to 1.0.2k).

Have you tried installing the debuginfo package for openssl so that the 
stacktrace will show you better info:
 ? debuginfo-install openssl-libs openssl

right now all you know is that the segfault occurs *somewhere* within 
ASN1_item_verify ()

HTH,

JJK

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210112/65592562/attachment.html>

From matt at openssl.org  Tue Jan 12 11:26:39 2021
From: matt at openssl.org (Matt Caswell)
Date: Tue, 12 Jan 2021 11:26:39 +0000
Subject: SSL_CONF_cmd(): SecurityLevel keyword, by chance?
In-Reply-To: <20210111221930.UhA3Y%steffen@sdaoden.eu>
References: <20210109232436.EqSFj%steffen@sdaoden.eu>
 <eea19b85-2030-15ed-c1d0-d8594c8cd097@openssl.org>
 <20210111221930.UhA3Y%steffen@sdaoden.eu>
Message-ID: <9b337dc8-3d2b-23c4-f4b8-ee332dedafb9@openssl.org>

Please raise your patch as a PR so that it can properly reviewed. You'll
also need to submit a CLA:

https://www.openssl.org/policies/cla.html

Thanks

Matt


On 11/01/2021 22:19, Steffen Nurpmeso wrote:
> Hello.
> 
> Matt Caswell wrote in
>  <eea19b85-2030-15ed-c1d0-d8594c8cd097 at openssl.org>:
>  |On 09/01/2021 23:24, Steffen Nurpmeso wrote:
>  |> Hello.
>  |>
>  |> I do use SSL_CONF_cmd() (and modules) possibility if it exists,
>  |> since it allow users to simply use the features of the newest
>  |> OpenSSL library without any code changes on my side.
>  |> This is great, and i think i applauded in the past.
>  |>
>  |> I discovered security_level(), needless to say i thought
>  |> @SECLEVEL= of ciphers(1) was broken until i discovered -s is
>  |> required to make it functional (..and do not get me started on
>  |> -ciphersuites..).
>  |>
>  |> Wouldn't it make sense to offer SecurityLevel as a keyword for
>  |> SSL_CONF_cmd(), and therefore also SSL_CTX_config(), too -- since
>  |> it seems (from the manual) to extend to more than what i would
>  |> assume to be covered by a @SECLEVEL member of CipherString aka
>  |> ..Ciphersuites...?
>  |
>  |This is probably a good idea. I'd support it if someone wanted to add that.
> 
> Please find a simple add-on attached, it could be it ("having no
> idea of the codebase"..).  It compiles, but when linking against
> 678cae0295e3f (master from today) plus the patch i get errors:
> 
>   In file included from /home/steffen/src/nail.git/src/mx/xtls.c:60:
>   /home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected declaration specifiers or '...' before 'ossl_check_const_GENERAL_NAME_sk_type'
>     402 |    DEFINE_STACK_OF(GENERAL_NAME)
>         |    ^~~~~~~~~~~~~~~
>   /home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected ')' before '*' token
>     402 |    DEFINE_STACK_OF(GENERAL_NAME)
>         |    ^~~~~~~~~~~~~~~
>   /home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected ')' before 'OPENSSL_sk_value'
>     402 |    DEFINE_STACK_OF(GENERAL_NAME)
>         |    ^~~~~~~~~~~~~~~
>   In file included from /home/steffen/usr-kent-linux-x86_64/opt/.ossl3/include/openssl/crypto.h:35,
>                    from /home/steffen/src/nail.git/src/mx/xtls.c:53:
>   /home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected identifier or '(' before 'struct'
>     402 |    DEFINE_STACK_OF(GENERAL_NAME)
>         |    ^~~~~~~~~~~~~~~
>   In file included from /home/steffen/src/nail.git/src/mx/xtls.c:60:
>   /home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected ')' before 'OPENSSL_sk_new'
>     402 |    DEFINE_STACK_OF(GENERAL_NAME)
>         |    ^~~~~~~~~~~~~~~
>   /home/steffen/src/nail.git/src/mx/xtls.c:402:1: error: macro "sk_GENERAL_NAME_new_null" passed 1 arguments, but takes just 0
>     402 |    DEFINE_STACK_OF(GENERAL_NAME)
>         | ^  ~~~~~~~~~~~~~~~~~~~~~
>   In file included from /home/steffen/src/nail.git/src/mx/xtls.c:60:
>   /home/steffen/usr-kent-linux-x86_64/opt/.ossl3/include/openssl/x509v3.h:225: note: macro "sk_GENERAL_NAME_new_null" defined here
>     225 | #define sk_GENERAL_NAME_new_null() ((STACK_OF(GENERAL_NAME) *)OPENSSL_sk_new_null())
>         |
> 
> I have not tested OpenSSL 3.0 for a while, but it was clean when
> i tried it last, my last commit was "Be truly
> OPENSSL_NO_DEPRECATED_3_0 clean" on 2020-07-19.  I used
> 
>   ./config --prefix=/home/steffen/usr-kent-linux-x86_64/opt/.ossl3 \
>     zlib-dynamic shared no-deprecated no-async threads no-tests \
>     -Wl,-rpath,'$(LIBRPATH)'
> 
> on a current glibc Linux (CRUX-Linux 3.6).
> 
> Ciao from Germany,
> 
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
> 

From matt at openssl.org  Tue Jan 12 11:32:47 2021
From: matt at openssl.org (Matt Caswell)
Date: Tue, 12 Jan 2021 11:32:47 +0000
Subject: Random and rare Seg faults at openssl library level
In-Reply-To: <CAJ1bD4-w99KZU2S16=sAU+-O3gihVC0yb9voGzm23SQ0o+zVog@mail.gmail.com>
References: <CAJ1bD4_Cx0MBrh9Uz-aQ4maZGfT+7ir0Np+dVeU=RM_W8_0JHQ@mail.gmail.com>
 <CAJ1bD4-w99KZU2S16=sAU+-O3gihVC0yb9voGzm23SQ0o+zVog@mail.gmail.com>
Message-ID: <b85ebaf6-3cf8-abe2-233b-0e51defe7e3e@openssl.org>



On 12/01/2021 04:23, Gimhani Uthpala wrote:
> Hi team,
> https://www.openssl.org/docs/man1.0.2/man3/CRYPTO_set_locking_callback.html
> :? From this , learnt that for openssl multi-threaded applications to be
> run safely, the callback functions to be implemented.
> 
> I am using this in a multi-threaded application and Above scenario was
> again recreated and in that case 2 threads were calling RSA_verify (same
> stack above). However, for SSL_do_handshake, SSL* objects are given
> separately and they are not shared between threads. So, we have not
> implemented callback functions.
> 
> Could you please clarify whether we need to implement locking callbacks
> for multi-threaded applications? even if the ssl objects we supply are
> provided separately for threads?

If you are using 1.0.2 in a multi-threaded context then you *must*
implement the locking callbacks. There are resources that are shared
between multiple threads that require appropriate locking.

Matt



> 
> Many?thanks.
> 
> On Wed, Jan 6, 2021 at 10:40 PM Gimhani Uthpala
> <gimhanieuthpala at gmail.com <mailto:gimhanieuthpala at gmail.com>> wrote:
> 
>     Dear team,
>     I'm running an application which uses openssl for secure
>     communication between processes. I am getting seg-faults at openssl
>     level. This only occurred?very randomly and the following are stacks
>     that seg faults? at openssl level in the given 2 cases. We are using
>     openssl 1.0.2k.?
> 
>     Went through the security vulnerabilities list for this version but
>     couldn't find a clue. Running valgrind too didn't give an exact clue
>     related to the issue. Can you please guide me how can I find the
>     exact root cause for the seg fault???
> 
>     I am calling SSL_do_handshake(ssl_ctx) from my code level and both
>     the below seg faults are occuring from it's inside.?
> 
>     #0 ?0x00007fd64cdabdd3 in ASN1_item_verify () from
>     /lib64/libcrypto.so.10
>     #1 ?0x00007fd64cdcac58 in internal_verify () from /lib64/libcrypto.so.10
>     #2 ?0x00007fd64cdccaef in X509_verify_cert () from
>     /lib64/libcrypto.so.10
>     #3 ?0x00007fd64d111c68 in ssl_verify_cert_chain () from
>     /lib64/libssl.so.10
>     #4 ?0x00007fd64d0e8cc6 in ssl3_get_client_certificate () from
>     /lib64/libssl.so.10
>     *#5 ?0x00007fd64d0ea3f8 in ssl3_accept () from /lib64/libssl.so.10*
> 
> 
>     ?#0 0x00007ffb65529854 in RSA_verify () from /usr/lib64/libcrypto.so.10
>     ?#1 0x00007ffb6552f1fc in pkey_rsa_verify () from
>     /usr/lib64/libcrypto.so.10
>     ?#2 0x00007ffb65561877 in EVP_DigestVerifyFinal () from
>     /usr/lib64/libcrypto.so.10
>     ?#3 0x00007ffb6556af25 in ASN1_item_verify () from
>     /usr/lib64/libcrypto.so.10
>     ?#4 0x00007ffb65589c58 in internal_verify () from
>     /usr/lib64/libcrypto.so.10
>     ?#5 0x00007ffb6558baef in X509_verify_cert () from
>     /usr/lib64/libcrypto.so.10
>     ?#6 0x00007ffb658d1417 in ssl_add_cert_chain () from
>     /usr/lib64/libssl.so.10
>     ?#7 0x00007ffb658b6095 in ssl3_output_cert_chain () from
>     /usr/lib64/libssl.so.10
>     ?#8 0x00007ffb658ae894 in ssl3_send_client_certificate () from
>     /usr/lib64/libssl.so.10
>     *?#9 0x00007ffb658aeecf in ssl3_connect () from /usr/lib64/libssl.so.10
>     ?#10 0x00007ffb658b8e7e in ssl23_connect () from
>     /usr/lib64/libssl.so.10*
> 
>     ? I am setting context to use SSLv23_method() s. However, I can see
>     ssl3_ methods being called. Is there any issue with that???
> 
>     Given below is SSL* object passed to SSL_do_handshake method.
> 
>     (gdb) p *p_SSLCtx
>     $2 = {version = 771, type = 4096, method = 0x7ffb65af3320, rbio =
>     0x7ffb5819e140, wbio = 0x7ffb58193570, bbio = 0x7ffb58193570,
>     rwstate = 1, in_handshake = 2, *handshake_func = 0x7ffb658aea30
>     <ssl3_connect>*, server = 0, new_session = 0, quiet_shutdown = 0,
>     shutdown = 0, state = 4467,
>     ? rstate = 240, init_buf = 0x7ffb581934b0, init_msg =
>     0x7ffb581e10d4, init_num = 0, init_off = 0, *packet = 0x7ffb581e6633
>     "\026\003\003", packet_length = 0*, s2 = 0x0, s3 = 0x7ffb58195ee0,
>     d1 = 0x0, read_ahead = 0, msg_callback = 0x0, msg_callback_arg =
>     0x0, hit = 0, param = 0x7ffb581933f0,
>     ? cipher_list = 0x0, cipher_list_by_id = 0x0, mac_flags = 0,
>     enc_read_ctx = 0x0, read_hash = 0x0, expand = 0x0, enc_write_ctx =
>     0x0, write_hash = 0x0, compress = 0x0, cert = 0x7ffb58195ba0,
>     sid_ctx_length = 0, sid_ctx = '\000' <repeats 31 times>, session =
>     0x7ffb58198100,
>     ? generate_session_id = 0x0,......
>     ?
> 
> 
>     -- 
>     *Gimhani Uthpala Kankanamge*
> 
> 
> 
> -- 
> *Gimhani Uthpala Kankanamge*

From Michael.Wojcik at microfocus.com  Tue Jan 12 15:30:20 2021
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 12 Jan 2021 15:30:20 +0000
Subject: private key not available for client_cert_cb
In-Reply-To: <8ef3d5ac-0279-744c-f5d0-8ded0bc3bd7d@gmail.com>
References: <292d3b25-9197-4977-a406-0a19abc15a0d@gmail.com>
 <e015a686-88b2-e483-a7da-53e9efabd9fc@nikhef.nl>
 <30032dde-70d1-d438-86ae-77f04a8179cf@gmail.com>
 <2495b1de-13d0-8777-56b0-46ac80cd0203@nikhef.nl>
 <5887cae2-1ecb-4081-1ee9-bcf566a88afe@gmail.com>
 <8011726e-0a7a-a753-983d-b89a24e3e225@nikhef.nl>
 <ab55a9e8-8bd3-c353-3922-1cae88349cb8@gmail.com>
 <8038268f-fd47-1ef8-7dec-ce365b0d453e@nikhef.nl>
 <00492ef8-67aa-8848-97fe-65cf2ba3b38f@gmail.com>
 <e8d14828-97aa-a1ee-52e2-36e124978cc6@nikhef.nl>
 <3e6e027f-812a-ea2d-2d2e-435ad52852b1@gmail.com>
 <471b029c-420c-e45e-d827-ba0576f22847@nikhef.nl>
 <1b20aba6-b88f-2ee1-af0d-23ae19c0746f@gmail.com>
 <640febc7-2499-2284-6625-b7a899ad66ea@nikhef.nl>
 <95f017bb-6946-f37d-e585-05367f0e2da7@gmail.com>
 <DM6PR18MB2700D51CA007871717F6C533F9AE9@DM6PR18MB2700.namprd18.prod.outlook.com>
 <6ea69357-8457-32f4-8803-162c7ec3a29c@gmail.com>
 <DM6PR18MB270035C69BEEB9E0DBAFE706F9AB9@DM6PR18MB2700.namprd18.prod.outlook.com>
 <8ef3d5ac-0279-744c-f5d0-8ded0bc3bd7d@gmail.com>
Message-ID: <DM6PR18MB2700D9FB1E2C4E42DEC02A10F9AA9@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of George
> Sent: Tuesday, 12 January, 2021 00:18

> I'm running this in Windows 10 and when I load the smart card middleware
> PKCS11 DLL, I see the exception:
> Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ exception:
> unsigned long at memory location 0x07FCFA00.

OK. If I were debugging libp11, it would be useful to know what the exception actually was, but as it is all I can say is that it seems to be a libp11 problem. As you noted further below:

> It looks like someone else using a smart card has also encountered similar
> problems in Windows but there is no real answer as to why they are occurring:
> https://www.codeproject.com/Questions/1254182/Smart-card-apis-throw-first-chance-
> exceptions-but

You'll probably have to just swallow the exceptions and retry until it works or your code decides to give up and return an error. Maybe one of the libp11 maintainers or someone else using the library will dig into it at some point.

--
Michael Wojcik

From tiolangit at outlook.com  Tue Jan 12 19:26:23 2021
From: tiolangit at outlook.com (Timo Lange)
Date: Tue, 12 Jan 2021 19:26:23 +0000
Subject: Sign without having the private key
In-Reply-To: <CADqLbz+xG4rWcoNpKkz0Ec9SYL8Y0cwa_HOrR4zNdPpJkUtX0Q@mail.gmail.com>
References: <DB8PR04MB56733EE962D7392D49E54819FDAB0@DB8PR04MB5673.eurprd04.prod.outlook.com>,
 <CADqLbz+xG4rWcoNpKkz0Ec9SYL8Y0cwa_HOrR4zNdPpJkUtX0Q@mail.gmail.com>
Message-ID: <AM0PR04MB566753B156026A567FC6F11CFDAA0@AM0PR04MB5667.eurprd04.prod.outlook.com>

Hi all,

thanks for the input so far.
What I have been playing with is something like this:
RSA_METHOD *meth = RSA_meth_dup(RSA_get_default_method());
RSA_meth_set1_name(meth, "myrsa");
RSA_meth_set_sign(meth, sign);
RSA_meth_set_verify(meth, verify);
RSA_set_default_method(meth);

with sign and verify being functions that I implemented.
But non of these two is ever invoked.
If I also set the init and final callbacks, they are properly executed.

Any ideas?

Br, Timo

________________________________
Von: openssl-users <openssl-users-bounces at openssl.org> im Auftrag von Dmitry Belyavsky <beldmit at gmail.com>
Gesendet: Montag, 11. Januar 2021 19:00
An: openssl-users at openssl.org <openssl-users at openssl.org>
Betreff: Re: Sign without having the private key

Dear Timo,

For 1.0* versions it was possible to provide custom RSA_METHOD and EC_METHOD and implement an IPC callback.
I think it still should work for 1.1.1

It may be also useful to take a look at the async API.

On Mon, Jan 11, 2021 at 6:56 PM Timo Lange <tiolangit at outlook.com<mailto:tiolangit at outlook.com>> wrote:
Hey all,

I have a question similar to http://openssl.6102.n7.nabble.com/private-key-not-available-for-client-cert-cb-td79369.html, that I am actively following, but though it differs in detail.

What I want to achieve is the following:
My client applications runs inside a container and needs to establish a mutual TLS connection to a server.
The client certificate is available in the container.
The root certificate, as well as the client private key is not available inside the container, but stored in a HSM.
For sure the private key may never leave the HSM and also the root certificate should not.

The application cannot directly interfere with the HSM through standardized mechanisms as it is not accessible from inside the container.
For doing so a proprietary interprocess-communication is required.

I now want something like a "verify callback" and a "sign callback".

The "verify callback" would be needed in order to verify the server certificate against the root certificate. It seems to be easy using: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_cert_verify_callback.html

I need the same, something like a "sign callback" also for the private key, when a signature is required during handshake. Such that requests from openSSL to sign something can be forwarded through the inter-process-communication into the HSM. So that the actual signing happens there.
This would only be required during handshake. For the actual encryption symmetric keys can be used, such that the encryption takes place in the openSSL library, not in the HSM.

I assume I need to write a custom ENGINE, but failed with all my approaches.

Can someone give me brief hint on where to start and which API to look at first?

Thanks a lot!
Timo



--
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210112/f8d772e7/attachment.html>

From steffen at sdaoden.eu  Tue Jan 12 19:38:28 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Tue, 12 Jan 2021 20:38:28 +0100
Subject: SSL_CONF_cmd(): SecurityLevel keyword, by chance?
In-Reply-To: <9b337dc8-3d2b-23c4-f4b8-ee332dedafb9@openssl.org>
References: <20210109232436.EqSFj%steffen@sdaoden.eu>
 <eea19b85-2030-15ed-c1d0-d8594c8cd097@openssl.org>
 <20210111221930.UhA3Y%steffen@sdaoden.eu>
 <9b337dc8-3d2b-23c4-f4b8-ee332dedafb9@openssl.org>
Message-ID: <20210112193828.undj8%steffen@sdaoden.eu>

Matt Caswell wrote in
 <9b337dc8-3d2b-23c4-f4b8-ee332dedafb9 at openssl.org>:
 |Please raise your patch as a PR so that it can properly reviewed. You'll
 |also need to submit a CLA:

Sorry no, i do not have a github account nor will i go there.
You may commit it with your own name, or not.
Have a nice day.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From harishvk27 at gmail.com  Thu Jan 14 19:04:30 2021
From: harishvk27 at gmail.com (Harish Kulkarni)
Date: Fri, 15 Jan 2021 00:34:30 +0530
Subject: Memory usage pattern in openssl - limiting number connections in
 connections pool
Message-ID: <CAHV7XR7iTR8V3tQ6UUJcGkR5taRpbf01RoWf_B8hHn+L3hF9=w@mail.gmail.com>

Hello All,

Happy new year and Wish you all the best in 2021.

I am doing a browser memory leak investigation.. as part of the
investigation, we are using heaptrack and our observation is top-most
memory allocation happens in openssl with following memory allocation
back-trace.

>From my investigation.. it seems like this is not a memory leak as such but
the way openssl allocates memory.. for each connection it looks like once
the memory assigned ( like storage certificate ) is not freed.. I am not
sure how this works if you point me to some document explaining memory
usage within openssl could be great help.

My second question is.. is there a way i can limit this connection-pool in
openssl?. For embedded systems we will not have lot of memory so we need to
reduce our memory allocation, and if we can reduce number fo
connections memory is allocated for may be i have an answer to my question.

CRYPTO_malloc
asn1_enc_save
asn1_item_ex_d2i
asn1_template_noexp_d2i
asn1_template_ex_d2i
asn1_item_ex_d2i
ASN1_item_ex_d2i
ASN1_item_d2i
ASN1_item_dup

-thanks
harish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210115/60406970/attachment.html>

From dev at hymes.name  Fri Jan 15 19:06:42 2021
From: dev at hymes.name (Deft Developer)
Date: Fri, 15 Jan 2021 11:06:42 -0800
Subject: Response Verify Failure attempting to configure OCSP server.
Message-ID: <000d01d6eb71$902209f0$b0661dd0$@hymes.name>

I have openssl 1.0.2, on CentOS 7. I'm trying to configure and test ocsp
service.

This host, toberlone, is a certificate authority and signs local certificate
requests.

Questions:

1) Why do I get a "Response "Verify Failure" when testing?

2) How do I configure the CA+signer to serve ocsp requests?

3) How do I configure signature requests to use ocsp?

4) Am I using the openssh ocsp commands correctly?

 

I have the self-signed CA certificate in the file:

caCertfile="/etc/pki/CA/certs/toberlone_certificate_public_certificate-autho
rity_authenticate.crt"

 

This host also has a general server certificate, signed by the CA above, in
the file

serverCertfile="warehouse/certificates/toberlone_certificate_public_server_g
eneral.crt"

 

Working from the example on the ocsp man page, I try to check with

 

openssl ocsp -issuer "$caCertfile" -cert "$serverCertfile" -url
'http://localhost:8083 <http://localhost:8083/> '

 

but I get the error:

 

Response Verify Failure

139661258700688:error:27069065:OCSP routines:OCSP_basic_verify:certificate
verify error:ocsp_vfy.c:138:Verify error:unable to get local issuer
certificate

warehouse/certificates/toberlone_certificate_public_server_general.crt:
unknown

This Update: Jan 14 21:53:36 2021 GMT

 

I fear that I have not configured my CA and or signing requests for ocsp.
First, I'm uncertain where to locate the line

authorityInfoAccess = OCSP;URI:http:// <http://toblerone:8083/> toblerone
<http://toblerone:8083/> :808 <http://toblerone:8083/> 3
<http://toblerone:8083/> 

 

I put it in the "ca_extensions" section of the ca.conf, no openssl commands
report errors.

 

Some, not all, blogs say the ca.conf should have an ocsp section. Some say
it should be called "ocsp", others "v3_OCSP":

 

[ ocsp ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = OCSPSigning

 

Other blogs say the ocsp section should be in the server_sig_request.conf
files that generate the signature requests. My server_sig_request.conf files
do not have any ocsp stuff in them. Should they include "OCSPSigning" or
some other mention of ocsp? 

 

If I insert ocsp sections into the ca or server_sig_request conf files, how
does that effect the command line for creating the self-signed CA cert,
and/or the command for the CA to sign the request? Specifically I wonder
about using the -extensions option, and using the -CAFile option when I try
a test connection to the ocsp server.

 

Finally, I'm uncertain about how the ocsp server uses relative v.s. absolute
paths. Does the current directory matter when starting the ocsp server? Does
it matter when attempting to test via the URI? 

 

I will post copies of the ca.conf and server_sig_request.conf, if requested.

 

Thanks!

 

Deft

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210115/4ad28370/attachment.html>

From housley at vigilsec.com  Tue Jan 19 23:26:23 2021
From: housley at vigilsec.com (Russ Housley)
Date: Tue, 19 Jan 2021 18:26:23 -0500
Subject: RSA-OAEP Certificate
Message-ID: <699655A0-1D79-468D-B6A1-CA158DB95D6E@vigilsec.com>

I am looking a test certificate that contains an RSA-OAEP subject public key (OID = id-RSAES-OAEP from RFC 4055) and is signed with RSA-PSS (OID = id-RSASSA-PSS also from RFC 4055).  I have not ben able to find a way to generate such a certificate with OpenSSL.  If you have a pointer to such a certificate or a recipe for generating one, I would appreciate the pointer.

  Russ

From openssl-users at dukhovni.org  Wed Jan 20 01:24:24 2021
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 19 Jan 2021 20:24:24 -0500
Subject: RSA-OAEP Certificate
In-Reply-To: <699655A0-1D79-468D-B6A1-CA158DB95D6E@vigilsec.com>
References: <699655A0-1D79-468D-B6A1-CA158DB95D6E@vigilsec.com>
Message-ID: <YAeGSFaEeLXsJ+2N@straasha.imrryr.org>

On Tue, Jan 19, 2021 at 06:26:23PM -0500, Russ Housley wrote:

> I am looking a test certificate that contains an RSA-OAEP subject
> public key (OID = id-RSAES-OAEP from RFC 4055) and is signed with
> RSA-PSS (OID = id-RSASSA-PSS also from RFC 4055).  I have not ben able
> to find a way to generate such a certificate with OpenSSL.  If you
> have a pointer to such a certificate or a recipe for generating one, I
> would appreciate the pointer.

While RSA-PSS keys are supported by genpkey(1), I don't see any support
for generating RSAES-OAEP keys in any of the command-line utilities.

It does not look like RSAES-OAEP SPKI are supported even at the API
level.  Perhaps I did not look hard enough...

-- 
    Viktor.

From harishvk27 at gmail.com  Wed Jan 20 03:25:13 2021
From: harishvk27 at gmail.com (Harish Kulkarni)
Date: Wed, 20 Jan 2021 08:55:13 +0530
Subject: sessions reuse in openssl
Message-ID: <CAHV7XR6sZ7qK22PmzrdHo7UwOCxKtf91X8_jBmv+5Oqk+bPRww@mail.gmail.com>

Hello All,

For some experiments i want to stop session re-use in openssl.. is there a
way to stop reusing of same session?.

-thanks
harish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210120/b7c1285b/attachment-0001.html>

From openssl-users at dukhovni.org  Wed Jan 20 04:55:50 2021
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 19 Jan 2021 23:55:50 -0500
Subject: sessions reuse in openssl
In-Reply-To: <CAHV7XR6sZ7qK22PmzrdHo7UwOCxKtf91X8_jBmv+5Oqk+bPRww@mail.gmail.com>
References: <CAHV7XR6sZ7qK22PmzrdHo7UwOCxKtf91X8_jBmv+5Oqk+bPRww@mail.gmail.com>
Message-ID: <YAe31vWucRq5z1xI@straasha.imrryr.org>

On Wed, Jan 20, 2021 at 08:55:13AM +0530, Harish Kulkarni wrote:

> For some experiments i want to stop session re-use in openssl.. is there a
> way to stop reusing of same session?.

Your question is not sufficiently specific.  Are you looking to not
reuse a session in an client or a server?  Is the server issuing
stateless session tickets or doing fully stateful resumption with
an in memory session cache?  Are you using TLS 1.2 or TLS 1.3?

Post a reasonable level of detail outlining where the decision
to reuse or not reuse the session is going to be made, and how
session resumption is performed when not disabled.

-- 
    Viktor.

From harishvk27 at gmail.com  Wed Jan 20 06:03:21 2021
From: harishvk27 at gmail.com (Harish Kulkarni)
Date: Wed, 20 Jan 2021 11:33:21 +0530
Subject: sessions reuse in openssl
In-Reply-To: <YAe31vWucRq5z1xI@straasha.imrryr.org>
References: <CAHV7XR6sZ7qK22PmzrdHo7UwOCxKtf91X8_jBmv+5Oqk+bPRww@mail.gmail.com>
 <YAe31vWucRq5z1xI@straasha.imrryr.org>
Message-ID: <CAHV7XR4+iqq0rD4QtkVoC_XJTT_d-FOTB-247wsLDbEJ=WSzYQ@mail.gmail.com>

I am working on memory analysis of openssl. One of the observation is the
memory allocated by d2i_X509() API (returned in x) is not being freed after
the connection is closed.. and this memory is stored as part of session.. i
want to limit number of sessions which we cache for re-use.. or if possible
completely avoid session caching.


Using TLS 1.3


-thanks

harish


        x = d2i_X509(NULL, &q, l); //// <<<<<<< memory allocated HERE (HVK)

        if (x == NULL) {

            al = SSL_AD_BAD_CERTIFICATE;

            SSLerr(SSL_F_SSL3_GET_SERVER_CERTIFICATE, ERR_R_ASN1_LIB);

            goto f_err;

        }

        if (q != (p + l)) {

            al = SSL_AD_DECODE_ERROR;

            SSLerr(SSL_F_SSL3_GET_SERVER_CERTIFICATE,

                   SSL_R_CERT_LENGTH_MISMATCH);

            goto f_err;

        }

        if (!sk_X509_push(sk, x)) { ////// STORED IN LIST HERE (HVK)

            SSLerr(SSL_F_SSL3_GET_SERVER_CERTIFICATE, ERR_R_MALLOC_FAILURE);

            goto err;

        }

        x = NULL;

        nc += l + 3;

        p = q;

    }


    i = ssl_verify_cert_chain(s, sk);

    if ((s->verify_mode != SSL_VERIFY_NONE) && (i <= 0)

#ifndef OPENSSL_NO_KRB5

        && !((s->s3->tmp.new_cipher->algorithm_mkey & SSL_kKRB5) &&

             (s->s3->tmp.new_cipher->algorithm_auth & SSL_aKRB5))

#endif                          /* OPENSSL_NO_KRB5 */

        ) {

        al = ssl_verify_alarm_type(s->verify_result);

        SSLerr(SSL_F_SSL3_GET_SERVER_CERTIFICATE,

               SSL_R_CERTIFICATE_VERIFY_FAILED);

        goto f_err;

    }

    ERR_clear_error();          /* but we keep s->verify_result */


    sc = ssl_sess_cert_new();

    if (sc == NULL)

        goto err;


    if (s->session->sess_cert)

        ssl_sess_cert_free(s->session->sess_cert);

    s->session->sess_cert = sc;


    sc->cert_chain = sk; ///// (HVK) THE CHAIN IS STORED HERE.. as part of
session struct.. not freed.

    /*

     * Inconsistency alert: cert_chain does include the peer's certificate,

     * which we don't include in s3_srvr.c

     */

    x = sk_X509_value(sk, 0);

    sk = NULL;

On Wed, Jan 20, 2021 at 10:26 AM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Wed, Jan 20, 2021 at 08:55:13AM +0530, Harish Kulkarni wrote:
>
> > For some experiments i want to stop session re-use in openssl.. is there
> a
> > way to stop reusing of same session?.
>
> Your question is not sufficiently specific.  Are you looking to not
> reuse a session in an client or a server?  Is the server issuing
> stateless session tickets or doing fully stateful resumption with
> an in memory session cache?  Are you using TLS 1.2 or TLS 1.3?
>
> Post a reasonable level of detail outlining where the decision
> to reuse or not reuse the session is going to be made, and how
> session resumption is performed when not disabled.
>
> --
>     Viktor.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210120/84eb4c1a/attachment-0001.html>

From openssl-users at dukhovni.org  Wed Jan 20 06:27:05 2021
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 20 Jan 2021 01:27:05 -0500
Subject: sessions reuse in openssl
In-Reply-To: <CAHV7XR4+iqq0rD4QtkVoC_XJTT_d-FOTB-247wsLDbEJ=WSzYQ@mail.gmail.com>
References: <CAHV7XR6sZ7qK22PmzrdHo7UwOCxKtf91X8_jBmv+5Oqk+bPRww@mail.gmail.com>
 <YAe31vWucRq5z1xI@straasha.imrryr.org>
 <CAHV7XR4+iqq0rD4QtkVoC_XJTT_d-FOTB-247wsLDbEJ=WSzYQ@mail.gmail.com>
Message-ID: <YAfNOWkvvOanEA4J@straasha.imrryr.org>

On Wed, Jan 20, 2021 at 11:33:21AM +0530, Harish Kulkarni wrote:

> I am working on memory analysis of OpenSSL.  One of the observation is the
> memory allocated by d2i_X509() API (returned in x) is not being freed after
> the connection is closed.. and this memory is stored as part of session.. I
> want to limit number of sessions which we cache for re-use.. or if possible
> completely avoid session caching.

You still have not explicitly stated whether the issue is server-side or
client-side.  Reading between the lines, it seems to be client-side.
The server certificate is an expectedd part of the session object.  When
you free the session object, the certificate object is also freed.

In OpenSSL, X.509 certificate objects are reference-counted, you also
need to be careful with functions that inspect the server certificate
and increment its reference count as a side-effect.  If you use these,
you need to call X509_free() when the returned certificate is no longer
needed.

There is no automatic client-side session reuse in OpenSSL, so you don't
need to do anything to avoid resuming sessions.  Internal caching of
client-side sessions is off by default.  See the manual page of
SSL_CTX_set_session_cache_mode(3).

-- 
    Viktor.

From dheinz at softwarekey.com  Wed Jan 20 20:18:22 2021
From: dheinz at softwarekey.com (Dan Heinz)
Date: Wed, 20 Jan 2021 20:18:22 +0000
Subject: OpenSSL 1.1.1g Windows build slow rsa tests
Message-ID: <SN7PR06MB7214F223DE61E2620D85B4BBD9A29@SN7PR06MB7214.namprd06.prod.outlook.com>

Hello,

I'm building openssl 1.1.1g  on multiple platforms and I found that the rsa speed tests are significantly slower in my build than on the other OS platforms (Linux and macOS).

I downloaded a Windows 64-bit binary distribution of openssl from https://kb.firedaemon.com/support/solutions/articles/4000121705 as they include the configure parameters used for their build.
I ran the speed rsa tests on their openssl Windows 64-bit binary and they were much faster than the tests on my build.

Here's some output.
My openssl binary executed with openssl speed rsa:
Doing 2048 bits private rsa's for 10s: 409 2048 bits private RSA's in 10.00s
Doing 2048 bits public rsa's for 10s: 15663 2048 bits public RSA's in 10.02s
Doing 4096 bits private rsa's for 10s: 60 4096 bits private RSA's in 10.00s
Doing 4096 bits public rsa's for 10s: 4316 4096 bits public RSA's in 10.02s
OpenSSL 1.1.1g  21 Apr 2020
built on: Wed Jan 20 18:38:14 2021 UTC
options:bn(64,64) rc4(int) des(long) aes(partial) blowfish(ptr)
compiler: cl /Fdossl_static.pdb  /Gs0 /GF /Gy /MT /Zi /W3 /wd4090 /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.024450s 0.000639s     40.9   1563.9
rsa 4096 bits 0.166667s 0.002321s      6.0    430.9

Here is the downloaded binary from https://kb.firedaemon.com/support/solutions/articles/4000121705:
Doing 2048 bits private rsa's for 10s: 1622 2048 bits private RSA's in 10.02s
Doing 2048 bits public rsa's for 10s: 72622 2048 bits public RSA's in 10.00s
Doing 4096 bits private rsa's for 10s: 255 4096 bits private RSA's in 10.03s
Doing 4096 bits public rsa's for 10s: 18976 4096 bits public RSA's in 10.00s
OpenSSL 1.1.1j-dev  xx XXX xxxx
built on: Wed Jan  6 11:11:12 2021 UTC
options:bn(64,64) rc4(int) des(long) aes(partial) idea(int) blowfish(ptr)
compiler: cl /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.006175s 0.000138s    161.9   7262.2
rsa 4096 bits 0.039338s 0.000527s     25.4   1897.6

That is a little over 4 times faster.

Here are my configure parameters:
Configure VC-WIN64A no-shared  no-asm no-idea no-mdc2 no-rc5 no-ssl2 no-ssl3 no-zlib no-comp no-pinshared no-ui-console  -DOPENSSL_NO_DEPRECATED --api=1.1.0

And their configure parameters:
Configure VC-WIN64A no-asm no-ssl3 no-zlib no-comp no-ui-console --api=1.1.0 --prefix="%openssl-dst%" --openssldir=ssl -DOPENSSL_NO_DEPRECATED

Both my build and theirs are built with Visual Studio 2015.
Any ideas why my build is so much slower?  Is there something in my configuration that might cause this?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210120/2e00e174/attachment.html>

From pauli at openssl.org  Wed Jan 20 23:18:53 2021
From: pauli at openssl.org (Dr Paul Dale)
Date: Thu, 21 Jan 2021 09:18:53 +1000
Subject: OpenSSL 1.1.1g Windows build slow rsa tests
In-Reply-To: <SN7PR06MB7214F223DE61E2620D85B4BBD9A29@SN7PR06MB7214.namprd06.prod.outlook.com>
References: <SN7PR06MB7214F223DE61E2620D85B4BBD9A29@SN7PR06MB7214.namprd06.prod.outlook.com>
Message-ID: <b2aef85d-5543-a078-160d-2b140a217b7d@openssl.org>

Try building without the no-asm configuration option.

Pauli

On 21/1/21 6:18 am, Dan Heinz wrote:
> Hello,
> 
> I?m building openssl 1.1.1g ?on multiple platforms and I found that the 
> rsa speed tests are significantly slower in my build than on the other 
> OS platforms (Linux and macOS).
> 
> I downloaded a Windows 64-bit binary distribution of openssl from 
> https://kb.firedaemon.com/support/solutions/articles/4000121705 
> <https://kb.firedaemon.com/support/solutions/articles/4000121705> as 
> they include the configure parameters used for their build.
> 
> I ran the speed rsa tests on their openssl Windows 64-bit binary and 
> they were much faster than the tests on my build.
> 
> Here?s some output.
> My openssl binary executed with openssl speed rsa:
> 
> Doing 2048 bits private rsa's for 10s: 409 2048 bits private RSA's in 10.00s
> 
> Doing 2048 bits public rsa's for 10s: 15663 2048 bits public RSA's in 10.02s
> 
> Doing 4096 bits private rsa's for 10s: 60 4096 bits private RSA's in 10.00s
> 
> Doing 4096 bits public rsa's for 10s: 4316 4096 bits public RSA's in 10.02s
> 
> OpenSSL 1.1.1g? 21 Apr 2020
> 
> built on: Wed Jan 20 18:38:14 2021 UTC
> 
> options:bn(64,64) rc4(int) des(long) aes(partial) blowfish(ptr)
> 
> compiler: cl /Fdossl_static.pdb? /Gs0 /GF /Gy /MT /Zi /W3 /wd4090 
> /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED
> 
>  ????????????????? sign??? verify??? sign/s verify/s
> 
> rsa 2048 bits 0.024450s 0.000639s???? 40.9?? 1563.9
> 
> rsa 4096 bits 0.166667s 0.002321s????? 6.0??? 430.9
> 
> Here is the downloaded binary from 
> https://kb.firedaemon.com/support/solutions/articles/4000121705 
> <https://kb.firedaemon.com/support/solutions/articles/4000121705>:
> Doing 2048 bits private rsa's for 10s: 1622 2048 bits private RSA's in 
> 10.02s
> 
> Doing 2048 bits public rsa's for 10s: 72622 2048 bits public RSA's in 10.00s
> 
> Doing 4096 bits private rsa's for 10s: 255 4096 bits private RSA's in 10.03s
> 
> Doing 4096 bits public rsa's for 10s: 18976 4096 bits public RSA's in 10.00s
> 
> OpenSSL 1.1.1j-dev? xx XXX xxxx
> 
> built on: Wed Jan? 6 11:11:12 2021 UTC
> 
> options:bn(64,64) rc4(int) des(long) aes(partial) idea(int) blowfish(ptr)
> 
> compiler: cl /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo 
> /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED
> 
>  ????????????????? sign??? verify??? sign/s verify/s
> 
> rsa 2048 bits 0.006175s 0.000138s??? 161.9?? 7262.2
> 
> rsa 4096 bits 0.039338s 0.000527s???? 25.4?? 1897.6
> 
> That is a little over 4 times faster.
> 
> Here are my configure parameters:
> Configure VC-WIN64A no-shared? no-asm no-idea no-mdc2 no-rc5 no-ssl2 
> no-ssl3 no-zlib no-comp no-pinshared no-ui-console 
>  ?-DOPENSSL_NO_DEPRECATED --api=1.1.0
> 
> And their configure parameters:
> Configure VC-WIN64Ano-asm no-ssl3 no-zlib no-comp no-ui-console 
> --api=1.1.0 --prefix="%openssl-dst%" --openssldir=ssl 
> -DOPENSSL_NO_DEPRECATED
> 
> Both my build and theirs are built with Visual Studio 2015.
> 
> Any ideas why my build is so much slower?? Is there something in my 
> configuration that might cause this?
> 

From uri at ll.mit.edu  Thu Jan 21 00:22:28 2021
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 21 Jan 2021 00:22:28 +0000
Subject: Parsing and generating CBOR certificates?
Message-ID: <3C079B3F-0FC8-4BB0-B927-50481604939F@ll.mit.edu>

I need to work with CBOR-encoded certificates. Is there any way to use OpenSSL to parse and/or generate certs in CBOR encoding?

Thanks

Regards,
Uri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5818 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210121/36a35670/attachment-0001.bin>

From bkaduk at akamai.com  Thu Jan 21 00:25:50 2021
From: bkaduk at akamai.com (Kaduk, Ben)
Date: Thu, 21 Jan 2021 00:25:50 +0000
Subject: Parsing and generating CBOR certificates?
In-Reply-To: <3C079B3F-0FC8-4BB0-B927-50481604939F@ll.mit.edu>
References: <3C079B3F-0FC8-4BB0-B927-50481604939F@ll.mit.edu>
Message-ID: <1611188745094.51849@akamai.com>

No.  OpenSSL does not include any CBOR protocol support.
I'm also not sure what you mean by "CBOR-encoded certificate"; I don't
know of any such thing other than
https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/
which is very much still a work in progress.

-Ben

________________________________________
From: Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu>
Sent: Wednesday, January 20, 2021 4:22 PM
To: openssl-users
Subject: Parsing and generating CBOR certificates?

I need to work with CBOR-encoded certificates. Is there any way to use OpenSSL to parse and/or generate certs in CBOR encoding?

Thanks

Regards,
Uri

From uri at ll.mit.edu  Thu Jan 21 00:35:24 2021
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 21 Jan 2021 00:35:24 +0000
Subject: Parsing and generating CBOR certificates?
In-Reply-To: <1611188745094.51849@akamai.com>
References: <1611188745094.51849@akamai.com>
Message-ID: <6AE2764D-42F0-496A-860C-0FC4237C843D@ll.mit.edu>

I meant not "CBOR protocol" (which,  in all likelihood, doesn't and shouldn't exist) but CBOR encoding of X.509 certificates (which, hopefully, does exists).

At least, I'm looking for a tool that would convert between these two encodings (DER and CBOR) for specific objects (X.509-conformant certificates).

Thanks

Regards,
Uri

> On Jan 20, 2021, at 19:26, Kaduk, Ben <bkaduk at akamai.com> wrote:
> 
> ?No.  OpenSSL does not include any CBOR protocol support.
> I'm also not sure what you mean by "CBOR-encoded certificate"; I don't
> know of any such thing other than
> https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/
> which is very much still a work in progress.
> 
> -Ben
> 
> ________________________________________
> From: Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu>
> Sent: Wednesday, January 20, 2021 4:22 PM
> To: openssl-users
> Subject: Parsing and generating CBOR certificates?
> 
> I need to work with CBOR-encoded certificates. Is there any way to use OpenSSL to parse and/or generate certs in CBOR encoding?
> 
> Thanks
> 
> Regards,
> Uri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210121/5f38c310/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5818 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210121/5f38c310/attachment.bin>

From Michael.Wojcik at microfocus.com  Thu Jan 21 00:37:09 2021
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 21 Jan 2021 00:37:09 +0000
Subject: OpenSSL 1.1.1g Windows build slow rsa tests
In-Reply-To: <b2aef85d-5543-a078-160d-2b140a217b7d@openssl.org>
References: <SN7PR06MB7214F223DE61E2620D85B4BBD9A29@SN7PR06MB7214.namprd06.prod.outlook.com>
 <b2aef85d-5543-a078-160d-2b140a217b7d@openssl.org>
Message-ID: <DM6PR18MB2700594D1ADA09944850AEC4F9A11@DM6PR18MB2700.namprd18.prod.outlook.com>

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Dr Paul
> Dale
> Sent: Wednesday, 20 January, 2021 16:19
>
> Try building without the no-asm configuration option.

That was my first thought, but according to Dan's message, the firedaemon version is also built with no-asm.

The only relevant differences I see between the two builds are static (Dan's) versus dynamic (firedaemon's) linkage:

> On 21/1/21 6:18 am, Dan Heinz wrote:

> > compiler: cl /Fdossl_static.pdb  /Gs0 /GF /Gy /MT /Zi /W3 /wd4090
> > /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED

/MT uses the static-linked MSVC runtime.

> > Here is the downloaded binary from
> > https://kb.firedaemon.com/support/solutions/articles/4000121705
> > <https://kb.firedaemon.com/support/solutions/articles/4000121705>:
> > compiler: cl /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
> > /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED

/MD uses the dynamic-linked MSVC runtime.

> > Here are my configure parameters:
> > Configure VC-WIN64A no-shared  no-asm no-idea no-mdc2 no-rc5 no-ssl2
> > no-ssl3 no-zlib no-comp no-pinshared no-ui-console
> >   -DOPENSSL_NO_DEPRECATED --api=1.1.0
> >
> > And their configure parameters:
> > Configure VC-WIN64Ano-asm no-ssl3 no-zlib no-comp no-ui-console
> > --api=1.1.0 --prefix="%openssl-dst%" --openssldir=ssl
> > -DOPENSSL_NO_DEPRECATED

Assuming the lack of a space between "VC_WIN64A" and "no-asm" is a typo, they're also building with no-asm, and the only significant difference for this case that I can see is no-shared. (no-pinshared looks even less likely to affect this test, and does it even have any effect when building no-shared?)

Linking with /MT will affect code size and layout, which could adversely affect code caching. It's not impossible that would have a factor-of-four penalty on compute-bound code. I'm reluctant to conclude that's the problem, though, without more evidence.

Unfortunately tracking this down would likely require profiling.

That's assuming Dan is correct about the firedaemon build being configured with no-asm.

--
Michael Wojcik

From bkaduk at akamai.com  Thu Jan 21 00:37:13 2021
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Wed, 20 Jan 2021 16:37:13 -0800
Subject: Parsing and generating CBOR certificates?
In-Reply-To: <6AE2764D-42F0-496A-860C-0FC4237C843D@ll.mit.edu>
References: <1611188745094.51849@akamai.com>
 <6AE2764D-42F0-496A-860C-0FC4237C843D@ll.mit.edu>
Message-ID: <20210121003712.GO3538@akamai.com>

And again, where do you believe such a conversion is specified?
The IETF internet-draft I reference is a way to do so, but it is (to repeat)
very much a work in progress.

-Ben

On Thu, Jan 21, 2021 at 12:35:24AM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> I meant not "CBOR protocol" (which,  in all likelihood, doesn't and shouldn't exist) but CBOR encoding of X.509 certificates (which, hopefully, does exists).
> 
> At least, I'm looking for a tool that would convert between these two encodings (DER and CBOR) for specific objects (X.509-conformant certificates).
> 
> Thanks
> 
> Regards,
> Uri
> 
> > On Jan 20, 2021, at 19:26, Kaduk, Ben <bkaduk at akamai.com> wrote:
> > 
> > ?No.  OpenSSL does not include any CBOR protocol support.
> > I'm also not sure what you mean by "CBOR-encoded certificate"; I don't
> > know of any such thing other than
> > https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/
> > which is very much still a work in progress.
> > 
> > -Ben
> > 
> > ________________________________________
> > From: Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu>
> > Sent: Wednesday, January 20, 2021 4:22 PM
> > To: openssl-users
> > Subject: Parsing and generating CBOR certificates?
> > 
> > I need to work with CBOR-encoded certificates. Is there any way to use OpenSSL to parse and/or generate certs in CBOR encoding?
> > 
> > Thanks
> > 
> > Regards,
> > Uri



From uri at ll.mit.edu  Thu Jan 21 01:07:45 2021
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 21 Jan 2021 01:07:45 +0000
Subject: Parsing and generating CBOR certificates?
In-Reply-To: <20210121003712.GO3538@akamai.com>
References: <1611188745094.51849@akamai.com>
 <6AE2764D-42F0-496A-860C-0FC4237C843D@ll.mit.edu>
 <20210121003712.GO3538@akamai.com>
Message-ID: <50D045AE-043C-44AB-84B5-C37ADE90E5A3@ll.mit.edu>

On 1/20/21, 19:42, "Benjamin Kaduk" <bkaduk at akamai.com> wrote:
>    And again, where do you believe such a conversion is specified?

What do you mean "specified"? There's an ASN.1 "specification" of the certificate format, which theoretically can be encoded into whatever - DER, PER, OER, etc. One such tool (https://github.com/mouse07410/asn1c.git that I use) generates from ASN.1 file codecs for many encoding formats, and is able to convert between them.

Unfortunately, there's no ASN.1 -> CBOR codec generator, AFAIK, which is why I'm asking here.

>   The IETF internet-draft I reference is a way to do so, but it is (to repeat)
>   very much a work in progress.

Understood. Do you know if there's any code behind it? Or just the "theory"?

Thanks!

    On Thu, Jan 21, 2021 at 12:35:24AM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
    > I meant not "CBOR protocol" (which,  in all likelihood, doesn't and shouldn't exist) but CBOR encoding of X.509 certificates (which, hopefully, does exists).
    > 
    > At least, I'm looking for a tool that would convert between these two encodings (DER and CBOR) for specific objects (X.509-conformant certificates).
    > 
    > Thanks
    > 
    > Regards,
    > Uri
    > 
    > > On Jan 20, 2021, at 19:26, Kaduk, Ben <bkaduk at akamai.com> wrote:
    > > 
    > > No.  OpenSSL does not include any CBOR protocol support.
    > > I'm also not sure what you mean by "CBOR-encoded certificate"; I don't
    > > know of any such thing other than
    > > https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/
    > > which is very much still a work in progress.
    > > 
    > > -Ben
    > > 
    > > ________________________________________
    > > From: Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu>
    > > Sent: Wednesday, January 20, 2021 4:22 PM
    > > To: openssl-users
    > > Subject: Parsing and generating CBOR certificates?
    > > 
    > > I need to work with CBOR-encoded certificates. Is there any way to use OpenSSL to parse and/or generate certs in CBOR encoding?
    > > 
    > > Thanks
    > > 
    > > Regards,
    > > Uri


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210121/31712602/attachment.bin>

From pauli at openssl.org  Thu Jan 21 02:27:35 2021
From: pauli at openssl.org (Dr Paul Dale)
Date: Thu, 21 Jan 2021 12:27:35 +1000
Subject: OpenSSL 1.1.1g Windows build slow rsa tests
In-Reply-To: <DM6PR18MB2700594D1ADA09944850AEC4F9A11@DM6PR18MB2700.namprd18.prod.outlook.com>
References: <SN7PR06MB7214F223DE61E2620D85B4BBD9A29@SN7PR06MB7214.namprd06.prod.outlook.com>
 <b2aef85d-5543-a078-160d-2b140a217b7d@openssl.org>
 <DM6PR18MB2700594D1ADA09944850AEC4F9A11@DM6PR18MB2700.namprd18.prod.outlook.com>
Message-ID: <ade515d4-08be-2c44-d663-2bfe278ae671@openssl.org>

I'd suggest giving a build without the no-asm option a try.  The 
performance difference is usually quite significant.

Statis vs dynamic builds wouldn't normally be associated with such a 
large difference.  If the difference were routinely this large, nobody 
would use dynamic linking.


Pauli

On 21/1/21 10:37 am, Michael Wojcik wrote:
>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Dr Paul
>> Dale
>> Sent: Wednesday, 20 January, 2021 16:19
>>
>> Try building without the no-asm configuration option.
> 
> That was my first thought, but according to Dan's message, the firedaemon version is also built with no-asm.
> 
> The only relevant differences I see between the two builds are static (Dan's) versus dynamic (firedaemon's) linkage:
> 
>> On 21/1/21 6:18 am, Dan Heinz wrote:
> 
>>> compiler: cl /Fdossl_static.pdb  /Gs0 /GF /Gy /MT /Zi /W3 /wd4090
>>> /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED
> 
> /MT uses the static-linked MSVC runtime.
> 
>>> Here is the downloaded binary from
>>> https://kb.firedaemon.com/support/solutions/articles/4000121705
>>> <https://kb.firedaemon.com/support/solutions/articles/4000121705>:
>>> compiler: cl /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
>>> /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_NO_DEPRECATED
> 
> /MD uses the dynamic-linked MSVC runtime.
> 
>>> Here are my configure parameters:
>>> Configure VC-WIN64A no-shared  no-asm no-idea no-mdc2 no-rc5 no-ssl2
>>> no-ssl3 no-zlib no-comp no-pinshared no-ui-console
>>>    -DOPENSSL_NO_DEPRECATED --api=1.1.0
>>>
>>> And their configure parameters:
>>> Configure VC-WIN64Ano-asm no-ssl3 no-zlib no-comp no-ui-console
>>> --api=1.1.0 --prefix="%openssl-dst%" --openssldir=ssl
>>> -DOPENSSL_NO_DEPRECATED
> 
> Assuming the lack of a space between "VC_WIN64A" and "no-asm" is a typo, they're also building with no-asm, and the only significant difference for this case that I can see is no-shared. (no-pinshared looks even less likely to affect this test, and does it even have any effect when building no-shared?)
> 
> Linking with /MT will affect code size and layout, which could adversely affect code caching. It's not impossible that would have a factor-of-four penalty on compute-bound code. I'm reluctant to conclude that's the problem, though, without more evidence.
> 
> Unfortunately tracking this down would likely require profiling.
> 
> That's assuming Dan is correct about the firedaemon build being configured with no-asm.
> 
> --
> Michael Wojcik
> 

From levitte at openssl.org  Thu Jan 21 10:27:21 2021
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 21 Jan 2021 11:27:21 +0100
Subject: RSA-OAEP Certificate
In-Reply-To: <YAeGSFaEeLXsJ+2N@straasha.imrryr.org>
References: <699655A0-1D79-468D-B6A1-CA158DB95D6E@vigilsec.com>
 <YAeGSFaEeLXsJ+2N@straasha.imrryr.org>
Message-ID: <87zh12wpo6.wl-levitte@openssl.org>

On Wed, 20 Jan 2021 02:24:24 +0100,
Viktor Dukhovni wrote:
> 
> On Tue, Jan 19, 2021 at 06:26:23PM -0500, Russ Housley wrote:
> 
> > I am looking a test certificate that contains an RSA-OAEP subject
> > public key (OID = id-RSAES-OAEP from RFC 4055) and is signed with
> > RSA-PSS (OID = id-RSASSA-PSS also from RFC 4055).  I have not ben able
> > to find a way to generate such a certificate with OpenSSL.  If you
> > have a pointer to such a certificate or a recipe for generating one, I
> > would appreciate the pointer.
> 
> While RSA-PSS keys are supported by genpkey(1), I don't see any support
> for generating RSAES-OAEP keys in any of the command-line utilities.
> 
> It does not look like RSAES-OAEP SPKI are supported even at the API
> level.  Perhaps I did not look hard enough...

You are entirely correct.  I was surprised when I discovered this, but
there you go.  I suppose that the early implementation was "on demand", 
i.e. RSA-PSS keys were seen out in the wild, prompting us ("someone")
to add support for them.  RSA-OAEP keys haven't had the same demand,
so no one implemented support for them as such.

We do have support for RSA-OAEP, but only on an operational level,
i.e. encryption and decryption with a "normal" RSA key and additional
OAEP parameters for the operation.  On a command level, it means that
it's possible to have OAEP padding mode with 'openssl pkeyutl'.

A few of us in the team are keenly aware of the lack of RSA-OAEP key
support, and we have discussed internally whether we should add that
with OpenSSL 3.0...  I don't quite recall if we came to an actual "yay
or nay" decision, it's just not been a top priority item.  That being
said, I can't see that any of us will protest if someone chooses to
chip in and add such support, at least in our providers [*]

-----
[*] in other words, PR welcome...  I believe that the RSA-PSS work
    can be a good enough template that RSA-OAEP key support doesn't
    have to be too hard to do.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From dev at ddvo.net  Thu Jan 21 12:05:21 2021
From: dev at ddvo.net (David von Oheimb)
Date: Thu, 21 Jan 2021 13:05:21 +0100
Subject: Parsing and generating CBOR certificates?
In-Reply-To: <50D045AE-043C-44AB-84B5-C37ADE90E5A3@ll.mit.edu>
References: <1611188745094.51849@akamai.com>
 <6AE2764D-42F0-496A-860C-0FC4237C843D@ll.mit.edu>
 <20210121003712.GO3538@akamai.com>
 <50D045AE-043C-44AB-84B5-C37ADE90E5A3@ll.mit.edu>
Message-ID: <6b95b753-fb30-a985-61c0-21ac95074e2d@ddvo.net>

I'd welcome support for CBOR(-encoded) certificates since they can save
a lot of space
for both the data itself and the code handling it, which may be vital
for IoT scenarios, for instance.
It looks like the standardization of their definition got pretty far
already.

Although it is certainly possible to convert between DER-encoded ASN.1
(or at least its subset needed for X.509 certs) and CBOR,
this is not strictly needed since there is a definition of natively
signed CBOR certs.
Thus all the ASN.1 fuzz, which is bulky and error-prone to implement and
use, can be avoided then.

https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress writes:

   The use of natively signed CBOR certificates removes the need for
   ASN.1 encoding, which is a rich source of security vulnerabilities.


It may be also worth noting in this context that due to it sheer size
the OpenSSL code itself is not suited for constrained systems.
Yet even then it would make sense if OpenSSL supported CBOR certs
because they could be used by TLS peers on constrained systems.
Moreover, when using only natively signed CBOR certs it should be possible
(though likely hard to achieve with the current strongly ASN.1 entangled
libcrypto code)
to build OpenSSL without any ASN.1 support, which should reduce code
size drastically.

I suggest opening a feature request at
https://github.com/openssl/openssl/issues

Regards,
??? David

On 21.01.21 02:07, Blumenthal, Uri - 0553 - MITLL wrote:
> On 1/20/21, 19:42, "Benjamin Kaduk" <bkaduk at akamai.com> wrote:
>>    And again, where do you believe such a conversion is specified?
> What do you mean "specified"? There's an ASN.1 "specification" of the certificate format, which theoretically can be encoded into whatever - DER, PER, OER, etc. One such tool (https://github.com/mouse07410/asn1c.git that I use) generates from ASN.1 file codecs for many encoding formats, and is able to convert between them.
>
> Unfortunately, there's no ASN.1 -> CBOR codec generator, AFAIK, which is why I'm asking here.
>
>>   The IETF internet-draft I reference is a way to do so, but it is (to repeat)
>>   very much a work in progress.
> Understood. Do you know if there's any code behind it? Or just the "theory"?
>
> Thanks!
>
> On Thu, Jan 21, 2021 at 12:35:24AM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
>> I meant not "CBOR protocol" (which,  in all likelihood, doesn't and shouldn't exist) but CBOR encoding of X.509 certificates (which, hopefully, does exists).
>>
>> At least, I'm looking for a tool that would convert between these two encodings (DER and CBOR) for specific objects (X.509-conformant certificates).
>>
>> Thanks
>>
>> Regards,
>> Uri
>>
>>> On Jan 20, 2021, at 19:26, Kaduk, Ben <bkaduk at akamai.com> wrote:
>>>
>>> ?No.  OpenSSL does not include any CBOR protocol support.
>>> I'm also not sure what you mean by "CBOR-encoded certificate"; I don't
>>> know of any such thing other than
>>> https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/
>>> which is very much still a work in progress.
>>>
>>> -Ben
>>>
>>> ________________________________________
>>> From: Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu>
>>> Sent: Wednesday, January 20, 2021 4:22 PM
>>> To: openssl-users
>>> Subject: Parsing and generating CBOR certificates?
>>>
>>> I need to work with CBOR-encoded certificates. Is there any way to use OpenSSL to parse and/or generate certs in CBOR encoding?
>>>
>>> Thanks
>>>
>>> Regards,
>>> Uri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210121/31ff080d/attachment.html>

From Michael.Wojcik at microfocus.com  Thu Jan 21 14:27:54 2021
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 21 Jan 2021 14:27:54 +0000
Subject: OpenSSL 1.1.1g Windows build slow rsa tests
In-Reply-To: <ade515d4-08be-2c44-d663-2bfe278ae671@openssl.org>
References: <SN7PR06MB7214F223DE61E2620D85B4BBD9A29@SN7PR06MB7214.namprd06.prod.outlook.com>
 <b2aef85d-5543-a078-160d-2b140a217b7d@openssl.org>
 <DM6PR18MB2700594D1ADA09944850AEC4F9A11@DM6PR18MB2700.namprd18.prod.outlook.com>
 <ade515d4-08be-2c44-d663-2bfe278ae671@openssl.org>
Message-ID: <MN2PR18MB270322D69AFBC552E0B0E35FF9A19@MN2PR18MB2703.namprd18.prod.outlook.com>

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Dr Paul
> Dale
> Sent: Wednesday, 20 January, 2021 19:28
>
> I'd suggest giving a build without the no-asm option a try.  The
> performance difference is usually quite significant.

I agree. It just doesn't explain what Dan's email claims.

> Statis vs dynamic builds wouldn't normally be associated with such a
> large difference.  If the difference were routinely this large, nobody
> would use dynamic linking.

In this case it's the static-linked version which is slower. But I'd be surprised if that's actually the cause.

--
Michael Wojcik

From housley at vigilsec.com  Thu Jan 21 16:35:14 2021
From: housley at vigilsec.com (Russ Housley)
Date: Thu, 21 Jan 2021 11:35:14 -0500
Subject: Parsing and generating CBOR certificates?
In-Reply-To: <50D045AE-043C-44AB-84B5-C37ADE90E5A3@ll.mit.edu>
References: <1611188745094.51849@akamai.com>
 <6AE2764D-42F0-496A-860C-0FC4237C843D@ll.mit.edu>
 <20210121003712.GO3538@akamai.com>
 <50D045AE-043C-44AB-84B5-C37ADE90E5A3@ll.mit.edu>
Message-ID: <1FD969AD-D0D1-411D-84EE-1ED0E5165E6B@vigilsec.com>

Uri:
> 
> Unfortunately, there's no ASN.1 -> CBOR codec generator, AFAIK, which is why I'm asking here.

Nope, and if there were, it would not generate the same result as the compressions routines that Ben referenced.

Russ


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210121/e4504542/attachment.html>

From dheinz at softwarekey.com  Thu Jan 21 18:22:51 2021
From: dheinz at softwarekey.com (Dan Heinz)
Date: Thu, 21 Jan 2021 18:22:51 +0000
Subject: OpenSSL 1.1.1g Windows build slow rsa tests
In-Reply-To: <MN2PR18MB270322D69AFBC552E0B0E35FF9A19@MN2PR18MB2703.namprd18.prod.outlook.com>
References: <SN7PR06MB7214F223DE61E2620D85B4BBD9A29@SN7PR06MB7214.namprd06.prod.outlook.com>
 <b2aef85d-5543-a078-160d-2b140a217b7d@openssl.org>
 <DM6PR18MB2700594D1ADA09944850AEC4F9A11@DM6PR18MB2700.namprd18.prod.outlook.com>
 <ade515d4-08be-2c44-d663-2bfe278ae671@openssl.org>
 <MN2PR18MB270322D69AFBC552E0B0E35FF9A19@MN2PR18MB2703.namprd18.prod.outlook.com>
Message-ID: <SN7PR06MB721482FD9A98583554EFC7FCD9A19@SN7PR06MB7214.namprd06.prod.outlook.com>

-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Michael Wojcik
Sent: Thursday, January 21, 2021 9:28 AM
To: openssl-users at openssl.org
Subject: RE: OpenSSL 1.1.1g Windows build slow rsa tests

> >From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of 
> >Dr Paul Dale
> >Sent: Wednesday, 20 January, 2021 19:28
>>
>> I'd suggest giving a build without the no-asm option a try.  The 
>> performance difference is usually quite significant.

>I agree. It just doesn't explain what Dan's email claims.

>> Statis vs dynamic builds wouldn't normally be associated with such a 
>> large difference.  If the difference were routinely this large, nobody 
>> would use dynamic linking.

>In this case it's the static-linked version which is slower. But I'd be surprised if that's actually the cause.

Thank you all for the helpful suggestions.  When I removed no-asm and built using nmake in the Developer Command  Prompt for Visual Studio 2015, I ended up getting an error "VC-WIN64A X86 conflicts with target x64".  From the command prompt I ran cl and saw this "Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86".  So I was building for x86?  I'm not sure why it built with no-asm, but it did.

Once I ran the correct command prompt (I used Visual Studio x64 Native Tools Command Prompt), I saw a huge speed increase.  For example, 2048 bits:
Doing 2048 bits private rsa's for 10s: 8384 2048 bits private RSA's in 10.02s
Doing 2048 bits public rsa's for 10s: 236090 2048 bits public RSA's in 9.98s

Previously, I saw:
Doing 2048 bits private rsa's for 10s: 409 2048 bits private RSA's in 10.00s
Doing 2048 bits public rsa's for 10s: 15663 2048 bits public RSA's in 10.02s

For further testing, I added back no-asm and my speed tests were in line with the downloaded openssl binary I was testing with.  
Doing 2048 bits private rsa's for 10s: 1868 2048 bits private RSA's in 10.00s
Doing 2048 bits public rsa's for 10s: 71338 2048 bits public RSA's in 10.02s

You can see removing no-asm does make a pretty large speed increase too.

In summary, using the correct build tools helps (although I am surprised it built with no-asm).  And removing no-asm sped things up.

From uri at ll.mit.edu  Thu Jan 21 21:31:21 2021
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 21 Jan 2021 21:31:21 +0000
Subject: Parsing and generating CBOR certificates?
In-Reply-To: <6b95b753-fb30-a985-61c0-21ac95074e2d@ddvo.net>
References: <1611188745094.51849@akamai.com>
 <6AE2764D-42F0-496A-860C-0FC4237C843D@ll.mit.edu>
 <20210121003712.GO3538@akamai.com>
 <50D045AE-043C-44AB-84B5-C37ADE90E5A3@ll.mit.edu>
 <6b95b753-fb30-a985-61c0-21ac95074e2d@ddvo.net>
Message-ID: <0A3011B6-DE1F-4C15-BE36-F818EFD9C7EF@ll.mit.edu>

> I'd welcome support for CBOR(-encoded) certificates since they can save a lot of space
> for both the data itself and the code handling it, which may be vital for IoT scenarios, for instance.
> It looks like the standardization of their definition got pretty far already.

Exactly! And there?s been a bunch of publications, describing/defining CBOR encoding for IoT certificates, such as 
http://kth.diva-portal.org/smash/get/diva2:1153958/FULLTEXT01.pdf 
 
> Although it is certainly possible to convert between DER-encoded ASN.1 (or at least its subset needed for X.509 certs) and CBOR,
> this is not strictly needed since there is a definition of natively signed CBOR certs.
> Thus all the ASN.1 fuzz, which is bulky and error-prone to implement and use, can be avoided then.

Yes. My primary goal is to reduce the overhead on the wire ? but simplifying the processing code would be welcome as well.

> It may be also worth noting in this context that due to it sheer size the OpenSSL code itself is not suited for constrained systems.
> Yet even then it would make sense if OpenSSL supported CBOR certs because they could be used by TLS peers on constrained systems.

Yes.

> Moreover, when using only natively signed CBOR certs it should be possible 
> (though likely hard to achieve with the current strongly ASN.1 entangled libcrypto code)
> to build OpenSSL without any ASN.1 support, which should reduce code size drastically.

Something I don't urgently need, but would welcome regardless.

> I suggest opening a feature request at https://github.com/openssl/openssl/issues

Done: https://github.com/openssl/openssl/issues/13925 

Thanks!


On 21.01.21 02:07, Blumenthal, Uri - 0553 - MITLL wrote:
On 1/20/21, 19:42, "Benjamin Kaduk" mailto:bkaduk at akamai.com wrote:
   And again, where do you believe such a conversion is specified?
What do you mean "specified"? There's an ASN.1 "specification" of the certificate format, which theoretically can be encoded into whatever - DER, PER, OER, etc. One such tool (https://github.com/mouse07410/asn1c.git that I use) generates from ASN.1 file codecs for many encoding formats, and is able to convert between them.

Unfortunately, there's no ASN.1 -> CBOR codec generator, AFAIK, which is why I'm asking here.

  The IETF internet-draft I reference is a way to do so, but it is (to repeat)
  very much a work in progress.
Understood. Do you know if there's any code behind it? Or just the "theory"?

Thanks!

On Thu, Jan 21, 2021 at 12:35:24AM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
I meant not "CBOR protocol" (which,  in all likelihood, doesn't and shouldn't exist) but CBOR encoding of X.509 certificates (which, hopefully, does exists).

At least, I'm looking for a tool that would convert between these two encodings (DER and CBOR) for specific objects (X.509-conformant certificates).

Thanks

Regards,
Uri

On Jan 20, 2021, at 19:26, Kaduk, Ben mailto:bkaduk at akamai.com wrote:

No.  OpenSSL does not include any CBOR protocol support.
I'm also not sure what you mean by "CBOR-encoded certificate"; I don't
know of any such thing other than
https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/
which is very much still a work in progress.

-Ben

________________________________________
From: Blumenthal, Uri - 0553 - MITLL mailto:uri at ll.mit.edu
Sent: Wednesday, January 20, 2021 4:22 PM
To: openssl-users
Subject: Parsing and generating CBOR certificates?

I need to work with CBOR-encoded certificates. Is there any way to use OpenSSL to parse and/or generate certs in CBOR encoding?

Thanks

Regards,
Uri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210121/ac2abe8c/attachment.bin>

From janjust at nikhef.nl  Fri Jan 22 11:09:24 2021
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Fri, 22 Jan 2021 12:09:24 +0100
Subject: OpenSSL 1.1.1g Windows build slow rsa tests
In-Reply-To: <SN7PR06MB721482FD9A98583554EFC7FCD9A19@SN7PR06MB7214.namprd06.prod.outlook.com>
References: <SN7PR06MB7214F223DE61E2620D85B4BBD9A29@SN7PR06MB7214.namprd06.prod.outlook.com>
 <b2aef85d-5543-a078-160d-2b140a217b7d@openssl.org>
 <DM6PR18MB2700594D1ADA09944850AEC4F9A11@DM6PR18MB2700.namprd18.prod.outlook.com>
 <ade515d4-08be-2c44-d663-2bfe278ae671@openssl.org>
 <MN2PR18MB270322D69AFBC552E0B0E35FF9A19@MN2PR18MB2703.namprd18.prod.outlook.com>
 <SN7PR06MB721482FD9A98583554EFC7FCD9A19@SN7PR06MB7214.namprd06.prod.outlook.com>
Message-ID: <135cda8f-a663-bd02-e67c-e0acf1373150@nikhef.nl>

Hi Dan,

On 21/01/21 19:22, Dan Heinz wrote:
> [...]

> Thank you all for the helpful suggestions. When I removed no-asm and 
> built using nmake in the Developer Command Prompt for Visual Studio 
> 2015, I ended up getting an error "VC-WIN64A X86 conflicts with target 
> x64". From the command prompt I ran cl and saw this "Microsoft (R) 
> C/C++ Optimizing Compiler Version 19.00.24215.1 for x86". So I was 
> building for x86? I'm not sure why it built with no-asm, but it did.
> Once I ran the correct command prompt (I used Visual Studio x64 Native Tools Command Prompt), I saw a huge speed increase.  For example, 2048 bits:
> Doing 2048 bits private rsa's for 10s: 8384 2048 bits private RSA's in 10.02s
> Doing 2048 bits public rsa's for 10s: 236090 2048 bits public RSA's in 9.98s
>
> Previously, I saw:
> Doing 2048 bits private rsa's for 10s: 409 2048 bits private RSA's in 10.00s
> Doing 2048 bits public rsa's for 10s: 15663 2048 bits public RSA's in 10.02s
>
> For further testing, I added back no-asm and my speed tests were in line with the downloaded openssl binary I was testing with.
> Doing 2048 bits private rsa's for 10s: 1868 2048 bits private RSA's in 10.00s
> Doing 2048 bits public rsa's for 10s: 71338 2048 bits public RSA's in 10.02s
>
> You can see removing no-asm does make a pretty large speed increase too.
>
> In summary, using the correct build tools helps (although I am surprised it built with no-asm).  And removing no-asm sped things up.

Not sure why you'd want to do a 'no-asm' build to begin with, but 
another thing worth testing with your "asm" build is to run the speed 
test like this:
 ?set OPENSSL_ia32cap=0
 ?openssl speed rsa
(Linux/UNIX:? OPENSSL_ia32cap=0 openssl speed rsa)

On my (10th gen Intel ) laptop this gives me a ~35% performance hit. 
Explanation:
- no-asm build -> compiler generates all code, no hand-tuned assembly 
used at all; should be slowest

- asm build + OPENSSL_ia32cap=0? -> no newer CPU features used, but 
hand-tuned assembly is used. Especially AES encryption takes a hit if 
you disable these newer features

- asm build -> hand-tuned assemby, including the use of all new CPU 
features such as AES, SHA etc.

I've found that this sometimes helps manage expectations when the "build 
environment" CPU and the "runtime environment" CPU are very different. 
I've seen a developer claim his/her code runs blazingly fast on his/her 
Core i7 bla bla but when deploying it on a cheaper runtime device 
performance is terrible.

Note that no-asm + OPENSSL_ia32cap=0 should not have any effect compared 
to "no-asm".

JM2CW,

JJK / Jan Just Keijser


From hkario at redhat.com  Fri Jan 22 19:38:42 2021
From: hkario at redhat.com (Hubert Kario)
Date: Fri, 22 Jan 2021 20:38:42 +0100
Subject: Parsing and generating CBOR =?iso-8859-1?Q?certificates=3F?=
In-Reply-To: <6b95b753-fb30-a985-61c0-21ac95074e2d@ddvo.net>
References: <1611188745094.51849@akamai.com>
 <6AE2764D-42F0-496A-860C-0FC4237C843D@ll.mit.edu>
 <20210121003712.GO3538@akamai.com>
 <50D045AE-043C-44AB-84B5-C37ADE90E5A3@ll.mit.edu>
 <6b95b753-fb30-a985-61c0-21ac95074e2d@ddvo.net>
Message-ID: <9bdf9bc0-98b3-4df3-8772-b84ff8213c99@redhat.com>

On Thursday, 21 January 2021 13:05:21 CET, David von Oheimb wrote:
> I'd welcome support for CBOR(-encoded) certificates since they can save
> a lot of space
> for both the data itself and the code handling it, which may be vital
> for IoT scenarios, for instance.
> It looks like the standardization of their definition got pretty far
> already.
>
> Although it is certainly possible to convert between DER-encoded ASN.1
> (or at least its subset needed for X.509 certs) and CBOR,
> this is not strictly needed since there is a definition of natively
> signed CBOR certs.
> Thus all the ASN.1 fuzz, which is bulky and error-prone to implement and
> use, can be avoided then.
>
> https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress writes:
>
>    The use of natively signed CBOR certificates removes the need for
>    ASN.1 encoding, which is a rich source of security vulnerabilities.

that's a huge and rather crucial difference

as X.509 certificate signatures are specified over byte strings that are 
the DER
encoding of the tbsCertificate structure

you can send that certificate however you want, including by translating it 
into
XML variant of ASN.1

but for verification you still need to turn that XML into DER so that you
can verify that the signature that the CA created is correct

if the signature is expected to be made over CBOR serialising of 
tbsCertificate,
then that's a completely different certificate and it's the CA that needs
to produce it, it's not something that openssl could do (convert from DER 
to
CBOR)

-- 
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 johnthoe at outlook.com  Sat Jan 23 15:22:34 2021
From: johnthoe at outlook.com (John Thoe)
Date: Sat, 23 Jan 2021 15:22:34 +0000
Subject: Default value of a session resumption timeout (300 seconds vs 7200
 seconds)
Message-ID: <CY4PR0801MB3650AEA1D1A8F2026A64DC93C9BF9@CY4PR0801MB3650.namprd08.prod.outlook.com>

Hi list,

The session reuse question posted on the mailing list earlier (https://mta.openssl.org/pipermail/openssl-users/2021-January/013360.html) reminded of a somewhat similar question I have.

As per the docs, https://www.openssl.org/docs/man1.0.2/man3/SSL_get_default_timeout.html, it says the default value is 300 seconds for which a session resuse will be accepted. The docs say that it is the same for all protocols.

However I tried it with my setup where I didn't explicitly set the timeout and I am getting 7200 seconds as the default value. s_client output: TLS session ticket lifetime hint: 7200 (seconds). My client openssl.conf has no setting override (not that it should matter because this is a server preference). No OpenSSL settings on the server have been modified as well. 

In ssl/ssl_sess.c#L80, the code matches the document: ss->timeout = 60 * 5 + 4;   /* 5 minute timeout by default */ ... (with additional four seconds?)

I have noticed similar outputs (7200 seconds) from searching about this question so seems like I am not the only one. What is the reason for this discrepancy and is the value 300 seconds or 7200 seconds?

- JT

From david025 at springtimesoftware.com  Mon Jan 25 02:11:11 2021
From: david025 at springtimesoftware.com (David Spector)
Date: Sun, 24 Jan 2021 21:11:11 -0500
Subject: Hoping to get a working example of SFTP in PHP
Message-ID: <e33a538d-e721-a817-4d22-f64e80963daa@springtimesoftware.com>

This question may be considered off-topic, since is not directly about 
using the OpenSSL library. Let me know if you want me to delete this 
posting.

I have a question about uploading a file (text.txt) securely in PHP 
using the SFTP protocol and a public/private key pair. I have posted 
this question is several fora, but no one seems to know for sure how to 
do it. Although I've received much advice, none of the actual published 
examples are known to work, and do not work for me. I know my parameters 
are okay, since they work in CoreFTP and PuTTY, two manual applications 
that implement SFTP with private keys. Also, a short FTP insecure 
example works perfectly for me. There seem to be many subtle 
undocumented issues with getting any of the published example code to 
work. I'm inexperienced with SFTP in PHP and am hoping to locate a 
working example.

So far I have tried a number of examples using the ssh2 PHP extension 
and the cURL PHP extension. They fail, and the error messages, if any, 
are uninformative.

A little background:

I do website development work for two small companies on a Windows 
computer (Apache/PHP 7), uploading to a remote production server 
(VPS/cPanel/Centos). My local software versions are: Windows 10 
Hone/2004, Bitnami WAMP/7.4.13-0, Apache/2.4.46 (Win64), OpenSSL/1.1.1h, 
PHP/7.4.13, libssh2/1.9.0.

Where I am now is that I used cPanel on the remote server to install an 
SSH/SFTP public key for a particular account. I then copied the 
generated encrypted x.key and x.ppk private key files to my local 
computer. Now I am ready to upload files securely, if only PHP made the 
task easy. Unfortunately, it does not.

I know that phpseclib is available, but it is a very large PHP source 
code library, so I'd rather use the php_ssh2.dll or cURL PHP extension, 
the OpenSSL PHP extension (if it can do SFTP), or something similar.

In summary, I'm looking for someone who has got SFTP file upload with 
private key working in PHP to share their code with me. I pledge to test 
the code and post it further to help others with this difficult but 
widely useful problem.

From doctor at doctor.nl2k.ab.ca  Mon Jan 25 14:56:28 2021
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Mon, 25 Jan 2021 07:56:28 -0700
Subject: OPenssl 3.0 issues
Message-ID: <YA7cHAB5NNMYMkyD@doctor.nl2k.ab.ca>

Anyone using BSD running into basename issues?

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b  
Born 29 Jan 1969 Redhill, Surrey, UK 

From uri at ll.mit.edu  Mon Jan 25 15:14:57 2021
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Mon, 25 Jan 2021 15:14:57 +0000
Subject: OPenssl 3.0 issues
In-Reply-To: <YA7cHAB5NNMYMkyD@doctor.nl2k.ab.ca>
References: <YA7cHAB5NNMYMkyD@doctor.nl2k.ab.ca>
Message-ID: <AA21972A-297F-4B1F-9CCC-8A184AEDDCBD@ll.mit.edu>

On 1/25/21, 10:13, "openssl-users on behalf of The Doctor" <openssl-users-bounces at openssl.org on behalf of doctor at doctor.nl2k.ab.ca> wrote:

    Anyone using BSD running into basename issues?

Basename issues on MacOS. Presumably the same as you're having on BSD.
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210125/f70127a3/attachment-0001.bin>

From Zeke.Evans at microfocus.com  Mon Jan 25 16:53:24 2021
From: Zeke.Evans at microfocus.com (Zeke Evans)
Date: Mon, 25 Jan 2021 16:53:24 +0000
Subject: PKCS12 APIs with fips 3.0
Message-ID: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>

Hi,

Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse, PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips provider.  It looks like that is because they try to load PKCS12KDF which is not implemented in the fips provider.  These were all working in 1.0.2 with the fips 2.0 module.  Will they be supported in 3.0 with fips?  If not, is there a way for applications running in fips approved mode to support the same functionality and use existing stores/files that contain PKCS12 objects?

Thanks,
Zeke Evans
Micro Focus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210125/8945eaab/attachment.html>

From matt at openssl.org  Mon Jan 25 17:38:04 2021
From: matt at openssl.org (Matt Caswell)
Date: Mon, 25 Jan 2021 17:38:04 +0000
Subject: Default value of a session resumption timeout (300 seconds vs
 7200 seconds)
In-Reply-To: <CY4PR0801MB3650AEA1D1A8F2026A64DC93C9BF9@CY4PR0801MB3650.namprd08.prod.outlook.com>
References: <CY4PR0801MB3650AEA1D1A8F2026A64DC93C9BF9@CY4PR0801MB3650.namprd08.prod.outlook.com>
Message-ID: <8c5d46e5-4ead-ed3b-1671-3929db78df9d@openssl.org>



On 23/01/2021 15:22, John Thoe wrote:
> Hi list,
> 
> The session reuse question posted on the mailing list earlier
> (https://mta.openssl.org/pipermail/openssl-users/2021-January/013360.html)
> reminded of a somewhat similar question I have.
> 
> As per the docs,
> https://www.openssl.org/docs/man1.0.2/man3/SSL_get_default_timeout.html,
> it says the default value is 300 seconds for which a session resuse
> will be accepted. The docs say that it is the same for all
> protocols.
> 
> However I tried it with my setup where I didn't explicitly set the
> timeout and I am getting 7200 seconds as the default value. s_client
> output: TLS session ticket lifetime hint: 7200 (seconds). My client
> openssl.conf has no setting override (not that it should matter
> because this is a server preference). No OpenSSL settings on the
> server have been modified as well.

Looks to me like the docs are wrong. They probably should say 7200.


> 
> In ssl/ssl_sess.c#L80, the code matches the document: ss->timeout =
> 60 * 5 + 4;   /* 5 minute timeout by default */ ... (with additional
> four seconds?)


This gets set during construction and then later overwritten when we
actually get a new session via "ssl_get_new_session":

    /* If the context has a default timeout, use it */
    if (s->session_ctx->session_timeout == 0)
        ss->timeout = SSL_get_default_timeout(s);
    else
        ss->timeout = s->session_ctx->session_timeout;

In most cases SSL_get_default_timeout() calls tls1_default_timeout() (it
can end up somewhere different for certain protocol versions - but all
the different variants are the same!):

long tls1_default_timeout(void)
{
    /*
     * 2 hours, the 24 hours mentioned in the TLSv1 spec is way too long for
     * http, the cache would over fill
     */
    return (60 * 60 * 2);
}

60 * 60 * 2 = 7200


Matt


From jhb at FreeBSD.org  Mon Jan 25 22:20:46 2021
From: jhb at FreeBSD.org (John Baldwin)
Date: Mon, 25 Jan 2021 14:20:46 -0800
Subject: OPenssl 3.0 issues
In-Reply-To: <YA7cHAB5NNMYMkyD@doctor.nl2k.ab.ca>
References: <YA7cHAB5NNMYMkyD@doctor.nl2k.ab.ca>
Message-ID: <f3a35b03-e43b-7c09-f47c-5b76a390d36b@FreeBSD.org>

On 1/25/21 6:56 AM, The Doctor wrote:
> Anyone using BSD running into basename issues?
  
I have not, but my use of 3.0 has been limited to KTLS testing
with nginx.  Are you referring to whether or not the string
returned by basename(3) is part of the input string or whether
it is a copy stored in an internal buffer in libc?

-- 
John Baldwin

From whippet0 at gmail.com  Tue Jan 26 04:28:11 2021
From: whippet0 at gmail.com (George)
Date: Mon, 25 Jan 2021 23:28:11 -0500
Subject: UI_METHOD functions not being invoked for smart card
Message-ID: <ac90a321-3d80-79b4-47c3-d5a2474bc807@gmail.com>

Hi,

 ??? I'm trying to get OpenSSL 1.0.2u with the FIPS Object Module 
2.0.16? in Windows 10 to prompt the user for a smart card's PIN number 
every time the application is launched. However, I cannot seem to get it 
to work. My UI_METHOD callback functions are not being invoked.

I'm using the following code as a reference:
https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c

I tried the following:

    UI_METHOD* transfer_pin = UI_create_method("transfer_pin");

    int writer (UI *ui, UI_STRING *uis)
    {
     ??? PW_CB_DATA* cb_data = (PW_CB_DATA*)UI_get0_user_data(ui);
     ??? UI_set_result(ui, uis, cb_data->password);
     ??? return 1;
    };
    int stub (UI* ui) {return 1;};
    int stub_reader (UI *ui, UI_STRING *uis) {return 1;};

    UI_method_set_writer(transfer_pin,? writer);
    UI_method_set_opener(transfer_pin,? stub);
    UI_method_set_closer(transfer_pin,? stub);
    UI_method_set_flusher(transfer_pin, stub);
    UI_method_set_reader(transfer_pin,? stub_reader);

    pkey = ENGINE_load_private_key(pkey_engine, pkey_identifier,
    transfer_pin, &cb_data);



However, none of the callback functions "writer", "stub", or 
"stub_reader" actually get called. Do I need to do anything else to 
enable this functionality?? I would like to force the user to enter PIN 
number every time.



Thanks,
George

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210125/81c17501/attachment.html>

From pravesh.rai at gmail.com  Tue Jan 26 08:03:33 2021
From: pravesh.rai at gmail.com (Pravesh Rai)
Date: Tue, 26 Jan 2021 13:33:33 +0530
Subject: Javax.Crypto.AEADBadTagException: Tag Mismatch
Message-ID: <CAJp-7Tg9Gz5XmUJE0DtsBQr+ScbG0gjSLBYLXLmkLFAt6ayNTA@mail.gmail.com>

Hi,

We've Java on the client side & OpenSSL on the server side. After updating
Java to 1.8u261 & started getting following exception:

Javax.Crypto.AEADBadTagException: Tag Mismatch

when trying to communicate with a server having OpenSSL 1.0.2.

Looks like the issue is due to AES-GCM ciphers. So, just wanted to know if
we need to make some changes in OpenSSL configuration to avoid the given
exception.

Regards,
PR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210126/277eac6a/attachment-0001.html>

From levitte at openssl.org  Tue Jan 26 08:08:53 2021
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 26 Jan 2021 09:08:53 +0100
Subject: OPenssl 3.0 issues
In-Reply-To: <YA7cHAB5NNMYMkyD@doctor.nl2k.ab.ca>
References: <YA7cHAB5NNMYMkyD@doctor.nl2k.ab.ca>
Message-ID: <87im7kglwq.wl-levitte@openssl.org>

That should be fixed, I merged a fixup commit yesterday.

Cheers,
Richard

On Mon, 25 Jan 2021 15:56:28 +0100,
The Doctor wrote:
> 
> Anyone using BSD running into basename issues?
> 
> -- 
> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
> Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b  
> Born 29 Jan 1969 Redhill, Surrey, UK 
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From janjust at nikhef.nl  Tue Jan 26 09:29:58 2021
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Tue, 26 Jan 2021 10:29:58 +0100
Subject: UI_METHOD functions not being invoked for smart card
In-Reply-To: <ac90a321-3d80-79b4-47c3-d5a2474bc807@gmail.com>
References: <ac90a321-3d80-79b4-47c3-d5a2474bc807@gmail.com>
Message-ID: <1ed07614-f302-f935-3842-3ff3ea50e5e7@nikhef.nl>

On 26/01/21 05:28, George wrote:
> Hi,
>
> ??? I'm trying to get OpenSSL 1.0.2u with the FIPS Object Module 
> 2.0.16? in Windows 10 to prompt the user for a smart card's PIN number 
> every time the application is launched. However, I cannot seem to get 
> it to work. My UI_METHOD callback functions are not being invoked.
>
> I'm using the following code as a reference:
> https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c
>
> I tried the following:
>
>     UI_METHOD* transfer_pin = UI_create_method("transfer_pin");
>
>     int writer (UI *ui, UI_STRING *uis)
>     {
>     ??? PW_CB_DATA* cb_data = (PW_CB_DATA*)UI_get0_user_data(ui);
>     ??? UI_set_result(ui, uis, cb_data->password);
>     ??? return 1;
>     };
>     int stub (UI* ui) {return 1;};
>     int stub_reader (UI *ui, UI_STRING *uis) {return 1;};
>
>     UI_method_set_writer(transfer_pin,? writer);
>     UI_method_set_opener(transfer_pin,? stub);
>     UI_method_set_closer(transfer_pin,? stub);
>     UI_method_set_flusher(transfer_pin, stub);
>     UI_method_set_reader(transfer_pin,? stub_reader);
>
>     pkey = ENGINE_load_private_key(pkey_engine, pkey_identifier,
>     transfer_pin, &cb_data);
>
>
>
> However, none of the callback functions "writer", "stub", or 
> "stub_reader" actually get called. Do I need to do anything else to 
> enable this functionality?? I would like to force the user to enter 
> PIN number every time.
>

this depends on how openssl for windows was built ; some non-UNIX builds 
set the flag OPENSSL_NO_UI_CONSOLE? (or possibly OPENSSL_NO_UI) in which 
case all UI_methods are effectively disabled. If this flag is set for 
your build then you will have to rebuild OpenSSL.

Apart from that, that code snippet above is not the cleanest code I have 
ever written? - some C/C++ compilers do not like functions defined 
insides an? "if { } " block; you might have to take the function "int 
writer { } " outside of the "if { } " block.

HTH,

JJK


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210126/5c50e19c/attachment.html>

From jb-openssl at wisemo.com  Tue Jan 26 11:05:48 2021
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 26 Jan 2021 12:05:48 +0100
Subject: PKCS12 APIs with fips 3.0
In-Reply-To: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>
References: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>
Message-ID: <c7f86553-85df-f2ef-5413-5a73a1384181@wisemo.com>

On 2021-01-25 17:53, Zeke Evans wrote:
>
> Hi,
>
> Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse, 
> PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips 
> provider.? It looks like that is because they try to load PKCS12KDF 
> which is not implemented in the fips provider.? These were all working 
> in 1.0.2 with the fips 2.0 module.? Will they be supported in 3.0 with 
> fips?? If not, is there a way for applications running in fips 
> approved mode to support the same functionality and use existing 
> stores/files that contain PKCS12 objects?
>
This is an even larger issue: Is OpenSSL 3.x so badly designed
that the "providers" need to separately implement every standard
or non-standard combination of algorithm invocations?

In a properly abstracted design PKCS12KDF would be implemented by
invoking general EVP functions for underlying algorithms, which
would in turn invoke the provider versions of those algorithms.

The only exception would be if FIPS allowed implementing PKCS12KDF
using an otherwise unapproved algorithm such as SHA1.? In that
particular case, it would make sense to check if a provider offered
such as PKCS12KDF variant before trying (and failing) to run
provider-independent code that invokes the provider implementation
of a FIPS-unapproved algorithm.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210126/99a45ba9/attachment.html>

From matt at openssl.org  Tue Jan 26 11:45:59 2021
From: matt at openssl.org (Matt Caswell)
Date: Tue, 26 Jan 2021 11:45:59 +0000
Subject: PKCS12 APIs with fips 3.0
In-Reply-To: <c7f86553-85df-f2ef-5413-5a73a1384181@wisemo.com>
References: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <c7f86553-85df-f2ef-5413-5a73a1384181@wisemo.com>
Message-ID: <5ef31738-9181-1581-ecf3-e925ee5ad955@openssl.org>



On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:
> On 2021-01-25 17:53, Zeke Evans wrote:
>>
>> Hi,
>>
>> ?
>>
>> Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse,
>> PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips
>> provider.? It looks like that is because they try to load PKCS12KDF
>> which is not implemented in the fips provider.? These were all working
>> in 1.0.2 with the fips 2.0 module.? Will they be supported in 3.0 with
>> fips?? If not, is there a way for applications running in fips
>> approved mode to support the same functionality and use existing
>> stores/files that contain PKCS12 objects?
>>
>> ?
>>
> This is an even larger issue: Is OpenSSL 3.x so badly designed
> that the "providers" need to separately implement every standard
> or non-standard combination of algorithm invocations?
> 
> In a properly abstracted design PKCS12KDF would be implemented by
> invoking general EVP functions for underlying algorithms, which
> would in turn invoke the provider versions of those algorithms.

This is exactly the way it works. The implementation of PKCS12KDF
fetches the underlying digest algorithm using whatever providers it has
available. So, for example, if the PKCS12KDF implementation needs to use
SHA256, then it will fetch an available implementation for it - and that
implementation may come from the FIPS provider (or any other provider).

However, in 3.0, KDFs are themselves fetchable cryptographic algorithms
implemented by providers. The FIPS module implements a set of KDFs - but
PKCS12KDF is not one of them. Its only available from the default provider.

So, the summary is, while you can set things up so that all your crypto,
including any digests used by the PKCS12KDF, all come from the FIPS
provider, there is no getting away from the fact that you still need to
have the default provider loaded in order to have an implementation of
the PKCS12KDF itself - which will obviously be outside the module boundary.

There aren't any current plans to bring the implementation of PKCS12KDF
inside the FIPS module. I don't know whether that is feasible or not.

Matt

From tm at t8m.info  Tue Jan 26 12:48:21 2021
From: tm at t8m.info (Tomas Mraz)
Date: Tue, 26 Jan 2021 13:48:21 +0100
Subject: PKCS12 APIs with fips 3.0
In-Reply-To: <5ef31738-9181-1581-ecf3-e925ee5ad955@openssl.org>
References: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <c7f86553-85df-f2ef-5413-5a73a1384181@wisemo.com>
 <5ef31738-9181-1581-ecf3-e925ee5ad955@openssl.org>
Message-ID: <261306f686144c7ae5ad3b1cac78e9b0e34c0b93.camel@t8m.info>

On Tue, 2021-01-26 at 11:45 +0000, Matt Caswell wrote:
> 
> On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:
> > On 2021-01-25 17:53, Zeke Evans wrote:
> > > Hi,
> > > 
> > >  
> > > 
> > > Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse,
> > > PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips
> > > provider.  It looks like that is because they try to load
> > > PKCS12KDF
> > > which is not implemented in the fips provider.  These were all
> > > working
> > > in 1.0.2 with the fips 2.0 module.  Will they be supported in 3.0
> > > with
> > > fips?  If not, is there a way for applications running in fips
> > > approved mode to support the same functionality and use existing
> > > stores/files that contain PKCS12 objects?
> > > 
> > >  
> > > 
> > This is an even larger issue: Is OpenSSL 3.x so badly designed
> > that the "providers" need to separately implement every standard
> > or non-standard combination of algorithm invocations?
> > 
> > In a properly abstracted design PKCS12KDF would be implemented by
> > invoking general EVP functions for underlying algorithms, which
> > would in turn invoke the provider versions of those algorithms.
> 
> This is exactly the way it works. The implementation of PKCS12KDF
> fetches the underlying digest algorithm using whatever providers it
> has
> available. So, for example, if the PKCS12KDF implementation needs to
> use
> SHA256, then it will fetch an available implementation for it - and
> that
> implementation may come from the FIPS provider (or any other
> provider).
> 
> However, in 3.0, KDFs are themselves fetchable cryptographic
> algorithms
> implemented by providers. The FIPS module implements a set of KDFs -
> but
> PKCS12KDF is not one of them. Its only available from the default
> provider.
> 
> So, the summary is, while you can set things up so that all your
> crypto,
> including any digests used by the PKCS12KDF, all come from the FIPS
> provider, there is no getting away from the fact that you still need
> to
> have the default provider loaded in order to have an implementation
> of
> the PKCS12KDF itself - which will obviously be outside the module
> boundary.
> 
> There aren't any current plans to bring the implementation of
> PKCS12KDF
> inside the FIPS module. I don't know whether that is feasible or not.

IMO PKCS12KDF should not be in the FIPS module as this is not a FIPS
approved KDF algorithm. Besides that KDF should not IMO be needed for
"modern" PKCS12 files. I need to test that though.

-- 
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 harishvk27 at gmail.com  Tue Jan 26 18:13:01 2021
From: harishvk27 at gmail.com (Harish Kulkarni)
Date: Tue, 26 Jan 2021 23:43:01 +0530
Subject: Default value of a session resumption timeout (300 seconds vs
 7200 seconds)
In-Reply-To: <8c5d46e5-4ead-ed3b-1671-3929db78df9d@openssl.org>
References: <CY4PR0801MB3650AEA1D1A8F2026A64DC93C9BF9@CY4PR0801MB3650.namprd08.prod.outlook.com>
 <8c5d46e5-4ead-ed3b-1671-3929db78df9d@openssl.org>
Message-ID: <CAHV7XR4YgaRkA-v9sK_M1AuZtiXiUrrFeCU3dYCq8=kB_oN+Bg@mail.gmail.com>

Thank you both for bringing this to my attention, your points are
invaluable.

If this is something which gets set from server on client side. can client
override this?. Can i change this to something less and try?. Has anyone
tried?.

Whats the option in openssl.conf or some other place?.

-thanks
harish


On Mon, Jan 25, 2021 at 11:08 PM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 23/01/2021 15:22, John Thoe wrote:
> > Hi list,
> >
> > The session reuse question posted on the mailing list earlier
> > (
> https://mta.openssl.org/pipermail/openssl-users/2021-January/013360.html)
> > reminded of a somewhat similar question I have.
> >
> > As per the docs,
> > https://www.openssl.org/docs/man1.0.2/man3/SSL_get_default_timeout.html,
> > it says the default value is 300 seconds for which a session resuse
> > will be accepted. The docs say that it is the same for all
> > protocols.
> >
> > However I tried it with my setup where I didn't explicitly set the
> > timeout and I am getting 7200 seconds as the default value. s_client
> > output: TLS session ticket lifetime hint: 7200 (seconds). My client
> > openssl.conf has no setting override (not that it should matter
> > because this is a server preference). No OpenSSL settings on the
> > server have been modified as well.
>
> Looks to me like the docs are wrong. They probably should say 7200.
>
>
> >
> > In ssl/ssl_sess.c#L80, the code matches the document: ss->timeout =
> > 60 * 5 + 4;   /* 5 minute timeout by default */ ... (with additional
> > four seconds?)
>
>
> This gets set during construction and then later overwritten when we
> actually get a new session via "ssl_get_new_session":
>
>     /* If the context has a default timeout, use it */
>     if (s->session_ctx->session_timeout == 0)
>         ss->timeout = SSL_get_default_timeout(s);
>     else
>         ss->timeout = s->session_ctx->session_timeout;
>
> In most cases SSL_get_default_timeout() calls tls1_default_timeout() (it
> can end up somewhere different for certain protocol versions - but all
> the different variants are the same!):
>
> long tls1_default_timeout(void)
> {
>     /*
>      * 2 hours, the 24 hours mentioned in the TLSv1 spec is way too long
> for
>      * http, the cache would over fill
>      */
>     return (60 * 60 * 2);
> }
>
> 60 * 60 * 2 = 7200
>
>
> Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210126/3185bc61/attachment.html>

From pauli at openssl.org  Wed Jan 27 00:21:40 2021
From: pauli at openssl.org (Dr Paul Dale)
Date: Wed, 27 Jan 2021 10:21:40 +1000
Subject: PKCS12 APIs with fips 3.0
In-Reply-To: <261306f686144c7ae5ad3b1cac78e9b0e34c0b93.camel@t8m.info>
References: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <c7f86553-85df-f2ef-5413-5a73a1384181@wisemo.com>
 <5ef31738-9181-1581-ecf3-e925ee5ad955@openssl.org>
 <261306f686144c7ae5ad3b1cac78e9b0e34c0b93.camel@t8m.info>
Message-ID: <ea8a0b8f-da92-b746-b53b-64089116138d@openssl.org>

I'm not even sure that NIST can validate the PKCS#12 KDF.
If it can't be validated, it doesn't belong in the FIPS provider.


Pauli

On 26/1/21 10:48 pm, Tomas Mraz wrote:
> On Tue, 2021-01-26 at 11:45 +0000, Matt Caswell wrote:
>>
>> On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:
>>> On 2021-01-25 17:53, Zeke Evans wrote:
>>>> Hi,
>>>>
>>>>   
>>>>
>>>> Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse,
>>>> PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips
>>>> provider.  It looks like that is because they try to load
>>>> PKCS12KDF
>>>> which is not implemented in the fips provider.  These were all
>>>> working
>>>> in 1.0.2 with the fips 2.0 module.  Will they be supported in 3.0
>>>> with
>>>> fips?  If not, is there a way for applications running in fips
>>>> approved mode to support the same functionality and use existing
>>>> stores/files that contain PKCS12 objects?
>>>>
>>>>   
>>>>
>>> This is an even larger issue: Is OpenSSL 3.x so badly designed
>>> that the "providers" need to separately implement every standard
>>> or non-standard combination of algorithm invocations?
>>>
>>> In a properly abstracted design PKCS12KDF would be implemented by
>>> invoking general EVP functions for underlying algorithms, which
>>> would in turn invoke the provider versions of those algorithms.
>>
>> This is exactly the way it works. The implementation of PKCS12KDF
>> fetches the underlying digest algorithm using whatever providers it
>> has
>> available. So, for example, if the PKCS12KDF implementation needs to
>> use
>> SHA256, then it will fetch an available implementation for it - and
>> that
>> implementation may come from the FIPS provider (or any other
>> provider).
>>
>> However, in 3.0, KDFs are themselves fetchable cryptographic
>> algorithms
>> implemented by providers. The FIPS module implements a set of KDFs -
>> but
>> PKCS12KDF is not one of them. Its only available from the default
>> provider.
>>
>> So, the summary is, while you can set things up so that all your
>> crypto,
>> including any digests used by the PKCS12KDF, all come from the FIPS
>> provider, there is no getting away from the fact that you still need
>> to
>> have the default provider loaded in order to have an implementation
>> of
>> the PKCS12KDF itself - which will obviously be outside the module
>> boundary.
>>
>> There aren't any current plans to bring the implementation of
>> PKCS12KDF
>> inside the FIPS module. I don't know whether that is feasible or not.
> 
> IMO PKCS12KDF should not be in the FIPS module as this is not a FIPS
> approved KDF algorithm. Besides that KDF should not IMO be needed for
> "modern" PKCS12 files. I need to test that though.
> 

From Zeke.Evans at microfocus.com  Wed Jan 27 00:47:53 2021
From: Zeke.Evans at microfocus.com (Zeke Evans)
Date: Wed, 27 Jan 2021 00:47:53 +0000
Subject: PKCS12 APIs with fips 3.0
In-Reply-To: <ea8a0b8f-da92-b746-b53b-64089116138d@openssl.org>
References: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <c7f86553-85df-f2ef-5413-5a73a1384181@wisemo.com>
 <5ef31738-9181-1581-ecf3-e925ee5ad955@openssl.org>
 <261306f686144c7ae5ad3b1cac78e9b0e34c0b93.camel@t8m.info>
 <ea8a0b8f-da92-b746-b53b-64089116138d@openssl.org>
Message-ID: <CY4PR18MB1526E864EAF5F3F93A2A76BEF3BB9@CY4PR18MB1526.namprd18.prod.outlook.com>

I understand that PKCS12 cannot be implemented in the fips provider but I'm looking for a suitable workaround, particularly something that is close to the same behavior as 1.0.2 with the fips 2.0 module.  

In my case, the default provider is loaded but I am calling EVP_set_default_properties(NULL, "fips=yes").  I can wrap calls to the PKCS12 APIs and momentarily allow non-fips algorithms (ie: "fips=no" or "provider=default") but that prevents the PKCS12 implementation from using the crypto implementations in the fips provider.  Is there a property string or some other way to allow PKCS12KDF in the default provider as well as the crypto methods in the fips provider?  I have tried "provider=default,fips=yes" but that doesn't seem to work.

Using the default provider is probably a reasonable workaround for reading in PKCS12 files in order to maintain backwards compatibility.  Is there a recommended method going forward that would allow reading and writing to a key store while only using the fips provider?

Thanks,
Zeke Evans
Micro Focus

-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Dr Paul Dale
Sent: Tuesday, January 26, 2021 5:22 PM
To: openssl-users at openssl.org
Subject: Re: PKCS12 APIs with fips 3.0

I'm not even sure that NIST can validate the PKCS#12 KDF.
If it can't be validated, it doesn't belong in the FIPS provider.


Pauli

On 26/1/21 10:48 pm, Tomas Mraz wrote:
> On Tue, 2021-01-26 at 11:45 +0000, Matt Caswell wrote:
>>
>> On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:
>>> On 2021-01-25 17:53, Zeke Evans wrote:
>>>> Hi,
>>>>
>>>>   
>>>>
>>>> Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse,
>>>> PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips 
>>>> provider.  It looks like that is because they try to load PKCS12KDF 
>>>> which is not implemented in the fips provider.  These were all 
>>>> working in 1.0.2 with the fips 2.0 module.  Will they be supported 
>>>> in 3.0 with fips?  If not, is there a way for applications running 
>>>> in fips approved mode to support the same functionality and use 
>>>> existing stores/files that contain PKCS12 objects?
>>>>
>>>>   
>>>>
>>> This is an even larger issue: Is OpenSSL 3.x so badly designed that 
>>> the "providers" need to separately implement every standard or 
>>> non-standard combination of algorithm invocations?
>>>
>>> In a properly abstracted design PKCS12KDF would be implemented by 
>>> invoking general EVP functions for underlying algorithms, which 
>>> would in turn invoke the provider versions of those algorithms.
>>
>> This is exactly the way it works. The implementation of PKCS12KDF 
>> fetches the underlying digest algorithm using whatever providers it 
>> has available. So, for example, if the PKCS12KDF implementation needs 
>> to use SHA256, then it will fetch an available implementation for it 
>> - and that implementation may come from the FIPS provider (or any 
>> other provider).
>>
>> However, in 3.0, KDFs are themselves fetchable cryptographic 
>> algorithms implemented by providers. The FIPS module implements a set 
>> of KDFs - but PKCS12KDF is not one of them. Its only available from 
>> the default provider.
>>
>> So, the summary is, while you can set things up so that all your 
>> crypto, including any digests used by the PKCS12KDF, all come from 
>> the FIPS provider, there is no getting away from the fact that you 
>> still need to have the default provider loaded in order to have an 
>> implementation of the PKCS12KDF itself - which will obviously be 
>> outside the module boundary.
>>
>> There aren't any current plans to bring the implementation of 
>> PKCS12KDF inside the FIPS module. I don't know whether that is 
>> feasible or not.
> 
> IMO PKCS12KDF should not be in the FIPS module as this is not a FIPS 
> approved KDF algorithm. Besides that KDF should not IMO be needed for 
> "modern" PKCS12 files. I need to test that though.
> 

From pauli at openssl.org  Wed Jan 27 01:01:11 2021
From: pauli at openssl.org (Dr Paul Dale)
Date: Wed, 27 Jan 2021 11:01:11 +1000
Subject: PKCS12 APIs with fips 3.0
In-Reply-To: <CY4PR18MB1526E864EAF5F3F93A2A76BEF3BB9@CY4PR18MB1526.namprd18.prod.outlook.com>
References: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <c7f86553-85df-f2ef-5413-5a73a1384181@wisemo.com>
 <5ef31738-9181-1581-ecf3-e925ee5ad955@openssl.org>
 <261306f686144c7ae5ad3b1cac78e9b0e34c0b93.camel@t8m.info>
 <ea8a0b8f-da92-b746-b53b-64089116138d@openssl.org>
 <CY4PR18MB1526E864EAF5F3F93A2A76BEF3BB9@CY4PR18MB1526.namprd18.prod.outlook.com>
Message-ID: <ffa7d73b-5577-dadd-906a-73e6f4b24334@openssl.org>

You could set the default property query to "?fips=yes".  This will 
prefer FIPS algorithms over any others but will not prevent other 
algorithms from being fetched.

Pauli

On 27/1/21 10:47 am, Zeke Evans wrote:
> I understand that PKCS12 cannot be implemented in the fips provider but I'm looking for a suitable workaround, particularly something that is close to the same behavior as 1.0.2 with the fips 2.0 module.
> 
> In my case, the default provider is loaded but I am calling EVP_set_default_properties(NULL, "fips=yes").  I can wrap calls to the PKCS12 APIs and momentarily allow non-fips algorithms (ie: "fips=no" or "provider=default") but that prevents the PKCS12 implementation from using the crypto implementations in the fips provider.  Is there a property string or some other way to allow PKCS12KDF in the default provider as well as the crypto methods in the fips provider?  I have tried "provider=default,fips=yes" but that doesn't seem to work.
> 
> Using the default provider is probably a reasonable workaround for reading in PKCS12 files in order to maintain backwards compatibility.  Is there a recommended method going forward that would allow reading and writing to a key store while only using the fips provider?
> 
> Thanks,
> Zeke Evans
> Micro Focus
> 
> -----Original Message-----
> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Dr Paul Dale
> Sent: Tuesday, January 26, 2021 5:22 PM
> To: openssl-users at openssl.org
> Subject: Re: PKCS12 APIs with fips 3.0
> 
> I'm not even sure that NIST can validate the PKCS#12 KDF.
> If it can't be validated, it doesn't belong in the FIPS provider.
> 
> 
> Pauli
> 
> On 26/1/21 10:48 pm, Tomas Mraz wrote:
>> On Tue, 2021-01-26 at 11:45 +0000, Matt Caswell wrote:
>>>
>>> On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:
>>>> On 2021-01-25 17:53, Zeke Evans wrote:
>>>>> Hi,
>>>>>
>>>>>    
>>>>>
>>>>> Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse,
>>>>> PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips
>>>>> provider.  It looks like that is because they try to load PKCS12KDF
>>>>> which is not implemented in the fips provider.  These were all
>>>>> working in 1.0.2 with the fips 2.0 module.  Will they be supported
>>>>> in 3.0 with fips?  If not, is there a way for applications running
>>>>> in fips approved mode to support the same functionality and use
>>>>> existing stores/files that contain PKCS12 objects?
>>>>>
>>>>>    
>>>>>
>>>> This is an even larger issue: Is OpenSSL 3.x so badly designed that
>>>> the "providers" need to separately implement every standard or
>>>> non-standard combination of algorithm invocations?
>>>>
>>>> In a properly abstracted design PKCS12KDF would be implemented by
>>>> invoking general EVP functions for underlying algorithms, which
>>>> would in turn invoke the provider versions of those algorithms.
>>>
>>> This is exactly the way it works. The implementation of PKCS12KDF
>>> fetches the underlying digest algorithm using whatever providers it
>>> has available. So, for example, if the PKCS12KDF implementation needs
>>> to use SHA256, then it will fetch an available implementation for it
>>> - and that implementation may come from the FIPS provider (or any
>>> other provider).
>>>
>>> However, in 3.0, KDFs are themselves fetchable cryptographic
>>> algorithms implemented by providers. The FIPS module implements a set
>>> of KDFs - but PKCS12KDF is not one of them. Its only available from
>>> the default provider.
>>>
>>> So, the summary is, while you can set things up so that all your
>>> crypto, including any digests used by the PKCS12KDF, all come from
>>> the FIPS provider, there is no getting away from the fact that you
>>> still need to have the default provider loaded in order to have an
>>> implementation of the PKCS12KDF itself - which will obviously be
>>> outside the module boundary.
>>>
>>> There aren't any current plans to bring the implementation of
>>> PKCS12KDF inside the FIPS module. I don't know whether that is
>>> feasible or not.
>>
>> IMO PKCS12KDF should not be in the FIPS module as this is not a FIPS
>> approved KDF algorithm. Besides that KDF should not IMO be needed for
>> "modern" PKCS12 files. I need to test that though.
>>

From whippet0 at gmail.com  Wed Jan 27 03:57:48 2021
From: whippet0 at gmail.com (George)
Date: Tue, 26 Jan 2021 22:57:48 -0500
Subject: UI_METHOD functions not being invoked for smart card
In-Reply-To: <1ed07614-f302-f935-3842-3ff3ea50e5e7@nikhef.nl>
References: <ac90a321-3d80-79b4-47c3-d5a2474bc807@gmail.com>
 <1ed07614-f302-f935-3842-3ff3ea50e5e7@nikhef.nl>
Message-ID: <4569dc91-19e2-6d1f-3fea-85c480d3718a@gmail.com>

Hi,

 ? I looked for "NO_UI" in the source code but did not find any 
references to it. I'll take a closer look and see if I can find some 
other flag, which disables the UI_METHOD function calls.

By the way, I found your code for this in eap-tls.c very helpful and 
easy to follow. :)? I did have to make minor modifications for it to 
compile with the Visual Studio C++ compiler, though.

Thanks,
George



On 2021-01-26 4:29 a.m., Jan Just Keijser wrote:
> On 26/01/21 05:28, George wrote:
>> Hi,
>>
>> ??? I'm trying to get OpenSSL 1.0.2u with the FIPS Object Module 
>> 2.0.16? in Windows 10 to prompt the user for a smart card's PIN 
>> number every time the application is launched. However, I cannot seem 
>> to get it to work. My UI_METHOD callback functions are not being invoked.
>>
>> I'm using the following code as a reference:
>> https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c
>>
>> I tried the following:
>>
>>     UI_METHOD* transfer_pin = UI_create_method("transfer_pin");
>>
>>     int writer (UI *ui, UI_STRING *uis)
>>     {
>>     ??? PW_CB_DATA* cb_data = (PW_CB_DATA*)UI_get0_user_data(ui);
>>     ??? UI_set_result(ui, uis, cb_data->password);
>>     ??? return 1;
>>     };
>>     int stub (UI* ui) {return 1;};
>>     int stub_reader (UI *ui, UI_STRING *uis) {return 1;};
>>
>>     UI_method_set_writer(transfer_pin,? writer);
>>     UI_method_set_opener(transfer_pin,? stub);
>>     UI_method_set_closer(transfer_pin,? stub);
>>     UI_method_set_flusher(transfer_pin, stub);
>>     UI_method_set_reader(transfer_pin,? stub_reader);
>>
>>     pkey = ENGINE_load_private_key(pkey_engine, pkey_identifier,
>>     transfer_pin, &cb_data);
>>
>>
>>
>> However, none of the callback functions "writer", "stub", or 
>> "stub_reader" actually get called. Do I need to do anything else to 
>> enable this functionality?? I would like to force the user to enter 
>> PIN number every time.
>>
>
> this depends on how openssl for windows was built ; some non-UNIX 
> builds set the flag OPENSSL_NO_UI_CONSOLE? (or possibly OPENSSL_NO_UI) 
> in which case all UI_methods are effectively disabled. If this flag is 
> set for your build then you will have to rebuild OpenSSL.
>
> Apart from that, that code snippet above is not the cleanest code I 
> have ever written? - some C/C++ compilers do not like functions 
> defined insides an? "if { } " block; you might have to take the 
> function "int writer { } " outside of the "if { } " block.
>
> HTH,
>
> JJK
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210126/b3de8d50/attachment.html>

From harishvk27 at gmail.com  Wed Jan 27 05:59:40 2021
From: harishvk27 at gmail.com (Harish Kulkarni)
Date: Wed, 27 Jan 2021 11:29:40 +0530
Subject: Default value of a session resumption timeout (300 seconds vs
 7200 seconds)
In-Reply-To: <CAHV7XR4YgaRkA-v9sK_M1AuZtiXiUrrFeCU3dYCq8=kB_oN+Bg@mail.gmail.com>
References: <CY4PR0801MB3650AEA1D1A8F2026A64DC93C9BF9@CY4PR0801MB3650.namprd08.prod.outlook.com>
 <8c5d46e5-4ead-ed3b-1671-3929db78df9d@openssl.org>
 <CAHV7XR4YgaRkA-v9sK_M1AuZtiXiUrrFeCU3dYCq8=kB_oN+Bg@mail.gmail.com>
Message-ID: <CAHV7XR7fLU1BXSRXXqycHxqogRLuSna78+66LOdde=mG1cxagA@mail.gmail.com>

Even if session life time is proposed by server.. if client has a
configuration local configuration shouldn't we pick the minimum of what
server is configuring and what client is configured with?.

If we don't have this option in openssl should we have this change.. any
one interested to work along with me?.

-thanks
harish


On Tue, Jan 26, 2021 at 11:43 PM Harish Kulkarni <harishvk27 at gmail.com>
wrote:

> Thank you both for bringing this to my attention, your points are
> invaluable.
>
> If this is something which gets set from server on client side. can client
> override this?. Can i change this to something less and try?. Has anyone
> tried?.
>
> Whats the option in openssl.conf or some other place?.
>
> -thanks
> harish
>
>
> On Mon, Jan 25, 2021 at 11:08 PM Matt Caswell <matt at openssl.org> wrote:
>
>>
>>
>> On 23/01/2021 15:22, John Thoe wrote:
>> > Hi list,
>> >
>> > The session reuse question posted on the mailing list earlier
>> > (
>> https://mta.openssl.org/pipermail/openssl-users/2021-January/013360.html)
>> > reminded of a somewhat similar question I have.
>> >
>> > As per the docs,
>> > https://www.openssl.org/docs/man1.0.2/man3/SSL_get_default_timeout.html
>> ,
>> > it says the default value is 300 seconds for which a session resuse
>> > will be accepted. The docs say that it is the same for all
>> > protocols.
>> >
>> > However I tried it with my setup where I didn't explicitly set the
>> > timeout and I am getting 7200 seconds as the default value. s_client
>> > output: TLS session ticket lifetime hint: 7200 (seconds). My client
>> > openssl.conf has no setting override (not that it should matter
>> > because this is a server preference). No OpenSSL settings on the
>> > server have been modified as well.
>>
>> Looks to me like the docs are wrong. They probably should say 7200.
>>
>>
>> >
>> > In ssl/ssl_sess.c#L80, the code matches the document: ss->timeout =
>> > 60 * 5 + 4;   /* 5 minute timeout by default */ ... (with additional
>> > four seconds?)
>>
>>
>> This gets set during construction and then later overwritten when we
>> actually get a new session via "ssl_get_new_session":
>>
>>     /* If the context has a default timeout, use it */
>>     if (s->session_ctx->session_timeout == 0)
>>         ss->timeout = SSL_get_default_timeout(s);
>>     else
>>         ss->timeout = s->session_ctx->session_timeout;
>>
>> In most cases SSL_get_default_timeout() calls tls1_default_timeout() (it
>> can end up somewhere different for certain protocol versions - but all
>> the different variants are the same!):
>>
>> long tls1_default_timeout(void)
>> {
>>     /*
>>      * 2 hours, the 24 hours mentioned in the TLSv1 spec is way too long
>> for
>>      * http, the cache would over fill
>>      */
>>     return (60 * 60 * 2);
>> }
>>
>> 60 * 60 * 2 = 7200
>>
>>
>> Matt
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210127/31aa2ee1/attachment-0001.html>

From matt at openssl.org  Wed Jan 27 10:02:57 2021
From: matt at openssl.org (Matt Caswell)
Date: Wed, 27 Jan 2021 10:02:57 +0000
Subject: Default value of a session resumption timeout (300 seconds vs
 7200 seconds)
In-Reply-To: <CAHV7XR4YgaRkA-v9sK_M1AuZtiXiUrrFeCU3dYCq8=kB_oN+Bg@mail.gmail.com>
References: <CY4PR0801MB3650AEA1D1A8F2026A64DC93C9BF9@CY4PR0801MB3650.namprd08.prod.outlook.com>
 <8c5d46e5-4ead-ed3b-1671-3929db78df9d@openssl.org>
 <CAHV7XR4YgaRkA-v9sK_M1AuZtiXiUrrFeCU3dYCq8=kB_oN+Bg@mail.gmail.com>
Message-ID: <3bcaee40-5bbe-fa3c-d95f-d1e637d59509@openssl.org>



On 26/01/2021 18:13, Harish Kulkarni wrote:
> Thank you both for bringing this to my attention, your points are
> invaluable.
> 
> If this is something which gets set from server?on client side. can
> client override this?. Can i change this to something less and try?. Has
> anyone tried?.
> 
> Whats the option in openssl.conf or some other place?.

The session timeout is something entirely controlled by the server. The
client has no influence on this*. If the server is using session tickets
for its sessions then it provides a lifetime hint to the client to say
how long the client can expect the session to be good for. The client
can query this using SSL_SESSION_get_ticket_lifetime_hint().

On the server the timeout can be configured using SSL_CTX_set_timeout().
I don't think this is possible to change via openssl.conf.

Matt


* Note that the client may be managing a cache of sessions provided by
servers. That's not something that happens by default in OpenSSL but can
be configured using SSL_CTX_set_session_cache_mode(). In that case there
will be separate timeouts associated with the life of the session in the
client cache. Those timeouts may not be the same as the server's timeouts.

> 
> -thanks
> harish
> 
> 
> On Mon, Jan 25, 2021 at 11:08 PM Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>     On 23/01/2021 15:22, John Thoe wrote:
>     > Hi list,
>     >
>     > The session reuse question posted on the mailing list earlier
>     >
>     (https://mta.openssl.org/pipermail/openssl-users/2021-January/013360.html)
>     > reminded of a somewhat similar question I have.
>     >
>     > As per the docs,
>     >
>     https://www.openssl.org/docs/man1.0.2/man3/SSL_get_default_timeout.html,
>     > it says the default value is 300 seconds for which a session resuse
>     > will be accepted. The docs say that it is the same for all
>     > protocols.
>     >
>     > However I tried it with my setup where I didn't explicitly set the
>     > timeout and I am getting 7200 seconds as the default value. s_client
>     > output: TLS session ticket lifetime hint: 7200 (seconds). My client
>     > openssl.conf has no setting override (not that it should matter
>     > because this is a server preference). No OpenSSL settings on the
>     > server have been modified as well.
> 
>     Looks to me like the docs are wrong. They probably should say 7200.
> 
> 
>     >
>     > In ssl/ssl_sess.c#L80, the code matches the document: ss->timeout =
>     > 60 * 5 + 4;? ?/* 5 minute timeout by default */ ... (with additional
>     > four seconds?)
> 
> 
>     This gets set during construction and then later overwritten when we
>     actually get a new session via "ssl_get_new_session":
> 
>     ? ? /* If the context has a default timeout, use it */
>     ? ? if (s->session_ctx->session_timeout == 0)
>     ? ? ? ? ss->timeout = SSL_get_default_timeout(s);
>     ? ? else
>     ? ? ? ? ss->timeout = s->session_ctx->session_timeout;
> 
>     In most cases SSL_get_default_timeout() calls tls1_default_timeout() (it
>     can end up somewhere different for certain protocol versions - but all
>     the different variants are the same!):
> 
>     long tls1_default_timeout(void)
>     {
>     ? ? /*
>     ? ? ?* 2 hours, the 24 hours mentioned in the TLSv1 spec is way too
>     long for
>     ? ? ?* http, the cache would over fill
>     ? ? ?*/
>     ? ? return (60 * 60 * 2);
>     }
> 
>     60 * 60 * 2 = 7200
> 
> 
>     Matt
> 

From Zeke.Evans at microfocus.com  Wed Jan 27 14:02:44 2021
From: Zeke.Evans at microfocus.com (Zeke Evans)
Date: Wed, 27 Jan 2021 14:02:44 +0000
Subject: PKCS12 APIs with fips 3.0
In-Reply-To: <ffa7d73b-5577-dadd-906a-73e6f4b24334@openssl.org>
References: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <c7f86553-85df-f2ef-5413-5a73a1384181@wisemo.com>
 <5ef31738-9181-1581-ecf3-e925ee5ad955@openssl.org>
 <261306f686144c7ae5ad3b1cac78e9b0e34c0b93.camel@t8m.info>
 <ea8a0b8f-da92-b746-b53b-64089116138d@openssl.org>
 <CY4PR18MB1526E864EAF5F3F93A2A76BEF3BB9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <ffa7d73b-5577-dadd-906a-73e6f4b24334@openssl.org>
Message-ID: <CY4PR18MB15267E380EA1C946ACF47E76F3BB9@CY4PR18MB1526.namprd18.prod.outlook.com>

That works.  Thanks!

-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Dr Paul Dale
Sent: Tuesday, January 26, 2021 6:01 PM

You could set the default property query to "?fips=yes".  This will prefer FIPS algorithms over any others but will not prevent other algorithms from being fetched.

Pauli


From sanarayana at rbbn.com  Wed Jan 27 15:13:53 2021
From: sanarayana at rbbn.com (Narayana, Sunil Kumar)
Date: Wed, 27 Jan 2021 15:13:53 +0000
Subject: <Replacement for RSA_public_decrypt>
Message-ID: <SN6PR03MB406197D8639A66FFB244F57CB0BB9@SN6PR03MB4061.namprd03.prod.outlook.com>

Dear Openssl team,
                While migrating from 1.0.2 to 3.0 we observe that RSA_public_decrypt() API been deprecated in 3.0.
We referred the example provided in man page but we are not clear in generating the initial 'key' required to create CTX.
Please suggest on (key , eng) params to proceed

Also currently we are using PEM_read_bio_RSA_PUBKEY() to generate RSA, I think this might not require in case of EVP, please suggest.

/*
  * NB: assumes key, eng, in, inlen are already set up
  * and that key is an RSA private key
  */
ctx = EVP_PKEY_CTX_new(key, eng);


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: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210127/142824d8/attachment-0001.html>

From jb-openssl at wisemo.com  Thu Jan 28 08:26:06 2021
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 28 Jan 2021 09:26:06 +0100
Subject: PKCS12 APIs with fips 3.0
In-Reply-To: <ffa7d73b-5577-dadd-906a-73e6f4b24334@openssl.org>
References: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <c7f86553-85df-f2ef-5413-5a73a1384181@wisemo.com>
 <5ef31738-9181-1581-ecf3-e925ee5ad955@openssl.org>
 <261306f686144c7ae5ad3b1cac78e9b0e34c0b93.camel@t8m.info>
 <ea8a0b8f-da92-b746-b53b-64089116138d@openssl.org>
 <CY4PR18MB1526E864EAF5F3F93A2A76BEF3BB9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <ffa7d73b-5577-dadd-906a-73e6f4b24334@openssl.org>
Message-ID: <5c783662-a8e7-4fea-ece5-7cb2dafd25ff@wisemo.com>

Does that mean that OpenSSL 3.0 will not have a true "FIPS mode" where 
all the non-FIPS algorithms are disabled, but the FIPS-independent 
schemes/protocols in the "default" provider remains available?

Remember that in other software systems, such as OpenSSL 1.0.x and MS 
CryptoAPI, FIPS mode causes all non-validated algorithms to fail hard, 
so all higher level operations are guaranteed to use only FIPS-validated 
crypto.

On 2021-01-27 02:01, Dr Paul Dale wrote:
> You could set the default property query to "?fips=yes".? This will 
> prefer FIPS algorithms over any others but will not prevent other 
> algorithms from being fetched.
>
> Pauli
>
> On 27/1/21 10:47 am, Zeke Evans wrote:
>> I understand that PKCS12 cannot be implemented in the fips provider 
>> but I'm looking for a suitable workaround, particularly something 
>> that is close to the same behavior as 1.0.2 with the fips 2.0 module.
>>
>> In my case, the default provider is loaded but I am calling 
>> EVP_set_default_properties(NULL, "fips=yes").? I can wrap calls to 
>> the PKCS12 APIs and momentarily allow non-fips algorithms (ie: 
>> "fips=no" or "provider=default") but that prevents the PKCS12 
>> implementation from using the crypto implementations in the fips 
>> provider.? Is there a property string or some other way to allow 
>> PKCS12KDF in the default provider as well as the crypto methods in 
>> the fips provider?? I have tried "provider=default,fips=yes" but that 
>> doesn't seem to work.
>>
>> Using the default provider is probably a reasonable workaround for 
>> reading in PKCS12 files in order to maintain backwards 
>> compatibility.? Is there a recommended method going forward that 
>> would allow reading and writing to a key store while only using the 
>> fips provider?
>>
>> Thanks,
>> Zeke Evans
>> Micro Focus
>>
>> -----Original Message-----
>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of 
>> Dr Paul Dale
>> Sent: Tuesday, January 26, 2021 5:22 PM
>> To: openssl-users at openssl.org
>> Subject: Re: PKCS12 APIs with fips 3.0
>>
>> I'm not even sure that NIST can validate the PKCS#12 KDF.
>> If it can't be validated, it doesn't belong in the FIPS provider.
>>
>>
>> Pauli
>>
>> On 26/1/21 10:48 pm, Tomas Mraz wrote:
>>> On Tue, 2021-01-26 at 11:45 +0000, Matt Caswell wrote:
>>>>
>>>> On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:
>>>>> On 2021-01-25 17:53, Zeke Evans wrote:
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse,
>>>>>> PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips
>>>>>> provider.? It looks like that is because they try to load PKCS12KDF
>>>>>> which is not implemented in the fips provider.? These were all
>>>>>> working in 1.0.2 with the fips 2.0 module.? Will they be supported
>>>>>> in 3.0 with fips?? If not, is there a way for applications running
>>>>>> in fips approved mode to support the same functionality and use
>>>>>> existing stores/files that contain PKCS12 objects?
>>>>>>
>>>>>>
>>>>> This is an even larger issue: Is OpenSSL 3.x so badly designed that
>>>>> the "providers" need to separately implement every standard or
>>>>> non-standard combination of algorithm invocations?
>>>>>
>>>>> In a properly abstracted design PKCS12KDF would be implemented by
>>>>> invoking general EVP functions for underlying algorithms, which
>>>>> would in turn invoke the provider versions of those algorithms.
>>>>
>>>> This is exactly the way it works. The implementation of PKCS12KDF
>>>> fetches the underlying digest algorithm using whatever providers it
>>>> has available. So, for example, if the PKCS12KDF implementation needs
>>>> to use SHA256, then it will fetch an available implementation for it
>>>> - and that implementation may come from the FIPS provider (or any
>>>> other provider).
>>>>
>>>> However, in 3.0, KDFs are themselves fetchable cryptographic
>>>> algorithms implemented by providers. The FIPS module implements a set
>>>> of KDFs - but PKCS12KDF is not one of them. Its only available from
>>>> the default provider.
>>>>
>>>> So, the summary is, while you can set things up so that all your
>>>> crypto, including any digests used by the PKCS12KDF, all come from
>>>> the FIPS provider, there is no getting away from the fact that you
>>>> still need to have the default provider loaded in order to have an
>>>> implementation of the PKCS12KDF itself - which will obviously be
>>>> outside the module boundary.
>>>>
>>>> There aren't any current plans to bring the implementation of
>>>> PKCS12KDF inside the FIPS module. I don't know whether that is
>>>> feasible or not.
>>>
>>> IMO PKCS12KDF should not be in the FIPS module as this is not a FIPS
>>> approved KDF algorithm. Besides that KDF should not IMO be needed for
>>> "modern" PKCS12 files. I need to test that though.
>>>
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 tm at t8m.info  Thu Jan 28 08:36:16 2021
From: tm at t8m.info (Tomas Mraz)
Date: Thu, 28 Jan 2021 09:36:16 +0100
Subject: PKCS12 APIs with fips 3.0
In-Reply-To: <5c783662-a8e7-4fea-ece5-7cb2dafd25ff@wisemo.com>
References: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <c7f86553-85df-f2ef-5413-5a73a1384181@wisemo.com>
 <5ef31738-9181-1581-ecf3-e925ee5ad955@openssl.org>
 <261306f686144c7ae5ad3b1cac78e9b0e34c0b93.camel@t8m.info>
 <ea8a0b8f-da92-b746-b53b-64089116138d@openssl.org>
 <CY4PR18MB1526E864EAF5F3F93A2A76BEF3BB9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <ffa7d73b-5577-dadd-906a-73e6f4b24334@openssl.org>
 <5c783662-a8e7-4fea-ece5-7cb2dafd25ff@wisemo.com>
Message-ID: <e4c56e9c66ce47e4a8f9c074f6fda38559b73cd2.camel@t8m.info>

I do not get how you came to this conclusion. The "true" FIPS mode can
be easily achieved with OpenSSL 3.0 - either by loading just the fips
and base provider, or by loading both default and fips providers but
using the "fips=yes" default property (without the "?").

The PKCS12KDF does not work because it is not an FIPS approved KDF
algorithm so it cannot really work in the "true" FIPS mode. But IMO
this does not mean that PKCS12 keys do not work at all - if you use
right (more modern) algoritm based on PBKDF2 to do the password based
key derivation, they should work.

That in 1.0.x the PKCS12 worked with the FIPS module with legacy
algorithms it only shows that the "true" FIPS mode was not as "true" as
you might think. There were some crypto algorithms like the KDFs
outside of the FIPS module boundary.

Tomas Mraz

On Thu, 2021-01-28 at 09:26 +0100, Jakob Bohm via openssl-users wrote:
> Does that mean that OpenSSL 3.0 will not have a true "FIPS mode"
> where 
> all the non-FIPS algorithms are disabled, but the FIPS-independent 
> schemes/protocols in the "default" provider remains available?
> 
> Remember that in other software systems, such as OpenSSL 1.0.x and
> MS 
> CryptoAPI, FIPS mode causes all non-validated algorithms to fail
> hard, 
> so all higher level operations are guaranteed to use only FIPS-
> validated 
> crypto.
> 
> On 2021-01-27 02:01, Dr Paul Dale wrote:
> > You could set the default property query to "?fips=yes".  This
> > will 
> > prefer FIPS algorithms over any others but will not prevent other 
> > algorithms from being fetched.
> > 
> > Pauli
> > 
> > On 27/1/21 10:47 am, Zeke Evans wrote:
> > > I understand that PKCS12 cannot be implemented in the fips
> > > provider 
> > > but I'm looking for a suitable workaround, particularly
> > > something 
> > > that is close to the same behavior as 1.0.2 with the fips 2.0
> > > module.
> > > 
> > > In my case, the default provider is loaded but I am calling 
> > > EVP_set_default_properties(NULL, "fips=yes").  I can wrap calls
> > > to 
> > > the PKCS12 APIs and momentarily allow non-fips algorithms (ie: 
> > > "fips=no" or "provider=default") but that prevents the PKCS12 
> > > implementation from using the crypto implementations in the fips 
> > > provider.  Is there a property string or some other way to allow 
> > > PKCS12KDF in the default provider as well as the crypto methods
> > > in 
> > > the fips provider?  I have tried "provider=default,fips=yes" but
> > > that 
> > > doesn't seem to work.
> > > 
> > > Using the default provider is probably a reasonable workaround
> > > for 
> > > reading in PKCS12 files in order to maintain backwards 
> > > compatibility.  Is there a recommended method going forward that 
> > > would allow reading and writing to a key store while only using
> > > the 
> > > fips provider?
> > > 
> > > Thanks,
> > > Zeke Evans
> > > Micro Focus
> > > 
> > > -----Original Message-----
> > > From: openssl-users <openssl-users-bounces at openssl.org> On Behalf
> > > Of 
> > > Dr Paul Dale
> > > Sent: Tuesday, January 26, 2021 5:22 PM
> > > To: openssl-users at openssl.org
> > > Subject: Re: PKCS12 APIs with fips 3.0
> > > 
> > > I'm not even sure that NIST can validate the PKCS#12 KDF.
> > > If it can't be validated, it doesn't belong in the FIPS provider.
> > > 
> > > 
> > > Pauli
> > > 
> > > On 26/1/21 10:48 pm, Tomas Mraz wrote:
> > > > On Tue, 2021-01-26 at 11:45 +0000, Matt Caswell wrote:
> > > > > On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:
> > > > > > On 2021-01-25 17:53, Zeke Evans wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > 
> > > > > > > Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse,
> > > > > > > PKCS12_verify_mac) do not work in OpenSSL 3.0 when using
> > > > > > > the fips
> > > > > > > provider.  It looks like that is because they try to load
> > > > > > > PKCS12KDF
> > > > > > > which is not implemented in the fips provider.  These
> > > > > > > were all
> > > > > > > working in 1.0.2 with the fips 2.0 module.  Will they be
> > > > > > > supported
> > > > > > > in 3.0 with fips?  If not, is there a way for
> > > > > > > applications running
> > > > > > > in fips approved mode to support the same functionality
> > > > > > > and use
> > > > > > > existing stores/files that contain PKCS12 objects?
> > > > > > > 
> > > > > > > 
> > > > > > This is an even larger issue: Is OpenSSL 3.x so badly
> > > > > > designed that
> > > > > > the "providers" need to separately implement every standard
> > > > > > or
> > > > > > non-standard combination of algorithm invocations?
> > > > > > 
> > > > > > In a properly abstracted design PKCS12KDF would be
> > > > > > implemented by
> > > > > > invoking general EVP functions for underlying algorithms,
> > > > > > which
> > > > > > would in turn invoke the provider versions of those
> > > > > > algorithms.
> > > > > 
> > > > > This is exactly the way it works. The implementation of
> > > > > PKCS12KDF
> > > > > fetches the underlying digest algorithm using whatever
> > > > > providers it
> > > > > has available. So, for example, if the PKCS12KDF
> > > > > implementation needs
> > > > > to use SHA256, then it will fetch an available implementation
> > > > > for it
> > > > > - and that implementation may come from the FIPS provider (or
> > > > > any
> > > > > other provider).
> > > > > 
> > > > > However, in 3.0, KDFs are themselves fetchable cryptographic
> > > > > algorithms implemented by providers. The FIPS module
> > > > > implements a set
> > > > > of KDFs - but PKCS12KDF is not one of them. Its only
> > > > > available from
> > > > > the default provider.
> > > > > 
> > > > > So, the summary is, while you can set things up so that all
> > > > > your
> > > > > crypto, including any digests used by the PKCS12KDF, all come
> > > > > from
> > > > > the FIPS provider, there is no getting away from the fact
> > > > > that you
> > > > > still need to have the default provider loaded in order to
> > > > > have an
> > > > > implementation of the PKCS12KDF itself - which will obviously
> > > > > be
> > > > > outside the module boundary.
> > > > > 
> > > > > There aren't any current plans to bring the implementation of
> > > > > PKCS12KDF inside the FIPS module. I don't know whether that
> > > > > is
> > > > > feasible or not.
> > > > 
> > > > IMO PKCS12KDF should not be in the FIPS module as this is not a
> > > > FIPS
> > > > approved KDF algorithm. Besides that KDF should not IMO be
> > > > needed for
> > > > "modern" PKCS12 files. I need to test that though.
> > > > 
> Enjoy
> 
> Jakob
-- 
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 matt at openssl.org  Thu Jan 28 08:42:45 2021
From: matt at openssl.org (Matt Caswell)
Date: Thu, 28 Jan 2021 08:42:45 +0000
Subject: PKCS12 APIs with fips 3.0
In-Reply-To: <5c783662-a8e7-4fea-ece5-7cb2dafd25ff@wisemo.com>
References: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <c7f86553-85df-f2ef-5413-5a73a1384181@wisemo.com>
 <5ef31738-9181-1581-ecf3-e925ee5ad955@openssl.org>
 <261306f686144c7ae5ad3b1cac78e9b0e34c0b93.camel@t8m.info>
 <ea8a0b8f-da92-b746-b53b-64089116138d@openssl.org>
 <CY4PR18MB1526E864EAF5F3F93A2A76BEF3BB9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <ffa7d73b-5577-dadd-906a-73e6f4b24334@openssl.org>
 <5c783662-a8e7-4fea-ece5-7cb2dafd25ff@wisemo.com>
Message-ID: <31e8877b-1973-9972-3731-d54c0e61c714@openssl.org>



On 28/01/2021 08:26, Jakob Bohm via openssl-users wrote:
> Does that mean that OpenSSL 3.0 will not have a true "FIPS mode" where
> all the non-FIPS algorithms are disabled, but the FIPS-independent
> schemes/protocols in the "default" provider remains available?
> 
> Remember that in other software systems, such as OpenSSL 1.0.x and MS
> CryptoAPI, FIPS mode causes all non-validated algorithms to fail hard,
> so all higher level operations are guaranteed to use only FIPS-validated
> crypto.

In 3.0 all crypto algorithms are moved to providers. Higher level
features such as CMS and TLS etc remain in libcrypto/libssl.

Applications can load the providers that they want to use for any given
situation. To simulate the way that 1.0.x worked in FIPS mode then they
can choose to *only* load the FIPS provider which will guarantee that no
non FIPS-validated crypto can be used.

Alternatively they can have both FIPS and non-FIPS crypto providers
loaded and available at the same time and swap between them as required
for the context.

More details of how this works are on the 3.0 wiki page here:

https://wiki.openssl.org/index.php/OpenSSL_3.0

In particular section 7 of the above page discusses the various options
you have for using FIPS validated crypto.

Matt


> 
> On 2021-01-27 02:01, Dr Paul Dale wrote:
>> You could set the default property query to "?fips=yes".? This will
>> prefer FIPS algorithms over any others but will not prevent other
>> algorithms from being fetched.
>>
>> Pauli
>>
>> On 27/1/21 10:47 am, Zeke Evans wrote:
>>> I understand that PKCS12 cannot be implemented in the fips provider
>>> but I'm looking for a suitable workaround, particularly something
>>> that is close to the same behavior as 1.0.2 with the fips 2.0 module.
>>>
>>> In my case, the default provider is loaded but I am calling
>>> EVP_set_default_properties(NULL, "fips=yes").? I can wrap calls to
>>> the PKCS12 APIs and momentarily allow non-fips algorithms (ie:
>>> "fips=no" or "provider=default") but that prevents the PKCS12
>>> implementation from using the crypto implementations in the fips
>>> provider.? Is there a property string or some other way to allow
>>> PKCS12KDF in the default provider as well as the crypto methods in
>>> the fips provider?? I have tried "provider=default,fips=yes" but that
>>> doesn't seem to work.
>>>
>>> Using the default provider is probably a reasonable workaround for
>>> reading in PKCS12 files in order to maintain backwards
>>> compatibility.? Is there a recommended method going forward that
>>> would allow reading and writing to a key store while only using the
>>> fips provider?
>>>
>>> Thanks,
>>> Zeke Evans
>>> Micro Focus
>>>
>>> -----Original Message-----
>>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of
>>> Dr Paul Dale
>>> Sent: Tuesday, January 26, 2021 5:22 PM
>>> To: openssl-users at openssl.org
>>> Subject: Re: PKCS12 APIs with fips 3.0
>>>
>>> I'm not even sure that NIST can validate the PKCS#12 KDF.
>>> If it can't be validated, it doesn't belong in the FIPS provider.
>>>
>>>
>>> Pauli
>>>
>>> On 26/1/21 10:48 pm, Tomas Mraz wrote:
>>>> On Tue, 2021-01-26 at 11:45 +0000, Matt Caswell wrote:
>>>>>
>>>>> On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:
>>>>>> On 2021-01-25 17:53, Zeke Evans wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>> Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse,
>>>>>>> PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips
>>>>>>> provider.? It looks like that is because they try to load PKCS12KDF
>>>>>>> which is not implemented in the fips provider.? These were all
>>>>>>> working in 1.0.2 with the fips 2.0 module.? Will they be supported
>>>>>>> in 3.0 with fips?? If not, is there a way for applications running
>>>>>>> in fips approved mode to support the same functionality and use
>>>>>>> existing stores/files that contain PKCS12 objects?
>>>>>>>
>>>>>>>
>>>>>> This is an even larger issue: Is OpenSSL 3.x so badly designed that
>>>>>> the "providers" need to separately implement every standard or
>>>>>> non-standard combination of algorithm invocations?
>>>>>>
>>>>>> In a properly abstracted design PKCS12KDF would be implemented by
>>>>>> invoking general EVP functions for underlying algorithms, which
>>>>>> would in turn invoke the provider versions of those algorithms.
>>>>>
>>>>> This is exactly the way it works. The implementation of PKCS12KDF
>>>>> fetches the underlying digest algorithm using whatever providers it
>>>>> has available. So, for example, if the PKCS12KDF implementation needs
>>>>> to use SHA256, then it will fetch an available implementation for it
>>>>> - and that implementation may come from the FIPS provider (or any
>>>>> other provider).
>>>>>
>>>>> However, in 3.0, KDFs are themselves fetchable cryptographic
>>>>> algorithms implemented by providers. The FIPS module implements a set
>>>>> of KDFs - but PKCS12KDF is not one of them. Its only available from
>>>>> the default provider.
>>>>>
>>>>> So, the summary is, while you can set things up so that all your
>>>>> crypto, including any digests used by the PKCS12KDF, all come from
>>>>> the FIPS provider, there is no getting away from the fact that you
>>>>> still need to have the default provider loaded in order to have an
>>>>> implementation of the PKCS12KDF itself - which will obviously be
>>>>> outside the module boundary.
>>>>>
>>>>> There aren't any current plans to bring the implementation of
>>>>> PKCS12KDF inside the FIPS module. I don't know whether that is
>>>>> feasible or not.
>>>>
>>>> IMO PKCS12KDF should not be in the FIPS module as this is not a FIPS
>>>> approved KDF algorithm. Besides that KDF should not IMO be needed for
>>>> "modern" PKCS12 files. I need to test that though.
>>>>
> Enjoy
> 
> Jakob

From jb-openssl at wisemo.com  Thu Jan 28 09:24:26 2021
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 28 Jan 2021 10:24:26 +0100
Subject: PKCS12 APIs with fips 3.0
In-Reply-To: <e4c56e9c66ce47e4a8f9c074f6fda38559b73cd2.camel@t8m.info>
References: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <c7f86553-85df-f2ef-5413-5a73a1384181@wisemo.com>
 <5ef31738-9181-1581-ecf3-e925ee5ad955@openssl.org>
 <261306f686144c7ae5ad3b1cac78e9b0e34c0b93.camel@t8m.info>
 <ea8a0b8f-da92-b746-b53b-64089116138d@openssl.org>
 <CY4PR18MB1526E864EAF5F3F93A2A76BEF3BB9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <ffa7d73b-5577-dadd-906a-73e6f4b24334@openssl.org>
 <5c783662-a8e7-4fea-ece5-7cb2dafd25ff@wisemo.com>
 <e4c56e9c66ce47e4a8f9c074f6fda38559b73cd2.camel@t8m.info>
Message-ID: <0a05bfba-5808-1403-21e7-2746dc1966de@wisemo.com>

Does FIPS 140 or the related legal requirements limit the use of higher
level compositions such as PKCS12KDF, when using only validated
cryptography for the underlying operations?

On 2021-01-28 09:36, Tomas Mraz wrote:
> I do not get how you came to this conclusion. The "true" FIPS mode can
> be easily achieved with OpenSSL 3.0 - either by loading just the fips
> and base provider, or by loading both default and fips providers but
> using the "fips=yes" default property (without the "?").
> 
> The PKCS12KDF does not work because it is not an FIPS approved KDF
> algorithm so it cannot really work in the "true" FIPS mode. But IMO
> this does not mean that PKCS12 keys do not work at all - if you use
> right (more modern) algoritm based on PBKDF2 to do the password based
> key derivation, they should work.
> 
> That in 1.0.x the PKCS12 worked with the FIPS module with legacy
> algorithms it only shows that the "true" FIPS mode was not as "true" as
> you might think. There were some crypto algorithms like the KDFs
> outside of the FIPS module boundary.
> 
> Tomas Mraz
> 
> On Thu, 2021-01-28 at 09:26 +0100, Jakob Bohm via openssl-users wrote:
>> Does that mean that OpenSSL 3.0 will not have a true "FIPS mode"
>> where
>> all the non-FIPS algorithms are disabled, but the FIPS-independent
>> schemes/protocols in the "default" provider remains available?
>>
>> Remember that in other software systems, such as OpenSSL 1.0.x and
>> MS
>> CryptoAPI, FIPS mode causes all non-validated algorithms to fail
>> hard,
>> so all higher level operations are guaranteed to use only FIPS-
>> validated
>> crypto.
>>
>> On 2021-01-27 02:01, Dr Paul Dale wrote:
>>> You could set the default property query to "?fips=yes".  This
>>> will
>>> prefer FIPS algorithms over any others but will not prevent other
>>> algorithms from being fetched.
>>>
>>> Pauli
>>>
>>> On 27/1/21 10:47 am, Zeke Evans wrote:
>>>> I understand that PKCS12 cannot be implemented in the fips
>>>> provider
>>>> but I'm looking for a suitable workaround, particularly
>>>> something
>>>> that is close to the same behavior as 1.0.2 with the fips 2.0
>>>> module.
>>>>
>>>> In my case, the default provider is loaded but I am calling
>>>> EVP_set_default_properties(NULL, "fips=yes").  I can wrap calls
>>>> to
>>>> the PKCS12 APIs and momentarily allow non-fips algorithms (ie:
>>>> "fips=no" or "provider=default") but that prevents the PKCS12
>>>> implementation from using the crypto implementations in the fips
>>>> provider.  Is there a property string or some other way to allow
>>>> PKCS12KDF in the default provider as well as the crypto methods
>>>> in
>>>> the fips provider?  I have tried "provider=default,fips=yes" but
>>>> that
>>>> doesn't seem to work.
>>>>
>>>> Using the default provider is probably a reasonable workaround
>>>> for
>>>> reading in PKCS12 files in order to maintain backwards
>>>> compatibility.  Is there a recommended method going forward that
>>>> would allow reading and writing to a key store while only using
>>>> the
>>>> fips provider?
>>>>
>>>> Thanks,
>>>> Zeke Evans
>>>> Micro Focus
>>>>
>>>> -----Original Message-----
>>>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf
>>>> Of
>>>> Dr Paul Dale
>>>> Sent: Tuesday, January 26, 2021 5:22 PM
>>>> To: openssl-users at openssl.org
>>>> Subject: Re: PKCS12 APIs with fips 3.0
>>>>
>>>> I'm not even sure that NIST can validate the PKCS#12 KDF.
>>>> If it can't be validated, it doesn't belong in the FIPS provider.
>>>>
>>>>
>>>> Pauli
>>>>
>>>> On 26/1/21 10:48 pm, Tomas Mraz wrote:
>>>>> On Tue, 2021-01-26 at 11:45 +0000, Matt Caswell wrote:
>>>>>> On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:
>>>>>>> On 2021-01-25 17:53, Zeke Evans wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>> Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse,
>>>>>>>> PKCS12_verify_mac) do not work in OpenSSL 3.0 when using
>>>>>>>> the fips
>>>>>>>> provider.  It looks like that is because they try to load
>>>>>>>> PKCS12KDF
>>>>>>>> which is not implemented in the fips provider.  These
>>>>>>>> were all
>>>>>>>> working in 1.0.2 with the fips 2.0 module.  Will they be
>>>>>>>> supported
>>>>>>>> in 3.0 with fips?  If not, is there a way for
>>>>>>>> applications running
>>>>>>>> in fips approved mode to support the same functionality
>>>>>>>> and use
>>>>>>>> existing stores/files that contain PKCS12 objects?
>>>>>>>>
>>>>>>>>
>>>>>>> This is an even larger issue: Is OpenSSL 3.x so badly
>>>>>>> designed that
>>>>>>> the "providers" need to separately implement every standard
>>>>>>> or
>>>>>>> non-standard combination of algorithm invocations?
>>>>>>>
>>>>>>> In a properly abstracted design PKCS12KDF would be
>>>>>>> implemented by
>>>>>>> invoking general EVP functions for underlying algorithms,
>>>>>>> which
>>>>>>> would in turn invoke the provider versions of those
>>>>>>> algorithms.
>>>>>>
>>>>>> This is exactly the way it works. The implementation of
>>>>>> PKCS12KDF
>>>>>> fetches the underlying digest algorithm using whatever
>>>>>> providers it
>>>>>> has available. So, for example, if the PKCS12KDF
>>>>>> implementation needs
>>>>>> to use SHA256, then it will fetch an available implementation
>>>>>> for it
>>>>>> - and that implementation may come from the FIPS provider (or
>>>>>> any
>>>>>> other provider).
>>>>>>
>>>>>> However, in 3.0, KDFs are themselves fetchable cryptographic
>>>>>> algorithms implemented by providers. The FIPS module
>>>>>> implements a set
>>>>>> of KDFs - but PKCS12KDF is not one of them. Its only
>>>>>> available from
>>>>>> the default provider.
>>>>>>
>>>>>> So, the summary is, while you can set things up so that all
>>>>>> your
>>>>>> crypto, including any digests used by the PKCS12KDF, all come
>>>>>> from
>>>>>> the FIPS provider, there is no getting away from the fact
>>>>>> that you
>>>>>> still need to have the default provider loaded in order to
>>>>>> have an
>>>>>> implementation of the PKCS12KDF itself - which will obviously
>>>>>> be
>>>>>> outside the module boundary.
>>>>>>
>>>>>> There aren't any current plans to bring the implementation of
>>>>>> PKCS12KDF inside the FIPS module. I don't know whether that
>>>>>> is
>>>>>> feasible or not.
>>>>>
>>>>> IMO PKCS12KDF should not be in the FIPS module as this is not a
>>>>> FIPS
>>>>> approved KDF algorithm. Besides that KDF should not IMO be
>>>>> needed for
>>>>> "modern" PKCS12 files. I need to test that though.
>>>>>




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 tm at t8m.info  Thu Jan 28 09:46:20 2021
From: tm at t8m.info (Tomas Mraz)
Date: Thu, 28 Jan 2021 10:46:20 +0100
Subject: PKCS12 APIs with fips 3.0
In-Reply-To: <0a05bfba-5808-1403-21e7-2746dc1966de@wisemo.com>
References: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <c7f86553-85df-f2ef-5413-5a73a1384181@wisemo.com>
 <5ef31738-9181-1581-ecf3-e925ee5ad955@openssl.org>
 <261306f686144c7ae5ad3b1cac78e9b0e34c0b93.camel@t8m.info>
 <ea8a0b8f-da92-b746-b53b-64089116138d@openssl.org>
 <CY4PR18MB1526E864EAF5F3F93A2A76BEF3BB9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <ffa7d73b-5577-dadd-906a-73e6f4b24334@openssl.org>
 <5c783662-a8e7-4fea-ece5-7cb2dafd25ff@wisemo.com>
 <e4c56e9c66ce47e4a8f9c074f6fda38559b73cd2.camel@t8m.info>
 <0a05bfba-5808-1403-21e7-2746dc1966de@wisemo.com>
Message-ID: <952093a0f549489ff30a855915bf46553e9a04e4.camel@t8m.info>

There is unfortunately no simple straightforward answer to this
question. It really depends on the context.

Anyway OpenSSL 3.0 gives you all the flexibility needed.

Tomas

On Thu, 2021-01-28 at 10:24 +0100, Jakob Bohm via openssl-users wrote:
> Does FIPS 140 or the related legal requirements limit the use of
> higher
> level compositions such as PKCS12KDF, when using only validated
> cryptography for the underlying operations?
> 
> On 2021-01-28 09:36, Tomas Mraz wrote:
> > I do not get how you came to this conclusion. The "true" FIPS mode
> > can
> > be easily achieved with OpenSSL 3.0 - either by loading just the
> > fips
> > and base provider, or by loading both default and fips providers
> > but
> > using the "fips=yes" default property (without the "?").
> > 
> > The PKCS12KDF does not work because it is not an FIPS approved KDF
> > algorithm so it cannot really work in the "true" FIPS mode. But IMO
> > this does not mean that PKCS12 keys do not work at all - if you use
> > right (more modern) algoritm based on PBKDF2 to do the password
> > based
> > key derivation, they should work.
> > 
> > That in 1.0.x the PKCS12 worked with the FIPS module with legacy
> > algorithms it only shows that the "true" FIPS mode was not as
> > "true" as
> > you might think. There were some crypto algorithms like the KDFs
> > outside of the FIPS module boundary.
> > 
> > Tomas Mraz
> > 
> > On Thu, 2021-01-28 at 09:26 +0100, Jakob Bohm via openssl-users
> > wrote:
> > > Does that mean that OpenSSL 3.0 will not have a true "FIPS mode"
> > > where
> > > all the non-FIPS algorithms are disabled, but the FIPS-
> > > independent
> > > schemes/protocols in the "default" provider remains available?
> > > 
> > > Remember that in other software systems, such as OpenSSL 1.0.x
> > > and
> > > MS
> > > CryptoAPI, FIPS mode causes all non-validated algorithms to fail
> > > hard,
> > > so all higher level operations are guaranteed to use only FIPS-
> > > validated
> > > crypto.
> > > 
> > > On 2021-01-27 02:01, Dr Paul Dale wrote:
> > > > You could set the default property query to "?fips=yes".  This
> > > > will
> > > > prefer FIPS algorithms over any others but will not prevent
> > > > other
> > > > algorithms from being fetched.
> > > > 
> > > > Pauli
> > > > 
> > > > On 27/1/21 10:47 am, Zeke Evans wrote:
> > > > > I understand that PKCS12 cannot be implemented in the fips
> > > > > provider
> > > > > but I'm looking for a suitable workaround, particularly
> > > > > something
> > > > > that is close to the same behavior as 1.0.2 with the fips 2.0
> > > > > module.
> > > > > 
> > > > > In my case, the default provider is loaded but I am calling
> > > > > EVP_set_default_properties(NULL, "fips=yes").  I can wrap
> > > > > calls
> > > > > to
> > > > > the PKCS12 APIs and momentarily allow non-fips algorithms
> > > > > (ie:
> > > > > "fips=no" or "provider=default") but that prevents the PKCS12
> > > > > implementation from using the crypto implementations in the
> > > > > fips
> > > > > provider.  Is there a property string or some other way to
> > > > > allow
> > > > > PKCS12KDF in the default provider as well as the crypto
> > > > > methods
> > > > > in
> > > > > the fips provider?  I have tried "provider=default,fips=yes"
> > > > > but
> > > > > that
> > > > > doesn't seem to work.
> > > > > 
> > > > > Using the default provider is probably a reasonable
> > > > > workaround
> > > > > for
> > > > > reading in PKCS12 files in order to maintain backwards
> > > > > compatibility.  Is there a recommended method going forward
> > > > > that
> > > > > would allow reading and writing to a key store while only
> > > > > using
> > > > > the
> > > > > fips provider?
> > > > > 
> > > > > Thanks,
> > > > > Zeke Evans
> > > > > Micro Focus
> > > > > 
> > > > > -----Original Message-----
> > > > > From: openssl-users <openssl-users-bounces at openssl.org> On
> > > > > Behalf
> > > > > Of
> > > > > Dr Paul Dale
> > > > > Sent: Tuesday, January 26, 2021 5:22 PM
> > > > > To: openssl-users at openssl.org
> > > > > Subject: Re: PKCS12 APIs with fips 3.0
> > > > > 
> > > > > I'm not even sure that NIST can validate the PKCS#12 KDF.
> > > > > If it can't be validated, it doesn't belong in the FIPS
> > > > > provider.
> > > > > 
> > > > > 
> > > > > Pauli
> > > > > 
> > > > > On 26/1/21 10:48 pm, Tomas Mraz wrote:
> > > > > > On Tue, 2021-01-26 at 11:45 +0000, Matt Caswell wrote:
> > > > > > > On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:
> > > > > > > > On 2021-01-25 17:53, Zeke Evans wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Many of the PKCS12 APIs (ie: PKCS12_create,
> > > > > > > > > PKCS12_parse,
> > > > > > > > > PKCS12_verify_mac) do not work in OpenSSL 3.0 when
> > > > > > > > > using
> > > > > > > > > the fips
> > > > > > > > > provider.  It looks like that is because they try to
> > > > > > > > > load
> > > > > > > > > PKCS12KDF
> > > > > > > > > which is not implemented in the fips provider.  These
> > > > > > > > > were all
> > > > > > > > > working in 1.0.2 with the fips 2.0 module.  Will they
> > > > > > > > > be
> > > > > > > > > supported
> > > > > > > > > in 3.0 with fips?  If not, is there a way for
> > > > > > > > > applications running
> > > > > > > > > in fips approved mode to support the same
> > > > > > > > > functionality
> > > > > > > > > and use
> > > > > > > > > existing stores/files that contain PKCS12 objects?
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > This is an even larger issue: Is OpenSSL 3.x so badly
> > > > > > > > designed that
> > > > > > > > the "providers" need to separately implement every
> > > > > > > > standard
> > > > > > > > or
> > > > > > > > non-standard combination of algorithm invocations?
> > > > > > > > 
> > > > > > > > In a properly abstracted design PKCS12KDF would be
> > > > > > > > implemented by
> > > > > > > > invoking general EVP functions for underlying
> > > > > > > > algorithms,
> > > > > > > > which
> > > > > > > > would in turn invoke the provider versions of those
> > > > > > > > algorithms.
> > > > > > > 
> > > > > > > This is exactly the way it works. The implementation of
> > > > > > > PKCS12KDF
> > > > > > > fetches the underlying digest algorithm using whatever
> > > > > > > providers it
> > > > > > > has available. So, for example, if the PKCS12KDF
> > > > > > > implementation needs
> > > > > > > to use SHA256, then it will fetch an available
> > > > > > > implementation
> > > > > > > for it
> > > > > > > - and that implementation may come from the FIPS provider
> > > > > > > (or
> > > > > > > any
> > > > > > > other provider).
> > > > > > > 
> > > > > > > However, in 3.0, KDFs are themselves fetchable
> > > > > > > cryptographic
> > > > > > > algorithms implemented by providers. The FIPS module
> > > > > > > implements a set
> > > > > > > of KDFs - but PKCS12KDF is not one of them. Its only
> > > > > > > available from
> > > > > > > the default provider.
> > > > > > > 
> > > > > > > So, the summary is, while you can set things up so that
> > > > > > > all
> > > > > > > your
> > > > > > > crypto, including any digests used by the PKCS12KDF, all
> > > > > > > come
> > > > > > > from
> > > > > > > the FIPS provider, there is no getting away from the fact
> > > > > > > that you
> > > > > > > still need to have the default provider loaded in order
> > > > > > > to
> > > > > > > have an
> > > > > > > implementation of the PKCS12KDF itself - which will
> > > > > > > obviously
> > > > > > > be
> > > > > > > outside the module boundary.
> > > > > > > 
> > > > > > > There aren't any current plans to bring the
> > > > > > > implementation of
> > > > > > > PKCS12KDF inside the FIPS module. I don't know whether
> > > > > > > that
> > > > > > > is
> > > > > > > feasible or not.
> > > > > > 
> > > > > > IMO PKCS12KDF should not be in the FIPS module as this is
> > > > > > not a
> > > > > > FIPS
> > > > > > approved KDF algorithm. Besides that KDF should not IMO be
> > > > > > needed for
> > > > > > "modern" PKCS12 files. I need to test that though.
> > > > > > 
> 
> 
> 
> Enjoy
> 
> Jakob
-- 
Tom?? Mr?z
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]



From jb-openssl at wisemo.com  Thu Jan 28 10:08:43 2021
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 28 Jan 2021 11:08:43 +0100
Subject: PKCS12 APIs with fips 3.0
In-Reply-To: <952093a0f549489ff30a855915bf46553e9a04e4.camel@t8m.info>
References: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <c7f86553-85df-f2ef-5413-5a73a1384181@wisemo.com>
 <5ef31738-9181-1581-ecf3-e925ee5ad955@openssl.org>
 <261306f686144c7ae5ad3b1cac78e9b0e34c0b93.camel@t8m.info>
 <ea8a0b8f-da92-b746-b53b-64089116138d@openssl.org>
 <CY4PR18MB1526E864EAF5F3F93A2A76BEF3BB9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <ffa7d73b-5577-dadd-906a-73e6f4b24334@openssl.org>
 <5c783662-a8e7-4fea-ece5-7cb2dafd25ff@wisemo.com>
 <e4c56e9c66ce47e4a8f9c074f6fda38559b73cd2.camel@t8m.info>
 <0a05bfba-5808-1403-21e7-2746dc1966de@wisemo.com>
 <952093a0f549489ff30a855915bf46553e9a04e4.camel@t8m.info>
Message-ID: <03fdaaa9-f746-7ce8-8347-cd0d929109d9@wisemo.com>

If the context does not limit the use of higher level compositions, then
OpenSSL 3.0 provides no way to satisfy the usual requirement that a
product can be set into "FIPS mode" and not invoke the non-validated
lower level algorithms in the "default" provider.

The usual context is to "sell" (give) products to the US Government or
its contractors that have a "FIPS" box-checking procurement requirement.

On 2021-01-28 10:46, Tomas Mraz wrote:
> There is unfortunately no simple straightforward answer to this
> question. It really depends on the context.
> 
> Anyway OpenSSL 3.0 gives you all the flexibility needed.
> 
> Tomas
> 
> On Thu, 2021-01-28 at 10:24 +0100, Jakob Bohm via openssl-users wrote:
>> Does FIPS 140 or the related legal requirements limit the use of
>> higher
>> level compositions such as PKCS12KDF, when using only validated
>> cryptography for the underlying operations?
>>
>> On 2021-01-28 09:36, Tomas Mraz wrote:
>>> I do not get how you came to this conclusion. The "true" FIPS mode
>>> can
>>> be easily achieved with OpenSSL 3.0 - either by loading just the
>>> fips
>>> and base provider, or by loading both default and fips providers
>>> but
>>> using the "fips=yes" default property (without the "?").
>>>
>>> The PKCS12KDF does not work because it is not an FIPS approved KDF
>>> algorithm so it cannot really work in the "true" FIPS mode. But IMO
>>> this does not mean that PKCS12 keys do not work at all - if you use
>>> right (more modern) algoritm based on PBKDF2 to do the password
>>> based
>>> key derivation, they should work.
>>>
>>> That in 1.0.x the PKCS12 worked with the FIPS module with legacy
>>> algorithms it only shows that the "true" FIPS mode was not as
>>> "true" as
>>> you might think. There were some crypto algorithms like the KDFs
>>> outside of the FIPS module boundary.
>>>
>>> Tomas Mraz
>>>
>>> On Thu, 2021-01-28 at 09:26 +0100, Jakob Bohm via openssl-users
>>> wrote:
>>>> Does that mean that OpenSSL 3.0 will not have a true "FIPS mode"
>>>> where
>>>> all the non-FIPS algorithms are disabled, but the FIPS-
>>>> independent
>>>> schemes/protocols in the "default" provider remains available?
>>>>
>>>> Remember that in other software systems, such as OpenSSL 1.0.x
>>>> and
>>>> MS
>>>> CryptoAPI, FIPS mode causes all non-validated algorithms to fail
>>>> hard,
>>>> so all higher level operations are guaranteed to use only FIPS-
>>>> validated
>>>> crypto.
>>>>
>>>> On 2021-01-27 02:01, Dr Paul Dale wrote:
>>>>> You could set the default property query to "?fips=yes".  This
>>>>> will
>>>>> prefer FIPS algorithms over any others but will not prevent
>>>>> other
>>>>> algorithms from being fetched.
>>>>>
>>>>> Pauli
>>>>>
>>>>> On 27/1/21 10:47 am, Zeke Evans wrote:
>>>>>> I understand that PKCS12 cannot be implemented in the fips
>>>>>> provider
>>>>>> but I'm looking for a suitable workaround, particularly
>>>>>> something
>>>>>> that is close to the same behavior as 1.0.2 with the fips 2.0
>>>>>> module.
>>>>>>
>>>>>> In my case, the default provider is loaded but I am calling
>>>>>> EVP_set_default_properties(NULL, "fips=yes").  I can wrap
>>>>>> calls
>>>>>> to
>>>>>> the PKCS12 APIs and momentarily allow non-fips algorithms
>>>>>> (ie:
>>>>>> "fips=no" or "provider=default") but that prevents the PKCS12
>>>>>> implementation from using the crypto implementations in the
>>>>>> fips
>>>>>> provider.  Is there a property string or some other way to
>>>>>> allow
>>>>>> PKCS12KDF in the default provider as well as the crypto
>>>>>> methods
>>>>>> in
>>>>>> the fips provider?  I have tried "provider=default,fips=yes"
>>>>>> but
>>>>>> that
>>>>>> doesn't seem to work.
>>>>>>
>>>>>> Using the default provider is probably a reasonable
>>>>>> workaround
>>>>>> for
>>>>>> reading in PKCS12 files in order to maintain backwards
>>>>>> compatibility.  Is there a recommended method going forward
>>>>>> that
>>>>>> would allow reading and writing to a key store while only
>>>>>> using
>>>>>> the
>>>>>> fips provider?
>>>>>>
>>>>>> Thanks,
>>>>>> Zeke Evans
>>>>>> Micro Focus
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: openssl-users <openssl-users-bounces at openssl.org> On
>>>>>> Behalf
>>>>>> Of
>>>>>> Dr Paul Dale
>>>>>> Sent: Tuesday, January 26, 2021 5:22 PM
>>>>>> To: openssl-users at openssl.org
>>>>>> Subject: Re: PKCS12 APIs with fips 3.0
>>>>>>
>>>>>> I'm not even sure that NIST can validate the PKCS#12 KDF.
>>>>>> If it can't be validated, it doesn't belong in the FIPS
>>>>>> provider.
>>>>>>
>>>>>>
>>>>>> Pauli
>>>>>>
>>>>>> On 26/1/21 10:48 pm, Tomas Mraz wrote:
>>>>>>> On Tue, 2021-01-26 at 11:45 +0000, Matt Caswell wrote:
>>>>>>>> On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:
>>>>>>>>> On 2021-01-25 17:53, Zeke Evans wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Many of the PKCS12 APIs (ie: PKCS12_create,
>>>>>>>>>> PKCS12_parse,
>>>>>>>>>> PKCS12_verify_mac) do not work in OpenSSL 3.0 when
>>>>>>>>>> using
>>>>>>>>>> the fips
>>>>>>>>>> provider.  It looks like that is because they try to
>>>>>>>>>> load
>>>>>>>>>> PKCS12KDF
>>>>>>>>>> which is not implemented in the fips provider.  These
>>>>>>>>>> were all
>>>>>>>>>> working in 1.0.2 with the fips 2.0 module.  Will they
>>>>>>>>>> be
>>>>>>>>>> supported
>>>>>>>>>> in 3.0 with fips?  If not, is there a way for
>>>>>>>>>> applications running
>>>>>>>>>> in fips approved mode to support the same
>>>>>>>>>> functionality
>>>>>>>>>> and use
>>>>>>>>>> existing stores/files that contain PKCS12 objects?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> This is an even larger issue: Is OpenSSL 3.x so badly
>>>>>>>>> designed that
>>>>>>>>> the "providers" need to separately implement every
>>>>>>>>> standard
>>>>>>>>> or
>>>>>>>>> non-standard combination of algorithm invocations?
>>>>>>>>>
>>>>>>>>> In a properly abstracted design PKCS12KDF would be
>>>>>>>>> implemented by
>>>>>>>>> invoking general EVP functions for underlying
>>>>>>>>> algorithms,
>>>>>>>>> which
>>>>>>>>> would in turn invoke the provider versions of those
>>>>>>>>> algorithms.
>>>>>>>>
>>>>>>>> This is exactly the way it works. The implementation of
>>>>>>>> PKCS12KDF
>>>>>>>> fetches the underlying digest algorithm using whatever
>>>>>>>> providers it
>>>>>>>> has available. So, for example, if the PKCS12KDF
>>>>>>>> implementation needs
>>>>>>>> to use SHA256, then it will fetch an available
>>>>>>>> implementation
>>>>>>>> for it
>>>>>>>> - and that implementation may come from the FIPS provider
>>>>>>>> (or
>>>>>>>> any
>>>>>>>> other provider).
>>>>>>>>
>>>>>>>> However, in 3.0, KDFs are themselves fetchable
>>>>>>>> cryptographic
>>>>>>>> algorithms implemented by providers. The FIPS module
>>>>>>>> implements a set
>>>>>>>> of KDFs - but PKCS12KDF is not one of them. Its only
>>>>>>>> available from
>>>>>>>> the default provider.
>>>>>>>>
>>>>>>>> So, the summary is, while you can set things up so that
>>>>>>>> all
>>>>>>>> your
>>>>>>>> crypto, including any digests used by the PKCS12KDF, all
>>>>>>>> come
>>>>>>>> from
>>>>>>>> the FIPS provider, there is no getting away from the fact
>>>>>>>> that you
>>>>>>>> still need to have the default provider loaded in order
>>>>>>>> to
>>>>>>>> have an
>>>>>>>> implementation of the PKCS12KDF itself - which will
>>>>>>>> obviously
>>>>>>>> be
>>>>>>>> outside the module boundary.
>>>>>>>>
>>>>>>>> There aren't any current plans to bring the
>>>>>>>> implementation of
>>>>>>>> PKCS12KDF inside the FIPS module. I don't know whether
>>>>>>>> that
>>>>>>>> is
>>>>>>>> feasible or not.
>>>>>>>
>>>>>>> IMO PKCS12KDF should not be in the FIPS module as this is
>>>>>>> not a
>>>>>>> FIPS
>>>>>>> approved KDF algorithm. Besides that KDF should not IMO be
>>>>>>> needed for
>>>>>>> "modern" PKCS12 files. I need to test that though.
>>>>>>>



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 tm at t8m.info  Thu Jan 28 10:26:10 2021
From: tm at t8m.info (Tomas Mraz)
Date: Thu, 28 Jan 2021 11:26:10 +0100
Subject: PKCS12 APIs with fips 3.0
In-Reply-To: <03fdaaa9-f746-7ce8-8347-cd0d929109d9@wisemo.com>
References: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <c7f86553-85df-f2ef-5413-5a73a1384181@wisemo.com>
 <5ef31738-9181-1581-ecf3-e925ee5ad955@openssl.org>
 <261306f686144c7ae5ad3b1cac78e9b0e34c0b93.camel@t8m.info>
 <ea8a0b8f-da92-b746-b53b-64089116138d@openssl.org>
 <CY4PR18MB1526E864EAF5F3F93A2A76BEF3BB9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <ffa7d73b-5577-dadd-906a-73e6f4b24334@openssl.org>
 <5c783662-a8e7-4fea-ece5-7cb2dafd25ff@wisemo.com>
 <e4c56e9c66ce47e4a8f9c074f6fda38559b73cd2.camel@t8m.info>
 <0a05bfba-5808-1403-21e7-2746dc1966de@wisemo.com>
 <952093a0f549489ff30a855915bf46553e9a04e4.camel@t8m.info>
 <03fdaaa9-f746-7ce8-8347-cd0d929109d9@wisemo.com>
Message-ID: <d409011d53fd4df327024a6adf4e07904674cc76.camel@t8m.info>

This is a purely hypothetical context. Besides, as I said below - the
PKCS12KDF should not be used with modern PKCS12 files. Because it can
be used only with obsolete encryption algorithms anyway - the best one
being 3DES for the encryption and SHA1 for the KDF.

Tomas

On Thu, 2021-01-28 at 11:08 +0100, Jakob Bohm via openssl-users wrote:
> If the context does not limit the use of higher level compositions,
> then
> OpenSSL 3.0 provides no way to satisfy the usual requirement that a
> product can be set into "FIPS mode" and not invoke the non-validated
> lower level algorithms in the "default" provider.
> 
> The usual context is to "sell" (give) products to the US Government
> or
> its contractors that have a "FIPS" box-checking procurement
> requirement.
> 
> On 2021-01-28 10:46, Tomas Mraz wrote:
> > There is unfortunately no simple straightforward answer to this
> > question. It really depends on the context.
> > 
> > Anyway OpenSSL 3.0 gives you all the flexibility needed.
> > 
> > Tomas
> > 
> > On Thu, 2021-01-28 at 10:24 +0100, Jakob Bohm via openssl-users
> > wrote:
> > > Does FIPS 140 or the related legal requirements limit the use of
> > > higher
> > > level compositions such as PKCS12KDF, when using only validated
> > > cryptography for the underlying operations?
> > > 
> > > On 2021-01-28 09:36, Tomas Mraz wrote:
> > > > I do not get how you came to this conclusion. The "true" FIPS
> > > > mode
> > > > can
> > > > be easily achieved with OpenSSL 3.0 - either by loading just
> > > > the
> > > > fips
> > > > and base provider, or by loading both default and fips
> > > > providers
> > > > but
> > > > using the "fips=yes" default property (without the "?").
> > > > 
> > > > The PKCS12KDF does not work because it is not an FIPS approved
> > > > KDF
> > > > algorithm so it cannot really work in the "true" FIPS mode. But
> > > > IMO
> > > > this does not mean that PKCS12 keys do not work at all - if you
> > > > use
> > > > right (more modern) algoritm based on PBKDF2 to do the password
> > > > based
> > > > key derivation, they should work.
> > > > 
> > > > That in 1.0.x the PKCS12 worked with the FIPS module with
> > > > legacy
> > > > algorithms it only shows that the "true" FIPS mode was not as
> > > > "true" as
> > > > you might think. There were some crypto algorithms like the
> > > > KDFs
> > > > outside of the FIPS module boundary.
> > > > 
> > > > Tomas Mraz

-- 
Tom?? Mr?z
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]



From jb-openssl at wisemo.com  Thu Jan 28 11:14:54 2021
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 28 Jan 2021 12:14:54 +0100
Subject: PKCS12 APIs with fips 3.0
In-Reply-To: <d409011d53fd4df327024a6adf4e07904674cc76.camel@t8m.info>
References: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <c7f86553-85df-f2ef-5413-5a73a1384181@wisemo.com>
 <5ef31738-9181-1581-ecf3-e925ee5ad955@openssl.org>
 <261306f686144c7ae5ad3b1cac78e9b0e34c0b93.camel@t8m.info>
 <ea8a0b8f-da92-b746-b53b-64089116138d@openssl.org>
 <CY4PR18MB1526E864EAF5F3F93A2A76BEF3BB9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <ffa7d73b-5577-dadd-906a-73e6f4b24334@openssl.org>
 <5c783662-a8e7-4fea-ece5-7cb2dafd25ff@wisemo.com>
 <e4c56e9c66ce47e4a8f9c074f6fda38559b73cd2.camel@t8m.info>
 <0a05bfba-5808-1403-21e7-2746dc1966de@wisemo.com>
 <952093a0f549489ff30a855915bf46553e9a04e4.camel@t8m.info>
 <03fdaaa9-f746-7ce8-8347-cd0d929109d9@wisemo.com>
 <d409011d53fd4df327024a6adf4e07904674cc76.camel@t8m.info>
Message-ID: <17ffa9df-bdb8-7008-e64b-c25b3fce75d4@wisemo.com>

If that is a hypothetical context, what context is the official design 
goal of the OpenSSL Foundation for their validation effort?

On 2021-01-28 11:26, Tomas Mraz wrote:
> This is a purely hypothetical context. Besides, as I said below - the
> PKCS12KDF should not be used with modern PKCS12 files. Because it can
> be used only with obsolete encryption algorithms anyway - the best one
> being 3DES for the encryption and SHA1 for the KDF.
> 
> Tomas
> 
> On Thu, 2021-01-28 at 11:08 +0100, Jakob Bohm via openssl-users wrote:
>> If the context does not limit the use of higher level compositions,
>> then
>> OpenSSL 3.0 provides no way to satisfy the usual requirement that a
>> product can be set into "FIPS mode" and not invoke the non-validated
>> lower level algorithms in the "default" provider.
>>
>> The usual context is to "sell" (give) products to the US Government
>> or
>> its contractors that have a "FIPS" box-checking procurement
>> requirement.
>>
>> On 2021-01-28 10:46, Tomas Mraz wrote:
>>> There is unfortunately no simple straightforward answer to this
>>> question. It really depends on the context.
>>>
>>> Anyway OpenSSL 3.0 gives you all the flexibility needed.
>>>
>>> Tomas
>>>
>>> On Thu, 2021-01-28 at 10:24 +0100, Jakob Bohm via openssl-users
>>> wrote:
>>>> Does FIPS 140 or the related legal requirements limit the use of
>>>> higher
>>>> level compositions such as PKCS12KDF, when using only validated
>>>> cryptography for the underlying operations?
>>>>
>>>> On 2021-01-28 09:36, Tomas Mraz wrote:
>>>>> I do not get how you came to this conclusion. The "true" FIPS
>>>>> mode
>>>>> can
>>>>> be easily achieved with OpenSSL 3.0 - either by loading just
>>>>> the
>>>>> fips
>>>>> and base provider, or by loading both default and fips
>>>>> providers
>>>>> but
>>>>> using the "fips=yes" default property (without the "?").
>>>>>
>>>>> The PKCS12KDF does not work because it is not an FIPS approved
>>>>> KDF
>>>>> algorithm so it cannot really work in the "true" FIPS mode. But
>>>>> IMO
>>>>> this does not mean that PKCS12 keys do not work at all - if you
>>>>> use
>>>>> right (more modern) algoritm based on PBKDF2 to do the password
>>>>> based
>>>>> key derivation, they should work.
>>>>>
>>>>> That in 1.0.x the PKCS12 worked with the FIPS module with
>>>>> legacy
>>>>> algorithms it only shows that the "true" FIPS mode was not as
>>>>> "true" as
>>>>> you might think. There were some crypto algorithms like the
>>>>> KDFs
>>>>> outside of the FIPS module boundary.
>>>>>
>>>>> Tomas Mraz
> 



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 pauli at openssl.org  Thu Jan 28 11:20:16 2021
From: pauli at openssl.org (Dr Paul Dale)
Date: Thu, 28 Jan 2021 21:20:16 +1000
Subject: PKCS12 APIs with fips 3.0
In-Reply-To: <03fdaaa9-f746-7ce8-8347-cd0d929109d9@wisemo.com>
References: <CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <c7f86553-85df-f2ef-5413-5a73a1384181@wisemo.com>
 <5ef31738-9181-1581-ecf3-e925ee5ad955@openssl.org>
 <261306f686144c7ae5ad3b1cac78e9b0e34c0b93.camel@t8m.info>
 <ea8a0b8f-da92-b746-b53b-64089116138d@openssl.org>
 <CY4PR18MB1526E864EAF5F3F93A2A76BEF3BB9@CY4PR18MB1526.namprd18.prod.outlook.com>
 <ffa7d73b-5577-dadd-906a-73e6f4b24334@openssl.org>
 <5c783662-a8e7-4fea-ece5-7cb2dafd25ff@wisemo.com>
 <e4c56e9c66ce47e4a8f9c074f6fda38559b73cd2.camel@t8m.info>
 <0a05bfba-5808-1403-21e7-2746dc1966de@wisemo.com>
 <952093a0f549489ff30a855915bf46553e9a04e4.camel@t8m.info>
 <03fdaaa9-f746-7ce8-8347-cd0d929109d9@wisemo.com>
Message-ID: <4f494d9b-8119-b934-f679-32bf895dfc33@openssl.org>

Of course OpenSSL 3.0 will support a strict FIPS mode and this will be 
the recommended set up.  By setting the default query to "fips=yes" or 
(better) setting up a library context that has no non-FIPS cryptographic 
implementations and you are in a strictly compliant FIPS mode.

If you want to use the PKCS #12 KDF, then you want something that 
*cannot* currently be FIPS validated --> you are not running in strict 
FIPS mode and need a solution that allows FIPS validated cryptographic 
implementations to be bypassed.


Pauli

On 28/1/21 8:08 pm, Jakob Bohm via openssl-users wrote:
> If the context does not limit the use of higher level compositions, then
> OpenSSL 3.0 provides no way to satisfy the usual requirement that a
> product can be set into "FIPS mode" and not invoke the non-validated
> lower level algorithms in the "default" provider.
> 
> The usual context is to "sell" (give) products to the US Government or
> its contractors that have a "FIPS" box-checking procurement requirement.
> 
> On 2021-01-28 10:46, Tomas Mraz wrote:
>> There is unfortunately no simple straightforward answer to this
>> question. It really depends on the context.
>>
>> Anyway OpenSSL 3.0 gives you all the flexibility needed.
>>
>> Tomas
>>
>> On Thu, 2021-01-28 at 10:24 +0100, Jakob Bohm via openssl-users wrote:
>>> Does FIPS 140 or the related legal requirements limit the use of
>>> higher
>>> level compositions such as PKCS12KDF, when using only validated
>>> cryptography for the underlying operations?
>>>
>>> On 2021-01-28 09:36, Tomas Mraz wrote:
>>>> I do not get how you came to this conclusion. The "true" FIPS mode
>>>> can
>>>> be easily achieved with OpenSSL 3.0 - either by loading just the
>>>> fips
>>>> and base provider, or by loading both default and fips providers
>>>> but
>>>> using the "fips=yes" default property (without the "?").
>>>>
>>>> The PKCS12KDF does not work because it is not an FIPS approved KDF
>>>> algorithm so it cannot really work in the "true" FIPS mode. But IMO
>>>> this does not mean that PKCS12 keys do not work at all - if you use
>>>> right (more modern) algoritm based on PBKDF2 to do the password
>>>> based
>>>> key derivation, they should work.
>>>>
>>>> That in 1.0.x the PKCS12 worked with the FIPS module with legacy
>>>> algorithms it only shows that the "true" FIPS mode was not as
>>>> "true" as
>>>> you might think. There were some crypto algorithms like the KDFs
>>>> outside of the FIPS module boundary.
>>>>
>>>> Tomas Mraz
>>>>
>>>> On Thu, 2021-01-28 at 09:26 +0100, Jakob Bohm via openssl-users
>>>> wrote:
>>>>> Does that mean that OpenSSL 3.0 will not have a true "FIPS mode"
>>>>> where
>>>>> all the non-FIPS algorithms are disabled, but the FIPS-
>>>>> independent
>>>>> schemes/protocols in the "default" provider remains available?
>>>>>
>>>>> Remember that in other software systems, such as OpenSSL 1.0.x
>>>>> and
>>>>> MS
>>>>> CryptoAPI, FIPS mode causes all non-validated algorithms to fail
>>>>> hard,
>>>>> so all higher level operations are guaranteed to use only FIPS-
>>>>> validated
>>>>> crypto.
>>>>>
>>>>> On 2021-01-27 02:01, Dr Paul Dale wrote:
>>>>>> You could set the default property query to "?fips=yes".? This
>>>>>> will
>>>>>> prefer FIPS algorithms over any others but will not prevent
>>>>>> other
>>>>>> algorithms from being fetched.
>>>>>>
>>>>>> Pauli
>>>>>>
>>>>>> On 27/1/21 10:47 am, Zeke Evans wrote:
>>>>>>> I understand that PKCS12 cannot be implemented in the fips
>>>>>>> provider
>>>>>>> but I'm looking for a suitable workaround, particularly
>>>>>>> something
>>>>>>> that is close to the same behavior as 1.0.2 with the fips 2.0
>>>>>>> module.
>>>>>>>
>>>>>>> In my case, the default provider is loaded but I am calling
>>>>>>> EVP_set_default_properties(NULL, "fips=yes").? I can wrap
>>>>>>> calls
>>>>>>> to
>>>>>>> the PKCS12 APIs and momentarily allow non-fips algorithms
>>>>>>> (ie:
>>>>>>> "fips=no" or "provider=default") but that prevents the PKCS12
>>>>>>> implementation from using the crypto implementations in the
>>>>>>> fips
>>>>>>> provider.? Is there a property string or some other way to
>>>>>>> allow
>>>>>>> PKCS12KDF in the default provider as well as the crypto
>>>>>>> methods
>>>>>>> in
>>>>>>> the fips provider?? I have tried "provider=default,fips=yes"
>>>>>>> but
>>>>>>> that
>>>>>>> doesn't seem to work.
>>>>>>>
>>>>>>> Using the default provider is probably a reasonable
>>>>>>> workaround
>>>>>>> for
>>>>>>> reading in PKCS12 files in order to maintain backwards
>>>>>>> compatibility.? Is there a recommended method going forward
>>>>>>> that
>>>>>>> would allow reading and writing to a key store while only
>>>>>>> using
>>>>>>> the
>>>>>>> fips provider?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Zeke Evans
>>>>>>> Micro Focus
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: openssl-users <openssl-users-bounces at openssl.org> On
>>>>>>> Behalf
>>>>>>> Of
>>>>>>> Dr Paul Dale
>>>>>>> Sent: Tuesday, January 26, 2021 5:22 PM
>>>>>>> To: openssl-users at openssl.org
>>>>>>> Subject: Re: PKCS12 APIs with fips 3.0
>>>>>>>
>>>>>>> I'm not even sure that NIST can validate the PKCS#12 KDF.
>>>>>>> If it can't be validated, it doesn't belong in the FIPS
>>>>>>> provider.
>>>>>>>
>>>>>>>
>>>>>>> Pauli
>>>>>>>
>>>>>>> On 26/1/21 10:48 pm, Tomas Mraz wrote:
>>>>>>>> On Tue, 2021-01-26 at 11:45 +0000, Matt Caswell wrote:
>>>>>>>>> On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:
>>>>>>>>>> On 2021-01-25 17:53, Zeke Evans wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Many of the PKCS12 APIs (ie: PKCS12_create,
>>>>>>>>>>> PKCS12_parse,
>>>>>>>>>>> PKCS12_verify_mac) do not work in OpenSSL 3.0 when
>>>>>>>>>>> using
>>>>>>>>>>> the fips
>>>>>>>>>>> provider.? It looks like that is because they try to
>>>>>>>>>>> load
>>>>>>>>>>> PKCS12KDF
>>>>>>>>>>> which is not implemented in the fips provider.? These
>>>>>>>>>>> were all
>>>>>>>>>>> working in 1.0.2 with the fips 2.0 module.? Will they
>>>>>>>>>>> be
>>>>>>>>>>> supported
>>>>>>>>>>> in 3.0 with fips?? If not, is there a way for
>>>>>>>>>>> applications running
>>>>>>>>>>> in fips approved mode to support the same
>>>>>>>>>>> functionality
>>>>>>>>>>> and use
>>>>>>>>>>> existing stores/files that contain PKCS12 objects?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> This is an even larger issue: Is OpenSSL 3.x so badly
>>>>>>>>>> designed that
>>>>>>>>>> the "providers" need to separately implement every
>>>>>>>>>> standard
>>>>>>>>>> or
>>>>>>>>>> non-standard combination of algorithm invocations?
>>>>>>>>>>
>>>>>>>>>> In a properly abstracted design PKCS12KDF would be
>>>>>>>>>> implemented by
>>>>>>>>>> invoking general EVP functions for underlying
>>>>>>>>>> algorithms,
>>>>>>>>>> which
>>>>>>>>>> would in turn invoke the provider versions of those
>>>>>>>>>> algorithms.
>>>>>>>>>
>>>>>>>>> This is exactly the way it works. The implementation of
>>>>>>>>> PKCS12KDF
>>>>>>>>> fetches the underlying digest algorithm using whatever
>>>>>>>>> providers it
>>>>>>>>> has available. So, for example, if the PKCS12KDF
>>>>>>>>> implementation needs
>>>>>>>>> to use SHA256, then it will fetch an available
>>>>>>>>> implementation
>>>>>>>>> for it
>>>>>>>>> - and that implementation may come from the FIPS provider
>>>>>>>>> (or
>>>>>>>>> any
>>>>>>>>> other provider).
>>>>>>>>>
>>>>>>>>> However, in 3.0, KDFs are themselves fetchable
>>>>>>>>> cryptographic
>>>>>>>>> algorithms implemented by providers. The FIPS module
>>>>>>>>> implements a set
>>>>>>>>> of KDFs - but PKCS12KDF is not one of them. Its only
>>>>>>>>> available from
>>>>>>>>> the default provider.
>>>>>>>>>
>>>>>>>>> So, the summary is, while you can set things up so that
>>>>>>>>> all
>>>>>>>>> your
>>>>>>>>> crypto, including any digests used by the PKCS12KDF, all
>>>>>>>>> come
>>>>>>>>> from
>>>>>>>>> the FIPS provider, there is no getting away from the fact
>>>>>>>>> that you
>>>>>>>>> still need to have the default provider loaded in order
>>>>>>>>> to
>>>>>>>>> have an
>>>>>>>>> implementation of the PKCS12KDF itself - which will
>>>>>>>>> obviously
>>>>>>>>> be
>>>>>>>>> outside the module boundary.
>>>>>>>>>
>>>>>>>>> There aren't any current plans to bring the
>>>>>>>>> implementation of
>>>>>>>>> PKCS12KDF inside the FIPS module. I don't know whether
>>>>>>>>> that
>>>>>>>>> is
>>>>>>>>> feasible or not.
>>>>>>>>
>>>>>>>> IMO PKCS12KDF should not be in the FIPS module as this is
>>>>>>>> not a
>>>>>>>> FIPS
>>>>>>>> approved KDF algorithm. Besides that KDF should not IMO be
>>>>>>>> needed for
>>>>>>>> "modern" PKCS12 files. I need to test that though.
>>>>>>>>
> 
> 
> 
> Enjoy
> 
> Jakob

From openssl at openssl.org  Thu Jan 28 13:28:52 2021
From: openssl at openssl.org (OpenSSL)
Date: Thu, 28 Jan 2021 13:28:52 +0000
Subject: OpenSSL version 3.0.0-alpha11 published
Message-ID: <20210128132852.GA11091@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


   OpenSSL version 3.0 alpha 11 released
   =====================================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   OpenSSL 3.0 is currently in alpha.

   OpenSSL 3.0 alpha 11 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-alpha11.tar.gz
      Size: 14104901
      SHA1 checksum:  7c934bab3e310884e97b0f4a53dfe9fb3d97bb76
      SHA256 checksum:  2a18f18df6a7ba33cfcc423b77d93990bf70939c06aa2b599b1eabf6e222ea74

   The checksums were calculated using the following commands:

    openssl sha1 openssl-3.0.0-alpha11.tar.gz
    openssl sha256 openssl-3.0.0-alpha11.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-----

iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAmASt0cACgkQ1enkP335
7ozLXA/9FQJ01swsFc5qzW0+Bn7vu2B4qykmyKhQURuyvR7BAbtiUaRIjaJf9sgY
ah1Rx8Pik8ff4BEnCnPfK2CEo0M1T4A8V94Liqico0JAYabUUMa3rAoy6muQnsMh
0CKdYSKcptWZL9zNEKAuB0WUmAFnaT5fS01/STpsjfb8zfS5YQCSAOZ0UZbjxFM2
Qpx7xxNYBJcaspu6xKcWm+c2nyRBh1eB8kTDtK1s54TVdCRLLO+zFYHZXH0mOdww
N+obyMk+GmD0tylSCMEHuXZzEfYO8fNjTL5gbnmlapdVpxk7vDCkTSiD0cT+dMlU
zZMpXWoVLSTQKlbQuozPAt3Crz2fmmij2+SZRxVKWBbVvmlEqAsFarvNhzuR0T8o
NrtKpKDHc2zEMXfeuRd9Wed/cxxiUe/nRjeh7kQ3K0eSciq0Cc2fSLGGZ/OihWQj
QnGE8a31NPXZnqaugiUktS0xK4lDSvObtSch7hkMbRd/2r7tPoa+iwWlQ1ZVXck9
ZH39sFtX56dbjzVp2d5jqls76O2A8oON4kvW+Q8TPa8uHvojb2ulgvPZcB+SurRE
sRYUzexVVZubMx1xvUIguDtsPeR0etVdWaRvLMYnoeMlfeb/DXR/7xGFvxLIjoEx
TKNGgLSRxdZlnkRyyUWukH9VQLqGmf8DZC+nF1DAkyyjPjJu0XM=
=m6RZ
-----END PGP SIGNATURE-----

From harishvk27 at gmail.com  Thu Jan 28 17:16:39 2021
From: harishvk27 at gmail.com (Harish Kulkarni)
Date: Thu, 28 Jan 2021 22:46:39 +0530
Subject: Default value of a session resumption timeout (300 seconds vs
 7200 seconds)
In-Reply-To: <3bcaee40-5bbe-fa3c-d95f-d1e637d59509@openssl.org>
References: <CY4PR0801MB3650AEA1D1A8F2026A64DC93C9BF9@CY4PR0801MB3650.namprd08.prod.outlook.com>
 <8c5d46e5-4ead-ed3b-1671-3929db78df9d@openssl.org>
 <CAHV7XR4YgaRkA-v9sK_M1AuZtiXiUrrFeCU3dYCq8=kB_oN+Bg@mail.gmail.com>
 <3bcaee40-5bbe-fa3c-d95f-d1e637d59509@openssl.org>
Message-ID: <CAHV7XR74ZN8jq7FXnOAEXz8Xg5uw6kv0yMTNMUbKvtE5iYt_jA@mail.gmail.com>

Hi,

I keep seeing growth in memory usage.. suspecting a leak. Want to disable
reference counting as well as stop caches so that i can isolate the issue.

It's all happening on client side. I will try disabling cache..

Mean while if any other inputs/pointers would be helpful.

-thanks
harish


On Wed, Jan 27, 2021 at 3:32 PM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 26/01/2021 18:13, Harish Kulkarni wrote:
> > Thank you both for bringing this to my attention, your points are
> > invaluable.
> >
> > If this is something which gets set from server on client side. can
> > client override this?. Can i change this to something less and try?. Has
> > anyone tried?.
> >
> > Whats the option in openssl.conf or some other place?.
>
> The session timeout is something entirely controlled by the server. The
> client has no influence on this*. If the server is using session tickets
> for its sessions then it provides a lifetime hint to the client to say
> how long the client can expect the session to be good for. The client
> can query this using SSL_SESSION_get_ticket_lifetime_hint().
>
> On the server the timeout can be configured using SSL_CTX_set_timeout().
> I don't think this is possible to change via openssl.conf.
>
> Matt
>
>
> * Note that the client may be managing a cache of sessions provided by
> servers. That's not something that happens by default in OpenSSL but can
> be configured using SSL_CTX_set_session_cache_mode(). In that case there
> will be separate timeouts associated with the life of the session in the
> client cache. Those timeouts may not be the same as the server's timeouts.
>
> >
> > -thanks
> > harish
> >
> >
> > On Mon, Jan 25, 2021 at 11:08 PM Matt Caswell <matt at openssl.org
> > <mailto:matt at openssl.org>> wrote:
> >
> >
> >
> >     On 23/01/2021 15:22, John Thoe wrote:
> >     > Hi list,
> >     >
> >     > The session reuse question posted on the mailing list earlier
> >     >
> >     (
> https://mta.openssl.org/pipermail/openssl-users/2021-January/013360.html)
> >     > reminded of a somewhat similar question I have.
> >     >
> >     > As per the docs,
> >     >
> >
> https://www.openssl.org/docs/man1.0.2/man3/SSL_get_default_timeout.html,
> >     > it says the default value is 300 seconds for which a session resuse
> >     > will be accepted. The docs say that it is the same for all
> >     > protocols.
> >     >
> >     > However I tried it with my setup where I didn't explicitly set the
> >     > timeout and I am getting 7200 seconds as the default value.
> s_client
> >     > output: TLS session ticket lifetime hint: 7200 (seconds). My client
> >     > openssl.conf has no setting override (not that it should matter
> >     > because this is a server preference). No OpenSSL settings on the
> >     > server have been modified as well.
> >
> >     Looks to me like the docs are wrong. They probably should say 7200.
> >
> >
> >     >
> >     > In ssl/ssl_sess.c#L80, the code matches the document: ss->timeout =
> >     > 60 * 5 + 4;   /* 5 minute timeout by default */ ... (with
> additional
> >     > four seconds?)
> >
> >
> >     This gets set during construction and then later overwritten when we
> >     actually get a new session via "ssl_get_new_session":
> >
> >         /* If the context has a default timeout, use it */
> >         if (s->session_ctx->session_timeout == 0)
> >             ss->timeout = SSL_get_default_timeout(s);
> >         else
> >             ss->timeout = s->session_ctx->session_timeout;
> >
> >     In most cases SSL_get_default_timeout() calls tls1_default_timeout()
> (it
> >     can end up somewhere different for certain protocol versions - but
> all
> >     the different variants are the same!):
> >
> >     long tls1_default_timeout(void)
> >     {
> >         /*
> >          * 2 hours, the 24 hours mentioned in the TLSv1 spec is way too
> >     long for
> >          * http, the cache would over fill
> >          */
> >         return (60 * 60 * 2);
> >     }
> >
> >     60 * 60 * 2 = 7200
> >
> >
> >     Matt
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210128/651e6ffb/attachment-0001.html>

From patrickcaruana at gmail.com  Thu Jan 28 18:34:56 2021
From: patrickcaruana at gmail.com (Patrick Caruana)
Date: Thu, 28 Jan 2021 19:34:56 +0100
Subject: How to build for python on Windows 10
Message-ID: <CAFPzV1SV3-35iX63982NDH-Rn5ZN+rSipbAfbH6MTb+a4j0rUQ@mail.gmail.com>

Hi, I have experience with python but absolutely none with c/c++ so any
help would be greatly appreciated!

I am running python 3.9.1 for windows 10 (x64). I have noticed the openssl
dll files shipped with python (libcrypto-1_1.dll & libssl-1_1.dll) are only
version 1.1.7. I would therefore like to replace these with the latest
versions.

I have been able to successfully build openssl 1.1.9 in windows 10
following the instructions in the release. I am using Microsoft visual
studio 2019 + strawberry perl + nasm. I ran the following config command
using the x64 native tools command prompt for vs 2019:

perl Configure VC-WIN64A

I then run the nmake command. This produces the two dlls I
need: libcrypto-1_1-x64.dll and libssl-1_1-x64.dll

I renamed both files to remove the "-x64" at the end of the name and then
used them to replace the existing old dlls in the python installation.

When I try to import the ssl library in python, I get the error:

ImportError: DLL load failed while importing _ssl: The specified module
could not be found.

I then built openssl for x86, using the x86 native tools command prompt for
vs 2019 and the command:

perl Configure VC-WIN32

I then ran nmake which produced: libcrypto-1_1.dll and libssl-1_1.dll

I replaced the dlls in the python installation with those. When I try and
import the ssl library in python I get: ImportError: DLL load failed while
importing _ssl: %1 is not a valid Win32 application.

I am reasonably certain I need the x64 version of the dlls because  (1) my
python installation is x64 (2) when I used the visual studio dumpbin.exe
tool on the python shipped dlls to inspect the headers they say "x64" in
them (3) the x64 dlls  are a similar size to the ones shipped with python
and the x86 versions are smaller.

I don't know what I am doing wrong and am out of ideas. I was once able to
do this following the above steps for an older version of python. That
version shipped with openssl 1.1.3 and I built the dlls for 1.1.7 and
replaced them and python had no issues. If I recall correctly the perl
configuration commands did not use "VC-WIN32" "VC-WIN64A" but instead used
something different like "x86_x64" and "x64_x86". Is it possible that the
default configuration scripts have changed over these versions such that
the default windows x64 configuration no longer builds openssl in a way
that works with python and I therefore need to use custom settings?

Its quite important for me that I do this as I have a small python based
desktop client app in production and I want to make sure the clients are
always running the latest version of openssl. Thanks for any help!

Below is the output of "perl configdata.pm --dump":

Command line (with current working directory = .):

    C:\Strawberry\perl\bin\perl.exe Configure VC-WIN64A

Perl information:

    C:\Strawberry\perl\bin\perl.exe
    5.32.1 for MSWin32-x64-multi-thread

Enabled features:

    aria
    asm
    async
    autoalginit
    autoerrinit
    autoload-config
    bf
    blake2
    buildtest-c\+\+
    camellia
    capieng
    cast
    chacha
    cmac
    cms
    comp
    ct
    deprecated
    des
    dgram
    dh
    dsa
    dso
    dtls
    dynamic-engine
    ec
    ec2m
    ecdh
    ecdsa
    engine
    err
    filenames
    gost
    hw(-.+)?
    idea
    makedepend
    md4
    mdc2
    multiblock
    nextprotoneg
    pinshared
    ocb
    ocsp
    pic
    poly1305
    posix-io
    psk
    rc2
    rc4
    rdrand
    rfc3779
    rmd160
    scrypt
    seed
    shared
    siphash
    sm2
    sm3
    sm4
    sock
    srp
    srtp
    sse2
    ssl
    static-engine
    stdio
    tests
    threads
    tls
    ts
    ui-console
    whirlpool
    tls1
    tls1-method
    tls1_1
    tls1_1-method
    tls1_2
    tls1_2-method
    tls1_3
    dtls1
    dtls1-method
    dtls1_2
    dtls1_2-method

Disabled features:

    afalgeng                [not-linux] OPENSSL_NO_AFALGENG
    asan                    [default]   OPENSSL_NO_ASAN
    crypto-mdebug           [default]   OPENSSL_NO_CRYPTO_MDEBUG
    crypto-mdebug-backtrace [default]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
    devcryptoeng            [default]   OPENSSL_NO_DEVCRYPTOENG
    ec_nistp_64_gcc_128     [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
    egd                     [default]   OPENSSL_NO_EGD
    external-tests          [default]   OPENSSL_NO_EXTERNAL_TESTS
    fuzz-libfuzzer          [default]   OPENSSL_NO_FUZZ_LIBFUZZER
    fuzz-afl                [default]   OPENSSL_NO_FUZZ_AFL
    heartbeats              [default]   OPENSSL_NO_HEARTBEATS
    md2                     [default]   OPENSSL_NO_MD2 (skip crypto\md2)
    msan                    [default]   OPENSSL_NO_MSAN
    rc5                     [default]   OPENSSL_NO_RC5 (skip crypto\rc5)
    sctp                    [default]   OPENSSL_NO_SCTP
    ssl-trace               [default]   OPENSSL_NO_SSL_TRACE
    ubsan                   [default]   OPENSSL_NO_UBSAN
    unit-test               [default]   OPENSSL_NO_UNIT_TEST
    weak-ssl-ciphers        [default]   OPENSSL_NO_WEAK_SSL_CIPHERS
    zlib                    [default]
    zlib-dynamic            [default]
    ssl3                    [default]   OPENSSL_NO_SSL3
    ssl3-method             [default]   OPENSSL_NO_SSL3_METHOD

Config target attributes:

    AR => "lib",
    ARFLAGS => "/nologo",
    AS => "nasm",
    ASFLAGS => "-g",
    CC => "cl",
    CFLAGS => "/W3 /wd4090 /nologo /O2",
    CPP => "\$(CC) /EP /C",
    HASHBANGPERL => "/usr/bin/env perl",
    LD => "link",
    LDFLAGS => "/nologo /debug",
    MT => "mt",
    MTFLAGS => "-nologo",
    RANLIB => "CODE(0x2602f90)",
    RC => "rc",
    aes_asm_src => "aes_core.c aes_cbc.c vpaes-x86_64.s aesni-x86_64.s
aesni-sha1-x86_64.s aesni-sha256-x86_64.s aesni-mb-x86_64.s",
    aes_obj => "aes_core.o aes_cbc.o vpaes-x86_64.o aesni-x86_64.o
aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o",
    apps_aux_src => "win32_init.c",
    apps_init_src => "../ms/applink.c",
    apps_obj => "win32_init.o",
    aroutflag => "/out:",
    asflags => "-Ox -f win64 -DNEAR",
    asoutflag => "-o ",
    bf_asm_src => "bf_enc.c",
    bf_obj => "bf_enc.o",
    bin_cflags => "/Zi /Fdapp.pdb",
    bin_lflags => "/subsystem:console /opt:ref",
    bn_asm_src => "bn_asm.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s
rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s",
    bn_obj => "bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o",
    bn_ops => "EXPORT_VAR_AS_FN SIXTY_FOUR_BIT",
    build_file => "makefile",
    build_scheme => [ "unified", "windows", "VC-common" ],
    cast_asm_src => "c_enc.c",
    cast_obj => "c_enc.o",
    cflags => "/Gs0 /GF /Gy /MD",
    chacha_asm_src => "chacha-x86_64.s",
    chacha_obj => "chacha-x86_64.o",
    cmll_asm_src => "cmll-x86_64.s cmll_misc.c",
    cmll_obj => "cmll-x86_64.o cmll_misc.o",
    coutflag => "/Fo",
    cppflags => "",
    cpuid_asm_src => "x86_64cpuid.s",
    cpuid_obj => "x86_64cpuid.o",
    defines => [ "OPENSSL_SYS_WIN32", "WIN32_LEAN_AND_MEAN", "UNICODE",
"_UNICODE", "_CRT_SECURE_NO_DEPRECATE", "_WINSOCK_DEPRECATED_NO_WARNINGS",
"OPENSSL_USE_APPLINK" ],
    des_asm_src => "des_enc.c fcrypt_b.c",
    des_obj => "des_enc.o fcrypt_b.o",
    disable => [  ],
    dso_cflags => "/Zi /Fddso.pdb",
    dso_extension => ".dll",
    dso_scheme => "win32",
    ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s",
    ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o",
    enable => [  ],
    ex_libs => "ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib",
    exe_extension => "",
    includes => [  ],
    keccak1600_asm_src => "keccak1600-x86_64.s",
    keccak1600_obj => "keccak1600-x86_64.o",
    ldoutflag => "/out:",
    lflags => "",
    lib_cflags => "/Zi /Fdossl_static.pdb",
    lib_cppflags => "",
    lib_defines => [ "L_ENDIAN" ],
    md5_asm_src => "md5-x86_64.s",
    md5_obj => "md5-x86_64.o",
    modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s",
    modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o",
    module_cflags => "",
    module_cxxflags => "",
    module_ldflags => "/dll",
    mtinflag => "-manifest ",
    mtoutflag => "-outputresource:",
    multilib => "-x64",
    padlock_asm_src => "e_padlock-x86_64.s",
    padlock_obj => "e_padlock-x86_64.o",
    perlasm_scheme => "auto",
    poly1305_asm_src => "poly1305-x86_64.s",
    poly1305_obj => "poly1305-x86_64.o",
    rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s",
    rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o",
    rc5_asm_src => "rc5_enc.c",
    rc5_obj => "rc5_enc.o",
    rcoutflag => "/fo",
    rmd160_asm_src => "",
    rmd160_obj => "",
    sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s
sha1-mb-x86_64.s sha256-mb-x86_64.s",
    sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
sha1-mb-x86_64.o sha256-mb-x86_64.o",
    shared_cflag => "",
    shared_defines => [  ],
    shared_extension => ".dll",
    shared_extension_simple => ".dll",
    shared_ldflag => "/dll",
    shared_rcflag => "",
    shared_target => "win-shared",
    sys_id => "WIN64A",
    thread_defines => [  ],
    thread_scheme => "winthreads",
    unistd => "<unistd.h>",
    uplink_aux_src => "../ms/uplink.c uplink-x86_64.s",
    uplink_obj => "../ms/uplink.o uplink-x86_64.o",
    wp_asm_src => "wp-x86_64.s",
    wp_obj => "wp-x86_64.o",

Recorded environment:

    AR =
    ARFLAGS =
    AS =
    ASFLAGS =
    BUILDFILE =
    CC =
    CFLAGS =
    CPP =
    CPPDEFINES =
    CPPFLAGS =
    CPPINCLUDES =
    CROSS_COMPILE =
    CXX =
    CXXFLAGS =
    HASHBANGPERL =
    LD =
    LDFLAGS =
    LDLIBS =
    MT =
    MTFLAGS =
    OPENSSL_LOCAL_CONFIG_DIR =
    PERL =
    RANLIB =
    RC =
    RCFLAGS =
    RM =
    WINDRES =
    __CNF_CFLAGS =
    __CNF_CPPDEFINES =
    __CNF_CPPFLAGS =
    __CNF_CPPINCLUDES =
    __CNF_CXXFLAGS =
    __CNF_LDFLAGS =
    __CNF_LDLIBS =

Makevars:

    AR              = lib
    ARFLAGS         = /nologo
    AS              = nasm
    ASFLAGS         = -g
    CC              = cl
    CFLAGS          = /W3 /wd4090 /nologo /O2
    CPP             = $(CC) /EP /C
    CPPDEFINES      =
    CPPFLAGS        =
    CPPINCLUDES     =
    CXXFLAGS        =
    HASHBANGPERL    = /usr/bin/env perl
    LD              = link
    LDFLAGS         = /nologo /debug
    LDLIBS          =
    MT              = mt
    MTFLAGS         = -nologo
    PERL            = C:\Strawberry\perl\bin\perl.exe
    RANLIB          = ranlib
    RC              = rc
    RCFLAGS         =

NOTE: These variables only represent the configuration view.  The build file
template may have processed these variables further, please have a look at
the
build file for more exact data:
    makefile

build file:

    makefile

build file templates:

    Configurations\common0.tmpl
    Configurations\windows-makefile.tmpl
    Configurations\common.tmpl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210128/15c3835e/attachment-0001.html>

From thulasi.goriparthi at gmail.com  Thu Jan 28 19:07:18 2021
From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi)
Date: Fri, 29 Jan 2021 00:37:18 +0530
Subject: Encoding of AlgorithmIdentifier with NULL parameters
Message-ID: <CAB7O4Gzqxo7mx7nQDtKf8SRE-OgMYM5FEjBj=T1=rCep06i11A@mail.gmail.com>

I am trying to provide a test certificate generated by
openssl-3.0.0-alpha10 to a third party certificate parser/manager. This
software expects AlgorithmIdentifier to either have parameters or to have
null encoded (05 00) parameters which seems to be missing in the
certificate.

Certificate generated by openssl-3.0.0-alpha10

    0:d=0  hl=4 l=1030 cons: SEQUENCE

    4:d=1  hl=4 l= 752 cons: SEQUENCE

    8:d=2  hl=2 l=   3 cons: cont [ 0 ]

   10:d=3  hl=2 l=   1 prim: INTEGER           :02

   13:d=2  hl=2 l=   1 prim: INTEGER           :01

*   16:d=2  hl=2 l=  11 cons: SEQUENCE          *

*   18:d=3  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption*

*   29:d=2  hl=3 l= 143 cons: *SEQUENCE

   32:d=3  hl=2 l=  11 cons: SET

   34:d=4  hl=2 l=   9 cons: SEQUENCE

   36:d=5  hl=2 l=   3 prim: OBJECT            :countryName

Certificate generated by openssl-1.1.1g

    0:d=0  hl=4 l= 988 cons: SEQUENCE

    4:d=1  hl=4 l= 708 cons: SEQUENCE

    8:d=2  hl=2 l=   3 cons: cont [ 0 ]

   10:d=3  hl=2 l=   1 prim: INTEGER           :02

   13:d=2  hl=2 l=   1 prim: INTEGER           :01

*   16:d=2  hl=2 l=  13 cons: SEQUENCE          *

*   18:d=3  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption*

*   29:d=3  hl=2 l=   0 prim: NULL *

   31:d=2  hl=3 l= 143 cons: SEQUENCE

   34:d=3  hl=2 l=  11 cons: SET

   36:d=4  hl=2 l=   9 cons: SEQUENCE

   38:d=5  hl=2 l=   3 prim: OBJECT            :countryName

>From https://tools.ietf.org/html/rfc5280#section-4.1.1.2, It isn't clear if
NULL parameters can be completely omitted or if it should still have NULL
encoding.

Is this a too stringent check in the third-party s/w or a miss in
openss-3.0.0-alpha10?

Thanks,
Thulasi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210129/aa36e400/attachment.html>

From housley at vigilsec.com  Thu Jan 28 20:04:17 2021
From: housley at vigilsec.com (Russ Housley)
Date: Thu, 28 Jan 2021 15:04:17 -0500
Subject: Encoding of AlgorithmIdentifier with NULL parameters
In-Reply-To: <CAB7O4Gzqxo7mx7nQDtKf8SRE-OgMYM5FEjBj=T1=rCep06i11A@mail.gmail.com>
References: <CAB7O4Gzqxo7mx7nQDtKf8SRE-OgMYM5FEjBj=T1=rCep06i11A@mail.gmail.com>
Message-ID: <5BDD3D81-7514-4249-9C60-3A363EA15A6E@vigilsec.com>

RFC 4055 says:

   The object identifier used to identify the PKCS #1 version 1.5
   signature algorithm with SHA-224 is:

      sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 }

   The object identifier used to identify the PKCS #1 version 1.5
   signature algorithm with SHA-256 is:

      sha256WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 11 }

   The object identifier used to identify the PKCS #1 version 1.5
   signature algorithm with SHA-384 is:

      sha384WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 12 }

   The object identifier used to identify the PKCS #1 version 1.5
   signature algorithm with SHA-512 is:

      sha512WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 13 }

   When any of these four object identifiers appears within an
   AlgorithmIdentifier, the parameters MUST be NULL.  Implementations
   MUST accept the parameters being absent as well as present.

So, when generating the certificate, the NULL ought to be there.

Also, when validating, the code should be forgiving about it not being there.

Russ


> On Jan 28, 2021, at 2:07 PM, Thulasi Goriparthi <thulasi.goriparthi at gmail.com> wrote:
> 
> I am trying to provide a test certificate generated by openssl-3.0.0-alpha10 to a third party certificate parser/manager. This software expects AlgorithmIdentifier to either have parameters or to have null encoded (05 00) parameters which seems to be missing in the certificate.
> 
> Certificate generated by openssl-3.0.0-alpha10
> 
>     0:d=0  hl=4 l=1030 cons: SEQUENCE          
>     4:d=1  hl=4 l= 752 cons: SEQUENCE          
>     8:d=2  hl=2 l=   3 cons: cont [ 0 ]        
>    10:d=3  hl=2 l=   1 prim: INTEGER           :02
>    13:d=2  hl=2 l=   1 prim: INTEGER           :01
>    16:d=2  hl=2 l=  11 cons: SEQUENCE          
>    18:d=3  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
>    29:d=2  hl=3 l= 143 cons: SEQUENCE          
>    32:d=3  hl=2 l=  11 cons: SET               
>    34:d=4  hl=2 l=   9 cons: SEQUENCE          
>    36:d=5  hl=2 l=   3 prim: OBJECT            :countryName
> 
> Certificate generated by openssl-1.1.1g
> 
>     0:d=0  hl=4 l= 988 cons: SEQUENCE          
>     4:d=1  hl=4 l= 708 cons: SEQUENCE          
>     8:d=2  hl=2 l=   3 cons: cont [ 0 ]        
>    10:d=3  hl=2 l=   1 prim: INTEGER           :02
>    13:d=2  hl=2 l=   1 prim: INTEGER           :01
>    16:d=2  hl=2 l=  13 cons: SEQUENCE          
>    18:d=3  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
>    29:d=3  hl=2 l=   0 prim: NULL              
>    31:d=2  hl=3 l= 143 cons: SEQUENCE          
>    34:d=3  hl=2 l=  11 cons: SET               
>    36:d=4  hl=2 l=   9 cons: SEQUENCE          
>    38:d=5  hl=2 l=   3 prim: OBJECT            :countryName
> 
> From https://tools.ietf.org/html/rfc5280#section-4.1.1.2 <https://tools.ietf.org/html/rfc5280#section-4.1.1.2>, It isn't clear if NULL parameters can be completely omitted or if it should still have NULL encoding.
> 
> Is this a too stringent check in the third-party s/w or a miss in openss-3.0.0-alpha10?
> 
> Thanks,
> Thulasi.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210128/2f9c8ad9/attachment-0001.html>

From openssl-users at dukhovni.org  Thu Jan 28 22:25:41 2021
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 28 Jan 2021 17:25:41 -0500
Subject: Encoding of AlgorithmIdentifier with NULL parameters
In-Reply-To: <CAB7O4Gzqxo7mx7nQDtKf8SRE-OgMYM5FEjBj=T1=rCep06i11A@mail.gmail.com>
References: <CAB7O4Gzqxo7mx7nQDtKf8SRE-OgMYM5FEjBj=T1=rCep06i11A@mail.gmail.com>
Message-ID: <YBM55ZkJ9Nc83eBd@straasha.imrryr.org>

On Fri, Jan 29, 2021 at 12:37:18AM +0530, Thulasi Goriparthi wrote:

> I am trying to provide a test certificate generated by
> openssl-3.0.0-alpha10 to a third party certificate parser/manager.
> This software expects AlgorithmIdentifier to either have parameters or
> to have null encoded (05 00) parameters which seems to be missing in
> the certificate.

Indeed it appears that the development branch differs in its output
format from the stable releases, in that the (05 00) NULL parameters
present in the tbsCertificate are missing from the signature block:

    $ OpenSSL_master/bin/openssl req \
        -config <(printf 'distinguished_name = dn\n[dn]\nprompt=yes\n') \
        -new -newkey rsa:1024 -keyout /dev/null \
        -x509 -subj / -days 30 -nodes 2>/dev/null |
        openssl asn1parse
        0:d=0  hl=4 l= 381 cons: SEQUENCE
        4:d=1  hl=3 l= 233 cons: SEQUENCE
        7:d=2  hl=2 l=  20 prim: INTEGER           :58EFB7C8A23DC6F6A16D9C30A9300C285B7E9287
       29:d=2  hl=2 l=  11 cons: SEQUENCE
       31:d=3  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
       42:d=2  hl=2 l=   0 cons: SEQUENCE
       44:d=2  hl=2 l=  30 cons: SEQUENCE
       46:d=3  hl=2 l=  13 prim: UTCTIME           :210128221706Z
       61:d=3  hl=2 l=  13 prim: UTCTIME           :210227221706Z
       76:d=2  hl=2 l=   0 cons: SEQUENCE
       78:d=2  hl=3 l= 159 cons: SEQUENCE
       81:d=3  hl=2 l=  13 cons: SEQUENCE
       83:d=4  hl=2 l=   9 prim: OBJECT            :rsaEncryption
       94:d=4  hl=2 l=   0 prim: NULL
       96:d=3  hl=3 l= 141 prim: BIT STRING
      240:d=1  hl=2 l=  11 cons: SEQUENCE
      242:d=2  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
      253:d=1  hl=3 l= 129 prim: BIT STRING

as compared with e.g. OpenSSL 1.1.1:

    $ OpenSSL_1_1_1/bin/openssl req \
        -config <(printf 'distinguished_name = dn\n[dn]\nprompt=yes\n')
        -new -newkey rsa:1024 -keyout /dev/null \
        -x509 -subj / -days 30 -nodes 2>/dev/null |
        openssl asn1parse
        0:d=0  hl=4 l= 385 cons: SEQUENCE
        4:d=1  hl=3 l= 235 cons: SEQUENCE
        7:d=2  hl=2 l=  20 prim: INTEGER           :72A1C904EDFE1C1F15DF51649A7A9F339A0982CD
       29:d=2  hl=2 l=  13 cons: SEQUENCE
       31:d=3  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
       42:d=3  hl=2 l=   0 prim: NULL
       44:d=2  hl=2 l=   0 cons: SEQUENCE
       46:d=2  hl=2 l=  30 cons: SEQUENCE
       48:d=3  hl=2 l=  13 prim: UTCTIME           :210128222008Z
       63:d=3  hl=2 l=  13 prim: UTCTIME           :210227222008Z
       78:d=2  hl=2 l=   0 cons: SEQUENCE
       80:d=2  hl=3 l= 159 cons: SEQUENCE
       83:d=3  hl=2 l=  13 cons: SEQUENCE
       85:d=4  hl=2 l=   9 prim: OBJECT            :rsaEncryption
       96:d=4  hl=2 l=   0 prim: NULL
       98:d=3  hl=3 l= 141 prim: BIT STRING
      242:d=1  hl=2 l=  13 cons: SEQUENCE
      244:d=2  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
      255:d=2  hl=2 l=   0 prim: NULL
      257:d=1  hl=3 l= 129 prim: BIT STRING

If there isn't yet a Github issue for this, please open one.  It appears
that the code that is actually generating the signature is no longer
encoding explicit NULL parameters for the algorithms in question.

-- 
    Viktor.

From jb-openssl at wisemo.com  Fri Jan 29 02:09:32 2021
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 29 Jan 2021 03:09:32 +0100
Subject: Encoding of AlgorithmIdentifier with NULL parameters
In-Reply-To: <CAB7O4Gzqxo7mx7nQDtKf8SRE-OgMYM5FEjBj=T1=rCep06i11A@mail.gmail.com>
References: <CAB7O4Gzqxo7mx7nQDtKf8SRE-OgMYM5FEjBj=T1=rCep06i11A@mail.gmail.com>
Message-ID: <c717e821-6c2b-5506-e272-10001e79a494@wisemo.com>

Also note that the official ASN.1 declaration for
AlgorithmIdentifier (from X.509 (2012), section 7.2) marks
the parameters field as OPTIONAL, so parsers really should
accept its absence.

However if broken parsers are common (this thread
only found one such parser), maybe it would be
good practice to include the NULL value for compatibility.

AlgorithmIdentifier{ALGORITHM:SupportedAlgorithms} ::= SEQUENCE {
 ??? algorithm ALGORITHM.&id({SupportedAlgorithms}),
 ??? parameters ALGORITHM.&Type({SupportedAlgorithms}{@algorithm}) OPTIONAL,
... }

On 2021-01-28 20:07, Thulasi Goriparthi wrote:
> I am trying to provide a test certificate generated by 
> openssl-3.0.0-alpha10 to a third party certificate parser/manager. 
> This software expects AlgorithmIdentifier to either have parameters or 
> to have null encoded (05 00) parameters which seems to be missing in 
> the certificate.
>
> Certificate generated by openssl-3.0.0-alpha10
>
> ? ??0:d=0? hl=4 l=1030 cons: SEQUENCE
>
> ? ? 4:d=1? hl=4 l= 752 cons: SEQUENCE
>
> ? ? 8:d=2? hl=2 l= ? 3 cons: cont [ 0 ]
>
> ?? 10:d=3? hl=2 l= ? 1 prim: INTEGER ? ? ? ? ? :02
>
> ?? 13:d=2? hl=2 l= ? 1 prim: INTEGER ? ? ? ? ? :01
>
> *?? 16:d=2? hl=2 l=? 11 cons: SEQUENCE *
>
> *?? 18:d=3? hl=2 l= ? 9 prim: OBJECT? ? ? ? ? ? :sha256WithRSAEncryption*
>
> *?? 29:d=2? hl=3 l= 143 cons: *SEQUENCE
>
> ?? 32:d=3? hl=2 l=? 11 cons: SET
>
> ?? 34:d=4? hl=2 l= ? 9 cons: SEQUENCE
>
> ?? 36:d=5? hl=2 l= ? 3 prim: OBJECT? ? ? ? ? ? :countryName
>
>
> Certificate generated by openssl-1.1.1g
>
> ? ??0:d=0? hl=4 l= 988 cons: SEQUENCE
>
> ? ? 4:d=1? hl=4 l= 708 cons: SEQUENCE
>
> ? ? 8:d=2? hl=2 l= ? 3 cons: cont [ 0 ]
>
> ?? 10:d=3? hl=2 l= ? 1 prim: INTEGER ? ? ? ? ? :02
>
> ?? 13:d=2? hl=2 l= ? 1 prim: INTEGER ? ? ? ? ? :01
>
> *?? 16:d=2? hl=2 l=? 13 cons: SEQUENCE *
>
> *?? 18:d=3? hl=2 l= ? 9 prim: OBJECT? ? ? ? ? ? :sha256WithRSAEncryption*
>
> *?? 29:d=3? hl=2 l= ? 0 prim: NULL *
>
> ?? 31:d=2? hl=3 l= 143 cons: SEQUENCE
>
> ?? 34:d=3? hl=2 l=? 11 cons: SET
>
> ?? 36:d=4? hl=2 l= ? 9 cons: SEQUENCE
>
> ?? 38:d=5? hl=2 l= ? 3 prim: OBJECT? ? ? ? ? ? :countryName
>
>
> From https://tools.ietf.org/html/rfc5280#section-4.1.1.2, It isn't 
> clear if NULL parameters can be completely omitted or if it should 
> still have NULL encoding.
>
> Is this a too stringent check in the third-party s/w or a miss in 
> openss-3.0.0-alpha10?
>
> Thanks,
> Thulasi.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210129/90091665/attachment.html>

From uri at ll.mit.edu  Fri Jan 29 02:19:37 2021
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Fri, 29 Jan 2021 02:19:37 +0000
Subject: Encoding of AlgorithmIdentifier with NULL parameters
In-Reply-To: <c717e821-6c2b-5506-e272-10001e79a494@wisemo.com>
References: <CAB7O4Gzqxo7mx7nQDtKf8SRE-OgMYM5FEjBj=T1=rCep06i11A@mail.gmail.com>
 <c717e821-6c2b-5506-e272-10001e79a494@wisemo.com>
Message-ID: <76B9016A-6B60-446E-A2E9-E8AA9D0F9F58@ll.mit.edu>

?OPTIONAL? means the parser must deal with complete absence, not only encoded as ASN.1 NULL.

 

Broken parsers should be fixed.

--

Regards,

Uri

 

There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                     -  C. A. R. Hoare

 

 

From: openssl-users-bounce <openssl-users-bounces at openssl.org> on behalf of openssl-users <openssl-users at openssl.org>
Organization: WiseMo A/S
Reply-To: Jakob Bohm <jb-openssl at wisemo.com>
Date: Thursday, January 28, 2021 at 21:10
To: openssl-users <openssl-users at openssl.org>
Subject: Re: Encoding of AlgorithmIdentifier with NULL parameters

 

Also note that the official ASN.1 declaration for 
AlgorithmIdentifier (from X.509 (2012), section 7.2) marks 
the parameters field as OPTIONAL, so parsers really should 
accept its absence.

However if broken parsers are common (this thread 
only found one such parser), maybe it would be 
good practice to include the NULL value for compatibility.

AlgorithmIdentifier{ALGORITHM:SupportedAlgorithms} ::= SEQUENCE {
    algorithm ALGORITHM.&id({SupportedAlgorithms}),
    parameters ALGORITHM.&Type({SupportedAlgorithms}{@algorithm}) OPTIONAL,
... }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210129/d6561f37/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210129/d6561f37/attachment-0001.bin>

From jb-openssl at wisemo.com  Fri Jan 29 02:38:30 2021
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 29 Jan 2021 03:38:30 +0100
Subject: Encoding of AlgorithmIdentifier with NULL parameters
In-Reply-To: <76B9016A-6B60-446E-A2E9-E8AA9D0F9F58@ll.mit.edu>
References: <CAB7O4Gzqxo7mx7nQDtKf8SRE-OgMYM5FEjBj=T1=rCep06i11A@mail.gmail.com>
 <c717e821-6c2b-5506-e272-10001e79a494@wisemo.com>
 <76B9016A-6B60-446E-A2E9-E8AA9D0F9F58@ll.mit.edu>
Message-ID: <9a82c1f8-b7ac-e05a-cf51-9db449113d78@wisemo.com>

If only one or a few parsers are broken, they need to be fixed.

If many broken parsers have proliferated due to generators
semi-violating DER by not omitting the empty field, that has become the
new reality that generators must deal with.

PKIX arbitrarily limiting serial numbers to 159 bits has created a 
similar unfortunate reality.

On 2021-01-29 03:19, Blumenthal, Uri - 0553 - MITLL wrote:
> ?OPTIONAL? means the parser _must_ deal with complete absence, not only 
> encoded as ASN.1 NULL.
> 
> Broken parsers should be fixed.
> 
> --
> 
> Regards,
> 
> Uri
> 
> //
> 
> /There are two ways to design a system. One is to make is so simple 
> there are obviously no deficiencies./
> 
> /The other is to make it so complex there are no obvious deficiencies./
> 
> /                  
>  ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????-? C. A. R. Hoare/
> 
> *From: *openssl-users-bounce <openssl-users-bounces at openssl.org> on 
> behalf of openssl-users <openssl-users at openssl.org>
> *Organization: *WiseMo A/S
> *Reply-To: *Jakob Bohm <jb-openssl at wisemo.com>
> *Date: *Thursday, January 28, 2021 at 21:10
> *To: *openssl-users <openssl-users at openssl.org>
> *Subject: *Re: Encoding of AlgorithmIdentifier with NULL parameters
> 
> Also note that the official ASN.1 declaration for
> AlgorithmIdentifier (from X.509 (2012), section 7.2) marks
> the parameters field as OPTIONAL, so parsers really should
> accept its absence.
> 
> However if broken parsers are common (this thread
> only found one such parser), maybe it would be
> good practice to include the NULL value for compatibility.
> 
> AlgorithmIdentifier{ALGORITHM:SupportedAlgorithms} ::= SEQUENCE {
>  ??? algorithm ALGORITHM.&id({SupportedAlgorithms}),
>  ??? parameters ALGORITHM.&Type({SupportedAlgorithms}{@algorithm}) OPTIONAL,
> ... }
> 



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 tincanteksup at gmail.com  Fri Jan 29 03:52:45 2021
From: tincanteksup at gmail.com (tincanteksup)
Date: Fri, 29 Jan 2021 03:52:45 +0000
Subject: Encoding of AlgorithmIdentifier with NULL parameters
In-Reply-To: <9a82c1f8-b7ac-e05a-cf51-9db449113d78@wisemo.com>
References: <CAB7O4Gzqxo7mx7nQDtKf8SRE-OgMYM5FEjBj=T1=rCep06i11A@mail.gmail.com>
 <c717e821-6c2b-5506-e272-10001e79a494@wisemo.com>
 <76B9016A-6B60-446E-A2E9-E8AA9D0F9F58@ll.mit.edu>
 <9a82c1f8-b7ac-e05a-cf51-9db449113d78@wisemo.com>
Message-ID: <2cd9ac2b-1c6e-9b75-af2d-e07a21426cce@gmail.com>

"Reality" ought not be defined this way.

On 29/01/2021 02:38, Jakob Bohm via openssl-users wrote:
> If only one or a few parsers are broken, they need to be fixed.
> 
> If many broken parsers have proliferated due to generators
> semi-violating DER by not omitting the empty field, that has become the
> new reality that generators must deal with.
> 
> PKIX arbitrarily limiting serial numbers to 159 bits has created a 
> similar unfortunate reality.
> 
> On 2021-01-29 03:19, Blumenthal, Uri - 0553 - MITLL wrote:
>> ?OPTIONAL? means the parser _must_ deal with complete absence, not 
>> only encoded as ASN.1 NULL.
>>
>> Broken parsers should be fixed.
>>
>> -- 
>>
>> Regards,
>>
>> Uri
>>
>> //
>>
>> /There are two ways to design a system. One is to make is so simple 
>> there are obviously no deficiencies./
>>
>> /The other is to make it so complex there are no obvious deficiencies./
>>
>> / 
>> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????-  
>> C. A. R. Hoare/
>>
>> *From: *openssl-users-bounce <openssl-users-bounces at openssl.org> on 
>> behalf of openssl-users <openssl-users at openssl.org>
>> *Organization: *WiseMo A/S
>> *Reply-To: *Jakob Bohm <jb-openssl at wisemo.com>
>> *Date: *Thursday, January 28, 2021 at 21:10
>> *To: *openssl-users <openssl-users at openssl.org>
>> *Subject: *Re: Encoding of AlgorithmIdentifier with NULL parameters
>>
>> Also note that the official ASN.1 declaration for
>> AlgorithmIdentifier (from X.509 (2012), section 7.2) marks
>> the parameters field as OPTIONAL, so parsers really should
>> accept its absence.
>>
>> However if broken parsers are common (this thread
>> only found one such parser), maybe it would be
>> good practice to include the NULL value for compatibility.
>>
>> AlgorithmIdentifier{ALGORITHM:SupportedAlgorithms} ::= SEQUENCE {
>> ???? algorithm ALGORITHM.&id({SupportedAlgorithms}),
>> ???? parameters ALGORITHM.&Type({SupportedAlgorithms}{@algorithm}) 
>> OPTIONAL,
>> ... }
>>
> 
> 
> 
> Enjoy
> 
> Jakob

From sanarayana at rbbn.com  Fri Jan 29 04:42:47 2021
From: sanarayana at rbbn.com (Narayana, Sunil Kumar)
Date: Fri, 29 Jan 2021 04:42:47 +0000
Subject: <Replacement for RSA_public_decrypt>
In-Reply-To: <SN6PR03MB406197D8639A66FFB244F57CB0BB9@SN6PR03MB4061.namprd03.prod.outlook.com>
References: <SN6PR03MB406197D8639A66FFB244F57CB0BB9@SN6PR03MB4061.namprd03.prod.outlook.com>
Message-ID: <SN6PR03MB4061F9050034C24254ACDD9BB0B99@SN6PR03MB4061.namprd03.prod.outlook.com>

Dear Openssl team,

                While migrating from 1.0.2 to 3.0 we observe that RSA_public_decrypt() API been deprecated in 3.0.
We referred the example provided in man page but we are not clear in generating the initial ?key? required to create CTX.
Please suggest on (key , eng) params to proceed

Also currently we are using PEM_read_bio_RSA_PUBKEY() to generate RSA, I think this might not require in case of EVP, please suggest.

/*
  * NB: assumes key, eng, in, inlen are already set up
  * and that key is an RSA private key
  */
ctx = EVP_PKEY_CTX_new(key, eng);


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: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210129/b04d58ff/attachment.html>

From thulasi.goriparthi at gmail.com  Fri Jan 29 07:37:20 2021
From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi)
Date: Fri, 29 Jan 2021 13:07:20 +0530
Subject: <Replacement for RSA_public_decrypt>
In-Reply-To: <SN6PR03MB4061F9050034C24254ACDD9BB0B99@SN6PR03MB4061.namprd03.prod.outlook.com>
References: <SN6PR03MB406197D8639A66FFB244F57CB0BB9@SN6PR03MB4061.namprd03.prod.outlook.com>
 <SN6PR03MB4061F9050034C24254ACDD9BB0B99@SN6PR03MB4061.namprd03.prod.outlook.com>
Message-ID: <CAB7O4Gzc8sxj1mGN3Ur2UddFX07RGEUL1XvwDBK0wQL_L=DGRw@mail.gmail.com>

Hope, you are referring to
https://www.openssl.org/docs/man1.0.2/man3/EVP_PKEY_encrypt.html

Use PEM_read_bio_PUBKEY to get EVP_PKEY.
eng is for engine reference. If you have no engine, it can be NULL.

Thanks,
Thulasi.

On Fri, 29 Jan 2021 at 10:13, Narayana, Sunil Kumar <sanarayana at rbbn.com>
wrote:

> Dear Openssl team,
>
>                 While migrating from 1.0.2 to 3.0 we observe that
> RSA_public_decrypt() API been deprecated in 3.0.
>
> We referred the example provided in man page but we are not clear in
> generating the initial ?key? required to create CTX.
>
> Please suggest on (key , eng) params to proceed
>
>
>
> Also currently we are using PEM_read_bio_RSA_PUBKEY() to generate RSA, I
> think this might not require in case of EVP, please suggest.
>
>
>
> /*
>
>   * NB: assumes key, eng, in, inlen are already set up
>
>   * and that key is an RSA private key
>
>   */
>
> ctx = EVP_PKEY_CTX_new(key, eng);
>
>
>
>
>
> 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: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210129/03d423d3/attachment-0001.html>

From sanarayana at rbbn.com  Fri Jan 29 11:29:25 2021
From: sanarayana at rbbn.com (Narayana, Sunil Kumar)
Date: Fri, 29 Jan 2021 11:29:25 +0000
Subject: <Replacement for RSA_public_decrypt>
In-Reply-To: <CAB7O4Gzc8sxj1mGN3Ur2UddFX07RGEUL1XvwDBK0wQL_L=DGRw@mail.gmail.com>
References: <SN6PR03MB406197D8639A66FFB244F57CB0BB9@SN6PR03MB4061.namprd03.prod.outlook.com>
 <SN6PR03MB4061F9050034C24254ACDD9BB0B99@SN6PR03MB4061.namprd03.prod.outlook.com>
 <CAB7O4Gzc8sxj1mGN3Ur2UddFX07RGEUL1XvwDBK0wQL_L=DGRw@mail.gmail.com>
Message-ID: <BL0PR03MB4052081A725AE8097EA3F217B0B99@BL0PR03MB4052.namprd03.prod.outlook.com>

Hi Thulasi,

Currently in (1.0.1) we are following the following sequence, which now need to replace with EVP.

Current sequence

//to create RSA pubkey
rsa = PEM_read_bio_RSA_PUBKEY(keybio, NULL, NULL, NULL);  // !!!

//to decrypt using RSA utility
RSA_public_decrypt(len, (unsigned char*)buffer,decrypted,rsa, RSA_PKCS1_PADDING) ;

As you mentioned , if we use PEM_read_bio_PUBKEY to get EVP_PKEY, it will be a pubkey right ? but in order to decrypt as per the example in https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_decrypt_init.html
We need to use an RSA private key

Please suggest.

Regards,
Sunil
From: Thulasi Goriparthi <thulasi.goriparthi at gmail.com>
Sent: 29 January 2021 13:07
To: Narayana, Sunil Kumar <sanarayana at rbbn.com>
Cc: openssl-users at openssl.org
Subject: Re: <Replacement for RSA_public_decrypt>

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

Hope, you are referring to https://www.openssl.org/docs/man1.0.2/man3/EVP_PKEY_encrypt.html<https://protect-us.mimecast.com/s/C67CC73AG3hQlMmXs8mmvp?domain=openssl.org>

Use PEM_read_bio_PUBKEY to get EVP_PKEY.
eng is for engine reference. If you have no engine, it can be NULL.

Thanks,
Thulasi.

On Fri, 29 Jan 2021 at 10:13, Narayana, Sunil Kumar <sanarayana at rbbn.com<mailto:sanarayana at rbbn.com>> wrote:
Dear Openssl team,

                While migrating from 1.0.2 to 3.0 we observe that RSA_public_decrypt() API been deprecated in 3.0.
We referred the example provided in man page but we are not clear in generating the initial ?key? required to create CTX.
Please suggest on (key , eng) params to proceed

Also currently we are using PEM_read_bio_RSA_PUBKEY() to generate RSA, I think this might not require in case of EVP, please suggest.

/*
  * NB: assumes key, eng, in, inlen are already set up
  * and that key is an RSA private key
  */
ctx = EVP_PKEY_CTX_new(key, eng);


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.

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: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210129/2086d642/attachment.html>

From thulasi.goriparthi at gmail.com  Fri Jan 29 11:54:06 2021
From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi)
Date: Fri, 29 Jan 2021 17:24:06 +0530
Subject: <Replacement for RSA_public_decrypt>
In-Reply-To: <BL0PR03MB4052081A725AE8097EA3F217B0B99@BL0PR03MB4052.namprd03.prod.outlook.com>
References: <SN6PR03MB406197D8639A66FFB244F57CB0BB9@SN6PR03MB4061.namprd03.prod.outlook.com>
 <SN6PR03MB4061F9050034C24254ACDD9BB0B99@SN6PR03MB4061.namprd03.prod.outlook.com>
 <CAB7O4Gzc8sxj1mGN3Ur2UddFX07RGEUL1XvwDBK0wQL_L=DGRw@mail.gmail.com>
 <BL0PR03MB4052081A725AE8097EA3F217B0B99@BL0PR03MB4052.namprd03.prod.outlook.com>
Message-ID: <CAB7O4GzFzvwExcHzESEAk=Xd7cFERsdXvYREsW_CYmNragOr-g@mail.gmail.com>

Isn't it obvious to use PEM_read_PrivateKey() or variants to load the
private key as EVP_PKEY
and use EVP_PKEY_decrypt* as specified in
https://www.openssl.org/docs/man1.0.2/man3/EVP_PKEY_decrypt.html ?

Thanks,
Thulasi.

On Fri, 29 Jan 2021 at 16:59, Narayana, Sunil Kumar <sanarayana at rbbn.com>
wrote:

> Hi Thulasi,
>
>
>
> Currently in (1.0.1) we are following the following sequence, which now
> need to replace with EVP.
>
>
>
> *Current sequence*
>
>
>
> //to create RSA pubkey
>
> rsa = PEM_read_bio_RSA_PUBKEY(keybio, NULL, NULL, NULL);  // !!!
>
>
>
> //to decrypt using RSA utility
>
> RSA_public_decrypt(len, (unsigned char*)buffer,decrypted,rsa,
> RSA_PKCS1_PADDING) ;
>
>
>
> As you mentioned , if we use PEM_read_bio_PUBKEY to get EVP_PKEY, it will
> be a pubkey right ? but in order to decrypt as per the example in
> https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_decrypt_init.html
>
> We need to use an RSA private key
>
>
>
> Please suggest.
>
>
>
> Regards,
>
> Sunil
>
> *From:* Thulasi Goriparthi <thulasi.goriparthi at gmail.com>
> *Sent:* 29 January 2021 13:07
> *To:* Narayana, Sunil Kumar <sanarayana at rbbn.com>
> *Cc:* openssl-users at openssl.org
> *Subject:* Re: <Replacement for RSA_public_decrypt>
>
>
> ------------------------------
>
> NOTICE: This email was received from an EXTERNAL sender
> ------------------------------
>
>
>
> Hope, you are referring to
> https://www.openssl.org/docs/man1.0.2/man3/EVP_PKEY_encrypt.html
> <https://protect-us.mimecast.com/s/C67CC73AG3hQlMmXs8mmvp?domain=openssl.org>
>
>
>
> Use PEM_read_bio_PUBKEY to get EVP_PKEY.
>
> eng is for engine reference. If you have no engine, it can be NULL.
>
>
>
> Thanks,
>
> Thulasi.
>
>
>
> On Fri, 29 Jan 2021 at 10:13, Narayana, Sunil Kumar <sanarayana at rbbn.com>
> wrote:
>
> Dear Openssl team,
>
>
>
>                 While migrating from 1.0.2 to 3.0 we observe that
> RSA_public_decrypt() API been deprecated in 3.0.
>
> We referred the example provided in man page but we are not clear in
> generating the initial ?key? required to create CTX.
>
> Please suggest on (key , eng) params to proceed
>
>
>
> Also currently we are using PEM_read_bio_RSA_PUBKEY() to generate RSA, I
> think this might not require in case of EVP, please suggest.
>
>
>
> /*
>
>   * NB: assumes key, eng, in, inlen are already set up
>
>   * and that key is an RSA private key
>
>   */
>
> ctx = EVP_PKEY_CTX_new(key, eng);
>
>
>
>
>
> 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.
>
>
> 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: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210129/c6c032ed/attachment-0001.html>

From sanarayana at rbbn.com  Fri Jan 29 12:16:58 2021
From: sanarayana at rbbn.com (Narayana, Sunil Kumar)
Date: Fri, 29 Jan 2021 12:16:58 +0000
Subject: <Replacement for RSA_public_decrypt>
In-Reply-To: <CAB7O4GzFzvwExcHzESEAk=Xd7cFERsdXvYREsW_CYmNragOr-g@mail.gmail.com>
References: <SN6PR03MB406197D8639A66FFB244F57CB0BB9@SN6PR03MB4061.namprd03.prod.outlook.com>
 <SN6PR03MB4061F9050034C24254ACDD9BB0B99@SN6PR03MB4061.namprd03.prod.outlook.com>
 <CAB7O4Gzc8sxj1mGN3Ur2UddFX07RGEUL1XvwDBK0wQL_L=DGRw@mail.gmail.com>
 <BL0PR03MB4052081A725AE8097EA3F217B0B99@BL0PR03MB4052.namprd03.prod.outlook.com>
 <CAB7O4GzFzvwExcHzESEAk=Xd7cFERsdXvYREsW_CYmNragOr-g@mail.gmail.com>
Message-ID: <BL0PR03MB4052ABD98511FFB7A80B955EB0B99@BL0PR03MB4052.namprd03.prod.outlook.com>

Yeah, it sounds correct. But since it?s an old application code & we are not sure why was it done so, we are little worried to change.
Can you please take a look the attachment which has the complete flow, and provide your views which helps us to change it to  PEM_read_PrivateKey() or variants as you suggested

Regards,
Sunil

From: Thulasi Goriparthi <thulasi.goriparthi at gmail.com>
Sent: 29 January 2021 17:24
To: Narayana, Sunil Kumar <sanarayana at rbbn.com>
Cc: openssl-users at openssl.org
Subject: Re: <Replacement for RSA_public_decrypt>

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

Isn't it obvious to use PEM_read_PrivateKey() or variants to load the private key as EVP_PKEY
and use EVP_PKEY_decrypt* as specified in https://www.openssl.org/docs/man1.0.2/man3/EVP_PKEY_decrypt.html<https://protect-us.mimecast.com/s/pIHaCqx23xSzZMNwiZOok8?domain=openssl.org> ?

Thanks,
Thulasi.

On Fri, 29 Jan 2021 at 16:59, Narayana, Sunil Kumar <sanarayana at rbbn.com<mailto:sanarayana at rbbn.com>> wrote:
Hi Thulasi,

Currently in (1.0.1) we are following the following sequence, which now need to replace with EVP.

Current sequence

//to create RSA pubkey
rsa = PEM_read_bio_RSA_PUBKEY(keybio, NULL, NULL, NULL);  // !!!

//to decrypt using RSA utility
RSA_public_decrypt(len, (unsigned char*)buffer,decrypted,rsa, RSA_PKCS1_PADDING) ;

As you mentioned , if we use PEM_read_bio_PUBKEY to get EVP_PKEY, it will be a pubkey right ? but in order to decrypt as per the example in https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_decrypt_init.html<https://protect-us.mimecast.com/s/iJORCrkY3ki1EBZJTzdO87?domain=openssl.org>
We need to use an RSA private key

Please suggest.

Regards,
Sunil
From: Thulasi Goriparthi <thulasi.goriparthi at gmail.com<mailto:thulasi.goriparthi at gmail.com>>
Sent: 29 January 2021 13:07
To: Narayana, Sunil Kumar <sanarayana at rbbn.com<mailto:sanarayana at rbbn.com>>
Cc: openssl-users at openssl.org<mailto:openssl-users at openssl.org>
Subject: Re: <Replacement for RSA_public_decrypt>

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

Hope, you are referring to https://www.openssl.org/docs/man1.0.2/man3/EVP_PKEY_encrypt.html<https://protect-us.mimecast.com/s/v2osCv2j32i2xk8Vtz2d4K?domain=openssl.org>

Use PEM_read_bio_PUBKEY to get EVP_PKEY.
eng is for engine reference. If you have no engine, it can be NULL.

Thanks,
Thulasi.

On Fri, 29 Jan 2021 at 10:13, Narayana, Sunil Kumar <sanarayana at rbbn.com<mailto:sanarayana at rbbn.com>> wrote:
Dear Openssl team,

                While migrating from 1.0.2 to 3.0 we observe that RSA_public_decrypt() API been deprecated in 3.0.
We referred the example provided in man page but we are not clear in generating the initial ?key? required to create CTX.
Please suggest on (key , eng) params to proceed

Also currently we are using PEM_read_bio_RSA_PUBKEY() to generate RSA, I think this might not require in case of EVP, please suggest.

/*
  * NB: assumes key, eng, in, inlen are already set up
  * and that key is an RSA private key
  */
ctx = EVP_PKEY_CTX_new(key, eng);


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.

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.

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: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210129/54f801ca/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rsasample.txt
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210129/54f801ca/attachment-0001.txt>

From thulasi.goriparthi at gmail.com  Fri Jan 29 12:54:10 2021
From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi)
Date: Fri, 29 Jan 2021 18:24:10 +0530
Subject: <Replacement for RSA_public_decrypt>
In-Reply-To: <BL0PR03MB4052ABD98511FFB7A80B955EB0B99@BL0PR03MB4052.namprd03.prod.outlook.com>
References: <SN6PR03MB406197D8639A66FFB244F57CB0BB9@SN6PR03MB4061.namprd03.prod.outlook.com>
 <SN6PR03MB4061F9050034C24254ACDD9BB0B99@SN6PR03MB4061.namprd03.prod.outlook.com>
 <CAB7O4Gzc8sxj1mGN3Ur2UddFX07RGEUL1XvwDBK0wQL_L=DGRw@mail.gmail.com>
 <BL0PR03MB4052081A725AE8097EA3F217B0B99@BL0PR03MB4052.namprd03.prod.outlook.com>
 <CAB7O4GzFzvwExcHzESEAk=Xd7cFERsdXvYREsW_CYmNragOr-g@mail.gmail.com>
 <BL0PR03MB4052ABD98511FFB7A80B955EB0B99@BL0PR03MB4052.namprd03.prod.outlook.com>
Message-ID: <CAB7O4Gyd+zxUP1QnpYor=amWS5hux7HdwRa=E3HHyhs0gtKULA@mail.gmail.com>

I am not sure why the code you have shared is trying to decrypt the
signature.
If it is done as part of signature verification, don't do this. Use
the actual EVP_PKEY_verify API with corresponding public key.

If you certainly need the decrypted signature, you should do public
encryption with NONE padding.
A Private key is not necessary.

Thanks,
Thulasi

On Fri, 29 Jan 2021 at 17:47, Narayana, Sunil Kumar <sanarayana at rbbn.com>
wrote:

> Yeah, it sounds correct. But since it?s an old application code & we are
> not sure why was it done so, we are little worried to change.
>
> Can you please take a look the attachment which has the complete flow, and
> provide your views which helps us to change it to  PEM_read_PrivateKey()
> or variants as you suggested
>
>
>
> Regards,
>
> Sunil
>
>
>
> *From:* Thulasi Goriparthi <thulasi.goriparthi at gmail.com>
> *Sent:* 29 January 2021 17:24
> *To:* Narayana, Sunil Kumar <sanarayana at rbbn.com>
> *Cc:* openssl-users at openssl.org
> *Subject:* Re: <Replacement for RSA_public_decrypt>
>
>
> ------------------------------
>
> NOTICE: This email was received from an EXTERNAL sender
> ------------------------------
>
>
>
> Isn't it obvious to use PEM_read_PrivateKey() or variants to load the
> private key as EVP_PKEY
>
> and use EVP_PKEY_decrypt* as specified in
> https://www.openssl.org/docs/man1.0.2/man3/EVP_PKEY_decrypt.html
> <https://protect-us.mimecast.com/s/pIHaCqx23xSzZMNwiZOok8?domain=openssl.org>
> ?
>
>
>
> Thanks,
>
> Thulasi.
>
>
>
> On Fri, 29 Jan 2021 at 16:59, Narayana, Sunil Kumar <sanarayana at rbbn.com>
> wrote:
>
> Hi Thulasi,
>
>
>
> Currently in (1.0.1) we are following the following sequence, which now
> need to replace with EVP.
>
>
>
> *Current sequence*
>
>
>
> //to create RSA pubkey
>
> rsa = PEM_read_bio_RSA_PUBKEY(keybio, NULL, NULL, NULL);  // !!!
>
>
>
> //to decrypt using RSA utility
>
> RSA_public_decrypt(len, (unsigned char*)buffer,decrypted,rsa,
> RSA_PKCS1_PADDING) ;
>
>
>
> As you mentioned , if we use PEM_read_bio_PUBKEY to get EVP_PKEY, it will
> be a pubkey right ? but in order to decrypt as per the example in
> https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_decrypt_init.html
> <https://protect-us.mimecast.com/s/iJORCrkY3ki1EBZJTzdO87?domain=openssl.org>
>
> We need to use an RSA private key
>
>
>
> Please suggest.
>
>
>
> Regards,
>
> Sunil
>
> *From:* Thulasi Goriparthi <thulasi.goriparthi at gmail.com>
> *Sent:* 29 January 2021 13:07
> *To:* Narayana, Sunil Kumar <sanarayana at rbbn.com>
> *Cc:* openssl-users at openssl.org
> *Subject:* Re: <Replacement for RSA_public_decrypt>
>
>
> ------------------------------
>
> NOTICE: This email was received from an EXTERNAL sender
> ------------------------------
>
>
>
> Hope, you are referring to
> https://www.openssl.org/docs/man1.0.2/man3/EVP_PKEY_encrypt.html
> <https://protect-us.mimecast.com/s/v2osCv2j32i2xk8Vtz2d4K?domain=openssl.org>
>
>
>
> Use PEM_read_bio_PUBKEY to get EVP_PKEY.
>
> eng is for engine reference. If you have no engine, it can be NULL.
>
>
>
> Thanks,
>
> Thulasi.
>
>
>
> On Fri, 29 Jan 2021 at 10:13, Narayana, Sunil Kumar <sanarayana at rbbn.com>
> wrote:
>
> Dear Openssl team,
>
>
>
>                 While migrating from 1.0.2 to 3.0 we observe that
> RSA_public_decrypt() API been deprecated in 3.0.
>
> We referred the example provided in man page but we are not clear in
> generating the initial ?key? required to create CTX.
>
> Please suggest on (key , eng) params to proceed
>
>
>
> Also currently we are using PEM_read_bio_RSA_PUBKEY() to generate RSA, I
> think this might not require in case of EVP, please suggest.
>
>
>
> /*
>
>   * NB: assumes key, eng, in, inlen are already set up
>
>   * and that key is an RSA private key
>
>   */
>
> ctx = EVP_PKEY_CTX_new(key, eng);
>
>
>
>
>
> 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.
>
>
> 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.
>
>
> 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: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210129/f40fec7d/attachment.html>

From harishvk27 at gmail.com  Sun Jan 31 04:36:06 2021
From: harishvk27 at gmail.com (Harish Kulkarni)
Date: Sun, 31 Jan 2021 10:06:06 +0530
Subject: Default value of a session resumption timeout (300 seconds vs
 7200 seconds)
In-Reply-To: <CAHV7XR74ZN8jq7FXnOAEXz8Xg5uw6kv0yMTNMUbKvtE5iYt_jA@mail.gmail.com>
References: <CY4PR0801MB3650AEA1D1A8F2026A64DC93C9BF9@CY4PR0801MB3650.namprd08.prod.outlook.com>
 <8c5d46e5-4ead-ed3b-1671-3929db78df9d@openssl.org>
 <CAHV7XR4YgaRkA-v9sK_M1AuZtiXiUrrFeCU3dYCq8=kB_oN+Bg@mail.gmail.com>
 <3bcaee40-5bbe-fa3c-d95f-d1e637d59509@openssl.org>
 <CAHV7XR74ZN8jq7FXnOAEXz8Xg5uw6kv0yMTNMUbKvtE5iYt_jA@mail.gmail.com>
Message-ID: <CAHV7XR5UUx1RwXtSvkwaiVQHoCyiTCjupneLY3L+E3kf9pX8TQ@mail.gmail.com>

I am using heaptrack memory analyzer tool to track some memory leak on an
application which is using openssl as CLIENT.
One of the observations is we see constant leak with below backtrace. My
analysis has been this is to do with local caching of sessions, or some
free which we are not doing from applicable layer.

I am doing current code changes to replace reference CRYPTO_ADD with
actually replicating the object which we can referring counting.. so that i
can know at which location we are actually referring to object(s) and then
later not freeing it up.

Is there a easy way in OPENSSL source code to replace reference counts with
actual multiple objects allocation so that it's easy to track memory
usages.. otherwise the code is so complex for newbies to understand and fix
anything.


CRYPTO_malloc in mem.c:350 (libcrypto.so.1.0.0)

asn1_enc_save in tasn_utl.c:179 (libcrypto.so.1.0.0)

asn1_item_ex_d2i in tasn_dec.c:507 (libcrypto.so.1.0.0)

asn1_template_noexp_d2i in tasn_dec.c:719 (libcrypto.so.1.0.0)

asn1_template_ex_d2i in tasn_dec.c:604 (libcrypto.so.1.0.0)

asn1_item_ex_d2i in tasn_dec.c:461 (libcrypto.so.1.0.0)

ASN1_item_ex_d2i in tasn_dec.c:534 (libcrypto.so.1.0.0)

ASN1_item_d2i in tasn_dec.c:154 (libcrypto.so.1.0.0)

ssl3_get_server_certificate in s3_clnt.c:1245 (libssl.so.1.0.0)

ssl3_connect in s3_clnt.c:351 (libssl.so.1.0.0)

ssl23_get_server_hello in s23_clnt.c:832 (libssl.so.1.0.0)

ssl23_connect in s23_clnt.c:231 (libssl.so.1.0.0)

<unresolved function> in ?? (libgioopenssl.so)

<unresolved function> in ?? (libgioopenssl.so)

<unresolved function> in ?? (libgioopenssl.so)

<unresolved function> in ?? (libgio-2.0.so.0)

On Thu, Jan 28, 2021 at 10:46 PM Harish Kulkarni <harishvk27 at gmail.com>
wrote:

> Hi,
>
> I keep seeing growth in memory usage.. suspecting a leak. Want to disable
> reference counting as well as stop caches so that i can isolate the issue.
>
> It's all happening on client side. I will try disabling cache..
>
> Mean while if any other inputs/pointers would be helpful.
>
> -thanks
> harish
>
>
> On Wed, Jan 27, 2021 at 3:32 PM Matt Caswell <matt at openssl.org> wrote:
>
>>
>>
>> On 26/01/2021 18:13, Harish Kulkarni wrote:
>> > Thank you both for bringing this to my attention, your points are
>> > invaluable.
>> >
>> > If this is something which gets set from server on client side. can
>> > client override this?. Can i change this to something less and try?. Has
>> > anyone tried?.
>> >
>> > Whats the option in openssl.conf or some other place?.
>>
>> The session timeout is something entirely controlled by the server. The
>> client has no influence on this*. If the server is using session tickets
>> for its sessions then it provides a lifetime hint to the client to say
>> how long the client can expect the session to be good for. The client
>> can query this using SSL_SESSION_get_ticket_lifetime_hint().
>>
>> On the server the timeout can be configured using SSL_CTX_set_timeout().
>> I don't think this is possible to change via openssl.conf.
>>
>> Matt
>>
>>
>> * Note that the client may be managing a cache of sessions provided by
>> servers. That's not something that happens by default in OpenSSL but can
>> be configured using SSL_CTX_set_session_cache_mode(). In that case there
>> will be separate timeouts associated with the life of the session in the
>> client cache. Those timeouts may not be the same as the server's timeouts.
>>
>> >
>> > -thanks
>> > harish
>> >
>> >
>> > On Mon, Jan 25, 2021 at 11:08 PM Matt Caswell <matt at openssl.org
>> > <mailto:matt at openssl.org>> wrote:
>> >
>> >
>> >
>> >     On 23/01/2021 15:22, John Thoe wrote:
>> >     > Hi list,
>> >     >
>> >     > The session reuse question posted on the mailing list earlier
>> >     >
>> >     (
>> https://mta.openssl.org/pipermail/openssl-users/2021-January/013360.html)
>> >     > reminded of a somewhat similar question I have.
>> >     >
>> >     > As per the docs,
>> >     >
>> >
>> https://www.openssl.org/docs/man1.0.2/man3/SSL_get_default_timeout.html,
>> >     > it says the default value is 300 seconds for which a session
>> resuse
>> >     > will be accepted. The docs say that it is the same for all
>> >     > protocols.
>> >     >
>> >     > However I tried it with my setup where I didn't explicitly set the
>> >     > timeout and I am getting 7200 seconds as the default value.
>> s_client
>> >     > output: TLS session ticket lifetime hint: 7200 (seconds). My
>> client
>> >     > openssl.conf has no setting override (not that it should matter
>> >     > because this is a server preference). No OpenSSL settings on the
>> >     > server have been modified as well.
>> >
>> >     Looks to me like the docs are wrong. They probably should say 7200.
>> >
>> >
>> >     >
>> >     > In ssl/ssl_sess.c#L80, the code matches the document: ss->timeout
>> =
>> >     > 60 * 5 + 4;   /* 5 minute timeout by default */ ... (with
>> additional
>> >     > four seconds?)
>> >
>> >
>> >     This gets set during construction and then later overwritten when we
>> >     actually get a new session via "ssl_get_new_session":
>> >
>> >         /* If the context has a default timeout, use it */
>> >         if (s->session_ctx->session_timeout == 0)
>> >             ss->timeout = SSL_get_default_timeout(s);
>> >         else
>> >             ss->timeout = s->session_ctx->session_timeout;
>> >
>> >     In most cases SSL_get_default_timeout() calls
>> tls1_default_timeout() (it
>> >     can end up somewhere different for certain protocol versions - but
>> all
>> >     the different variants are the same!):
>> >
>> >     long tls1_default_timeout(void)
>> >     {
>> >         /*
>> >          * 2 hours, the 24 hours mentioned in the TLSv1 spec is way too
>> >     long for
>> >          * http, the cache would over fill
>> >          */
>> >         return (60 * 60 * 2);
>> >     }
>> >
>> >     60 * 60 * 2 = 7200
>> >
>> >
>> >     Matt
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210131/e92b5fae/attachment-0001.html>

From levitte at openssl.org  Sun Jan 31 22:21:00 2021
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 31 Jan 2021 23:21:00 +0100
Subject: Encoding of AlgorithmIdentifier with NULL parameters
In-Reply-To: <5BDD3D81-7514-4249-9C60-3A363EA15A6E@vigilsec.com>
References: <CAB7O4Gzqxo7mx7nQDtKf8SRE-OgMYM5FEjBj=T1=rCep06i11A@mail.gmail.com>
 <5BDD3D81-7514-4249-9C60-3A363EA15A6E@vigilsec.com>
Message-ID: <87tuqweoj7.wl-levitte@openssl.org>

This was a good find, thank you all.

It's clearly a bug.  Fix on GitHub, in PR #14030
(https://github.com/openssl/openssl/pull/14030)

Cheers,
Richard

On Thu, 28 Jan 2021 21:04:17 +0100,
Russ Housley wrote:
> 
> [1  <text/plain; us-ascii (quoted-printable)>]
> [2  <text/html; us-ascii (quoted-printable)>]
> RFC 4055 says:
> 
>    The object identifier used to identify the PKCS #1 version 1.5
>    signature algorithm with SHA-224 is:
> 
>       sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 }
> 
>    The object identifier used to identify the PKCS #1 version 1.5
>    signature algorithm with SHA-256 is:
> 
>       sha256WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 11 }
> 
>    The object identifier used to identify the PKCS #1 version 1.5
>    signature algorithm with SHA-384 is:
> 
>       sha384WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 12 }
> 
>    The object identifier used to identify the PKCS #1 version 1.5
>    signature algorithm with SHA-512 is:
> 
>       sha512WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 13 }
> 
>    When any of these four object identifiers appears within an
>    AlgorithmIdentifier, the parameters MUST be NULL.  Implementations
>    MUST accept the parameters being absent as well as present.
> 
> So, when generating the certificate, the NULL ought to be there.
> 
> Also, when validating, the code should be forgiving about it not being there.
> 
> Russ
> 
>     On Jan 28, 2021, at 2:07 PM, Thulasi Goriparthi <thulasi.goriparthi at gmail.com> wrote:
>    
>     I am trying to provide a test certificate generated by openssl-3.0.0-alpha10 to a third party
>     certificate parser/manager. This software expects AlgorithmIdentifier to either have
>     parameters or to have null encoded (05 00) parameters which seems to be missing in the
>     certificate.
>    
>     Certificate generated by openssl-3.0.0-alpha10
>    
>         0:d=0  hl=4 l=1030 cons: SEQUENCE          
>         4:d=1  hl=4 l= 752 cons: SEQUENCE          
>         8:d=2  hl=2 l=   3 cons: cont [ 0 ]        
>        10:d=3  hl=2 l=   1 prim: INTEGER           :02
>        13:d=2  hl=2 l=   1 prim: INTEGER           :01
>        16:d=2  hl=2 l=  11 cons: SEQUENCE          
>        18:d=3  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
>        29:d=2  hl=3 l= 143 cons: SEQUENCE          
>        32:d=3  hl=2 l=  11 cons: SET               
>        34:d=4  hl=2 l=   9 cons: SEQUENCE          
>        36:d=5  hl=2 l=   3 prim: OBJECT            :countryName
>    
>     Certificate generated by openssl-1.1.1g
>    
>         0:d=0  hl=4 l= 988 cons: SEQUENCE          
>         4:d=1  hl=4 l= 708 cons: SEQUENCE          
>         8:d=2  hl=2 l=   3 cons: cont [ 0 ]        
>        10:d=3  hl=2 l=   1 prim: INTEGER           :02
>        13:d=2  hl=2 l=   1 prim: INTEGER           :01
>        16:d=2  hl=2 l=  13 cons: SEQUENCE          
>        18:d=3  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
>        29:d=3  hl=2 l=   0 prim: NULL              
>        31:d=2  hl=3 l= 143 cons: SEQUENCE          
>        34:d=3  hl=2 l=  11 cons: SET               
>        36:d=4  hl=2 l=   9 cons: SEQUENCE          
>        38:d=5  hl=2 l=   3 prim: OBJECT            :countryName
>    
>     From https://tools.ietf.org/html/rfc5280#section-4.1.1.2, It isn't clear if NULL parameters
>     can be completely omitted or if it should still have NULL encoding.
>    
>     Is this a too stringent check in the third-party s/w or a miss in openss-3.0.0-alpha10?
>    
>     Thanks,
>     Thulasi.
> 
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/