Qual é a diferença entre SSL e TLS?

Historicamente a mesma coisa. SSL era o nome da Netscape; O TLS é o sucessor padronizado pela IETF a partir de 1999. O uso coloquial moderno costuma chamar tudo de 'SSL', embora o TLS seja o protocolo real há mais de 25 anos. Todas as conexões web seguras atuais usam TLS 1.2 ou TLS 1.3.

Por que o TLS 1.3 é mais rápido?

Ele reduz o handshake de duas viagens de ida e volta para uma (1-RTT), enviando a chave pública DH do cliente na primeira mensagem e agrupando a resposta do servidor com todos os outros estados de handshake. A retomada da sessão pode até iniciar o envio de dados do aplicativo com a primeira mensagem (0-RTT). Em um link com latência de 100 ms, isso representa uma melhoria percebida de 200 ms na primeira conexão.

O TLS 1.2 ainda é seguro em 2026?

Sim, quando configurado corretamente: cifra AES-GCM ou ChaCha20-Poly1305, troca de chave ECDHE para sigilo de encaminhamento, sem cifras no modo CBC, sem RC4, sem fallback SSL 3.0. O TLS 1.3 remove totalmente o risco de configuração, excluindo as opções ruins.

O que é cliente criptografado Olá?

Uma extensão que criptografa o campo Server Name Indication (SNI) no handshake TLS. Sem ECH, sua rede pode ver todos os domínios que você visita, mesmo quando o restante da conexão está criptografado. A ECH (e a ESNI anterior) esconde esse último pedaço de metadados, completando a história de privacidade que o TLS iniciou em 1994.

O TLS é seguro para quantum?

Ainda não por padrão, mas em implementação. O Diffie-Hellman de curva elíptica padrão X25519 é teoricamente quebrável por um computador quântico grande o suficiente. O modo híbrido X25519MLKEM768 (padrão do Chrome desde o final de 2024, suporte crescente ao navegador) combina algoritmos clássicos e pós-quânticos para que o tráfego permaneça seguro mesmo contra futuros invasores quânticos.

TLS explicado: o protocolo por trás de cada ícone de cadeado

Transport Layer Security é a base criptográfica de HTTPS, e-mail moderno, VPNs, aplicativos de mensagens e a maior parte do tráfego da Internet em 2026. Começou como SSL da Netscape em 1994 e foi atualizado silenciosamente oito vezes desde então. Este é o explicador técnico – como funciona o handshake, o que o TLS 1.3 mudou, os ataques que o moldaram e para onde vai a seguir.

O corpo completo do artigo é fornecido em inglês abaixo.

SSL → TLS: a história cronológica

A Netscape Communications construiu a primeira implementação SSL em 1994 para proteger compras on-line no novíssimo navegador Netscape Navigator. O SSL 1.0 nunca foi lançado publicamente porque apresentava falhas críticas. O SSL 2.0 lançado em fevereiro de 1995 foi prontamente quebrado e o SSL 3.0 foi seguido em 1996 como uma reescrita quase total.

Em 1999, a IETF assumiu o protocolo e o renomeou como Transport Layer Security para marcar a transição de um produto Netscape para um padrão aberto. O histórico da versão desde:

TLS 1.0 (janeiro de 1999, RFC 2246) - essencialmente SSL 3.1.
TLS 1.1 (abril de 2006, RFC 4346) - protegido contra ataques CBC por meio de inicialização explícita vetores.
TLS 1.2 (agosto de 2008, RFC 5246) — adicionadas cifras AEAD, SHA-256, algoritmos de assinatura configuráveis. Dominado por uma década.
TLS 1.3 (agosto de 2018, RFC 8446) — grande reformulação. Remoção do legado legado, sigilo de encaminhamento obrigatório, latência de handshake reduzida.

SSL 3.0 foi formalmente obsoleto em junho de 2015 (RFC 7568) após POODLE. TLS 1.0 e 1.1 foram descontinuados em março de 2021 (RFC 8996). Em 2026, os servidores modernos deveriam recusar qualquer coisa abaixo do TLS 1.2 e preferir o TLS 1.3.

Como o handshake realmente funciona

Cada conexão TLS começa com um handshake que faz três coisas: concordar com um conjunto de criptografia, provar a identidade do servidor e derivar chaves compartilhadas para o resto da sessão.

TLS 1.2 handshake (o fluxo clássico)

ClientHello: o cliente envia versões TLS suportadas, conjuntos de criptografia e um número aleatório.
ServerHello: o servidor escolhe um conjunto de criptografia e envia seu aleatório número.
Certificate: o servidor envia sua cadeia de certificados X.509 para que o cliente possa verificar a identidade.
ServerKeyExchange: o servidor envia sua chave pública Diffie-Hellman (para chave efêmera exchange).
ClientKeyExchange: cliente envia sua chave pública DH. Ambos os lados agora derivam o mesmo segredo compartilhado.
Finished: ambos os lados confirmam o handshake enviando um MAC sobre toda a transcrição.

São duas viagens completas antes que o primeiro byte do aplicativo possa fluir. Em um link de latência de 100 ms, cada nova conexão HTTPS consome 200 ms antes de qualquer conteúdo real ser movido.

TLS 1.3 handshake (o fluxo moderno)

TLS 1.3 reduz o handshake para uma viagem de ida e volta no comum caso:

ClientHello: inclui a chave pública DH do cliente para cada grupo de cifras que o cliente suporta.
ServerHello + todo o resto: o servidor escolhe um grupo, envia sua chave pública DH, certificado e Concluído, tudo em um voo.
O cliente valida e responde com seu próprio Finalizado.

Uma viagem de ida e volta, dois voos. Com a retomada da sessão (0-RTT), o cliente pode até começar a enviar dados com sua primeira mensagem - ao custo de algumas propriedades de sigilo de encaminhamento para esses dados iniciais.

O que o TLS 1.3 removeu

TLS 1.3A outra grande mudança do 1.3 foi a exclusão. Foram eliminados:

Troca de chave RSA estática (quebrou o sigilo direto). Cifras de modo
CBC (vulneráveis a BEAST e Lucky Thirteen). assinaturas.
Renegociação (substituída por autenticação pós-handshake).
Compressão (classe de ataques CRIME).
Parâmetros Diffie-Hellman personalizados (correção de Logjam).

A lista de conjuntos de criptografia passou de ~ 300 no TLS 1.2 até 5 no TLS 1.3. Menos corda para se enforcar.

O histórico de ataque que moldou TLS

BEAST (2011) — ataque de texto simples escolhido no modo CBC no TLS 1.0. Corrigido em 1.1+ por meio de IVs explícitos.
CRIME (2012) — compactação TLS usada para recuperar cookies de sessão. Corrigido desativando a compactação.
BREACH (2013) — compactação em nível HTTP equivalente a CRIME. Mitigado pela desativação da compactação HTTP em respostas confidenciais.
Heartbleed (abril de 2014) — bug do OpenSSL, não um problema de especificação TLS. Vazamento de memória do servidor, incluindo chaves privadas. Evento de rotação de certificados em massa na web.
POODLE (outubro de 2014) — fallback SSL 3.0 explorado. Eliminou SSL 3.0 em navegadores em semanas.
Logjam (2015) — mostrou que pequenos grupos Diffie-Hellman (especialmente o Grupo 2 de 1024 bits amplamente usado em IPsec/IKE) estavam ao alcance de invasores de estados-nação. Migração forçada de todo o setor para grupos maiores e curva elíptica DH.
Lucky Thirteen (2013) — ataque de temporização no modo CBC. Correção em nível de biblioteca em OpenSSL e outros.

Cada ataque reforçou o protocolo. Pelo TLS 1.3, a maioria dessas classes é impossível por design.

Autoridades certificadoras e o problema de confiançaA autenticação

TLS depende de Autoridades de Certificação (CAs) nas quais os navegadores confiam por padrão. Os três primeiros por participação de mercado desde 2019: IdenTrust, DigiCert e Sectigo. Let's Encrypt — a CA gratuita e automatizada lançada em 2016 — impulsionou o maior impulso de adoção na história do HTTPS.

O ponto fraco estrutural: qualquer CA confiável pode emitir um certificado para qualquer domínio. Uma CA comprometida ou coagida pode emitir um certificado válido para o seu banco. Os logs Certificate Transparency (CT) — registros públicos somente anexados de cada certificado já emitido — foram introduzidos para detectar isso. Os navegadores agora exigem que os certificados apareçam nos logs de CT antes de aceitá-los.

O CA/Browser Forum aprovou a redução da validade máxima do certificado para 47 dias até 2029, diminuindo a janela durante a qual uma CA comprometida pode causar danos.

Cliente criptografado Olá (ECH)

Uma coisa clássica que vaza TLS: a indicação do nome do servidor (SNI) no ClientHello, que informa ao servidor a qual nome de host você está se conectando para que ele possa apresentar o certificado correto. SNI é texto simples, então os observadores da rede aprendem cada domínio que você visita, mesmo que o resto da conexão esteja criptografado.

Encrypted Client Hello (ECH) – uma evolução da proposta anterior da ESNI – criptografa o SNI usando uma chave pública que o destino publica via DNS. Cloudflare e Apple forneceram suporte ECH; Firefox e Chrome lançaram-no atrás de sinalizadores até 2024 e estão migrando para o padrão. Para usuários em redes hostis, ECH é a próxima atualização de privacidade depois do HTTPS universal.

DTLS — TLS para UDP

DTLS (Datagram TLS) é a variante TLS que funciona sobre UDP. Ele alimenta WebRTC (vídeo/voz do navegador), a segurança subjacente do QUIC e vários protocolos VPN. DTLS 1.3 (RFC 9147, 2022) corresponde ao handshake e modernizações de criptografia do TLS 1.3.

Post-quantum TLS

Diffie-Hellman key exchange - a base do sigilo direto do TLS - é quebrável por um computador quântico suficientemente grande. A solução é a troca de chaves híbridas combinando um algoritmo clássico (X25519) com um candidato pós-quântico (normalmente ML-KEM-768, anteriormente conhecido como Kyber).

Chrome habilitou o híbrido X25519MLKEM768 por padrão no final de 2024. Cloudflare, Apple iCloud e vários provedores de VPN o enviaram até 2025. A implementação mais ampla protege o tráfego de hoje contra o Ataque "colha agora, descriptografe depois" - um adversário registrando tráfego criptografado hoje, esperando por computadores quânticos e depois descriptografando historicamente.

Como verificar o TLS que seu navegador está realmente usando

Clique no cadeado na barra de endereço do seu navegador. Os navegadores modernos mostram a versão do protocolo, o conjunto de criptografia e os detalhes do certificado. Se você vir o TLS 1.0 ou 1.1, o site está usando configurações obsoletas. Se você vir TLS 1.3 com AES-256-GCM ou ChaCha20-Poly1305, você está na criptografia moderna.

A tecnologia complementar HTTPS – abordada em nosso explicador HTTPS – é o que envolve a web em TLS. Os dois termos são frequentemente usados de forma intercambiável coloquialmente, mas TLS é o protocolo criptográfico subjacente; HTTPS é apenas HTTP sobre TLS.

Perguntas frequentes

Qual é a diferença entre SSL e TLS?: Historicamente a mesma coisa. SSL era o nome da Netscape; O TLS é o sucessor padronizado pela IETF a partir de 1999. O uso coloquial moderno costuma chamar tudo de 'SSL', embora o TLS seja o protocolo real há mais de 25 anos. Todas as conexões web seguras atuais usam TLS 1.2 ou TLS 1.3.
Por que o TLS 1.3 é mais rápido?: Ele reduz o handshake de duas viagens de ida e volta para uma (1-RTT), enviando a chave pública DH do cliente na primeira mensagem e agrupando a resposta do servidor com todos os outros estados de handshake. A retomada da sessão pode até iniciar o envio de dados do aplicativo com a primeira mensagem (0-RTT). Em um link com latência de 100 ms, isso representa uma melhoria percebida de 200 ms na primeira conexão.
O TLS 1.2 ainda é seguro em 2026?: Sim, quando configurado corretamente: cifra AES-GCM ou ChaCha20-Poly1305, troca de chave ECDHE para sigilo de encaminhamento, sem cifras no modo CBC, sem RC4, sem fallback SSL 3.0. O TLS 1.3 remove totalmente o risco de configuração, excluindo as opções ruins.
O que é cliente criptografado Olá?: Uma extensão que criptografa o campo Server Name Indication (SNI) no handshake TLS. Sem ECH, sua rede pode ver todos os domínios que você visita, mesmo quando o restante da conexão está criptografado. A ECH (e a ESNI anterior) esconde esse último pedaço de metadados, completando a história de privacidade que o TLS iniciou em 1994.
O TLS é seguro para quantum?: Ainda não por padrão, mas em implementação. O Diffie-Hellman de curva elíptica padrão X25519 é teoricamente quebrável por um computador quântico grande o suficiente. O modo híbrido X25519MLKEM768 (padrão do Chrome desde o final de 2024, suporte crescente ao navegador) combina algoritmos clássicos e pós-quânticos para que o tráfego permaneça seguro mesmo contra futuros invasores quânticos.