sts-sponsors team mailing list archive
-
sts-sponsors team
-
Mailing list archive
-
Message #03124
[Bug 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest
Attach debdiff relative to 18.04.17:
openssl (1.1.1-1ubuntu2.1~18.04.17ubuntu1) bionic; urgency=medium
* Backport pr9780:
- d/p/pr9780_0001-Don-t-send-a-status_request-extension-in-a-Certifica.patch
- d/p/pr9780_0002-Teach-TLSProxy-how-to-parse-CertificateRequest-messa.patch
-- Bruce Elrick <bruce.elrick@xxxxxxxxxxxxx> Mon, 09 May 2022 19:38:43
+0000
** Patch added: "openssl_1.1.1-1ubuntu2.1~18.04.17ubuntu1.debdiff"
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+attachment/5587970/+files/openssl_1.1.1-1ubuntu2.1~18.04.17ubuntu1.debdiff
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1940141
Title:
OpenSSL servers can send a non-empty status_request in a
CertificateRequest
Status in openssl package in Ubuntu:
Fix Released
Status in openssl source package in Bionic:
Fix Committed
Bug description:
[Impact]
openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a
CertificateRequest message to the client with a non-empty
status_request extension.
This issue was fixed in openssl-1.1.1d and is included in Focal
onward.
Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767
Upstream patch review at https://github.com/openssl/openssl/pull/9780
The issue leads to various client failures with TLS 1.3 as described
in, e.g.
https://github.com/golang/go/issues/35722
https://github.com/golang/go/issues/34040
[Test Plan]
The issue can be reproduced by building with `enable-ssl-trace`
and then running `s_server` like this:
```
openssl s_server -key key.pem -cert cert.pem -status_file test/recipes/ocsp-response.der -Verify 5
```
And running `s_client` like this:
```
openssl s_client -status -trace -cert cert.pem -key key.pem
```
The output shows a `status_request` extension in the
`CertificateRequest` as follows:
Received Record
Header:
Version = TLS 1.2 (0x303)
Content Type = ApplicationData (23)
Length = 1591
Inner Content Type = Handshake (22)
CertificateRequest, Length=1570
request_context (len=0):
extensions, length = 1567
extension_type=status_request(5), length=1521
0000 - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2 ....0..........
000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01 0.....+.....0..
001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86 ....0...0......
002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47 0..1.0...U....G
...more lines omitted...
If the `status_request` extension is present in a
`CertificateRequest` then it must be empty according to RFC8446,
Sec. 4.4.2.1.
[Where problems could occur]
The patch disables the `status_request` extension inside a
`CertificateRequest`. Applications expecting the incorrect,
non-empty reply for the `status_request` extension will break
with this patch.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+subscriptions