Configurações do Registro do protocolo TLS
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows 11, Windows 10 e versões anteriores indicadas
Este artigo explica as informações de configuração de registro com suporte à implementação Windows do protocolo TLS (Transport Layer Security) e do protocolo SSL (Secure Sockets Layer) por meio do SSP (Provedor de Suporte de Segurança SChannel). As entradas e as subchaves do Registro abordadas neste artigo podem ajudar você a administrar e solucionar problemas de SSP SChannel, especificamente com 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 a Política de Grupo ou outras ferramentas do Windows, como o MMC (Console de Gerenciamento Microsoft). Se você deve editar o Registro, tenha muito cuidado.
Registro em log do SChannel
Há oito níveis de log para eventos SChannel salvos no log de eventos do sistema e exibidos por meio do Visualizador de Eventos. Esse caminho de registro é armazenado em HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL na chave EventLogging com um valor DWORD definido como 1.
| Decimal ou Hex | Eventos de registro em log do SChannel |
|---|---|
| 0 | Nenhum evento |
| 1 | Eventos de erro |
| 2 | Eventos de aviso |
| 3 | Eventos de erro e aviso |
| 4 | Eventos informativos e de êxito |
| 5 | Eventos de erro, informativos e de êxito |
| 6 | Eventos de aviso, informativos e de êxito |
| 7 | Eventos de erro, aviso, informativos e de êxito |
Observação
Você precisa reinicializar o dispositivo depois de alterar o nível de registro em log do SChannel.
CertificateMappingMethods
Quando um aplicativo para servidores requer autenticação de cliente, o SChannel automaticamente tenta mapear o certificado fornecido pelo computador do 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).
O provedor SChannel usa 4 (quatro) métodos de mapeamento de certificado:
- Mapeamento de S4U (serviço para usuário) Kerberos (habilitado por padrão)
- Mapeamento de nome UPN
- Mapeamento um a um (também conhecido como mapeamento de assunto/emissor)
- Mapeamento muitos-para-um
Caminho de registro: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
| Nome da entrada | DWORD | Habilitado por padrão |
|---|---|---|
| Entidade/emissor | 0x000000001 | Não |
| Emissor | 0x000000002 | Não |
| UPN | 0x000000004 | Não |
| S4U2Self | 0x000000008 | Sim |
| S4U2Self Explicit | 0x000000010 | Sim |
Versões aplicáveis: conforme indicado na lista Aplica-se a no começo deste artigo.
Criptografias
As criptografias TLS/SSL devem ser controladas com a configuração do pedido do pacote de criptografia. Para obter detalhes, consulte Configurando o pedido do pacote de criptografia TLS.
Para mais informações sobre os pedidos padrão do pacote de criptografia usados pelo SSP SChannel, confira Pacotes de criptografia no protocolo TLS/SSL (SSP SChannel).
CipherSuites
A configuração de pacotes de criptografia TLS/SSL deve ser feita usando política de grupo, MDM ou PowerShell; consulte Configurando o pedido do pacote de criptografia TLS para obter detalhes.
Para mais informações sobre os pedidos padrão do pacote de criptografia usados pelo SSP SChannel, confira Pacotes de criptografia no protocolo TLS/SSL (SSP SChannel).
ClientCacheTime
Essa entrada especifica o tempo de vida do item de cache de sessão TLS do cliente em milissegundos. Do Windows Server 2008 e do Windows Vista em diante, o padrão é de 10 horas. Um valor 0 desativa o cache de sessão TLS no cliente.
Na primeira vez que um cliente se conecta a um servidor por meio do SSP SChannel, um handshake TLS/SSL completo é executado. Quando isso for concluído, o segredo mestre, o conjunto de criptografias e os certificados serão armazenados no cache da sessão, nos respectivos cliente e servidor.
Caminho de registro: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
EnableOcspStaplingForSni
O grampeamento do OCSP (Protocolo de Status de Certificado Online) permite que um servidor Web, como os 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 a 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 a vários clientes Web. Sem esse recurso, cada cliente Web tentaria recuperar o status OCSP atual do certificado do servidor OCSP. Isso geraria uma carga alta nesse servidor OCSP.
Além do IIS, os serviços Web por http.sys também podem se beneficiar dessa configuração, incluindo AD FS (Serviços de Federação do Active Directory) e WAP (Web Proxy de Aplicativo).
Por padrão, o suporte a OCSP está habilitado para sites do IIS que têm uma associação (SSL/TLS) simples protegida. No entanto, esse suporte não estará habilitado por padrão se o site do IIS estiver usando um ou os dois seguintes tipos de associações SSL/TLS:
- Exigir Indicação de Nome de Servidor
- Usar repositório de certificados centralizados
Nesse caso, a resposta do servidor hello durante o handshake do TLS não incluirá um status grampeado OCSP por padrão. Esse comportamento melhora o desempenho: a implementação de grampeamento do Windows OCSP é dimensionada para centenas de certificados de servidor. No entanto, a SNI (Indicação de Nome do Servidor) e o CCS (Repositório Central de Certificados) permitem que o IIS seja dimensionado para milhares de sites que potencialmente têm milhares de certificados de servidor. Portanto, habilitar o grampeamento do OCSP para associações CCS talvez cause 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
A habilitação dessa chave do Registro tem possível impacto no desempenho.
Hashes
Os algoritmos de hash TLS/SSL devem ser controladas com a configuração do pedido do pacote de criptografia. Consulte Configurando o pedido 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 SSP SChannel 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, é adicionado ao cache, e o SSP SChannel não tenta mapear o nome do emissor novamente, até que a entrada de cache expire. 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 o Windows Server 2008 e o Windows Vista.
Caminho de registro: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
IssuerCacheTime
Essa entrada controla a duração do intervalo de tempo limite do cache em milissegundos. O SSP SChannel tenta mapear todos os emissores na cadeia de certificados do cliente, não apenas o emissor direto do certificado do cliente. Caso os emissores não sejam 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, é adicionado ao cache, e o SSP SChannel não tenta 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 o Windows Server 2008 e o Windows Vista.
Caminho de registro: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Tamanhos de chave KeyExchangeAlgorithm
Por padrão, as entradas a seguir talvez não existam no Registro e devem ser criadas manualmente. O uso de algoritmos de troca de chaves deve ser controlado com a configuração do pedido do pacote de criptografia. Para saber mais sobre os algoritmos de criptografia do pacote de criptografia TLS/SSL, consulte Pacotes de Criptografia em TLS/SSL (SSP Schannel).
Adicionado no Windows 10, versão 1507 e no Windows Server 2016.
Caminho do registro: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman
Para especificar um intervalo mínimo com suporte do tamanho de bit de chave Diffie-Hellman para o cliente TLS, crie uma entrada ClientMinKeyBitLength. Depois de criar a entrada, altere o valor DWORD para o comprimento de bit desejado. Se não estiver configurado, 1024 bits será o mínimo.
Para especificar um intervalo máximo com suporte de tamanho de bit de chave Diffie-Hellman para o cliente TLS, crie uma entrada ClientMaxKeyBitLength. Depois de criar a entrada, altere o valor DWORD para o comprimento de bit desejado.
Para especificar o tamanho de bit de chave Diffie-Hellman para o padrão do servidor TLS, crie uma entrada ServerMinKeyBitLength. Depois de criar a entrada, altere o valor DWORD para o comprimento de bit desejado. Se não estiver configurado, 2048 bits será o padrão.
Observação
As curvas elípticas configuradas determinam a força criptográfica da troca de chaves ECDHE. Para mais informações, confira TLS (Gerenciador do protocolo TLS).
MaximumCacheSize
Essa entrada controla o número máximo de sessões TLS para cache. A configuração de MaximumCacheSize definida como 0 desabilita o cache de sessão do lado do servidor para impedir a retomada. 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 KB 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 o Windows Server 2008 e o Windows Vista.
Caminho de registro: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Mensagens – análise de fragmentos
Essa entrada controla o tamanho máximo permitido de uma mensagem de handshake TLS que seja aceita. As mensagens maiores do que o tamanho permitido não serão aceitas e ocorrerá falha no handshake TLS. 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 levam à falha do handshake TLS. Isso acaba com a conformidade dos clientes ou servidores TLS no computador atual com os RFCs TLS.
O tamanho máximo permitido pode ser aumentado até 2^16 bytes. Não é uma boa ideia permitir que um cliente ou servidor leiam e armazenem grandes volumes de dados não verificados direto da rede, pois esse procedimento consome memória adicional para cada contexto de segurança.
Adicionado no Windows 7 e no Windows Server 2008 R2: está disponível uma atualização que habilita o Internet Explorer no Windows XP, no Windows Vista ou no Windows Server 2008 para analisar mensagens fragmentadas de handshake TLS/SSL.
Caminho do registro: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Messaging
Para especificar o tamanho máximo permitido de mensagens de handshake TLS que o cliente TLS aceita, 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 o tamanho máximo permitido de mensagens de handshake TLS que o servidor TLS aceita quando não há 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 o tamanho máximo permitido de mensagens de handshake TLS que o servidor TLS aceita quando não há 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
Os servidores TLS talvez enviem uma lista dos nomes diferenciados das autoridades de certificação aceitáveis ao solicitar a autenticação do cliente. Isso talvez ajude os clientes TLS a selecionar um certificado de cliente TLS apropriado. Os servidores TLS baseados em SChannel não enviam essa lista de emissores confiáveis por padrão porque ela expõe as autoridades de certificação confiáveis pelo servidor a observadores passivos e também aumenta a quantidade de dados trocados no curso do handshake TLS. Definir esse valor como 1 faz com que os servidores baseados em SChannel enviem suas listas de emissores confiáveis.
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 Microsoft Edge 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 uma lista, o Microsoft Edge exibirá todos os certificados de cliente que estão instalados no cliente.
Esse comportamento pode ser desejável. Por exemplo, quando os ambientes de PKI incluírem certificados cruzados, os certificados de cliente e servidor não terão a mesma AC raiz. Portanto, o Microsoft Edge não poderá escolher um certificado que seja encadeado até uma das ACs do servidor. Os clientes TLS podem oferecer certificados de cliente disponíveis quando um servidor não enviar uma lista de emissores confiáveis. 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 2012, Windows Server 8 ou versões posteriores | FALSE |
| Windows Server 2008 R2, Windows 7 e versões anteriores | TRUE |
Versões aplicáveis: todas as versões que começam com o Windows Server 2008 e o Windows Vista.
Caminho de registro: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
ServerCacheTime
Essa entrada especifica o tempo de vida do item de cache de sessão TLS do servidor em milissegundos. O padrão é 10 horas. Um valor 0 desativa o cache de sessão TLS no servidor e impede a retomada da sessão. O aumento de ServerCacheTime 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 KB 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 o Windows Server 2008 e o Windows Vista.
Caminho de registro: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Tempo de cache do servidor padrão: 10 horas
Configurações de versão de protocolo TLS, DTLS e SSL
O SSP SChannel implementa versões dos protocolos TLS, DTLS e SSL. Versões diferentes do Windows 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 a estrutura SCH_CREDENTIALS 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:
- Enabled: a menos que o chamador SSPI desabilite explicitamente essa versão de protocolo usando estrutura SCH_CREDENTIALS, o SSP SChannel talvez negocie essa versão de protocolo com um par de suporte.
- Disabled: o SSP SChannel não negocia essa versão de protocolo, independentemente das configurações que o chamador de SSPI possa especificar.
Esses valores de registro são configurados separadamente para as funções de cliente e servidor de protocolo nas subchaves do registro nomeadas usando o seguinte formato:
<SSL/TLS/DTLS><número da versão principal>.<número da versão secundária><Cliente\Servidor>
Essas subchaves específicas da versão podem ser criadas no seguinte caminho de registro:
HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
Por exemplo, aqui estão alguns caminhos de registro válidos 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 (D)TLS ou SSL com suporte ao estado Enabled, crie um valor de Registro DWORD chamado "Enabled" com valor de entrada igual a "1" na subchave específica da versão correspondente.
O exemplo abaixo mostra o cliente TLS 1.0 definido como o estado Enabled:
Para substituir um padrão do sistema e definir uma versão de protocolo (D)TLS ou SSL com suporte ao estado Disabled, altere um valor de Registro DWORD de "Enabled" para "0" na subchave específica da versão correspondente.
O exemplo abaixo mostra o DTLS 1.2 desabilitado no registro:
A alternância de uma versão do protocolo (D)TLS ou SSL para o estado Disabled talvez faça com que as chamadas AcquireCredentialsHandle falhem devido à falta de versões de protocolo habilitadas para todo o sistema e ao mesmo tempo permitidas por determinados chamadores de SSPI. Além disso, a redução do conjunto de versões de (D)TLS e SSL Enabled pode interromper a interoperabilidade com pares remotos.
Depois que as configurações de versão do protocolo (D)TLS ou SSL forem modificadas, elas entrarão em vigor em conexões estabelecidas usando-se identificadores de credencial abertos por chamadas AcquireCredentialsHandle subsequentes. (Os serviços e aplicativos de cliente e servidor (D)TLS e SSL tendem a reutilizar identificadores de credenciais para várias conexões, por motivos de desempenho. Para que esses aplicativos requisitem seus identificadores de credencial, uma reinicialização de aplicativo ou serviço talvez seja necessária.
Essas configurações de Registro se aplicam apenas ao SSP SChannel e não afetam nenhuma implementação de (D)TLS e SSL de terceiros que talvez estejam instaladas no sistema.
Aviso
A tentativa de criar ou ajustar as configurações do Registro de SChannel que não sejam explicitamente detalhadas neste artigo não é recomendada devido a riscos potenciais e consequências não intencionais que possam surgir de configurações sem suporte.
Para saber mais sobre como gerenciar o pacote de criptografia TLS usando o PowerShell, consulte Referência de comando TLS. Se estiver interessado em gerenciar as configurações de TLS por meio da Política de Grupo, consulte Configurando a ordem do pacote de criptografia TLS usando a Política de Grupo.