Isso alterará os padrões do SO de forma a permitir todas as versões do TLS (ou até mesmo SSL, se você escolher). Eu testei isso no ARR Windows 2008 R2. Patch de correção fácil do Windows
Em resumo, precisamos usar o Application Request Routing 3.0 para fazer com segurança as solicitações HTTPS de proxy reverso feitas em um servidor da Web, na mesma URL em um servidor de aplicativos, em que os dois servidores estejam executando o Windows Server 2008 R2. O servidor web tem permissão para suportar conexões de entrada e saída TLS 1.0 e TLS 1.2, mas o servidor de aplicativos só tem permissão para suportar TLS 1.2 para conexões de entrada (o TLS 1.0 de saída é permitido, mas provavelmente não é relevante para essa questão). >
[Navegador] --TLS 1.0 / 1.2 - > [Servidor Web + ARR] - TLS 1.2 - > [Servidor de aplicativos]
Eu configurei as configurações de registro SCHANNEL no servidor de aplicativos, conforme mostrado abaixo ("HKEY_LOCAL_MACHINE" substituído por "HKLM" por motivos de formatação). O servidor da Web é configurado de forma semelhante, mas também com conexões de cliente e servidor TLS 1.0 ativadas. Os servidores foram reinicializados após a alteração do registro.
[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
Na maioria das vezes, as configurações SCHANNEL parecem funcionar como esperado, mas o ARR oferecerá apenas o TLS 1.0 no Client Hello do handshake SSL com o servidor de aplicativos, conforme observado com o Wireshark e o NetMon. A conexão é descartada porque o servidor de aplicativos não pode continuar com o handshake e a ARR retorna um erro de gateway inválido para o navegador. Fazer um navegador (IE 11) solicitar diretamente do servidor da Web para o servidor de aplicativos resulta em um handshake de TLS 1.2 bem-sucedido.
A desativação das conexões do cliente TLS 1.0 a partir do servidor da web resulta no servidor da web sem nem mesmo enviar um Client Hello (e uma resposta de Bad Gateway retornada ao navegador, com um motivo ligeiramente diferente).
Ativar as conexões do servidor TLS 1.0 no servidor de aplicativos resulta em um handshake TLS 1.0 bem-sucedido e o ARR faz proxy da solicitação conforme o esperado.
Os servidores que estou tentando usar tiveram todas as atualizações instaladas diretamente do Windows Update.
Usar um farm de servidores do IIS ou codificar permanentemente o nome do servidor de aplicativos nas regras de reescrita não parece fazer diferença.
A mesma configuração funciona bem no Windows Server 2012 e eu sou capaz de reproduzir os sintomas nas VMs do Server 2008 R2 que eu criei no Azure.
O que eu realmente gostaria de saber é se isso é realmente possível com o ARR e o Windows Server 2008 R2 e, em caso afirmativo, quais etapas ou correções de configuração adicionais são necessárias. Embora sugestões de outras tecnologias possam ser úteis, estamos limitados por requisitos bastante inflexíveis neste momento.
Isso alterará os padrões do SO de forma a permitir todas as versões do TLS (ou até mesmo SSL, se você escolher). Eu testei isso no ARR Windows 2008 R2. Patch de correção fácil do Windows
Sim, isso é possível.
Eu implantei as chaves de registro via GPO em todo o meu Windows 7 2008 r2
A resposta acima do Microsoft IIS / ASP.NET Developer Support está incorreta. Eu não posso comentar ainda devido à reputação.
Isso funciona. Confirmado em ARR 2008 R2 sp1 com atualização. Antes de a chave ARR de saída (que usa o winhttp) é TLS 1.0 Depois da chave reg (usei A80 para ativar o TLS 1.0-1.2), a ARR usa o TLS 1.2 para saída.
UPDATE A Microsoft lançou um patch e etapas de solução de problemas associadas desde que essa resposta foi enviada. Por favor, veja respostas e comentários mais recentes para detalhes.
Acontece que a resposta é não, não é possível.
A seguinte resposta do Microsoft IIS / ASP.NET Developer Support esclarece os detalhes técnicos.
Upon further investigation we have found that the use of Windows Server 2008 r2 and ARR uses WinHTTP to make the outbound request and is thereby bound to the default protocols for the OS. (SSL3 and TLS 1.0) Short Answer - ARR doesn't support WinHttpSetOption with WINHTTP_OPTION_SECURE_PROTOCOLS flag to pass WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_2 value
WinHttp!Internet_Session_Handle_Object loads the dwSecureProtocols value directly from %SDXROOT%\net\winhttp\inc\defaults.h Windows Server 2008 r2 only supports SSL3 and TLS 1.0. IIS can be configured to use TLS 1.2, however ARR is bound to the OS defaults, and no matter how configured will always use either SSL 3 or TLS 1.0. Until the OS defaults are changed.