From beldmit at gmail.com Mon Feb 1 08:13:58 2021 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 1 Feb 2021 09:13:58 +0100 Subject: Change of scenery In-Reply-To: References: Message-ID: Congratulations! On Sun, Jan 31, 2021 at 10:27 PM Dr Paul Dale wrote: > Letting people know that I'm starting as an OpenSSL fellow today. > > I'm looking forward to working as part of the team and I'll be able to > fully devote my efforts to the benefit of the project. > > > Dr Paul Dale > > > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From tm at t8m.info Mon Feb 1 11:10:45 2021 From: tm at t8m.info (Tomas Mraz) Date: Mon, 01 Feb 2021 12:10:45 +0100 Subject: Monthly Status Report (January 2021) Message-ID: <74c96412666c263693cdbdc1bf93ce7d81f099bd.camel@t8m.info> My key activities this month were: - triage of newly reported issues and responding to questions - participation on the OTC meetings - reviews of various PRs: - I've reviewed about 80 PRs this month, merged many of them submitted by 3rd party contributors - Major PRs reviewed: - 3.0 alpha 11 release review - Update CMP doc on cert and key sources and extend use of PKCS#10 input #13841 - Deprecate EVP_KEY_new_CMAC_key #13829 - [crypto/dh] side channel hardening for computing DH shared keys #13783 - x509_vfy.c: Fix a regression in find_issuer(); extend and re-organize some tests #13762 - X509_cmp(): Fix comparison in case x509v3_cache_extensions() failed to due to invalid cert #13755 - Major improvemens of pkey app and bugfix on IS_HTTP(S) macros #13712 - X509 app: major cleanup of user guidance, documentation, and code structure #13711 - Fix a crash with multi-threaded applications using the FIPS module #13660 - apps/{req,x509,ca}.c Make sure certs have SKID and AKID by default #13658 - Use centralized fetching errors #13467 - Remove pkey_downgrade from PKCS7 code #13435 - Test CLI key validation and SM2 key validation #13359 - EVP: fix keygen for EVP_PKEY_RSA_PSS #13099 - submitted 11 PRs: - In particular: - chacha20: Properly reinitialize the cipher context with NULL key #13850 - Deprecation of the remaining functions related to X9.31 RSA key generation #13921 - Rename EVP_CIPHER_CTX_get_iv and EVP_CIPHER_CTX_get_iv_state for clarity #13870 - Fixes in DH derivation related to DH support in CMS #13869 - Implement missing algorithm id generation for the RSA-PSS signatures #13988 - took over the PR for deprecation of EC_KEY and related functions (#13139) from Shane, finalized it -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From pauli at openssl.org Tue Feb 2 08:51:56 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 2 Feb 2021 18:51:56 +1000 Subject: OTC Vote: Moving forwards we will use TYPE_NAME_action_name for function names. Message-ID: <85b7e013-c986-d3f2-c272-cfbf34ee0f44@openssl.org> topic: Moving forwards we will use TYPE_NAME_action_name for function names. comment: Not camel case, underscores separating words.? I.e. EVP_MAC_update ???????? not EVP_MACUpdate or EVP_MAC_Update. Proposed by pauli. Public: yes opened: 2020-02-02 closed: 2020-02-02 accepted:? yes? (for: 7, against: 0, abstained: 1, not voted: 3) From Matthias.St.Pierre at ncp-e.com Tue Feb 2 08:53:56 2021 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 2 Feb 2021 08:53:56 +0000 Subject: OTC Vote: Moving forwards we will use TYPE_NAME_action_name for function names. In-Reply-To: <85b7e013-c986-d3f2-c272-cfbf34ee0f44@openssl.org> References: <85b7e013-c986-d3f2-c272-cfbf34ee0f44@openssl.org> Message-ID: <8250a2488ffd4ef59f8284c23c8eccae@ncp-e.com> +1 > -----Original Message----- > From: openssl-project On Behalf Of Dr Paul Dale > Sent: Tuesday, February 2, 2021 9:52 AM > To: openssl-project at openssl.org > Subject: OTC Vote: Moving forwards we will use TYPE_NAME_action_name for function names. > > topic: Moving forwards we will use TYPE_NAME_action_name for function names. > comment: Not camel case, underscores separating words.? I.e. EVP_MAC_update > ???????? not EVP_MACUpdate or EVP_MAC_Update. > Proposed by pauli. > Public: yes > opened: 2020-02-02 > closed: 2020-02-02 > accepted:? yes? (for: 7, against: 0, abstained: 1, not voted: 3) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7494 bytes Desc: not available URL: From pauli at openssl.org Tue Feb 2 09:07:25 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 2 Feb 2021 19:07:25 +1000 Subject: OTC VOTE: functions not conforming to the TYPE_NAME_action_name naming scheme are defects Message-ID: <73d452bb-b863-8996-522c-7ee728ba8a83@openssl.org> topic: Where a function does not use the TYPE_NAME_action_name naming scheme, ?????? it is considered to be a defect. comment: These are not considered blockers for 3.0 if the function existed in ???????? 1.1.1.? New functions that do not conform must be fixed before release. Proposed by pauli. Public: yes opened: 2020-02-02 closed: 2020-02-02 accepted:? yes? (for: 5, against: 0, abstained: 3, not voted: 3) From pauli at openssl.org Tue Feb 2 09:17:57 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 2 Feb 2021 19:17:57 +1000 Subject: OTC Vote: EVP init functions should accept an OSSL_PARAM array to set parameters. Message-ID: <4a83dd4e-75a8-0ece-3e2f-f35d692d7a56@openssl.org> topic: EVP init functions should accept an OSSL_PARAM array to set parameters. comment: This will mostly avoid calling the equivalent set_param call. Proposed by pauli. Public: yes opened: 2020-02-02 closed: 2020-02-02 accepted:? yes? (for: 8, against: 0, abstained: 1, not voted: 2) From pauli at openssl.org Tue Feb 2 09:47:48 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 2 Feb 2021 19:47:48 +1000 Subject: OTC Vote: EVP_MAC_init should accept key and key length arguments. Message-ID: topic: EVP_MAC_init should accept key and key length arguments. Proposed by pauli. Public: yes opened: 2020-02-02 closed: 2020-02-02 accepted:? yes? (for: 4, against: 1, abstained: 4, not voted: 2) From pauli at openssl.org Tue Feb 2 10:09:54 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 2 Feb 2021 20:09:54 +1000 Subject: OTC Vote: We should not support EVP_xxx_reset() operations. Message-ID: topic: We should not support EVP_xxx_reset() operations. comment: The existing EVP_xxx_dup() function supports this functionality. ???????? Existing EVP_xxx_reset() functions not to be removed in the 3.0 ???????? timeframe. Proposed by pauli. Public: yes opened: 2020-02-02 closed: 2020-02-02 accepted:? yes? (for: 7, against: 0, abstained: 1, not voted: 3) From pauli at openssl.org Tue Feb 2 10:17:26 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 2 Feb 2021 20:17:26 +1000 Subject: OTC vote: The EVP_xxx_CTX types should support an EVP_xxx_CTX_dup call but not an EVP_xxx_CTX_copy call. Message-ID: topic: The EVP_xxx_CTX types should support an EVP_xxx_CTX_dup call but not an ?????? EVP_xxx_CTX_copy call. comments: Existing EVP_xxx_copy() functions not to be removed in the 3.0 ????????? timeframe. Proposed by pauli. Public: yes opened: 2020-02-02 closed: 2020-02-02 accepted:? yes? (for: 8, against: 0, abstained: 0, not voted: 3) From Matthias.St.Pierre at ncp-e.com Tue Feb 2 11:24:06 2021 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 2 Feb 2021 11:24:06 +0000 Subject: OTC VOTE: functions not conforming to the TYPE_NAME_action_name naming scheme are defects In-Reply-To: <73d452bb-b863-8996-522c-7ee728ba8a83@openssl.org> References: <73d452bb-b863-8996-522c-7ee728ba8a83@openssl.org> Message-ID: <8843d95c270f4d4fbd875c48dedb2e8e@ncp-e.com> +1 > -----Original Message----- > From: openssl-project On Behalf Of Dr Paul Dale > Sent: Tuesday, February 2, 2021 10:07 AM > To: openssl-project at openssl.org > Subject: OTC VOTE: functions not conforming to the TYPE_NAME_action_name naming scheme are defects > > topic: Where a function does not use the TYPE_NAME_action_name naming > scheme, > ?????? it is considered to be a defect. > comment: These are not considered blockers for 3.0 if the function > existed in > ???????? 1.1.1.? New functions that do not conform must be fixed before > release. > Proposed by pauli. > Public: yes > opened: 2020-02-02 > closed: 2020-02-02 > accepted:? yes? (for: 5, against: 0, abstained: 3, not voted: 3) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7494 bytes Desc: not available URL: From Matthias.St.Pierre at ncp-e.com Tue Feb 2 11:28:16 2021 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 2 Feb 2021 11:28:16 +0000 Subject: OTC Vote: EVP init functions should accept an OSSL_PARAM array to set parameters. In-Reply-To: <4a83dd4e-75a8-0ece-3e2f-f35d692d7a56@openssl.org> References: <4a83dd4e-75a8-0ece-3e2f-f35d692d7a56@openssl.org> Message-ID: <178f68dd36764bba815537ec6fec9a52@ncp-e.com> +1 I recall that in our discussion the OSSL_PARAM array pointer was intended to be optional, i.e., NULL pointers allowed. Maybe the word 'optional' should be added as follows? EVP init functions should accept an *optional* OSSL_PARAM array to set parameters. > -----Original Message----- > From: openssl-project On Behalf Of Dr Paul Dale > Sent: Tuesday, February 2, 2021 10:18 AM > To: openssl-project at openssl.org > Subject: OTC Vote: EVP init functions should accept an OSSL_PARAM array to set parameters. > > topic: EVP init functions should accept an OSSL_PARAM array to set > parameters. > comment: This will mostly avoid calling the equivalent set_param call. > Proposed by pauli. > Public: yes > opened: 2020-02-02 > closed: 2020-02-02 > accepted:? yes? (for: 8, against: 0, abstained: 1, not voted: 2) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7494 bytes Desc: not available URL: From tm at t8m.info Tue Feb 2 11:31:49 2021 From: tm at t8m.info (Tomas Mraz) Date: Tue, 02 Feb 2021 12:31:49 +0100 Subject: OTC Vote: EVP init functions should accept an OSSL_PARAM array to set parameters. In-Reply-To: <178f68dd36764bba815537ec6fec9a52@ncp-e.com> References: <4a83dd4e-75a8-0ece-3e2f-f35d692d7a56@openssl.org> <178f68dd36764bba815537ec6fec9a52@ncp-e.com> Message-ID: <6aa47de65db47b1717103b4546556b90997a227a.camel@t8m.info> We discussed that within the call. We did not add the 'optional' word because the meaning of it is convoluted with the parameter being really optional (as in fn(a, b, ...)). That the caller can pass NULL as OSSL_PARAM array pointer is already implicit. On Tue, 2021-02-02 at 11:28 +0000, Dr. Matthias St. Pierre wrote: > +1 > > I recall that in our discussion the OSSL_PARAM array pointer was > intended to be optional, > i.e., NULL pointers allowed. Maybe the word 'optional' should be > added as follows? > > EVP init functions should accept an *optional* OSSL_PARAM array to > set parameters. > > > > -----Original Message----- > > From: openssl-project On > > Behalf Of Dr Paul Dale > > Sent: Tuesday, February 2, 2021 10:18 AM > > To: openssl-project at openssl.org > > Subject: OTC Vote: EVP init functions should accept an OSSL_PARAM > > array to set parameters. > > > > topic: EVP init functions should accept an OSSL_PARAM array to set > > parameters. > > comment: This will mostly avoid calling the equivalent set_param > > call. > > Proposed by pauli. > > Public: yes > > opened: 2020-02-02 > > closed: 2020-02-02 > > accepted: yes (for: 8, against: 0, abstained: 1, not voted: 2) -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From ivan.ristic at gmail.com Tue Feb 2 20:17:11 2021 From: ivan.ristic at gmail.com (Ivan Ristic) Date: Tue, 2 Feb 2021 20:17:11 +0000 Subject: OpenSSL Cookbook 3ed has been released Message-ID: Hello list, A couple of months ago I mentioned the imminent release of the next edition of my OpenSSL Cookbook. Just wanted to let you know that the 3rd edition is now out and freely available to everyone. This is a big update with many improvements and coverage of the latest stable version. https://www.feistyduck.com/books/openssl-cookbook/ Matt, thanks again for your help :) Cheers. -- Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Feb 5 10:44:05 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 5 Feb 2021 10:44:05 +0000 Subject: Monthly Status Report (January) Message-ID: As well as normal reviews, responding to user queries, wiki user requests, OMC business, support customer issues, CLA submissions, handling security reports, etc., key activities this month: - Attendance at the regular OTC meetings - Attendance at the OMC meeting - Attended meetings with the FIPS lab - Fixed a bug with TLS stitched stream ciphers - Performed alpha10 release - Fixed the "enable-weak-ssl-ciphers" option - Completed the PR started in December fixing various threading issues (finally fixing 6 different issues in one PR) - Implemented an SRP constant time fix as a result of a security report - Removed some dubious code that copied key parameters from the private key into the public key in libssl - Fixed a bug relating to obtaining the default digest for an EVP_PKEY when using provider side keys - Fixed the no-dh and no-dsa options - Implemented a large PR to remove compile time algorithm checks from libssl - Provided a fix to ensure that it was still possible to use EC keys which don't have the public key set - Fixed running mingw dhparam test under wine - Implemented a second PR to fix various additional threading issues Matt From pauli at openssl.org Tue Feb 9 10:15:50 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 9 Feb 2021 20:15:50 +1000 Subject: OTC vote: change PKCS #12 defaults Message-ID: topic: Change PKCS#12 creation to use AES-256-CBC and SHA-256 by default. comment: Both app and API, inlcude CHANGES entry. Proposed by Pauli. Public: yes opened: 2020-02-09 closed: 2020-02-09 accepted:? yes? (for: 8, against: 0, abstained: 0, not voted: 3) From matt at openssl.org Tue Feb 9 17:33:54 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 9 Feb 2021 17:33:54 +0000 Subject: Forthcoming OpenSSL Release Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.1j. This release will be made available on Tuesday 16th February 2021 between 1300-1700 UTC. OpenSSL 1.1.1j is a security-fix release. The highest severity issue fixed in this release is MODERATE: https://www.openssl.org/policies/secpolicy.html#moderate Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmAix4IACgkQ2cTSbQ5g RJEObwgAkM5/Nx3KjqX1Uj69C6b+8Cxx2ijdfei4wQjkVhLqZLteZpKDE0QBAHsV wGc3cwv1AyPnNfgWvfUwj0k5mRr67fYkz+iAJiNisLc40k0+xPd9F2F804TvKQh2 6HPRY2+AEpQD6nuxJejIOBZruDbFaXRzh1rloQggE9tqUoLslQbYhkrR6BRiePqN zQarux5yBZDfkQzkaYTDqFH5M6RLrb3w5hlJiJ4uJ1lLz4FNyeUtADofluiIrJuj zDRZxocOVoyUt2wIZZ+2xhMY894hlilwnBE+fXvWu5d4HakdZkHe4p+HFvP/O0IY AGn/qXIQfYGt9jH93jCPFdrgO/jvWA== =ZcL6 -----END PGP SIGNATURE----- From openssl at openssl.org Tue Feb 16 16:12:43 2021 From: openssl at openssl.org (OpenSSL) Date: Tue, 16 Feb 2021 16:12:43 +0000 Subject: OpenSSL version 1.1.1j published Message-ID: <20210216161243.GA15166@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.1j 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.1j 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.1j 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.1j.tar.gz Size: 9823161 SHA1 checksum: 04c340b086828eecff9df06dceff196790bb9268 SHA256 checksum: aaf2fcb575cdf6491b98ab4829abf78a3dec8402b8b81efc8f23c00d443981bf The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1j.tar.gz openssl sha256 openssl-1.1.1j.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmAr45gACgkQ2cTSbQ5g RJFhXAf7BMbLDUqKxw1YnGpUTXRTKe1TSzrOPI/m/yfyn3YHm64HYwTxNy8Idm9Y V+78djXqhs3VMDDu9ZOmopSLEOOOHvpKE89kj7pHrYnOJcmPE+HNmS0qneOyQZtb slvYbDhqeyEqNxy/jVlz6Bm/BV57HdbszpAzhv9zTP6hf6aYvNwIFJoPpHznu028 Knn+qrlkcHizKPY9zG1h8zfK9m6CWGV+S8qeKHERgvlKBz6hAOYC/3f6sZumRr7K m7jEEjkEvjVzcojXKoY2+C9yeRwJdj8GM2Haa+kdwcW34o4uCOrP+mW+MeBg+4qM id26+r6cNtTdv7jE4gPWLCKoOZ7CsA== =baPF -----END PGP SIGNATURE----- From openssl at openssl.org Tue Feb 16 16:27:22 2021 From: openssl at openssl.org (OpenSSL) Date: Tue, 16 Feb 2021 16:27:22 +0000 Subject: OpenSSL Security Advisory Message-ID: <20210216162722.GA18992@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL Security Advisory [16 February 2021] ============================================ Null pointer deref in X509_issuer_and_serial_hash() (CVE-2021-23841) ==================================================================== Severity: Moderate The OpenSSL public API function X509_issuer_and_serial_hash() attempts to create a unique hash value based on the issuer and serial number data contained within an X509 certificate. However it fails to correctly handle any errors that may occur while parsing the issuer field (which might occur if the issuer field is maliciously constructed). This may subsequently result in a NULL pointer deref and a crash leading to a potential denial of service attack. The function X509_issuer_and_serial_hash() is never directly called by OpenSSL itself so applications are only vulnerable if they use this function directly and they use it on certificates that may have been obtained from untrusted sources. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However 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.2y. Other users should upgrade to 1.1.1j. This issue was reported to OpenSSL on 15th December 2020 by Tavis Ormandy from Google. The fix was developed by Matt Caswell. Incorrect SSLv2 rollback protection (CVE-2021-23839) ==================================================== Severity: Low OpenSSL 1.0.2 supports SSLv2. If a client attempts to negotiate SSLv2 with a server that is configured to support both SSLv2 and more recent SSL and TLS versions then a check is made for a version rollback attack when unpadding an RSA signature. Clients that support SSL or TLS versions greater than SSLv2 are supposed to use a special form of padding. A server that supports greater than SSLv2 is supposed to reject connection attempts from a client where this special form of padding is present, because this indicates that a version rollback has occurred (i.e. both client and server support greater than SSLv2, and yet this is the version that is being requested). The implementation of this padding check inverted the logic so that the connection attempt is accepted if the padding is present, and rejected if it is absent. This means that such as server will accept a connection if a version rollback attack has occurred. Further the server will erroneously reject a connection if a normal SSLv2 connection attempt is made. Only OpenSSL 1.0.2 servers from version 1.0.2s to 1.0.2x are affected by this issue. In order to be vulnerable a 1.0.2 server must: 1) have configured SSLv2 support at compile time (this is off by default), 2) have configured SSLv2 support at runtime (this is off by default), 3) have configured SSLv2 ciphersuites (these are not in the default ciphersuite list) OpenSSL 1.1.1 does not have SSLv2 support and therefore is not vulnerable to this issue. The underlying error is in the implementation of the RSA_padding_check_SSLv23() function. This also affects the RSA_SSLV23_PADDING padding mode used by various other functions. Although 1.1.1 does not support SSLv2 the RSA_padding_check_SSLv23() function still exists, as does the RSA_SSLV23_PADDING padding mode. Applications that directly call that function or use that padding mode will encounter this issue. However since there is no support for the SSLv2 protocol in 1.1.1 this is considered a bug and not a security issue in that version. 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.2y. Other users should upgrade to 1.1.1j. This issue was reported to OpenSSL on 21st January 2021 by D. Katz and Joel Luellwitz from Trustwave. The fix was developed by Matt Caswell. Integer overflow in CipherUpdate (CVE-2021-23840) ================================================= Severity: Low Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However 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.2y. Other users should upgrade to 1.1.1j. This issue was reported to OpenSSL on 13th December 2020 by Paul Kehrer. 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 these issues on OpenSSL 1.1.0 has not been analysed. Users of these versions should upgrade to OpenSSL 1.1.1. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20210216.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----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmAr8gYACgkQ2cTSbQ5g RJFzowf/UF+mnAAOuOEO+aNIsMSnuzeylkAtKXnSHEa1uKeLd1udlLls75WUCW0R d8PfDrAMuYn7XQdQ/NalQ52teES0+XNGG6+s8FukmAiaCYIzu4Ko0C0VJK0BuaJk fa5DCPec+XzudqqLAgxzfV+lRakCf/ARfBoT1/JRXHXv3VIUXFN/QEonjbpxmH3C czWqOiPyZ+gY7MKlGer8AohQtc+GjQRSJKpUzW76Itr0MlzUlitnLs4VK16Tu1pc b6sruEl4/ukAodvTUkVLaDDNqEgtYK676ABJ8h2L+Muy7s+ZY34sKSbhN76E4I1h YGqcOFFEerFiZivfyqdbrLNUxKLMkA== =NAqk -----END PGP SIGNATURE----- From openssl at openssl.org Thu Feb 18 15:37:49 2021 From: openssl at openssl.org (OpenSSL) Date: Thu, 18 Feb 2021 15:37:49 +0000 Subject: OpenSSL version 3.0.0-alpha12 published Message-ID: <20210218153749.GA15169@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.0 alpha 12 released ===================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 12 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha12.tar.gz Size: 14142492 SHA1 checksum: fbcb255c1bf11928f4bd52b8cf68ab8341238d4f SHA256 checksum: 8d78239be66af578b969441252e7c125aa134ef3b9bac6179d84275cfe01950c The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha12.tar.gz openssl sha256 openssl-3.0.0-alpha12.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmAugwwACgkQ2cTSbQ5g RJHuyQgApX0LV7z8tmxqPNyMIfLMMnlFfV7m4YcblXN6YO+wDwFiX3KgnopGvfim 0B8pGPxkwJjPhLQxGyZ4fUkTMEJ3jtp+ncVf7+ccF7JfKkh1bjBmmSBZ0GhJPqhB HGxdb+cNe0rQFxXoWU5s8YmV4ImmPzUOhMKMP3b/lUJZpzlmriMw5QxbTc/dk96J 5wVf36sHbMPbAQlVrzRXLDWSacUXLVk4D4C9KJ1xt3Ri6RsWdlx6Z4N+dzhxOwP3 kyIzJAckQ8x3f8cAYu9CEgncLquUVO9vnC3CsbK6rfqNuGu6FzhDGYRzf5nn6NVd 4AAM/zKCkUlyufNVGQa7O96mkG6fsQ== =BcMo -----END PGP SIGNATURE----- From matt at openssl.org Tue Feb 23 10:18:48 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 23 Feb 2021 10:18:48 +0000 Subject: VOTE: Calling a free function on an algorithm method Message-ID: <6d63ac33-00be-03b7-b88d-97ea113fad94@openssl.org> topic: We allow calling a free function on an algorithm method for methods that were not fetched. The free function does nothing in that case. EVP_MD_CTX_md will be deprecated and documented as having "get0" semantics. We will replace it with EVP_MD_CTX_get0_md and EVP_MD_CTX_get1_md. We should do the same for other similar functions Proposed by Matt Caswell Public: yes opened: 2021-02-23 closed: 2021-02-23 accepted: yes (for: 4, against: 0, abstained: 5, not voted: 2) Matt [+1] Mark [ ] Pauli [ 0] Viktor [ ] Tim [+1] Richard [ 0] Shane [+0] Tomas [+0] Kurt [ 0] Matthias [+1] Nicola [+1] From tomas at openssl.org Tue Feb 23 10:21:41 2021 From: tomas at openssl.org (Tomas Mraz) Date: Tue, 23 Feb 2021 11:21:41 +0100 Subject: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely Message-ID: topic: The RSA_SSLV23_PADDING and related functions should be completely removed from OpenSSL 3.0 code. comment: The padding mode and the related functions (which are already deprecated in the current master branch) is useless outside of SSLv2 support. We do not support SSLv2 and we do not expect anybody using OpenSSL 3.0 to try to support SSLv2 by calling those functions. Proposed by Tomas Mraz. public: yes opened: 2021-02-23 From tomas at openssl.org Tue Feb 23 10:25:30 2021 From: tomas at openssl.org (Tomas Mraz) Date: Tue, 23 Feb 2021 11:25:30 +0100 Subject: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely In-Reply-To: References: Message-ID: <93d242892838b802077f17ec3a442b6e4f754429.camel@openssl.org> +1 from me of course On Tue, 2021-02-23 at 11:21 +0100, Tomas Mraz wrote: > topic: The RSA_SSLV23_PADDING and related functions should be > completely removed from OpenSSL 3.0 code. > > comment: The padding mode and the related functions (which are > already > deprecated in the current master branch) is useless outside of SSLv2 > support. We do not support SSLv2 and we do not expect anybody using > OpenSSL 3.0 to try to support SSLv2 by calling those functions. > > Proposed by Tomas Mraz. > > public: yes > opened: 2021-02-23 > > > From pauli at openssl.org Tue Feb 23 12:02:29 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 23 Feb 2021 22:02:29 +1000 Subject: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely In-Reply-To: References: Message-ID: <0eff0746-e650-5421-55e6-2b4e6edd61a2@openssl.org> +1 here too. Pauli On 23/2/21 8:21 pm, Tomas Mraz wrote: > topic: The RSA_SSLV23_PADDING and related functions should be > completely removed from OpenSSL 3.0 code. > > comment: The padding mode and the related functions (which are already > deprecated in the current master branch) is useless outside of SSLv2 > support. We do not support SSLv2 and we do not expect anybody using > OpenSSL 3.0 to try to support SSLv2 by calling those functions. > > Proposed by Tomas Mraz. > > public: yes > opened: 2021-02-23 > > > From matt at openssl.org Tue Feb 23 12:05:19 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 23 Feb 2021 12:05:19 +0000 Subject: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely In-Reply-To: References: Message-ID: 0 On 23/02/2021 10:21, Tomas Mraz wrote: > topic: The RSA_SSLV23_PADDING and related functions should be > completely removed from OpenSSL 3.0 code. > > comment: The padding mode and the related functions (which are already > deprecated in the current master branch) is useless outside of SSLv2 > support. We do not support SSLv2 and we do not expect anybody using > OpenSSL 3.0 to try to support SSLv2 by calling those functions. > > Proposed by Tomas Mraz. > > public: yes > opened: 2021-02-23 > > > From tjh at cryptsoft.com Tue Feb 23 13:12:00 2021 From: tjh at cryptsoft.com (Tim Hudson) Date: Tue, 23 Feb 2021 23:12:00 +1000 Subject: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely In-Reply-To: References: Message-ID: 0 Tim. On Tue, Feb 23, 2021 at 8:21 PM Tomas Mraz wrote: > topic: The RSA_SSLV23_PADDING and related functions should be > completely removed from OpenSSL 3.0 code. > > comment: The padding mode and the related functions (which are already > deprecated in the current master branch) is useless outside of SSLv2 > support. We do not support SSLv2 and we do not expect anybody using > OpenSSL 3.0 to try to support SSLv2 by calling those functions. > > Proposed by Tomas Mraz. > > public: yes > opened: 2021-02-23 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at openssl.org Tue Feb 23 14:13:04 2021 From: mark at openssl.org (Mark J Cox) Date: Tue, 23 Feb 2021 14:13:04 +0000 Subject: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely In-Reply-To: References:

Message-ID: 0 On Tue, Feb 23, 2021 at 1:12 PM Tim Hudson wrote: > 0 > > Tim. > > On Tue, Feb 23, 2021 at 8:21 PM Tomas Mraz wrote: > >> topic: The RSA_SSLV23_PADDING and related functions should be >> completely removed from OpenSSL 3.0 code. >> >> comment: The padding mode and the related functions (which are already >> deprecated in the current master branch) is useless outside of SSLv2 >> support. We do not support SSLv2 and we do not expect anybody using >> OpenSSL 3.0 to try to support SSLv2 by calling those functions. >> >> Proposed by Tomas Mraz. >> >> public: yes >> opened: 2021-02-23 >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Tue Feb 23 14:14:39 2021 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 23 Feb 2021 14:14:39 +0000 Subject: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely In-Reply-To: <93d242892838b802077f17ec3a442b6e4f754429.camel@openssl.org> References: <93d242892838b802077f17ec3a442b6e4f754429.camel@openssl.org> Message-ID: +1 > -----Original Message----- > From: openssl-project On Behalf Of Tomas Mraz > Sent: Tuesday, February 23, 2021 11:26 AM > To: openssl-project at openssl.org > Subject: Re: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely > > +1 from me of course > > On Tue, 2021-02-23 at 11:21 +0100, Tomas Mraz wrote: > > topic: The RSA_SSLV23_PADDING and related functions should be > > completely removed from OpenSSL 3.0 code. > > > > comment: The padding mode and the related functions (which are > > already > > deprecated in the current master branch) is useless outside of SSLv2 > > support. We do not support SSLv2 and we do not expect anybody using > > OpenSSL 3.0 to try to support SSLv2 by calling those functions. > > > > Proposed by Tomas Mraz. > > > > public: yes > > opened: 2021-02-23 > > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7494 bytes Desc: not available URL: From kurt at roeckx.be Tue Feb 23 17:35:53 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 23 Feb 2021 18:35:53 +0100 Subject: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely In-Reply-To: References: Message-ID: On Tue, Feb 23, 2021 at 11:21:41AM +0100, Tomas Mraz wrote: > topic: The RSA_SSLV23_PADDING and related functions should be > completely removed from OpenSSL 3.0 code. +1 Kurt From shane.lontis at oracle.com Tue Feb 23 22:33:14 2021 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Wed, 24 Feb 2021 08:33:14 +1000 Subject: [External] : OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely In-Reply-To: References: Message-ID: 0 > On 23 Feb 2021, at 8:21 pm, Tomas Mraz wrote: > > topic: The RSA_SSLV23_PADDING and related functions should be > completely removed from OpenSSL 3.0 code. > > comment: The padding mode and the related functions (which are already > deprecated in the current master branch) is useless outside of SSLv2 > support. We do not support SSLv2 and we do not expect anybody using > OpenSSL 3.0 to try to support SSLv2 by calling those functions. > > Proposed by Tomas Mraz. > > public: yes > opened: 2021-02-23 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Feb 24 10:34:09 2021 From: levitte at openssl.org (Richard Levitte) Date: Wed, 24 Feb 2021 11:34:09 +0100 Subject: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely In-Reply-To: References: Message-ID: <874ki1pxem.wl-levitte@openssl.org> 0 On Tue, 23 Feb 2021 11:21:41 +0100, Tomas Mraz wrote: > > topic: The RSA_SSLV23_PADDING and related functions should be > completely removed from OpenSSL 3.0 code. > > comment: The padding mode and the related functions (which are already > deprecated in the current master branch) is useless outside of SSLv2 > support. We do not support SSLv2 and we do not expect anybody using > OpenSSL 3.0 to try to support SSLv2 by calling those functions. > > Proposed by Tomas Mraz. > > public: yes > opened: 2021-02-23 > > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Wed Feb 24 21:59:03 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 24 Feb 2021 19:59:03 -0200 Subject: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely In-Reply-To: References: Message-ID: <5E0DEDF8-3509-4E66-B561-AECCD82B0771@dukhovni.org> Is there an open pull request for this? > On Feb 23, 2021, at 8:21 AM, Tomas Mraz wrote: > > topic: The RSA_SSLV23_PADDING and related functions should be > completely removed from OpenSSL 3.0 code. > > comment: The padding mode and the related functions (which are already > deprecated in the current master branch) is useless outside of SSLv2 > support. We do not support SSLv2 and we do not expect anybody using > OpenSSL 3.0 to try to support SSLv2 by calling those functions. I am inclined to vote yes on general grounds, but my concern is whether this might then cause some downstream consumers of OpenSSL to fail to compile (things like Python bindings to OpenSSL, Net::SSLeay, ...) It may be prudent to leave some stub functions in place that just return errors, if they're currently exposed in various tools, and likely unused, but would still cause some pain to the downstream API maintainers if entirely removed. Are there any such functions exposed by popular toolkits? -- Viktor. From tomas at openssl.org Thu Feb 25 08:26:18 2021 From: tomas at openssl.org (Tomas Mraz) Date: Thu, 25 Feb 2021 09:26:18 +0100 Subject: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely In-Reply-To: <5E0DEDF8-3509-4E66-B561-AECCD82B0771@dukhovni.org> References: <5E0DEDF8-3509-4E66-B561-AECCD82B0771@dukhovni.org> Message-ID: On Wed, 2021-02-24 at 19:59 -0200, Viktor Dukhovni wrote: > Is there an open pull request for this? No there isn't yet, but Rich Salz was working on deprecation of this and he is willing to change the PR to do removal instead. > > On Feb 23, 2021, at 8:21 AM, Tomas Mraz wrote: > > > > topic: The RSA_SSLV23_PADDING and related functions should be > > completely removed from OpenSSL 3.0 code. > > > > comment: The padding mode and the related functions (which are > > already > > deprecated in the current master branch) is useless outside of > > SSLv2 > > support. We do not support SSLv2 and we do not expect anybody using > > OpenSSL 3.0 to try to support SSLv2 by calling those functions. > > I am inclined to vote yes on general grounds, but my concern is > whether > this might then cause some downstream consumers of OpenSSL to fail to > compile (things like Python bindings to OpenSSL, Net::SSLeay, ...) > > It may be prudent to leave some stub functions in place that just > return errors, if they're currently exposed in various tools, and > likely unused, but would still cause some pain to the downstream > API maintainers if entirely removed. > > Are there any such functions exposed by popular toolkits? I did not do any serious research but I know that M2Crypto provides such bindings. So there definitely are cases where the various bindings implementations will have to be adjusted. I do not see that as a reason to block the removal as the bindings really will have to be adjusted for 3.0 for other reasons anyway. We do not promise 100% API compatibility with 1.1.1. Also in case of the M2Crypto bindings they will already fail with 1.1.1 because they tested for the incorrect behavior that was fixed by the recent related CVE fix. Tomas From tomas at openssl.org Thu Feb 25 09:22:29 2021 From: tomas at openssl.org (Tomas Mraz) Date: Thu, 25 Feb 2021 10:22:29 +0100 Subject: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely In-Reply-To: References: Message-ID: <63faf8b1a5fb41178570622148c636488327c566.camel@openssl.org> The vote is now closed: topic: The RSA_SSLV23_PADDING and related functions should be completely removed from OpenSSL 3.0 code. Proposed by Tomas Mraz Public: yes opened: 2021-02-23 closed: 2021-02-28 accepted: yes (for: 6, against: 0, abstained: 5, not voted: 0) Tomas