Regression for GMail after libssl upgrade with TLSv1.3

[pataquets]

[Impact]

 * Users of libc-client2007e (e.g., php7.x-imap) can no longer
   connect to GMail on Bionic and later, after introduction of
   TLSv1.3 with OpenSSL 1.1.1 (normal upgrade path in Bionic).

 * GMail requires Server Name Indication (SNI) to be set when
   TLSv1.3 is used, otherwise the server provided certificate
   fails verification in the client and connection is aborted.

 * The fix is to set SNI to the hostname that the client will
   perform verification on. The change is only enabled if the
   client is built with OpenSSL 1.1.1 or later (i.e., TLSv1.3
   support) so not to affect pre- TLSv1.3 support's behavior.

 * However it is functional nonetheless if the client is built
   with OpenSSL 1.1.1 or later but an earlier TLS version ends
   up used due to the handshake/negotiation/server TLS support
   (e.g., TLSv1.2); this shouldn't be a problem per test below.

 * Regression testing happened with a crawled list of IMAP/POP
   SSL servers (167 servers), and no regressions were observed.
   Actually, one more email provider/server has been fixed too.

 * OpenSSL-only demonstration with -(no)servername:

   $ echo QUIT \
     | openssl s_client \
       -connect imap.gmail.com:993 \
       -verify_hostname imap.gmail.com \
       -noservername `# or -servername imap.gmail.com` \
       -tls1_3 -brief 2>&1 \
     | grep -i ^verif

  Output with '-noservername':

  verify error:num=18:self signed certificate
  verify error:num=62:Hostname mismatch
  Verification error: Hostname mismatch

  Output with '-servername imap.gmail.com'

  Verification: OK
  Verified peername: imap.gmail.com

[Test Case]

 * Commands:

   $ sudo apt install uw-mailutils
   $ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"

   $ sudo apt install php7.2-cli php7.2-imap
   $ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'

 * Before:

   $ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
   Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
   Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid

   $ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
   PHP Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
   PHP Notice: Unknown: Certificate failure for imap.gmail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid (errflg=2) in Unknown on line 0

 * After:

   $ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
   {ce-in-f16.1e100.net/imap} username:
   ^C

   $ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");'
   PHP Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
   PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
   PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
   PHP Notice: Unknown: Can not authenticate to IMAP server: [ALERT] Invalid credentials (Failure) (errflg=2) in Unknown on line 0

 * Regression testing scripts/results are provided in attachments/comments.

[Regression Potential]

 * Theoretically possible, but not observed in hundred+ of (167)
   IMAP/POP SSL servers.

 * The change sends additional data (SNI) from client to server
   when connecting, if built with OpenSSL 1.1.1 or later, which
   is in the specification, so should be handled by the server.

 * The risk is servers that misbehave when provided such info
   (not observed in the 167 server test).

 * Less likely are servers that do not recognize the server name
   identified (this also not observed in test and unlikely since
   the client usually reaches the server by public/known address).

 * Even less likely are servers whose provided certificate doesn't
   contain the server name identified (again not observed and it's
   in the server, not client, to provide a certificate for address
   it doesn't recognize).

 * This both shows the SRU team that the risks have been considered,
   and provides guidance to testers in regression-testing the SRU.

[Other Info]

 * Reverse build dependencies have been patched for No Change Rebuilds
   and (re)built correctly on all architectures in Launchpad PPA for
   all affected releases (eoan, disco, bionic).

[Original Description]

After upgrading from PHP5 to PHP7.2 (from Bionic), calling imap_open() against Google's Gmail servers stopped working.
After researching, I've found that new OpenSSL version introduced TLSv13-related breaking changes.

Here are the relevant issues:
PHP: https://bugs.php.net/bug.php?id=77108
PHP (Debian): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041
In fetchmail (solved): https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786

OpenSSL upstream devs have issues related to this:
https://github.com/openssl/openssl/issues/5944
https://github.com/openssl/openssl/pull/5947

Looks like to me that either adding the SNI server name to the openssl open call would be needed, as done on fetchmail.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[David Zuelke (dzuelke)]

For some clarification: this is due to the upgrade to openssl 1.1.1 in bionic-upgrades, which includes TLSv1.3 support. This leads to connections being negotiated als TLSv1.3, and Google's IMAP servers reject the connection (by returning an invalid certificate with a message) if the attempt is not using SNI.

Here is a simple way to reproduce this, without a PHP script or anything:

$ apt-get install uw-mailutils
$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"

This will work if the OpenSSL 1.1.0 library is installed, but fail if 1.1.1 is there:

root@e6e4f3531a65:/app# mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
root@e6e4f3531a65:/app# openssl version
OpenSSL 1.1.0g 2 Nov 2017 (Library: OpenSSL 1.1.1 11 Sep 2018)

[David Zuelke (dzuelke)]

Here's a patch.

Before, when connecting to GMail IMAP with PHP:

root@39f3acd3838c:/app# php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "user", "pass") or die(imap_last_error());'

Warning: imap_open(): Couldn't open stream {imap.googlemail.com:993/imap/ssl}INBOX in /app/imap.php on line 6
Certificate failure for imap.googlemail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid

After the patch (the auth error is correct for those credentials obviously):

root@00b5d649f707:/app# php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "user", "pass") or die(imap_last_error());'

Warning: imap_open(): Couldn't open stream {imap.googlemail.com:993/imap/ssl}INBOX in /app/imap.php on line 5
Can not authenticate to IMAP server: [AUTHENTICATIONFAILED] Invalid credentials (Failure)

There is a similar patch at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041, but that uses an OpenSSL version check instead of the IMO better #ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "uw-imap-sni.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[David Zuelke (dzuelke)]

New patch that's RFC 6066 compliant (SNI may only be done for hostnames, not for IP addresses).

[David Zuelke (dzuelke)]

Another small update to the patch, just in case anyone wants to build it against OpenSSL versions older than 1.0.2 (let's say on Ubuntu 12.04).

It now checks for the OpenSSL version instead of for SSL_CTRL_SET_TLSEXT_HOSTNAME (which has been around since 0.9.8.something, so this change is safe in that regard). The a2i_IPADDRESS function was introduced in 1.0.2; the patch calls it to determine if the ServerName TLS extension info should be set (SNI is not allowed for IP addresses, just for hostnames).

For anything before OpenSSL 1.0.2 (because a2i_IPADDRESS is not available there), SNI wouldn't be done.

Since nothing before OpenSSL 1.1.1 supports TLSv1.3 anyway (and that's when the problem occurs in the first place), that approach seems better.

P.S. have the info on a2i_IPADDRESS version availability from https://github.com/python/cpython/commit/e9370a47389903bb72badc95032ec84a0ebbf8cc, which does even more extra correct things for ancient OpenSSL versions, but that doesn't apply to Ubuntu.

[Mauricio Faria de Oliveira (mfo)]

Packages with run-time dependency / shared library / libc-client2007e (no changes required):
---

$ reverse-depends libc-client2007e
Reverse-Depends
===============
* asterisk-voicemail-imapstorage
* libc-client2007e-dev
* mailsync
* php7.2-imap
* php7.3-imap
* prayer
* uw-mailutils

Packages with build-time dependency / static library / libc-client2007e-dev (rebuild required):

$ reverse-depends -b libc-client2007e-dev
Reverse-Build-Depends
=====================
* asterisk
* mailsync
* prayer

P.S.: build-dep list obtained from Eoan's deb-src lines from all pockets with all components:

$ for pocket in $(lsb_release -cs){,-{updates,proposed,backports,security}}; do echo "deb-src http://archive.ubuntu.com/ubuntu $pocket main restricted universe multiverse"; done | sudo tee /etc/apt/sources.list.d/all-sources.list

$ cat /etc/apt/sources.list.d/all-sources.list
deb-src http://archive.ubuntu.com/ubuntu eoan main restricted universe multiverse
deb-src http://archive.ubuntu.com/ubuntu eoan-updates main restricted universe multiverse
deb-src http://archive.ubuntu.com/ubuntu eoan-proposed main restricted universe multiverse
deb-src http://archive.ubuntu.com/ubuntu eoan-backports main restricted universe multiverse
deb-src http://archive.ubuntu.com/ubuntu eoan-security main restricted universe multiverse

$ sudo apt-get update

$ reverse-depends -b libc-client2007e-dev
...

[Mauricio Faria de Oliveira (mfo)]

Regression testing
------------------

This consists in crawling the 'emailconfiguration <dot> com'
website with 'googler' and parsing the IMAP/POP servers with
SSL encryption from the results/website pages. Test scripts
are attached in a tarball.

$ mkdir testing
$ cd testing

$ ~/get-email-config-links.sh && ~/get-email-config-pages.sh && ~/get-email-config-servers.sh

Number of results from googler:

$ wc -l email-config.links
299 email-config.links

$ ls -1 email-config.page_* | wc -l
299

Number of found pages + SSL servers:

$ wc -l email-config.servers
265 email-config.servers

Number of unique SSL servers:

$ sort -u email-config.servers | wc -l
167

There are only 167 unique servers from a list
of 299 providers because some of the provider
pages are not found in the website, less some
providers which have the same server address
for multiple domains listed as different pages
in the website.

eoan
====

$ lsb_release -ds
Ubuntu Eoan Ermine (development branch)

dependencies
------------

$ sudo apt-get install uw-mailutils php7.2-cli php7.2-imap

original package
----------------

$ dpkg -s libc-client2007e | grep Version:
Version: 8:2007f~dfsg-6

$ mkdir orig-pkg
$ (cd orig-pkg && ~/try-email-config-servers.sh ../ && ~/normalize-email-config-servers-log.sh)

modified package
----------------

$ dpkg -s libc-client2007e | grep Version:
Version: 8:2007f~dfsg-6ubuntu1

$ mkdir test-pkg
$ (cd test-pkg && ~/try-email-config-servers.sh ../ && ~/normalize-email-config-servers-log.sh)

comparison
----------

Summary: imap.gmail.com, imap.mail.att.net, and inbound.att.net
have certificate failures with the original package, and either
reach the username prompt (mailutil check) or errors due to the
authentication errors (php -r imap_open) with the test package.

Some other servers have false negatives because of connection
timeouts or other failures but after more attempts eventually
show consistent behavior (no change).

$ diff -ur orig-pkg/ test-pkg/ | grep -v -e ^@@ -e ^--- -e ^+++ | sed 's/^diff/\ndiff/'

diff -ur orig-pkg/email-config.servers.log.imap.gmail.com_993.mailutil test-pkg/email-config.servers.log.imap.gmail.com_993.mailutil
-Certificate failure for imap.gmail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
-Certificate failure for imap.gmail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
+{SERVER} username:
\ No newline at end of file

diff -ur orig-pkg/email-config.servers.log.imap.gmail.com_993.php-imap test-pkg/email-config.servers.log.imap.gmail.com_993.php-imap
 PHP Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
-PHP Notice: Unknown: Certificate failure for imap.gmail.com: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid (errflg=2) in Unknown on line 0
+PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
+PHP Notice: Unknown: Retrying PLAIN authentication after [ALERT] Invalid credentials (Failure) (errflg=1) in Unknown on line 0
+PHP Notice: Unk...

[Mauricio Faria de Oliveira (mfo)]

Regression test scripts

[Mauricio Faria de Oliveira (mfo)]

Verification of version/release upgrade path
with the version numbers used in the debdiff
for all packages/releases (to be attached).

$ for pkg in prayer mailsync asterisk
do

  echo "Package: $pkg"

  E_NEW="$(grep -h urgency ${pkg}_e*.debdiff | grep -o '(.*)' | tr -d '[()]' | sed -n 1p)"
  E_OLD="$(grep -h urgency ${pkg}_e*.debdiff | grep -o '(.*)' | tr -d '[()]' | sed -n 2p)"
  D_NEW="$(grep -h urgency ${pkg}_d*.debdiff | grep -o '(.*)' | tr -d '[()]' | sed -n 1p)"
  D_OLD="$(grep -h urgency ${pkg}_d*.debdiff | grep -o '(.*)' | tr -d '[()]' | sed -n 2p)"
  B_NEW="$(grep -h urgency ${pkg}_b*.debdiff | grep -o '(.*)' | tr -d '[()]' | sed -n 1p)"
  B_OLD="$(grep -h urgency ${pkg}_b*.debdiff | grep -o '(.*)' | tr -d '[()]' | sed -n 2p)"

  echo "Versions:"
  echo "B (old): $B_OLD"
  echo "B (new): $B_NEW"
  echo "D (old): $D_OLD"
  echo "D (new): $D_NEW"
  echo "E (old): $E_OLD"
  echo "E (new): $E_NEW"

  dpkg --compare-versions $E_NEW gt $E_OLD && \
  dpkg --compare-versions $E_NEW gt $D_NEW && \
  dpkg --compare-versions $D_NEW gt $D_OLD && \
  dpkg --compare-versions $D_NEW gt $B_NEW && \
  dpkg --compare-versions $B_NEW gt $B_OLD && \
  echo 'Version/release upgrade path is OK.' || \
  echo 'Version/release upgrade path is NOT ok.'

  echo
done

Package: prayer
Versions:
B (old): 1.3.5-dfsg1-4build1
B (new): 1.3.5-dfsg1-4build2
D (old): 1.3.5-dfsg1-6
D (new): 1.3.5-dfsg1-6build0.19.04.1
E (old): 1.3.5-dfsg1-6
E (new): 1.3.5-dfsg1-6build1
Version/release upgrade path is OK.

Package: mailsync
Versions:
B (old): 5.2.2-3.1build1
B (new): 5.2.2-3.1build1.18.04.1
D (old): 5.2.2-3.1build1
D (new): 5.2.2-3.1build1.19.04.1
E (old): 5.2.2-3.1build1
E (new): 5.2.2-3.1build2
Version/release upgrade path is OK.

Package: asterisk
Versions:
B (old): 1:13.18.3~dfsg-1ubuntu4
B (new): 1:13.18.3~dfsg-1ubuntu4build1
D (old): 1:16.2.1~dfsg-1
D (new): 1:16.2.1~dfsg-1build1
E (old): 1:16.2.1~dfsg-2
E (new): 1:16.2.1~dfsg-2build1
Version/release upgrade path is OK.

[Mauricio Faria de Oliveira (mfo)]

The uw-imap debdiffs address the problem.

The next debdiffs (asterisk, mailsync, prayer) are
no-change-rebuilds for the reverse build dependencies.

Thus, should only be uploaded/built *after* uw-imap is.

[Mauricio Faria de Oliveira (mfo)]

Marking php-imap bug as invalid because it's fixed via run-time dependency / shared library.

[Mauricio Faria de Oliveira (mfo)]

For documentation purposes,

Test with an IP address should not send SNI per the patch,
so it should fail with the certificate verification error:

$ mailutil check {imap.gmail.com:993/imap/ssl}INBOX
{cb-in-f108.1e100.net/imap} username:

$ host imap.gmail.com | grep -m1 address
gmail-imap.l.google.com has address 64.233.186.108

$ mailutil check {64.233.186.108:993/imap/ssl}INBOX
Certificate failure for 64.233.186.108: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
Certificate failure for 64.233.186.108: self signed certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid

[Dan Streetman (ddstreet)]

> Test with an IP address should not send SNI per the patch,
> so it should fail with the certificate verification error:

just to clarify as I was not clear at first:

-with <TLSv1.3, the client did not send and the server did not require SNI

-with =>TLSv1.3, some servers (as listed in description, e.g. gmail) require SNI
  -if the client is accessing the server via DNS name, it provides SNI
  -if the client is accessing the server via IP address, it does not provide SNI

So this means the servers that require SNI when using TLSv1.3 can not (any longer?) be accessed by their direct ip address, their hostname *must* be used.

questions:
1) did access by IP address used to work, before updating to TLSv1.3?
2) if direct IP address used to work before, does the code need to do a fallback to pre-TLSv1.3 for servers that require SNI but are being accessed by IP address?

I have sponsored this to e, d, and b, as it seems to be doing the right thing based on the RFC:
https://tools.ietf.org/html/rfc6066#page-6
as discussed in previous comments.

But, I think the regression potential should be considered in case direct IP address access worked before (i.e. before the update to openssl 1.1.1), but isn't restored by this patch. At minimum it should be listed in the regression potential section of the description.

Thanks!

[Mauricio Faria de Oliveira (mfo)]

Dan,

Very good point.

Access by IP address didn't work before -- I just checked w/ Xenial / OpenSSL 1.0.0,
and it fails with certification verification error too.

IIUIC this seems reasonable - as the default certificate is the only thing the server
could send to the client without SNI (which prohibited for IP addresses) to hint/tell
the server which hostname it wants the certificate for, and the certificate owners
would need to keep the default certificate up-to-date with all IP addresses the server
could possibly serve/respond on (it seems unfeasible).

So we should be good on this particular case!
Thanks for catching this.

--

$ lsb_release -cs
xenial

$ dpkg -l | grep libssl1. | awk '{ print $2 }'
libssl1.0.0:amd64

$ mailutil check {imap.gmail.com:993/imap/ssl}INBOX
{cb-in-f109.1e100.net/imap} username: ^C

$ host imap.gmail.com | grep -m1 address
gmail-imap.l.google.com has address 64.233.186.108

$ mailutil check {64.233.186.108:993/imap/ssl}INBOX
Certificate failure for 64.233.186.108: Server name does not match certificate: /C=US/ST=California/L=Mountain View/O=Google LLC/CN=imap.gmail.com
Certificate failure for 64.233.186.108: Server name does not match certificate: /C=US/ST=California/L=Mountain View/O=Google LLC/CN=imap.gmail.com

[Launchpad Janitor (janitor)]

This bug was fixed in the package uw-imap - 8:2007f~dfsg-6ubuntu1

---------------
uw-imap (8:2007f~dfsg-6ubuntu1) eoan; urgency=medium

  * 2014_openssl1.1.1_sni.patch (new): Use SNI when building
    with OpenSSL 1.1.1 / TLSv1.3 support, since some servers
    (e.g., imap.gmail.com, imap.mail.att.net) require SNI on
    TLSv1.3 to pass certificate verification. (LP: #1834340)
  * debian/control{,.in{,.in}}: Update maintainer across all.

 -- Mauricio Faria de Oliveira <email address hidden> Fri, 09 Aug 2019 11:51:00 -0300

[David Zuelke (dzuelke)]

> So this means the servers that require SNI when using TLSv1.3 can not (any longer?) be accessed by their direct ip address, their hostname *must* be used.

SNI, per RFC 6066 is not allowed for IP addresses, so servers couldn't require it (this is not new in TLSv1.3):

"Literal IPv4 and IPv6 addresses are not permitted in "HostName"."

The change in TLSv1.3 is that servers *may* now require SNI, and Google chose to do so for GMail's IMAP servers.

It's still possible to connect to IP addresses using TLSv1.3, the server just can't mandate SNI, but that's not a regression per se.

Either way, SNI is useless for an IP address - the client is already connecting to a literal IP address, so the server could, if desired, return a matching certificate without having to resort to "HostName", and that hasn't changed.

[Brian Murray (brian-murray)]

Hello pataquets, or anyone else affected,

Accepted uw-imap into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/uw-imap/8:2007f~dfsg-5ubuntu0.19.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

Hello pataquets, or anyone else affected,

Accepted uw-imap into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/uw-imap/8:2007f~dfsg-5ubuntu0.18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Mauricio Faria de Oliveira (mfo)]

Verification done for bionic:
---

'mailutil check' successfully connects to gmail,
and prompts for an username, using openssl1.1.1.

$ lsb_release -cs
bionic

$ sudo apt-get install libc-client2007e uw-mailutils
...
Get:1 http://archive.ubuntu.com/ubuntu bionic-proposed/universe amd64 libc-client2007e amd64 8:2007f~dfsg-5ubuntu0.18.04.1 [580 kB]
Get:2 http://archive.ubuntu.com/ubuntu bionic-proposed/universe amd64 uw-mailutils amd64 8:2007f~dfsg-5ubuntu0.18.04.1 [31.6 kB]
...

$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
{cb-in-f16.1e100.net/imap} username:

$ strace mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX" 2>&1 | grep libssl
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libssl.so.1.1", O_RDONLY|O_CLOEXEC) = 3
^C

$ dpkg -S /usr/lib/x86_64-linux-gnu/libssl.so.1.1
libssl1.1:amd64: /usr/lib/x86_64-linux-gnu/libssl.so.1.1

$ dpkg -s libssl1.1 | grep Version:
Version: 1.1.1-1ubuntu2.1~18.04.1

[Mauricio Faria de Oliveira (mfo)]

Verification done for disco:
---

'mailutil check' successfully connects to gmail,
and prompts for an username, using openssl1.1.1.

$ lsb_release -cs
disco

$ sudo apt-get install libc-client2007e uw-mailutils
...
Get:1 http://archive.ubuntu.com/ubuntu disco-proposed/universe amd64 libc-client2007e amd64 8:2007f~dfsg-5ubuntu0.19.04.1 [577 kB]
Get:2 http://archive.ubuntu.com/ubuntu disco-proposed/universe amd64 uw-mailutils amd64 8:2007f~dfsg-5ubuntu0.19.04.1 [31.7 kB]
...

$ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
{ce-in-f16.1e100.net/imap} username: ^C

$ strace mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX" 2>&1 | grep libssl
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libssl.so.1.1", O_RDONLY|O_CLOEXEC) = 3
^C

$ dpkg -S /usr/lib/x86_64-linux-gnu/libssl.so.1.1
libssl1.1:amd64: /usr/lib/x86_64-linux-gnu/libssl.so.1.1

$ dpkg -s libssl1.1 | grep Version:
Version: 1.1.1b-1ubuntu2

[pataquets (pataquets)]

Verification done for bionic:
---
Performed both command line and PHP code tests above, which worked successfully.
I've done them prior to deployment to production, to fix the issue which originated this very same bug report.
Packages are now upgraded and after reenabling certificate verification, code keeps working without problems. Previously, code crashed without 'novalidate-cert' option.
Thank you everyone.

(Due to company policies, I'm not allowed to post any production logs)

[Mauricio Faria de Oliveira (mfo)]

Thanks for verifying bionic-proposed @pataquets!

[Mauricio Faria de Oliveira (mfo)]

For documentation purposes.
The patch carried in Ubuntu has been sent to Debian bug 916041 [1].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916041

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for uw-imap has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package uw-imap - 8:2007f~dfsg-5ubuntu0.19.04.1

---------------
uw-imap (8:2007f~dfsg-5ubuntu0.19.04.1) disco; urgency=medium

  * 2014_openssl1.1.1_sni.patch (new): Use SNI when building
    with OpenSSL 1.1.1 / TLSv1.3 support, since some servers
    (e.g., imap.gmail.com, imap.mail.att.net) require SNI on
    TLSv1.3 to pass certificate verification. (LP: #1834340)
  * debian/control.in.in: Update maintainer that lasts build.

 -- Mauricio Faria de Oliveira <email address hidden> Fri, 09 Aug 2019 11:51:00 -0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package uw-imap - 8:2007f~dfsg-5ubuntu0.18.04.1

---------------
uw-imap (8:2007f~dfsg-5ubuntu0.18.04.1) bionic; urgency=medium

  * 2014_openssl1.1.1_sni.patch (new): Use SNI when building
    with OpenSSL 1.1.1 / TLSv1.3 support, since some servers
    (e.g., imap.gmail.com, imap.mail.att.net) require SNI on
    TLSv1.3 to pass certificate verification. (LP: #1834340)
  * debian/control.in.in: Update maintainer that lasts build.

 -- Mauricio Faria de Oliveira <email address hidden> Fri, 09 Aug 2019 11:51:00 -0300

[Mauricio Faria de Oliveira (mfo)]

Attaching updated debdiff for asterisk on Eoan,
which changed versions while we waited uw-imap.

[Dan Streetman (ddstreet)]

sponsored asterisk, prayer, and mailsync for e/d/b

[Launchpad Janitor (janitor)]

This bug was fixed in the package prayer - 1.3.5-dfsg1-6build1

---------------
prayer (1.3.5-dfsg1-6build1) eoan; urgency=medium

  * No change rebuild to pick up libc-client2007e-dev. (LP: #1834340)

 -- Mauricio Faria de Oliveira <email address hidden> Tue, 13 Aug 2019 11:50:43 -0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package mailsync - 5.2.2-3.1build2

---------------
mailsync (5.2.2-3.1build2) eoan; urgency=medium

  * No change rebuild to pick up libc-client2007e-dev. (LP: #1834340)

 -- Mauricio Faria de Oliveira <email address hidden> Tue, 13 Aug 2019 11:01:00 -0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package asterisk - 1:16.2.1~dfsg-2build2

---------------
asterisk (1:16.2.1~dfsg-2build2) eoan; urgency=medium

  * No change rebuild to pick up libc-client2007e-dev. (LP: #1834340)

 -- Mauricio Faria de Oliveira <email address hidden> Thu, 29 Aug 2019 09:52:20 -0300

[Steve Langasek (vorlon)]

Why does asterisk need a rebuild against the new uw-imap? There is no test case listed for asterisk here.

[Steve Langasek (vorlon)]

Why does mailsync need a rebuild against the new uw-imap? There is no test case listed for mailsync here.

[Steve Langasek (vorlon)]

An upload of asterisk to bionic-proposed has been rejected from the upload queue for the following reason: "Confirmed with ddstreet that no-change rebuilds only wanted for statically-linked packages and this is dynamically linked against libc-client2007e".

[Steve Langasek (vorlon)]

An upload of mailsync to bionic-proposed has been rejected from the upload queue for the following reason: "Confirmed with ddstreet that no-change rebuilds only wanted for statically-linked packages and this is dynamically linked against libc-client2007e".

[Steve Langasek (vorlon)]

An upload of prayer to bionic-proposed has been rejected from the upload queue for the following reason: "Confirmed with ddstreet that no-change rebuilds only wanted for statically-linked packages and this is dynamically linked against libc-client2007e".

[Steve Langasek (vorlon)]

An upload of asterisk to disco-proposed has been rejected from the upload queue for the following reason: "Confirmed with ddstreet that no-change rebuilds only wanted for statically-linked packages and this is dynamically linked against libc-client2007e".

[Steve Langasek (vorlon)]

An upload of mailsync to disco-proposed has been rejected from the upload queue for the following reason: "Confirmed with ddstreet that no-change rebuilds only wanted for statically-linked packages and this is dynamically linked against libc-client2007e".

[Steve Langasek (vorlon)]

An upload of prayer to disco-proposed has been rejected from the upload queue for the following reason: "Confirmed with ddstreet that no-change rebuilds only wanted for statically-linked packages and this is dynamically linked against libc-client2007e".

[Mauricio Faria de Oliveira (mfo)]

Thanks for catching that; I just set the packages/releases for those as Invalid.