[Bug 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest

[Dan Streetman]

for later reference, i'd discussed this with nick and asked him to check
if the 'status_request' reply contained any kind of valid data in the
specific cases where this patch will disable it; my concern is if there
is valid data in it, it's possible there are applications out there that
might currently expect and/or use it, even if it's against the RFC,
which might result in a regression after this patch. However, if the
reply is empty or just has garbage, it's unlikely that any application
is using it for anything currently, so there would be less chance of
causing a regression.

** Tags added: sts-sponsor-ddstreet

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to openssl in Ubuntu.
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:
  New

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