O TLS 1.3 foi aprovado pela Internet Engineering Task Force (IETF). Ele contém “grandes melhorias nas áreas de segurança, desempenho e privacidade” e, ao contrário do TLS 1.2, parece haver uma motivação interna para atualização. O aumento de desempenho oferecido pelo TLS 1.3 por si só vai despertar o interesse de mais pessoas do que apenas profissionais de segurança.
Os benefícios que o TLS 1.3 oferece são substanciais; mas uma criptografia mais abrangente também torna mais difícil detectar tráfego malicioso e se defender contra ataques ocultos nesse tráfego criptografado. Esta é uma ameaça real: uma pesquisa recente do F5 Labs descobriu que 68% do malware se esconde na criptografia. Talvez seja necessário adotar uma nova abordagem para obter a visibilidade necessária e, ao mesmo tempo, preservar o ganho de desempenho obtido com o protocolo atualizado.
Os benefícios do TLS 1.3 são substanciais; mas uma criptografia mais abrangente também torna mais difícil detectar tráfego malicioso.
O TLS 1.3 oferece algumas grandes melhorias em relação ao TLS 1.2. Partes opcionais vulneráveis do protocolo foram removidas, há suporte para cifras mais fortes que são necessárias para implementar o sigilo de encaminhamento perfeito (PFS) e o processo de handshake foi significativamente encurtado.
Além disso, a implementação do TLS 1.3 deve ser relativamente simples. Você pode usar as mesmas chaves usadas para o TLS 1.2. Clientes e servidores negociarão automaticamente um handshake TLS 1.3 quando ambos oferecerem suporte a ele, e a maioria dos navegadores tradicionais faz isso por padrão nas versões mais recentes.
Embora o TLS 1.2 ainda possa ser implantado com segurança, diversas vulnerabilidades de alto perfil exploraram partes opcionais do protocolo e cifras desatualizadas. O TLS 1.3 remove muitas dessas opções problemáticas e inclui suporte apenas para algoritmos que atualmente não apresentam vulnerabilidades conhecidas.
O IETF optou por remover todas as cifras que não suportam PFS das conexões TLS, incluindo DES, AES-CBC, RC4 e outras cifras menos comumente usadas. Eles também removeram a capacidade de executar o que é conhecido como "renegociação", que permite que um cliente e um servidor que já tenham uma conexão TLS negociem novos parâmetros, gerem novas chaves e assim por diante. Eliminar a renegociação fecha uma janela de oportunidade para um ataque.
O TLS 1.3 também habilita o PFS por padrão. Essa técnica criptográfica adiciona outra camada de confidencialidade a uma sessão criptografada, garantindo que somente os dois terminais possam descriptografar o tráfego. Com o PFS, mesmo que um terceiro registre uma sessão criptografada e depois obtenha acesso à chave privada do servidor, ele não poderá usar essa chave para descriptografar a sessão.
Em termos de desempenho, o TLS 1.3 reduz uma viagem de ida e volta inteira do handshake de estabelecimento da conexão, o que reduz a latência da criptografia pela metade. Outra vantagem é que quando você acessa um site que já visitou, agora você pode enviar dados da primeira mensagem para o servidor. Isso é chamado de "tempo de ida e volta zero" (0-RTT). Essas melhorias, juntamente com algoritmos criptográficos modernos e eficientes, podem tornar o TLS 1.3 mais rápido que o TLS 1.2.
Com todos esses benefícios, qual poderia ser o problema? Que bom que você perguntou! Com o PFS, somente os endpoints (o usuário da web e o servidor de aplicativos) podem descriptografar o tráfego. No entanto, é provável que você tenha uma ou mais soluções — como um firewall de última geração, um sistema de detecção de intrusão (IDS) ou uma sandbox de malware — projetadas para detectar tráfego malicioso saindo da sua rede. Como alternativa, você pode ter um firewall de aplicativo da web, um IDS ou uma solução de análise na frente de um aplicativo que você hospeda. Todas essas soluções ficam entre o usuário e o aplicativo ou site ao qual ele está conectado, de modo que normalmente não conseguem detectar o tráfego criptografado.
Algumas ferramentas de inspeção de segurança têm a capacidade de descriptografar; no entanto, isso geralmente acarreta perdas de desempenho nas ferramentas e adiciona complexidade à arquitetura da sua rede. Além disso, descriptografar tudo às cegas pode introduzir violações de privacidade.
Vale mencionar que alguns especialistas em segurança estão indignados com o recurso 0-RTT, devido ao potencial de ataques de repetição. E sem o 0-RTT habilitado na configuração TLS, você pode perder a maior parte do aumento de desempenho que o motivou a implementar em primeiro lugar.
A decisão de implementar o TLS 1.3 neste momento dependerá de seus requisitos e motivações. Existem alguns navegadores que não suportam a versão 1.3, o que pode resultar em uma experiência ruim para o usuário. Além disso, se você remover recursos potencialmente vulneráveis, como renegociação, e usar o PFS para a configuração TLS 1.2 dos seus aplicativos, você obterá todos os mesmos benefícios de segurança e privacidade do TLS 1.3. Quanto a um possível aumento de desempenho, você deve realizar testes completos para ver se isso é verdade para seu aplicativo, pois pode não valer a pena o esforço com o 0-RTT desabilitado.
Seja qual for sua decisão, isso não significa que as versões anteriores do TLS desaparecerão tão cedo. O Google anunciou que descontinuará o TLS 1.0 e 1.1 até 2020, então o TLS 1.2 continuará existindo por um bom tempo. E, com exceção de algumas conexões de API ponto a ponto, você precisará continuar a oferecer suporte ao TLS 1.2 (e possivelmente 1.1) por algum tempo para garantir que não interrompa as conexões dos usuários com seus aplicativos.
Independentemente da sua versão do TLS, você precisa ter visibilidade das ameaças criptografadas para proteger seu negócio. Dispositivos de descriptografia baseados em SSL/TLS que permitem a inspeção de pacotes podem interceptar tráfego criptografado, descriptografar, inspecionar e criptografar novamente tráfego TLS não confiável que entra ou sai da rede, mas isso ainda não é suficiente.
Dispositivos de descriptografia baseados em SSL/TLS que permitem a inspeção de pacotes podem interceptar tráfego criptografado, descriptografar, inspecionar e criptografar novamente tráfego TLS não confiável que entra ou sai da rede, mas isso ainda não é suficiente.
As equipes de segurança e operações de rede descobriram que configurar zonas de descriptografia não é fácil. Muitas vezes, eles precisam recorrer ao encadeamento manual ou à configuração tediosa para gerenciar a descriptografia/criptografia em toda a pilha de segurança. E então eles descobrem que as exceções são abundantes.
O F5 SSL Orchestrator oferece visibilidade, mas se diferencia dos demais pela orquestração que fornece direcionamento de tráfego baseado em políticas para uma cadeia de serviços com base em riscos e condições dinâmicas de rede. Como funciona como um proxy completo para SSL/TLS e HTTP, o SSL Orchestrator pode tomar decisões inteligentes para direcionar o tráfego de entrada e saída para qualquer combinação de ferramentas de inspeção dentro da pilha de segurança.
Não importa quão complicados sejam seus requisitos de criptografia de entrada e saída, o SSL Orchestrator pode trazer visibilidade de volta às suas soluções de inspeção, o que ajuda a manter sua rede — e seus aplicativos — mais seguros.
Você não pode proteger o que não pode ver — entenda como os invasores usam criptografia para mascarar malware e exfiltração de dados e o que você pode fazer para bloqueá-los.
Obtenha insights sobre como e quando seus pares empresariais estão adotando a nova versão do protocolo TLS 1.3 e como você pode ser afetado pela falta de visibilidade do tráfego criptografado.
Descubra como identificar rapidamente ameaças ocultas e evitar ataques com total visibilidade e orquestração do seu tráfego criptografado.
Pronto para entender como identificar ameaças ocultas e prevenir ataques com o SSL Orchestrator?
Entre em contato com a F5 hoje mesmo.
