New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve key usage checks in internal_verify() and backport fix of issue 1418 to v1.1.1 #12357
Improve key usage checks in internal_verify() and backport fix of issue 1418 to v1.1.1 #12357
Conversation
crypto/x509/x509_vfy.c
Outdated
* and its depth (rather than the depth of the subject). | ||
*/ | ||
if (xs != xi || (ctx->param->flags & X509_V_FLAG_CHECK_SS_SIGNATURE)) { | ||
EVP_PKEY *pkey; | ||
int issuer_depth = n + (xi == xs ? 0 : 1); | ||
int ret = x509_signing_allowed(xi, xs); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps the signing-allowed check should happen only at issuer_depth > 0
? Otherwise an EE-self-signed cert might fail when X509_V_FLAG_CHECK_SS_SIGNATURE
is set, and the keyUsage does not include KU_KEY_CERT_SIGN
. And I think the goal of this PR is allow such EE certs. I don't think that X509_V_FLAG_CHECK_SS_SIGNATURE
should override that policy. Am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good thought not to check key usage restrictions for root certs regardless of X509_V_FLAG_CHECK_SS_SIGNATURE
.
I've done this tentatively, and all tests still pass.
Before suggesting to forward-port ;-) this to the master, I plan to check if this is RFC 5280 compliant...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Indeed a forward-port to master may be appropriate. With this much more focused PR, it was easier to separate heat from chaff and notice this potential anomaly. I'll be happy to review your findings. Good luck.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that my comment wasn't broadly about self-signatures on root CA, but just about the depth 0 case. But presumably if the CA is not at depth 0 then the key usage would be checked anyway to allow it to sign the immediate subject certificate, right? If so, it may be appropriate to just skip the check for the top of chain self-signed TA regardless of the chain depth.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that my comment wasn't broadly about self-signatures on root CA, but just about the depth 0 case.
Sure.
But presumably if the CA is not at depth 0 then the key usage would be checked anyway to allow it to sign the immediate subject certificate, right?
Right. I've just verified with RFC 5280 that checking the keyUsage keyCertSign is demanded during chain validation for a cert of depth n in preparation of checking cert n+1.
Quoting from https://tools.ietf.org/html/rfc5280#section-6.1.4:
(n) If a key usage extension is present, verify that the
keyCertSign bit is set.
Moreover, I understand this in a way that this step is not meant to be done if there is no such cert n+1, i.e., in our special case of a single self-signed (or at least self-issued) EE cert.
So to address my above concern of RFC 5280 compliance, I've slightly adapted the fixup to do the key usage check also for depth 0 certs in case there are further certs in the given chain.
The tests still pass on the adapted version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the other hand from the perspective of RFC5280, a trust anchor is just a public key, trust anchors in the form of self-signed certificates are somewhat outside the model. Verifying self-signatures is therefore in good measure also outside the model. I'll take a closer look at the updated code soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wrote yesterday:
Here is also an interesting further requirement of RFC 5280 regarding verifying cert signatures and key usage checks:
If the keyUsage extension is present, then the subject public key MUST NOT be used to verify signatures on certificates or CRLs unless the corresponding keyCertSign or cRLSign bit is set
On this it looks like we have a problem that I'm currently investigating:
Adding such a tests makes a couple of tests fail.
Therefore in the tentative commit that I did pushed I've commented out the new check !x509_signing_allowed(xi, xs)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It turns out that the mentioned problem with some tests failing was just due to a bug interpreting the result of x509_signing_allowed()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps the signing-allowed check should happen only at
issuer_depth > 0
? Otherwise an EE-self-signed cert might fail whenX509_V_FLAG_CHECK_SS_SIGNATURE
is set, and the keyUsage does not includeKU_KEY_CERT_SIGN
. And I think the goal of this PR is allow such EE certs. I don't think thatX509_V_FLAG_CHECK_SS_SIGNATURE
should override that policy. Am I missing something?
It turns out that we must not skip the signing-allowed check because of the mentioned extra requirement in https://tools.ietf.org/html/rfc5280#section-4.2.1.3:
If the keyUsage extension is present, then the subject public key
MUST NOT be used to verify signatures on certificates or CRLs unless
the corresponding keyCertSign or cRLSign bit is set
So we have to obey any given key usage restrictions.
In case of a self-issued root/EE cert at the end of the chain, what I think we can do in case cert self-signature checks being requested by X509_V_FLAG_CHECK_SS_SIGNATURE
is to simply ignore this request in case the key usage prohibits verifying the (self-)signatures of such a certs. This is what I've now implemented.
Moreover I've re-phrased the existing checks and added some comments for better readability of internal_verify()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As planned above in #12357 (comment) I've meanwhile prepared a 'forward-port' of this last commit in #12375.
@romen, note that I've followed your practice and use as the number of that related PR the value that results from swapping the last two digits 😉
413fed0
to
b4bbb70
Compare
b4bbb70
to
207762f
Compare
crypto/x509/x509_vfy.c
Outdated
* and its depth (rather than the depth of the subject). | ||
* Skip signature check for self-issued certificates unless explicitly | ||
* asked for because it does not add any security and just wastes time. | ||
* We must not verify the signature if key usage prohibits signing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The last of this comment is perhaps now out of place? And I think it meant "Signature verification must fail if...", rather than "We must not verify the signature if...".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my above quote form the RFC 5280, which so far had been neglected:
If the keyUsage extension is present, then the subject public key
MUST NOT be used to verify signatures on certificates or CRLs unless
the corresponding keyCertSign or cRLSign bit is set
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It this clear now, together with the further extended code comments and my new comment in the above review discussion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is my summary of the proposed updated commit:
If a self-issued root/EE cert is last in chain we verify its signature only if X509_V_FLAG_CHECK_SS_SIGNATURE
is requested.
(This has been the semantics so far.)
What this commit changes is:
Even in this case skip the signature verification if the cert key usage prohibits signing.
Make clear that we must check key usage when verifying the signature of
the next cert and we must not verify a signature if key usage forbids it.
Add some comments for making internal_verify() easier to understand.
Update the documentation of X509_V_FLAG_CHECK_SS_SIGNATURE
accordingly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What this commit changes is:
Even in this case skip the signature verification if the cert key usage prohibits signing.
I am not sure that's what users of X509_V_FLAG_CHECK_SS_SIGNATURE
would expect. For a self-signed EE certificate, that does not have kuCertSign
(intended to be a leaf only, not a CA), a self signature check is still possible, and would likely be expected if X509_V_FLAG_CHECK_SS_SIGNATURE
is set. The EE self-signed case is entirely outside the scope of RFC5280. It can only be trusted by being directly bound as fit for a particular service without any CA involvement. So we get to set the verification rules subject to reasonable user expectations and our own documentation. So I'd like to ask for this to be considered more carefully, and a brief rationale written down one way or the other...
Make clear that we must check key usage when verifying the signature of
the next cert and we must not verify a signature if key usage forbids it.
Add some comments for making internal_verify() easier to understand.
Update the documentation ofX509_V_FLAG_CHECK_SS_SIGNATURE
accordingly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The EE self-signed case is entirely outside the scope of RFC5280.
This would surprise me - can you provide a proof for this statement?
I cannot find any such scope restriction on/within RFC 5280.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
5280 has no concept of self-signed EE certificates. It only discusses self-signed CA certificates:
This specification covers two classes of certificates: CA
certificates and end entity certificates. CA certificates may be
further divided into three classes: cross-certificates, self-issued
certificates, and self-signed certificates. Cross-certificates are
CA certificates in which the issuer and subject are different
entities. Cross-certificates describe a trust relationship between
the two CAs. Self-issued certificates are CA certificates in which
the issuer and subject are the same entity. Self-issued certificates
are generated to support changes in policy or operations. Self-
signed certificates are self-issued certificates where the digital
signature may be verified by the public key bound into the
certificate. Self-signed certificates are used to convey a public
key for use to begin certification paths. End entity certificates
are issued to subjects that are not authorized to issue certificates.
And yet, many users of OpenSSL deploy self-signed EE certificates
that are in no way intended to be used as CAs that issue certificates
for other subject names. Furthermore, in 5280 a self-signed CA
certificate is just a public key container. There is no process in
5280 describing verification of such certificates.
When the trust anchor is provided in the form of a self-signed
certificate, this self-signed certificate is not included as part of
the prospective certification path. Information about trust anchors
is provided as inputs to the certification path validation algorithm
(Section 6.1.1).
So my question is what to do about EE self-signed certs. Should the self-signature
be checked when the X509_V_FLAG_CHECK_SS_SIGNATURE
flag is set? I don't
claim to have the definitive answer, but I do claim that no answer is or can be given
in RFC5280. If I'm right, then we need to decide what the right (least-surprise)
answer is for users of OpenSSL. It may well be to ignore keyUsage when verifying EE
self-signatures, and check the signature anyway, when X509_V_FLAG_CHECK_SS_SIGNATURE
is set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I wrote above, the topic is not necessarily self-signed EE certs, but more generally self-issued EE certs.
And the definition of EE certs in 5280 does not refer to self-issued not self-signed. So it does note exclude either of those types of EE certs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Self-issued certs do not carry any explicit indication whether they are self-signed or not.
The only indication that one has is whether their key usage permits self-signing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my view the X509_V_FLAG_CHECK_SS_SIGNATURE
user flag should be interpreted as:
Verify the signature of the last self-issued cert in the chain as self-signature where this is appropriate.
This typically is the case for (self-signed root) CA certs,
but also for certain self-issued EE certs, namely for those where the key usage allows certificate signing.
As mentioned, there are self-issued EE certs where the type of the public key is algorithmically unsuitable for signing (for instance, pure key agreement keys such as DH), so attempting to still verify "self-signature" would fail deeply.
06bfd18
to
7af78e2
Compare
796ec76
to
c4f2f1b
Compare
I think I'm failing to understand something.
I expect a root CA certificate to always have the keyCertSign bit
set, that without that bit, the certificate can not be used to sign
certificates. One of the certificates the root CA signs is the root CA
certificate itself. So if the X509_V_FLAG_CHECK_SS_SIGNATURE is
set, I see no reason why we can't verify that signature.
The other trust anchor we can have is a self signed certificate
that is not a CA. It should not have the keyCertSign bit set,
otherwise it would also need to be a CA. In theory you could say
that it's not allowed to sign it's own certificate, but at the
same time it needs to do it. So here I see no reason that if
someone ensist to check the self signed signature that we check
it, it just might need special code to be able to deal with it.
|
Sure, and this normal case is not in question.
Note that not all self-issued certs are self-signed. |
Note that not all self-issued certs are self-signed.
One such interesting examples is https://tools.ietf.org/html/draft-ietf-curdle-pkix-04#section-10.2
We're talking about checking the self signatures, and that doesn't
have a self signature. The EXFLAG_SS flag should not be set in that
certificate, so there is nothing to check when
X509_V_FLAG_CHECK_SS_SIGNATURE is set.
I guess we can also be in the case where an intermediate CA is in
the trust store, but the root CA is not. We can't check the
signature of the last certificate, because it's not self-signed.
The X509_V_FLAG_CHECK_SS_SIGNATURE flag also doesn't do anything in
that case.
The manual currently says:
B<X509_V_FLAG_CHECK_SS_SIGNATURE> requires verifying the signature
of the last certificate in a chain even when it is a self-signed
(root CA) certificate.
This seems to assume that only self-signed certificates are in the
trust store, so I guess that should be clarified.
PS: That has been published as RFC 8410.
|
Sure, but unless you're also enable partial chains, a chain ending in a self-issued, but not self-signed certificate is incomplete! Self-issued certificates need to have an authority key id that makes it clear that the certificate is not self-signed:
And in any case no one compels users to use the
Not if they present a single-element chain with a self-signed EE key and ask for signature verification. |
Yes. For such a cert directly trusting it would not be sufficient.
Indeed for certs conforming to RFC 5280 one is able to deduce from the SKID and from the AKID (or its non-presence) whether the cert is (meant to be) self-signed.
Right.
Up to this point it is not really clear whether we should be able and be allowed to check the self-signature.
I agree that we should not confuse these two.
That's right (and I suppose we do not need to check for matching signatures beforehand because
Again, I see no good reason to disregard, even on user's request, to ignore the requirement
We could explicitly state in our documentation that the (self-)signature verification may in this case be in violation of that rule. |
I think we need to go over all the cases, because I'm not sure
that we understand each other.
- Normal CA cert, signs an EE cert: The CA cert has a self signature.
We don't check that signature by default, but it can be checked.
The CA cert has the keyCertSign bit, because otherwise it can't
sign the EE cert.
- A non-CA self-signed certificate: It has no keyCertSign, but
it falls outside the scope of RFC5280. If requested, we can check
the signature. Whatever RFC5280 says is irrelevant.
- A not self-signed certificate that's placed in the trust store,
like your self-issued X25519 example. It needs the partial chain
option if it wasn't to be verified successful. It's not
self-signed, so we can't check the signature.
Is there some case I'm missing?
|
I'm answering now on each of @kroeckx's most recent comments; here is the first section of this:
Correct. Yet when the code in the body of
Indeed the |
Yes.
Yes, because such a cert is not even self-issued (which would be required for a self-signed cert).
That sentence is really a bit strange.
The sentence in the manual was not meant to assume this.
What did you mean here? Which information and in which section of it? |
On Sun, Jul 12, 2020 at 06:47:08AM -0700, David von Oheimb wrote:
> PS: That has been published as RFC 8410.
What did you mean here? Which information and in which section of it?
You keep pointing to draft-ietf-curdle-pkix-04, which has been
published as RFC 8410.
|
In particular, the weird cert in <https://tools.ietf.org/html/draft-ietf-curdle-pkix-04#section-10.2> only has an SKID, which misleads `x509v3_cache_extensions()` to set `EXFLAG_SS`.
I would argue that that's a bug in the RFC 8410 and that you file an
errata.
|
Maybe this is needed, but only as far as the last cert in a chain is concerned,
I guess you meant a root CA cert, which signs a intermediate CA cert or EE cert.
At least this is what typically can be assumed for root CA certs.
Right (assuming we are talking about a root CA cert, which could also sign an intermediate CA cert rather than an EE cert).
In other words, a self-signed EE cert.
Well, it must not have keyCertSign, according to https://tools.ietf.org/html/rfc5280#section-4.2.1.3:
So in case the keyCertSign bit is still set for a non-CA cert the cert is non-conforming.
I still do not buy these statements until I am given a compelling argument for their validity.
I guess you mean an /EE/ cert that is not self-signed.
Well, right, but, as explained earlier today (#12357 (comment)) there are various situations where the code cannot be /sure/ if a cert is meant to be self-signed (unless it does the actual verification).
Yes, even restricting ourselves to the last cert in a chain, from a logical (decision tree) perspective the following case is missing: A not self-signed EE certificate that's not placed in the trust store.
|
Ah, right, thanks for that hint! |
Good suggestion - done at https://www.rfc-editor.org/errata/eid6229 |
So are we just talking about what should happen when we see such
an invalid certificate? One that is detected as self-signed, but
can't be self-signed because the the key type doesn't support
signing? The X25519 certificat being an example.
For such certicates, I think there are 3 options:
1) Always reject it, it's clearly an invalid certificate
2) Reject it when they ask for the self signature to be checked
3) Always accept it
I think you're arguing for 3), while I think we should do 1)
|
The scope of our discussion is wider, namely how to handle the case that a certificate at the end of a chain appears to be self-signed (and typically is in fact self-signed) and So the problem arises also for valid/well-formed/conforming certificates that are actually self-signed and have a keyUsage extension that does not include keyCertSign. The typical - an perfectly legitimate - use case is a directly trusted self-signed EE cert (i.e., one that is not issued by a CA) for a key that supports signing. For technical reasons it must bear a signature, and thus usually a self-signature is used, while the cA flag and the keyCertSign key usage bit is not set (in order to prevent the cert from being interpreted as a CA cert). If no key usage extension is given the problem does not arise because then implicitly all key usages are allowed. Yet the cert (self-)issuer may want to make sure that the cert key use is restricted (e.g., to digitalSignature). As I wrote yesterday (#12357 (comment)) in such a situation there are the following possibilities (where I added on case describing the status quo):
|
Maybe it males (some) sense to add one more flag - X509_IGNORE_SS_KU? Yes, it is over-engineering, I see... |
My take is that a trusted chain consisting of exactly one self-issued certificate as its own trust-anchor that has keyUsage without certSign and yet is actually signed by the same key, is so far outside the scope of RFC5280 or any standard PKI model, that perhaps the right thing to do is what the user asked us to do, which is check the certificate signature as requested. This supports the creation of self-signed certs in which keyUsage explicitly disavows certSign, and yet their self signature can be checked. Ultimately however, this is rather a corner case, and we're in bikeshedding territory. If there's some support for David's position, I can back off... |
c4f2f1b
to
8a68267
Compare
I've just done this tentatively. |
…k_issued() Move check that cert signing is allowed from x509v3_cache_extensions() to where it belongs: internal_verify(), generalize it for proxy cert signing. Correct and simplify check_issued(), now checking self-issued (not: self-signed). Add test case to 25-test_verify.t that demonstrates successful fix. As prerequisites, this adds the static function check_sig_alg_match() and the internal functions x509_likely_issued() and x509_signing_allowed(). This is a backport of the core of PR openssl#10587. Fixes openssl#1418
8a68267
to
3fe1a36
Compare
If a presumably self-signed cert is last in chain we verify its signature only if X509_V_FLAG_CHECK_SS_SIGNATURE is set. Upon this request we do the signature verification, but not in case it is a (non-conforming) self-issued CA certificate with a key usage extension that does not include keyCertSign. Make clear when we must verify the signature of a certificate and when we must adhere to key usage restrictions of the 'issuing' cert. Add some comments for making internal_verify() easier to understand. Update the documentation of X509_V_FLAG_CHECK_SS_SIGNATURE accordingly.
3fe1a36
to
b83033c
Compare
@vdukhovni and @kroeckx, during a very good discussion this morning with my colleague @HBrock https://tools.ietf.org/html/rfc6818#section-2 says
So you are right in the sense that for self-issued and self-signed certificates On the other hand, for CA certs that are self-issued and supposedly self-signed we are bound to RFC 5280 So for our implementation of |
b83033c
to
0090665
Compare
Due to this new insight I've updated the proposed solution as follows. In the commit message I write:
The respective section in
and I've updated the documentation to:
|
0090665
to
46294ca
Compare
Maybe I am confused but what is the non-conforming CA case really about - such an invalid CA certificate would not be able to verify any other certificate signature anyway so failing the self-signature check with X509_V_FLAG_CHECK_SS_SIGNATURE is expected and does not warrant any special handling. |
So far the implementation of The case that a CA cert is non-conforming because it key usage does not allow keyCertSign is of course just a corner case.
There is also the general question what to do with certs that are not RFC 5280 compliant for various reasons, |
This PR has developed into two parts:
@vdukhovni, is it realistic that you can approve this PR by tomorrow, after which I'll be on vacation for two weeks? |
I've approved the #12375 as I think that change in the end is pretty uncontroversial. For this one I'd leave the approval on Viktor. |
Thanks Tomáš! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, you've convinced me. And I reviewed the backport and agree with it.
This pull request is ready to merge |
…k_issued() Move check that cert signing is allowed from x509v3_cache_extensions() to where it belongs: internal_verify(), generalize it for proxy cert signing. Correct and simplify check_issued(), now checking self-issued (not: self-signed). Add test case to 25-test_verify.t that demonstrates successful fix. As prerequisites, this adds the static function check_sig_alg_match() and the internal functions x509_likely_issued() and x509_signing_allowed(). This is a backport of the core of PR #10587. Fixes #1418 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from #12357)
If a presumably self-signed cert is last in chain we verify its signature only if X509_V_FLAG_CHECK_SS_SIGNATURE is set. Upon this request we do the signature verification, but not in case it is a (non-conforming) self-issued CA certificate with a key usage extension that does not include keyCertSign. Make clear when we must verify the signature of a certificate and when we must adhere to key usage restrictions of the 'issuing' cert. Add some comments for making internal_verify() easier to understand. Update the documentation of X509_V_FLAG_CHECK_SS_SIGNATURE accordingly. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from #12357)
Merged - glad that also this (extended) backport of the fix for #1418 is finally in. |
@@ -800,12 +833,23 @@ static int no_check(const X509_PURPOSE *xp, const X509 *x, int ca) | |||
* These are: | |||
* 1. Check issuer_name(subject) == subject_name(issuer) | |||
* 2. If akid(subject) exists check it matches issuer | |||
* 3. If key_usage(issuer) exists check it supports certificate signing | |||
* 3. Check that issuer public key algorithm matches subject signature algorithm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi ,I think your changes are great.
But what is the basis for this change? Is there a regulation in some FRC?
Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your comment and question.
The basis for this additional check is the observation that in order to be able to sign the subject cert, the public key of the candidate issuer cert must have a matching type.
If it does not match, in particular it does not make sense to select the candidate issuer cert during chain building:
When later trying to verify the signature during chain verification, that verification will certainly fail, so the chain building reached a dead end. Since moreover the chain building implementation does not backtrack, the whole target cert verification would fail for an inadequate reason. This happened for the example referred to in #1418.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is simply a sanity check. There is no point in adding to the chain an issuer that could not possibly sign the subject certificate. Unfortunately it was incorrectly implemented in this PR as a RSA key can create RSA-PSS signatures. This is now fixed in the repository with commit c2fc111
* Update external/openssl from branch 'build-tools' to 8c346234bb495fdae254bfdd46e6e267624d404c - Merge "Merge tag 'OpenSSL_1_1_1i' for Python and cmdline tool" into build-tools - Merge tag 'OpenSSL_1_1_1i' for Python and cmdline tool Upstream python does not support boringssl, so bring back openssl, but only for host python. See https://www.python.org/dev/peps/pep-0644/ for some discussion upstream. Secondarily, the build system also uses the `openssl` command line tool during some actions, so this will allow us to use a prebuilt for that rather than an arbitrary version from the host. Boringssl does not provide a command line tool. Actual build rules will follow in another CL. Bug: 173151817 Change-Id: Idf1a125071c422b2f18d085eb73d01fc40ac17f2 - Prepare for 1.1.1i release Reviewed-by: Richard Levitte <levitte@openssl.org> - Update copyright year Reviewed-by: Richard Levitte <levitte@openssl.org> - Update CHANGES and NEWS for new release Reviewed-by: Richard Levitte <levitte@openssl.org> - Add a test for encoding/decoding using an invalid ASN.1 Template If you have a CHOICE type that it must use explicit tagging - otherwise the template is invalid. We add tests for this. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> - Add a test for GENERAL_NAME_cmp Based on a boringssl test contributed by David Benjamin Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> - Complain if we are attempting to encode with an invalid ASN.1 template It never makes sense for multi-string or CHOICE types to have implicit tagging. If we have a template that uses the in this way then we should immediately fail. Thanks to David Benjamin from Google for reporting this issue. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> - Check that multi-strings/CHOICE types don't use implicit tagging It never makes sense for multi-string or CHOICE types to use implicit tagging since the content would be ambiguous. It is an error in the template if this ever happens. If we detect it we should stop parsing. Thanks to David Benjamin from Google for reporting this issue. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> - Correctly compare EdiPartyName in GENERAL_NAME_cmp() If a GENERAL_NAME field contained EdiPartyName data then it was incorrectly being handled as type "other". This could lead to a segmentation fault. Many thanks to David Benjamin from Google for reporting this issue. CVE-2020-1971 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> - DirectoryString is a CHOICE type and therefore uses explicit tagging EDIPartyName has 2 fields that use a DirectoryString. However they were marked as implicit tagging - which is not correct for a CHOICE type. Additionally the partyName field was marked as Optional when, according to RFC5280 it is not. Many thanks to github user @filipnavara for reporting this issue. Also to David Benjamin from Google who independently identified and reported it. Fixes #6859 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> - CHANGES: Move misplaced change item Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13605) - x509_vfy.c: Restore rejection of expired trusted (root) certificate The certificate path validation procedure specified in RFC 5280 does not include checking the validity period of the trusted (root) certificate. Still it is common good practice to perform this check. Also OpenSSL did this until version 1.1.1h, yet commit e2590c3a162eb118c36b09c2168164283aa099b4 accidentally killed it. The current commit restores the previous behavior. It also removes the cause of that bug, namely counter-intuitive design of the internal function check_issued(), which was complicated by checks that actually belong to some other internal function, namely find_issuer(). Moreover, this commit adds a regression check and proper documentation of the root cert validity period check feature, which had been missing so far. Fixes #13471 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13585) - Configuration: darwin64-arm64-cc for Apple silicon Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12369) - Fix comment in do_dtls1_write() This code started off as a copy of ssl3_write_bytes(), and the comment was not updated with the implementation. Reported by yangyangtiantianlonglong in #13518 Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13566) (cherry picked from commit 70cae332a2c200087605f94cdccfee80c9380fbf) - Turn on Github CI - backport improved ci.yml to 1.1.1 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13586) - aes/asm/aesv8-armx.pl: avoid 32-bit lane assignment in CTR mode ARM Cortex-A57 and Cortex-A72 cores running in 32-bit mode are affected by silicon errata #1742098 [0] and #1655431 [1], respectively, where the second instruction of a AES instruction pair may execute twice if an interrupt is taken right after the first instruction consumes an input register of which a single 32-bit lane has been updated the last time it was modified. This is not such a rare occurrence as it may seem: in counter mode, only the least significant 32-bit word is incremented in the absence of a carry, which makes our counter mode implementation susceptible to these errata. So let's shuffle the counter assignments around a bit so that the most recent updates when the AES instruction pair executes are 128-bit wide. [0] ARM-EPM-049219 v23 Cortex-A57 MPCore Software Developers Errata Notice [1] ARM-EPM-012079 v11.0 Cortex-A72 MPCore Software Developers Errata Notice Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13571) (cherry picked from commit 26217510d21cd4d5928db8bff41c6756a7c7a636) - Update bio_ok.c CLA: trivial Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13515) (cherry picked from commit a614af95531dd9f168aa4b71bd1195b4fdfe1794) - rsa_test: add return value check Fixes #13361 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13362) (cherry picked from commit 93c87f745d5694b829d5b52d371d478b063a1fba) - Verification zero-length content in S/MIME format Fixes #13082 Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/13106) - Correct description of BN_mask_bits CLA: trivial Correct right shift to left shift. Pseudo code `a&=~((~0)>>n)` means "get higher n-bits of a", but actually crypto lib gives lower n-bits. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12727) (cherry picked from commit b6ef3c7089e887427cde8c550e28211dc0c22dd1) - Unify ssl3_get_cipher_by_std_name() implementation The handling for the SCSVs was the same as for regular ciphers; just merge them into the same table-driven handler. Reviewed-by: Paul Dale <paul.dale@oracle.com> (cherry picked from commit 231849bc9ca69dfd3adf40821421d8e2d804d8e8) (Merged from https://github.com/openssl/openssl/pull/13280) - optimise ssl3_get_cipher_by_std_name() Return immediately on matched cipher. Without this patch the code only breaks out of the inner for loop, meaning for a matched TLS13 cipher the code will still loop through 160ish SSL3 ciphers. CLA: trivial Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (cherry picked from commit d93bded6aa2852e681de2ed76fb43c415687af68) Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/13280) - crypto/poly1305/asm: fix armv8 pointer authentication PAC pointer authentication signs the return address against the value of the stack pointer, to prevent stack overrun exploits from corrupting the control flow. However, this requires that the AUTIASP is issued with SP holding the same value as it held when the PAC value was generated. The Poly1305 armv8 code got this wrong, resulting in crashes on PAC capable hardware. Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13256) (cherry picked from commit fcf6e9d056162d5af64c6f7209388a5c3be2ce57) - Ensure we raise SSLfatal on error We were missing a call to SSLfatal. A comment claimed that we had already called it - but that is incorrect. Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/13230) - Allow to continue on UNABLE_TO_VERIFY_LEAF_SIGNATURE This unifies the behaviour of a single certificate with an unknown CA certificate with a self-signed certificate. The user callback can mask that error to retrieve additional error information. So the user application can decide to abort the connection instead to be forced by openssl. This change in behaviour is backward compatible as user callbacks who don't want to ignore UNABLE_TO_VERIFY_LEAF_SIGNATURE will still abort the connection by default. CLA: trivial Fixes #11297 Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11359) - Fix aarch64 static linking into shared libraries (see issue #10842 and pull request #11464) Cherry-pick of https://github.com/openssl/openssl/pull/13056 for branch 1.1.1. Tested against the release 1.1.1h Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/13218) - Fix AES-GCM bug on aarch64 BigEndian Fixes #10638 Fixes #13188 Fixes a bug for aarch64 bigendian with instructions 'st1' and 'ld1' on AES-GCM mode. CLA: trivial (cherry picked from commit bc8b648f744566031ce84d77333dbbcb9689e975) Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13193) - resolve defects: reverse_inull; row[DB_exp_date] referenced before checking Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13170) (cherry picked from commit 6a13c9c9842f54ed8d98c6f37cc4ae6c1cde8b7a) - Avoid potential doublefree on dh object assigned to EVP_PKEY Fixes regression from 7844f3c784bfc93c9b94ae5a4082f9d01e82e0af Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13194) - Add a CHANGES entry for the SSL_SECOP_TMP_DH change Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/13136) - Pass an EVP_PKEY for SSL_SECOP_TMP_DH in the security callback The security operation SSL_SECOP_TMP_DH is defined to take an EVP_PKEY in the "other" parameter: /* Temporary DH key */ # define SSL_SECOP_TMP_DH (7 | SSL_SECOP_OTHER_PKEY) In most places this is what is passed. All these places occur server side. However there is one client side call of this security operation and it passes a DH object instead. This is incorrect according to the definition of SSL_SECOP_TMP_DH, and is inconsistent with all of the other locations. Our own default security callback, and the debug callback in the apps, never look at this value and therefore this issue was never noticed previously. In theory a client side application could be relying on this behaviour and could be broken by this change. This is probably fairly unlikely but can't be ruled out. Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/13136) - Changing X509at_get0_data_by_OBJ to expect const stack of X509_ATTRIBUTE CLA: trivial Reviewed-by: Kurt Roeckx <kurt@roeckx.be> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13062) (cherry picked from commit 796948cd733d2bd0d8acbaf2354c718bcd4352a6) - syscall_random(): don't fail if the getentropy() function is a dummy Several embedded toolchains may provide dummy implemented getentropy() function which always returns -1 and sets errno to the ENOSYS. As a result the function SSL_CTX_new() fails to create a new context. Fixes #13002 Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/13112) - Fixed typo in ssl_lib.c orignal -> original CLA: trivial Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/13111) (cherry picked from commit 9f7505ab6a1ce76497654ea8cf6a74307da78989) - Avoid memory leak of parent on allocation failure for child structure Reviewed-by: Ben Kaduk <kaduk@mit.edu> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/13055) (cherry picked from commit a21db568bf3d0ab4194fd3e0917ee982f1fc8bfd) - Use size of target buffer for allocation Reviewed-by: Ben Kaduk <kaduk@mit.edu> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/13055) (cherry picked from commit 8ad369171fc2b435c0ca427111481da4d4c3c1ce) - Ensure that _GNU_SOURCE is defined for NI_MAXHOST and NI_MAXSERV Since glibc 2.8, these defines like `NI_MAXHOST` are exposed only if suitable feature test macros are defined, namely: _GNU_SOURCE, _DEFAULT_SOURCE (since glibc 2.19), or _BSD_SOURCE or _SVID_SOURCE (before glibc 2.19), see GETNAMEINFO(3). CLA: trivial Fixes #13049 Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/13054) (cherry picked from commit 99501e817cbc4f11cc045dbaa7a81854d4349335) - Prepare for 1.1.1i-dev Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> - Prepare for 1.1.1h release Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> - Update copyright year Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/12949) - Updates CHANGES and NEWS for the new release Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/12949) - Add const to 'ppin' function parameter CLA: trivial Reviewed-by: Kurt Roeckx <kurt@roeckx.be> Reviewed-by: Matt Caswell <matt@openssl.org> GH: #12205 (cherry picked from commit 434343f896a2bb3e5857cc9831c38f8cd1cceec1) - Support keys with RSA_METHOD_FLAG_NO_CHECK with OCSP sign OCSP_basic_sign_ctx() in ocsp_srv.c , does not check for RSA_METHOD_FLAG_NO_CHECK. If a key has RSA_METHOD_FLAG_NO_CHECK set, OCSP sign operations can fail because the X509_check_private_key() can fail. The check for the RSA_METHOD_FLAG_NO_CHECK was moved to crypto/rsa/rsa_ameth.c as a common place to check. Checks in ssl_rsa.c were removed. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12419) - Disallow certs with explicit curve in verification chain The check is applied only with X509_V_FLAG_X509_STRICT. Fixes #12139 Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com> Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/12909) - EC_KEY: add EC_KEY_decoded_from_explicit_params() The function returns 1 when the encoding of a decoded EC key used explicit encoding of the curve parameters. Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com> Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/12909) - Fix: ecp_nistz256-armv4.S bad arguments Fix this error: crypto/ec/ecp_nistz256-armv4.S:3853: Error: bad arguments to instruction -- `orr r11,r10' crypto/ec/ecp_nistz256-armv4.S:3854: Error: bad arguments to instruction -- `orr r11,r12' crypto/ec/ecp_nistz256-armv4.S:3855: Error: bad arguments to instruction -- `orrs r11,r14' CLA: trivial Fixes #12848 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Kurt Roeckx <kurt@roeckx.be> GH: #12854 (cherry picked from commit b5f82567afa820bac55b7dd7eb9dd510c32c3ef6) - Revert two renamings backported from master The original names were more intuitive: the generate_counter counts the number of generate requests, and the reseed_counter counts the number of reseedings (of the principal DRBG). reseed_gen_counter -> generate_counter reseed_prop_counter -> reseed_counter This partially reverts commit 35a34508ef4d649ace4e373e1d019192b7e38c36. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12759) - Fix the DRBG seed propagation In a nutshell, reseed propagation is a compatibility feature with the sole purpose to support the traditional way of (re-)seeding manually by calling 'RAND_add()' before 'RAND_bytes(). It ensures that the former has an immediate effect on the latter *within the same thread*, but it does not care about immediate reseed propagation to other threads. The implementation is lock-free, i.e., it works without taking the lock of the primary DRBG. Pull request #7399 not only fixed the data race issue #7394 but also changed the original implementation of the seed propagation unnecessarily. This commit reverts most of the changes of commit 1f98527659b8 and intends to fix the data race while retaining the original simplicity of the seed propagation. - use atomics with relaxed semantics to load and store the seed counter - add a new member drbg->enable_reseed_propagation to simplify the overflow treatment of the seed propagation counter - don't handle races between different threads This partially reverts commit 1f98527659b8290d442c4e1532452b9ba6463f1e. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12759) - Fix memory leaks in conf_def.c Fixes #12471 CLA: trivial Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12533) (cherry picked from commit 4348995b0d818203f37ffa51c9bdf4488cf24bad) - Coverity Fixes x_algor.c: Explicit null dereferenced cms_sd.c: Resource leak ts_rsp_sign.c Resource Leak extensions_srvr.c: Resourse Leak v3_alt.c: Resourse Leak pcy_data.c: Resource Leak cms_lib.c: Resource Leak drbg_lib.c: Unchecked return code Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12531) - Fix PEM_write_bio_PrivateKey_traditional() to not output PKCS#8 PEM_write_bio_PrivateKey_traditional() uses i2d_PrivateKey() to do the actual encoding to DER. However, i2d_PrivateKey() is a generic function that will do what it can to produce output according to what the associated EVP_PKEY_ASN1_METHOD offers. If that method offers a function 'old_priv_encode', which is expected to produce the "traditional" encoded form, then i2d_PrivateKey() uses that. If not, i2d_PrivateKey() will go on and used more modern methods, which are all expected to produce PKCS#8. To ensure that PEM_write_bio_PrivateKey_traditional() never produces more modern encoded forms, an extra check that 'old_priv_encode' is non-NULL is added. If it is NULL, an error is returned. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12729) - Ignore vendor name in Clang version number. For example, FreeBSD prepends "FreeBSD" to version string, e.g., FreeBSD clang version 11.0.0 (git@github.com:llvm/llvm-project.git llvmorg-11.0.0-rc2-0-g414f32a9e86) Target: x86_64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin This prevented us from properly detecting AVX support, etc. CLA: trivial Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/12725) (cherry picked from commit cd84d8832d274357a5ba5433640d7ef76691b1ac) - sslapitest: Add test for premature call of SSL_export_keying_material Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12594) (cherry picked from commit ea9f6890eb54e4b9e8b81cc1318ca3a6fc0c8356) - Avoid segfault in SSL_export_keying_material if there is no session Fixes #12588 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12594) (cherry picked from commit dffeec1c10a874d7c7b83c221dbbce82f755edb1) - Fix a test_verify failure A recently added certificate in test/certs expired causing test_verify to fail. This add a replacement certificate with a long expiry date. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12561) - Fix typos and repeated words Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/12370) - Update EVP_EncodeInit.pod Fix EVP_EncodeBlock description using incorrect parameter name for encoding length CLA: trivial Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from https://github.com/openssl/openssl/pull/12518) (cherry picked from commit 1660c8fa6be2d7c4587e490c88a44a870e9b4298) - test/drbgtest.c: Fix error check test The condition in test_error_checks() was inverted, so the test succeeded as long as error_check() failed. Incidently, error_check() contained several bugs that assured it always failed, thus giving overall drbg test success. Remove the broken explicit zero check. RAND_DRBG_uninstantiate() cleanses the data via drbg_ctr_uninstantiate(), but right after that it resets drbg->data.ctr using RAND_DRBG_set(), so TEST_mem_eq(zero, sizeof(drbg->data)) always failed. (backport from https://github.com/openssl/openssl/pull/11195) Signed-off-by: Vitezslav Cizek <vcizek@suse.com> Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/12517) - fixed swapped parameters descriptions for x509 CLA: trivial Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from https://github.com/openssl/openssl/pull/12505) - Avoid errors with a priori inapplicable protocol bounds The 'MinProtocol' and 'MaxProtocol' configuration commands now silently ignore TLS protocol version bounds when configurign DTLS-based contexts, and conversely, silently ignore DTLS protocol version bounds when configuring TLS-based contexts. The commands can be repeated to set bounds of both types. The same applies with the corresponding "min_protocol" and "max_protocol" command-line switches, in case some application uses both TLS and DTLS. SSL_CTX instances that are created for a fixed protocol version (e.g. TLSv1_server_method()) also silently ignore version bounds. Previously attempts to apply bounds to these protocol versions would result in an error. Now only the "version-flexible" SSL_CTX instances are subject to limits in configuration files in command-line options. Expected to resolve #12394 Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Matt Caswell <matt@openssl.org> GH: #12507 - man3: Drop warning about using security levels higher than 1. Today, majority of web-browsers reject communication as allowed by the security level 1. Instead key sizes and algorithms from security level 2 are required. Thus remove the now obsolete warning against using security levels higher than 1. For example Ubuntu, compiles OpenSSL with security level set to 2, and further restricts algorithm versions available at that security level. Reviewed-by: Kurt Roeckx <kurt@roeckx.be> Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/12444) (cherry picked from commit 02e14a65fd6cc63204b43a79d510e95a63bdd901) - doc: Fix documentation of EVP_EncryptUpdate(). The documentation was off by one for the length this function could return. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12435) (cherry picked from commit 3fc164e8d18dcdef57d297956debf8d966e7fbef) - x509_vfy.c: Improve key usage checks in internal_verify() of cert chains If a presumably self-signed cert is last in chain we verify its signature only if X509_V_FLAG_CHECK_SS_SIGNATURE is set. Upon this request we do the signature verification, but not in case it is a (non-conforming) self-issued CA certificate with a key usage extension that does not include keyCertSign. Make clear when we must verify the signature of a certificate and when we must adhere to key usage restrictions of the 'issuing' cert. Add some comments for making internal_verify() easier to understand. Update the documentation of X509_V_FLAG_CHECK_SS_SIGNATURE accordingly. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12357) - Fix issue 1418 by moving check of KU_KEY_CERT_SIGN and weakening check_issued() Move check that cert signing is allowed from x509v3_cache_extensions() to where it belongs: internal_verify(), generalize it for proxy cert signing. Correct and simplify check_issued(), now checking self-issued (not: self-signed). Add test case to 25-test_verify.t that demonstrates successful fix. As prerequisites, this adds the static function check_sig_alg_match() and the internal functions x509_likely_issued() and x509_signing_allowed(). This is a backport of the core of PR #10587. Fixes #1418 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12357) - Enable WinCE build without deceiving _MSC_VER. Reviewed-by: Mark J. Cox <mark@awe.com> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11526) (cherry picked from commit c35b8535768e22cd3b7743f4887a72e53a621a5f) - To generate makefile with correct parameters for WinCE. Reviewed-by: Mark J. Cox <mark@awe.com> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11526) (cherry picked from commit a1736f37aee855fecf463b9f15519e12c333ecfc) - Disable optimiization of BN_num_bits_word() for VS2005 ARM compiler due to its miscompilation of the function. https://mta.openssl.org/pipermail/openssl-users/2018-August/008465.html Reviewed-by: Mark J. Cox <mark@awe.com> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11526) (cherry picked from commit 7a09fab2b3d201062a2cc07c1a40d09d61ea31bd) - Changed uintptr_t to size_t. WinCE6 doesn't seem it have the definition. Reviewed-by: Mark J. Cox <mark@awe.com> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11526) (cherry picked from commit 6c2a56beec847da18e5ac60a30219f0dea39baf9) - [1.1.1][test] Avoid missing EC_GROUP wrappers Backport of https://github.com/openssl/openssl/pull/12096 to 1.1.1 broke the build as the following functions are missing: const BIGNUM *EC_GROUP_get0_field(const EC_GROUP *group); int EC_GROUP_get_field_type(const EC_GROUP *group); Turns out that for the purposes of the test code, we don't really need to differentiate between prime and binary fields, and we can directly use the existing `EC_GROUP_get_degree()` in the same fashion as was being done for binary fields also for prime fields. Fixes https://github.com/openssl/openssl/issues/12432 Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from https://github.com/openssl/openssl/pull/12433) - [test] ectest: check custom generators Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from https://github.com/openssl/openssl/pull/12096) (cherry picked from commit a01cae99ac384cb6a74b46ccdc90736fe0754958) - improve SSL_CTX_set_tlsext_ticket_key_cb ref impl improve reference implementation code in SSL_CTX_set_tlsext_ticket_key_cb man page change EVP_aes_128_cbc() to EVP_aes_256_cbc(), with the implication of requiring longer keys. Updating this code brings the reference implementation in line with implementation in openssl committed in 2016: commit 05df5c20 Use AES256 for the default encryption algorithm for TLS session tickets add comments where user-implementation is needed to complete code (backport from https://github.com/openssl/openssl/pull/12063) Reviewed-by: Ben Kaduk <kaduk@mit.edu> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12391) - [test][15-test_genec] Improve EC tests with genpkey Test separately EC parameters and EC key generation. Some curves only support explicit params encoding. For some curves we have had cases in which generating the parameters under certain conditions failed, while generating and serializing a key under the same conditions did not. See <https://github.com/openssl/openssl/issues/12306> for more details. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12308) - [apps/genpkey] exit status should not be 0 on output errors If the key is to be serialized or printed as text and the framework returns an error, the app should signal the failure to the user using a non-zero exit status. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12305) (cherry picked from commit 466d30c0d7fa861a5fcbaebd2e2010a8c2aea322) - [EC][ASN1] Detect missing OID when serializing EC parameters and keys The following built-in curves do not have an assigned OID: - Oakley-EC2N-3 - Oakley-EC2N-4 In general we shouldn't assume that an OID is always available. This commit detects such cases, raises an error and returns appropriate return values so that the condition can be detected and correctly handled by the callers, when serializing EC parameters or EC keys with the default `ec_param_enc:named_curve`. Fixes #12306 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12312) - Configure: Check source and build dir equality a little more thoroughly 'absolutedir' does a thorough job ensuring that we have a "real" path to both source and build directory, unencumbered by symbolic links. However, that isn't enough on case insensitive file systems on Unix flavored platforms, where it's possible to stand in, for example, /PATH/TO/Work/openssl, and then do this: perl ../../work/openssl/Configure ... and thereby having it look like the source directory and the build directory aren't the same. We solve this by having a closer look at the computed source and build directories, and making sure they are exactly the same strings if they are in fact the same directory. This is especially important when making symbolic links based on this directories, but may have other ramifications as well. Fixes #12323 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12337) (cherry picked from commit 610e2b3b7019b11d97f1dcda13575254a2c65c3d) - Free pre_proc_exts in SSL_free() Usually it will be freed in tls_early_post_process_client_hello(). However if a ClientHello callback will be used and will return SSL_CLIENT_HELLO_RETRY then tls_early_post_process_client_hello() may never come to the point where pre_proc_exts is freed. Fixes #12194 CLA: trivial Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/12330) (cherry picked from commit 94941cada25433a7dca35b5b9f8cbb751ab65ab3) - doc: remove reference to the predecessor of SHA-1. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12322) (cherry picked from commit 69f982679ec0c8887a4324d8518a33808fee1cd7) - Fix a typo on the SSL_dup page Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12245) - Add an SSL_dup test Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12245) - Don't attempt to duplicate the BIO state in SSL_dup SSL_dup attempted to duplicate the BIO state if the source SSL had BIOs configured for it. This did not work. Firstly the SSL_dup code was passing a BIO ** as the destination argument for BIO_dup_state. However BIO_dup_state expects a BIO * for that parameter. Any attempt to use this will either (1) fail silently, (2) crash or fail in some other strange way. Secondly many BIOs do not implement the BIO_CTRL_DUP ctrl required to make this work. Thirdly, if rbio == wbio in the original SSL object, then an attempt is made to up-ref the BIO in the new SSL object - even though it hasn't been set yet and is NULL. This results in a crash. This appears to have been broken for a very long time with at least some of the problems described above coming from SSLeay. The simplest approach is to just remove this capability from the function. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12245) - Update the SSL_dup documentation to match reality Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12245) - Ensure that SSL_dup copies the min/max protocol version With thanks to Rebekah Johnson for reporting this issue. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12245) - Force ssl/tls protocol flags to use stream sockets Prior to this patch doing something like openssl s_client -dtls1 -tls1 ... could cause s_client to speak TLS on a UDP socket which does not normally make much sense. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12266) (cherry picked from commit 2c9ba46c90e9d25040260bbdc43e87921f08c788) - Configuration: do not overwrite BASE_unix ex_libs in AIX BASE_unix sets ex_libs to `-lz` based the on zlib linking. AIX platforms overwrote this instead of adding to it. CLA: Trivial Signed-off-by: Attila Szakacs <attila.szakacs@oneidentity.com> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12271) (cherry picked from commit b1f9db698011e5a178d53483eccfd0a44f132baf) - doc/man3: fix types taken by HMAC(), HMAC_Update() HMAC() and HMAC_Update() take size_t for 'n' and 'len' respectively. CLA: trivial Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12264) (cherry picked from commit cc63865f336e0144f8501aa0a862ba0247a50622) - Fix wrong return value check of mmap function The mmap function never returns NULL. If an error occurs, the function returns MAP_FAILED. CLA: trivial Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12187) (cherry picked from commit 1d78129dd205e3e85083a91c33540a70c51b0a23) - Refactor BN_R_NO_INVERSE logic in internal functions Closes #12129 As described in https://github.com/openssl/openssl/issues/12129 the readability of the internal functions providing the two alternative implementations for `BN_mod_inverse()` is a bit lacking. Both these functions are now completely internal, so we have the flexibility needed to slightly improve readability and remove unnecessary NULL checks. The main changes here are: - rename `BN_mod_inverse_no_branch()` as `bn_mod_inverse_no_branch()`: this function is `static` so it is not even visible within the rest of libcrypto. By convention upcase prefixes are reserved for public functions. - remove `if (pnoinv == NULL)` checks in `int_bn_mod_inverse()`: this function is internal to the BN module and we can guarantee that all callers pass non-NULL arguments. - `bn_mod_inverse_no_branch()` takes an extra `int *pnoinv` argument, so that it can signal if no inverse exists for the given inputs: in this way the caller is in charge of raising `BN_R_NO_INVERSE` as it is the case for the non-consttime implementation of `int_bn_mod_inverse()`. - `BN_mod_inverse()` is a public function and must guarantee that the internal functions providing the actual implementation receive valid arguments. If the caller passes a NULL `BN_CTX` we create a temporary one for internal use. - reorder function definitions in `crypto/bn/bn_gcd.c` to avoid forward declaration of `static` functions (in preparation for inlining) - inline `bn_mod_inverse_no_branch()`. (Backport to 1.1.1 from https://github.com/openssl/openssl/pull/12142) (cherry picked from commit 5d8b3a3ef2941b8822523742a0408ca6896aa65d) Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12169) - Make it clear that you can't use all ciphers for CMAC Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12107) - Add a CMAC test We did not have a test of the low level CMAC APIs so we add one. This is heavily based on the HMAC test. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12107) - Correctly handle the return value from EVP_Cipher() in the CMAC code EVP_Cipher() is a very low level routine that directly calls the underlying cipher function. It's return value semantics are very odd. Depending on the type of cipher 0 or -1 is returned on error. We should just check for <=0 for a failure. Fixes #11957 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12107) - Ensure we never use a partially initialised CMAC_CTX If the CMAC_CTX is partially initialised then we make a note of this so that future operations will fail if the initialisation has not been completed. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12107) - use safe primes in ssl_get_auto_dh() DH_get_1024_160() and DH_get_2048_224() return parameters from RFC5114. Those parameters include primes with known small subgroups, making them unsafe. Change the code to use parameters from RFC 2409 and RFC 3526 instead (group 2 and 14 respectively). This patch also adds automatic selection of 4096 bit params for 4096 bit RSA keys backport of 7646610 Signed-off-by: Hubert Kario <hkario@redhat.com> Reviewed-by: Kurt Roeckx <kurt@roeckx.be> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12160) - CMS_get0_signers() description CLA: trivial Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12055) (cherry picked from commit 9ac916c7529a21cd01d1b539362abf8402719e30) - EVP: allow empty strings to EVP_Decode* functions This is a simple check order correction. Fixes #12143 Reviewed-by: Ben Kaduk <kaduk@mit.edu> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12144) (cherry picked from commit 0800288e6e1d9f44d471043a970ba57743ca8f4c) - doc: Random spellchecking A little spell checking. Backport of commit af0d413654d19 ("doc: Random spellchecking") Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Reviewed-by: Kurt Roeckx <kurt@roeckx.be> Reviewed-by: Paul Dale <paul.dale@oracle.com> GH: #12075 - Do not allow dropping Extended Master Secret extension on renegotiaton Abort renegotiation if server receives client hello with Extended Master Secret extension dropped in comparison to the initial session. Fixes #9754 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12099) - Test genpkey app for EC keygen with various args This commit adds a new recipe to test EC key generation with the `genpkey` CLI app. For each built-in curve, it tests key generation with text output, in PEM and in DER format, using `explicit` and `named_curve` for parameters encoding. The list of built-in curves is static at the moment, as this allows to differentiate between prime curves and binary curves to avoid failing when ec2m is disabled. Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/12085) - Silence gcc false positive warning on alpn_protos_len in test/handshake_helper.c Fixes #12033 Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/12041) - Silence gcc false positive warning on refdatalen in test/tls13encryptiontest.c Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/12041) - Fix err checking and mem leaks of BIO_set_conn_port and BIO_set_conn_address Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12036) - Replace BUF_strdup() call by OPENSSL_strdup() adding failure check in bss_acpt.c Add OPENSSL_strdup failure check to cpt_ctrl() in bss_acpt.c Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12036) - [crypto/ec] Remove unreachable AVX2 code in NISTZ256 implementation `crypto/ec/ecp_nistz256.c` contained code sections guarded by a `ECP_NISTZ256_AVX2` define. The relevant comment read: > /* > * Note that by default ECP_NISTZ256_AVX2 is undefined. While it's great > * code processing 4 points in parallel, corresponding serial operation > * is several times slower, because it uses 29x29=58-bit multiplication > * as opposite to 64x64=128-bit in integer-only scalar case. As result > * it doesn't provide *significant* performance improvement. Note that > * just defining ECP_NISTZ256_AVX2 is not sufficient to make it work, > * you'd need to compile even asm/ecp_nistz256-avx.pl module. > */ Without diminishing the quality of the original submission, it's evident that this code has been basically unreachable without modifications to the library source code and is under-tested. This commit removes these sections from the codebase. (cherry picked from commit 00da0f69890874feaa555fafb99b967b861e9118 , backported from https://github.com/openssl/openssl/pull/12019 ) Reviewed-by: Kurt Roeckx <kurt@roeckx.be> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/12046) - Fix a typo in SSL_CTX_set_session_ticket_cb.pod "SSL" takes two esses, not three. [skip ci] Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12038) (cherry picked from commit 09527c493596060544bda92ecd0d8ef40a366c5e) - enable DECLARE_DEPRECATED macro for Oracle Developer Studio compiler Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/9575) - Fix a buffer overflow in drbg_ctr_generate This can happen if the 32-bit counter overflows and the last block is not a multiple of 16 bytes. Fixes #12012 [extended tests] Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Patrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: Kurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/12016) (cherry picked from commit 42fa3e66697baa121220b4eacf03607280e4ff89) - fix a docs typo Correct "EC_KEY_point2buf" to "EC_POINT_point2buf". The former does not exist. CLA: trivial Reviewed-by: Ben Kaduk <kaduk@mit.edu> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11988) (cherry picked from commit a5a87011baeef71c86938a2bae54f89fbe99e5dc) - Prevent extended tests run unexpectedly in appveyor Reason turns out that "git log -2" is picking up a merge commit and a random commit message from the master branch. Restore the expected behavior by using git log -1 $env:APPVEYOR_PULL_REQUEST_HEAD_COMMIT Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11981) (cherry picked from commit d805b83166538907535862372c16ff6ceb648b21) - Revert the check for NaN in %f format Unfortunately -Ofast seems to break that check. Fixes #11994 Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12003) (cherry picked from commit 41dccd68b9b9b7622b26d264c5fa190aa5bd4201) - Make BIO_do_connect() and friends handle multiple IP addresses Backport of #11971 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/11989) - bio printf: Avoid using rounding errors in range check There is a problem casting ULONG_MAX to double which clang-10 is warning about. ULONG_MAX typically cannot be exactly represented as a double. ULONG_MAX + 1 can be and this fix uses the latter, however since ULONG_MAX cannot be represented exactly as a double number we subtract 65535 from this number, and the result has at most 48 leading one bits, and can therefore be represented as a double integer without rounding error. By adding 65536.0 to this number we achive the correct result, which should avoid the warning. The addresses a symptom of the underlying problem: we print doubles via an unsigned long integer. Doubles have a far greater range and should be printed better. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11955) (cherry picked from commit 082c041b4233b17b80129d4ac6b33a28014442b0) - EVP_EncryptInit.pod: fix example Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11976) (cherry picked from commit d561b84143f5e7956454090e15de0c5e1425ceac) - AES CTR-DRGB: performance improvement Optimize the the AES-based implementation of the CTR_DRBG construction, see 10.2.1 in [1]. Due to the optimizations, the code may deviate (more) from the pseudocode in [1], but it is functional equivalence being decisive for compliance: "All DRBG mechanisms and algorithms are described in this document in pseudocode, which is intended to explain functionality. The pseudocode is not intended to constrain real-world implementations." [9 in [1]]. The following optimizations are done: - Replace multiple plain AES encryptions by a single AES-ECB encryption of a corresponding pre-initialized buffer, where possible. This allows platform-specific AES-ECB support to be used and reduces the overhead of multiple EVP calls. - Replace the generate operation loop (which is a counter increment followed by a plain AES encryption) by a loop which does a plain AES encryption followed by a counter increment. The latter loop is just a description of AES-CTR, so we replace it by a single AES-CTR encryption. This allows for platform-specific AES-CTR support to be used and reduces the overhead of multiple EVP calls. This change, that is, going from a pre- to a post- counter increment, requires the counter in the internal state to be kept at "+1" (compared to the pseudocode in [1]) such that it is in the correct state, when a generate operation is called. That in turn also requires all other operations to be changed from pre- to post-increment to keep functional equivalence. [1] NIST SP 800-90A Revision 1 Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (cherry picked from commit 28bdbe1aaa474ae8cd83e520d02e463e46ce89d9) Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/11968) - Avoid undefined behavior with unaligned accesses Fixes: #4983 [extended tests] Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/11781) - More testing for CLI usage of Ed25519 and Ed448 keys Add testing for the `req` app and explicit conversion tests similar to what is done for ECDSA keys. The included test keys for Ed25519 are from the examples in RFC 8410 (Sec. 10) The key for Ed448 is derived from the first of the test vectors in RFC 8032 (Sec. 7.4) using OpenSSL to encode it into PEM format. (cherry picked from commit 81722fdf2e01cfa71c46abbcc19e65aa003e083f) This is originally a cherry-pick from https://github.com/openssl/openssl/pull/10410, with trivial changes from the original commit to account for the differences in 1.1.1. Fixes #10687 Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from https://github.com/openssl/openssl/pull/11939) - More testing for sign/verify through `dgst` Add tests for signature generation and verification with `dgst` CLI for common key types: - RSA - DSA - ECDSA (cherry picked from commit ef1e59ed833e8ed1d5f4de5b0c734da8561890e3) This is a backport from https://github.com/openssl/openssl/pull/10410. Support for testing EdDSA through `pkeyutl` was dropped as the required `-rawin` option is not supported in 1.1.1. Fixes #10687 Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from https://github.com/openssl/openssl/pull/11939) - Coverity 1463830: Resource leaks (RESOURCE_LEAK) Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/11941) (cherry picked from commit bbc3c22c0e2b3b4b6f069712dc8322a48506b775) - Fix B<..> vs. I<..> and add two remarks in OSSL_STORE_open.pod Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11912) - Allow NULL arg to OSSL_STORE_close() Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11912) - There is no -signreq option in CA.pl CLA: trivial Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11897) - Prevent use after free of global_engine_lock If buggy application calls engine functions after cleanup of engines already happened the global_engine_lock will be used although already freed. See for example: https://bugzilla.redhat.com/show_bug.cgi?id=1831086 Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/11896) (cherry picked from commit e12813d0d31f4f7be2ccc592d382ef3e94bdb842) - STORE: Make try_decode_PrivateKey() ENGINE aware This function only considered the built-in and application EVP_PKEY_ASN1_METHODs, and is now amended with a loop that goes through all loaded engines, using whatever table of methods they each have. Fixes #11861 (cherry picked from commit b84439b06a1b9a7bfb47e230b70a6d3ee46e8a19) Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11887) - Fix d2i_PrivateKey() to work as documented d2i_PrivateKey() is documented to return keys of the type given as first argument |type|, unconditionally. Most specifically, the manual says this: > An error occurs if the decoded key does not match type. However, when faced of a PKCS#8 wrapped key, |type| was ignored, which may lead to unexpected results. (cherry picked from commit b2952366dd0248bf35c83e1736cd203033a22378) Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from https://github.com/openssl/openssl/pull/11888) - t1_trce: Fix remaining places where the 24 bit shift overflow happens [extended tests] Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11857) (cherry picked from commit 7486c718e54cc762edc5f1c7c526ab83d0f97ef7) - Avoid potential overflow to the sign bit when shifting left 24 places Although there are platforms where int is 64 bit, 2GiB large BIGNUMs instead of 4GiB should be "big enough for everybody". Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11857) (cherry picked from commit 1d05eb55caa8965a151360c2469c463ecd990987) - Cast the unsigned char to unsigned int before shifting left This is needed to avoid automatic promotion to signed int. Fixes #11853 [extended tests] Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11857) (cherry picked from commit cbeb0bfa961412eebfbdf1e72900f05527e81e15) - Fix egd and devrandom source configs ./config --with-rand-seed=egd need to defines OPENSSL_RAND_SEED_EGD and OPENSSL_NO_EGD so get rid of OPENSSL_NO_EGD (compiles but I did not really test EGD) ./config --with-rand-seed=devrandom does not work since wait_random_seeded works under the assumption that OPENSSL_RAND_SEED_GETRANDOM is supposed to be enabled as well, that is usually the case, but not when only devrandom is enabled. Skip the wait code in this special case. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11848) (cherry picked from commit ddec332f329a432a45c0131d83f3bfb46114532b) - Update early data exchange scenarios in doc Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/11816) (cherry picked from commit b2a5001d954e81e2a582f2a935212ab554a3cbbe) - Update limitation of psk_client_cb and psk_server_cb in usage with TLSv1.3 Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/11816) (cherry picked from commit e0bcb4f97f7496af032013ead15b7472b60e85fa) - Fix some places where X509_up_ref is used without error handling. This takes up the ball from #11278 without trying to solve everything at once. [extended tests] Reviewed-by: Kurt Roeckx <kurt@roeckx.be> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11852) - TTY_get() in crypto/ui/ui_openssl.c open_console() can also return errno 1 (EPERM, Linux) Signed-off-by: Maxim Zakharov <5158255+Maxime2@users.noreply.github.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11767) (cherry picked from commit 082394839ea32386abc7ee33aaa9da864287064c) - Test TLSv1.3 out-of-band PSK with all 5 ciphersuites Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11809) - Fix crash in early data send with out-of-band PSK using AES CCM Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11809) - If SOURCE_DATE_EPOCH is defined, use it for copyright year Using the date from SOURCE_DATE_EPOCH instead of the current date makes it possible to reproduce a build that was built on a different year: https://reproducible-builds.org/specs/source-date-epoch/ This is fixing an issue we had while building Tor Browser: https://trac.torproject.org/projects/tor/ticket/33535 CLA: trivial Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/11296) (cherry picked from commit 11d7d903447ab866d037fb8bba4ceb49c7d89191) - Correct alignment calculation in ssl3_setup_write The alignment calculation in ssl3_setup_write incorrectly results in an alignment allowance of (-SSL3_RT_HEADER_LENGTH) & (SSL3_ALIGN_PAYLOAD - 1) bytes. This equals 3 in almost all cases. The maximum alignment actually used in do_ssl3_write is (SSL3_ALIGN_PAYLOAD - 1). This equals 7 bytes in almost all cases. So there is a potential to overrun the buffer by up to 4 bytes. Fortunately, the encryption overhead allowed for is 80 bytes which consists of 16 bytes for the cipher block size and 64 bytes for the MAC output. However the biggest MAC that we ever produce is HMAC-384 which is 48 bytes - so we have a headroom of 16 bytes (i.e. more than the 4 bytes of potential overrun). Thanks to Nagesh Hegde for reporting this. Fixes #11766 Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/11768) (cherry picked from commit d30ef639647ad263d09740c931a5bfb5a8b6a5f6) - Configure: Avoid SIXTY_FOUR_BIT for linux-mips64 This is a 32-bit ABI build (as opposed to linux64-mips64). Setting SIXTY_FOUR_BIT breaks hardware optimizations, at least on octeon processors. Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11154) - Fix rsa8192.pem Q: How did I do that? A: That's a long story. Precondition: I used sage 8.1 for the math, it could probably done with simple python as well…
@vdukhovni, this is the said backport of the core of #10587
for fixing #1418 also for OpenSSL v1.1.1.