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

马丁

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

另外两台PC,其中一台装有Windows XP,一台也装有Win7 Professional 64位,就可以正常工作。

对VM使用桥接网络时,它也可以在Win7(无法在其上运行)计算机的Windows XP模式下工作,但对VM使用NAT网络时则不能去搞清楚。

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

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

注意:所有Windows 7计算机。


简短的摘要:

  • 这发生在 我们 来自台机器的 家庭网络中

  • 它可以在其他计算机,Win7和XP上运行

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

  • 我试图禁用AV,但它的防火墙无济于事。

  • 另外,这只是几天前“突然”发生的-一个晚上,它在前一天无法正常工作的地方工作了,就像现在这样,如果它“突然”是AV,那会很奇怪。

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

  • 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(请注意,尽管两者都是德国提供者,但它们是完全独立的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:
    
  • 与Google进行交叉检查: imap.gmail.com:993

更新:似乎我很幸运使用一个OpenSSL连接,但gmail.com/googlemail.com现在也无法正常工作。无法通过IMAP与Tunderbird连接我的gmail帐户-与其他两个帐户相同的问题。

(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
马丁

事实证明,AV /防火墙毕竟是问题所在。叹。

我不知道是什么让该软件陷入困境,但是将其卸载立即解决了端口993上的流量问题(因为这是唯一受影响的SSL端口)。(我以前曾尝试禁用它的防火墙功能,等等,但这无济于事。)

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

只是显示:如果您怀疑某个软件组件,请不要相信它的设置。尝试将其卸载。

本文收集自互联网,转载请注明来源。

如有侵权,请联系[email protected] 删除。

编辑于
0

我来说两句

0条评论
登录后参与评论

相关文章

来自分类Dev

如何处理Netty中的SSL握手失败

来自分类Dev

Websocket SSL握手失败

来自分类Dev

Weblogic SSL握手失败

来自分类Dev

Spring RestTemplate:SSL握手失败

来自分类Dev

Rails omniauth facebook SSL握手失败

来自分类Dev

与Facebook的Phantomjs连接失败SSL握手

来自分类Dev

Java SSL握手失败(SSLPoke)

来自分类Dev

nginx-记录SSL握手失败

来自分类Dev

ClientHello之后SSL握手失败

来自分类Dev

使用Logstash时SSL握手失败

来自分类Dev

带有SSL的RMI:握手失败

来自分类Dev

Rails omniauth facebook SSL握手失败

来自分类Dev

懒惰的“ take”函数如何进一步计算Scala流?

来自分类Dev

如何处理 SSL 握手

来自分类Dev

SSL握手失败SVN(无SSL证书)

来自分类Dev

如何解决错误SSL23_GET_SERVER_HELLO:sslv3警报握手失败

来自分类Dev

Cat7电缆仅在一台计算机上不起作用

来自分类Dev

Nginx反向代理到Heroku失败SSL握手

来自分类Dev

WSO2 ESB SSL握手失败

来自分类Dev

使用SpringAMQP时RabbitMQ SSL提供握手失败

来自分类Dev

Apache Bench:SSL握手失败与并发级别直接相关

来自分类Dev

由于握手问题,PerL SSL连接尝试失败

来自分类Dev

IBM Liberty和Cloudant之间的SSL握手失败

来自分类Dev

安装Crashlytics时出错-SSL对等握手失败

来自分类Dev

为什么ADF与mongodb.net的SSL握手失败?

来自分类Dev

Oauth,Net :: Twitter或SSL:500次握手失败

来自分类Dev

OpenSSL :: SSL :: SSLError与Homebrew OpenSSL握手失败

来自分类Dev

Java版本“ 1.7.0_79”的SSL握手失败

来自分类Dev

android asynchttpclient javax.net.ssl.SSLHandshakeException:握手失败