(Если вам интересно, почему я пытаюсь включить устаревшие комплекты шифров, краткий ответ заключается в том, что это для тех немногих людей, которые действительно не могут использовать что-либо новое, потому что они застряли на Windows Server 2003, ни мы, ни они могут что-то с этим поделать, и мы не хотим, чтобы предоставляемая им услуга перестала работать, если мы сможем ей помочь.)
я использовал IIS Crypto для включения ряда протоколов, шифров, хэшей, обмена ключами и наборов шифров (вот полный список), который должен включать в себя все, что необходимо нашему продукту для подключения к этому серверу через TLS 1.0, учитывая возможности Schannel в Windows Server 2003. (Сервер был перезагружен, так как изменения были применены в IIS Crypto.)
Однако сервер разрывает соединение и документирует его с помощью следующих двух записей журнала событий, размещенных Schannel в журнале системных событий:
«Запрос на соединение TLS 1.0 был получен от удаленного клиентского приложения, но ни один из наборов шифров, поддерживаемых клиентским приложением, не поддерживается сервером. Запрос на соединение SSL не выполнен». - идентификатор события 36874
с последующим
«Фатальное предупреждение было создано и отправлено на удаленную конечную точку. Это может привести к разрыву соединения. Код фатальной ошибки, определенный протоколом TLS, - 40. Состояние ошибки Windows SChannel - 1205.» - идентификатор события 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 не позволяют использовать эти наборы шифров, если, насколько я могу судить, я настроил их оба для использования независимо от значений по умолчанию?
Я знаю, что это устарело, но на случай, если кто-то захочет узнать больше, в реестре есть места для этого. Я думаю, что, возможно, TLS 1.0 включен = 0 или DisabledByDefault = 1?
Расположение в реестре: \ 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) будет отброшен)
Ссылки:
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 исчерпывающей и точной документации и желание кардинально изменить поведение в незначительных обновлениях свидетельствует о неуважении к их клиентам и их бизнесу, и им было бы хорошо, если бы у их конкурентов были уроки о том, как заботиться о безопасности своих клиентов, при этом доверяя им. по собственному усмотрению.
Большинство организаций будут следовать приведенным здесь рекомендациям по усилению защиты 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 этого не касается.