SSL (imap) doesn't work from some machines - ssl handshake failure - how to narrow down further?

Question

A few days ago our IMAP SSL (port 993) connections stopped working from our home network two Windows 7 PCs in our home network.

Two other PCs, one with Windows XP, one also with Win7 professional 64bit work just fine.

It also works from the Windows XP Mode from the Win7 (on which it's not working) machine when using Bridged Networking for the VM, but not when using NAT networking for the VM. Go figure.

It is not a network/hardware issue, I already plugged the working/not working machines into exactly the same wall socket, and also there's the VM happily working.

While trying to find out what's wrong, I installed OpenSSL (Windows build from here), and here's what I see: (I used the google mail server to cross check - doesn't work properly either - see below)

Note: All Windows 7 machines.

---

Short summary:

• This happens from our home network from multiple machines

• It works from other machines, Win7 as well as XP

• ==> Therefore, I do assume it's a (local) network issue software issue - I just have no clue what, given that the two machines are rather dissimilar, one's the HP Laptop of my wife, the other is my self-built gaming PC - they do have the same AV software installed, but that's mostly it.

• I tried disabling the AV and it's firewall to no avail.

• Also, this just happened "out of the blue" a few days ago - one evening it just didn't work where it worked the day before and it's like that now, spo it would be weird if it "suddenly" were the AV.

• I've certainly not installed anything on both machines at the time it started to fail. (Modulo Windows updates which I don't monitor too closely, as they just happen when they happen.)

• Thunderbird reports "Unable to connect to your IMAP server.", but it is not a number-of-connections issue.

• OpenSSL shows SSL23_WRITE:ssl handshake failure

• Wireshark trace shows imaps [RST, ACK]as last packet

• https connections (via Firefox) work totally fine on this machine (is it the same SSL connection as used by IMAP?)

---

• First account at 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:
  

• Second account at sslmailpool.ispgateway.de (note that while both are german providers, they are completely independent afaikt):

  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 with Google: imap.gmail.com:993

Update: While it seems I got lucky with one OpenSSL connection, gmail.com/googlemail.com isn't working either now. Can't connect my gmail account via IMAP with tunderbird - same problems as with the other two accounts.

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

I should also not that, when re-trying, the google connection sometimes hangs after unable to get local issuer certificate

• Thunderbird always only reports

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

• Doing a Wireshark trace: ...

Here's the OpenSSL output:

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:

And here's the corresponding Wireshark trace:

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

... and for 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

Solution 1

It turns out the AV/firewall was the problem after all. Sigh.

I've no clue what got messed up with the software, but uninstalling it immediately fixed the traffic on port 993 (as this was the only SSL port affected). (I had previously tried to disable it's firewall stuff, etc., but that didn't help.)

I've now re-installed the product and the online installer chose a newer version and everything is running smooth again._{I used ESET Smart Security 5 (NOD32) and the new version is ESS 7.}

Just goes to show: If you suspect a software component, don't trust it's settings. Try to uninstall it.

Solution 2

Yes as Martin mentions, I had the same problem with ESET NOD32 Antivirus 5, that started in Feb '14 too. I got a message from Thunderbird that I may have had too many IMAP connections to GMail.

I stand to be corrected, but think just disabling the email client protection for 10 minutes was enough to let Thunderbird connect properly again. I'm not sure if that somehow got ESET to re-enable the flow of data via IMAP, but it's working now and I didn't have to re-install.

Edit: Disabling email client protection only allows Thunderbird to work during the period that the functionality is disabled, so it's best to use that solution as a test. The long-term solution is to upgrade from ESET NOD32 v5 to v7 which is free if your subscription is still valid.

Solution 3

Shot in the dark. Have you updated the root certificates for the machines that wont connect? Also make sure the date and time is correct on the problem workstations.

Comments

[Johannes H.]

Thunderbrid message is unrelated. Most imap servers have a conneciton limit (usually 10-20) for each IP-Address - with all the unsuccessfull tries and testing, you might really have reached that. The other thing is the ahndshake-issue. I just tried myself using OpenSSL - and it worked fine. Maybe your system's trusted certificate chain is corrputed for some reason (but that wouldn't explain thunderbird'S faiulure, as it uses its own certificates...)?

[Johannes H.]

If it's really just the conections limit BTW, it fixes itself. JUst don't try to connect for a while and try again in a few hours.

[Martin]

@JohannesH. - thanks. I'm very sure it ain't the conn. limit. I just included this for completeness.

[Johannes H.]

Here is a paste of the successfull communication (didn't do anything besides connecting and exiting, as I have no GMX account anymore) with GMX's Imap servers, in case it does help: pastebin.com/Z0525rpX (sorry for the aligning-mess in the beginning, that was caused by my terminal eumlator I guess)

[Martin]

@JohannesH. - cheers. I know that both work, as I said it'S not working for several days now from home but it's working from the office.

[Johannes H.]

Your phone (which is working) - does it use WLAN and connect from inside your local network, or does it use mobile data (and has its own IP)? If the latter - does it still work fi you connect it to your network? (This should test if it's a software issue or tied to your IP-Address or network)

[Martin]

@JohannesH. - the phone connects via 3G, not related to the local network. I can't test WiFi, but the second cable bound machine isn't working either, so I do assume it's a network issue - I just have no clue what.

[Ram]

What OS are you using? What happens if you use a browser to go to yourimapserver:993

[Martin]

Thanks. Date and time are OK. - If the root certificates were the problem, then Thunderbird and OpenSSL should behave differently, because they use different certificates afaik?

[Martin]

Also note that the VM conbnection doesn't work when using VM NAT, only VM bridged works.