sts-sponsors team mailing list archive

[Mauricio Faria de Oliveira <mfo@xxxxxxxxxxxxx>]

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

-- 
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/1834340

Title:
  Regression for GMail after libssl upgrade with TLSv1.3

Status in asterisk package in Ubuntu:
  New
Status in mailsync package in Ubuntu:
  New
Status in php-imap package in Ubuntu:
  Invalid
Status in prayer package in Ubuntu:
  New
Status in uw-imap package in Ubuntu:
  In Progress
Status in asterisk source package in Bionic:
  New
Status in mailsync source package in Bionic:
  New
Status in php-imap source package in Bionic:
  Invalid
Status in prayer source package in Bionic:
  New
Status in uw-imap source package in Bionic:
  In Progress
Status in asterisk source package in Disco:
  New
Status in mailsync source package in Disco:
  New
Status in php-imap source package in Disco:
  Invalid
Status in prayer source package in Disco:
  New
Status in uw-imap source package in Disco:
  In Progress
Status in asterisk source package in Eoan:
  New
Status in mailsync source package in Eoan:
  New
Status in php-imap source package in Eoan:
  Invalid
Status in prayer source package in Eoan:
  New
Status in uw-imap source package in Eoan:
  In Progress
Status in uw-imap package in Debian:
  Unknown

Bug description:
  [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.

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