Configurações do Registro do protocolo TLS

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 subchaves do registro e entradas abordadas neste artigo podem ajudá-lo a administrar e solucionar problemas de SSP SChannel, especificamente com protocolos TLS e SSL.

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 do Registro é armazenado na HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL chave EventLogging com um valor DWORD definido como 1.

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 quatro métodos de mapeamento de certificado:

1. Mapeamento de S4U (serviço para usuário) Kerberos (habilitado por padrão)
2. Mapeamento de nome UPN
3. Mapeamento um a um (também conhecido como mapeamento de assunto/emissor)
4. Mapeamento muitos-para-um

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

Versões aplicáveis: conforme designado na lista Aplica-se a no início 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 a ordem 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 do 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 de saudação do servidor durante o handshake TLS não inclui 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 de 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 OCSP para associações CCS 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

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 do emissor não for mapeado para uma conta, ele será adicionado ao cache e o SSP SChannel não tentará mapear o nome do emissor novamente até que a entrada do 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 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 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 do emissor não for mapeado para uma conta, ele será adicionado ao cache e o SSP SChannel não tentará mapear o nome do emissor novamente até que a entrada do 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 do registro: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Tamanhos de chave KeyExchangeAlgorithm

Essas entradas a seguir podem não existir no registro por padrão 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).

MaximumCacheSize

Essa entrada controla o número máximo de sessões TLS para cache. Definir MaximumCacheSize como 0 desabilita o cache de sessão do lado do servidor para evitar a retomada da sessão. Aumentar MaximumCacheSize acima dos valores padrão faz com que Lsass.exe consuma memória extra. 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 do 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. Mensagens maiores que o tamanho permitido não são aceitas e o handshake TLS falha. 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 fazem com que o handshake TLS falhe. 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. Permitir que um cliente ou servidor leia e armazene grandes quantidades de dados não verificados da rede não é uma boa ideia e consome memória extra 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 um tamanho máximo permitido de mensagens de handshake TLS fragmentadas que o cliente TLS aceita, crie uma MessageLimitClient entrada. Depois de criar a entrada, altere o valor DWORD para o comprimento de bits 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 aceita quando não há autenticação de cliente, crie uma MessageLimitServer entrada. Depois de criar a entrada, altere o valor DWORD para o comprimento de bits 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 aceita quando há autenticação de cliente, crie uma MessageLimitServerClientAuth entrada. Depois de criar a entrada, altere o valor DWORD para o comprimento de bits desejado. Se não estiver configurado, o valor padrão será 0x8000 bytes.

SendTrustedIssuerList

Os servidores TLS podem enviar uma lista dos nomes distintos de autoridades de certificação aceitáveis ao solicitar a autenticação do cliente. Isso pode ajudar 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.

Não enviar uma lista de emissores confiáveis pode afetar o que o cliente envia quando é 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 PKI incluem certificados cruzados, os certificados de cliente e servidor não têm a mesma autoridade de certificação 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 qualquer certificado de cliente disponível quando um servidor não envia a 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ões aplicáveis: todas as versões que começam com o Windows Server 2008 e o Windows Vista.

Caminho do 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 do 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:

• Habilitado: a menos que o chamador SSPI desabilite explicitamente essa versão do protocolo usando SCH_CREDENTIALS estrutura, o SSP SChannel pode negociar essa versão do protocolo com um par de suporte.
• Desabilitado: o SSP SChannel não negocia essa versão do protocolo, independentemente das configurações que o chamador SSPI pode 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> <major version number>.<minor version number><Client\Server>

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 para o Enabled estado, crie um valor de registro DWORD nomeado Enabled com um valor de entrada de "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 para o Disabled estado, altere o valor do 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:

Alternar uma versão do protocolo (D)TLS ou SSL para o Disabled estado 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 SSPI específicos. Além disso, reduzir o conjunto de versões ( Enabled D)TLS e SSL 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 fazer com que esses aplicativos readquiram seus identificadores de credenciais, pode ser necessário reiniciar um aplicativo ou serviço.

Essas configurações do Registro se aplicam apenas ao SChannel SSP e não afetam nenhuma implementação (D)TLS e SSL de terceiros que possa estar instalada no sistema.

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.