Existe alguma razão pela qual o TLS 1.1 e 1.2 está desabilitado no Windows Server 2008 R2?

Question

O Windows Server 2008 R2 parece suportar o TLS 1.1 e 1.2, mas eles estão desabilitados por padrão.

Por que eles estão desabilitados por padrão?

Eles têm alguma desvantagem?

    

Answer 1

O Server 2008 R2 / Windows 7 apresentou o suporte a TLS 1.1 e TLS 1.2 para Windows e foi lançado antes dos ataques que tornaram o TLS 1.0 vulnerável, por isso provavelmente é apenas uma questão de TLS 1.0 ser o padrão porque era o mais amplamente versão TLS usada no momento em que o Server 2008 R2 foi lançado (julho de 2009).

Não tem certeza de como você saberia com certeza ou descobrir "por que" uma decisão de design foi feita, mas considerando que o Windows 7 e o Server 2008 R2 introduziram o recurso à família Windows e o Windows Server 2012 usa o TLS 1.2 por Por padrão, parece sugerir que era uma questão de "como as coisas eram feitas" na época. O TLS 1.0 ainda era "bom o suficiente", então era o padrão, mas o TLS 1.1 e o 1.2 eram suportados para suporte antecipado e operacionalidade avançada.

Este blog da technet de um funcionário da Microsoft recomenda ativar as versões mais recentes do TLS e também observa que (a partir de outubro de 2011):

Among web servers again, IIS 7.5 is the only which supports TLS 1.1 and TLS 1.2. As of now Apache doesn’t support these protocols as OPENSSL doesn’t include support for them. Hopefully, they’ll catch up to the industries new standards.

Isso apoia ainda mais a ideia de que as versões mais recentes do TLS não eram habilitadas por padrão no Server 2008 R2 pelo simples motivo de serem mais recentes e não amplamente suportadas ou usadas no momento - o Apache e o OpenSSL nem sequer suportá-los ainda, muito menos usá-los como padrão.

Detalhes sobre como ativar e desativar as várias versões de SSL / TLS podem ser encontrados no artigo número 245030 da Microsoft KB, intitulado How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll . Obviamente, as chaves Client controlam o Internet Explorer e as chaves Server cobrem o IIS.

    

Answer 2

Eu estava me perguntando isso sozinho ... talvez apenas devido a problemas de compatibilidade conhecidos no momento ... Eu encontrei esta entrada de blog do MSDN (de 24-Mar-2011):

link

Ele fala sobre alguns servidores da Web "mal-comportados" na maneira como respondem a solicitações de protocolo não suportadas, o que fez com que o cliente não recorresse a um protocolo suportado, com o resultado final sendo incapazes de acessar o site. ).

Citando parte da entrada do blog aqui:

The server isn’t supposed to behave this way—it’s instead expected to simply reply using the latest HTTPS protocol version it supports (e.g. "3.1” aka TLS 1.0). Now, had the server gracefully closed the connection at this point, it would be okay-- code in WinINET would fallback and retry the connection offering only TLS 1.0. WinINET includes code such that TLS1.1 & 1.2 fallback to TLS1.0, then fallback to SSL3 (if enabled) then SSL2 (if enabled). The downside to fallback is performance—the extra roundtrips required for the new lower-versioned handshake will usually result in a penalty amounting to tens or hundreds of milliseconds.

However, this server used a TCP/IP RST to abort the connection, which disables the fallback code in WinINET and causes the entire connection sequence to be abandoned, leaving the user with the “Internet Explorer cannot display the webpage” error message.