La cuenta IMAP dejó de funcionar después de actualizar a iOS 9: ¿problema con el certificado CAcert?

Resulta que, en mi caso, el problema no es el certificado CAcert, ni la versión TLS, son los cifrados de cifrado ofrecidos por OpenSSL en el servidor, o más bien, que algunos de ellos utilizan parámetros demasiado débiles.

Cuando Apple lanzó su actualización de iOS 8.4 hace un tiempo, hicieron mejoras en su biblioteca TLS coreTLS para evitar el llamado ataque Logjam. Es seguro asumir que estas mejoras también son parte de iOS 9. Como menciona Apple en esta nota técnica , coreTLS ya no acepta conjuntos de cifrado DH efímero de fuerza de exportación. En mi caso, este no es el problema, porque mi servidor no ofrece tales sistemas de cifrado a sus clientes.

Lo que Apple "olvidó" decir en su nota técnica es que también agregaron nuevos requisitos para los cifrados DH restantes. En este sentido, probablemente siguieron la Guía para implementar Diffie-Hellman para TLS , que es un documento "oficial" con recomendaciones hechas por Personas que descubrieron el ataque de Logjam. Específicamente, coreTLS ahora requiere que las suites de cifrado DH usen un tamaño de grupo DH mínimo.

El "grupo DH" es un parámetro para cifrados DH cuya fuerza se mide por su tamaño en bits. La guía mencionada anteriormente menciona que los navegadores modernos ahora requieren un tamaño de grupo DH mínimo de 1024. Al parecer, coreTLS también ha adoptado este requisito, porque esto es lo que descubrí en mi servidor ...

El servidor IMAP de Courier tiene la siguiente línea en su archivo de configuración /etc/courier/imapd-ssl :

TLS_DHPARAMS=/etc/courier/dhparams.pem

Cuando examino el archivo params DH, obtengo el siguiente resultado:

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

Como se puede ver, este grupo DH solo tiene un tamaño de 768 bits, lo que definitivamente no está a la altura de los estándares modernos.

Para resolver el problema, creé un nuevo grupo DH con mayor tamaño. Seguí el consejo en la "Guía para implementar DH" y creé un grupo con un tamaño de 2048 bits:

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

Cambie los permisos del nuevo archivo para que coincidan con los permisos del archivo original:

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

Luego actualicé el archivo de configuración de Courier IMAP:

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

y reinicie el servidor

/etc/init.d/courier-imap restart

Después de eso, la aplicación Mail funcionó bien. Problema resuelto.

PS: Anteriormente dije que los cambios coreTLS se enviaron con iOS 8.4, pero en mi pregunta afirmo que tengo dispositivos con iOS 8 que no tienen ningún problema de conexión IMAP. Ambas afirmaciones son ciertas, pero ahora me doy cuenta de que olvidé mencionar en mi pregunta que esos dispositivos con iOS 8 todavía están usando iOS 8.1.x. Lo siento por eso.

Pruebas de protocolo adicionales: jugué con la configuración de IMP de Courier TLS_STARTTLS_PROTOCOL , para forzar al cliente (aplicación de correo de iOS 9) a una versión específica del protocolo TLS. Curiosamente, descubrí que ni TLSv1.2 ni TLSv1.1 parecen funcionar (SSL3 tampoco funciona, pero eso está bien). La única opción que funciona es

TLS_STARTTLS_PROTOCOL=TLS1

(esto sigue siendo cierto incluso después de actualizar el tamaño del grupo DH)

Probé la misma configuración con iOS 8.1.2: la aplicación de Correo puede conectarse con las 3 versiones de protocolo (TLSv1.2, TLSv1.1, TLS1) e incluso SSL3.

Esto es muy, muy raro. Aunque es difícil de creer, en este momento parece que la aplicación iOS 9 Mail solo puede usar TLS1. A pesar de las mejoras en la seguridad en el frente del cifrado DH, no admitir TLSv1.2 sería una mala regresión, OMI. También puede ser que mi servidor esté mal configurado de una manera que no reconozco en este momento. Por lo tanto, sería útil si alguien más pudiera realizar pruebas similares para confirmar o descartar mis hallazgos.

Tengo el mismo problema, pero todavía no tengo respuesta. Espero que me esté acercando a una solución y que tenga información pertinente para usted.

Tengo el problema de iOS 9 como lo describiste con mi IMAP de Courier, pero no con mi SASL SMTP AUTH. La criptografía en los 2 servidores es similar.

Notablemente, ambos usan certificados autofirmados.

Aquí están los resultados de "openssl s_client" que estoy viendo:

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

Por lo tanto, ahora estoy analizando la diferencia entre "ECDHE" y "DHE", y si las claves públicas del servidor de 4096 frente a las de 2048 bits hacen una diferencia.

Solo asumo que Apple mantiene STARTTLS para SMTP e IMAP con los mismos estándares ...

El correo funcionaba bien en iOS 9.1 hasta que cambié la "alerta" en Notificaciones a "alerta" hoy. Luego recibí un mensaje que decía algo como "No se puede recibir el correo" y que estaba usando la información de inicio de sesión incorrecta. (Lo siento, no recuerdo la redacción exacta del mensaje). Lo intenté dos veces y recibí el mismo mensaje ambas veces, pero recordé de inmediato lo que había cambiado en "Configuración" el día anterior, así que volví a Configuración > Notificaciones > Estilo de notificaciones > Correo > Estilo de alerta y luego seleccioné "Ninguno". Cuando volví a mi aplicación de correo funcionó bien otra vez. (Yo uso GMail.)

tuvimos el mismo problema en nuestra empresa. Tenemos casi la misma configuración de Debian, Courier IMAP e IOS9. Para nosotros se resolvió solo cuando usamos el puerto 143 para la conexión imap ssl.