La count IMAP dejó de funcionar después de la actualización a iOS 9 – ¿problema con el certificate CAcert?

Después de actualizar mi iPhone 6+ de iOS 8 a iOS 9, mi count de correo IMAP dejó de funcionar. Cuando la aplicación de correo intenta conectarse al server, falla y muestra una alerta con el título "No se puede recibir correo" y el post "El server de correo xyz no responde. Verifique que haya ingresado la información de la count correcta en la configuration de correo. ".

Revisé la información de la count, y de hecho es correcta. Curiosamente, no recibo ningún post de error de la aplicación de configuration cuando bash save la count. Intenté ingresar información incorrecta a propósito (nombre de usuario incorrecto, contraseña incorrecta, puerto TCP incorrecto) y cada vez que hago eso e bash save la count, la aplicación de configuration muestra una alerta "El server IMAP xyz no responde". Así que estoy realmente seguro de que la información que ingresé es correcta.

Además, tengo otros dos dispositivos iOS en el hogar (un iPad 2 y un iPhone 4S) que están configurados para usar la misma count y que todavía están en iOS 8. De estos dispositivos, la count funciona correctamente, así que también sé que el El problema no es algo básico, como que el server IMAP no funciona.

He intentado varias cosas (ver a continuación), pero sin éxito. Lo único que sé con certeza es que el problema está de alguna manera conectado a TLS y / o certificates. Teniendo en count la información de esta pregunta de AskDifferent , sospecho que es un problema con el certificate CAcert, pero no estoy seguro.

¿Sabe algo sobre los cambios en iOS 9 en relación con el event handling certificates (que no son de confianza o no)? ¿O tienes otras pistas que podrían ayudarme a resolver este problema?


Información sobre el server:

  • El server IMAP se ejecuta en una máquina Debian sobre la cual tengo control total
  • El server IMAP es Courier IMAP
  • El server IMAP acepta conexiones en el puerto IMAP estándar 143
  • El server IMAP requiere STARTTLS para exigir que todo el tráfico esté encryption a través de TLS
  • El server IMAP usa un certificate de comodín
  • El server IMAP proporciona toda la cadena de certificates al cliente
  • La CA raíz es CAcert.org ( enlace a los certificates de CA raíz e intermedia )
  • Debido a que CAcert.org no está, por defecto, en la tienda de CA de confianza de iOS 9, he instalado manualmente los certificates de CA raíz e intermedia en el iPhone 6+
  • Versión de correo = 0.73.1 ( /usr/bin/imapd --version )
  • Versión de OpenSSL = 1.0.2d ( /usr/bin/openssl version )

¿Qué he intentado?

  • Lo primero que hice fue eliminar toda la configuration de la count en la aplicación de configuration del iPhone, luego crear una count nueva y volver a ingresar los detalles de la configuration. Sin éxito.
  • Actualicé varios packages en la máquina Debian, incluidos Courier y OpenSSL, para asegurarme de que el server tenga las "últimas y mejores" capacidades de security. Sin éxito.
  • Leí en alguna parte que iOS 9 podría requerir TLS 1.2 en el lado del server, por lo que comprobé que el server IMAP realmente ofrezca esa versión de TLS a sus clientes. Lo hace. Este es el command que utilicé para la verificación: openssl s_client -connect mail.herzbube.ch:143 -starttls imap . Si ejecuta esto verá un bloque con información sobre la session SSL hacia el final, este bloque contiene una línea que muestra la versión TLS que se utiliza ( Protocol : TLSv1.2 ). Tenga en count que para get TLS v1.2, su versión cliente de OpenSSL también debe ser compatible. Por ejemplo, OpenSSL en mi computadora portátil Mac OS X Yosemite (10.10.3) es demasiado viejo, es decir, es solo la versión 0.9.8.zd y no parece entender TLS 1.2, así que obtengo el Protocol : TLSv1 .
  • Eliminé la raíz de CAcert y los certificates intermedios en el iPhone, luego los reinstalé. No, no ayudó.
  • Inhabilité temporalmente el requisito de TLS en el lado del server, y esto resuelve el problema, es decir, ahora la aplicación de correo puede conectarse, iniciar session y recibir correos electrónicos del server. Obviamente, esta no es una solución real, ya que no quiero que el tráfico al server IMAP esté en text claro, pero al less ahora sé que el problema está de alguna manera conectado a TLS (y / o certificates).
  • Actualicé el iPhone a iOS 9.0.1. Sin éxito.

  • Al iniciar session en Shoprite Wifi, Google bloquea mi count
  • Gmail no funciona con la aplicación de correo pnetworkingeterminada en iPhone 6 con solo datos
  • Aplicación de correo de terceros iOS que permite conexiones a múltiples puertos al mismo time
  • Mezcle push / pull mail en iPhone?
  • Los correos borrados o archivados en Mail.app no ​​desaparecen en el correo mobile
  • ¿Cómo marcar como LEER todos los correos electrónicos recibidos en iPhone?
  • ¿Cómo puedo preservar la información de BCC del correo de iOS?
  • ¿Cómo hago que diferentes counts de correo usen los sonidos pnetworkingeterminados otra vez?
  • 4 Solutions collect form web for “La count IMAP dejó de funcionar después de la actualización a iOS 9 – ¿problema con el certificate CAcert?”

    Resulta que en mi caso el problema no es el certificate CAcert, ni la versión TLS: son los encryptions de encriptación ofrecidos por OpenSSL en el server, o más bien, que algunos de ellos usan parameters que son demasiado débiles.

    Cuando Apple envió su actualización de iOS 8.4 hace un time, hicieron mejoras en su biblioteca TLS coreTLS con el fin de evitar el llamado ataque de Logjam. Es seguro suponer que estas mejoras también forman parte de iOS 9. Como Apple menciona en esta coreTLS , coreTLS ya no acepta suites de encryption de DH efímeras y resistentes a la export. En mi caso, este no es el problema, porque mi server no ofrece tales cifras a sus clientes.

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

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

    El server Courier IMAP tiene la siguiente línea en su file de configuration /etc/courier/imapd-ssl :

     TLS_DHPARAMS=/etc/courier/dhparams.pem 

    Cuando examino el file DH params, 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, 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 tamaño 2048 bits:

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

    Cambie los permissions del nuevo file para que coincidan con los permissions del file original:

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

    Luego actualicé el file de configuration Courier IMAP:

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

    y reinició el server

     /etc/init.d/courier-imap restart 

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


    PD: Arriba dije que los cambios coreTLS se enviaron con iOS 8.4, pero en mi pregunta afirmo que tengo dispositivos iOS 8 que no tienen ningún problema de connection IMAP. Ambas afirmaciones son ciertas, pero ahora me doy count de que olvidé mencionar en mi pregunta que esos dispositivos con iOS 8 todavía usan iOS 8.1.x. Lo siento por eso.


    Pruebas adicionales de protocolo: TLS_STARTTLS_PROTOCOL con la configuration IMAP de Courier TLS_STARTTLS_PROTOCOL , para forzar al cliente (aplicación de correo iOS 9) a una versión de protocolo TLS específica. Curiosamente, descubrí que ni TLSv1.2 ni TLSv1.1 parecen funcionar (SSL3 tampoco funciona, pero 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 configuration con iOS 8.1.2 – allí la aplicación de correo puede conectarse con las 3 versiones de protocolo (TLSv1.2, TLSv1.1, TLS1) e incluso SSL3.

    Esto es realmente, realmente extraño. Aunque es difícil de creer, por el momento parece que la aplicación de correo iOS 9 solo puede usar TLS1. A pesar de las mejoras en la security en el frente de encryption DH, no admitir TLSv1.2 sería una mala regresión, IMO. También podría ser que mi server esté mal configurado de alguna manera que no reconozco en este momento. Por lo tanto, sería útil si alguien más pudiera hacer testings similares para confirmar o descartar mis hallazgos.

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

    Tengo el problema de iOS 9 como describes con mi Courier IMAP, pero no con mi SASL SMTP AUTH. La cryptography en los 2 serveres es similar.

    En particular, ambos usan certificates 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 .[.>@..og....' 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 ....=...mm%/..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 

    Así que ahora estoy investigando la diferencia entre "ECDHE" y "DHE", y si las keys públicas del server de 4096 contra 2048 bits hacen la diferencia.

    Estoy asumiendo que Apple tiene 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 para "alertar" hoy. Luego recibí un post que decía algo así como "No se puede get el correo" y que estaba usando la información de inicio de session incorrecta. (Lo siento, no recuerdo la networkingacción exacta del post.) Lo intenté dos veces y recibí el mismo post las dos veces, pero de inmediato recordé lo que había cambiado en "Configuración" el día de hoy, así que volví a Configuración> Notificaciones> Estilo de notifications> Correo> Estilo de alerta y luego seleccioné "Ninguno". Cuando volví a mi aplicación de correo funcionó bien de nuevo. (Yo uso GMail)

    Tuvimos el mismo problema en nuestra compañía. Tenemos casi la misma configuration Debian, Courier IMAP e IOS9. Para nosotros, se resolvió cuando usamos el puerto 143 para la connection ssl imap.

    Loving Apple Products like poisoning (iPhone, iPad, iMac, Macbook, iWatch).