| 2021-08-16 18:55:21 |
Nicolas Bock |
bug |
|
|
added bug |
| 2021-08-16 18:55:34 |
Nicolas Bock |
nominated for series |
|
Ubuntu Bionic |
|
| 2021-08-16 18:55:34 |
Nicolas Bock |
bug task added |
|
openssl (Ubuntu Bionic) |
|
| 2021-08-16 18:58:35 |
Nicolas Bock |
attachment added |
|
bionic.debdiff https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+attachment/5518220/+files/bionic.debdiff |
|
| 2021-08-16 19:00:08 |
Nicolas Bock |
openssl (Ubuntu): assignee |
|
Nicolas Bock (nicolasbock) |
|
| 2021-08-16 19:00:16 |
Nicolas Bock |
openssl (Ubuntu Bionic): assignee |
|
Nicolas Bock (nicolasbock) |
|
| 2021-08-16 20:23:08 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2021-08-16 20:23:15 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2021-08-16 20:58:01 |
Nicolas Bock |
bug |
|
|
added subscriber STS Sponsors |
| 2021-08-19 01:07:55 |
Mathew Hodson |
openssl (Ubuntu): importance |
Undecided |
Medium |
|
| 2021-08-19 01:07:57 |
Mathew Hodson |
openssl (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2021-08-19 01:08:01 |
Mathew Hodson |
openssl (Ubuntu): status |
New |
Fix Released |
|
| 2021-08-19 17:17:36 |
Nicolas Bock |
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
[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. As a non-empty reply is incorrect behavior |
[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
[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. |
|
| 2021-08-27 19:43:24 |
Gabriel Muñoz |
bug |
|
|
added subscriber Gabriel Muñoz |
| 2021-08-27 19:53:41 |
Gabriel Muñoz |
bug |
|
|
added subscriber Netflix Engineering |
| 2021-09-12 20:23:19 |
Nicolas Bock |
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
[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. |
[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. |
|
| 2021-10-01 12:02:14 |
Dan Streetman |
tags |
patch |
patch sts-sponsor-ddstreet |
|
| 2021-10-01 12:06:15 |
Dan Streetman |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2022-03-18 15:04:57 |
Bruce Elrick |
attachment added |
|
Backport pr9780 but make it optional https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+attachment/5570447/+files/bionic.debdiff |
|
| 2022-03-18 15:31:14 |
Bruce Elrick |
bug |
|
|
added subscriber Bruce Elrick |
| 2022-03-23 16:51:27 |
Dan Streetman |
bug |
|
|
added subscriber Ubuntu Security Team |
| 2022-03-23 19:42:22 |
Bruce Elrick |
attachment added |
|
test-results.txt https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+attachment/5572296/+files/test-results.txt |
|
| 2022-04-05 14:38:30 |
Bruce Elrick |
openssl (Ubuntu Bionic): milestone |
|
bionic-updates |
|
| 2022-04-05 14:38:38 |
Bruce Elrick |
openssl (Ubuntu Bionic): milestone |
bionic-updates |
|
|
| 2022-04-28 13:38:42 |
Łukasz Zemczak |
openssl (Ubuntu Bionic): status |
New |
Fix Committed |
|
| 2022-04-28 13:38:44 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-04-28 13:38:47 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2022-04-28 13:38:50 |
Łukasz Zemczak |
tags |
patch sts-sponsor-ddstreet |
patch sts-sponsor-ddstreet verification-needed verification-needed-bionic |
|
| 2022-05-09 20:04:57 |
Bruce Elrick |
attachment 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 |
|
| 2022-05-10 11:39:05 |
Dan Streetman |
openssl (Ubuntu): assignee |
Nicolas Bock (nicolasbock) |
|
|
| 2022-05-10 11:39:17 |
Dan Streetman |
openssl (Ubuntu Bionic): assignee |
Nicolas Bock (nicolasbock) |
Bruce Elrick (virtuous-sloth) |
|
| 2022-05-10 11:39:21 |
Dan Streetman |
openssl (Ubuntu Bionic): status |
Fix Committed |
In Progress |
|
| 2022-05-10 11:39:32 |
Dan Streetman |
tags |
patch sts-sponsor-ddstreet verification-needed verification-needed-bionic |
patch sts-sponsor-ddstreet |
|
| 2022-05-18 12:00:06 |
Robie Basak |
openssl (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2022-05-18 12:00:11 |
Robie Basak |
tags |
patch sts-sponsor-ddstreet |
patch sts-sponsor-ddstreet verification-needed verification-needed-bionic |
|
| 2022-06-21 12:13:29 |
Marc Deslauriers |
tags |
patch sts-sponsor-ddstreet verification-needed verification-needed-bionic |
patch sts-sponsor-ddstreet verification-done verification-done-bionic |
|
| 2022-06-21 14:32:33 |
Launchpad Janitor |
openssl (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2022-06-21 14:32:33 |
Launchpad Janitor |
cve linked |
|
2022-1292 |
|
| 2022-06-21 14:32:33 |
Launchpad Janitor |
cve linked |
|
2022-2068 |
|
