L'account IMAP ha smesso di funzionare dopo l'aggiornamento a iOS 9 - problema con il certificato CAcert?

Si scopre che nel mio caso il problema non è il certificato CAcert, né la versione TLS - sono i cifrari di enryption offerti da OpenSSL sul server, o meglio, che alcuni di essi usano parametri troppo deboli.

Quando Apple ha spedito il proprio aggiornamento iOS 8.4 qualche tempo fa, ha apportato miglioramenti alla libreria TLS coreTLS per impedire il cosiddetto attacco Logjam. È sicuro presumere che questi miglioramenti siano anche parte di iOS 9. Come Apple cita in questa technote , coreTLS non accetta più suite di cifratura DH effimere per forza di esportazione. Nel mio caso, questo non è il problema, però, perché il mio server non offre tali cifrari ai suoi clienti.

Ciò che Apple "ha dimenticato" di dire nella loro tecnologia è che hanno anche aggiunto nuovi requisiti per i rimanenti codici DH. In questo, probabilmente hanno seguito la Guida alla distribuzione di Diffie-Hellman per TLS , che è un documento "ufficiale" con le raccomandazioni formulate dal persone che hanno scoperto l'attacco Logjam. In particolare, coreTLS ora richiede che le suite di crittografia DH utilizzino una dimensione di gruppo DH minima.

Il "gruppo DH" è un parametro per i codici DH la cui forza è misurata dalla sua dimensione in bit. La guida di cui sopra menziona che i browser moderni richiedono ora una dimensione minima del gruppo DH di 1024. Apparentemente anche coreTLS ha adottato questo requisito, perché questo è quello che ho scoperto sul mio server ...

Il server IMAP Courier ha la seguente riga nel suo file di configurazione /etc/courier/imapd-ssl :

TLS_DHPARAMS=/etc/courier/dhparams.pem

Quando esamino il file dei parametri DH, ottengo il seguente risultato:

$ 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)

Come si può vedere, questo gruppo DH ha solo una dimensione di 768 bit, che non è sicuramente all'altezza degli standard moderni.

Per risolvere il problema, ho creato un nuovo gruppo DH con dimensioni maggiori. Ho seguito il consiglio nella "Guida alla distribuzione di DH" e ho creato un gruppo con dimensione 2048 bit:

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

Modifica le autorizzazioni del nuovo file in modo che corrispondano alle autorizzazioni del file originale:

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

Ho quindi aggiornato il file di configurazione IMAP di Courier:

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

e riavviato il server

/etc/init.d/courier-imap restart

Dopo che l'app Mail ha funzionato bene. Problema risolto.

PS: In alto ho detto che le modifiche di coreTLS sono state inviate con iOS 8.4, ma nella mia domanda dichiaro di avere dispositivi iOS 8 che non hanno problemi di connessione IMAP. Entrambe le affermazioni sono vere, ma come ora mi rendo conto di aver dimenticato di menzionare nella mia domanda che quei dispositivi iOS 8 usano ancora iOS 8.1.x. Ci scusiamo per questo.

Test aggiuntivi del protocollo: ho giocato con l'impostazione IMAP di Courier TLS_STARTTLS_PROTOCOL , per forzare il client (app iOS 9 Mail) a una specifica versione del protocollo TLS. Stranamente ho scoperto che né TLSv1.2 né TLSv1.1 sembrano funzionare (anche SSL3 non funziona, ma va bene). L'unica opzione che funziona è

TLS_STARTTLS_PROTOCOL=TLS1

(ciò rimane vero anche dopo aver aggiornato la dimensione del gruppo DH)

Ho provato le stesse impostazioni con iOS 8.1.2 - lì l'applicazione Mail è in grado di connettersi con tutte e 3 le versioni di protocollo (TLSv1.2, TLSv1.1, TLS1) e persino SSL3.

Questo è davvero, davvero strano. Anche se è difficile da credere, al momento sembra che l'app iOS 9 Mail possa usare solo TLS1. Nonostante i miglioramenti nella sicurezza sul fronte del cipher DH, il mancato supporto di TLSv1.2 sarebbe una brutta regressione, IMO. Potrebbe anche darsi che il mio server sia in qualche modo mal configurato in un modo che non riconosco al momento. Sarebbe quindi utile se qualcun altro potesse fare test simili per confermare o scartare i miei risultati.

Ho lo stesso problema, ma non ho ancora risposto. Spero di riuscire a concludere una soluzione e che io abbia informazioni pertinenti per te.

Ho il problema di iOS 9 come descrivi con il mio Courier IMAP, ma non con il mio AUTH SASL SAS. La crittografia sui 2 server è simile.

In particolare, entrambi utilizzano certificati autofirmati.

Ecco gli output di "openssl s_client" che sto guardando:

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

Quindi ora sto osservando la differenza tra "ECDHE" e "DHE" e se le chiavi pubbliche dei server da 4096 a 2048 bit fanno la differenza.

Sto solo partendo dal presupposto che Apple tenga STARTTLS sia per SMTP che per IMAP agli stessi standard ...

La posta funzionava perfettamente in iOS 9.1 fino a quando non ho modificato l'avviso in Notifiche a "avviso" oggi. Poi ho ricevuto un messaggio che diceva qualcosa come "Impossibile ottenere la posta" e che stavo usando l'informazione di accesso sbagliata. (Scusa se non ricordo la formulazione esatta del messaggio.) L'ho provato due volte e ho ricevuto lo stesso messaggio entrambe le volte, ma mi sono subito ricordato di cosa avevo modificato in "Impostazioni" in precedenza oggi, quindi sono tornato a Impostazioni > Notifiche > Notifiche Stile > Mail > Alert Style e quindi ho selezionato "None". Quando sono tornato alla mia app di posta, ha funzionato di nuovo bene. (Io uso GMail.)

abbiamo avuto lo stesso problema nella nostra azienda. Abbiamo quasi la stessa configurazione di Debian, Courier IMAP e IOS9. Per noi è stato risolto da solo quando abbiamo utilizzato la porta 143 per la connessione ssl imap.