IOS – IMAP account stopped working after upgrade to iOS 9 – problem with CAcert certificate

imapiosmobile-mail

After upgrading my iPhone 6+ from iOS 8 to iOS 9, my IMAP email account stopped working. When the Mail app tries to connect to the server, it fails and displays an alert with the title "Cannot get Mail" and the message "The mail server x.y.z is not responding. Verify that you have entered the correct account info in Mail settings.".

I did check the account info, and it is indeed correct. Interestingly, I do not get any error messages from the settings app when I try to save the account. I have tried entering wrong information on purpose (wrong username, wrong password, wrong TCP port), and whenever I do that and try to save the account, the settings app shows an alert "The IMAP server x.y.z is not responding.". So I am really sure that the information I have entered is correct.

Moreover, I have two other iOS devices in the household (an iPad 2 and an iPhone 4S) which are configured to use the same account and which are still on iOS 8 – from these devices the account works properly, so I also know that the problem is not something basic like the IMAP server is down.

I have tried various things (see below), but without success. The only thing I know for certain is that the problem is somehow connected to TLS and/or certificates. Taking into account the information from this AskDifferent question I suspect it's a problem with the CAcert certificate, but I am not sure.

Do you know anything about changes in iOS 9 regarding the handling of certificates (untrusted or otherwise)? Or do you have other clues that might help me solve this problem?

Information about the server:

  • The IMAP server runs on a Debian machine over which I have full control
  • The IMAP server is Courier IMAP
  • The IMAP server accepts connections on the standard IMAP port 143
  • The IMAP server requires STARTTLS to enforce that all traffic is encrypted via TLS
  • The IMAP server uses a wildcard certificate
  • The IMAP server provides the whole certificate chain to the client
  • The root CA is CAcert.org (link to root and intermediate CA certificates)
  • Because CAcert.org is not, by default, in the trusted CA store of iOS 9, I have manually installed the root and intermediate CA certificates on the iPhone 6+
  • Courier version = 0.73.1 (/usr/bin/imapd --version)
  • OpenSSL version = 1.0.2d (/usr/bin/openssl version)

What have I tried?

  • The first thing I did is, I deleted the entire account configuration in the iPhone's settings app, then created a new account and re-entered the configuration details. No success.
  • I upgraded various packages on the Debian machine, including Courier and OpenSSL, to make sure that the server has the "latest and greatest" security capabilities. No success.
  • I read somewhere that iOS 9 might require TLS 1.2 on the server side, so I double-checked that the IMAP server indeed offers that version of TLS to its clients. It does. This is the command I used for verification: openssl s_client -connect mail.herzbube.ch:143 -starttls imap. If you run this you will see a block with information about the SSL session towards the end, this block contains a line that shows the TLS version that is used (Protocol : TLSv1.2). Note that in order to get TLS v1.2, your client-side version of OpenSSL must also support this. For instance, OpenSSL on my Mac OS X Yosemite (10.10.3) laptop is too old, i.e. it is only version 0.9.8.zd and does not seem to understand TLS 1.2, so I get Protocol : TLSv1.
  • I deleted the CAcert root and intermediate certificates on the iPhone, then re-installed them. Nope, didn't help.
  • I temporarily disabled the requirement for TLS on the server-side, and this solves the issue, i.e. now the Mail app can connect, login and get emails from the server. Obviously this is not a real solution, since I don't want the traffic to the IMAP server to be in clear-text, but at least now I know that the problem is somehow connected to TLS (and/or certificates).
  • I updated the iPhone to iOS 9.0.1. No success.

Best Answer

It turns out that in my case the problem is not the CAcert certificate, nor the TLS version - it's the enryption ciphers offered by OpenSSL on the server, or rather, that some of them use parameters that are too weak.

When Apple shipped their iOS 8.4 update a while ago, they made improvements to their TLS library coreTLS in order to prevent the so-called Logjam attack. It is safe to assume that these improvements are also part of iOS 9. As Apple mentions in this technote, coreTLS no longer accepts export-strength ephemeral DH cipher suites. In my case, this is not the problem, though, because my server does not offer such ciphers to its clients.

What Apple "forgot" to say in their technote is that they also added new requirements for the remaining DH ciphers. In this, they probably followed the Guide to Deploying Diffie-Hellman for TLS, which is an "official" document with recommendations made by the people who discovered the Logjam attack. Specifically, coreTLS now requires that DH cipher suites use a minimum DH group size.

The "DH group" is a parameter for DH ciphers whose strength is measured by its size in bits. The guide referenced above mentions that modern browsers now require a minimum DH group size of 1024. Apparently coreTLS has also adopted this requirement, because this is what I discovered on my server...

The Courier IMAP server has the following line in its config file /etc/courier/imapd-ssl:

TLS_DHPARAMS=/etc/courier/dhparams.pem

When I examine the DH params file, I get the following output:

$ openssl dhparam -in /etc/courier/dhparams.pem -noout -text
    DH Parameters: (768 bit)
        prime:
            00:e0:01:64:54:ec:1c:17:86:f3:02:81:08:44:75:
            67:e6:ab:5c:dd:61:0a:a6:49:1e:23:48:98:29:e9:
            48:36:d3:6b:9c:0f:0f:89:7d:7b:7a:17:1f:03:f3:
            53:4f:cf:d7:4d:a3:8f:00:6e:af:fb:e2:95:e6:45:
            71:c3:8b:74:d2:b4:8c:7c:7d:4b:e1:11:12:eb:7e:
            31:fb:c2:ff:f0:60:3d:07:69:d8:36:19:43:03:00:
            52:43:5b:99:21:5f:c3
        generator: 2 (0x2)

As can be seen, this DH group only has a size of 768 bits, which is definitely not up to modern standards.

To solve the problem I created a new DH group with increased size. I followed the advice in the "Guide to Deploying DH" and created a group with size 2048 bits:

openssl dhparam -out /etc/courier/dhparams-2048-bit.pem 2048

Change permissions of the new file so that they match the original file's permissions:

chmod 600 dhparams-2048-bit.pem
chown daemon:daemon dhparams-2048-bit.pem

I then updated the Courier IMAP config file:

TLS_DHPARAMS=/etc/courier/dhparams-2048-bit.pem

and restarted the server

/etc/init.d/courier-imap restart

After that the Mail app worked fine. Problem solved.

PS: Above I said that the coreTLS changes were shipped with iOS 8.4, yet in my question I claim that I have iOS 8 devices that do not have any IMAP connection problems. Both statements are true, but as I now realize I forgot to mention in my question that those iOS 8 devices are still using iOS 8.1.x. Sorry for that.

Additional Protocol tests: I played around with the Courier IMAP setting TLS_STARTTLS_PROTOCOL, in order to force the client (iOS 9 Mail app) to a specific TLS protocol version. Strangely enough I discovered that neither TLSv1.2 nor TLSv1.1 seem to work (SSL3 also does not work, but that's OK). The only option that does work is

TLS_STARTTLS_PROTOCOL=TLS1

(this remains true even after I upgraded the DH group size)

I tested the same settings with iOS 8.1.2 - there the Mail application is able to connect with all 3 protocol versions (TLSv1.2, TLSv1.1, TLS1), and even SSL3.

This is really, really weird. Although it's hard to believe, at the moment it seems as if iOS 9 Mail app can only use TLS1. Despite improvements in security on the DH cipher front, not supporting TLSv1.2 would be a bad regression, IMO. It might also be that my server is somehow misconfigured in a way that I don't recognize at the moment. It would therefore be useful if someone else could make similar tests to either confirm or discard my findings.

Related Question