Configurações do Registro Transport Layer Security (TLS)

Este artigo explica as informações de configuração de registo suportadas para a implementação do Windows do protocolo TLS (Transport Layer Security) e do protocolo SSL (Secure Sockets Layer) através do SSP (Schannel Security Support Provider). As subchaves e entradas do Registro abordadas neste artigo ajudam você a administrar e solucionar problemas do SSP Schannel, especificamente os protocolos TLS e SSL.

Registro de schannel

Há oito níveis de log para eventos Schannel salvos no log de eventos do sistema e visíveis usando o Visualizador de Eventos. Esse caminho do Registro é armazenado sob HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL a chave EventLogging com um valor DWORD definido como 1.

CertificateMappingMethods

Quando um aplicativo de servidor requer autenticação de cliente, o Schannel tenta mapear automaticamente o certificado fornecido pelo computador cliente para uma conta de usuário. Você pode autenticar usuários que entram com um certificado de cliente criando mapeamentos, que relacionam as informações do certificado a uma conta de usuário do Windows.

Depois de criar e habilitar um mapeamento de certificado, cada vez que um cliente apresenta um certificado de cliente, seu aplicativo de servidor associa automaticamente esse usuário à conta de usuário apropriada do Windows.

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

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

O provedor Schannel usa quatro métodos de mapeamento de certificado:

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

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

Ciphers

As cifras TLS/SSL devem ser controladas configurando a ordem do conjunto de codificações. Para obter detalhes, consulte Configurando o pedido do conjunto de codificação TLS.

Para obter informações sobre ordens de conjunto de codificação padrão usadas pelo SSP Schannel, consulte Pacotes de codificação em TLS/SSL (SSP Schannel).

CipherSuites

A configuração de pacotes de codificação TLS/SSL deve ser feita usando a política de grupo, MDM ou PowerShell, consulte Configurando o pedido do conjunto de codificação TLS para obter detalhes.

Para obter informações sobre ordens de conjunto de codificação padrão usadas pelo SSP Schannel, consulte Pacotes de codificação em TLS/SSL (SSP Schannel).

ClientCacheTime

Esta entrada especifica o tempo de vida do item de cache de sessão TLS do cliente em milissegundos. A partir do Windows Server 2008 e do Windows Vista, o padrão é 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 concluído, o segredo mestre, o pacote de codificação e os certificados são armazenados no cache de sessão no respetivo cliente e servidor.

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

EnableOcspStaplingForSni

O grampeamento OCSP (Online Certificate Status Protocol) permite que um servidor Web, como o IIS (Serviços de Informações da Internet), forneça o status atual de revogação de um certificado de servidor quando ele envia o certificado do servidor para um cliente durante o handshake TLS. Esse recurso reduz a carga nos 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 da Web tentaria recuperar o status OCSP atual do certificado do servidor do servidor OCSP. Isso geraria uma alta carga nesse servidor OCSP.

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

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

• Exigir indicação de nome do servidor
• Usar armazenamento centralizado de certificados

Nesse caso, a resposta de saudação do servidor durante o handshake TLS não inclui um status de grampeado OCSP por padrão. Esse comportamento melhora o desempenho: a implementação de grampeamento OCSP do Windows é dimensionada para centenas de certificados de servidor. No entanto, a Indicação de Nome do Servidor (SNI) e o Armazenamento Central de Certificados (CCS) 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.

Caminho do registo: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Adicione a seguinte chave:

"EnableOcspStaplingForSni"=dword:00000001

Para desativar, defina o valor DWORD como 0:

"EnableOcspStaplingForSni"=dword:00000000

Hashes

Os algoritmos de hash TLS/SSL devem ser controlados configurando a ordem do conjunto de codificações. Consulte Configurando a ordem do conjunto de codificação TLS para obter detalhes.

IssuerCacheSize

Essa entrada controla o tamanho do cache do 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 mapeiam 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 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 de cache expire. Esta entrada do Registro especifica o tamanho do cache. Esta entrada não existe no registo por predefinição. O valor padrão é 100.

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

IssuerCacheTime

Essa entrada controla o comprimento 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. No caso em que os emissores não mapeiam 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 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 de cache expire. Esse cache é mantido por motivos de desempenho, para que o sistema não continue tentando mapear os mesmos emissores. Esta entrada não existe no registo por predefinição. O valor padrão é 10 minutos.

Caminho do registo: 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 pela configuração da ordem do conjunto de codificações. Para saber mais sobre algoritmos criptográficos do conjunto de codificação TLS/SSL, consulte Pacotes de codificação em TLS/SSL (SSP Schannel).

MaximumCacheSize

Esta entrada controla o número máximo de sessões TLS a armazenar em cache. Definir MaximumCacheSize para 0 desativar 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. Esta entrada não existe no registo por predefinição. O valor padrão é 20.000 elementos.

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

Mensagens – análise de fragmentos

Esta entrada controla o tamanho máximo permitido de uma mensagem de handshake TLS que é aceite. Mensagens maiores do 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 torna os clientes ou servidores TLS na máquina atual não compatíveis com as 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 permite que o Internet Explorer no Windows XP, no Windows Vista ou no Windows Server 2008 analise mensagens de handshake TLS/SSL fragmentadas.

Caminho do registo: 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 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 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 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 aceita quando há autenticação de cliente, crie uma MessageLimitServerClientAuth entrada. 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 podem enviar uma lista dos nomes distintos das 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 expõe as autoridades de certificação confiáveis pelo servidor a observadores passivos e também aumenta a quantidade de dados trocados durante o 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 encadeados até uma das autoridades de certificação enviadas pelo servidor. Se o servidor não enviou uma lista, o Microsoft Edge exibirá todos os certificados de cliente 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 pode escolher um certificado que encadeie até uma das CAs 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. Esta entrada não existe no registo por predefinição.

Comportamento padrão de Enviar Lista de Emissores Confiáveis

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

ServerCacheTime

Esta 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. Aumentar ServerCacheTime acima dos valores padrão faz com que Lsass.exe consuma memória adicional. Cada elemento de cache de sessão normalmente requer de 2 KB a 4 KB de memória. Esta entrada não existe no registo por predefinição.

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

Tempo de cache padrão do servidor: 10 horas

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

SChannel SSP implementa versões dos protocolos TLS, DTLS e SSL. Diferentes versões do Windows suportam diferentes versões de protocolo. 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 especificando a estrutura SCH_CREDENTIALS na chamada AcquireCredentialsHandle . É recomendável que os chamadores SSPI usem os padrões do sistema, em vez de impor restrições de versão do protocolo.

Uma versão suportada do protocolo (D)TLS ou SSL 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 do SSPI possa especificar.

Esses valores do 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 do 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 suportada do protocolo (D)TLS ou SSL 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 a seguir mostra o cliente TLS 1.0 definido para o estado Enabled :

Para substituir um padrão do sistema e definir uma versão suportada do protocolo (D)TLS ou SSL para o Disabled estado, altere o valor do Registro DWORD de Enabled para "0" na subchave específica da versão correspondente.

O exemplo a seguir mostra 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 poderia quebrar a interoperabilidade com pares remotos.

Depois que as configurações de versão do protocolo (D)TLS ou SSL são modificadas, elas entram em vigor nas conexões estabelecidas usando identificadores de credenciais abertos por chamadas AcquireCredentialsHandle subsequentes . (D)Os aplicativos e serviços de cliente e servidor TLS e SSL tendem a reutilizar identificadores de credenciais para várias conexões, por motivos de desempenho. Para que esses aplicativos readquiram seus identificadores de credenciais, pode ser necessário reiniciar um aplicativo ou serviço.

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

Para saber mais sobre como gerenciar o conjunto de codificação TLS usando o PowerShell, consulte Referência de comando TLS. Se estiver interessado em gerenciar as configurações de TLS por meio da Diretiva de Grupo, consulte Configurar a ordem do conjunto de codificação TLS usando a Diretiva de Grupo.