Ack, thank you for the candid feedback, it's helpful

On Tue, Aug 6, 2024, 6:10 PM Alex Gaynor <alex.gaynor () gmail com> wrote: Hi Neil,

Answering on behalf of the Python Cryptographic Authority, which develops pyca/cryptography, the most widely used Python cryptography library. We distribute binary builds that statically link a copy of OpenSSL.

1) Yes, we're fine with dropping TLS 1.0/1.1 on this time frame. Frankly, we'd be fine dropping it faster.

2) We would not re-enable TLS1.0/1.1 in our releases. Users wishing to use these protocols would be responsible for building and linking their own OpenSSL.

3) I don't have a good answer for you. I think systems programming is fairly impoverished in terms of ways to emit runtime warnings. I'd suggest focusing on compile-time warnings.

Alex

On Tue, Aug 6, 2024 at 7:29 AM Neil Horman <nhorman () openssl org> wrote: Neil Horman <nhorman () openssl org> 4:19 AM (42 minutes ago) to openssl-security

OpenSSL is currently considering the deprecation of the TLS 1.0/1.1 protocols. Currently TLS1.1 and TLS 1.0 are disabled at run time, and requires enablement by reducing the ssl security level value.

The current proposal under consideration is to explicitly disable TLS 1.0/1.1 at build time, in our 4.0 release (tentatively scheduled to release in the next 12-18 months), with an eye to completely remove the impacted code in a future major release. The default configuration could be overridden to re-enable TLS 1.0/1.1 at build time.

Questions to the community are:

1) Are distributions/users comfortable with this approach in the time frame proposed?

2) Would builders of OpenSSL consider using the default configuration (with TLS1.0/1.1 disabled in 4.0), or would they ship with these protocols re-enabled in their builds?

3) If the deprecated protocols are re-enabled, what would constitute a reasonable warning mechanism to inform users that these protocols are going away at some point in the future to pressure users to update to a newer, more secure protocol?

Input on these questions is requested and appreciated -- All that is necessary for evil to succeed is for good people to do nothing.

Hi Neil,

Answering on behalf of the Python Cryptographic Authority, which develops pyca/cryptography, the most widely used Python cryptography library. We distribute binary builds that statically link a copy of OpenSSL.

1) Yes, we're fine with dropping TLS 1.0/1.1 on this time frame. Frankly, we'd be fine dropping it faster.

2) We would not re-enable TLS1.0/1.1 in our releases. Users wishing to use these protocols would be responsible for building and linking their own OpenSSL.

3) I don't have a good answer for you. I think systems programming is fairly impoverished in terms of ways to emit runtime warnings. I'd suggest focusing on compile-time warnings.

Alex

On Tue, Aug 6, 2024 at 7:29 AM Neil Horman <nhorman () openssl org> wrote: Neil Horman <nhorman () openssl org> 4:19 AM (42 minutes ago) to openssl-security

OpenSSL is currently considering the deprecation of the TLS 1.0/1.1 protocols. Currently TLS1.1 and TLS 1.0 are disabled at run time, and requires enablement by reducing the ssl security level value.

The current proposal under consideration is to explicitly disable TLS 1.0/1.1 at build time, in our 4.0 release (tentatively scheduled to release in the next 12-18 months), with an eye to completely remove the impacted code in a future major release. The default configuration could be overridden to re-enable TLS 1.0/1.1 at build time.

Questions to the community are:

1) Are distributions/users comfortable with this approach in the time frame proposed?

2) Would builders of OpenSSL consider using the default configuration (with TLS1.0/1.1 disabled in 4.0), or would they ship with these protocols re-enabled in their builds?

3) If the deprecated protocols are re-enabled, what would constitute a reasonable warning mechanism to inform users that these protocols are going away at some point in the future to pressure users to update to a newer, more secure protocol?

Input on these questions is requested and appreciated -- All that is necessary for evil to succeed is for good people to do nothing.

https://github.com/pyca/cryptography/security/advisories/GHSA-jfhm-5ghh-2f97 reports:

------------------------------------------------------------------------------- Affected versions >= 3.1, < 41.0.6 Patched versions >=41.0.6

Summary PoC

Here is a Python code that triggers the issue: pemp7 = b""" -----BEGIN PKCS7----- MAsGCSqGSIb3DQEHAg== -----END PKCS7----- """

derp7 = b"\x30\x0B\x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x07\x02"

loadpempkcs7certificates(pemp7) loadderpkcs7certificates(derp7)

Impact -------------------------------------------------------------------------------

The fix was in https://github.com/pyca/cryptography/pull/9926

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

A buffer-overflow flaw was found in the python-cryptography package. In certain sequences of update() calls when symmetrically encrypting very large payloads (>2GB) could result in an integer overflow, leading to buffer overflows. Note: This fix is a workaround for the OpenSSL CVE-2021-23840 flaw. Source: pyca/cryptography project

HKDF in cryptography before 1.5.2 returns an empty byte-string if used with a length less than algorithm.digestsize.