Solucionar o problema do TLS 1.0, 2ª edição

Este documento apresenta as diretrizes mais recentes sobre como identificar e remover rapidamente as dependências do protocolo TLS versão 1.0 no software criado com base nos sistemas operacionais da Microsoft, mostrando, em seguida, os detalhes sobre alterações de produtos e novos recursos fornecidos pela Microsoft para proteger os próprios clientes e os serviços online. Ele se destina a ser usado como um ponto de partida para a criação de um plano de migração para um ambiente de rede do TLS 1.2 e posterior. Embora as soluções abordadas aqui possam ser transferidas e ajudar a remover o uso do TLS 1.0 em sistemas operacionais não Microsoft ou em bibliotecas de criptografia, elas não são o foco deste documento.

O TLS 1.0 é um protocolo de segurança definido pela primeira vez em 1999 para estabelecer canais de criptografia em redes de computadores. A Microsoft vem dando suporte a esse protocolo desde o Windows XP/Server 2003. Embora não seja mais o protocolo de segurança padrão usado pelos sistemas operacionais modernos, o TLS 1.0 ainda tem suporte para compatibilidade com versões anteriores. Os requisitos regulamentares em evolução, bem como novas vulnerabilidades de segurança no TLS 1.0 fornecem às empresas o incentivo para desabilitar o TLS 1.0 por completo.

A Microsoft recomenda que os clientes antecipem esse problema removendo as dependências do TLS 1.0 nos ambientes e desabilitando o TLS 1.0 no nível do sistema operacional sempre que possível. Dada a duração de suporte ao TLS 1.0 pelo setor de software, é altamente recomendável que qualquer plano de substituição do TLS 1.0 inclua o seguinte:

• Análise de código para encontrar/corrigir as instâncias embutidas em código do TLS 1.0 ou de protocolos de segurança mais antigos.

• Verificação de ponto de extremidade de rede e análise de tráfego para identificar os sistemas operacionais que usam o TLS 1.0 ou protocolos mais antigos.

• Teste de regressão completo por toda a pilha de aplicativos com o TLS 1.0 desabilitado.

• Migração de sistemas operacionais herdados e bibliotecas/estruturas de desenvolvimento para versões com capacidade de negociar o TLS 1.2 por padrão.

• Teste de compatibilidade em sistemas operacionais usados pela sua empresa para identificar problemas de suporte do TLS 1.2.

• Coordenação com os próprios clientes e parceiros de negócios para notificá-los de sua decisão de substituir o TLS 1.0.

• Entendimento de quais clientes talvez não possam mais se conectar aos seus servidores depois que o TLS 1.0 for desabilitado.

A meta deste documento é fornecer recomendações que possam ajudar a remover os obstáculos técnicos para a desabilitação do TLS 1.0 e, ao mesmo tempo, aumentar a visibilidade do impacto dessa alteração para os próprios clientes. A conclusão dessas investigações pode ajudar a reduzir o impacto nos negócios da próxima vulnerabilidade de segurança no TLS 1.0. Para fins deste documento, as referências à substituição do TLS 1.0 também incluem o TLS 1.1.

Os desenvolvedores de software corporativo têm uma necessidade estratégica de adotar soluções mais ágeis e seguras para o futuro (também conhecidas como agilidade criptográfica) para lidar com os futuros comprometimentos de protocolo de segurança. Embora este documento proponha soluções ágeis para a eliminação de codificações do TLS, as soluções mais amplas de agilidade criptográfica estão fora do escopo deste documento.

O estado atual da implementação do TLS 1.0 da Microsoft

A implementação do TLS 1.0 da Microsoft é isenta de vulnerabilidades de segurança conhecidas. Devido ao potencial de futuros ataques de downgrade de protocolo e outras vulnerabilidades do TLS 1.0 não específicas à implementação da Microsoft, é recomendável que as dependências em todos os protocolos de segurança anteriores ao TLS 1.2 sejam removidas sempre que possível (TLS 1.1/1.0/SSLv3/SSLv2).

No planejamento dessa migração para o TLS 1.2 e posterior, os desenvolvedores e os administradores do sistema devem estar cientes do potencial de codificação da versão de protocolo em aplicativos desenvolvidos por funcionários e parceiros. Codificação aqui significa que a versão do TLS foi corrigida para uma versão desatualizada e menos segura do que as versões mais recentes. As versões do TLS mais recentes do que a versão embutida em código não podem ser usadas sem modificar o programa em questão. Essa classe de problema não pode ser resolvida sem alterações no código-fonte e implantação de atualização de software. A codificação da versão do protocolo era comum no passado para fins de teste e suporte, pois muitos navegadores e sistemas operacionais diferentes tinham níveis variados de suporte ao TLS.

Versões compatíveis do TLS no Windows

Muitos sistemas operacionais têm padrões de versão do TLS desatualizados ou limites máximos de suporte que precisam ser levados em conta.

Figura 1: suporte do protocolo de segurança pela versão do sistema operacional

O Windows Server 2019 GS Edition é compatível com Microsoft SDL, TLS 1.2 apenas com um conjunto restrito de conjuntos de criptografia.

A edição de 2022 do Windows Server está em conformidade com Microsoft SDL, TLS 1.2 e TLS 1.3 apenas com um conjunto restrito de conjuntos de criptografia.

*O TLS 1.1/1.2 pode ser habilitado no Windows Server 2008 por meio deste pacote opcional do Windows Update.

Para obter mais informações sobre a substituição do TLS 1.0/1.1 no IE/Edge, confira Modernizar as conexões TLS no Microsoft Edge e no Internet Explorer 11, Compatibilidade do site – as próximas alterações de significativas no Microsoft Edge e Desabilitar o TLS/1.0 e o TLS/1.1 no novo navegador Edge

Uma forma rápida de determinar qual versão do TLS será solicitada por vários clientes ao se conectar aos seus serviços online é consultando a simulação de handshake do Qualys SSL Labs como referência. Essa simulação abrange combinações de sistema operacional cliente/navegador de vários fabricantes. Confira o Apêndice A ao final deste documento para obter um exemplo detalhado que mostra as versões do protocolo TLS negociadas por várias combinações simuladas de sistema operacional cliente/navegador ao se conectar a www.microsoft.com.

Se isso ainda não foi concluído, é altamente recomendável executar um inventário dos sistemas operacionais usados pela sua empresa, pelos clientes e pelos parceiros (os últimos dois por meio de contato/comunicação ou, pelo menos, a coleção de cadeias de caracteres de Agente-Usuário HTTP). Esse inventário pode ser ainda mais complementado pela análise de tráfego na borda da rede corporativa. Em uma situação como essa, a análise de tráfego produzirá as versões do TLS negociadas com êxito por clientes/parceiros que se conectam aos seus serviços, mas o tráfego em si permanecerá criptografado.

Aprimoramentos de engenharia da Microsoft para eliminar dependências do TLS 1.0

Desde a versão v1 deste documento, a Microsoft forneceu uma série de atualizações de software e novos recursos em suporte à substituição do TLS 1.0. Estão incluídos:

• Log personalizado do IIS para correlacionar a cadeia de caracteres do agente do usuário/IP do cliente, o URI de serviço, a versão do protocolo TLS e o pacote de criptografia.

  • Com esse log, os administradores podem finalmente quantificar a exposição dos clientes ao TLS fraco.

• Secure Score: para ajudar os administradores de locatários do Office 365 a identificar o próprio uso do TLS fraco, o portal do Secure Score foi criado para compartilhar essas informações já que o TLS 1.0 saiu do suporte no Office 365 em outubro de 2018.

  • Esse portal fornece aos administradores de locatário do Office 365 as informações importantes de que precisam para entrar em contato com os próprios clientes que podem não estar cientes das próprias dependências do TLS 1.0.

  • Visite https://securescore.microsoft.com/ para saber mais.

• Atualizações do .NET Framework para eliminar a codificação no nível do aplicativo e impedir dependências do TLS 1.0 herdadas pela estrutura.

• Foram lançadas diretrizes para desenvolvedores e atualizações de software para ajudar os clientes a identificar e eliminar dependências do .Net em TLS fraco: Melhores práticas de TLS (Transport Layer Security) com o .NET Framework

  • Observação: todos os aplicativos direcionados ao .NET 4.5 ou inferior provavelmente precisarão ser modificados para dar suporte ao TLS 1.2.

• Foi feito o backport do TLS 1.2 para o Windows Server 2008 SP2 e o XP POSReady 2009, a fim de ajudar os clientes com obrigações herdadas.

• Outros comunicados serão feitos no início de 2019 e divulgados nas atualizações seguintes deste documento.

Encontrar e corrigir as dependências do TLS 1.0 no código

Para os produtos que usam as bibliotecas de criptografia e os protocolos de segurança fornecidos pelo sistema operacional Windows, as seguintes etapas deverão ajudar a identificar qualquer uso do TLS 1.0 embutido em código nos seus aplicativos:

1. Identifique todas as instâncias de AcquireCredentialsHandle(). Isso ajuda os revisores a se aproximarem dos blocos de código nos quais o TLS pode estar embutido sem código.

2. Examine todas as instâncias das estruturas SecPkgContext_SupportedProtocols e SecPkgContext_ConnectionInfo em busca do TLS integrado em código.

3. No código nativo, defina as atribuições diferentes de zero de grbitEnabledProtocols como zero. Isso permite que o sistema operacional use a versão padrão do TLS.

4. Desabilite o Modo FIPS se ele estiver habilitado devido ao potencial de conflito com as configurações necessárias para desabilitar explicitamente o TLS 1.0/1.1 neste documento. Confira o Apêndice B para obter mais informações.

5. Atualize e recompile todos os aplicativos que usam o WinHTTP hospedado no Server 2012 ou mais antigo.

   1. Aplicativos gerenciados – recompile-os e redirecione-os com relação à última versão do .NET Framework

   2. Os aplicativos precisam adicionar o código para dar suporte ao TLS 1.2 por meio de WinHttpSetOption

6. Para abranger todas as bases, examine o código-fonte e os arquivos de configuração do serviço online para verificar se os padrões abaixo são correspondentes aos valores de tipo enumerado comumente usados na codificação do TLS:

   1. SecurityProtocolType

   2. SSLv2, SSLv23, SSLv3, TLS1, TLS 10, TLS11

   3. WINHTTP_FLAG_SECURE_PROTOCOL_

   4. SP_PROT_

   5. NSStreamSocketSecurityLevel

   6. PROTOCOL_SSL ou PROTOCOL_TLS

A solução recomendada em todos os casos acima é remover a seleção de versão do protocolo embutida em código e adiá-la para o padrão do sistema operacional. Se você estiver usando o DevSkim, clique aqui para ver as regras que abrangem as verificações acima que você poderá usar com o próprio código.

Atualizar scripts do Windows PowerShell ou as configurações do Registro relacionadas

O Windows PowerShell usa o .NET Framework 4.5, que não inclui o TLS 1.2 como um protocolo disponível. Para resolver isso, duas soluções estão disponíveis:

1. Modifique o script em questão para incluir o seguinte:

   [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;
   

2. Adicione uma chave do Registro de todo o sistema (por exemplo, por meio da política de grupo) a qualquer computador que precise realizar conexões TLS 1.2 em um aplicativo .NET. Isso fará o .NET usar as versões do TLS "Padrão do Sistema", o que adiciona o TLS 1.2 como um protocolo disponível, E permitirá que os scripts usem versões futuras do TLS quando o sistema operacional der suporte a elas. (por exemplo, TLS 1.3)

   reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:64

   reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:32

As soluções (1) e (2) são mutuamente exclusivas, o que significa que elas não precisam ser implementadas juntas.

Recompilar/redirecionar aplicativos gerenciados usando a última versão do .NET Framework

Os aplicativos que usam versões do .NET Framework anteriores à 4.7 podem ter limitações que limitem efetivamente o suporte ao TLS 1.0, independentemente dos padrões subjacentes do sistema operacional. Para mais informações, confira o diagrama abaixo e Melhores práticas do TLS (Transport Layer Security) com o .NET Framework.

SystemDefaultTLSVersion tem precedência sobre o direcionamento no nível do aplicativo das versões do TLS. A melhor prática recomendada é sempre o adiamento para a versão padrão do TLS do sistema operacional. Essa também é a única solução criptográfica ágil que permite que os seus aplicativos aproveitem o suporte futuro do TLS 1.3.

Se você estiver direcionando versões mais antigas do .NET Framework, como 4.5.2 ou 3.5, então seu aplicativo usará os protocolos mais antigos e não recomendados por padrão, como SSL 3.0 ou TLS 1.0. É altamente recomendável que você faça o upgrade para versões mais recentes do .NET Framework, como .NET Framework 4,6 ou defina as chaves do Registro apropriadas para 'UseStrongCrypto'.

Testar com o TLS 1.2 e posterior

Seguindo as correções recomendadas na seção acima, os produtos devem passar por um teste de regressão para verificar se há erros de negociação de protocolo e compatibilidade com outros sistemas operacionais na sua empresa.

• O problema mais comum neste teste de regressão será uma falha de negociação do TLS devido a uma tentativa de conexão de cliente em um sistema operacional ou de um navegador que não dá suporte ao TLS 1.2.

  • Por exemplo, um cliente do Vista não negociará o TLS com um servidor configurado para o TLS 1.2 e posterior, pois a versão máxima do TLS com suporte do Vista é 1.0. Esse cliente deverá ser atualizado ou desativado em um ambiente do TLS 1.2 ou posterior.

• Os produtos que usam a autenticação TLS Mútuo baseada em certificado podem exigir testes de regressão adicionais, pois o código de seleção de certificado associado ao TLS 1.0 era menos expressivo do que para o TLS 1.2.

  • Se um produto negociar o MTLS com um certificado em uma localização não padrão (fora dos repositórios de certificados nomeados padrão no Windows), esse código poderá precisar de uma atualização para verificar se o certificado foi adquirido corretamente.

• As interdependências de serviço devem ser examinadas para verificar se há pontos problemáticos.

  • Todos os serviços que interoperam com serviços de terceiros devem realizar testes de interoperabilidade adicionais com eles.

  • Os aplicativos ou sistemas operacionais de servidor em uso não Windows exigem uma investigação/confirmação de que eles podem dar suporte ao TLS 1.2. Um exame é a maneira mais fácil de determinar isso.

Um simples blueprint para testar essas alterações em um serviço online consiste no seguinte:

1. Realizar um exame dos sistemas de ambiente de produção para identificar os sistemas operacionais que não dão suporte ao TLS 1.2.

2. Examinar o código-fonte e os arquivos de configuração do serviço online para verificar se há um TLS embutido em código, conforme descrito em "Encontrar e corrigir dependências do TLS 1.0 no código"

3. Atualizar/recompilar aplicativos conforme necessário:

   1. Aplicativos gerenciados

      1. Recompilar com relação à última versão do .NET Framework.

      2. Verificar se o uso da enumeração SSLProtocols está definido como SSLProtocols.None para usar as configurações padrão do sistema operacional.

   2. Aplicativos WinHTTP – recompilar com WinHttpSetOption para dar suporte ao TLS 1.2

4. Iniciar o teste em um ambiente de pré-produção ou de preparo com todos os protocolos de segurança anteriores ao TLS 1.2 desabilitados por meio do Registro.

5. Corrigir todas as instâncias restantes da codificação do TLS conforme elas são encontradas no teste. Reimplantar o software e realizar uma nova execução de teste de regressão.

Notificar os parceiros de seus planos de substituição do TLS 1.0

Depois que você resolver a codificação do TLS e concluir as atualizações do sistema operacional/da estrutura de desenvolvimento, se optar por substituir o TLS 1.0, precisará coordenar com clientes e parceiros:

• O contato antecipado com o parceiro/cliente é essencial para uma distribuição de substituição bem-sucedida do TLS 1.0. No mínimo, isso deve consistir em postagens no blog, white papers ou outro conteúdo da Web.

• Cada um dos parceiros precisa avaliar a própria preparação para o TLS 1.2 por meio das iniciativas de teste de regressão/exame de código/sistema operacional descritas nas seções acima.

Conclusão

A remoção de dependências do TLS 1.0 é um problema complexo para ser conduzido de ponta a ponta. Os parceiros da Microsoft e do setor estão tomando medidas sobre essa questão hoje mesmo, a fim de verificar se toda a pilha de produtos é mais segura por padrão, de nossos componentes do sistema operacional e estruturas de desenvolvimento aos aplicativos/serviços criados com base neles. Seguir as recomendações feitas neste documento ajudará a sua empresa a trilhar o caminho certo e saber quais desafios devem ser esperados. Isso também ajudará seus clientes a ficarem mais preparados para a transição.

Apêndice A: simulação de handshake para vários clientes que se conectam a www.microsoft.com; cortesia de SSLLabs.com

Apêndice B: substituição do TLS 1.0/1.1 mantendo o Modo FIPS

Siga as etapas abaixo se a rede exigir o Modo FIPS; porém, o ideal é também substituir o TLS 1.0/1.1:

1. Configure as versões do TLS por meio do Registro, definindo "Habilitado" como zero para as versões indesejadas do TLS.

2. Desabilite a Curva 25519 (somente Server 2016) por meio da Política de Grupo.

3. Desabilite os pacotes de criptografia que usam algoritmos não permitidos pela publicação relevante do FIPS. Para o Server 2016 (supondo que as configurações padrão estejam em vigor), isso significa desabilitar as criptografias RC4, PSK e nula.

Colaboradores/agradecimentos a

Mark Cartwright
Bryan Sullivan
Patrick Jungles
Michael Scovetta
Tony Rice
David LeBlanc
Mortimer Cook
Daniel Sommerfeld
Andrei Popov
Michiko Short
Justin Burke
Gov Maharaj
Brad Turner
Sean Stevenson