O Server 2008 R2/Windows 7 introduziu o suporte TLS 1.1 e TLS 1.2 para Windows e foi lançado antes dos ataques que tornaram o TLS 1.0 vulnerável, portanto, provavelmente é apenas uma questão de TLS 1.0 ser o padrão porque era a versão TLS mais amplamente usada na época em que o Server 2008 R2 foi lançado (julho de 2009).
Não tenho certeza de como você saberia com certeza ou descobriria "por que" uma decisão de design foi tomada, mas como o Windows 7 e o Server 2008 R2 introduziram o recurso na família Windows e o Windows Server 2012 usa TLS 1.2 por padrão, parece sugerir que era uma questão de "como as coisas eram feitas" na época. TLS 1.0 ainda era "bom o suficiente", então era o padrão, mas TLS 1.1 e 1.2 eram suportados para suporte avançado e operação avançada.
Novamente entre os servidores da Web, o IIS 7.5 é o único que suporta TLS 1.1 e TLS 1.2. A partir de agora, o Apache não oferece suporte a esses protocolos, pois o OPENSSL não inclui suporte para eles. Esperançosamente, eles alcançarão os novos padrões da indústria.
Isso apóia ainda mais a ideia de que as versões mais recentes do TLS não foram habilitadas por padrão no Server 2008 R2 pela simples razão de que eram mais recentes e não eram amplamente suportadas ou usadas na época - Apache e OpenSSL nem as suportavam ainda, muito menos usá-los como padrão.
Eu mesmo estava me perguntando isso ... talvez apenas devido a problemas de compatibilidade conhecidos na época ... Encontrei esta entrada no blog do MSDN (de 24 de março de 2011):
Ele fala sobre alguns servidores da web "comportando-se mal" na maneira como respondem a solicitações de protocolo sem suporte, o que fez com que o cliente não voltasse para um protocolo com suporte, com o resultado final sendo que os usuários não conseguiam acessar o (s) site (s).
Citando parte dessa entrada do blog aqui:
O servidor não deve se comportar dessa maneira - em vez disso, espera-se que simplesmente responda usando a versão mais recente do protocolo HTTPS compatível (por exemplo, "3.1", também conhecido como TLS 1.0). ficaria bem-- o código no WinINET faria fallback e tentaria novamente a conexão oferecendo apenas TLS 1.0. O WinINET inclui código como TLS1.1 e 1.2 fallback para TLS1.0, depois fallback para SSL3 (se ativado) e SSL2 (se ativado). a desvantagem do fallback é o desempenho - as viagens de ida e volta extras necessárias para o novo handshake de versão inferior geralmente resultarão em uma penalidade de dezenas ou centenas de milissegundos.
No entanto, este servidor usou um TCP/IP RST para interromper a conexão, o que desabilita o código de fallback no WinINET e faz com que toda a sequência de conexão seja abandonada, deixando o usuário com a mensagem de erro “O Internet Explorer não pode exibir a página da Web”.
O Server 2008 R2/Windows 7 introduziu o suporte TLS 1.1 e TLS 1.2 para Windows e foi lançado antes dos ataques que tornaram o TLS 1.0 vulnerável, portanto, provavelmente é apenas uma questão de TLS 1.0 ser o padrão porque era a versão TLS mais amplamente usada na época em que o Server 2008 R2 foi lançado (julho de 2009).
Não tenho certeza de como você saberia com certeza ou descobriria "por que" uma decisão de design foi tomada, mas como o Windows 7 e o Server 2008 R2 introduziram o recurso na família Windows e o Windows Server 2012 usa TLS 1.2 por padrão, parece sugerir que era uma questão de "como as coisas eram feitas" na época. TLS 1.0 ainda era "bom o suficiente", então era o padrão, mas TLS 1.1 e 1.2 eram suportados para suporte avançado e operação avançada.
Este blog technet de um funcionário da Microsoft recomenda habilitar as versões mais recentes do TLS e também observa que (a partir de outubro de 2011):
Isso apóia ainda mais a ideia de que as versões mais recentes do TLS não foram habilitadas por padrão no Server 2008 R2 pela simples razão de que eram mais recentes e não eram amplamente suportadas ou usadas na época - Apache e OpenSSL nem as suportavam ainda, muito menos usá-los como padrão.
Detalhes sobre como habilitar e desabilitar 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, asClientchaves controlam o Internet Explorer e asServerchaves cobrem o IIS.Eu mesmo estava me perguntando isso ... talvez apenas devido a problemas de compatibilidade conhecidos na época ... Encontrei esta entrada no blog do MSDN (de 24 de março de 2011):
http://blogs.msdn.com/b/ieinternals/archive/2011/03/25/misbehaving-https-servers-impair-tls-1.1-and-tls-1.2.aspx
Ele fala sobre alguns servidores da web "comportando-se mal" na maneira como respondem a solicitações de protocolo sem suporte, o que fez com que o cliente não voltasse para um protocolo com suporte, com o resultado final sendo que os usuários não conseguiam acessar o (s) site (s).
Citando parte dessa entrada do blog aqui: