Windows Server 2008 R2, похоже, поддерживает TLS 1.1 и 1.2, но по умолчанию они отключены.
Почему они отключены по умолчанию?
Есть ли у них недостатки?
Server 2008 R2 / Windows 7 представила поддержку TLS 1.1 и TLS 1.2 для Windows и была выпущена до атак, сделавших TLS 1.0 уязвимым, так что, вероятно, дело в том, что TLS 1.0 используется по умолчанию, потому что это была наиболее широко используемая версия TLS. на момент выпуска Server 2008 R2 (июль 2009 г.).
Не уверен, как вы узнаете наверняка или выясните, «почему» было принято дизайнерское решение, но, учитывая, что Windows 7 и Server 2008 R2 представили эту функцию в семействе Windows, а Windows Server 2012 по умолчанию использует TLS 1.2, она Казалось бы, можно предположить, что это было вопросом «того, как все было сделано» в то время. TLS 1.0 по-прежнему «достаточно хорош», поэтому он используется по умолчанию, но TLS 1.1 и 1.2 поддерживаются для прямой поддержки и прямой работы.
Этот технический блог от сотрудника Microsoft рекомендует включить более новые версии TLS, а также отмечает, что (по состоянию на октябрь 2011 г.):
Опять же, среди веб-серверов IIS 7.5 - единственный, который поддерживает TLS 1.1 и TLS 1.2. На данный момент Apache не поддерживает эти протоколы, поскольку OPENSSL не поддерживает их. Надеюсь, они будут соответствовать новым отраслевым стандартам.
Это также подтверждает идею о том, что более новые версии TLS не были включены по умолчанию в Server 2008 R2 по той простой причине, что они были более новыми и широко не поддерживались или не использовались в то время - Apache и OpenSSL даже не служба поддержки их пока нет, не говоря уже об использовании их по умолчанию.
Подробную информацию о том, как именно включать и отключать различные версии SSL / TLS, можно найти в Статья Microsoft KB номер 245030, озаглавленная How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll. Очевидно, что Client клавиши управляют Internet Explorer, а Server Клавиши крышка IIS.
Мне самому это было интересно ... может быть, просто из-за известных в то время проблем с совместимостью ... Я нашел эту запись в блоге MSDN (от 24 марта 2011 г.):
В нем говорится о том, что некоторые веб-серверы «плохо себя ведут» в том, как они реагируют на запросы неподдерживаемого протокола, что затем заставляет клиента не переходить на поддерживаемый протокол, в результате чего пользователи не могут получить доступ к веб-сайтам.
Цитирую часть этой записи в блоге здесь:
Сервер не должен вести себя подобным образом - вместо этого ожидается, что он просто ответит, используя последнюю версию протокола HTTPS, которую он поддерживает (например, «3.1» или TLS 1.0). Теперь, если бы сервер корректно закрыл соединение на этом этапе, он бы все в порядке - код в WinINET откатится и попытается снова установить соединение, предлагая только TLS 1.0. WinINET включает такой код, что TLS1.1 и 1.2 откатываются к TLS1.0, затем отключаются к SSL3 (если включен), затем SSL2 (если включен). Обратной стороной отказа является производительность - дополнительные циклы обработки, необходимые для нового рукопожатия с более низкой версией, обычно приводят к штрафу в десятки или сотни миллисекунд.
Однако этот сервер использовал TCP / IP RST для прерывания соединения, что отключает резервный код в WinINET и приводит к отказу от всей последовательности подключения, оставляя пользователю сообщение об ошибке «Internet Explorer не может отобразить веб-страницу».