sts-sponsors team mailing list archive

[Dan Streetman <1940141@xxxxxxxxxxxxxxxxxx>]

> It's not needed for actual functionality of the backport but that
assumes that any future backports or fixes don't break this backport

yes i get that, my comment is about whether or not the patch changes any
code *outside* of the self-tests, e.g. the TLSProxy perl code changes.
If that's *only* used for self-tests then including in the backport
shouldn't cause any regression.

Remember that people reviewing/sponsoring patches may not have deep
experience with the code so it's good to more clearly explain things
that aren't necessarily obvious, such as the 2nd patch only affecting
test code (if that is indeed the case), since at first glance that isn't
what it looks like.

-- 
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:
  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