SSL (imap) bazı makinelerde çalışmıyor - ssl el sıkışma hatası - nasıl daha da daraltılır?


1

Birkaç gün önce IMAP SSL (port 993) bağlantılarımız , ev ağımızdan, ev ağımızdaki iki Windows 7 PC'den çalışmayı durdurdu .

Biri Windows XP, diğeri Win7 profesyonel 64bit olan iki bilgisayar daha iyi çalışıyor.

Ayrıca , VM için Bridged Networking kullanırken Win7 (üzerinde çalışmadığı) makineden Windows XP Mode'da da çalışır , ancak VM için NAT ağı kullanırken . Git figürü.

Bu bir ağ / donanım sorunu değil, zaten çalışan / çalışmayan makineleri aynı duvar prizine taktım ve ayrıca mutlu bir şekilde çalışan VM var.

Sorunun ne olduğunu bulmaya çalışırken, ben yüklü OpenSSL (Windows dan inşa burada (aşağıya bakın - - Ya düzgün çalışmıyor ben çek geçmeye google posta sunucusu kullanılır):) ve burada gördüklerimi var

Not: Tüm Windows 7 makineleri.


Kısa özet:

  • Bu gelen olur bizim ev ağına gelen çoklu makineleri

  • Diğer makinelerden çalışır, Win7 ve XP

  • ==> Bu nedenle, do o olduğunu farz (yerel) ağ sorunu yazılım sorunu - Sadece iki makine oldukça farklı olduğunu göz önüne alındığında, bir eşim HP Dizüstü konusunda hiçbir ipucu var, diğer benim kendini inşa oyun olduğunu PC - onlar yapmak zorunda aynı AV yazılımı yüklü, ama bu çoğunlukla bu.

  • AV'yi devre dışı bırakmayı denedim ve güvenlik duvarı boşuna değildi.

  • Ayrıca, bu birkaç gün önce "maviden" oldu - bir akşam önceki gün çalıştığı yerde işe yaramadı ve şimdi olduğu gibi, "aniden" AV olsaydı tuhaf olurdu.

  • Kesinlikle ettik değil başarısız başladı anda her iki makinelerde şey yüklü. (Modulo Windows, çok yakından takip etmediğim güncelleştirmeler, sadece oldukları zaman olduğu gibi.)

  • Thunderbird "IMAP sunucusuna bağlanılamıyor" bildiriyor, ama öyle değil , bir sayı-of-the bağlantıları sorunu.

  • OpenSSL şovları SSL23_WRITE:ssl handshake failure

  • Wireshark izi imaps [RST, ACK]son paket olarak gösteriyor

  • https bağlantılar (Firefox aracılığıyla) bu makinede tamamen iyi çalışıyor (IMAP tarafından kullanılanlarla aynı SSL bağlantısı mı?)


  • İlk hesap 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:
    
  • İkinci hesap sslmailpool.ispgateway.de(her ikisi de Alman sağlayıcı olsalar da, tamamen bağımsız olduklarını unutmayın):

    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 ile çapraz bağlantı: imap.gmail.com:993

Güncelleme : Bir OpenSSL bağlantısı ile şanslı olduğum halde, gmail.com/googlemail.com şu anda çalışmıyor. Gmail hesabımı IMAP üzerinden tunderbird ile bağlayamıyorum - diğer iki hesapla aynı sorunlar.

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

Ayrıca, yeniden denemeye çalışırken, google bağlantısı bazen bağlantıyı keser. unable to get local issuer certificate

  • Thunderbird her zaman yalnızca raporlar

IMAP sunucunuza bağlanılamıyor. Bu sunucuya maksimum bağlantı sayısını aştınız.

  • Bir Wireshark izi yapmak: ...

İşte OpenSSL çıktısı:

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:

Ve işte karşılık gelen Wireshark izi:

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

... ve için 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

Thunderbrid mesajı ilgisiz. Çoğu imap sunucusu, her IP Adresi için bir bağlantı sınırına (genellikle 10-20) sahiptir - tüm başarısız denemelerle ve testlerle gerçekten buna ulaşmış olabilirsiniz. Başka bir şey ahndshake sorunu. Sadece OpenSSL kullanarak kendimi denedim - ve iyi çalıştı. Belki de sisteminizin güvenilir sertifika zinciri bir nedenden ötürü düzeltilmiştir (ancak bu, thunderbird'ün arızasını kendi sertifikalarını kullandığı için açıklamaz).
Johannes H.

Eğer gerçekten sadece bağlantılar BTW'yi sınırlarsa, kendisini düzeltir. Bir süre bağlanmaya çalışmayın ve birkaç saat içinde tekrar deneyin.
Johannes H.

@JohannesH. - Teşekkürler. Bağlantı olmadığından eminim. sınırı. Ben sadece bunu tamlık için dahil ettim.
Martin,

İşte, artık yardım edersek, GMX'in Imap sunucuları ile (artık GMX hesabım olmadığından bağlantı kurma ve çıkma dışında hiçbir şey yapmadım), yardım etmesi durumunda: pastebin.com/Z0525rpX (hizalama-karışıklık için üzgünüm) Başlangıçta, bu benim terminal eumlator neden oldu sanırım)
Johannes H.

@JohannesH. - Şerefe. İkisinin de çalıştığını biliyorum, dediğim gibi birkaç gündür evden çalışmıyor ama ofisten çalışıyor.
Martin,

Yanıtlar:


1

Karanlıkta atış. Bağlanmayan makineler için kök sertifikalarını güncellediniz mi? Ayrıca sorunlu iş istasyonlarında tarih ve saatin doğru olduğundan emin olun.


Teşekkürler. Tarih ve saat tamam. - Kök sertifikalar sorun olsaydı, Thunderbird ve OpenSSL farklı davranış sergilemeliydi, çünkü farklı sertifikalar kullanıyorlardı.
Martin,

Ayrıca, VM bağlantılarının VM NAT kullanılırken çalışmadığını unutmayın, yalnızca VM köprü çalışır.
Martin

1

Evet, Martin’in dediği gibi, ben de '14 Şubat’ta başlayan ESET NOD32 Antivirus 5 ile aynı sorunu yaşadım. Thunderbird'den GMail ile çok fazla IMAP bağlantısı olabileceğime dair bir mesaj aldım.

Düzeltilmeye hazırım, ancak e-posta istemcisi korumasını 10 dakika devre dışı bırakmanın Thunderbird’ün tekrar düzgün bir şekilde bağlanmasına izin vermesi gerektiğini düşünüyorum. Bir şekilde IMAP üzerinden veri akışını yeniden etkinleştirmek için ESET'in bulunup bulunmadığından emin değilim, ancak şimdi çalışıyor ve yeniden yüklememe gerek kalmadı.

Düzenleme: E-posta istemcisi korumasını devre dışı bırakmak, Thunderbird'ün yalnızca işlevselliğin devre dışı bırakıldığı süre boyunca çalışmasına izin verir; bu nedenle bu çözümü test olarak kullanmak en iyisidir. Uzun vadeli çözüm, aboneliğiniz hala geçerliyse ESET NOD32 v5'ten v7'ye yükseltmektir.


0

Sonuçta AV / güvenlik duvarının sorun olduğu ortaya çıktı. İç çekmek.

Yazılımla ilgili ne olduğu hakkında hiçbir fikrim yok , ancak yazılımı kaldırmak hemen 993 numaralı bağlantı noktasındaki trafiği düzeltti (çünkü bu etkilenen tek SSL bağlantı noktasıydı). (Daha önce güvenlik duvarı olaylarını vb. Devre dışı bırakmayı denemiştim, ancak bu yardımcı olmadı.)

Şimdi ürünü yeniden yükledim ve çevrimiçi yükleyici daha yeni bir sürüm seçti ve her şey yeniden sorunsuz çalışıyor. ESET Smart Security 5 (NOD32) kullandım ve yeni sürüm ESS 7.

Sadece şunu göstermeye gider: Bir yazılım bileşeninden şüpheleniyorsanız, ayarlarına güvenmeyin. Kaldırmayı dene.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.