Таким образом, нам необходимо использовать Application Request Routing 3.0 для безопасного обратного прокси HTTPS-запросов, отправляемых на веб-сервер, на один и тот же URL-адрес на сервере приложений, где оба сервера работают под управлением Windows Server 2008 R2. Веб-серверу разрешено поддерживать входящие и исходящие соединения TLS 1.0 и TLS 1.2, но серверу приложений разрешено поддерживать только TLS 1.2 для входящих соединений (исходящий TLS 1.0 разрешен, но, вероятно, не имеет отношения к этому вопросу).
[Браузер] --TLS 1.0 / 1.2 -> [Веб-сервер + ARR] --TLS 1.2 -> [Сервер приложений]
Я настроил параметры реестра SCHANNEL на сервере приложений, как показано ниже («HKEY_LOCAL_MACHINE» заменено на «HKLM» по причинам форматирования). Веб-сервер настроен аналогично, но с включенными клиентскими и серверными соединениями TLS 1.0. После изменения реестра серверы были перезагружены.
[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"Enabled"=dword:00000000
[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]
"DisabledByDefault"=dword:00000001
[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
"Enabled"=dword:00000000
[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000000
[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000
[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000
[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
По большей части настройки SCHANNEL работают, как ожидалось, но ARR будет предлагать только TLS 1.0 в сообщении Client Hello при подтверждении связи SSL с сервером приложений, как это наблюдается с Wireshark и NetMon. Затем соединение разрывается, потому что сервер приложений не может продолжить рукопожатие, и ARR возвращает браузеру ошибку Bad Gateway. Выполнение запроса браузера (IE 11) непосредственно с веб-сервера на сервер приложений приводит к успешному рукопожатию TLS 1.2.
Отключение клиентских подключений TLS 1.0 с веб-сервера приводит к тому, что веб-сервер даже не отправляет клиентское приветствие (и в браузер возвращается ответ «Плохой шлюз» по несколько другой причине).
Включение подключений к серверу TLS 1.0 на сервере приложений приводит к успешному рукопожатию TLS 1.0, и ARR проксирует запрос, как и ожидалось.
На серверах, которые я пытаюсь использовать, были установлены все обновления непосредственно из Центра обновления Windows.
Либо использование фермы серверов IIS, либо жесткое кодирование имени сервера приложений в правилах перезаписи не имеет никакого значения.
Такая же конфигурация отлично работает на Windows Server 2012, и я могу воспроизвести симптомы на виртуальных машинах Server 2008 R2, которые я создал в Azure.
Я действительно хотел бы знать, возможно ли это на самом деле с ARR и Windows Server 2008 R2, и если да, то какие дополнительные шаги настройки или исправления необходимы. Хотя предложения других технологий могут оказаться полезными, на данный момент мы ограничены довольно негибкими требованиями.
Это изменит настройки ОС по умолчанию таким образом, чтобы разрешить все версии TLS (или даже SSL, если вы выберете). Я тестировал это на ARR Windows 2008 R2. Патч Windows Easy Fix
ОБНОВИТЬ С момента отправки этого ответа корпорация Майкрософт выпустила исправление и связанные с ним обходные действия. Пожалуйста, смотрите новые ответы и комментарии для подробностей.
Оказывается, нет, это невозможно.
В следующем ответе службы поддержки разработчиков Microsoft IIS / ASP.NET поясняются технические детали.
В ходе дальнейшего исследования мы обнаружили, что использование Windows Server 2008 r2 и ARR использует WinHTTP для выполнения исходящего запроса и, таким образом, привязано к протоколам по умолчанию для ОС. (SSL3 и TLS 1.0) Краткий ответ - ARR не поддерживает WinHttpSetOption с флагом WINHTTP_OPTION_SECURE_PROTOCOLS для передачи значения WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_2
WinHttp! Internet_Session_Handle_Object загружает значение dwSecureProtocols непосредственно из% SDXROOT% \ net \ winhttp \ inc \ defaults.h Windows Server 2008 r2 поддерживает только SSL3 и TLS 1.0. IIS можно настроить для использования TLS 1.2, однако ARR привязан к настройкам ОС по умолчанию, и независимо от того, как он настроен, всегда будет использовать SSL 3 или TLS 1.0. Пока не будут изменены параметры ОС по умолчанию.
Да, это возможно.
Я развернул ключи реестра через GPO на все мои Windows 7 2008 r2
Приведенный выше ответ службы поддержки разработчиков Microsoft IIS / ASP.NET неверен. Пока не могу комментировать из-за репутации.
Это действительно работает. Подтверждено на ARR 2008 R2 sp1 с обновлением. Перед исходящим ключом reg ARR (который использует winhttp) будет TLS 1.0. После ключа reg (я использовал A80 для включения TLS 1.0-1.2) ARR использует TLS 1.2 для исходящего.