As transações que utilizam o ambiente virtual estão sempre suscetíveis a ameaças, colocando em risco a segurança das informações. E como forma de suprir esta necessidade de bloquear as ameaças virtuais, protocolos como o TLS (Transport Layer Security) são utilizados. Esses protocolos, assim como todos os mecanismos de segurança, devem ser mantidos atualizados para que vulnerabilidades sejam corrigidas e novas funcionalidades sejam introduzidas. No caso do TLS, é a IETF (Internet Engineering Task Force) que fica encarregada de estudar e sugerir estas modificações.

Esse grupo segue reunindo-se para terminar a criação da RFC (Request for Comments) da versão 1.3 do protocolo TLS, atualmente em sua versão de Rascunho e a comunidade começa conhecer as principais modificações realizadas em comparação com a versão 1.2. Falaremos aqui sobre alguns detalhes importantes definidos.

A Cloudflare, gigante do setor de Content Delivery Network, está ativamente inserida nesta etapa de evolução do protocolo e participou do 33C3 - 33º Chaos Communication Congress, ocorrido na última semana de 2016 na Alemanha, onde Nick Sullivan e Filippo Valsorda palestraram sobre o estado até então estabelecido.

Melhorias no estabelecimento da comunicação

Diversas alterações priorizaram a melhora da performance da comunicação, entre elas, uma permite que o número de passos (e consequentemente, o tempo) necessários para a troca de chaves seja reduzido, no melhor cenário, pela metade.

Novas funcionalidades

Retomada de uma sessão TLS anterior

Na versão 1.2 e anteriores, existe a possibilidade de o cliente reaproveitar uma sessão já negociada com o servidor. O cliente envia o ClientHello e o SessionTicket para o servidor. Se o servidor reconhecer o SessionTicket, ele irá decriptografa-lo para ler os dados contidos no ticket e ser capaz de reutilizar a chave já acordada anteriormente. O problema é que, no caso do comprometimento da chave utilizada pelo servidor para criptografar o SessionTicket, o atacante poderá ser capaz de obter a chave da comunicação e decriptografar de forma passiva toda a conversa cliente/servidor.

Para não depender do valor definido como tempo de vida da chave que criptografa o SessionTicket (onde é possível a ocorrência de erros de implementação), a versão 1.3 permite o uso do algoritmo Diffie-Hellman (ECDHE), introduzindo Forward Secrecy à retomada da sessão, desta vez sem o envio de certificado por parte do servidor. Forward Secrecy é uma propriedade de protocolos e significa que o vazamento de uma chave permanente não compromete a chave de sessões realizadas no passado.

0 Passos Adicionais

Quando há a retomada de uma sessão anterior, o TLS 1.3 permite que o pacote inicial carregue os dados necessários para o restabelecimento do túnel TLS juntamente com a requisição HTTP, eliminando o handshake adicional geralmente necessário por conta da negociação do túnel. O problema é que neste caso, só há Forward Secrecy a partir da resposta do servidor, o que deixa a requisição HTTP que foi enviada antes do fim da negociação do túnel TLS desprotegida contra um atacante que conseguir acesso à chave utilizada pelo servidor para criptografar o SessionTicket.

Além disso, este primeiro pacote passa a ser alvo de ataques de replay, mas para resolver este problema, definiu-se que tais requisições não devem ser permitidas para endereços perigosos como /envia_dinheiro.php?para=atacante&valor=1000. A aplicação fica responsável por determinar quais endereços podem ser acessados com a funcionalidade de 0 passos adicionais (0-RTT), definindo que os demais endereços sejam acessados através de 1-RTT. É importante notar que, caso esta lista de endereços não seja definida, a funcionalidade 0-RTT será desabilitada e todas as requisições serão feitas através de 1-RTT.

Funcionalidades removidas

Modo RSA estático

Este modo foi removido logo nas primeiras iterações do grupo de trabalho por não prover Forward Secrecy à comunicação. Devido ao pedido de uma instituição financeira que precisava ser capaz de decriptografar o conteúdo capturado de conexões de servidores em sua infraestrutura, foi criado como forma de contorno um documento informativo mostrando como utilizar uma chave Diffie-Hellman estática, o que permite que a instituição mantenha seu parque em funcionamento sem afetar o protocolo.

Cifras, Construções e Funcionalidades

Foram removidos ainda as seguintes cifras:

Foram removidas também as seguintes funcionalidades:

Por conta disso, o protocolo deixa de estar suscetível a diversas vulnerabilidades como:

A continuação de sessão tornou-se mais segura

Na versão 1.2 do TLS, devido aos dados que são compartilhados para a retomada de uma sessão, o comprometimento da chave utilizada na criptografia do SessionTicket pode resultar no comprometimento de todas as conexões, inclusive da primeira sessão (sessão original que mais tarde será utilizada para retomar a comunicação).

Nesta atualização, só serão afetadas as conexões secundárias (derivadas da sessão original através do mecanismo de retomada), e mesmo assim, apenas os dados HTTP pré-enviados no caso de 0 Passos Adicionais (0-RTT) citado acima.

Implementações

Até o presente momento, sabemos que algumas bibliotecas já permitem o uso do TLS 1.3. NSS, BoringSSL e WolfSSL já possuem suporte a algum dos drafts publicados. A equipe do OpenSSL planejava liberar uma versão em 5 de abril, mas resolveram esperar a IETF encerrar o estágio de Drafts e publicar a versão definitiva da RFC para incorporar o protocolo ao OpenSSL 1.1.1.

Além da NSS, membros da IETF criaram uma implementação na biblioteca crypto/tls da linguagem Go.

Para saber maiores detalhes, assista ao vídeo da palestra logo abaixo.