Configurações do Registro do protocolo TLS

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows 10 e versões anteriores, conforme observado.

Este artigo explica as informações de configuração de registro com suporte para a implementação Windows do protocolo TLS (Transport Layer Security) e do protocolo SSL (Secure Sockets Layer) por meio do Provedor de Suporte de Segurança Schannel (SSP). As subchaves e as entradas do Registro abordadas neste tópico ajudam a administrar e solucionar problemas do Schannel SSP, especificamente os protocolos TLS e SSL.

Cuidado

Essas informações são fornecidas como uma referência a ser usada quando você estiver solucionando problemas ou verificando se as configurações necessárias estão aplicadas. É recomendável não editar diretamente o Registro, a menos que não haja outra alternativa. Modificações no Registro não são validadas pelo editor de Registro nem pelo sistema operacional Windows antes de serem aplicadas. Como resultado, valores incorretos podem ser armazenados, e isso pode resultar em erros irrecuperáveis no sistema. Quando possível, em vez de editar o registro diretamente, use Política de Grupo ou outras ferramentas de Windows, como o Console de Gerenciamento da Microsoft (MMC). Se você deve editar o Registro, tenha muito cuidado.

CertificateMappingMethods

Essa entrada não existe no Registro por padrão. O valor padrão é que todos os quatro métodos de mapeamento de certificado listados abaixo têm suporte.

Quando um aplicativo para servidores requer autenticação de cliente, o Schannel automaticamente tenta mapear o certificado fornecido pelo computador cliente para uma conta de usuário. Você pode autenticar os usuários que se conectam com um certificado de cliente, criando mapeamentos que se relacionam com as informações de certificado de uma conta de usuário do Windows. Depois de criar e habilitar um mapeamento de certificado, sempre que um cliente apresentar um certificado, o aplicativo para servidores associará automaticamente esse usuário à conta de usuário do Windows apropriada.

Na maioria dos casos, um certificado é mapeado para uma conta de usuário em uma de duas maneiras:

  • Um único certificado é mapeado para uma única conta de usuário (mapeamento um a um).
  • Vários certificados são mapeados para várias contas de usuário (mapeamento muitos para um).

Por padrão, o provedor Schannel usará os seguintes quatro métodos de mapeamento de certificados, listados em ordem de preferência:

  1. Mapeamento de certificado Kerberos S4U(Service-for-User)
  2. Mapeamento de nome UPN
  3. Mapeamento um a um (também conhecido como mapeamento de assunto/emissor)
  4. Mapeamento muitos-para-um

Versões aplicáveis: conforme designado na lista Aplica-se à lista no início deste tópico.

Caminho do Registro: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Criptografias

As criptografias TLS/SSL devem ser controladas pela configuração da ordem do pacote de criptografia. Para obter detalhes, consulte Configurar a ordem do Pacote de Criptografia do TLS.

Para obter informações sobre a ordem de pacotes de criptografia padrão que são usados pelo Schannel SSP, consulte Cipher Suites no TLS/SSL (Schannel SSP).

CipherSuites

A configuração de pacotes de criptografia TLS/SSL deve ser feita usando a política de grupo, o MDM ou o PowerShell, consulte Configurar o Ordem do Pacote de Criptografia do TLS para obter detalhes.

Para obter informações sobre a ordem de pacotes de criptografia padrão que são usados pelo Schannel SSP, consulte Cipher Suites no TLS/SSL (Schannel SSP).

ClientCacheTime

Essa entrada controla a quantidade de tempo que o sistema operacional leva em milissegundos para finalizar entradas de cache do lado do cliente. Um valor 0 desativa o cache de conexão segura. Essa entrada não existe no Registro por padrão.

Na primeira vez que um cliente se conecta a um servidor por meio do SSP Schannel, um handshake de TLS/SSL completo é executado. Quando isso é concluído, o segredo mestre, o conjunto de criptografias e os certificados são armazenados no cache da sessão, no respectivo cliente e servidor.

A partir do Windows Server 2008 e Windows Vista, o tempo de cache do cliente padrão é de 10 horas.

Caminho do Registro: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

EnableOcspStaplingForSni

A stapling do Protocolo de Status de Certificado Online (OCSP) permite que um servidor Web, como Serviços de Informações da Internet (IIS), forneça o status de revogação atual de um certificado de servidor quando ele envia o certificado do servidor para um cliente durante o handshake do TLS. Esse recurso reduz a carga em servidores OCSP porque o servidor Web pode armazenar em cache o status OCSP atual do certificado do servidor e enviá-lo para vários clientes Web. Sem esse recurso, cada cliente Web tentaria recuperar o status OCSP atual do certificado do servidor do servidor OCSP. Isso geraria uma carga alta nesse servidor OCSP.

Além do IIS, os serviços Web em http.sys também podem se beneficiar dessa configuração, incluindo Serviços de Federação do Active Directory (AD FS) (AD FS) e WAP (Proxy de Aplicativo Web).

Por padrão, o suporte ao OCSP está habilitado para sites do IIS que têm uma associação SSL/TLS (segurança simples). No entanto, esse suporte não será habilitado por padrão se o site do IIS estiver usando ambos os tipos de associações SSL/TLS a seguir:

  • Exigir indicação de nome do servidor
  • Usar repositório de certificados centralizados

Nesse caso, a resposta hello do servidor durante o handshake do TLS não incluirá um status grampeado OCSP por padrão. Esse comportamento melhora o desempenho: a implementação de stapling do Windows OCSP é dimensionada para centenas de certificados de servidor. Como o SNI e o CCS permitem que o IIS seja dimensionado para milhares de sites que potencialmente têm milhares de certificados de servidor, definir esse comportamento para ser habilitado por padrão pode causar problemas de desempenho.

Versões aplicáveis: todas as versões que começam com Windows Server 2012 e Windows 8.

Caminho do Registro: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]

Adicione a seguinte chave:

"EnableOcspStaplingForSni"=dword:00000001

Para desabilitar, defina o valor DWORD como 0:

"EnableOcspStaplingForSni"=dword:00000000

Observação

Habilitar essa chave do Registro tem um impacto potencial no desempenho.

FIPSAlgorithmPolicy

Esta entrada controla a conformidade do padrão FIPS. O padrão é 0.

Versões aplicáveis: todas as versões que começam com Windows Server 2012 e Windows 8.

Caminho do Registro: HKLM SYSTEM\CurrentControlSet\Control\LSA

Windows pacotes de criptografia FIPS do servidor: consulte pacotes e protocolos de criptografia com suporte no SSP do Schannel.

Hashes

Os algoritmos de hash TLS/SSL devem ser controlados configurando a ordem do pacote de criptografia. Confira a configuração do ordem do pacote de criptografia TLS para obter detalhes.

IssuerCacheSize

Essa entrada controla o tamanho do cache emissor e é usada com o mapeamento do emissor. O Schannel SSP tenta mapear todos os emissores na cadeia de certificados do cliente, não apenas o emissor direto do certificado do cliente. Quando os emissores não são mapeados para uma conta, que é o caso típico, o servidor pode tentar mapear o mesmo nome do emissor repetidamente, centenas de vezes por segundo.

Para evitar isso, o servidor tem um cache negativo, portanto, se um nome de emissor não é mapeado para uma conta, ele é adicionado ao cache e o SSP Schannel não tentará mapear o nome do emissor novamente, até que a entrada de cache expira. Essa entrada de Registro especifica o tamanho do cache. Essa entrada não existe no Registro por padrão. O valor padrão é 100.

Versões aplicáveis: todas as versões que começam com Windows Server 2008 e Windows Vista.

Caminho do Registro: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

IssuerCacheTime

Essa entrada controla a duração do intervalo de tempo limite do cache em milissegundos. O Schannel SSP tenta mapear todos os emissores na cadeia de certificados do cliente, não apenas o emissor direto do certificado do cliente. No caso em que os emissores não são mapeados para uma conta, que é o caso típico, o servidor pode tentar mapear o mesmo nome do emissor repetidamente, centenas de vezes por segundo.

Para evitar isso, o servidor tem um cache negativo, portanto, se um nome do emissor não for mapeado para uma conta, ele será adicionado ao cache e o SSP do Schannel não tentará mapear o nome do emissor novamente até que a entrada de cache expire. Esse cache é mantido por motivos de desempenho, para que o sistema não continue tentando mapear os mesmos emissores. Essa entrada não existe no Registro por padrão. O valor padrão é 10 minutos.

Versões aplicáveis: todas as versões que começam com Windows Server 2008 e Windows Vista.

Caminho do Registro: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

KeyExchangeAlgorithm – Tamanhos de chave RSA do cliente

Essa entrada controla os tamanhos de chave RSA do cliente.

O uso de algoritmos de troca de chaves deve ser controlado configurando a ordem do pacote de criptografia.

Adicionado em Windows 10, versão 1507 e Windows Server 2016.

Caminho do Registro: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\PKCS

Para especificar um intervalo mínimo com suporte de comprimento de bit de chave RSA para o cliente TLS, crie uma entrada ClientMinKeyBitLength . Essa entrada não existe no Registro por padrão. Depois de criar a entrada, altere o valor DWORD para o comprimento de bit desejado. Se não estiver configurado, 1024 bits serão o mínimo.

Para especificar um intervalo máximo com suporte de comprimento de bit de chave RSA para o cliente TLS, crie uma entrada ClientMaxKeyBitLength . Essa entrada não existe no Registro por padrão. Depois de criar a entrada, altere o valor DWORD para o comprimento de bit desejado. Se não estiver configurado, um máximo não será imposto.

KeyExchangeAlgorithm - Diffie-Hellman tamanhos de chave

Essa entrada controla os tamanhos de chave Diffie-Hellman.

O uso de algoritmos de troca de chaves deve ser controlado configurando a ordem do pacote de criptografia.

Adicionado em Windows 10, versão 1507 e Windows Server 2016.

Caminho do Registro: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman

Para especificar um intervalo mínimo com suporte de Diffie-Helman comprimento de bit de chave para o cliente TLS, crie uma entrada ClientMinKeyBitLength . Essa entrada não existe no Registro por padrão. Depois de criar a entrada, altere o valor DWORD para o comprimento de bit desejado. Se não estiver configurado, 1024 bits serão o mínimo.

Para especificar um intervalo máximo com suporte de Diffie-Helman comprimento de bit de chave para o cliente TLS, crie uma entrada ClientMaxKeyBitLength . Essa entrada não existe no Registro por padrão. Depois de criar a entrada, altere o valor DWORD para o comprimento de bit desejado. Se não estiver configurado, um máximo não será imposto.

Para especificar a Diffie-Helman comprimento de bit de chave para o servidor TLS padrão, crie uma entrada ServerMinKeyBitLength . Essa entrada não existe no Registro por padrão. Depois de criar a entrada, altere o valor DWORD para o comprimento de bit desejado. Se não estiver configurado, 2048 bits serão o padrão.

MaximumCacheSize

Essa entrada controla o número máximo de elementos de cache. A configuração de MaximumCacheSize como 0 desabilita o cache de sessão do servidor e impede a reconexão. O aumento de MaximumCacheSize acima dos valores padrão faz com que o Lsass.exe consuma memória adicional. Cada elemento de cache de sessão normalmente requer de 2 a 4 KB de memória. Essa entrada não existe no Registro por padrão. O valor padrão é 20.000 elementos.

Versões aplicáveis: todas as versões que começam com Windows Server 2008 e Windows Vista.

Caminho do Registro: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Mensagens – análise de fragmentos

Essa entrada controla o tamanho máximo permitido de mensagens de handshake TLS fragmentadas que serão aceitas. Mensagens maiores que o tamanho permitido não serão aceitas e o handshake do TLS falhará. Essas entradas não existem no registro por padrão.

Quando você define o valor como 0x0, as mensagens fragmentadas não são processadas e farão com que o handshake do TLS falhe. Isso torna os clientes ou servidores TLS no computador atual incompatíveis com as RFCs TLS.

O tamanho máximo permitido pode ser aumentado até 2^24-1 bytes. Permitir que um cliente ou servidor leia e armazene grandes quantidades de dados não verificados da rede não é uma boa ideia e consumirá memória adicional para cada contexto de segurança.

Adicionado no Windows 7 e Windows Server 2008 R2: uma atualização que habilita o Internet Explorer em Windows XP, no Windows Vista ou no Windows Server 2008 para analisar mensagens fragmentadas de handshake TLS/SSL está disponível.

Caminho do Registro: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Messaging

Para especificar um tamanho máximo permitido de mensagens de handshake TLS fragmentadas que o cliente TLS aceitará, crie uma entrada MessageLimitClient . Depois de criar a entrada, altere o valor DWORD para o comprimento de bit desejado. Se não estiver configurado, o valor padrão será 0x8000 bytes.

Para especificar um tamanho máximo permitido de mensagens de handshake TLS fragmentadas que o servidor TLS aceitará quando não houver autenticação de cliente, crie uma entrada MessageLimitServer . Depois de criar a entrada, altere o valor DWORD para o comprimento de bit desejado. Se não estiver configurado, o valor padrão será 0x4000 bytes.

Para especificar um tamanho máximo permitido de mensagens de handshake TLS fragmentadas que o servidor TLS aceitará quando houver autenticação de cliente, crie uma entrada MessageLimitServerClientAuth . Depois de criar a entrada, altere o valor DWORD para o comprimento de bit desejado. Se não estiver configurado, o valor padrão será 0x8000 bytes.

SendTrustedIssuerList

Essa entrada controla o sinalizador que é usado quando a lista de emissores confiáveis é enviada. No caso de servidores que confiam centenas de autoridades de certificação para autenticação de cliente, há muitos emissores de servidor capaz de enviá-los todos para o computador cliente ao solicitar a autenticação do cliente. Nessa situação, essa chave do Registro pode ser definida e, em vez de enviar uma lista parcial, o SSP Schannel não enviar nenhuma lista para o cliente.

O não envio de uma lista de emissores confiáveis pode afetar o que o cliente envia quando lhe é solicitado um certificado de cliente. Por exemplo, quando o Internet Explorer recebe uma solicitação de autenticação de cliente, ele exibe apenas os certificados de cliente que encadeiam até uma das autoridades de certificação enviadas pelo servidor. Se o servidor não tiver enviado a uma lista, o Internet Explorer exibirá todos os certificados de cliente que estão instalados no cliente.

Esse comportamento pode ser desejável. Por exemplo, quando os ambientes PKI incluem certificados cruzados, os certificados do cliente e do servidor não terão a mesma AC raiz; Portanto, o Internet Explorer não pode escolher um certificado que encadeia até um dos CAs do servidor. Ao configurar o servidor para não enviar uma lista de emissores confiáveis, o Internet Explorer enviará todos os seus certificados.

Essa entrada não existe no Registro por padrão.

Comportamento padrão da Lista de Emissores Confiáveis de Envio

Versão do Windows Comportamento padrão
Windows Server 2012 e Windows 8 e posterior FALSE
Windows Server 2008 R2 e Windows 7 e anterior TRUE

Versões aplicáveis: todas as versões que começam com Windows Server 2008 e Windows Vista.

Caminho do Registro: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

ServerCacheTime

Essa entrada controla a quantidade de tempo que o sistema operacional leva em milissegundos para finalizar entradas de cache do lado do servidor. Um valor de 0 desabilita o cache de sessão do lado do servidor e impede a reconexão. O aumento de ServerCacheTime acima dos valores padrão faz com que o Lsass.exe consuma memória adicional. Cada elemento de cache da sessão normalmente requer de 2 a 4 KB de memória. Essa entrada não existe no Registro por padrão.

Versões aplicáveis: todas as versões que começam com Windows Server 2008 e Windows Vista.

Caminho do Registro: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Tempo de cache do servidor padrão: 10 horas

Configurações de versão do protocolo TLS, DTLS e SSL

O SSP do Schannel implementa versões dos protocolos TLS, DTLS e SSL. Versões de Windows diferentes dão suporte a versões de protocolo diferentes. O conjunto de versões (D)TLS e SSL disponíveis em todo o sistema pode ser restrito (mas não expandido) por chamadores SSPI que especificam SCH_CREDENTIALS ou SCHANNEL_CRED estrutura na chamada AcquireCredentialsHandle . É recomendável que os chamadores de SSPI usem os padrões do sistema, em vez de impor restrições de versão de protocolo.

Uma versão de protocolo TLS ou SSL com suporte pode existir em um dos seguintes estados:

  • Habilitado: a menos que o chamador SSPI desabilite explicitamente essa versão de protocolo usando a estrutura SCH_CREDENTIALS , o Schannel SSP poderá negociar essa versão de protocolo com um par de suporte.
  • Desabilitado por padrão: a menos que o chamador SSPI solicite explicitamente essa versão de protocolo usando a estrutura de SCHANNEL_CRED preterida, o SSP do Schannel não negociará essa versão do protocolo.
  • Desabilitado: o Schannel SSP não negociará essa versão de protocolo independentemente das configurações que o chamador SSPI pode especificar.

O administrador do sistema pode substituir as configurações de versão padrão (D)TLS e protocolo SSL criando valores de registro DWORD "Habilitados" e "DisabledByDefault". Esses valores de registro são configurados separadamente para as funções de servidor e cliente de protocolo nas subchaves do Registro nomeadas usando o seguinte formato:

<Número da versão> SSL/TLS/DTLSmajor.<>< minor version numberClient><\Server>

Essas subchaves específicas de versão podem ser criadas no seguinte caminho do Registro:

HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Por exemplo, aqui estão alguns caminhos válidos do Registro com subchaves específicas da versão:

HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client

HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server

HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\DTLS 1.2\Client

Para substituir um padrão do sistema e definir uma versão de protocolo TLS (D)TLS ou SSL com suporte para o estado habilitado , crie um valor de registro DWORD chamado "Habilitado" com um valor diferente de zero e um valor de registro DWORD chamado "DisabledByDefault" com um valor zero, sob a subchave específica da versão correspondente.

O exemplo a seguir mostra o cliente TLS 1.0 definido como o estado Habilitado :

TLS 1.0 client enabled

Para substituir um padrão do sistema e definir uma versão de protocolo TLS ou SSL com suporte para Desabilitado por estado padrão , crie valores de registro DWORD chamados "Enabled" e "DisabledByDefault" com um valor diferente de zero na subchave específica da versão correspondente. O exemplo a seguir mostra o servidor TLS 1.0 definido como Desabilitado por estado padrão :

TLS 1.0 server disabled by default

Para substituir um padrão do sistema e definir uma versão de protocolo TLS (D)TLS ou SSL com suporte para o estado desabilitado , crie um valor de registro DWORD chamado "Habilitado", com um valor de zero, na subchave específica da versão correspondente.

O exemplo a seguir mostra o DTLS 1.2 desabilitado no registro:

DTLS 1.2 disabled

Alternar uma versão do protocolo (D)TLS ou SSL para Desabilitada por padrão ou estado desabilitado pode fazer com que as chamadas AcquireCredentialsHandle falhem devido à falta de versões de protocolo habilitadas em todo o sistema e ao mesmo tempo permitidas por chamadores específicos de SSPI. Além disso, reduzir o conjunto de versões TLS e SSL habilitadas pode interromper a interoperabilidade com pares remotos.

Depois que as configurações de versão do protocolo (D)TLS ou SSL tiverem sido modificadas, elas terão efeito sobre as conexões estabelecidas usando identificadores de credencial abertos por chamadas AcquireCredentialsHandle subsequentes . (D) Os serviços e aplicativos de cliente e servidor TLS e SSL tendem a reutilizar identificadores de credencial para várias conexões, por motivos de desempenho. Para que esses aplicativos requisiram seus identificadores de credencial, um aplicativo ou reinicialização de serviço pode ser necessário.

Observe que essas configurações de registro se aplicam apenas ao SSP do Schannel e não afetam nenhuma implementação TLS e SSL de terceiros que possam ser instaladas no sistema.