OpenSSL used in binary builds needs updating for CVE-2023-0286

[gpshead]

https://www.openssl.org/news/secadv/20230207.txt
https://nvd.nist.gov/vuln/detail/CVE-2023-0286

The just released binaries on Windows and macOS were all build using 1.1.1s, we need to use 1.1.1t in the release branches.

Linked PRs

• gh-101726: Update the OpenSSL version to 1.1.1t #101727
• [3.11] gh-101726: Update the OpenSSL version to 1.1.1t (GH-101727) #101749
• [3.10] gh-101726: Update the OpenSSL version to 1.1.1t (GH-101727) #101750
• [3.9] gh-101726: Update the OpenSSL version to 1.1.1t (GH-101727) #101751
• [3.8] gh-101726: Update the OpenSSL version to 1.1.1t (GH-101727) #101752
• [3.7] gh-101726: Update the OpenSSL version to 1.1.1t (GH-101727) #101753

[zooba]

My read of the impact to us:

• CVE-2023-0286 requires users to enable CRL checking, as it appears that we don't do anything besides provide the constants. Also, from the advisory: "In most cases, the attack requires the attacker to provide both the certificate chain and CRL", which suggests a more appropriate mitigation (don't use an attacker's revocation list :) )
• CVE-2022-4304 is a timing oracle requiring a very large number of requests. I suspect natural variation would make this infeasible over an actual network, but if it can be demoed, this seems like the biggest issue for us.
• CVE-2022-4203 requires a CA-signed certificate, and at worst may cause a crash. In any case, doesn't impact OpenSSL 1.1
• CVE-2023-0215 and CVE-2023-4450 impact BIO_new_NDEF and PEM_read_bio_ex which we neither use nor expose
• Remaining issues don't affect 1.1

So I think the only concerning one is the timing oracle, and it doesn't concern me enough to trigger a new round of releases.

However, I'm also concerned by the near certainty that we'll be criticised (again) for not immediately reacting, so if we'd rather not keep patiently explaining to nervous people that we aren't impacted, we could schedule new releases.