Re: OTC VOTE: Keeping API compatibility with missing public key
On Fri, Dec 04, 2020 at 01:45:07PM +0100, Tomas Mraz wrote: > topic: For 3.0 EVP_PKEY keys all algorithm implementations that were usable >with 1.1.1 EVP_PKEY API or low level APIs without public component must >stay usable. > >This overrules the > * all implementations apart from EC require the public component to > be present; >part of the vote closed on 2020-11-17. > +1 Kurt
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [08 December 2020] EDIPARTYNAME NULL pointer de-reference (CVE-2020-1971) == Severity: High The X.509 GeneralName type is a generic type for representing different types of names. One of those name types is known as EDIPartyName. OpenSSL provides a function GENERAL_NAME_cmp which compares different instances of a GENERAL_NAME to see if they are equal or not. This function behaves incorrectly when both GENERAL_NAMEs contain an EDIPARTYNAME. A NULL pointer dereference and a crash may occur leading to a possible denial of service attack. OpenSSL itself uses the GENERAL_NAME_cmp function for two purposes: 1) Comparing CRL distribution point names between an available CRL and a CRL distribution point embedded in an X509 certificate 2) When verifying that a timestamp response token signer matches the timestamp authority name (exposed via the API functions TS_RESP_verify_response and TS_RESP_verify_token) If an attacker can control both items being compared then that attacker could trigger a crash. For example if the attacker can trick a client or server into checking a malicious certificate against a malicious CRL then this may occur. Note that some applications automatically download CRLs based on a URL embedded in a certificate. This checking happens prior to the signatures on the certificate and CRL being verified. OpenSSL's s_server, s_client and verify tools have support for the "-crl_download" option which implements automatic CRL downloading and this attack has been demonstrated to work against those tools. Note that an unrelated bug means that affected versions of OpenSSL cannot parse or construct correct encodings of EDIPARTYNAME. However it is possible to construct a malformed EDIPARTYNAME that OpenSSL's parser will accept and hence trigger this attack. All OpenSSL 1.1.1 and 1.0.2 versions are affected by this issue. Other OpenSSL releases are out of support and have not been checked. OpenSSL 1.1.1 users should upgrade to 1.1.1i. OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2x. Other users should upgrade to OpenSSL 1.1.1i. This issue was reported to OpenSSL on 9th November 2020 by David Benjamin (Google). Initial analysis was performed by David Benjamin with additional analysis by Matt Caswell (OpenSSL). The fix was developed by Matt Caswell. Note OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. The impact of this issue on OpenSSL 1.1.0 has not been analysed. Users of these versions should upgrade to OpenSSL 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20201208.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl/PloEACgkQ2cTSbQ5g RJERNQf/d8G0r7APrOuxlwOL2j0j4JX5HZoR/ilD1eD6kSj3uZmCbl/DTZgN9uhj hMN9UTCVdF+NcWlqldwUVLLSq16/P821QLrbqKs4Q6i2NDwHIAU6VCneRZOUIOpl VOyQ+BJDavvqQ2gNziDK29sjG8JxWUqQ10fdphfrV1vS0Wd1fV1/Kk9I0ba+yv5O RiIyvbJobCEyNz52JdqbBsKjrSCtPh6qMra3IYm6EDJDnp+T8UpliB3RBIBuIPfU ALRageyqmE9+J5BFYxbd1Lx37mHXq1PZsSYd6L09Y9Wg5fJLHzWffd74SfJHwRza xZ/UTvCvkbGUbspT/U4mkuHwHzYXcg== =41vP -END PGP SIGNATURE-
OpenSSL version 1.1.1i published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 1.1.1i released === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1i of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1i is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1i.tar.gz Size: 9808346 SHA1 checksum: eb684ba4ed31fe2c48062aead75233ecd36882a6 SHA256 checksum: e8be6a35fe41d10603c3cc635e93289ed00bf34b79671a3a4de64fcee00d5242 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1i.tar.gz openssl sha256 openssl-1.1.1i.tar.gz Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl/PfcIACgkQ2cTSbQ5g RJGTdAgAg4vCZBf6Ugf0JojEHlqfxvdYTDPaz7C8vT4KFOsXW7vYr7Flc0O7rgfH hL/N25f8Ao4AlX1mtlq5whR6adf3dA3Ny3T5r8WNXy8a2GdC/AH7zSVI1+0yQ3L8 C1ohbRYUHgP9o6DjjSBylSgJzmwSK7CfBFbiq4MX/FeEqon+fy8Er5LMW7Cor2Tq 07a5532Gb67zuRPu/U5D6fFsXBDvzeDsT/c9ZMt0eImvmpU6wJNqALC+I0qI/pKY AY6FmljuYM3gr1aWbuCeyMbcGutRCFOLGrNl/VpQZFM5m7Rs6NQsQ+c3O5EICpoU NKmPlsXfAabUZpEaWKK/4mzXLgMxfw== =MgEX -END PGP SIGNATURE-
Re: #8765
I assume nobody is surprised to see me say this: I do not see a requirement to do this in 3.0. In particular, I hope that none of the contributors who already have 3.0 work spend time on this. If this is going to be considered for 3.0, I would like to know the rationale for doing so. I don’t think “the code is hard to understand” is important enough at this point in time. I don’t think making asymmetric keygen faster is important now, either.
