Visão geral técnica do SSP Schannel

Artigo
09/02/2016

Publicado: agosto de 2016

Aplicável a: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, Windows 8

Este tópico de referência para profissionais de TI explica o que é o SSP (provedor de suporte de segurança) Schannel (canal de segurança) e quais serviços de autenticação ele fornece ao usar os protocolos TLS e SSL.

Este tópico inclui as seções a seguir:

O que é TLS, SSL e Schannel?
Cenários TLS e SSL comuns
Schannel SSP Technical Overview
Dependências do TLS e do SSL

Dica

O TLS é descrito no tópico Protocolo de segurança da camada de transporte.

O DTLS, que está incluído no SSP Schannel, é descrito no tópico Protocolo de datagrama Transport Layer Security.

O que é TLS, SSL e Schannel?

Um problema a resolver quando você administra uma rede é proteger os dados que estão sendo enviados entre os aplicativos em uma rede não confiável. Você pode usar o TLS/SSL para autenticar servidores e computadores cliente e, depois, para criptografar mensagens entre as partes autenticadas.

Os protocolos TLS, SSL, DTLS e PCT são baseados em criptografia por chave pública. O pacote de protocolos de autenticação Schannel fornece esses protocolos. Todos os protocolos Schannel usam um modelo de cliente e de servidor. Para obter uma lista dos protocolos com suporte, consulte Pacotes e protocolos de criptografia com suporte no SSP Schannel.

No processo de autenticação, um computador cliente TLS/SSL envia uma mensagem para um servidor TLS/SSL e o servidor responde com as informações apropriadas para se autenticar. O cliente e o servidor executam uma troca adicional de chaves de sessão e a caixa de diálogo de autenticação é encerrada. Quando a autenticação é concluída, a comunicação SSL pode ser iniciada entre o servidor e o cliente usando as chaves de criptografia simétrica estabelecidas durante o processo de autenticação.

Para os servidores se autenticarem nos clientes, o TLS/SSL não exige que as chaves do servidor sejam armazenadas em controladores de domínio ou em um banco de dados, como os Serviços de Domínio do Active Directory. Os clientes confirmam a validade das credenciais do servidor com certificados de AC (autoridade de certificação) raiz confiável, que são carregados quando você instala um sistema operacional Windows Server. Portanto, a menos que o servidor exija a autenticação do usuário, os usuários não precisam estabelecer contas antes de criar uma conexão segura com um servidor.

Histórico e padrões do TLS e do SSL

O SSL foi desenvolvido pela Netscape Communications Corporation em 1994 para proteger as transações feitas na World Wide Web. Logo depois, a IETF (Internet Engineering Task Force) começou a desenvolver um protocolo padrão que fornecia a mesma funcionalidade. Eles usaram o SSL 3.0 como base para esse trabalho, que evoluiu para se tornar o TLS. A implementação do protocolo TLS, começando no Windows Server 2003, segue rigorosamente a especificação definida nas seguintes especificações listadas no banco de dados de RFC da IETF:

O TLS e o SSL são mais amplamente reconhecidos como os protocolos que fornecem o HTTPS (HTTP seguro) para transações na Internet entre navegadores da Web e servidores Web. O TLS/SSL também pode ser usado para outros protocolos de nível de aplicativo, como os protocolos FTP, LDAP e SMTP. O TLS/SSL habilita a autenticação do servidor, a autenticação do cliente, a criptografia de dados e a integridade dos dados nas redes, como a World Wide Web.

Diferenças entre TLS e SSL

Embora haja algumas pequenas diferenças entre o SSL 3.0 e as versões do TLS, este guia de referência se refere ao protocolo como TLS/SSL.

Dica

O TLS e o SSL 3.0 não são intercambiáveis, embora suas diferenças sejam pequenas. Se o mesmo protocolo não contar com suporte do cliente e do servidor, eles devem negociar um protocolo comum para se comunicar com êxito.

Uma vez que o SSL era vulnerável ao aumento dos ataques de segurança, a IETF desenvolveu padrões de Internet para um protocolo mais seguro, o TLS. A lista a seguir descreve os aperfeiçoamentos do TLS, além da capacidade do SSL para proteger a comunicação em redes não confiáveis.

O algoritmo HMAC com chave substitui o algoritmo MAC (Message Authentication Code) com SSL.
O TLS é padronizado e é um padrão da Internet, enquanto o SSL tem diversas variantes.
O TLS contém mensagens de alerta adicionais.
O SSL exige certificados emitidos pela (ou encadeados de volta à) AC raiz. Ao usar o TLS, nem sempre é necessário incluir certificados encadeados de volta à AC raiz. Você pode usar uma autoridade intermediária.
Os algoritmos Fortezza não estão incluídos no RFC do TLS, uma vez que não estão abertos para análise pública.

Benefícios do TLS e do SSL

O TLS/SSL fornece inúmeros benefícios com o uso de outros métodos de autenticação para clientes e servidores. A tabela a seguir descreve alguns desses benefícios:

Benefício	Descrição
Autenticação forte, privacidade de mensagens e integridade	O TLS/SSL pode ajudar a proteger os dados transmitidos ao usar criptografia. O TLS/SSL autentica servidores e, como opção, autentica clientes para comprovar as identidades dos sistemas envolvidos na comunicação segura. Além disso, fornece integridade de dados por meio de um valor de verificação de integridade. Além de proteger contra a divulgação de dados, o protocolo de segurança TLS/SSL pode ser usado para ajudar a proteger contra ataques disfarçados, man-in-the-middle, de reversão e de reprodução.
Interoperabilidade	O TLS/SSL funciona com a maioria dos navegadores da Web e na maioria dos sistemas operacionais e servidores Web. Normalmente, ele é integrado a leitores de notícias, a servidores LDAP e a uma variedade de outros aplicativos disponíveis no mercado.
Flexibilidade de algoritmo	O TLS/SSL fornece opções para os mecanismos de autenticação, algoritmos de criptografia e algoritmos de hash usados durante a sessão segura.
Facilidade de implantação	Muitos aplicativos usam o TLS/SSL de maneira transparente nos sistemas operacionais Windows Server. Você pode usar o TLS para uma navegação mais segura ao usar o Internet Explorer e o IIS (Serviços de Informações da Internet). Se o servidor já tiver um certificado de servidor instalado, você apenas precisará marcar a caixa de seleção no Internet Explorer.
Facilidade de uso	Uma vez que você implementa o TLS/SSL sob a camada de aplicativo, a maioria das operações dele é completamente invisível ao computador cliente. Isso permite que o cliente tenha pouco ou nenhum conhecimento da segurança das comunicações e, ainda assim, estará protegido contra invasores.

Limitações do TLS e do SSL

Há algumas limitações no uso do TLS/SSL, conforme descrito na tabela a seguir.

Limitação	Descrição
Aumento da carga do processador	Essa é a limitação mais significativa na implementação do TLS/SSL. A criptografia, especificamente as operações de chave pública, usa a CPU intensivamente. Como resultado, o desempenho varia ao usar o SSL. Infelizmente, não há como saber o quanto de desempenho você perderá. O desempenho varia dependendo da frequência que as conexões são estabelecidas e de quanto tempo elas duram. O TLS usa os maiores recursos ao configurar conexões.
Sobrecarga administrativa	Um ambiente TLS/SSL é complexo e exige manutenção. O administrador do sistema deve configurar o sistema e gerenciar certificados.

Aumento da carga do processador

Essa é a limitação mais significativa na implementação do TLS/SSL. A criptografia, especificamente as operações de chave pública, usa a CPU intensivamente. Como resultado, o desempenho varia ao usar o SSL. Infelizmente, não há como saber o quanto de desempenho você perderá. O desempenho varia dependendo da frequência que as conexões são estabelecidas e de quanto tempo elas duram. O TLS usa os maiores recursos ao configurar conexões.

Sobrecarga administrativa

Um ambiente TLS/SSL é complexo e exige manutenção. O administrador do sistema deve configurar o sistema e gerenciar certificados.

Cenários TLS e SSL comuns

Muitas pessoas pensam no TLS e no SSL como protocolos usados com navegadores da Web para navegar pela Internet com mais segurança. No entanto, eles também são protocolos para uso geral que podem ser usados sempre que a autenticação e a proteção de dados forem necessárias. Na verdade, a capacidade de acessar esses protocolos por meio de interface SSPI significa que você pode usá-los em quase todos os aplicativos. Muitos aplicativos estão sendo modificados para tirar proveito dos recursos do TLS/SSL. A tabela a seguir fornece exemplos de como usar o TLS/SSL.

Cenário	Descrição
Transações SSL com um site de comércio eletrônico	Essa situação representa um uso típico do SSL entre um navegador e um servidor Web. Um exemplo é um site de comércio eletrônico em que os clientes precisam fornecer os números de cartão de crédito. Primeiro, o protocolo confirma se o certificado do site é válido e, depois, envia as informações do cartão de crédito como texto criptografado. Para esse tipo de transação, quando o certificado do servidor é proveniente de uma origem confiável, a autenticação ocorre somente para o servidor. O TLS/SSL deve ser habilitado para a página da Web, como um formulário de pedido, em que ocorrem as transações de dados.
Acesso para cliente autenticado a um site protegido por SSL	O cliente e o servidor precisam de certificados de uma AC (autoridade de certificação) mutuamente confiável. Com o SSP Schannel, os certificados de cliente podem ser mapeados em um esquema um para um ou muitos para um para contas de usuário ou de computador em um sistema operacional Windows Server. Eles podem ser gerenciados por meio dos Usuários e Computadores do Active Directory e os usuários podem ser autenticados em um site sem fornecer uma senha. O mapeamento de muitos para um tem vários usos. Por exemplo, se desejar dar acesso a um material confidencial para vários usuários, você pode criar um grupo, mapear os certificados dos usuários para o grupo e dar ao grupo as permissões necessárias em relação ao material. No mapeamento um para um, o servidor tem uma cópia do certificado do cliente e quando um usuário entra no computador cliente, o servidor verifica se eles são idênticos. Esse mapeamento é normalmente usado para materiais privados, como um site de serviços bancários no qual apenas uma pessoa tem o direito de exibir uma conta pessoal.
Acesso remoto	Trabalhar remotamente é um uso comum do SSP Schannel. Você pode usar essa tecnologia para fornecer autenticação e proteção de dados quando os usuários entram remotamente nas redes ou nos sistemas baseados em Windows. Os usuários podem acessar os aplicativos corporativos e de email em casa ou durante uma viagem, reduzindo o risco de exposição das informações às pessoas na Internet.
Acesso ao SQL Server	Você pode exigir autenticação de um computador cliente quando ele se conecta a um servidor que executa o SQL Server. O cliente ou o servidor pode ser configurado para exigir a criptografia dos dados que são transferidos entre eles. Informações altamente confidenciais, como bancos de dados financeiros ou médicos, podem ser protegidas para evitar o acesso não autorizado e a divulgação de informações sobre a rede.
Email	Ao usar o Exchange Server, você pode usar o SSP Schannel para ajudar a proteger os dados enquanto eles são movidos de servidor a servidor na intranet ou na Internet. A segurança de ponta a ponta completa pode exigir o uso de S/MIME (Secure/Multipurpose Internet Mail Extensions). No entanto, ajudar a proteger os dados em uma troca de servidor para servidor permite que as empresas usem a Internet para transferir emails com segurança entre as divisões na própria empresa, nas subsidiárias e nos parceiros. Isso pode ser feito independentemente se o S/MIME for usado.

Arquitetura do SSP Schannel

Nos sistemas operacionais Windows Server, o pacote de protocolos de autenticação Schannel contém o TLS. O diagrama a seguir mostra no qual o SSP Schannel se encaixa entre essas e outras tecnologias. Os aplicativos cliente ou de servidor usam Secur32.dll por meio de chamadas de SSPI para se comunicarem com o serviço LSASS.

Arquitetura do SSP Schannel

Schannel Architecture

A tabela a seguir lista as descrições dos elementos que participam do TLS/SSL.

Elementos do subsistema de segurança usados na autenticação TLS e SSL

Elemento	Descrição
Schannel.dll	Protocolo de autenticação TLS/SSL. Esse protocolo fornece autenticação por um canal criptografado em vez de um canal não criptografado menos seguro.
Lsasrv.dll	O LSASS impõe políticas de segurança e atua como o gerenciador de pacotes de segurança da autoridade de segurança local.
Netlogon.dll	No que diz respeito aos serviços TLS, o serviço Netlogon passa informações do certificado do usuário por meio de um canal SSL para o controlador do domínio para mapear o certificado do usuário para uma conta de usuário.
Secur32.dll	O provedor de autenticação múltipla que implementa o SSPI.

O pacote de protocolos de autenticação é habilitado pelo SSP Schannel, que conta com suporte da API (interface de programação de aplicativo) SSPI que fornece os serviços de segurança para os sistemas operacionais Windows Server.

A interface SSPI da Microsoft é a base para a autenticação no sistema operacional Windows. Ou seja, aplicativos e serviços de infraestrutura que exigem autenticação usam a SSPI para fornecê-la. Quando um cliente e um servidor precisam ser autenticados para se comunicarem com mais segurança, as solicitações de autenticação são roteadas à SSPI, que conclui o processo de autenticação, independentemente do protocolo de rede em uso no momento. A SSPI é a implementação da GSSAPI (API do Serviço Genérico de Segurança). Para obter mais informações sobre a GSSAPI, consulte as seguintes RFCs no banco de dados de RFC da IETF.

Para obter informações sobre a arquitetura da SSPI de todos os SSPs e como o provedor Kerberos se encaixa nessa arquitetura, consulte Security Support Provider Interface Architecture.

Você pode usar o SSP Schannel para acessar serviços habilitados para Web, como email ou informações pessoais fornecidas em páginas da Web. O SSP Schannel usa certificados de chave pública para autenticar as partes. Quatro protocolos de autenticação estão incluídos no pacote. Ao autenticar terceiros, ele selecionará um dos quatro protocolos na seguinte ordem de preferência:

TLS versão 1.2
TLS versão 1.1
TLS versão 1.0
SSL versão 3.0

Em seguida, o SSP Schannel seleciona o protocolo de autenticação preferencial que o cliente e o servidor podem dar suporte. Por exemplo, se um servidor der suporte a todos os quatro protocolos Schannel e o computador cliente der suporte apenas ao SSL 3.0, o provedor Schannel usará o SSL 3.0 para a autenticação.

Gerenciamento de emissores confiáveis para autenticação de cliente

Antes do Windows Server 2012 e do Windows 8, os aplicativos ou processos que usavam o SSP Schannel (incluindo HTTP.sys e IIS) podiam fornecer uma lista dos emissores confiáveis aos quais eles davam suporte para autenticação de cliente. Essas informações eram fornecidas por meio de uma CTL (lista de certificados confiáveis).

Quando a autenticação do computador cliente é exigida ao usar o SSL ou o TLS, você pode configurar o servidor para enviar uma lista de emissores de certificados confiáveis. Essa lista contém o conjunto de emissores de certificados no qual o servidor confiará, além de fornecer uma dica ao computador cliente sobre qual certificado de cliente selecionar se houver vários certificados presentes. Além disso, a cadeia de certificados que o computador cliente envia ao servidor deve ser validada em relação à lista de emissores confiáveis configurada.

No Windows Server 2012 e no Windows 8, foram feitas alterações no processo de autenticação subjacente de forma que:

Não há mais suporte para o gerenciamento da lista de emissores confiáveis com base em CTL.
O comportamento para enviar a lista de emissores confiáveis é desabilitado por padrão. Agora, o valor padrão da chave do Registro SendTrustedIssuerList é 0 (desabilitado por padrão), em vez de 1.
A compatibilidade com as versões anteriores dos sistemas operacionais Windows é preservada.

Isso permite uma capacidade de gerenciamento mais familiar por meio dos cmdlets de gerenciamento de certificados existentes no provedor do Windows PowerShell, bem como das ferramentas de linha de comando, como certutil.exe. Embora o tamanho máximo da lista de autoridades de certificação confiáveis à qual o SSP Schannel dá suporte (16 KB) continue o mesmo que no Windows Server 2008 R2, no Windows Server 2012, há um novo repositório de certificados dedicado a emissores de autenticação de cliente, para que os certificados não relacionados não sejam incluídos na mensagem do cliente/servidor.

Como funciona

A lista de emissores confiáveis é configurada usando repositórios de certificados: um repositório de certificados de computador global padrão e um que é opcional por site. A origem da lista será determinada da seguinte maneira:

Se houver um repositório de credenciais específico configurado para o site, ele será usado como a origem.
Se não existir nenhum certificado no repositório definido pelo aplicativo, o Schannel verificará o repositório de Emissores de Autenticação de Cliente no computador local. Se houver certificados, o Schannel usará o repositório como a origem.
Se não houver nenhum certificado no repositório local ou no global, o SSP Schannel usará o repositório de Autoridades de Certificação Confiáveis como a origem da lista de emissores confiáveis. (Esse comportamento também ocorre no Windows Server 2008 R2.)

Você pode construir uma lista de nomes de prováveis emissores do certificado para fornecer dicas ao usuário final sobre qual escolher. Essa lista é configurável usando a Política de Grupo.

Se o repositório de Autoridades de Certificação Confiáveis contiver uma mistura de certificados de emissores raiz (autoassinados) e de emissores de AC (autoridade de certificação), somente os certificados de emissores de AC serão enviados ao servidor por padrão.

Como configurar o Schannel para usar o repositório de certificados de emissores confiáveis

O SSP Schannel, por padrão, usará os repositórios conforme descrito anteriormente para gerenciar a lista de emissores confiáveis. Você ainda pode usar os cmdlets de gerenciamento de certificados existentes no provedor do Windows PowerShell, bem como as ferramentas de linha de comando, como certutil.exe, para gerenciar os certificados.

Para obter informações sobre como gerenciar certificados usando o provedor do Windows PowerShell, consulte AD CS Administration Cmdlets in Windows PowerShell (Cmdlets de administração do AD CS no Windows PowerShell).

Para obter informações sobre como gerenciar certificados usando o utilitário de certificado, consulte certutil.exe.

Para obter informações sobre quais dados (incluindo o repositório definido pelo aplicativo) são definidos para uma credencial Schannel, consulte SCHANNEL_CRED structure (Windows) (Estrutura SCHANNEL_CRED (Windows)).

Configurando um aplicativo ou recurso para usar o repositório de Emissores de Autenticação de Cliente

Algumas tecnologias não usam o repositório de Emissores de Autenticação de Cliente por padrão. Nesses casos, você deve configurar a tecnologia para usar o repositório.

Por exemplo, com o servidor Web, o HTTP.sys, que implementa a pilha de servidores HTTP do Windows, não está configurado por padrão para usar o repositório de Emissores de Autenticação de Cliente.

Para configurar o HTTP.SYS para usar o repositório de Emissores de Autenticação de Cliente, você pode usar o seguinte comando:

netsh http add sslcert ipport=0.0.0.0:443 certhash=GUID hash value appid={GUID application identifier}  sslctlstorename=ClientAuthIssuer

Para encontrar os valores de certhash e de appid no servidor, você pode usar o seguinte comando:

netsh http show sslcert

Padrões dos modos de confiança

O SSP Schannel dá suporte a três modos de confiança de autenticação de clientes. O modo de confiança controla como a validação da cadeia de certificados do cliente é executada. Trata-se de uma configuração de todo o sistema controlada pelo REG_DWORD “ClientAuthTrustMode” em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel.

Valor	Modo de confiança	Descrição
0	Confiança do computador (padrão)	Requer que o certificado do cliente seja emitido por um certificado da lista de emissores confiáveis.
1	Confiança raiz exclusiva	Requer que um certificado de cliente esteja ligado a um certificado raiz contido no repositório de emissores confiáveis especificado pelo chamador. O certificado também deve ser emitido por meio da lista de emissores confiáveis.
2	Confiança de AC exclusiva	Requer que um certificado de cliente esteja ligado a um Certificado de Autoridade de Certificação intermediário ou a um certificado raiz no repositório de emissores confiáveis especificado pelo chamador.

Para obter informações sobre falhas de autenticação devido a problemas de configuração na lista de emissores confiáveis, consulte o artigo 280256 na Base de Dados de Conhecimento Microsoft.

Dependências do TLS e do SSL

O TLS e o SSL dependem de várias tecnologias relacionadas e recursos para funcionar corretamente. A tabela a seguir descreve essas tecnologias e recursos e resume como elas estão relacionadas à autenticação TLS/SSL.

Dependência	Descrição
Sistema operacional	A autenticação SSL e TLS dependem da funcionalidade do cliente que é interna nos sistemas operacionais Windows Server e Windows. Se um cliente ou servidor estiver executando um sistema operacional que não dá suporte a TLS/SSL, não será possível usar a autenticação TLS/SSL.
Conectividade de rede TCP/IP	Para a autenticação TLS ou SSL ocorrer, deve haver conectividade de rede TCP/IP entre o cliente e o servidor de destino. Para obter mais informações, consulte TCP/IP.
Domínio do Active Directory	Quando um aplicativo para servidores exige autenticação de cliente, o SSP Schannel tenta mapear automaticamente o certificado fornecido pelo cliente para uma conta de usuário. Você pode autenticar os usuários que entram com um certificado de cliente ao criar manualmente os mapeamentos, os quais relacionam as informações do certificado a uma conta de usuário do Windows. Depois de criar e habilitar um certificado de mapeamento, sempre que um cliente apresentar um certificado, seu aplicativo para servidores associará o usuário automaticamente à conta de usuário apropriada no sistema operacional Windows. Se desejar usar o mapeamento de certificado, você deve usar contas de usuário nos Serviços de Domínio do Active Directory. Para obter mais informações, consulte Visão geral dos serviços de domínio Active Directory.
Autoridades de certificação confiáveis	Como a autenticação baseia-se em certificados digitais, as ACs (autoridades de certificação), como a Verisign ou os Serviços de Certificados do Active Directory, são uma parte importante do TLS/SSL. Uma AC é um certificado não Microsoft mutuamente confiável que confirma a identidade de um solicitante de certificado (geralmente um usuário ou computador) e, em seguida, emite um certificado para ele. O certificado associa a identidade do solicitante a uma chave pública. As ACs também renovam e revogam certificados conforme necessário. Por exemplo, se um cliente recebeu o certificado do servidor, o computador cliente pode tentar encontrar uma correspondência da AC do servidor na lista de ACs confiáveis do cliente. Se a AC emissora for confiável, o cliente verificará se o certificado é autêntico e não foi adulterado. Para obter mais informações sobre as ACs, consulte Visão geral dos Serviços de Certificados do Active Directory.

Consulte também

Referência de provedor de suporte técnico segurança Schannel

Share via