none
SSL3_ALERT_HANDSHAKE_FAILURE RRS feed

  • Вопрос

  • Некоторые почтовые системы получают от нас сообщение о невозможности произвести «рукопожатие» при согласовании параметров для шифрования соединения при доставке корреспонденции от них к нам.

    Мы проанализировали протоколы работы коннектора получения Exchange и журнал системы Windows.

    В протоколе работы коннектора получения Exchange мы видим: TLS negotiation failed with error AlgorithmMismatch.

    В событиях системы этому сообщению предшествуют два события:

    36874 (An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.)

    36888 (A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 1205.).

    Сразу же встал вопрос по тому что же данные почтовые системы хотят с нами согласовать и что у нас согласовать не получается, точнее какой протокол и какой шифр. После анализа трафика Wireshark’ок мы отследили какие именно наборы шифров (TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA) не может согласовать наш почтовый сервер, т.к. протокол везде был один и тот же (TLS1.2).

    Так, как у нас нет ограничения на применения наборов шифров, встал вопрос какие шифры использует сервер по умолчанию. Данную информацию мы нашли здесь (https://msdn.microsoft.com/en-us/library/windows/desktop/mt767781%28v=vs.85%29.aspx). Очевидно, что вопросов по согласованию шифров быть не должно, т.к. данные шифры доступны для согласования по-умолчанию.

    Использую OpenSSL мы с эмулировали ситуацию (openssl s_client -cipher "AES256-SHA:AES128-SHA" -connect EXCH:25 -starttls smtp -tls1_2) и получили тот же ответ от нашего сервера, что и сторонние почтовые системы: TLS negotiation failed with error AlgorithmMismatch.

    Что бы проверить, то что сервер действительно может работать с данными шифрами, мы произвели тестовую отправку писем на адреса сторонней почтовой системы и увидели тем же Wireshark’ок, что в приветствии клиента(нашего почтового сервера) в наборе шифров для согласования присутствуют вышеупомянутые шифры.

    Вопрос: Почему наш сервер не согласует клиентам данные шифры (TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA) ?

    21 ноября 2016 г. 18:05

Ответы

  • а у вас какой CU?

    В CU2 по умолчанию теперь все сертификаты SHA2, попробуйте обновиться и попробовать еще раз.

    Вы этим замечанием навели нас на мысль)))

    Мы проверили привязку сертификата к коннекторам получения почты (Get-ReceiveConnector -Identity "EXCH" | fl *CertificateName*) и проверили в нем доступные алгоритмы криптографического хеширования. И все стало ясно, администратор ответственный за настройку безопасного соединения, сконфигурировал работу коннекторов получения почты на работу с полученным, проверенным сертификатом, который использует только алгоритм криптографического хеширования SHA256, поэтому вышеупомянутые шифры никак не могли быть согласованы нашими почтовыми серверами.

    • Предложено в качестве ответа Mikhail SartaevMVP 23 ноября 2016 г. 8:44
    • Помечено в качестве ответа Pavel Belyj 23 ноября 2016 г. 8:47
    22 ноября 2016 г. 19:57

Все ответы

  • а у вас какой CU?

    В CU2 по умолчанию теперь все сертификаты SHA2, попробуйте обновиться и попробовать еще раз.

    в CU3 есть такой лог при установке:

    Set-ItemProperty -path $keyPath -name “Functions” -value “TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_RC4_128_MD5” -Force;


    scientia potentia est
    My blog

    22 ноября 2016 г. 13:58
  • У нас стоит CU2 (Version 15.1 (Build 466.34)

    При обновлении до CU2, была выполнена и установка ограничения на использования шифров (это можно отследить по логам установки Install-CafeRole*.ps1):

    1000 строка содержит вот такую запись:

    Set-ItemProperty -path $keyPath -name "Functions" –value "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_RC4_128_MD5" -Force;

    Однако это не противоречит тому, что я описал выше. При внесении ограничений в политику использования шифров сервером, ограничения не затрагивают вышеупомянутые шифры, соответственно согласование должно проходить, а оно не проходит.



    • Изменено Pavel Belyj 22 ноября 2016 г. 16:43
    22 ноября 2016 г. 16:42
  • а у вас какой CU?

    В CU2 по умолчанию теперь все сертификаты SHA2, попробуйте обновиться и попробовать еще раз.

    Вы этим замечанием навели нас на мысль)))

    Мы проверили привязку сертификата к коннекторам получения почты (Get-ReceiveConnector -Identity "EXCH" | fl *CertificateName*) и проверили в нем доступные алгоритмы криптографического хеширования. И все стало ясно, администратор ответственный за настройку безопасного соединения, сконфигурировал работу коннекторов получения почты на работу с полученным, проверенным сертификатом, который использует только алгоритм криптографического хеширования SHA256, поэтому вышеупомянутые шифры никак не могли быть согласованы нашими почтовыми серверами.

    • Предложено в качестве ответа Mikhail SartaevMVP 23 ноября 2016 г. 8:44
    • Помечено в качестве ответа Pavel Belyj 23 ноября 2016 г. 8:47
    22 ноября 2016 г. 19:57