Melhores Práticas SSL/TLS: Criptografia em Trânsito

Melhores Práticas SSL/TLS

Implementação segura de SSL/TLS é fundamental para proteger dados em trânsito contra interceptação, modificação e ataques man-in-the-middle que podem comprometer confidencialidade e integridade de comunicações sensíveis. Apesar de SSL/TLS ser amplamente adotado (praticamente todo site moderno usa HTTPS), muitas implementações ainda contêm vulnerabilidades decorrentes de configurações inadequadas - uso de versões obsoletas do protocolo (SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1) que foram oficialmente deprecadas por organismos como IETF e PCI-DSS devido a vulnerabilidades conhecidas como POODLE, BEAST e CRIME, cipher suites fracos ou quebrados como RC4, DES, 3DES e MD5 que podem ser atacados com recursos computacionais modernos, certificados com algoritmos de assinatura SHA-1 já considerados inseguros, falta de Perfect Forward Secrecy (PFS) que permite que tráfego capturado seja descriptografado retroativamente se a chave privada do servidor for comprometida no futuro, ausência de HSTS (HTTP Strict Transport Security) permitindo downgrade attacks onde atacante força conexão HTTP não criptografada, e certificate pinning inadequado ou ausente em aplicações móveis críticas permitindo interception via certificados maliciosos instalados no device. Configuração otimizada de SSL/TLS não apenas melhora security posture mas também impacta performance (handshakes TLS 1.3 são mais rápidos que TLS 1.2), compatibilidade (clientes muito antigos podem não suportar configurações modernas) e compliance (LGPD, GDPR, PCI-DSS exigem criptografia forte para dados em trânsito). Este artigo fornece guidelines técnicos detalhados para implementar SSL/TLS seguindo best practices da indústria, recomendações do NIST, Mozilla SSL Configuration Generator e OWASP.

Versões de Protocolo: TLS 1.2 e TLS 1.3

Desabilite completamente SSL 2.0, SSL 3.0, TLS 1.0 e TLS 1.1 em todos os servidores - essas versões possuem vulnerabilidades documentadas e não devem ser usadas mesmo para compatibilidade com clientes legados. Configure seu servidor web (nginx, Apache, IIS) ou load balancer (AWS ALB, Azure Application Gateway) para aceitar apenas TLS 1.2 e TLS 1.3. TLS 1.3, ratificado em 2018 como RFC 8446, oferece melhorias significativas sobre versões anteriores: handshake mais rápido (1-RTT ao invés de 2-RTT, com suporte a 0-RTT para resumed sessions), remoção de cipher suites inseguros (não suporta mais RSA key exchange, CBC mode ciphers, RC4, 3DES), forward secrecy obrigatória em todos os cipher suites, e encrypted handshake que oculta metadados de negociação do protocolo. No nginx, configure com "ssl_protocols TLSv1.2 TLSv1.3;". No Apache, "SSLProtocol -all +TLSv1.2 +TLSv1.3". AWS ALB permite selection de security policy que define protoclos e ciphers - escolha "ELBSecurityPolicy-TLS13-1-2-2021-06" para ambientes modernos ou "ELBSecurityPolicy-2016-08" se precisar suportar alguns clientes antigos. Monitore seus logs de acesso para identificar quantos clientes ainda usam TLS 1.0/1.1 - se o número for insignificante (menor que 0.1% do tráfego), você pode desabilitar sem impacto material. Para APIs B2B onde você controla ambos endpoints, exija TLS 1.3 exclusively. Lembre-se que versão do protocolo é negociada durante handshake - o servidor deve anunciar as versões suportadas e o cliente seleciona a mais alta que ele também suporta.

Cipher Suites: ECDHE e AES-GCM

Cipher suites definem os algoritmos usados para key exchange, autenticação, criptografia simétrica e HMAC durante uma conexão TLS - escolha inadequada pode comprometer toda a segurança da comunicação mesmo usando TLS 1.2+. Priorize cipher suites com ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) para key exchange pois oferece Perfect Forward Secrecy, e AES-GCM (Galois/Counter Mode) ou ChaCha20-Poly1305 para criptografia simétrica pois são AEAD (Authenticated Encryption with Associated Data) ciphers que garantem tanto confidencialidade quanto integridade. Exemplo de cipher suite segura: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ou TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256. Evite completamente: cipher suites com RC4 (vulnerável a biases estatísticos), export ciphers (limitados a 40 ou 56 bits por regulações antigas de exportação), NULL ciphers (sem criptografia), DES e 3DES (tamanho de bloco pequeno vulnerável a Sweet32), CBC mode em TLS 1.0-1.1 (vulnerável a BEAST e Lucky13), e RSA key exchange sem DHE/ECDHE (sem forward secrecy). No nginx, configure "ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';" e "ssl_prefer_server_ciphers on;" para forçar ordem do servidor. Use ferramentas como ssllabs.com/ssltest para validar sua configuração e obter rating A+. Para TLS 1.3, cipher suites são simplificadas e mais seguras por padrão (TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256).

HSTS: HTTP Strict Transport Security

HSTS é um mecanismo que instrui navegadores a sempre usar HTTPS para um domínio específico, prevenindo ataques de SSL stripping onde um man-in-the-middle força conexão HTTP não criptografada ao interceptar a primeira requisição antes do redirect 301 para HTTPS acontecer. Implemente HSTS adicionando header "Strict-Transport-Security" em todas as respostas HTTPS do seu servidor: "Strict-Transport-Security: max-age=31536000; includeSubDomains; preload". O parâmetro max-age (em segundos) define por quanto tempo o navegador deve lembrar de usar apenas HTTPS - 31536000 segundos = 1 ano é valor recomendado. "includeSubDomains" aplica a política a todos os subdomínios (use com cuidado pois você precisa garantir que TODOS os subdomínios suportam HTTPS). "preload" indica que você quer seu domínio incluído na HSTS preload list mantida por navegadores - uma lista hardcoded de domínios que devem sempre usar HTTPS mesmo na primeira visita antes de qualquer header HSTS ser recebido. Para ser incluído na preload list, submeta seu domínio em hstspreload.org após confirmar que: todo o site funciona perfeitamente em HTTPS, você tem certificado válido cobrindo domínio e subdomínios, redireciona todo tráfego HTTP para HTTPS, serve HSTS header em base domain com includeSubDomains e preload directives, e max-age maior ou igual a 31536000. IMPORTANTE: preload é decisão one-way - remover domínio da lista pode levar meses e quebrará acesso para usuários durante esse período se você não puder mais suportar HTTPS. No nginx: "add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload' always;". No Apache: "Header always set Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload'".

Certificate Pinning para Aplicações Críticas

Certificate pinning é técnica onde sua aplicação (especialmente mobile apps e APIs críticas) hardcode ou embute hash/fingerprint do certificado esperado do servidor, validando durante TLS handshake que o certificado apresentado corresponde ao pin armazenado - isso previne ataques onde atacante instala certificado malicioso no device da vítima (via malware ou acesso físico) e intercepta tráfego HTTPS que normalmente seria trusted pela cadeia de CAs padrão do sistema operacional. Há dois tipos de pinning: pin do certificado leaf (específico para aquele certificado, precisa ser atualizado quando certificado expira/renova), ou pin da CA pública/chave pública (mais flexível, permite rotação de certificados desde que assinados pela mesma CA). Implemente pinning em apps mobile usando frameworks nativos: iOS Network framework permite pinning via URLSessionDelegate callbacks, Android usa Network Security Configuration XML com elemento pin-set, React Native pode usar react-native-ssl-pinning library. Para APIs, considere mutual TLS (mTLS) onde cliente também apresenta certificado ao servidor, validado via pinning. CUIDADO: pinning incorreto pode quebrar sua aplicação se você perder acesso ao certificado pinned e não tiver mecanismo de fallback - implemente sempre: pin de backup (segundo certificado/CA válido), over-the-air pin updates, e período de grace antes de enforçar pins para permitir rollback em emergências. Use Public Key Pinning ao invés de Certificate Pinning quando possível (mais resiliente a renovações). Exemplo de configuração no Android com digest SHA-256 e hash base64 da public key. Ferramentas como openssl podem extrair public key hash de certificados para usar nos pins.

Perfect Forward Secrecy (PFS)

Perfect Forward Secrecy é propriedade criptográfica onde comprometimento da chave privada de longo prazo do servidor (private key do certificado SSL) não permite descriptografar sessões passadas que foram capturadas - isso é alcançado usando ephemeral keys geradas dinamicamente para cada sessão que são destruídas após uso. Sem PFS, se atacante captura todo tráfego criptografado (algo trivial com network taps) e anos depois consegue roubar sua private key (via breach, insider threat, court order), ele pode voltar nos pcaps armazenados e descriptografar TODAS as sessões históricas - um cenário conhecido como "retrospective decryption". PFS previne isso gerando session keys únicos através de algoritmos Diffie-Hellman que não dependem da private key do certificado para derivação - mesmo que a private key seja comprometida, session keys anteriores permanecem seguros pois foram gerados com componentes ephemeral que não existem mais. Para garantir PFS, use apenas cipher suites com DHE (Diffie-Hellman Ephemeral) ou ECDHE (Elliptic Curve DHE) no key exchange - evite RSA key exchange que não oferece PFS pois session key é encrypted com a public key do servidor e decrypted com private key. Em TLS 1.3, PFS é mandatório (todas as cipher suites usam ECDHE). Em TLS 1.2, configure servidor para preferir ECDHE ciphers sobre RSA. Valide com: openssl s_client -connect seusite.com:443 -cipher 'ECDHE' - se conectar com sucesso, PFS está funcionando. Benefício adicional de PFS é compliance - muitos frameworks (PCI-DSS, NIST) recomendam ou exigem PFS para proteção de dados sensíveis. Desvantagem: slight performance overhead pois DHE operations são computacionalmente mais caras que RSA, mas com hardware moderno (AES-NI, CPU crypto acceleration) impacto é negligível.