O Transport Layer Security (TLS) criptografa os dados enviados pela Internet para garantir que bisbilhoteiros e hackers não consigam ver o que você transmite, o que é particularmente útil para informações privadas e confidenciais, como senhas, números de cartão de crédito e correspondência pessoal. Este post explica o que é TLS, como funciona e por que você deve implantá-lo.
O que é TLS?
TLS é um protocolo criptográfico que fornece segurança de ponta a ponta de dados enviados entre aplicativos pela Internet. É mais familiar para os usuários por meio de seu uso em navegação segura na web e, em particular, o ícone de cadeado que aparece nos navegadores da web quando uma sessão segura é estabelecida. No entanto, pode e deve ser usado também para outras aplicações, como e-mail, transferência de arquivos, vídeo/audioconferência, mensagens instantâneas e voz sobre IP, bem como serviços de Internet como DNS e NTP.
TLS evoluiu de Secure Socket Layers (SSL), que foi originalmente desenvolvido pela Netscape Communications Corporation em 1994 para proteger sessões da web. O SSL 1.0 nunca foi lançado publicamente, enquanto o SSL 2.0 foi rapidamente substituído pelo SSL 3.0 no qual o TLS é baseado.
O TLS foi especificado pela primeira vez no RFC 2246 em 1999 como um protocolo independente de aplicativos e, embora não fosse diretamente interoperável com o SSL 3.0, oferecia um modo alternativo, se necessário. No entanto, o SSL 3.0 agora é considerado inseguro e foi preterido pela RFC 7568 em junho de 2015, com a recomendação de que o TLS 1.2 deve ser usado. O TLS 1.3 também está atualmente (em dezembro de 2015) em desenvolvimento e eliminará o suporte para algoritmos menos seguros.
Deve-se observar que o TLS não protege dados em sistemas finais. Ele simplesmente garante a entrega segura de dados pela Internet, evitando possíveis escutas e/ou alteração de conteúdo.
O TLS é normalmente implementado em cima do TCP para criptografar os protocolos da Camada de Aplicação, como HTTP, FTP, SMTP e IMAP, embora também possa ser implementado em UDP, DCCP e SCTP (por exemplo, para uso de aplicativos baseados em VPN e SIP) . Isso é conhecido como Datagram Transport Layer Security (DTLS) e é especificado nas RFCs 6347 , 5238 e 6083 .
Por que devo me preocupar com o TLS?
Historicamente, os dados foram transmitidos sem criptografia pela Internet e, onde a criptografia foi usada, ela foi normalmente empregada de forma fragmentada para informações confidenciais, como senhas ou detalhes de pagamento. Embora tenha sido reconhecido em 1996 (pela RFC 1984 ) que o crescimento da Internet exigiria a proteção de dados privados, tornou-se cada vez mais evidente ao longo do período intermediário que as capacidades de espiões e invasores são maiores e mais difundidas do que se pensava anteriormente . O IAB , portanto, divulgou uma declaração em novembro de 2014 convocando os projetistas, desenvolvedores e operadores de protocolos a tornar a criptografia a norma para o tráfego da Internet, o que significa essencialmente torná-la confidencial por padrão.
Sem o TLS, informações confidenciais como logins, detalhes de cartão de crédito e detalhes pessoais podem ser facilmente obtidas por outras pessoas, mas também hábitos de navegação, correspondência por e-mail, bate-papos on-line e chamadas em conferência podem ser monitorados. Ao permitir que aplicativos de cliente e servidor suportem TLS, ele garante que os dados transmitidos entre eles sejam criptografados com algoritmos seguros e não possam ser visualizados por terceiros.
Versões recentes de todos os principais navegadores da Web atualmente oferecem suporte a TLS, e é cada vez mais comum que os servidores da Web ofereçam suporte a TLS por padrão. No entanto, o uso de TLS para e-mail e alguns outros aplicativos ainda não é obrigatório e, ao contrário dos navegadores da Web que fornecem pistas visuais, nem sempre é aparente para os usuários se suas conexões são criptografadas.
Recomenda-se, portanto, que todos os clientes e servidores insistam na utilização obrigatória do TLS nas suas comunicações, preferencialmente da versão mais recente TLS 1.2. Para segurança completa, é necessário usá-lo em conjunto com uma infraestrutura de chave pública X.509 (PKI) publicamente confiável e, de preferência, DNSSEC, a fim de autenticar que um sistema ao qual uma conexão está sendo feita é realmente o que afirma ser ser.
Como funciona o TLS?
O TLS usa uma combinação de criptografia simétrica e assimétrica, pois oferece um bom compromisso entre desempenho e segurança ao transmitir dados com segurança.
Com a criptografia simétrica, os dados são criptografados e descriptografados com uma chave secreta conhecida tanto pelo remetente quanto pelo destinatário; normalmente 128, mas preferencialmente 256 bits de comprimento (qualquer coisa menor que 80 bits agora é considerada insegura). A criptografia simétrica é eficiente em termos de computação, mas ter uma chave secreta comum significa que ela precisa ser compartilhada de maneira segura.
A criptografia assimétrica usa pares de chaves – uma chave pública e uma chave privada. A chave pública é matematicamente relacionada com a chave privada, mas dado o comprimento de chave suficiente, é computacionalmente impraticável derivar a chave privada da chave pública. Isso permite que a chave pública do destinatário seja usada pelo remetente para criptografar os dados que deseja enviar a eles, mas esses dados só podem ser descriptografados com a chave privada do destinatário.
A vantagem da criptografia assimétrica é que o processo de compartilhamento de chaves de criptografia não precisa ser seguro, mas a relação matemática entre chaves públicas e privadas significa que são necessários tamanhos de chave muito maiores. O tamanho mínimo de chave recomendado é de 1.024 bits, com 2.048 bits preferidos, mas isso é até mil vezes mais computacionalmente intensivo do que as chaves simétricas de força equivalente (por exemplo, uma chave assimétrica de 2.048 bits é aproximadamente equivalente a uma chave simétrica de 112 bits) e torna a criptografia assimétrica muito lenta para muitos propósitos.
Por esse motivo, o TLS usa criptografia assimétrica para gerar e trocar com segurança uma chave de sessão. A chave de sessão é então usada para criptografar os dados transmitidos por uma parte e para descriptografar os dados recebidos na outra extremidade. Quando a sessão termina, a chave de sessão é descartada.
Uma variedade de diferentes métodos de geração e troca de chaves pode ser usada, incluindo RSA, Diffie-Hellman (DH), Ephemeral Diffie-Hellman (DHE), Elliptic Curve Diffie-Hellman (ECDH) e Ephemeral Elliptic Curve Diffie-Hellman (ECDHE). DHE e ECDHE também oferecem sigilo avançado pelo qual uma chave de sessão não será comprometida se uma das chaves privadas for obtida no futuro, embora a geração de números aleatórios fracos e/ou o uso de um intervalo limitado de números primos tenha sido postulado para permitir a quebra de até chaves DH de 1024 bits com recursos de computação em nível de estado. No entanto, isso pode ser considerado implementação em vez de problemas de protocolo, e há ferramentas disponíveis para testar conjuntos de cifras mais fracos.
Com o TLS, também é desejável que um cliente conectado a um servidor seja capaz de validar a propriedade da chave pública do servidor. Isso normalmente é feito usando um certificado digital X.509 emitido por um terceiro confiável, conhecido como Autoridade de Certificação (CA), que afirma a autenticidade da chave pública. Em alguns casos, um servidor pode usar um certificado autoassinado que precisa ser explicitamente confiável pelo cliente (os navegadores devem exibir um aviso quando um certificado não confiável for encontrado), mas isso pode ser aceitável em redes privadas e/ou onde o certificado seguro distribuição é possível. É altamente recomendável usar certificados emitidos por CAs publicamente confiáveis.
O que é uma CA?
Uma Autoridade Certificadora (CA) é uma entidade que emite certificados digitais em conformidade com o padrão X.509 da ITU-T para Infraestruturas de Chave Pública (PKIs) . Os certificados digitais certificam a chave pública do proprietário do certificado (conhecido como assunto) e que o proprietário controla o domínio protegido pelo certificado. Uma CA, portanto, atua como um terceiro confiável que fornece aos clientes (conhecidos como partes confiáveis) a garantia de que estão se conectando a um servidor operado por uma entidade validada.
Os próprios certificados de entidade final são validados por meio de uma cadeia de confiança originada de um certificado raiz, também conhecido como âncora de confiança. Com a criptografia assimétrica, é possível usar a chave privada do certificado raiz para assinar outros certificados, que podem ser validados usando a chave pública do certificado raiz e, portanto, herdar a confiança da CA emissora. Na prática, os certificados de entidade final geralmente são assinados por um ou mais certificados intermediários (às vezes conhecidos como subordinados ou sub-CAs), pois isso protege o certificado raiz no caso de um certificado de entidade final ser emitido incorretamente ou comprometido.
A confiança do certificado raiz é normalmente estabelecida por meio da distribuição física dos certificados raiz em sistemas operacionais ou navegadores. Os principais programas de certificação são executados pela Microsoft (Windows e Windows Phone), Apple (OSX e iOS) e Mozilla (Firefox e Linux) e exigem que as CAs cumpram requisitos técnicos rigorosos e preencham um WebTrust, ETSI EN 319 411-3 (anteriormente TS 102 042) ou auditoria ISO 21188:2006 para serem incluídos em suas distribuições. WebTrust é um programa desenvolvido pelo American Institute of Certified Public Accountants e pelo Canadian Institute of Chartered Accountants, ETSI é o Instituto Europeu de Padrões de Telecomunicações, enquanto ISO é a Organização Internacional de Padrões.
Os certificados raiz distribuídos com os principais sistemas operacionais e navegadores são considerados publicamente ou globalmente confiáveis e os requisitos técnicos e de auditoria significam essencialmente que as CAs emissoras são corporações multinacionais ou governos. Atualmente, existem cerca de cinquenta CAs publicamente confiáveis, embora a maioria/todos tenham mais de um certificado raiz, e a maioria também seja membro do CA/Browser Forum, que desenvolve diretrizes do setor para emissão e gerenciamento de certificados.
No entanto, também é possível estabelecer CAs privadas e estabelecer confiança por meio da distribuição e instalação seguras de certificados raiz em sistemas clientes. Exemplos incluem as CAs RPKI operadas pelos Registros Regionais de Internet ( AfriNIC , APNIC , ARIN , LACNIC e RIPE NCC ) que emitem certificados para Registros Locais de Internet atestando os endereços IP e números AS que eles possuem; bem como a International Grid Trust Federation (IGTF)que fornece uma âncora de confiança para emitir certificados de servidor e cliente usados por máquinas em computação científica distribuída. Nesses casos, os certificados raiz podem ser baixados e instalados com segurança de sites usando um certificado emitido por uma CA de confiança pública.
Um ponto fraco do sistema X.509 PKI é que terceiros (CAs) podem emitir certificados para qualquer domínio, independentemente de a entidade solicitante realmente possuí-lo ou controlá-lo. A validação é normalmente realizada por meio da validação de domínio – ou seja, enviando um e-mail com um link de autenticação para um endereço sabidamente responsável administrativamente pelo domínio. Geralmente, esse é um dos endereços de contato padrão, como ‘ hostmaster@domain’ ou o contato técnico listou um banco de dados WHOIS, mas isso o deixa aberto a ataques man-in-the-middle nos protocolos DNS ou BGP, ou mais simplesmente, usuários registrando endereços administrativos em domínios que não foram reservados. Talvez mais importante, os certificados de domínio validado (DV) não afirmam que um domínio tenha qualquer relacionamento com uma entidade legal, mesmo que um domínio pareça ter um.
Por esse motivo, as CAs estão incentivando cada vez mais o uso de certificados Organization Validated (OV) e Extended Validation (EV). Com certificados OV, a entidade solicitante está sujeita a verificações adicionais, como confirmação do nome da organização, endereço e número de telefone usando bancos de dados públicos. Com os certificados EV, há verificações adicionais sobre estabelecimento legal, localização física e identidade dos indivíduos que pretendem agir em nome da entidade solicitante.
Obviamente, isso ainda não impede que as CAs emitam certificados incorretos acidental ou fraudulentamente, e também houve incidentes de violações de segurança em que as CAs foram induzidas a emitir certificados falsos. Apesar do reforço substancial dos procedimentos de segurança na sequência de vários incidentes de alto perfil, o sistema continua dependente da confiança de terceiros, o que levou ao desenvolvimento do protocolo de autenticação de entidades nomeadas (DANE) baseado em DNS, conforme especificado em RFCs 6698 , 7671 , 7672 e 7673 .
Com o DANE, um administrador de domínio pode certificar suas chaves públicas armazenando-as no DNS ou, alternativamente, especificando quais certificados devem ser aceitos por um cliente. Isso requer o uso de DNSSEC, que afirma criptograficamente a validade dos registros DNS, embora o DNSSEC ainda não tenha uma implantação generalizada e os principais navegadores atualmente exijam a instalação de um complemento para oferecer suporte ao DANE. Além disso, DNSSEC e DANE ainda exigirão a validação dos detentores de domínio, que provavelmente terá de ser realizada por registros de domínio e/ou registradores em vez de CAs.
