TLS 1.3

TLS 1.3 - O fim de um ciclo

Autor: Ailton Caetano, postado em 11/05/2017 as 15:15
Hashtags: #TLS, #Criptografia, #BlueTeam

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.


Estabelecimento de túnel no TLS 1.2
TLS 1.2 estabelecimento de tunel criptografado
Estabelecimento de túnel no TLS 1.3
      TLS 1.3 estabelecimento de tunel criptografado

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.


Um atacante passivo pode ler toda a conversa se tiver a chave que criptografou o SessionTicket
TLS 1.2 vulnerabilidade posse da chave
No TLS 1.3 podemos proteger o restante da conversa com Diffie-Hellman
      TLS 1.3 retomando a sessão com segurança

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.


TLS 1.3 0-RTT com ECDHE

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:

  • RC4
  • 3DES
  • MD5/SHA1
  • AES-CBC
  • RSA-PKCS1-1.5

Foram removidas também as seguintes funcionalidades:

  • Funcionalidade de Compressão
  • Renegociação

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

  • POODLE
  • FREAK
  • Sweet32
  • DROWN
  • CRIME
  • LogJam
  • BEAST
  • Lucky13, entre outros...

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.