IMAP account stopped working after upgrade to iOS 9 - problem with CAcert certificate?
Solution 1:
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.
Solution 2:
I have the same problem, but no answer yet. I hope that I am closing in on a solution and I that have pertinent information for you.
I have the iOS 9 problem as you describe with my Courier IMAP, but not with my SASL SMTP AUTH. The cryptography on the 2 servers is similar.
Notably, they both use self signed certificates.
Here are the "openssl s_client" outputs that I am looking at:
Courier IMAP (iOS 9 rejects)
------------
$ openssl s_client -connect 127.0.0.1:143 -starttls imap
No client certificate CA names sent
---
SSL handshake has read 3092 bytes and written 479 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : DHE-RSA-AES256-GCM-SHA384
Session-ID: 4E1B8D0D14AC480A4203C1898A0C75D57DE646547A9F9FC3D47CDFD1926B7C0C
Session-ID-ctx:
Master-Key: 4E9D26764E93204AE2C7232E72328C30B38A272B6500D1E524FDA25FEA86EDEBEA22416BECEF78DC8713E5CC5850060D
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - ad ad c0 42 ad 10 be 6b-2b 3e c0 79 79 8c 12 03 ...B...k+>.yy...
0010 - 74 06 9d ed 1b 72 90 0b-f7 ff f5 f7 1e 2f 6f ec t....r......./o.
0020 - a2 ea 8f ac 5a 64 b2 9e-b8 3f 09 56 31 b0 c3 76 ....Zd...?.V1..v
0030 - c8 b7 83 94 dc 04 81 1a-fe a7 72 4d 50 9c 18 e7 ..........rMP...
0040 - bd b2 2a cf 0b 29 1c f5-23 75 30 0e fe c9 0a 94 ..*..)..#u0.....
0050 - 6f c2 e9 ba fa fd b7 f2-33 83 34 91 75 bb 30 4a o.......3.4.u.0J
0060 - f1 68 5f 3b 3d f4 12 db-5e 52 82 e7 6f 35 83 c9 .h_;=...^R..o5..
0070 - 49 39 03 a4 08 8e 60 26-9a a7 5f 18 26 47 f7 ae I9....`&.._.&G..
0080 - 07 29 68 7b 5a 5d ad 2f-7d ea 02 f9 00 c8 53 64 .)h{Z]./}.....Sd
0090 - 1e c9 6e e6 b1 e9 59 83-f2 7a 13 0c 7f c7 44 7a ..n...Y..z....Dz
Start Time: 1442747573
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
. OK CAPABILITY completed
SMTP AUTH (iOS 9 accepts)
---------
$ openssl s_client -connect 127.0.0.1:25 -starttls smtp
No client certificate CA names sent
---
SSL handshake has read 1637 bytes and written 456 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 7B733E6F86EDC34FB2C399E6571263286DB3A3BE94CA04BD0146A9EE3602D6CF
Session-ID-ctx:
Master-Key: F72207EFCC8AF316D3BD120C2F11D45FBE9861EF0155CAEFE08395F239541FEE5AEA0D27CDB18B2BB7C5CAF9A8D22832
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - ff 5b be 3e 40 a4 c9 6f-f8 67 00 c9 ac 86 16 27 .[.>@..o.g.....'
0010 - a9 df 68 57 d1 5c 16 1a-27 e5 2a 74 91 2f b0 28 ..hW.\..'.*t./.(
0020 - 3f ec 58 2c 0c 23 d9 cb-8b 03 c5 7d 97 de 96 c7 ?.X,.#.....}....
0030 - fb 25 47 0d b8 7b 5a 45-0c 55 8e 7c 6d 2e 12 76 .%G..{ZE.U.|m..v
0040 - 8c 2b 1f 2b 27 3f d6 98-fd 23 3f 26 07 de f5 3e .+.+'?...#?&...>
0050 - be e7 ed 08 3d 0d b9 d3-6d a0 6d 25 2f cf b1 65 ....=...m.m%/..e
0060 - e1 36 f2 78 1d f4 36 4f-f4 e5 67 a1 16 e7 22 4c .6.x..6O..g..."L
0070 - c1 80 59 dc 58 72 16 15-73 73 8d 9f ef 67 bb 37 ..Y.Xr..ss...g.7
0080 - db a8 24 32 ee ce 5e 67-c1 8a 94 11 5c 3c b0 ff ..$2..^g....\<..
0090 - 3a 73 6a bf 77 07 94 d4-06 6c 27 00 9d 3f 61 4e :sj.w....l'..?aN
Start Time: 1442747626
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
250 DSN
So now I am looking into the difference between "ECDHE" and "DHE", and whether the 4096- versus 2048-bit server public keys make a difference.
I am just assuming that Apple is holding STARTTLS for both SMTP and IMAP to the same standards...
Solution 3:
Mail was working fine in iOS 9.1 until I changed the "alert" in Notifications to "alert" today. Then I got a message saying something like "Cannot get Mail" and that I was using the wrong sign in info. (Sorry I don't recall the exact wording of the message.)I tried it twice and got the same message both times, but I immediately remembered what I had changed in "Settings" earlier today so I went back to Settings>Notifications>Notifications Style>Mail>Alert Style and then I selected "None". When I went back to my Mail app it worked fine again. (I use GMail.)