Protocolo TLS e certificados digitais
Este artigo descreve detalhes sobre o protocolo TLS (Transport Layer Security) e certificados digitais.
Protocolo TLS
Os protocolos TLS e SSL estão localizados entre a camada do protocolo de aplicativo e a camada TCP/IP, onde podem proteger e enviar dados do aplicativo para a camada de transporte. Os protocolos TLS/SSL usam algoritmos de um pacote de criptografia para criar chaves e criptografar informações. O cliente e o servidor negociam a versão do protocolo e o pacote de criptografia a serem usados para criptografar durante a fase de conexão inicial (pré-logon) do estabelecimento da conexão. A versão TLS com maior suporte sempre é preferida no handshake do TLS. Para verificar as versões do protocolos TLS com suporte em diferentes versões dos sistemas operacionais Windows, confira Protocolos no TLS/SSL (SSP do Schannel). Várias vulnerabilidades conhecidas foram relatadas contra SSL e versões anteriores do protocolo TLS. Recomendamos que faça upgrade para o TLS 1.2 para comunicação segura.
O SQL Server pode usar o Protocolo TLS para criptografar dados transmitidos em uma rede entre uma instância do SQL Server e um aplicativo cliente. O TLS usa um certificado para implementar a criptografia.
A habilitação da criptografia TLS aumenta a segurança dos dados transmitidos pelas redes entre instâncias do SQL Server e aplicativos. No entanto, quando todo o tráfego entre o SQL Server e um aplicativo cliente é criptografado usando TLS, o seguinte processamento adicional é necessário:
- Idas e voltas extras da rede são necessárias no momento da conexão.
- Os pacotes enviados do aplicativo para a instância do SQL Server devem ser criptografados pela pilha TLS do cliente e descriptografados pela pilha TLS do servidor.
- Os pacotes enviados da instância do SQL Server para o aplicativo devem ser criptografados pela pilha TLS do servidor e descriptografados pela pilha TLS do cliente.
Importante
Após o SQL Server 2016 (13.x), o protocolo SSL foi descontinuado. Use o TLS (TLS 1.2 é recomendado) em vez disso. Para saber mais, confira KB3135244: Suporte ao TLS 1.2 para o Microsoft SQL Server. O SQL Server 2022 introduz suporte ao TLS 1.3. Para saber mais, confira o Suporte ao TLS 1.3. Se não houver protocolos correspondentes entre o cliente e o computador servidor, você poderá se deparar com o erro descrito em Uma conexão existente foi fechada à força pelo host remoto.
Visão geral do certificado digital
Os certificados digitais são arquivos eletrônicos que funcionam como uma senha online para verificar a identidade de um usuário ou de um computador. Eles são usados para criar o canal criptografado que é usado para comunicações do cliente. Uma declaração digital é um certificado emitido por uma CA (autoridade de certificação) que assegura a identidade do proprietário do certificado e habilita as partes a se comunicarem seguramente usando criptografia.
Os certificados digitais fornecem os seguintes serviços:
- Criptografia: ajuda a proteger os dados trocados contra roubo ou adulteração.
- Autenticação: verifica se os proprietários (pessoas, sites e até mesmo dispositivos de rede, como roteadores) são, de fato, quem ou o que alegam ser. Normalmente, a autenticação é unidirecional, ou seja, a origem verifica a identidade do destino. Mas também existe a autenticação TLS mútua.
Um certificado contém uma chave pública e conecta essa chave pública à identidade de uma pessoa, computador ou serviço que contém a chave privada correspondente. As chaves públicas e privadas são usadas pelo cliente e pelo servidor para criptografar os dados antes de transmiti-los. Para usuários, computadores e serviços do Windows, a confiança na AC é estabelecida quando o certificado raiz é definido no repositório de certificados raiz confiáveis e o certificado contém um caminho de certificação válido. Um certificado será considerado válido se ele não tiver expirado e nem sido revogado, ou seja, inserido na CRL (lista de revogação de certificados) da AC.
Os três tipos principais de certificados digitais são descritos na seguinte tabela:
| Type | Descrição | Vantagens | Desvantagens |
|---|---|---|---|
| Certificado autoassinado | O certificado é assinado pelo aplicativo que o criou ou é criado usando New-SelfSignedCertificate. | Custo (gratuito) | – O certificado não tem automaticamente a confiança dos dispositivos móveis e computadores clientes. O certificado precisa ser adicionado manualmente ao repositório de certificados raiz confiáveis em todos os dispositivos e computadores clientes, mas nem todos os dispositivos móveis permitem alterações no repositório de certificados raiz confiáveis. – Nem todos os serviços funcionam com certificados autoassinados. – É difícil estabelecer uma infraestrutura para gerenciamento do ciclo de vida do certificado. Por exemplo, certificados autoassinados não podem ser revogados. |
| Certificado emitido por uma AC interna | O certificado é emitido por uma PKI (infraestrutura de chave pública) da sua organização. Um exemplo são os AD CS (Serviços de Certificados do Active Directory). Para obter mais informações, confira Visão geral dos Serviços de Certificados do Active Directory. | – Permite que as organizações emitam certificados próprios. – É mais barato que os certificados de uma AC comercial. |
– Maior complexidade para implantar e manter a PKI. – O certificado não tem automaticamente a confiança dos dispositivos móveis e computadores clientes. O certificado precisa ser adicionado manualmente ao repositório de certificados raiz confiáveis em todos os dispositivos e computadores clientes, mas nem todos os dispositivos móveis permitem alterações no repositório de certificados raiz confiáveis. |
| Certificado emitido por uma AC comercial | O certificado é comprado de uma AC comercial confiável. | A implantação de certificados é simplificada porque todos os clientes, dispositivos e servidores confiam automaticamente nos certificados. | Custo. Você precisa planejar com antecedência para minimizar o número de certificados necessários. |
Para provar que o titular de um certificado é quem alega ser, o certificado deve identificá-lo com precisão para outros clientes, dispositivos ou servidores. Os três métodos básicos para fazer isso são descritos na seguinte tabela:
| Método | Descrição | Vantagens | Desvantagens |
|---|---|---|---|
| Correspondência de entidade de certificado | O campo Entidade do certificado contém o CN (nome comum) do host. Por exemplo, o certificado que é emitido para www.contoso.com pode ser usado para o site https://www.contoso.com. |
– Compatível com todos os clientes, dispositivos e serviços. – Compartimentalização. Revogar o certificado de um host não afeta outros hosts. |
– Número de certificados necessários. Você só pode usar o certificado para o host especificado. Por exemplo, você não pode usar o certificado www.contoso.com para ftp.contoso.com, mesmo quando os serviços estão instalados no mesmo servidor.– Complexidade. Em um servidor Web, cada certificado exige uma associação de endereço IP própria. |
| Correspondência de SAN (nome alternativo da entidade) do certificado | Além do campo Entidade, o campo Nome Alternativo da Entidade do certificado contém uma lista com vários nomes de host. Por exemplo:www.contoso.comftp.contoso.comftp.eu.fabirkam.net |
– Conveniência. Você pode usar o mesmo certificado para vários hosts em vários domínios separados. – A maioria dos clientes, dispositivos e serviços dá suporte a certificados SAN. – Auditoria e segurança. Você sabe exatamente quais hosts são capazes de usar o certificado SAN. |
– Requer mais planejamento. Você precisa fornecer a lista de hosts ao criar o certificado. – Falta de compartimentalização. Não é possível revogar seletivamente os certificados de alguns dos hosts especificados sem afetar todos os hosts do certificado. |
| Correspondência de certificado curinga | O campo Entidade do certificado contém o nome comum como o caractere curinga (*) mais um domínio ou subdomínio. Por exemplo, *.contoso.com ou *.eu.contoso.com. O certificado curinga *.contoso.com pode ser usado para:www.contoso.comftp.contoso.commail.contoso.com |
Flexibilidade. Não é preciso fornecer uma lista de hosts ao solicitar o certificado e é possível usar o certificado em qualquer número de hosts de que você possa precisar no futuro. | – Você não pode usar certificados curinga com outros TLDs (domínios de nível superior). Por exemplo, você não pode usar o certificado curinga *.contoso.com para hosts *.contoso.net.– Você só pode usar certificados curinga para nomes de host no nível do curinga. Por exemplo, você não pode usar o certificado *.contoso.com para www.eu.contoso.com. E você também não pode usar o certificado *.eu.contoso.com para www.uk.eu.contoso.com.– Clientes, dispositivos, aplicativos ou serviços mais antigos podem não dar suporte a certificados curinga. – Os curingas não estão disponíveis com certificados EV (Validação Estendida). – Auditoria e controle rigorosos são necessários. Se o certificado curinga estiver comprometido, ele afetará todos os hostes do domínio especificado. |
Conteúdo relacionado
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de