openssl, branch OpenSSL_1_1_1j

Prepare for 1.1.1j release

2021-02-16T15:24:01Z

Reviewed-by: Richard Levitte

Update copyright year

2021-02-16T15:17:22Z

Reviewed-by: Richard Levitte

Update CHANGES and NEWS for new release

2021-02-16T12:33:40Z

Reviewed-by: Richard Levitte

Don't overflow the output length in EVP_CipherUpdate calls

2021-02-16T11:42:35Z

CVE-2021-23840 Reviewed-by: Paul Dale

Fix rsa_test to properly test RSA_SSLV23_PADDING

2021-02-16T11:38:22Z

We test all three cases: - An SSLv2 only client talking to a TLS capable server - A TLS capable client talking to an SSLv2 only server - A TLS capable client talking to a TLS capable server (should fail due to detecting a rollback attack) Reviewed-by: Paul Dale

Fix the RSA_SSLV23_PADDING padding type

2021-02-16T11:38:22Z

This also fixes the public function RSA_padding_check_SSLv23. Commit 6555a89 changed the padding check logic in RSA_padding_check_SSLv23 so that padding is rejected if the nul delimiter byte is not immediately preceded by at least 8 bytes containing 0x03. Prior to that commit the padding is rejected if it *is* preceded by at least 8 bytes containing 0x03. Presumably this change was made to be consistent with what it says in appendix E.3 of RFC 5246. Unfortunately that RFC is in error, and the original behaviour was correct. This is fixed in later errata issued for that RFC. This has no impact on libssl for modern versions of OpenSSL because there is no protocol support for SSLv2 in these versions. However applications that call RSA_paddin_check_SSLv23 directly, or use the RSA_SSLV23_PADDING mode may still be impacted. The effect of the original error is that an RSA message encrypted by an SSLv2 only client will fail to be decrypted properly by a TLS capable server, or a message encrypted by a TLS capable client will fail to decrypt on an SSLv2 only server. Most significantly an RSA message encrypted by a TLS capable client will be successfully decrypted by a TLS capable server. This last case should fail due to a rollback being detected. Thanks to D. Katz and Joel Luellwitz (both from Trustwave) for reporting this issue. CVE-2021-23839 Reviewed-by: Paul Dale

Refactor rsa_test

2021-02-16T11:38:22Z

Reduce code copying by factoring out common code into a separate function. Reviewed-by: Paul Dale

Test that X509_issuer_and_serial_hash doesn't crash

2021-02-16T11:34:03Z

Provide a certificate with a bad issuer and check that X509_issuer_and_serial_hash doesn't crash. Reviewed-by: Richard Levitte Reviewed-by: Paul Dale (cherry picked from commit 55869f594f052561b11a2db6a7c42690051868de)

Fix Null pointer deref in X509_issuer_and_serial_hash()

2021-02-16T11:34:02Z

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. CVE-2021-23841 Reviewed-by: Richard Levitte Reviewed-by: Paul Dale (cherry picked from commit 8130d654d1de922ea224fa18ee3bc7262edc39c0)

VMS documentation fixes

2021-02-12T14:54:31Z

This mostly clarifies details. Fixes #13789 Reviewed-by: Tomas Mraz (Merged from https://github.com/openssl/openssl/pull/13834)