Versões do TLS, Conjuntos de Cifras e Sigilo de Encaminhamento Perfeito

TLS (Transport Layer Security) é o protocolo criptográfico que protege a maioria das comunicações na internet — HTTPS, SMTPS, IMAPS, LDAPS e VPNs dependem do TLS. O TLS oferece três propriedades de segurança: confidencialidade (a criptografia impede a interceptação), integridade (o MAC impede adulterações) e autenticação (os certificados verificam a identidade do servidor). O TLS evoluiu do SSL (Secure Sockets Layer), que agora está obsoleto. As versões atuais são TLS 1.2 (amplamente implantada) e TLS 1.3 (mais rápida e segura, recomendada para todas as novas implantações).

O TLS passou por várias versões, e as mais antigas continham vulnerabilidades críticas. SSL 2.0/3.0: obsoletos e vulneráveis aos ataques POODLE e DROWN. TLS 1.0: descontinuado pelo NIST e pelo PCI-DSS em 2020 (vulnerável ao BEAST e ao POODLE em cifras de bloco). TLS 1.1: descontinuado junto com o TLS 1.0. TLS 1.2: padrão mínimo atual; seguro quando configurado corretamente com conjuntos de cifras fortes. TLS 1.3: lançado em 2018; remove todos os algoritmos fracos, exige sigilo de encaminhamento, realiza um handshake significativamente mais rápido (1-RTT em vez de 2-RTT) e impede ataques de downgrade. O PCI-DSS 4.0 exige no mínimo TLS 1.2 e recomenda o TLS 1.3.

Um conjunto de cifras é um conjunto de algoritmos criptográficos usados em conjunto em uma sessão TLS. Cada conjunto de cifras especifica: um algoritmo de troca de chaves (como as chaves da sessão são estabelecidas), um algoritmo de autenticação (como o servidor é verificado), um algoritmo de criptografia em bloco (o que criptografa os dados) e um algoritmo de código de autenticação de mensagem (MAC) (como a integridade é verificada). O cliente e o servidor negociam qual conjunto de cifras usar durante o handshake do TLS — o servidor seleciona o conjunto mais forte compatível com ambas as partes.

A fase de troca de chaves estabelece a chave da sessão sem transmiti-la. Troca de chaves RSA (TLS 1.2): o cliente criptografa um segredo pré-mestre com a chave pública do servidor — se a chave privada for comprometida posteriormente, todas as sessões anteriores poderão ser descriptografadas. DHE (Diffie-Hellman Ephemeral): gera um novo par de chaves para cada sessão; oferece sigilo de encaminhamento, mas é lento. ECDHE (Elliptic Curve DHE): oferece o mesmo sigilo de encaminhamento que o DHE, mas com tamanhos de chave menores e melhor desempenho — é a troca de chaves preferida tanto no TLS 1.2 quanto no TLS 1.3. O TLS 1.3 exige ECDHE ou DHE, removendo completamente a troca de chaves RSA.

O sigilo de encaminhamento perfeito (PFS) garante que, mesmo que a chave privada de longo prazo do servidor seja comprometida posteriormente, as sessões gravadas anteriormente não poderão ser descriptografadas. O PFS é obtido com o uso de uma troca de chaves efêmeras (ECDHE ou DHE), na qual um novo par de chaves temporário é gerado para cada sessão e descartado após o uso. Sem PFS (troca de chaves RSA), um invasor pode gravar hoje todas as sessões TLS criptografadas e descriptografá-las retroativamente quando obtiver a chave privada. A estratégia de vigilância da NSA de “coletar agora, descriptografar depois” pressupõe que os alvos eventualmente atualizarão suas chaves para versões mais fortes ou que computadores quânticos quebrarão as chaves atuais.

Vários componentes legados de cifras estão quebrados do ponto de vista criptográfico e devem ser desativados. Cifras NULL: nenhuma criptografia. Cifras de nível de exportação (ataque FREAK): enfraquecidas deliberadamente para cumprir as regulamentações de exportação dos US na década de 1990. RC4: cifra de fluxo com vieses estatísticos explorados em ataques. DES e 3DES: cifras de bloco com tamanhos de bloco pequenos demais (ataque SWEET32) ou comprimentos de chave insuficientes. MD5 e SHA-1 para MACs: vulnerabilidades de colisão. Cifras anônimas (aNULL): nenhuma autenticação do servidor. As configurações modernas de TLS devem permitir apenas AES-GCM, ChaCha20-Poly1305, AES-CCM como cifras de bloco.

O TLS 1.3 oferece várias melhorias significativas de segurança em relação ao 1.2. PFS obrigatório: a troca de chaves RSA é removida — todas as sessões usam ECDHE ou DHE. Menos conjuntos de cifras: apenas 5 conjuntos de cifras AEAD são permitidos; não é possível negociar cifras fracas. Handshake mais rápido: uma viagem de ida e volta (1-RTT) em comparação com 2-RTT no TLS 1.2, e 0-RTT para retomada de sessão (embora o 0-RTT envolva considerações sobre ataques de repetição). Handshake criptografado: o certificado do servidor é criptografado durante o handshake, impedindo que observadores passivos identifiquem qual certificado — e, portanto, qual site — o cliente está acessando.

Ataques de downgrade induzem um servidor e um cliente TLS a usar uma versão do TLS ou um conjunto de cifras mais antigo e fraco do que aquele compatível com ambos. O POODLE (Padding Oracle On Downgraded Legacy Encryption) explorou o fato de que as implementações do TLS retornavam ao SSL 3.0 quando ocorriam erros de conexão. A mitigação foi desativar o SSL 3.0. O FREAK e o Logjam exploraram cifras de nível de exportação. TLS_FALLBACK_SCSV é um pseudo conjunto de cifras que os clientes incluem para indicar “esta não é minha versão preferida” — se um servidor o detectar e for compatível com uma versão superior, ele abortará a tentativa de downgrade.

A autenticação do servidor TLS depende da verificação, pelo cliente, da cadeia de certificados até uma CA raiz confiável. Verificações críticas: expiração (o certificado deve estar dentro do período de validade), revogação (a verificação por CRL ou OCSP confirma que o certificado não foi revogado), nome do host (SAN ou CN deve corresponder ao domínio ao qual a conexão é feita) e cadeia de assinaturas (as assinaturas da CA intermediária e da CA raiz são válidas). A Transparência de certificados (CT) exige que todos os certificados confiáveis publicamente sejam registrados em logs de CT somente para acréscimo, permitindo detectar certificados emitidos indevidamente poucos minutos após a emissão.

O Qualys SSL Labs (ssllabs.com/ssltest) é a ferramenta de referência para avaliar a configuração TLS de um servidor web. Ela classifica os servidores de A+ (excelente) a F (problemas críticos) com base em: versões do TLS compatíveis, força do conjunto de cifras, validade do certificado, configuração de HSTS, suporte a sigilo de encaminhamento e resistência a ataques conhecidos. Uma classificação A+ exige: somente TLS 1.2 ou superior, todas as cifras ECDHE, certificado válido e HSTS com pré-carregamento. As organizações devem executar testes do SSL Labs após a configuração inicial e novamente depois de qualquer alteração na pilha TLS. Muitas estruturas de conformidade (PCI-DSS) exigem avaliações periódicas da configuração TLS.

Certificados TLS expirados causam interrupções e avisos de confiança aos usuários, que os invasores exploram. O gerenciamento do ciclo de vida dos certificados envolve: manter o controle de todos os certificados em um inventário de certificados, configurar alertas de expiração com pelo menos 30 dias de antecedência, automatizar a renovação com o protocolo ACME (Let's Encrypt, Certbot), usar períodos de validade curtos para certificados (90 dias para certificados públicos) para reduzir a janela de risco decorrente de um comprometimento e usar certificados curinga (*.example.com) com cuidado, pois um certificado curinga comprometido afeta todos os subdomínios. As plataformas de gerenciamento de certificados (Venafi, DigiCert CertCentral) automatizam a descoberta e o ciclo de vida em grandes inventários de certificados.

Teste sua compreensão dos conceitos do CompTIA Security+ (SY0-701) abordados nesta lição.

Nesta lição, você aprendeu que: TLS 1.0/1.1 estão obsoletos e o TLS 1.2 é o padrão mínimo, enquanto o TLS 1.3 é preferível, com PFS obrigatório e handshakes criptografados; os conjuntos de cifras especificam a troca de chaves (prefira ECDHE), a criptografia em bloco (AES-GCM, ChaCha20) e os algoritmos MAC; e o sigilo de encaminhamento perfeito exige a troca de chaves efêmeras (DHE/ECDHE) para que as sessões anteriores não possam ser descriptografadas mesmo após o comprometimento da chave. A seguir, exploraremos o DNS seguro: DNSSEC e DNS sobre HTTPS.