Il y a quelques jours, nos connexions IMAP SSL (port 993) ont cessé de fonctionner à partir de notre réseau domestique, deux ordinateurs Windows 7 dans notre réseau domestique.
Deux autres PC, l'un avec Windows XP, l'un aussi avec Win7 professionnel 64bit fonctionne très bien.
Il fonctionne également à partir du mode Windows XP à partir de la machine Win7 (sur laquelle il ne fonctionne pas) lorsque vous utilisez le réseau en réseau ponté pour la machine virtuelle, mais pas lorsque vous utilisez un réseau NAT pour la machine virtuelle . Allez comprendre.
Ce n'est pas un problème de réseau / matériel, j'ai déjà branché les machines qui fonctionnent / ne fonctionnent pas dans la même prise murale, et il y a aussi la VM qui fonctionne heureusement.
En essayant de savoir ce qui ne va pas, j'ai installé OpenSSL (Windows à partir d' ici ), et voici ce que je vois: (j'ai utilisé le serveur de messagerie Google pour vérifier le point de départ – ne fonctionne pas correctement non plus – voir ci-dessous)
Remarque: Toutes les machines Windows 7.
Court résumé:
Cela se produit de notre réseau domestique à partir de plusieurs machines
Il fonctionne à partir d'autres machines, Win7 ainsi que XP
==> Par conséquent, je suppose qu'il s'agit d'un problème de logiciel (local) sur le problème du réseau – je n'ai rien à voir avec quoi, étant donné que les deux machines sont plutôt dissemblables, l'ordinateur portable HP de ma femme, l'autre est mon jeu auto-construit PC – ils ont le même logiciel AV installé, mais c'est surtout le cas.
J'ai essayé de désactiver l'AV et son pare-feu en vain.
De plus, cela s'est passé "hors du jour" il y a quelques jours – un soir, il ne fonctionnait pas là où il fonctionnait la veille et c'est comme ça maintenant, il serait bizarre si «soudain» était l'AV.
Je n'ai certainement rien installé sur les deux machines au moment où il a commencé à échouer. (Modulo Windows mises à jour que je ne surveille pas trop, car elles se produisent quand elles se produisent).
Thunderbird rapporte «Impossible de se connecter à votre serveur IMAP», mais ce n'est pas un problème de nombre de connexions.
OpenSSL montre SSL23_WRITE:ssl handshake failure
Wireshark trace montre imaps [RST, ACK]
en dernier paquet
https
connexions https
(via Firefox) fonctionnent parfaitement sur cette machine (est-ce la même connexion SSL utilisée par IMAP?)
Premier compte à 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:
Deuxième compte à sslmailpool.ispgateway.de
(notez que si les deux sont des fournisseurs allemands, ils sont complètement indépendants)
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:
Crosscheck avec Google: imap.gmail.com:993
Mise à jour : alors qu'il me semble que j'ai eu de la chance avec une connexion OpenSSL, gmail.com/googlemail.com ne fonctionne plus maintenant. Impossible de connecter mon compte Gmail via IMAP avec tunderbird – les mêmes problèmes qu'avec les deux autres comptes.
(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)
Je ne devrais pas non plus, en essayant de réessayer, la connexion de Google bloque parfois après avoir unable to get local issuer certificate
Impossible de se connecter à votre serveur IMAP. Vous avez peut-être dépassé le nombre maximum de connexions à ce serveur.
Voici la sortie 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:
Et voici la trace Wireshark correspondante:
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
… et pour 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
Une balle dans l'obscurité. Avez-vous mis à jour les certificats racine pour les machines qui ne se connectent pas? Assurez-vous également que la date et l'heure sont correctes sur les stations de travail problématiques.
Oui, comme le mentionne Martin, j'ai eu le même problème avec ESET NOD32 Antivirus 5, qui a commencé en février 14. J'ai reçu un message de Thunderbird pour que j'aie eu trop de connexions IMAP à GMail.
Je dois être corrigé, mais pense que la désactivation de la protection du client par courrier électronique pendant 10 minutes suffit à permettre à Thunderbird de se connecter correctement à nouveau. Je ne suis pas sûr de savoir si, d'une certaine manière, ESET réactive le flux de données via IMAP, mais il fonctionne maintenant et je n'ai pas dû réinstaller.
Modifier: la désactivation de la protection du client de messagerie ne permet à Thunderbird de fonctionner pendant la période où la fonctionnalité est désactivée, il est donc préférable d'utiliser cette solution comme test. La solution à long terme consiste à passer de ESET NOD32 v5 à v7 qui est gratuite si votre abonnement est toujours valide.
Il s'avère que l'AV / le pare-feu était le problème après tout. Soupir.
Je n'ai aucune idée de ce qui a été dérangé avec le logiciel, mais la désinstallation a immédiatement corrigé le trafic sur le port 993 (car c'était le seul port SSL affecté). (J'avais déjà essayé de désactiver son matériel de pare-feu, etc., mais cela n'a pas aidé.)
J'ai maintenant réinstallé le produit et l'installateur en ligne a choisi une version plus récente et tout est en cours d'exécution à nouveau. J'ai utilisé ESET Smart Security 5 (NOD32) et la nouvelle version ESS 7.
Il suffit de montrer: si vous soupçonnez un composant logiciel, ne faites pas confiance à ses paramètres. Essayez de le désinstaller.