Transport Layer Security

Esta página cita fontes, mas que não cobrem todo o conteúdo. Ajude a inserir referências (Encontre fontes: ABW  • CAPES  • Google (N • L • A)). (Dezembro de 2010)

O Transport Layer Security (TLS),^{[nota 1]} assim como o seu antecessor Secure Sockets Layer (SSL),^{[nota 2][1]} é um protocolo de segurança projetado para fornecer segurança nas comunicações sobre uma rede de computadores.^[2] Várias versões do protocolo encontram amplo uso em aplicativos como navegação na web, email, mensagens instantâneas e voz sobre IP (VoIP). Os sites podem usar o TLS para proteger todas as comunicações entre seus servidores e navegadores web.

O protocolo TLS visa principalmente fornecer privacidade e integridade de dados entre dois ou mais aplicativos de computador que se comunicam.^[2] Quando protegidos por TLS, conexões entre um cliente (por exemplo, um navegador da Web) e um servidor (por exemplo, wikipedia.org) devem ter uma ou mais das seguintes propriedades:

• A conexão é privada (ou segura) porque a criptografia simétrica é usada para criptografar os dados transmitidos. As chaves para essa criptografia simétrica são geradas exclusivamente para cada conexão e são baseadas em um segredo compartilhado que foi negociado no início da sessão (veja § Handshake TLS). O servidor e o cliente negociam os detalhes de qual algoritmo de criptografia e chaves criptográficas usar antes que o primeiro byte de dados seja transmitido (ver § Algoritmo abaixo). A negociação de um segredo compartilhado é segura (o segredo negociado não está disponível para bisbilhoteiros e não pode ser obtido, mesmo por um invasor que se coloque no meio da conexão) e confiável (nenhum invasor pode modificar as comunicações durante a negociação sem ser detectado).
• A identidade das partes em comunicação pode ser autenticada usando criptografia de chave pública. Essa autenticação pode ser opcional, mas geralmente é necessária para pelo menos uma das partes (geralmente o servidor).
• A conexão é confiável porque cada mensagem transmitida inclui uma verificação de integridade de mensagem usando um código de autenticação de mensagem para evitar perda não detectada ou alteração dos dados durante a transmissão.^[2]

Além das propriedades acima, a configuração cuidadosa do TLS pode fornecer propriedades adicionais relacionadas à privacidade, como sigilo de encaminhamento, garantindo que qualquer divulgação futura de chaves de criptografia não possa ser usada para descriptografar as comunicações TLS registradas no passado.^[3]

O TLS suporta muitos métodos diferentes para trocar chaves, criptografar dados e autenticar a integridade da mensagem (consulte § Algoritmo abaixo). Como resultado, a configuração segura do TLS envolve muitos parâmetros configuráveis ​​e nem todas as opções fornecem todas as propriedades relacionadas à privacidade descritas na lista acima (consulte § Troca de chave (autenticação), § Segurança de codificação e § Tabelas de integridade de dados).

Tentativas foram feitas para subverter aspectos da segurança das comunicações que o TLS procura fornecer, e o protocolo foi revisado várias vezes para lidar com essas ameaças de segurança (ver § Segurança). Os desenvolvedores de navegadores da Web também revisaram seus produtos para se defenderem de potenciais pontos fracos de segurança depois que eles foram descobertos (veja o histórico de suporte a TLS / SSL dos navegadores da Web).^[2]

O protocolo TLS compreende duas camadas: o registro TLS e os protocolos de handshake TLS.

O TLS é um padrão proposto pela IETF (Internet Engineering Task Force), definido pela primeira vez em 1999, e a versão atual é o TLS 1.3 definido no RFC 8446 (agosto de 2018). O TLS baseia-se nas especificações SSL anteriores (1994, 1995, 1996) desenvolvidas pela Netscape Communications^[4] para adicionar o protocolo HTTPS ao navegador da Web Navigator.

Aplicações cliente-servidor fazem uso do protocolo TLS para se comunicar através de uma rede de forma a prevenir a interceptação e adulteração da informação.

Uma vez que aplicações podem se comunicar tanto através de TLS (ou SSL) como sem ele, é necessário que o cliente sinalize ao servidor para a configuração de uma conexão TLS.^[5] Uma das maneiras de se obter isso é utilizar números de porta diferentes, por exemplo a porta 443 para HTTPS. Outro mecanismo é uma requisição específica por parte do cliente ao servidor para uma transição para a conexão TLS; por exemplo, ao fazer uma requisição STARTTLS ao utilizar protocolos de email.

Uma vez que o cliente e o servidor concordaram quanto ao uso do TLS, eles negociam uma conexão de estado por meio de um procedimento de handshake.^[6] Os protocolos utilizam um handshake com uma chave pública para estabelecer as configurações de criptografia e uma chave de sessão única compartilhada através da qual toda a comunicação é criptografada utilizando uma chave simétrica. Durante esse handshake, o cliente e o servidor concordam a respeito dos vários parâmetros necessários para estabelecer a segurança da conexão:

• O handshake é iniciado quando o cliente se conecta a um servidor habilitado para TLS requisitando uma conexão segura e apresentando uma lista de algoritmos suportados (cifras e funções hash).
• A partir dessa lista, o servidor seleciona uma cifra e uma função hash para as quais também tenha suporte e notifica ao cliente a decisão.
• O servidor então geralmente apresenta informações de identificação na forma de um certificado digital. O certificado contém o nome do servidor, a autoridade de certificação (CA) que concedeu o certificado, e a chave pública do servidor.
• O cliente confirma a validade do certificado antes de continuar.
• Para gerar as chaves de sessão utilizadas na conexão segura, o cliente:
  • criptografa um número aleatório com a chave pública recebida e envia o resultado ao servidor (o único capaz de descriptografar a mensagem com sua chave privada); ambas as partes então fazem uso do número aleatório para gerar uma chave de sessão única para a criptografia subsequente dos dados durante a sessão, ou
  • inicia uma troca de chaves de Diffie-Hellman para gerar seguramente uma chave de sessão aleatória e única, utilizada para criptografar e descriptografar os dados e que ainda possui a propriedade de foward secrecy: caso a chave privada do servidor seja vazada no futuro, ela é incapaz de descriptografar a sessão atual, mesmo que esta tenha sido interceptada e gravada por um terceiro.

Isso conclui o handshake e inicia a conexão segura, que é criptografada e descriptografada com a chave de sessão até o fim da conexão. Se qualquer um dos passos acima falhar, o handshake TLS também falha e a conexão não é criada.

Os protocolos TLS e SSL não se encaixam perfeitamente em nenhuma camada dos modelos OSI ou TCP/IP.^[7][8] O TLS é implementado "sobre um protocolo de comunicação confiável (por exemplo, o TCP)", o que implica que ele está acima da camada de transporte. Ele serve para criptografar as camadas superiores, o que normalmente seria função da camada de apresentação. Contudo, as aplicações geralmente fazem uso do TLS como se fosse uma camada de transporte,^[7][8] mesmo que essas aplicações devam controlar ativamente o início dos procedimentos de handshake e o gerenciamento dos certificados de autenticação compartilhados.^[2]

O servidor do site que está sendo acessado envia uma chave pública ao browser, usada por este para enviar uma chave secreta simetrica, criada aleatoriamente. Desta forma, fica estabelecida a troca de dados criptografados entre dois computadores.Baseia-se no protocolo TCP da suíte TCP/IP e utiliza-se do conceito introduzido por Diffie-Hellman nos anos 70 (criptografia de chave pública) e Phil Zimmermann (criador do conceito PGP).

A primeira versão foi desenvolvida pela Netscape em 1994. O SSL versão 3.0 foi lançado em 1996, e serviu posteriormente de base para o desenvolvimento do TLS versão 1.0, um protocolo padronizado da IETF originalmente definido pelo RFC 2246. Grandes instituições financeiras como Visa, MasterCard, American Express, dentre outras, aprovaram o SSL para comércio eletrônico seguro na Internet.O SSL opera de forma modular, possui design extensível e apresenta compatibilidade entre pares com versões diferentes do mesmo.O SSL executa a autenticação das 2 partes envolvidas nas comunicações (cliente e servidor) baseando-se em certificados digitais.

O TLS passou por várias versões ao longo dos anos, cada uma trazendo melhorias em segurança e desempenho. Aqui está um resumo das principais versões e suas novidades:

• TLS 1.0 (1999): Essa foi a primeira versão do TLS, projetada como uma atualização segura do SSL 3.0. Apesar de aprimorar a segurança, ela ainda tinha algumas vulnerabilidades e foi amplamente usada até ser considerada insegura para contextos modernos.

• TLS 1.1 (2006): Trouxe melhorias na segurança, como a proteção contra ataques de injeção de IV (Initialization Vector), mas ainda apresentava falhas em alguns aspectos, sendo logo substituída em favor de uma versão mais segura.

• TLS 1.2 (2008): Esta versão trouxe melhorias significativas, com suporte para algoritmos de criptografia mais fortes, como SHA-256, e mais flexibilidade nas suítes de criptografia, além de ser resistente a vários tipos de ataques conhecidos na época. Até hoje, é uma das versões mais amplamente utilizadas, embora a adoção do TLS 1.3 esteja crescendo.

• TLS 1.3 (2018): A versão mais recente, o TLS 1.3, removeu algoritmos obsoletos e inseguros, simplificou o processo de handshake (tornando a conexão mais rápida e segura) e aumentou a privacidade dos dados. Além disso, o TLS 1.3 permite menos idas e vindas entre o cliente e o servidor, reduzindo a latência e melhorando a eficiência.

Ataques significativos contra TLS/SSL estão listados abaixo.

Em fevereiro de 2015, a IETF emitiu um informativo RFC^[9] resumindo os vários ataques conhecidos contra TLS/SSL.

A Apple corrigiu a vulnerabilidade BEAST implementando a divisão 1/n-1 e ativando-a por padrão no OS X Mavericks, lançado em 22 de outubro de 2013.^[10]

A falha POODLE (Padding Oracle On Downgraded Legacy Encryption) é uma vulnerabilidade descoberta em 2014 que afeta o protocolo SSL 3.0, mas também impacta o TLS nas versões até o TLS 1.1. Para mitigar o POODLE, a recomendação foi desabilitar o suporte ao SSL 3.0 nos servidores e nos navegadores.^[11]