SSL(imap)在某些机器上不起作用 - SSL 握手失败 - 如何进一步缩小范围?

SSL(imap)在某些机器上不起作用 - SSL 握手失败 - 如何进一步缩小范围?

几天前,我们的家庭网络中的两台 Windows 7 PC 的 IMAP SSL(端口 993)连接停止工作。

另外两台电脑,一台安装有 Windows XP,另一台也安装有 Win7 专业版 64 位,运行正常。

它也可以在 Win7 的 Windows XP 模式下运行(但在 Win7 上无法运行)机器使用时桥接网络对于虚拟机来说,但是当虚拟机使用 NAT 网络时则不行。 去搞清楚。

这不是网络/硬件问题,我已经将工作/不工作的机器插入完全相同的墙上插座,并且虚拟机也正常运行。

在尝试找出问题所在时,我安装了OpenSSL(Windows 构建自这里),我看到的是:(我使用谷歌邮件服务器进行交叉检查 - 也无法正常工作 - 见下文)

注意:所有 Windows 7 机器。


简短的摘要:

  • 这是从我们的家庭网络发生的多种的机器

  • 它可以在其他机器上运行,包括 Win7 和 XP

  • ==> 因此,我假设这是一个(本地)网络问题软件问题 - 我只是不知道是什么,因为这两台机器相当不同,一个是我妻子的 HP 笔记本电脑,另一个是我自己组装的游戏电脑 - 他们相同的 AV 软件已安装,但基本上就是这样。

  • 我尝试禁用 AV 及其防火墙,但没有效果。

  • 此外,这件事几天前就“突然”发生了——一天晚上,它在前一天正常工作的地方就不工作了,现在也是这样,所以如果它“突然”变成 AV 那就很奇怪了。

  • 我当然不是在开始出现故障时,在两台机器上都安装了任何东西。(Modulo Windows 更新我不会太密切地监视,因为它们只是发生时才发生。)

  • Thunderbird 报告“无法连接到您的 IMAP 服务器。”,但它不是连接数量问题。

  • OpenSSL 显示SSL23_WRITE:ssl handshake failure

  • Wireshark 跟踪显示imaps [RST, ACK]为最后一个数据包

  • https连接(通过 Firefox)在这台机器上运行良好(它与 IMAP 使用的 SSL 连接相同吗?)


  • 第一个帐户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:
    
  • 第二个帐户sslmailpool.ispgateway.de(请注意,虽然两者都是德国提供商,但据我所知他们是完全独立的):

    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:
    
  • 使用 Google 进行交叉检查:imap.gmail.com:993

更新:虽然我似乎很幸运地通过了一个 OpenSSL 连接,但 gmail.com/googlemail.com 现在也无法使用。无法通过 IMAP 将我的 gmail 帐户与 tunderbird 连接 - 与其他两个帐户存在同样的问题。

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

我也不应该,当重新尝试时,谷歌连接有时会在unable to get local issuer certificate

无法连接到您的 IMAP 服务器。您可能已超出此服务器的最大连接数。

  • 执行 Wireshark 跟踪:...

以下是 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:

以下是相应的 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

... 以及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

答案1

瞎猜。您是否更新了无法连接的机器的根证书?还要确保问题工作站上的日期和时间正确。

答案2

是的,正如 Martin 提到的,我也遇到了与 ESET NOD32 Antivirus 5 相同的问题,也是从 2014 年 2 月开始的。我收到 Thunderbird 的消息,说我可能与 GMail 建立了过多的 IMAP 连接。

我愿意接受纠正,但我认为只需禁用电子邮件客户端保护 10 分钟就足以让 Thunderbird 再次正常连接。我不确定这是否以某种方式让 ESET 重新启用通过 IMAP 的数据流,但它现在正在运行,我不必重新安装。

编辑:禁用电子邮件客户端保护仅允许 Thunderbird 在功能被禁用期间工作,因此最好将该解决方案用作测试。长期解决方案是从 ESET NOD32 v5 升级到 v7,如果您的订阅仍然有效,则升级是免费的。

答案3

事实证明,问题出在 AV/防火墙上。叹。

我不知道什么软件搞乱了,但卸载后立即修复了端口 993 上的流量(因为这是唯一受影响的 SSL 端口)。(我之前曾尝试禁用防火墙等,但没有帮助。)

我现在已经重新安装了该产品,在线安装程序选择了较新的版本,一切又恢复正常。我使用的是 ESET Smart Security 5 (NOD32),新版本是 ESS 7。

这表明:如果您怀疑某个软件组件,请不要信任其设置。尝试卸载它。

相关内容