A conta IMAP parou de funcionar após a atualização para o iOS 9 - problema com o certificado CAcert?

Depois de atualizar meu iPhone 6+ do iOS 8 para o iOS 9, minha conta de email IMAP parou de funcionar. Quando o aplicativo de email tenta se conectar ao servidor, ele falha e exibe um alerta com o título "Não é possível obter email" e a mensagem "O servidor de email xyz não está respondendo. Verifique se você inseriu as informações corretas da conta nas configurações de email. "

Eu verifiquei as informações da conta e está realmente correta. Curiosamente, não recebo nenhuma mensagem de erro do aplicativo de configurações quando tento salvar a conta. Tentei inserir informações incorretas de propósito (nome de usuário, senha incorretos, porta TCP incorreta) e sempre que faço isso e tento salvar a conta, o aplicativo de configurações exibe um alerta "O servidor IMAP xyz não está respondendo". Então, eu estou realmente certeza de que a informação que eu tenho introduzido está correcto.

Além disso, eu tenho dois outros dispositivos iOS em casa (um iPad 2 e um iPhone 4S) configurados para usar a mesma conta e que ainda estão no iOS 8 - a partir desses dispositivos, a conta funciona corretamente, então eu também sei que o problema não é algo básico, como o servidor IMAP está inoperante.

Eu tentei várias coisas (veja abaixo), mas sem sucesso. A única coisa que sei com certeza é que o problema está de alguma forma conectado ao TLS e / ou certificados. Levando em conta as informações desta pergunta AskDifferent , suspeito que seja um problema com o certificado CAcert, mas não tenho certeza.

Você sabe alguma coisa sobre as alterações no iOS 9 em relação à manipulação de certificados (não confiáveis ​​ou não)? Ou você tem outras pistas que podem me ajudar a resolver esse problema?

Informações sobre o servidor:

• O servidor IMAP é executado em uma máquina Debian sobre a qual eu tenho controle total
• O servidor IMAP é Courier IMAP
• O servidor IMAP aceita conexões na porta IMAP padrão 143
• O servidor IMAP exige que o STARTTLS imponha que todo o tráfego seja criptografado via TLS
• O servidor IMAP usa um certificado curinga
• O servidor IMAP fornece toda a cadeia de certificados ao cliente
• A CA raiz é CAcert.org ( link para certificados de CA raiz e intermediária )
• Como o CAcert.org não está, por padrão, no repositório de CA confiável do iOS 9, instalei manualmente os certificados de CA raiz e intermediária no iPhone 6+
• Versão Courier = 0.73.1 ( /usr/bin/imapd --version)
• Versão do OpenSSL = 1.0.2d ( /usr/bin/openssl version)

O que eu tentei?

• A primeira coisa que fiz foi excluir a configuração da conta inteira no aplicativo de configurações do iPhone, criar uma nova conta e inserir novamente os detalhes da configuração. Sem sucesso.
• Atualizei vários pacotes na máquina Debian, incluindo Courier e OpenSSL, para garantir que o servidor tenha os "melhores e mais recentes" recursos de segurança. Sem sucesso.
• Eu li em algum lugar que iOS 9 pode exigir TLS 1.2 no lado do servidor, então eu verifiquei que o servidor IMAP oferece, de facto essa versão do TLS aos seus clientes. Faz. Este é o comando que eu usei para verificação: openssl s_client -connect mail.herzbube.ch:143 -starttls imap. Se você executar isso, verá um bloco com informações sobre a sessão SSL no final, esse bloco conterá uma linha que mostra a versão do TLS usada ( Protocol : TLSv1.2). Observe que, para obter o TLS v1.2, sua versão do OpenSSL do lado do cliente também deve suportar isso. Por exemplo, o OpenSSL no meu laptop Mac OS X Yosemite (10.10.3) é muito antigo, ou seja, é apenas a versão 0.9.8.zd e parece não entender o TLS 1.2, pelo que entendi Protocol : TLSv1.
• Excluí os certificados raiz e intermediário do CAcert no iPhone e os reinstalei. Não, não ajudou.
• Desativei temporariamente o requisito do TLS no lado do servidor, e isso resolve o problema, ou seja, agora o aplicativo Mail pode se conectar, fazer login e receber e-mails do servidor. Obviamente, essa não é uma solução real, pois não quero que o tráfego para o servidor IMAP seja em texto não criptografado, mas pelo menos agora sei que o problema está de alguma forma conectado ao TLS (e / ou certificados).
• Atualizei o iPhone para o iOS 9.0.1. Sem sucesso.

Acontece que, no meu caso, o problema não é o certificado CAcert, nem a versão TLS - são as cifras de criptografia oferecidas pelo OpenSSL no servidor, ou melhor, que algumas delas usam parâmetros muito fracos.

Quando a Apple lançou a atualização do iOS 8.4 há um tempo, eles fizeram melhorias em sua biblioteca TLS coreTLSpara evitar o chamado ataque Logjam. É seguro supor que essas melhorias também fazem parte do iOS 9. Como a Apple menciona nesta nota técnica , coreTLSnão aceita mais pacotes de cifras DH efêmeros com força de exportação. No meu caso, esse não é o problema, porque meu servidor não oferece essas cifras para seus clientes.

O que a Apple "esqueceu" de dizer em sua nota técnica é que eles também adicionaram novos requisitos para as demais cifras DH. Nisso, eles provavelmente seguiram o Guide to Deploying Diffie-Hellman for TLS , que é um documento "oficial" com recomendações feitas pelas pessoas que descobriram o ataque Logjam. Especificamente, coreTLSagora exige que os conjuntos de cifras DH usem um tamanho mínimo de grupo DH.

O "grupo DH" é um parâmetro para cifras DH cuja força é medida pelo seu tamanho em bits. O guia mencionado acima menciona que os navegadores modernos agora exigem um tamanho mínimo de grupo DH de 1024. Aparentemente coreTLS, também adotou esse requisito, porque foi o que descobri no meu servidor ...

O servidor IMAP Courier possui a seguinte linha em seu arquivo de configuração /etc/courier/imapd-ssl:

TLS_DHPARAMS=/etc/courier/dhparams.pem

Quando examino o arquivo de parâmetros DH, recebo a seguinte saída:

$ 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 pode ser visto, esse grupo DH possui apenas um tamanho de 768 bits, o que definitivamente não está de acordo com os padrões modernos.

Para resolver o problema, criei um novo grupo DH com tamanho aumentado. Segui o conselho do "Guide to Deploying DH" e criei um grupo com tamanho 2048 bits:

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

Altere as permissões do novo arquivo para que correspondam às permissões do arquivo original:

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

Atualizei o arquivo de configuração do Courier IMAP:

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

e reiniciou o servidor

/etc/init.d/courier-imap restart

Depois disso, o aplicativo Mail funcionou bem. Problema resolvido.

PS: Acima, eu disse que as coreTLSalterações foram enviadas com o iOS 8.4, mas, na minha pergunta, afirmo que tenho dispositivos iOS 8 que não apresentam problemas de conexão IMAP. Ambas as afirmações são verdadeiras, mas agora percebo que esqueci de mencionar na minha pergunta que esses dispositivos iOS 8 ainda estão usando o iOS 8.1.x. Desculpe por isso.

Testes adicionais de protocolo: brinquei com a configuração Courier IMAP TLS_STARTTLS_PROTOCOL, para forçar o cliente (aplicativo iOS 9 Mail) a uma versão específica do protocolo TLS. Estranhamente, descobri que nem o TLSv1.2 nem o TLSv1.1 parecem funcionar (o SSL3 também não funciona, mas tudo bem). A única opção que funciona é

TLS_STARTTLS_PROTOCOL=TLS1

(isso permanece verdadeiro mesmo depois que eu atualizei o tamanho do grupo DH)

Testei as mesmas configurações com o iOS 8.1.2 - lá, o aplicativo Mail pode conectar-se às 3 versões do protocolo (TLSv1.2, TLSv1.1, TLS1) e até SSL3.

Isso é muito, muito estranho. Embora seja difícil de acreditar, no momento parece que o aplicativo iOS 9 Mail pode usar apenas o TLS1. Apesar das melhorias na segurança na frente da cifra DH, não oferecer suporte ao TLSv1.2 seria uma regressão ruim, IMO. Também pode ser que meu servidor esteja de alguma forma configurado incorretamente de uma maneira que não reconheço no momento. Portanto, seria útil se outra pessoa pudesse fazer testes semelhantes para confirmar ou descartar minhas descobertas.

Eu tenho o mesmo problema, mas ainda não tenho resposta. Espero que eu esteja me aproximando de uma solução e que tenha informações pertinentes para você.

Eu tenho o problema do iOS 9 conforme descrito no meu Courier IMAP, mas não no meu SASL SMTP AUTH. A criptografia nos 2 servidores é semelhante.

Notavelmente, ambos usam certificados autoassinados.

Aqui estão as saídas "openssl s_client" que eu estou olhando:

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

Portanto, agora estou analisando a diferença entre "ECDHE" e "DHE" e se as chaves públicas do servidor de 4096 x 2048 bits fazem a diferença.

Estou apenas assumindo que a Apple está mantendo STARTTLS para SMTP e IMAP com os mesmos padrões ...

O e-mail estava funcionando bem no iOS 9.1 até eu alterar o "alerta" em Notificações para "alerta" hoje. Em seguida, recebi uma mensagem dizendo algo como "Não é possível receber o correio" e que eu estava usando as informações de login incorretas. (Desculpe, não me lembro do texto exato da mensagem.) Tentei duas vezes e recebi a mesma mensagem nas duas vezes, mas lembrei-me imediatamente do que havia alterado em "Configurações" hoje mais cedo e voltei para Configurações> Notificações> Estilo de notificações> Correio> Estilo de alerta e, em seguida, selecione "Nenhum". Quando voltei ao meu aplicativo Mail, funcionou bem novamente. (Eu uso o GMail.)

nós tivemos o mesmo problema em nossa empresa. Temos quase a mesma configuração Debian, Courier IMAP e IOS9. Para nós, ele se resolveu quando usamos a porta 143 para a conexão ssl imap.