The Ubuntu Security Team is okay with publishig the xenial openssl in
proposed (1.0.2g-1ubuntu4.20) to xenial-security and updates. I didn't
see any symbol changes or dependency changes in the binaries that would
have indicated that building against xenial-updates was a problem.

Thanks!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1928989

Title:
  expiring trust anchor compatibility issue

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Trusty:
  New
Status in openssl source package in Xenial:
  Fix Committed

Bug description:
  [Impact]

   * openssl fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install openssl ca-certificates wget
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

  test case:
  openssl s_client -connect expired-root-ca-test.germancoding.com:443 
-servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem

  bad result:
  connection failed
  verify depth is 1
  CONNECTED(00000003)
  depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Doctored Durian Root CA X3
  verify error:num=10:certificate has expired
  notAfter=Jan 30 14:01:15 2021 GMT
  140672978626200:error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:

  good result:
  connection successful

  verify depth is 1
  CONNECTED(00000003)
  depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = 
(STAGING) Pretend Pear X1
  verify return:1
  depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial 
Apricot R3
  verify return:1
  depth=0 CN = expired-root-ca-test.germancoding.com
  verify return:1
  ---
  Certificate chain
   0 s:/CN=expired-root-ca-test.germancoding.com
     i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
   1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
   2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend 
Pear X1
     i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored 
Durian Root CA X3
  ---
  Server certificate
  -----BEGIN CERTIFICATE-----

  Connection should be successful and trusted with correctly working
  openssl s_client that can manage to ignore expired CA, and build a
  valid trust path using non-expired CA in the chain.

  [Testcase #2]

  $ sudo apt install ca-certificates wget faketime

  # Good connectivity
  $ wget -O /dev/null https://canonical.com
  --2021-07-13 11:54:20--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2b, 
2001:67c:1360:8001::2c, 91.189.88.181, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2b|:443... 
connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 30933 (30K) [text/html]
  Saving to: '/dev/null'

  /dev/null               100%[============================>]  30.21K
  --.-KB/s    in 0.001s

  2021-07-13 11:54:20 (22.3 MB/s) - '/dev/null' saved [30933/30933]

  # Jump to october to experience failure
  $ faketime '2021-10-01' wget -O /dev/null https://canonical.com
  --2021-10-01 00:00:00--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2b, 
2001:67c:1360:8001::2c, 91.189.88.181, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2b|:443... 
connected.
  ERROR: cannot verify canonical.com's certificate, issued by 'CN=R3,O=Let\'s 
Encrypt,C=US':
    Issued certificate has expired.
  To connect to canonical.com insecurely, use `--no-check-certificate'.

  # upgrade to new openssl, to see that connectivity is restored, even in 
october
  $ dpkg-query -W libssl1.0.0
  libssl1.0.0:amd64     1.0.2g-1ubuntu4.20

  $ faketime '2021-10-01' wget -O /dev/null https://canonical.com
  --2021-10-01 00:00:00--  https://canonical.com/
  Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2c, 
2001:67c:1360:8001::2b, 91.189.88.180, ...
  Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2c|:443... 
connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 30933 (30K) [text/html]
  Saving to: '/dev/null'

  /dev/null               100%[============================>]  30.21K
  --.-KB/s    in 0.001s

  2021-10-01 00:00:00 (21.9 MB/s) - '/dev/null' saved [30933/30933]


  [Where problems could occur]

   * Changes as to how the trust paths are built in TLS connection may
  result in introducing bugs (failure to connect to valid sites) and/or
  security vulnerabilities (connecting to invalid sites successfully).

  [Other Info]

   * Background info
   * The current chain from letsencrypt is expiring, they are adding a new 
chain, but also keeping the expiring one. This will result in connectivity 
issues when using old gnutls/openssl against websites using the default 
letsencrypt configuration after September 2021.

  
https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
  
https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817

  Currently openssl in xenial and earlier will not establish a
  connection, if any parts of the trust chain have expired, even though
  alternative non-expired chains are available.

  This has been fixed in OpenSSL 1.1.0+ by setting
  X509_V_FLAG_TRUSTED_FIRST by default see
  
https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c

  Note only the new default flag is backported on its own. The other
  changes to more strongly verify additional auxiliary trust OIDs and
  key usage are not backported.

  gnutls bug for this is
  https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to