Сервер IIS 8.5 не принимает подключение TLS 1.0 от Windows Server 2003

(Если вам интересно, почему я пытаюсь включить комплекты шифров, которые устарели, то короткий ответ - это для тех немногих, кто действительно не может использовать что-то более новое, потому что они застряли на Windows Server 2003, ни мы, ни они могут делать с этим что угодно, и мы не хотим, чтобы предоставляемый им сервис перестал работать, если мы можем помочь.)

Я использовал IIS Crypto для включения ряда протоколов, шифров, хэшей, обменов ключами и наборов шифров ( здесь приведен полный список), которые должны охватывать все, что необходимо для нашего продукта для подключения к этому серверу через TLS 1.0 с учетом возможностей Schannel в Windows Server 2003. (Сервер был перезагружен, так как изменения были применены в IIS Crypto.)

Однако сервер отбрасывает соединение и документирует его с помощью следующих двух записей в журнале событий, опубликованных Schannel в журнале системных событий:

"Запрос на подключение TLS 1.0 был получен от удаленного клиентского приложения, но ни один из наборов шифров, поддерживаемых клиентским приложением, не поддерживается сервером. Запрос на подключение SSL не выполнен". - событие ID 36874

с последующим

"Неустранимое предупреждение было сгенерировано и отправлено на удаленную конечную точку. Это может привести к разрыву соединения. Протокол фатальной ошибки, определенный протоколом TLS, равен 40. Состояние ошибки Windows SChannel равно 1205." - событие ID 36888

Используя Wireshark на клиенте, я вижу, что он пытается согласовать следующие комплекты шифров:

            Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
            Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
            Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
            Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009)
            Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064)
            Cipher Suite: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x0062)
            Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
            Cipher Suite: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006)
            Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
            Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012)
            Cipher Suite: TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (0x0063)

из которых эти:

TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_3DES_EDE_CBC_SHA

включены в то, что я включил с IIS Crypto. И все же сервер не хочет трогать эти комплекты шифров и разрешать установление соединения. Вместо этого он просто разрывает соединение, о чем свидетельствует эта попытка подключения с использованием OpenSSL.

Почему IIS или Schannel не разрешают использовать эти наборы шифров, когда, насколько я могу судить, я настроил их оба для их использования независимо от настроек по умолчанию?

Источник

3 ответа

Решение

TL;DR: отказался и использовал Linux и Nginx.

Я так и не нашел ответ на то, чего не хватало. Помимо упомянутого сервера Windows Server 2012 R2, я настроил сервер Windows Server 2008 R2 и полностью обновил его и использовал IIS Crypto таким же образом, и мне кажется, что в каком-то обновлении был установлен какой-то переключатель уничтожения RC4. линия, которая не может быть деактивирована документированным способом, особенно потому, что другой сервер Windows Server 2012 R2, который не был отключен для установки исправлений, не делает то же самое.

Поскольку я не могу жить в страхе перед запуском Центра обновления Windows, мне пришлось прибегнуть к настройке сервера Ubuntu под управлением Nginx, обработке завершения TLS и обратному проксированию на сервер по обычному HTTP на сервере, который теперь мне не нужно было показывать. публично. Отсутствие у Microsoft исчерпывающей и точной документации и стремление кардинально изменить поведение в незначительных обновлениях демонстрируют презрение к своим клиентам и их предприятиям, и им было бы неплохо обратиться к своим конкурентам за уроками о том, как заботиться о безопасности своих клиентов, при этом все еще доверяя им со своим собственным мнением.

Источник

Я знаю, что это старо, но в случае, если кто-то хочет знать больше, в реестре также есть места для этого. Я думаю, что, возможно, TLS 1.0 это Enabled=0 или DisabledByDefault = 1?

SSL / TSL:

Расположение реестра: \HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Если в папке реестра Protocols есть ключи с вложенными ключами Client и Server, а в них есть DWORDS - DisabledByDefault и Enabled, то это то, что его настраивает. Состояние по умолчанию для Win 2012 (r1) было TLS1 было разрешено и разрешено по умолчанию. (Если нет, вы можете добавить их в)

(Обратите внимание, что Сервер для входящих подключений, а клиент для исходящих.)

Рекомендации:

шифры:

Расположение реестра: \HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers

Мы также использовали IIS Crypto, после многих исследований и выяснив, что все просто используют эту программу. (Это избавило нас от ограничения в 1023 символа в списке Cipher Suite в редакторе групповой политики.)

(Помимо: Win XP потеряет все соединения с HTTPS, если 3DES (тройной DES) будет отбракован)

Рекомендации:

Источник

Большинство организаций будут следовать рекомендациям по усилению безопасности IIS 8 здесь: https://benchmarks.cisecurity.org/tools2/iis/CIS_Microsoft_IIS_8_Benchmark_v1.0.0.pdf

Я бы посоветовал вам проверить следующие значения: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319 SchUseStrongCrypto

Включение Strong Crypto автоматически отключает поддержку RC4, и это не то, чего не касается инструмент IIS Crypto.

Источник
Другие вопросы по тегам