Tópico 10 · Segurança de Transporte

Protocolos SSL e TLS

A camada de segurança da Internet: confidencialidade, integridade e autenticação — RFC 8446 (TLS 1.3)

Serviços de Redes

O que são SSL e TLS

O TLS (Transport Layer Security) é o protocolo que cifra e autentica a comunicação na Internet. É o "S" do HTTPS.

Confidencialidade: ninguém no caminho lê os dados.
Integridade: a adulteração é detectada.
Autenticação: você fala mesmo com o servidor pretendido.

SSL × TLS

O SSL (Secure Sockets Layer) foi o predecessor, criado pela Netscape nos anos 1990. O TLS é sua evolução padronizada pela IETF. Hoje, "SSL" é usado por hábito, mas o protocolo em uso é sempre o TLS — o SSL está obsoleto e inseguro.

Evolução: de SSL 2.0 a TLS 1.3

Versão	Ano	Situação
SSL 2.0	1995	Quebrado — banido.
SSL 3.0	1996	Inseguro (POODLE) — banido.
TLS 1.0	1999	Obsoleto (depreciado em 2021).
TLS 1.1	2006	Obsoleto (depreciado em 2021).
TLS 1.2	2008	Seguro e ainda amplamente usado.
TLS 1.3	2018	Atual — mais rápido e seguro.

Cada quebra histórica motivou uma nova versão; a tendência é remover algoritmos e recursos legados.

Onde o TLS se encaixa

O TLS fica entre a aplicação e o transporte: a aplicação enxerga um canal seguro; por baixo, é o TCP comum.

Dois subprotocolos principais: o Handshake negocia parâmetros e autentica; o Record cifra e transporta os dados da aplicação em registros.

HTTP + TLS = HTTPS. O QUIC (HTTP/3) integra o TLS 1.3 diretamente sobre UDP.

A engenharia: criptografia híbrida

O TLS combina o melhor dos dois mundos da criptografia, em duas fases:

1. Assimétrica (no handshake)

Uma troca (EC)DHE estabelece um segredo compartilhado, e a assinatura do certificado (RSA ou ECDSA) autentica o servidor. Caro, mas usado só no início.

2. Simétrica (nos dados)

A partir do segredo, derivam-se chaves para uma cifra AEAD rápida — AES-GCM ou ChaCha20-Poly1305 — que protege todo o tráfego.

Por quê? A criptografia assimétrica resolve a distribuição da chave sem canal seguro prévio; a simétrica entrega desempenho. O TLS usa cada uma onde ela é melhor.

Cipher suites: a "receita" da conexão

Uma cipher suite nomeia os algoritmos negociados. Compare as duas eras:

# TLS 1.2 — descreve cada componente
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
↑ troca de chave ↑ autenticação ↑ cifra ↑ hash

# TLS 1.3 — enxuta (só a cifra AEAD + hash)
TLS_AES_128_GCM_SHA256

No TLS 1.3 a troca de chave é sempre (EC)DHE efêmera e a autenticação vem do certificado — por isso não precisam constar no nome. Só a cifra de dados e o hash são listados.

O handshake do TLS 1.2 (2-RTT)

O cliente valida o certificado e ambos derivam as mesmas chaves de sessão.

O handshake do TLS 1.3 (1-RTT)

Mais rápido e com o handshake cifrado a partir do ServerHello — inclusive o certificado.

Certificados e a cadeia de confiança (PKI)

A autenticação do servidor repousa na PKI: um certificado X.509 liga uma chave pública a um nome de domínio, assinado por uma Autoridade Certificadora (CA).

O navegador confia em um conjunto de CAs-raiz.
Valida a cadeia: servidor → CA intermediária → raiz.
Verifica domínio, validade e revogação.

O que impede a falsificação

O servidor prova possuir a chave privada correspondente ao certificado (no TLS 1.3, via CertificateVerify). Sem ela, um impostor não conclui o handshake — mesmo tendo o certificado público.

SNI (Server Name Indication) informa, no ClientHello, qual site se quer — permitindo vários domínios HTTPS no mesmo IP.

Sigilo encaminhado (Forward Secrecy)

Com chaves efêmeras (EC)DHE, cada sessão usa um segredo descartável.

Se a chave privada de longo prazo do servidor vazar no futuro, as sessões passadas continuam seguras — pois as chaves de sessão não podem ser recalculadas.

Obrigatório no TLS 1.3

O TLS 1.3 exige troca de chave efêmera. O antigo modo "RSA key transport" (sem forward secrecy) foi removido: lá, capturar o tráfego e depois roubar a chave revelava tudo.

Por que o TLS 1.3 é melhor

Mais rápido

Handshake em 1-RTT (e 0-RTT na retomada), contra 2-RTT do 1.2.

Mais limpo e seguro

Removeu o que era fraco: RSA key transport, RC4, MD5/SHA-1, cifras CBC, compressão e renegociação. Só sobraram primitivas AEAD.

Handshake cifrado: a partir do ServerHello tudo é protegido — inclusive o certificado — reduzindo o que um espião consegue observar sobre a conexão.

Ataques históricos e lições

Ataque	Alvo	Lição
POODLE	SSL 3.0 (padding CBC)	Aposentar protocolos antigos.
BEAST	TLS 1.0 (CBC/IV)	Migrar para AEAD.
CRIME / BREACH	Compressão	Compressão + cifra vaza segredos.
Heartbleed	OpenSSL (implementação)	Bug de código, não do protocolo — atualizar bibliotecas.
DROWN	SSLv2 residual	Desativar versões legadas em todo lugar.
Downgrade	Negociação de versão	Forçar a versão mais alta; o 1.3 inclui proteção anti-downgrade.

Padrão recorrente: a maioria das quebras explorou algoritmos legados ou erros de implementação — não a ideia do TLS. Daí remover o legado e manter as bibliotecas atualizadas.

Boas práticas de implantação

Habilitar apenas TLS 1.2 e 1.3; desativar SSL e TLS 1.0/1.1.
Preferir cipher suites com forward secrecy e AEAD (AES-GCM, ChaCha20-Poly1305).
Usar HSTS para forçar HTTPS e evitar downgrade para HTTP.
Gerir o ciclo de vida dos certificados (validade curta, automação, ex.: ACME/Let's Encrypt).
Manter bibliotecas TLS atualizadas (lição do Heartbleed).

Síntese

Em resumo

O TLS (sucessor do SSL) cifra e autentica a comunicação via criptografia híbrida: um handshake assimétrico ((EC)DHE + certificado) estabelece chaves para uma cifra simétrica AEAD. Garante confidencialidade, integridade, autenticação e forward secrecy. O TLS 1.3 é mais rápido (1-RTT), com handshake cifrado e sem algoritmos legados. Suas falhas históricas vieram do legado e de bugs de implementação — não do desenho.

Voltar aos Tópicos