1

Несколько дней назад наши соединения IMAP SSL (порт 993) перестали работать из нашей домашней сети на двух компьютерах с Windows 7 в нашей домашней сети.

Два других ПК, один с Windows XP, другой также с 64-битной Win7 professional работают нормально.

Он также работает в режиме Windows XP с машины Win7 (на которой он не работает) при использовании мостовой сети для виртуальной машины, но не при использовании сети NAT для виртуальной машины. Пойди разберись.

Это не проблема сети / оборудования, я уже подключил работающие / не работающие машины к точно такой же настенной розетке, и к тому же, виртуальная машина с удовольствием работает.

Пытаясь выяснить, в чем дело, я установил OpenSSL (сборка Windows отсюда), и вот что я вижу: (Я использовал почтовый сервер Google для перекрестной проверки - тоже не работает - см. Ниже)

Примечание. Все машины с Windows 7.

Краткое содержание:

  • Это происходит из нашей домашней сети с нескольких машин

  • Он работает с других машин, Win7, а также XP

  • ==> Поэтому я предполагаю , что это проблема программного обеспечения (локальная) сеть проблема - я просто понятия не имеют , что, учитывая , что две машины весьма различны, одна - х годах Ноутбук HP моей жены, другой мой самодельных игровой PC - они имеют то же программное обеспечение AV установлен, но это в основном это.

  • Я попытался отключить AV, и это брандмауэр безрезультатно.

  • Кроме того, это просто произошло "на ровном месте" несколько дней назад - однажды вечером это просто не сработало там, где оно работало накануне, и сейчас так, спо, это было бы странно, если бы это "внезапно" было AV.

  • Я, конечно, ничего не установил на обеих машинах в тот момент, когда он начал выходить из строя. (Обновления по модулю Windows, которые я не отслеживаю слишком внимательно, так как они случаются, когда они случаются.)

  • Thunderbird сообщает "Невозможно подключиться к вашему серверу IMAP", но это не проблема количества соединений.

  • OpenSSL показывает SSL23_WRITE:ssl handshake failure

  • Трассировка Wireshark показывает imaps [RST, ACK] как последний пакет

  • Соединения https (через Firefox) на этом компьютере работают нормально (это то же SSL-соединение, которое используется IMAP?)

  • Первый аккаунт на 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 тоже не работает. Не удается подключить мою учетную запись Gmail через IMAP к 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)

Не следует также указывать, что при повторной попытке соединение с Google иногда зависает после 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
|источник

3 ответа3

1

Да, как упоминает Мартин, у меня была та же проблема с ESET NOD32 Antivirus 5, которая также началась в феврале 14 года. Я получил сообщение от Thunderbird о том, что у меня слишком много IMAP-соединений с GMail.

Я исправляюсь, но думаю, что простого отключения защиты почтового клиента на 10 минут было достаточно для правильного подключения Thunderbird. Я не уверен, что это каким-то образом заставило ESET повторно включить поток данных через IMAP, но сейчас он работает, и мне не пришлось переустанавливать его.

Изменить: Отключение защиты почтового клиента позволяет Thunderbird работать только в период, когда эта функция отключена, поэтому лучше использовать это решение в качестве теста. Долгосрочным решением является обновление с ESET NOD32 v5 до v7, которое бесплатно, если ваша подписка все еще действительна.

|источник
1

Выстрел в темноте. Вы обновили корневые сертификаты для компьютеров, которые не подключаются? Также убедитесь в правильности даты и времени на проблемных рабочих станциях.

|источник
0

Оказывается, проблема с AV/firewall была в конце концов. Вздох.

Я понятия не имею, что запуталось с программным обеспечением, но удаление его немедленно исправило трафик на порт 993 (так как это был единственный затронутый порт SSL). (Ранее я пытался отключить его брандмауэр и т.д., Но это не помогло.)

Теперь я переустановил продукт, и онлайн-установщик выбрал более новую версию, и все снова работает нормально.Я использовал ESET Smart Security 5 (NOD32), а новая версия - ESS 7.

Просто покажу: если вы подозреваете программный компонент, не доверяйте его настройкам. Попробуйте удалить его.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .