Criptografia em Trânsito

A Criptografia em Trânsito garante que os dados trocados entre um cliente e um servidor não possam ser lidos nem modificados enquanto atravessam a rede (Internet, LAN ou nuvem). Diferente da VPN (que protege a rede inteira), a criptografia em trânsito protege a conexão individual da aplicação.

1. Tríade de Estados dos Dados

A criptografia em trânsito é a primeira camada obrigatória — qualquer dado que sai de um host deve ser protegido contra escuta e adulteração.

2. TLS/SSL (Transport Layer Security)

O TLS (sucessor do SSL) é o protocolo padrão para a criptografia em trânsito na Internet.

• Ele reside entre a camada de Transporte (TCP) e a camada de Aplicação (RFC 8446 para TLS 1.3, RFC 5246 para TLS 1.2).
• O TLS provê as três bases da Segurança da Informação:
  1. Confidencialidade: Dados cifrados com cifras simétricas (AES, ChaCha20).
  2. Integridade: Mensagens protegidas com AEAD (AES-GCM, ChaCha20-Poly1305) — cipher e MAC combinados.
  3. Autenticação: O servidor prova que é ele mesmo através de um Certificado Digital assinado por uma CA.

Evolução SSL → TLS

3. O Processo de Handshake TLS

Antes de qualquer dado ser enviado, ocorre uma negociação complexa:

TLS 1.2 (handshake clássico, 2 RTT)

1. Client Hello: O navegador envia versões do TLS e cifras que suporta, além de extensions (SNI, ALPN, supported_groups).
2. Server Hello: O servidor escolhe a cifra e envia seu Certificado Digital.
3. Validação: O navegador verifica se o certificado foi emitido por uma Autoridade Certificadora (CA) confiável (Let's Encrypt, DigiCert, Sectigo).
4. Troca de Chaves: Cliente e servidor usam criptografia assimétrica (RSA, DHE, ECDHE) para concordar sobre uma chave de sessão simétrica.
5. Criptografia: O trânsito de dados começa usando a chave simétrica (AES-GCM).

TLS 1.3 (handshake otimizado, 1 RTT)

O TLS 1.3 reduz para um único RTT e remove algoritmos fracos (RSA key exchange, CBC mode, SHA-1, MD5). Suporta 0-RTT para conexões repetidas (com risco de replay attack).

Cliente                         Servidor
  |---- ClientHello + KeyShare -->|
  |                               |
  |<--- ServerHello + KeyShare ---|
  |<--- EncryptedExtensions ------|
  |<--- Certificate --------------|
  |<--- CertificateVerify --------|
  |<--- Finished -----------------|
  |---- Finished ---------------->|
  |---- Application Data -------->| (já cifrado)

4. Cipher Suites

A cipher suite é a combinação de algoritmos usados em uma conexão TLS. Formato TLS 1.2: TLS_Kx_Au_WITH_CIPHER_HASH. Exemplo: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.

5. Perfect Forward Secrecy (PFS)

A PFS garante que, mesmo se a chave privada do servidor for comprometida no futuro, sessões gravadas no passado não podem ser decifradas. Isso é obtido usando DHE ou ECDHE (Ephemeral Diffie-Hellman), onde a chave de sessão é gerada com parâmetros efêmeros descartados ao fim da conexão. O TLS 1.3 exige PFS em todas as conexões — sem ECDHE/DHE não há TLS 1.3.

6. Implementações Comuns

• HTTPS: HTTP sobre TLS (Porta 443, RFC 9110/9112).
• SMTPS / IMAPS / POP3S: Protocolos de e-mail sobre TLS (STARTTLS ou implícito).
• MQTTS: Protocolo IoT sobre TLS (porta 8883).
• LDAPS: Acesso a diretórios (Active Directory) sobre TLS (porta 636).
• FTPS: FTP sobre TLS (RFC 4217).
• DNS over TLS (DoT): porta 853, RFC 7858.
• DNS over HTTPS (DoH): RFC 8484.

7. IPSec (IP Security)

Para cifrar tráfego IP inteiro (não só aplicação), usa-se o IPSec (RFC 4301), composto por:

• AH (Authentication Header, RFC 4302): garante integridade e autenticidade; não cifra.
• ESP (Encapsulating Security Payload, RFC 4303): garante confidencialidade + integridade.
• IKE (Internet Key Exchange, RFC 7296): negocia chaves (IKEv2 é o padrão moderno).

Modos: Transport (cifra payload, mantém IP original — host-to-host) ou Tunnel (cifra pacote inteiro dentro de novo IP — VPN site-to-site).

8. SSH (Secure Shell)

O SSH (RFC 4251-4254) substituiu Telnet, RSH e FTP. Oferece:

• Autenticação por senha, chave pública (Ed25519 recomendada), ou certificado.
• Túneis port forward (local, remote, dynamic/SOCKS).
• SFTP e SCP para transferência segura de arquivos.
• Multiplexação de canais numa única sessão TCP.

# Geração de chave Ed25519 (recomendada)
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "user@host"

# Desabilitar algoritmos fracos no sshd_config
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

9. VPN Moderna

WireGuard (RFC draft, atual em 2024) é o estado-da-arte: código 4.000 linhas (vs 600.000 do OpenVPN+IPSec), uses apenas ChaCha20-Poly1305, Curve25519, BLAKE2s e HKDF.

10. Ataques contra Criptografia em Trânsito

11. Defesas Adicionais

• HSTS (HTTP Strict Transport Security, RFC 6797): Header HTTP que força o navegador a usar apenas HTTPS. Strict-Transport-Security: max-age=63072000; includeSubDomains; preload.
• Certificate Pinning: Aplicativos mobile embarcam hash da chave pública esperada, rejeitando certificados CA fraudulentos (até mesmo emitidos por CA legítima comprometida).
• Certificate Transparency (RFC 6962): Logs públicos de todos os certificados emitidos, permitindo detecção de emissões fraudulentas.
• OCSP Stapling: Servidor traz o status de revogação do certificado no handshake, evitando atraso e privacidade do OCSP lookup.
• Let's Encrypt / ACME (RFC 8555): CA gratuita e automatizada — responsável por mais de 50% dos certificados ativos na web.

Exemplo Nginx com TLS 1.3 e HSTS

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_tickets off;
    ssl_session_timeout 1d;
    ssl_session_cache shared:Moz:50m;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
}

12. Ferramentas de Diagnóstico

# Verificar cipher suites suportados por um servidor
nmap --script ssl-enum-ciphers -p 443 example.com

# Verificar conformidade TLS (qualidade nota A+)
openssl s_client -connect example.com:443 -tls1_3
testssl.sh https://example.com
sslyze --regular example.com

# Verificar certificado remotamente
echo | openssl s_client -showcerts -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -text

13. Conclusão

A criptografia em trânsito deixou de ser opcional — é obrigatória em qualquer arquitetura moderna. O TLS 1.3 é o estado-da-arte, mas a cadeia de confiança (PKI, CA, Certificate Transparency) e os mecanismos complementares (HSTS, Pinning, OCSP Stapling) são igualmente críticos. Em ambientes corporativos, deve-se configurar os servidores para aceitar apenas TLS 1.2 e TLS 1.3, desabilitar cipher suites com CBC, RSA estático e SHA-1, e monitorar ativamente a expiração de certificados (Let's Encrypt + renovação automática elimina a maior parte dos incidentes operacionais). Em ambientes cloud e microserviços, o padrão é mTLS (mutual TLS) automatizado por service mesh (Istio, Linkerd), garantindo que cada conexão East-West seja autenticada bilateralmente.