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 ... ** Description changed: + [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 (161 servers), and no regressions were observed. + Actually, one more email provider/server has been fixed too. + + [Test Case] + + * 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 + + * 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 hundreds of (161) + 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 161 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. + + [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. ** Description changed: [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). + * 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. + * 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. + * 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. + * 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 (161 servers), and no regressions were observed. - Actually, one more email provider/server has been fixed too. + * Regression testing happened with a crawled list of IMAP/POP + SSL servers (161 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] - * OpenSSL-only demonstration with -(no)servername: + * Commands: - $ 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 + $ sudo apt install uw-mailutils + $ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX" - * Commands: + $ sudo apt install php7.2-cli php7.2-imap + $ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");' - $ sudo apt install uw-mailutils - $ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX" + * Before: - $ sudo apt install php7.2-cli php7.2-imap - $ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", "password");' + $ 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 - * Before: + $ 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 - $ 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 + * After: - $ 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 + $ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX" + {ce-in-f16.1e100.net/imap} username: + ^C - * After: + $ 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 - $ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX" - {ce-in-f16.1e100.net/imap} username: - ^C + * Regression testing scripts/results are provided in + attachments/comments. - $ 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 hundreds of (161) - IMAP/POP SSL servers. + * Theoretically possible, but not observed in hundreds of (161) + 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 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 161 server test). + * The risk is servers that misbehave when provided such info + (not observed in the 161 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). + * 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). + * 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. + * This both shows the SRU team that the risks have been considered, + and provides guidance to testers in regression-testing the SRU. + [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. ** Description changed: [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 (161 servers), and no regressions were observed. + 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': + Output with '-noservername': - verify error:num=18:self signed certificate - verify error:num=62:Hostname mismatch - Verification error: Hostname mismatch + verify error:num=18:self signed certificate + verify error:num=62:Hostname mismatch + Verification error: Hostname mismatch - Output with '-servername imap.gmail.com' + Output with '-servername imap.gmail.com' - Verification: OK - Verified peername: 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 hundreds of (161) + * 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 161 server test). + (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. - [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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1834340 Title: Possible regression on libssl upgrade when using TLSv1.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/php-imap/+bug/1834340/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs