Em setembro de 2026, quase toda a internet fala TLS 1.3. Mas “quase toda” não é “toda”, e a diferença entre as três versões do protocolo que ainda circulam em produção, TLS 1.3, TLS 1.2 e o par obsoleto TLS 1.0/1.1, continua a definir se um site é rápido e seguro ou um alvo fácil. A IETF já mandou desligar as versões antigas há cinco anos. Ainda assim, equipas de TI adiam a migração por medo de quebrar clientes legados, e bancos, seguradoras e operadoras continuam a explicar aos auditores porque um sistema interno ainda aceita um protocolo de 1999. Este artigo compara as três gerações de TLS lado a lado: segurança, velocidade de handshake, adoção real, custo de certificados e um guia prático de migração.
O que é o TLS e porque a versão do protocolo importa
TLS (Transport Layer Security) é o protocolo que cifra a ligação entre o browser e o servidor, o mesmo que mostra o cadeado ao lado do endereço. Sem ele, qualquer pessoa na mesma rede Wi-Fi consegue ler passwords, números de cartão ou mensagens em texto simples. O protocolo já passou por quatro versões principais desde 1999: TLS 1.0, TLS 1.1, TLS 1.2 e TLS 1.3. Cada versão nova corrige falhas da anterior e remove algoritmos que deixaram de ser seguros.
A confusão nasce porque as quatro versões continuam tecnicamente disponíveis em muitos servidores, mesmo depois de a IETF ter publicado a RFC 8996 em 2021 a proibir formalmente o uso de TLS 1.0 e TLS 1.1. A norma é direta: “TLS 1.0 MUST NOT be used”, lê-se no texto oficial. Já o TLS 1.2, apesar de mais antigo que o TLS 1.3, não foi banido, e continua a ser aceite como piso de compatibilidade em muitos ambientes empresariais. Perceber a diferença entre “proibido”, “tolerado” e “recomendado” é o primeiro passo antes de decidir o que desligar num servidor de produção.
TLS 1.0 e TLS 1.1: as versões que a IETF já baniu
O TLS 1.0 nasceu em 1999 como a RFC 2246, sucessor direto do SSL 3.0. O TLS 1.1 chegou em 2006, com a RFC 4346, e tentou corrigir alguns dos problemas do vetor de inicialização (IV) que tornavam o TLS 1.0 vulnerável ao ataque BEAST. Nenhuma das duas versões sobreviveu ao escrutínio da década seguinte. Ambas dependem de cifras em modo CBC com falhas conhecidas, aceitam algoritmos de hash como MD5 e SHA-1, e em muitas implementações antigas ainda toleravam RC4, um cifrador de fluxo considerado quebrado.
A RFC 8996, publicada pela IETF, fecha o assunto sem margem para interpretação: “TLS 1.1 MUST NOT be used.” O mesmo documento acrescenta que “qualquer outra versão do TLS é mais segura que o TLS 1.0”. Google Chrome, Mozilla Firefox, Microsoft Edge e Safari desativaram o suporte por omissão a estas duas versões em 2020, o que significa que, na prática, um utilizador comum já não consegue abrir um site que dependa exclusivamente de TLS 1.0 ou TLS 1.1 sem alterar configurações avançadas do browser. Segundo dados da TechnologyChecker referentes a julho de 2026, o TLS 1.0 representa apenas 0,01% do tráfego humano medido na web, um valor residual que confirma o sucesso da retirada coordenada.
Os setores onde o TLS 1.0/1.1 ainda persiste, mesmo depois da proibição formal, tendem a ser os mesmos de sempre: máquinas industriais com ciclos de substituição de dez ou vinte anos, equipamento médico certificado que não pode ser alterado sem recertificação regulatória, e caixas multibanco ou terminais de pagamento mais antigos ainda em circulação em zonas rurais. Nenhum destes casos justifica expor o protocolo à internet pública. A resposta técnica correta é isolar o dispositivo numa rede segmentada, sem acesso direto, e tratar a atualização do próprio equipamento como prioridade de médio prazo, não como algo a adiar indefinidamente.
TLS 1.2: o piso de compatibilidade que ainda domina alguns setores
O TLS 1.2 chegou em 2008, com a RFC 5246, e foi durante uma década o padrão de facto da internet. Ao contrário do TLS 1.0/1.1, nunca foi formalmente descontinuado pela IETF. É por isso que continua vivo em sistemas de pagamentos, terminais de ponto de venda, dispositivos IoT industriais e APIs internas de empresas que não conseguem atualizar toda a cadeia de fornecedores de uma vez.
A força do TLS 1.2 está na flexibilidade, mas essa flexibilidade também é o problema. O protocolo permite dezenas de conjuntos de cifras, desde combinações modernas como TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 até opções obsoletas com 3DES ou troca de chaves RSA estática, que não oferece sigilo de encaminhamento (forward secrecy). Configurado corretamente, com ECDHE para troca de chaves e AES-GCM ou ChaCha20-Poly1305 como cifra, o TLS 1.2 continua a ser considerado seguro pelo guia de boas práticas da OWASP, que recomenda que “aplicações web devem usar TLS 1.3 por omissão e podem suportar TLS 1.2 para compatibilidade”. Mal configurado, com cifras CBC antigas ou RSA estático, arrasta consigo os mesmos riscos que levaram o TLS 1.0 a ser banido.
TLS 1.3: o que mudou na versão atual do protocolo
O TLS 1.3, definido na RFC 8446 e publicado em 2018, não é um ajuste incremental. É uma reescrita que elimina praticamente tudo o que os investigadores de segurança passaram uma década a atacar. Desapareceram MD5, SHA-1, RC4, DES e 3DES da lista de algoritmos permitidos. O protocolo já não aceita compressão (que abriu a porta ao ataque CRIME) nem renegociação a meio da sessão. O conjunto de cifras ficou reduzido a um núcleo pequeno, todo baseado em AEAD: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 e TLS_CHACHA20_POLY1305_SHA256 são as três opções mais usadas.
A mudança mais visível para quem usa a internet no dia a dia é a velocidade. O TLS 1.3 reduziu o handshake completo de dois round trips (2-RTT) para apenas um (1-RTT), e introduziu um modo opcional de 0-RTT para ligações retomadas, que elimina praticamente toda a espera antes de a aplicação poder enviar dados. Também tornou o sigilo de encaminhamento obrigatório em todas as ligações, algo que no TLS 1.2 dependia da configuração escolhida pelo administrador do servidor. Segundo o NCSC britânico, o TLS 1.3 é atualmente a única versão do protocolo com um caminho definido para integrar criptografia pós-quântica.
Tabela comparativa: TLS 1.3 vs TLS 1.2 vs TLS 1.0/1.1
A tabela seguinte resume as diferenças técnicas mais relevantes entre as três gerações do protocolo, da criptografia permitida ao estado atual junto dos organismos de normalização.
| Característica | TLS 1.3 | TLS 1.2 | TLS 1.0 / TLS 1.1 |
|---|---|---|---|
| Ano de publicação | 2018 | 2008 | 1999 / 2006 |
| RFC de referência | RFC 8446 | RFC 5246 | RFC 2246 / RFC 4346 |
| Handshake completo | 1 RTT | 2 RTT | 2 RTT |
| Modo 0-RTT | Sim, com risco de repetição | Não | Não |
| Conjuntos de cifras | 5 suites AEAD apenas | Dezenas, incluindo CBC e 3DES | CBC, 3DES, RC4 em implementações antigas |
| Sigilo de encaminhamento | Obrigatório | Opcional (requer ECDHE/DHE) | Normalmente ausente |
| Algoritmos de hash | SHA-256 / SHA-384 apenas | Permite SHA-1, ainda usado em legado | Permite MD5 e SHA-1 |
| Compressão da sessão | Removida | Desaconselhada | Presente em implementações antigas |
| Estado junto da IETF | Recomendado | Permitido, não recomendado para novos sistemas | Proibido (RFC 8996, 2021) |
| Suporte em browsers modernos | Total desde 2018-2020 | Total | Desativado por omissão desde 2020 |
| Adoção estimada na web (2026) | 68% a 76% das páginas | 6% a 15% do tráfego | 0,01% do tráfego humano |
| Exigido pela PCI DSS | Recomendado | Mínimo aceite desde 2018 | Proibido desde 30 de junho de 2018 |
| Caminho para pós-quântico | Sim, único com suporte previsto | Não | Não |
Desempenho: quanto tempo poupa o handshake do TLS 1.3
A poupança de um round trip parece pequena, mas soma-se rápido em ligações móveis ou distantes do servidor. Um relatório da Cloudflare, publicado em setembro de 2026, mediu que 99,2% das ligações TLS 1.3 com suporte a criptografia pós-quântica no seu conjunto de dados foram concluídas num único round trip, confirmando na prática o que a especificação promete no papel. O TLS 1.2 e o par TLS 1.0/1.1 mantêm-se presos aos dois round trips do handshake tradicional, salvo quando a sessão é retomada por outros mecanismos de cache.
Para dar sentido prático a estes números, a tabela abaixo mostra o tempo estimado de handshake em diferentes latências de rede, calculado apenas a partir do número de round trips, sem contar processamento do servidor. São valores ilustrativos, não uma medição de laboratório, mas ajudam a perceber o impacto acumulado em utilizadores com ligações mais lentas.
| Latência de rede (RTT) | TLS 1.3 (1 RTT) | TLS 1.2 / 1.0 / 1.1 (2 RTT) | Poupança |
|---|---|---|---|
| 20 ms (fibra, mesma região) | 20 ms | 40 ms | 20 ms |
| 60 ms (4G europeu típico) | 60 ms | 120 ms | 60 ms |
| 100 ms (ligação intercontinental) | 100 ms | 200 ms | 100 ms |
| 200 ms (rede móvel congestionada) | 200 ms | 400 ms | 200 ms |
Vale a pena notar duas ressalvas técnicas antes de tirar conclusões definitivas. Primeiro, o TLS 1.2 também suporta retoma de sessão, o que reduz o custo do handshake para visitantes que já ligaram antes, por isso comparar apenas handshakes completos exagera a diferença para tráfego recorrente. Segundo, o HTTP/3 e o QUIC já integram o TLS 1.3 de raiz, o que reduz ainda mais a latência de estabelecimento de ligação, mas isso mistura a camada de transporte com a camada de segurança e não deve ser confundido com uma medição isolada do protocolo TLS.
Segurança: cifras permitidas e vulnerabilidades históricas
A diferença de segurança entre as três gerações não é teórica, tem nomes de ataques concretos. O BEAST, identificado como CVE-2011-3389 e divulgado em 2011, explorou o modo CBC do TLS 1.0 através de um vetor de inicialização previsível, permitindo a um atacante decifrar partes de uma sessão HTTPS em condições específicas de navegador. O ataque empurrou a indústria a migrar para o TLS 1.2 com conjuntos de cifras AEAD.
Já o POODLE, catalogado como CVE-2014-3566 e revelado em outubro de 2014, atingiu diretamente o SSL 3.0, não o TLS 1.0, mas teve um efeito colateral importante: mostrou como o mecanismo de downgrade entre versões podia ser abusado para forçar uma ligação a cair para a versão mais fraca disponível. Esse episódio acelerou a retirada de protocolos legados em toda a indústria, incluindo o TLS 1.0, mesmo sem ser tecnicamente uma falha do TLS. O TLS 1.3 elimina esse vetor de ataque ao remover a negociação de downgrade insegura e ao recusar qualquer conjunto de cifras que não seja AEAD.
Do lado das cifras permitidas, a diferença é gritante. O TLS 1.2 continua a aceitar, dependendo da configuração do servidor, suites como TLS_RSA_WITH_AES_128_CBC_SHA256 ou variantes com 3DES, que não oferecem sigilo de encaminhamento. O TLS 1.0 e o TLS 1.1 vão mais longe e, em implementações antigas, ainda toleram TLS_RSA_WITH_RC4_128_SHA, uma cifra que deixou de ser considerada segura há mais de uma década. O TLS 1.3 fecha essa porta: só aceita cinco conjuntos de cifras, todos com autenticação de dados (AEAD) e todos com troca de chaves efémera obrigatória.
Como verificar em segundos que versão de TLS um site usa
Não é preciso confiar apenas na documentação do fornecedor para saber que protocolo está realmente ativo num servidor. A forma mais rápida de confirmar é a linha de comandos, com o OpenSSL instalado em praticamente qualquer sistema Linux ou macOS. O comando abaixo força uma ligação usando apenas TLS 1.3 e mostra de imediato se o servidor aceita ou recusa essa versão.
openssl s_client -connect exemplo.pt:443 -tls1_3
# Para testar se o servidor ainda aceita TLS 1.0 (deveria falhar)
openssl s_client -connect exemplo.pt:443 -tls1
# Para listar todas as cifras negociáveis num único pedido
nmap --script ssl-enum-ciphers -p 443 exemplo.ptSe o segundo comando, o que força TLS 1.0, conseguir estabelecer ligação, é sinal de que o servidor ainda tem uma versão proibida pela RFC 8996 ativa e precisa de correção imediata. Para quem prefere uma interface gráfica, o SSL Labs da Qualys continua a ser a referência: além de mostrar as versões suportadas, atribui uma nota de A a F com base na configuração completa, incluindo o comprimento das chaves, a presença de sigilo de encaminhamento e eventuais vulnerabilidades conhecidas ainda expostas. Ferramentas como o Nmap, já usadas por equipas de segurança para auditar redes internas, também têm scripts dedicados à enumeração de cifras TLS, úteis para verificar servidores que não estão expostos publicamente e por isso não aparecem no SSL Labs.
Vale a pena repetir este teste depois de qualquer alteração de infraestrutura, incluindo trocas de balanceador de carga, migração para um novo CDN ou atualização de uma imagem de contentor. É comum que uma migração para uma nova versão de biblioteca reative acidentalmente cifras antigas que a configuração anterior já tinha bloqueado, sobretudo quando os valores por omissão do sistema operativo mudam entre versões.
Adoção real na web em 2026: quem já mudou e quem ainda não
Os números de adoção variam conforme a metodologia de cada fonte, e é importante não misturar dados que medem coisas diferentes. Uns contam páginas rastreadas, outros contam handshakes negociados num período específico, outros ainda medem apenas tráfego humano identificado. Ainda assim, todas apontam na mesma direção: o TLS 1.3 já é maioritário.
| Fonte e data | O que mede | TLS 1.3 | TLS 1.2 |
|---|---|---|---|
| HTTP Archive Web Almanac (edição 2025, publicada em 15/01/2026) | Páginas web rastreadas | ~76% | ~13% a 15% |
| F5 Labs (26/06/2025) | Preferência entre o top 1 milhão de sites | 71,3% | Não discriminado |
| TechnologyChecker (T2 2026) | Quota de tráfego web reportado | 71,71% | 6,07% |
| TechnologyChecker (julho de 2026) | Tráfego humano identificado | 65,90% | 2,68% |
| Defaults.Exposed (5 de setembro de 2026) | Censo completo de domínios que concluíram handshake TLS | 94,4% | 5,6% |
| SiteGuardian (setembro de 2026) | Amostra de sites europeus | 92,1% | 7,8% |
A leitura mais honesta destes dados é que o TLS 1.3 já domina o tráfego que passa por CDNs e infraestrutura moderna, medido pela Defaults.Exposed e pela SiteGuardian acima dos 90%, enquanto medições mais amplas de todo o universo de páginas web, como a do HTTP Archive Web Almanac, ficam na casa dos 70%, porque incluem sites mais pequenos e menos atualizados. Nenhuma das fontes consultadas sustenta a ideia de que o TLS 1.2 esteja perto de desaparecer, mas todas confirmam que o TLS 1.0 e o TLS 1.1 já são resíduo estatístico.
Preços: quanto custa gerir certificados TLS em 2026
A versão do protocolo não determina diretamente o preço do certificado, mas a escolha da entidade certificadora e do modelo de gestão tem um impacto direto no orçamento de segurança de qualquer empresa que precise de migrar para TLS 1.3 em várias dezenas ou centenas de domínios.
| Fornecedor | Certificado DV | Certificado OV | Certificado EV |
|---|---|---|---|
| Let’s Encrypt (ACME) | Grátis | Não emite | Não emite |
| AWS Certificate Manager (serviços integrados) | Sem custo | Sem custo | Sem custo |
| AWS Certificate Manager (exportável) | $7 por FQDN (emissão e renovação) | $7 por FQDN | $7 por FQDN |
| AWS Certificate Manager (wildcard exportável) | $79 por nome wildcard | $79 por nome wildcard | $79 por nome wildcard |
| Sectigo (faixa indicativa de mercado, 2025) | $60 a $100/ano | $200 a $400/ano | $400 a $800/ano |
| DigiCert (faixa indicativa de mercado, 2025) | $150 a $200/ano | $400 a $800/ano | $800 a $1.500/ano |
Para a maioria dos sites e APIs que só precisam de validação de domínio, o Let’s Encrypt continua a ser a opção mais barata, com automação total via ACME e sem custo por certificado. Empresas que precisam de validação de organização ou validação estendida, normalmente bancos, seguradoras e plataformas de pagamento, continuam a pagar a fornecedores como a Sectigo ou a DigiCert, cujos preços variam consoante o número de domínios, o nível de suporte contratado e se o certificado é wildcard.
Cinco exemplos reais de migração e obrigatoriedade do TLS
- PCI DSS v3.2.1: o conselho de normas da indústria de cartões de pagamento exigiu a desativação do TLS 1.0 até 30 de junho de 2018, com uma exceção documentada apenas para comerciantes com um plano formal de mitigação de risco e migração em curso.
- Mozilla Firefox: desativou o TLS 1.0 e o TLS 1.1 por omissão em 2020, mostrando um erro de ligação segura a qualquer site que ainda dependesse exclusivamente dessas versões.
- Microsoft Edge e Internet Explorer: retiraram o suporte por omissão ao TLS 1.0/1.1 em 2020, com remoção posterior das configurações suportadas no ecossistema Windows.
- Safari: juntou-se à mesma vaga coordenada de desativação de browsers em 2020, alinhando a Apple com Google, Mozilla e Microsoft.
- BEAST (CVE-2011-3389): o ataque de 2011 contra o modo CBC do TLS 1.0 foi o gatilho técnico que começou a empurrar bancos e processadores de pagamento para o TLS 1.2 com cifras AEAD, anos antes de o TLS 1.3 sequer existir.
Guia de migração: como passar de TLS 1.2 para TLS 1.3 sem quebrar produção
Migrar um servidor de produção para TLS 1.3 não é uma questão de trocar um número de versão numa linha de configuração. Exige um plano faseado que proteja os clientes mais antigos sem prolongar indefinidamente o risco de manter protocolos fracos ativos.
1. Auditar o que está realmente ativo
Antes de mudar qualquer configuração, confirme quais versões e cifras o servidor aceita hoje. Ferramentas como o SSL Labs da Qualys ou o testssl.sh na linha de comandos mostram exatamente que protocolos e suites estão expostos, incluindo eventuais suites fracas herdadas de configurações antigas nunca revistas.
2. Atualizar a biblioteca TLS subjacente
O TLS 1.3 só funciona com versões recentes do OpenSSL, do BoringSSL ou de bibliotecas equivalentes. Servidores com OpenSSL anterior à 1.1.1 não suportam TLS 1.3 de todo, por isso o primeiro passo técnico é normalmente uma atualização de sistema operativo ou de dependências antes de tocar em ficheiros de configuração do servidor web.
3. Ativar TLS 1.3 a par do TLS 1.2, sem desligar já o 1.2
No nginx, isto significa alterar a diretiva ssl_protocols para incluir ambas as versões modernas, mantendo o TLS 1.2 como rede de segurança durante o período de transição:
server {
listen 443 ssl;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
ssl_certificate /etc/letsencrypt/live/exemplo.pt/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/exemplo.pt/privkey.pem;
}Quem gere servidores Apache em vez de nginx segue a mesma lógica, apenas com uma sintaxe diferente. A diretiva SSLProtocol aceita a mesma abordagem de listar as versões permitidas, excluindo explicitamente tudo o que for anterior ao TLS 1.2:
<VirtualHost *:443>
SSLEngine on
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLCertificateFile /etc/letsencrypt/live/exemplo.pt/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/exemplo.pt/privkey.pem
</VirtualHost>Em ambos os casos, a linha mais importante não é a que ativa o TLS 1.3, mas a que exclui tudo o resto explicitamente. Configurações herdadas de tutoriais antigos, copiadas de servidor em servidor ao longo dos anos, são a causa mais comum de um TLS 1.0 continuar ativo sem que ninguém na equipa tenha decidido isso conscientemente.
4. Monitorizar falhas de handshake antes de desligar versões antigas
Depois de ativar o TLS 1.3, monitorize os registos do servidor durante pelo menos duas a quatro semanas à procura de falhas de negociação. Clientes muito antigos, incluindo pilhas compatíveis com a era do Internet Explorer 11, podem não suportar TLS 1.3 corretamente, e é essa telemetria que deve orientar a decisão final de desligar o TLS 1.0/1.1, se ainda estiverem ativos, e, mais tarde, ponderar a retirada do próprio TLS 1.2.
5. Repetir a auditoria e documentar para conformidade
Depois da migração, corra novamente o SSL Labs ou o testssl.sh e guarde o relatório. Para empresas sujeitas à PCI DSS, ao RGPD ou à NIS2 em Portugal, este relatório é frequentemente pedido por auditores como prova de que os protocolos obsoletos foram efetivamente removidos, não apenas desativados por omissão numa configuração que continua a permitir negociação manual.
Vantagens e desvantagens de cada versão
TLS 1.3
A favor: handshake mais rápido, cifras obrigatoriamente modernas, sigilo de encaminhamento garantido em todas as ligações e o único caminho claro para integração futura com criptografia pós-quântica. Contra: exige bibliotecas e sistemas operativos recentes, o modo 0-RTT precisa de cuidado extra em aplicações que não tolerem repetição de pedidos, e alguns middleboxes corporativos antigos ainda inspecionam mal o tráfego TLS 1.3.
TLS 1.2
A favor: compatibilidade quase universal, décadas de implementações maduras e testadas, e continua aceite por reguladores como piso mínimo. Contra: exige configuração cuidadosa para evitar cifras fracas, não garante sigilo de encaminhamento por omissão, e o handshake mais lento penaliza aplicações sensíveis a latência.
TLS 1.0 e TLS 1.1
A favor: praticamente nenhuma em 2026, exceto compatibilidade forçada com hardware industrial ou médico impossível de atualizar. Contra: proibidas pela IETF, rejeitadas por todos os browsers modernos por omissão, reprovadas em qualquer auditoria de conformidade, e associadas a ataques documentados como o BEAST.
TLS e velocidade de carregamento: o que muda para SEO e conversão
A discussão sobre a versão do TLS costuma ficar confinada às equipas de infraestrutura, mas tem um efeito direto em métricas que marketing e produto acompanham de perto. O tempo até ao primeiro byte (TTFB) inclui o handshake TLS, por isso um round trip a menos conta diretamente para os Core Web Vitals da Google, em particular para o Largest Contentful Paint em ligações móveis mais lentas. Sites que dependem de tráfego internacional, com visitantes a centenas de milissegundos de distância do servidor de origem, sentem esse ganho de forma mais evidente do que sites com audiência concentrada num único país.
Há ainda um efeito indireto menos falado: navegadores mostram avisos de segurança mais agressivos em ligações consideradas fracas, o que aumenta a taxa de abandono em páginas de checkout ou formulários de registo. Uma loja online que ainda negoceie TLS 1.2 com cifras antigas, mesmo sem chegar a usar TLS 1.0, pode ver esse aviso aparecer em browsers configurados com políticas de segurança mais estritas, uma situação comum em ambientes empresariais que bloqueiam ligações abaixo de um determinado nível de cifra. Migrar para TLS 1.3 elimina essa categoria de aviso por completo, porque todas as cifras aceites já cumprem os critérios mais exigentes por omissão.
Casos de uso: qual protocolo faz sentido em cada cenário
- Site institucional ou blog novo: TLS 1.3 desde o primeiro dia, sem necessidade de manter TLS 1.2 ativo, já que a esmagadora maioria dos visitantes usa browsers atualizados.
- API pública consumida por integrações de terceiros: TLS 1.3 com TLS 1.2 como fallback documentado, porque alguns clientes corporativos ainda correm em stacks mais antigas fora do controlo direto da equipa.
- Sistema de pagamentos sujeito à PCI DSS: TLS 1.2 como mínimo absoluto, com migração ativa para TLS 1.3 onde o processador de pagamentos já o suportar, e TLS 1.0/1.1 completamente desligados sem exceção.
- Dispositivo IoT industrial legado: TLS 1.2 bem configurado, com cifras AEAD e ECDHE, quando a atualização de firmware para suportar TLS 1.3 não for viável a curto prazo, isolando o dispositivo numa rede segmentada.
- Aplicação financeira ou de saúde com dados sensíveis: TLS 1.3 obrigatório, sem fallback para versões anteriores, dado o volume de dados pessoais em causa e as coimas previstas em regimes como o RGPD ou a NIS2 em Portugal.
- Loja online com clientes internacionais: TLS 1.3 com TLS 1.2 mantido por mais tempo do que num site institucional, porque mercados com adoção de browsers mais lenta ainda dependem parcialmente do TLS 1.2.
O que dizem os padrões e organismos de segurança
Não há ambiguidade nas fontes oficiais quando o assunto é TLS 1.0 e TLS 1.1. A RFC 8996 da IETF é taxativa ao afirmar que “TLS 1.0 MUST NOT be used” e que “TLS 1.1 MUST NOT be used”, fechando qualquer margem de interpretação para novas implementações.
“Any other version of TLS is more secure than TLS 1.0.”
IETF, RFC 8996 – datatracker.ietf.org
O NIST, agência norte-americana de normas tecnológicas, adota um tom ligeiramente mais pragmático na sua publicação especial SP 800-52r2, reconhecendo que setores públicos com dependências legadas nem sempre conseguem migrar de imediato.
“The use of TLS versions 1.1 and 1.0 is generally discouraged, but these versions may be configured when necessary to enable interaction with citizens and businesses.”
NIST, SP 800-52r2 – nvlpubs.nist.gov
A OWASP, por seu lado, resume a orientação prática que a maioria das equipas de engenharia acaba por seguir no terreno.
“Web applications must default to TLS 1.3 and may support TLS 1.2 for compatibility.”
OWASP, Transport Layer Security Cheat Sheet – cheatsheetseries.owasp.org
As três fontes, apesar de origens diferentes, convergem para a mesma hierarquia prática: TLS 1.3 como padrão, TLS 1.2 tolerado apenas quando bem configurado e por razões de compatibilidade documentadas, TLS 1.0 e TLS 1.1 fora de questão em qualquer sistema novo.
Veredicto: qual protocolo escolher com base nos dados
Os números não deixam grande espaço para debate. O TLS 1.3 reduz o handshake para metade do número de round trips, elimina as cifras que alimentaram ataques como o BEAST, e já cobre entre 68% e 95% do tráfego web em 2026, consoante a fonte e a metodologia usada. Para qualquer sistema novo, a escolha é óbvia: ativar TLS 1.3 por omissão. O TLS 1.2, bem configurado com ECDHE e cifras AEAD, continua a ser uma rede de segurança legítima para compatibilidade, não um risco em si mesmo, desde que as suites fracas sejam explicitamente desativadas. Já o TLS 1.0 e o TLS 1.1 não têm defesa técnica que resista ao escrutínio de 2026: estão banidos pela IETF, rejeitados por todos os browsers principais e representam, segundo a TechnologyChecker, apenas 0,01% do tráfego humano medido. Manter estas duas versões ativas num servidor de produção deixou de ser uma opção de compatibilidade para se tornar um risco de conformidade e de reputação.
Para equipas que ainda não migraram, o caminho mais seguro combina o conhecimento básico sobre como o HTTPS protege uma ligação com uma auditoria real do que está ativo hoje, seguida de uma ativação faseada do TLS 1.3 a par do TLS 1.2, e só depois a retirada definitiva de qualquer resquício de TLS 1.0 ou TLS 1.1. Quem gere certificados em múltiplos domínios pode ainda comparar o custo de automatizar tudo via ACME com o Let’s Encrypt no nginx contra o preço de certificados OV ou EV pagos, e rever a biblioteca criptográfica subjacente, já que a escolha entre OpenSSL e LibreSSL também influencia a rapidez com que novas versões do TLS chegam a produção. Para ambientes que exigem autenticação mútua, vale a pena revisitar como configurar mTLS com TLS 1.3 em Node.js.
Perguntas frequentes sobre TLS 1.3, TLS 1.2 e TLS 1.0/1.1
O TLS 1.2 ainda é seguro em 2026?
Sim, desde que configurado apenas com cifras AEAD modernas, como AES-GCM ou ChaCha20-Poly1305, e com troca de chaves ECDHE para garantir sigilo de encaminhamento. O TLS 1.2 não foi banido pela IETF e continua a ser o mínimo aceite pela PCI DSS, mas exige mais atenção de configuração do que o TLS 1.3, que restringe automaticamente as opções inseguras.
Devo desativar o TLS 1.0 e o TLS 1.1 já?
Sim. A IETF proíbe o uso destas versões desde 2021, através da RFC 8996, e todos os browsers principais já as desativaram por omissão desde 2020. Manter estas versões ativas só faz sentido em casos muito específicos de hardware legado isolado numa rede segmentada, nunca num servidor exposto à internet pública.
Qual é a diferença prática entre 1-RTT e 2-RTT no handshake?
Cada RTT (round trip time) é o tempo que um pacote demora a ir do cliente ao servidor e voltar. O TLS 1.3 fecha o handshake completo num único round trip, enquanto o TLS 1.2 e as versões anteriores precisam de dois. Em ligações com 100 ms de latência, isso representa uma poupança de 100 ms só no estabelecimento da ligação, antes mesmo de qualquer dado da aplicação começar a fluir.
O modo 0-RTT do TLS 1.3 é seguro para qualquer aplicação?
Não para todas. O 0-RTT permite enviar dados antes de o handshake terminar em ligações retomadas, mas esses dados iniciais podem ser reenviados por um atacante em certas condições, um risco conhecido como ataque de repetição. A OWASP recomenda cautela e sugere reservar o 0-RTT para pedidos que sejam seguros para repetir, como leituras, e evitá-lo em operações que alterem estado, como pagamentos.
Quanto custa migrar certificados para suportar TLS 1.3?
O TLS 1.3 não exige um novo tipo de certificado, a mudança é ao nível da configuração do servidor e da biblioteca criptográfica usada, não do certificado em si. Continua a poder usar certificados gratuitos do Let’s Encrypt ou certificados pagos de fornecedores como a Sectigo ou a DigiCert, cujos preços variam entre cerca de 60 dólares por ano para um certificado DV básico e mais de 1.500 dólares por ano para certificados EV empresariais.
Que percentagem da web já usa TLS 1.3?
Depende da fonte e da metodologia. O HTTP Archive Web Almanac, na edição publicada em janeiro de 2026, mediu cerca de 76% das páginas rastreadas a usar TLS 1.3. Medições focadas em handshakes concluídos através de infraestrutura moderna, como a da Defaults.Exposed, chegam a quase 95%. Em qualquer dos casos, o TLS 1.3 já é claramente a versão maioritária.
Preciso de atualizar o sistema operativo para suportar TLS 1.3?
Normalmente sim, se o servidor correr uma versão antiga do OpenSSL, anterior à 1.1.1, ou uma distribuição Linux desatualizada. A maioria das distribuições lançadas depois de 2019 já inclui bibliotecas criptográficas com suporte nativo a TLS 1.3, mas vale sempre a pena confirmar a versão exata antes de planear a migração.
O TLS 1.3 funciona com todos os browsers atuais?
Sim. Chrome, Firefox, Edge e Safari suportam TLS 1.3 desde 2018-2020, e a esmagadora maioria dos utilizadores já corre versões destes browsers com suporte total. Os únicos casos problemáticos envolvem sistemas operativos ou dispositivos muito antigos que já não recebem atualizações, e nesses casos o problema raramente se resolve só do lado do servidor.
