SSL (imap) não funciona em algumas máquinas - falha de handshake ssl - como diminuir ainda mais?

Question

Alguns dias atrás, nossas conexões IMAP SSL (porta 993) pararam de funcionar em nossa rede doméstica dois PCs Windows 7 em nossa rede doméstica.

Dois outros PCs, um com o Windows XP, outro também com o profissional de 64 bits do Win7 funcionam bem.

Ele também funciona a partir do Windows XP Mode da máquina Win7 (em que não está funcionando) ao usar Networking em ponte para a VM, mas não ao usar a rede NAT para a VM . Vá a figura.

Não é um problema de rede / hardware, eu já pluguei as máquinas que funcionam / não funcionam exatamente no mesmo soquete de parede, e também há a VM trabalhando alegremente.

Ao tentar descobrir o que está errado, eu instalei o OpenSSL (construção do Windows a partir de aqui ), e aqui está o que eu vejo: (eu usei o servidor de e-mail do Google para checar a verificação cruzada - também não funciona corretamente - veja abaixo)

Nota: todas as máquinas com o Windows 7.

Breve resumo:

• Isso acontece em nossa rede doméstica em várias máquinas

• Funciona de outras máquinas, Win7 e XP

• == > Portanto, eu faço assumir que é um problema de software questão de rede - eu não tenho idéia do que, dado que as duas máquinas são bastante diferentes, é o Laptop HP da minha esposa, o outro é o meu PC de jogos auto-construído - eles fazem tem o o mesmo software antivírus instalado, mas é principalmente isso.

• Eu tentei desativar o antivírus e seu firewall sem sucesso.

• Além disso, isso só aconteceu "do nada" há alguns dias - uma noite, simplesmente não funcionava onde funcionava no dia anterior e é assim agora, seria estranho se " de repente "foram os AV.

• Eu certamente não instalei qualquer coisa em ambas as máquinas no momento em que ela começou a falhar. (Modulo Windows atualiza o que eu não monitora muito de perto, como eles acontecem quando acontecem.)

• O Thunderbird informa "Não é possível conectar-se ao seu servidor IMAP", mas não é um problema de número de conexões.

• O OpenSSL mostra SSL23_WRITE:ssl handshake failure

• O rastreio do Wireshark mostra imaps [RST, ACK] como último pacote

• https connections (via Firefox) funciona perfeitamente nesta máquina (é a mesma conexão SSL usada pelo IMAP?)

• Primeira conta em imap.gmx.net:993 :

  C:\Users\martin>openssl s_client -connect imap.gmx.net:993
  CONNECTED(00000003)
  5852:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
  

• Segunda conta em sslmailpool.ispgateway.de (note que enquanto ambos são provedores alemães, eles são completamente independentes):

  C:\Users\martin>openssl s_client -connect sslmailpool.ispgateway.de:993
  CONNECTED(00000003)
  4288:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
  

• Verifique com o Google: imap.gmail.com:993

Atualizar : Embora pareça que tive sorte com uma conexão OpenSSL, o gmail.com/googlemail.com não está funcionando agora. Não é possível conectar minha conta do Gmail pelo IMAP com o tunderbird - os mesmos problemas das outras duas contas.

(1)

C:\Users\martin>openssl s_client -connect imap.gmail.com:993
CONNECTED(00000003)
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=imap.gmail.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEdjCCA16gAwIBAgIINAwAQ8mvPHwwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UE
...
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=imap.gmail.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
---
SSL handshake has read 3231 bytes and written 432 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
    Session-ID: EC0A386BA...
    Session-ID-ctx:
    Master-Key: 462251B....
    Key-Arg   : None
    Start Time: 1391458141
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
* OK Gimap ready for requests from 85.127.220.93 v13if18594894eej.137

(2)

Eu também não deveria que, ao tentar novamente, a conexão do Google às vezes trava após unable to get local issuer certificate

• O Thunderbird sempre apenas relatórios

Unable to connect to your IMAP server. You may have exceeded the maximum number of connections to this server.

• Fazendo um rastreamento do Wireshark: ...

Aqui está a saída do OpenSSL:

C:\Users\martin>openssl s_client -connect sslmailpool.ispgateway.de:993
CONNECTED(00000003)
depth=1 /C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA
verify error:num=20:unable to get local issuer certificate
verify return:0
4720:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:

E aqui está o traçado correspondente do Wireshark:

No.     Time           Source                Destination           Protocol Length Info
      1 0.000000000    192.168.178.31        80.67.29.6            TCP      66     51421 > imaps [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
      2 0.039910000    80.67.29.6            192.168.178.31        TCP      66     imaps > 51421 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1420 SACK_PERM=1 WS=64
      3 0.039990000    192.168.178.31        80.67.29.6            TCP      54     51421 > imaps [ACK] Seq=1 Ack=1 Win=66740 Len=0
      4 0.042722000    192.168.178.31        80.67.29.6            SSLv2    172    Client Hello
      5 0.084554000    80.67.29.6            192.168.178.31        TCP      60     imaps > 51421 [ACK] Seq=1 Ack=119 Win=5888 Len=0
      6 0.102205000    80.67.29.6            192.168.178.31        TLSv1    1474   Server Hello
      7 0.103826000    80.67.29.6            192.168.178.31        TLSv1    1474   Certificate
      8 0.103880000    192.168.178.31        80.67.29.6            TCP      54     51421 > imaps [ACK] Seq=119 Ack=2841 Win=66740 Len=0
      9 0.143686000    80.67.29.6            192.168.178.31        TLSv1    178    Server Key Exchange
     10 0.343232000    192.168.178.31        80.67.29.6            TCP      54     51421 > imaps [ACK] Seq=119 Ack=2965 Win=66616 Len=0
     30 60.080125000   80.67.29.6            192.168.178.31        TCP      60     imaps > 51421 [FIN, ACK] Seq=2965 Ack=119 Win=5888 Len=0
     31 60.080280000   192.168.178.31        80.67.29.6            TCP      54     51421 > imaps [ACK] Seq=119 Ack=2966 Win=66616 Len=0
     32 60.082774000   192.168.178.31        80.67.29.6            TCP      54     51421 > imaps [RST, ACK] Seq=119 Ack=2966 Win=0 Len=0

... e para gmx.imap.net :

No.     Time           Source                Destination           Protocol Length Info
      9 5.948764000    192.168.178.31        212.227.17.170        TCP      66     51551 > imaps [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
     10 5.990774000    212.227.17.170        192.168.178.31        TCP      66     imaps > 51551 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1420 SACK_PERM=1 WS=512
     11 5.990852000    192.168.178.31        212.227.17.170        TCP      54     51551 > imaps [ACK] Seq=1 Ack=1 Win=66560 Len=0
     12 5.994007000    192.168.178.31        212.227.17.170        TCP      83     [TCP segment of a reassembled PDU]
     13 6.036307000    212.227.17.170        192.168.178.31        TCP      60     imaps > 51551 [ACK] Seq=1 Ack=30 Win=14848 Len=0
     14 16.041594000   212.227.17.170        192.168.178.31        TCP      60     imaps > 51551 [FIN, ACK] Seq=1 Ack=30 Win=14848 Len=0
     15 16.041751000   192.168.178.31        212.227.17.170        TCP      54     51551 > imaps [ACK] Seq=30 Ack=2 Win=66560 Len=0
     16 16.043491000   192.168.178.31        212.227.17.170        TCP      54     51551 > imaps [RST, ACK] Seq=30 Ack=2 Win=0 Len=0

    

Answer 1

Acontece que o AV / firewall era o problema afinal. Suspiro.

Eu não tenho ideia do que me atrapalhou com o software, mas a desinstalação imediatamente corrigiu o tráfego na porta 993 (já que essa era a única porta SSL afetada). (Eu já havia tentado desativar o firewall, etc., mas isso não ajudou.)

Eu já reinstalei o produto e o instalador on-line escolheu uma versão mais recente e tudo está funcionando perfeitamente. _{Eu usei o ESET Smart Security 5 (NOD32) e a nova versão é o ESS 7.}

Apenas para mostrar: Se você suspeitar de um componente de software, não confie nas configurações dele. Tente desinstalá-lo.

    

Answer 2

Filmado no escuro. Você atualizou os certificados raiz das máquinas que não serão conectadas? Verifique também se a data e a hora estão corretas nas estações de trabalho com problemas.

    

Answer 3

Sim, como Martin menciona, eu tive o mesmo problema com o ESET NOD32 Antivirus 5, que começou em fevereiro de 2014 também. Eu recebi uma mensagem do Thunderbird que eu posso ter tido muitas conexões IMAP para o GMail.

Eu tenho que ser corrigido, mas acho que apenas desativar a proteção do cliente de e-mail por 10 minutos foi suficiente para permitir que o Thunderbird se conecte novamente. Não tenho certeza se isso de alguma forma fez com que a ESET reativasse o fluxo de dados via IMAP, mas agora está funcionando e não precisei reinstalá-lo.

Editar: Desabilitar a proteção do cliente de email só permite que o Thunderbird funcione durante o período em que a funcionalidade é desativada, por isso é melhor usar essa solução como um teste. A solução a longo prazo é atualizar do ESET NOD32 v5 para o v7, que é gratuito se sua assinatura ainda for válida.