Agora oficialmente: TLS 1.3 reconhecido como padrão

Escrevemos anteriormente que o Internet Engineering Council (IETF) aprovou uma nova versão do TLS - 1.3. Na semana passada, o protocolo foi reconhecido como padrão. Hoje - vamos falar sobre suas capacidades.


/ foto Charles Dyer CC

Recursos do TLS 1.3


Eles começaram a trabalhar na atualização do protocolo em 2014. Extra-oficialmente, o trabalho no TLS 1.3 terminou em março deste ano, mas os engenheiros precisaram de mais alguns meses para realizar verificações adicionais.

Os criadores afirmam que a versão final do TLS 1.3 é mais segura e produtiva: todas as vulnerabilidades conhecidas (hoje) do TLS 1.2 são fechadas em seus algoritmos de criptografia, e o processo de "handshake" é duas vezes mais rápido que seu antecessor. Os desenvolvedores também adicionaram sigilo e novos recursos, como 0-RTT.

O TLS 1.3 fez o maior número de mudanças significativas na história do protocolo. Por esse motivo, alguns até sugeriram chamá-lo de TLS 2.0.

Agora que a nova versão do protocolo TLS 1.3 ( RFC 8446 ) foi aprovada oficialmente, resta implementá-lo em todas as conexões de rede.

Dificuldades de implementação


O TLS tem um tipo de compatibilidade com versões anteriores. Quando uma conexão é estabelecida entre o cliente e o servidor, as versões suportadas do protocolo são trocadas e aquela com a qual os dois lados podem trabalhar é selecionada. No entanto, esse recurso não é usado em todos os lugares. Com o advento do TLS 1.3, mais de 3% dos servidores com suporte ao TLS 1.2 simplesmente desconectaram em vez de enviar ao cliente o número da versão suportada.

Ocorreu um problema semelhante com os nós intermediários ( caixa intermediária). Devido ao fato de o TLS não ter mudado muito, coisas como firewalls, NAT e balanceadores de carga se recusaram a trabalhar com a nova versão do protocolo.

Os engenheiros apelidaram esse fenômeno de ossificação (ossificação). O fato de alguns desenvolvedores não usarem os recursos flexíveis do protocolo dificulta a introdução de novas implementações. Como analogia, os participantes da indústria citam o exemplo da porta antiga. Se você não tocar por um longo tempo, os loops enferrujam e se abrem com um rangido.


/ foto Christopher Sessums CC

Acontece que o protocolo anterior está desatualizado, mas não funcionará para introduzir um novo por padrão. Mais sobre o assunto pode ser encontrado, por exemplo, no estudo do ano passado do IEEE ( PDF ).

A solução foi encontrada por David Benjamin, trabalhando no Chromium. Ele sugeriu disfarçar a primeira mensagem de um cliente que suporta o TLS 1.3 como uma mensagem TLS 1.2. E funcionou: os 3% mencionados dos servidores pararam de se desconectar. Para sites intermediários, Kyle Nekritz, do Facebook, sugeriu o uso da mesma abordagem. Isso reduziu o número de falhas em 6,5% no Chrome e em 2% no Firefox.

Para verificar se as caixas intermediárias são compatíveis com a nova versão do protocolo, você pode usar o teste desenvolvido no Cloudflare.

Como simplificar a implementação


Segundo Eric Rescorla, um dos desenvolvedores de especificações para TLS e HTTPS, em geral, implementar o TLS 1.3 não é tão difícil. O conselho de engenharia tentou tornar esse processo o mais simples possível. O TLS 1.3 usa as mesmas chaves e certificados que o TLS 1.2. Isso permite que o cliente e o servidor estabeleçam automaticamente uma conexão pelo TLS 1.3 se ambos suportarem a nova versão do protocolo.

Além disso, existem várias bibliotecas que podem ajudá-lo a implantar o protocolo mais rapidamente. Por exemplo, no início da semana passada, o Facebook transferiu sua biblioteca TLS 1.3 Fizz para código aberto . O Fizz reduz a latência na transmissão de dados, bem como a carga na CPU.

Os desenvolvedores prepararam um guia sobre como começar a usar o Fizz no Ubuntu 16.04 LTS. Está no repositório oficial do GitHub (também possui um guia para MacOS).

Primeiro, você precisa instalar as dependências necessárias de tolice e libsodium :

sudo apt-get install \ g++ \ cmake \ libboost-all-dev \ libevent-dev \ libdouble-conversion-dev \ libgoogle-glog-dev \ libgflags-dev \ libiberty-dev \ liblz4-dev \ liblzma-dev \ libsnappy-dev \ make \ zlib1g-dev \ binutils-dev \ libjemalloc-dev \ libssl-dev \ pkg-config \ libsodium-dev 

Em seguida, você precisa criar e instalar a loucura:

 git clone https://github.com/facebook/folly mkdir folly/build_ && cd folly/build_ cmake configure .. make -j $(nproc) sudo make install 

Depois, você pode instalar o Fizz:

 cd ../.. git clone https://github.com/facebookincubator/fizz mkdir fizz/build_ && cd fizz/build_ cmake configure ../fizz make -j $(nproc) sudo make install 

Além do Fizz, existem outras bibliotecas na rede, por exemplo, wolfSSL , GnuTLS ou rustls .

Protocolo futuro


Para finalmente resolver o problema com a "ossificação" do protocolo, David Benjamin propôs , além da versão oficial do padrão, usar algumas de suas variações, que serão lançadas a cada seis semanas (junto com o lançamento de novas versões do Chrome). Assim, será necessário que servidores e nós intermediários cumpram todas as regras para estabelecer uma conexão; caso contrário, a maioria dos clientes não poderá se conectar aos serviços.

Devido a isso, os desenvolvedores esperam evitar possíveis falhas no carregamento de páginas da Web, bem como problemas semelhantes com versões futuras do TLS.

A segurança geral da rede deve aumentar significativamente após a introdução do TLS 1.3. As bibliotecas que facilitam a implantação de uma nova versão do protocolo terão que contribuir para a distribuição em massa.



PS Outros materiais do nosso blog corporativo de IaaS:




O que fazemos no IT-GRAD - as principais áreas:

Infraestrutura virtual (IaaS) | Hospedagem PCI DSS | Cloud FZ-152

Source: https://habr.com/ru/post/pt420521/


All Articles