Em setembro de 2014, pesquisadores do Google publicaram um paper descrevendo um ataque chamado POODLE (Padding Oracle On Downgraded Legacy Encryption). O ataque explorava uma vulnerabilidade fundamental no SSL 3.0 — um protocolo que havia sido lançado em 1996 e que a maioria das implementações ainda suportava por compatibilidade. O POODLE permitia que um atacante que controlasse o canal de comunicação forçasse um downgrade de TLS para SSL 3.0 e depois explorasse a vulnerabilidade para descriptografar dados.
A resposta da indústria foi definitiva: browsers, servidores e CDNs desabilitaram SSL 3.0 em questão de semanas. O Firefox 34 e o Chrome 39, lançados dois meses depois, vieram com SSL 3.0 desabilitado por padrão.
Antes do POODLE, houve o Heartbleed (2014) — uma vulnerabilidade na implementação do OpenSSL que permitia a qualquer atacante ler 64KB de memória do servidor por requisição, repetidamente, sem deixar rastros nos logs. Antes disso, o BEAST (2011), o CRIME (2012), o BREACH (2013), o DROWN (2016), o ROBOT (2017). A história do SSL/TLS é inseparável da história dos ataques que quebraram versões anteriores e forçaram a evolução para versões mais seguras.
O protocolo que chamamos genericamente de “SSL” é hoje predominantemente TLS 1.3 (RFC 8446, 2018) — uma versão que removeu décadas de legado vulnerável e redesenhou o handshake para ser mais rápido e mais seguro. Entender como chegamos aqui, quais vulnerabilidades foram exploradas no caminho, e como configurar TLS corretamente hoje é conhecimento fundamental para qualquer profissional de segurança.
Neste artigo, você vai entender como TLS funciona tecnicamente em cada fase do handshake, quais vulnerabilidades históricas revelaram as fraquezas do protocolo, como TLS 1.3 corrigiu os problemas estruturais de versões anteriores, como configurar cipher suites corretamente em Nginx e Apache, como gerenciar o ciclo de vida de certificados, e como auditar a configuração TLS de um servidor. Este é o guia técnico que profissionais de segurança precisam.
SSL vs TLS: a linha do tempo que explica a terminologia
“SSL” e “TLS” são frequentemente usados como sinônimos no mercado, mas referem-se a versões diferentes com histórias de segurança completamente distintas.
SSL 1.0 — desenvolvido pela Netscape em 1994, nunca lançado publicamente por vulnerabilidades críticas.
SSL 2.0 — lançado em 1995, rapidamente encontrado com vulnerabilidades graves. Formalmente deprecado pela RFC 6176 em 2011.
SSL 3.0 — lançado em 1996, usado amplamente por quase duas décadas. Vulnerável ao POODLE. Deprecado pela RFC 7568 em 2015.
TLS 1.0 — lançado em 1999 como upgrade do SSL 3.0. Vulnerável ao BEAST em certas configurações. Deprecado pelo PCI DSS em 2018; browsers o desabilitaram em 2020.
TLS 1.1 — lançado em 2006. Deprecado junto com TLS 1.0 pelos principais browsers em 2020.
TLS 1.2 — lançado em 2008. Ainda amplamente usado, seguro quando configurado corretamente com cipher suites modernas e AEAD.
TLS 1.3 — lançado em 2018 (RFC 8446). Remove cipher suites vulneráveis, redesenha o handshake, manda embora décadas de legado problemático. O padrão atual.
Quando alguém diz “meu site usa SSL”, na prática está descrevendo TLS — provavelmente TLS 1.2 ou 1.3. A terminologia “SSL” persistiu porque é mais conhecida, mas nenhum servidor moderno deveria usar SSL em nenhuma versão.
💡 Dica: Para verificar qual versão de TLS um servidor usa, openssl s_client oferece uma maneira rápida de testar: openssl s_client -connect example.com:443 -tls1_3 conecta usando TLS 1.3. Se o servidor responder com handshake bem-sucedido, suporta TLS 1.3. Se retornar erro, não suporta. Para uma verificação mais completa, o SSL Labs (ssllabs.com/ssltest) avalia automaticamente a configuração completa e dá um grade (A+ a F).
Como o TLS Handshake funciona? Cada fase e sua função de segurança
O handshake TLS estabelece uma conexão segura entre cliente e servidor antes de qualquer dado da aplicação ser transmitido. Cada fase tem uma função de segurança específica.
TLS 1.2 Handshake: o funcionamento clássico
O handshake TLS 1.2 envolve múltiplos round-trips e várias decisões de criptografia:
Cliente Servidor
| |
|---------- ClientHello ------------------->|
| (versão TLS, cipher suites suportadas, |
| random bytes, extensões) |
| |
|<-------- ServerHello ---------------------|
| (versão TLS selecionada, |
| cipher suite escolhida, random bytes) |
| |
|<-------- Certificate ---------------------|
| (certificado do servidor) |
| |
|<-------- ServerKeyExchange ---------------|
| (parâmetros Diffie-Hellman, se ECDHE) |
| |
|<-------- ServerHelloDone -----------------|
| |
|-------- ClientKeyExchange -------------> |
| (chave de sessão criptografada com |
| chave pública do servidor) |
| |
|-------- ChangeCipherSpec ---------------->|
|-------- Finished ------------------------>|
| (MAC de todas as mensagens anteriores) |
| |
|<-------- ChangeCipherSpec ----------------|
|<-------- Finished ------------------------|
| |
|====== Dados da Aplicação ================>|
ClientHello carrega a lista de cipher suites que o cliente suporta (em ordem de preferência), a versão TLS mais alta que o cliente suporta, e bytes aleatórios que contribuem para o material de chave da sessão.
ServerHello seleciona a cipher suite e confirma a versão TLS. A escolha da cipher suite determina o algoritmo de troca de chaves (RSA, ECDHE, DHE), o algoritmo de criptografia simétrica (AES-128, AES-256, ChaCha20) e o algoritmo de autenticação de mensagem (SHA-256, SHA-384).
Certificate envia o certificado digital do servidor — o cliente verifica se o certificado foi assinado por uma CA confiável, se não está expirado, se o nome no certificado corresponde ao domínio, e se não foi revogado.
ServerKeyExchange (presente apenas com ECDHE ou DHE) transmite os parâmetros para o acordo de chave efêmera — a base do Perfect Forward Secrecy.
ClientKeyExchange e Finished completam o estabelecimento de chaves e verificam a integridade das mensagens anteriores.
TLS 1.3 Handshake: mais rápido e mais seguro
O TLS 1.3 redesenhou o handshake para reduzir latência e eliminar opções inseguras:
Cliente Servidor
| |
|-------- ClientHello --------------------->|
| (versão, cipher suites, |
| key shares para ECDHE, |
| extensões) |
| |
|<-------- ServerHello ---------------------|
|<-------- {EncryptedExtensions} -----------|
|<-------- {Certificate} -------------------|
|<-------- {CertificateVerify} -------------|
|<-------- {Finished} ----------------------|
| |
|-------- {Finished} ---------------------->|
| |
|====== Dados da Aplicação ================>|
Diferenças críticas em relação ao TLS 1.2:
Um round-trip a menos — o TLS 1.3 completa o handshake em 1-RTT em vez de 2-RTT, reduzindo latência perceptível especialmente em conexões de alta latência.
Sem negociação de cipher suites legacy — o TLS 1.3 remove completamente cipher suites com RSA para troca de chaves, todas as cifras com CBC (vulneráveis ao BEAST e variantes), RC4, DES, e exportar cifras. Apenas cinco cipher suites são suportadas: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256, TLS_AES_128_CCM_8_SHA256, e TLS_AES_128_CCM_SHA256.
Handshake criptografado — no TLS 1.3, o Certificate, CertificateVerify e Finished (indicados por {}) são criptografados. Isso protege metadados da negociação contra observação passiva.
ECDHE obrigatório — Perfect Forward Secrecy não é opcional no TLS 1.3; é o único modelo de troca de chaves suportado.
0-RTT opcional — TLS 1.3 suporta resumption de sessão com dados enviados no primeiro packet (0-RTT), com ressalvas: dados 0-RTT não têm proteção contra replay, então sua ativação para endpoints que modificam estado (POST requests) requer cuidado.
As vulnerabilidades que quebraram o SSL/TLS
A história dos ataques ao SSL/TLS é a história de como cada geração de pesquisadores encontrou falhas que pareciam impossíveis, forçando o campo a evoluir.
Heartbleed (CVE-2014-0160): 64KB de memória por requisição
O Heartbleed foi uma vulnerabilidade de buffer over-read na extensão heartbeat do OpenSSL, não no protocolo TLS em si. A extensão heartbeat permite que cliente e servidor verifiquem se a conexão ainda está ativa, enviando um “ping” com um payload e recebendo o mesmo payload de volta (o “pong”).
O bug: o servidor não validava se o comprimento declarado no heartbeat correspondia ao comprimento real do payload. Um atacante enviava um payload de 1 byte declarando comprimento de 65535 bytes, e o servidor respondia com 65535 bytes de sua memória — incluindo chaves privadas, passwords em memória, tokens de sessão e outros dados confidenciais.
Cliente -> Servidor:
Type: Heartbeat
Length: 65535 <-- mentira: o payload real tem 1 byte
Payload: "A"
Servidor -> Cliente:
Type: Heartbeat
Length: 65535
Payload: "A" + 65534 bytes da memória do servidor <-- chaves, passwords, tokensO Heartbleed não deixava rastros em logs de acesso normais. Estimativas indicam que 500.000 a 600.000 servidores estavam vulneráveis no momento da divulgação.
Impacto e lição: A vulnerabilidade não estava no TLS, mas na biblioteca que implementa TLS. Isso gerou práticas que persistem hoje: uso de versões suportadas de OpenSSL (com patches de segurança ativos), monitoramento de CVEs relevantes para as bibliotecas usadas, e a necessidade de revogar e reemitir certificados após a exposição da chave privada.
POODLE (CVE-2014-3566): downgrade para SSL 3.0
O POODLE demonstrou que manter suporte a SSL 3.0 por compatibilidade retroativa criava um vetor de ataque. Um atacante na posição de Man-in-the-Middle podia forçar um downgrade de TLS para SSL 3.0 ao interferir nas mensagens de handshake — browsers da época implementavam fallback automático para protocolo mais antigo quando o handshake falhava.
Uma vez em SSL 3.0, o atacante explorava uma vulnerabilidade no modo CBC (Cipher Block Chaining): o padding em SSL 3.0 não era verificado com MAC, permitindo um ataque de padding oracle que, com aproximadamente 256 requisições por byte, descriptografava cookies de sessão.
Lição: Suporte a protocolos legados por compatibilidade cria “downgrade attacks”. A defesa exige tanto desabilitar SSL 3.0 quanto implementar o mecanismo TLS_FALLBACK_SCSV, que sinaliza ao servidor que o cliente está tentando uma versão reduzida para que o servidor rejeite tentativas de downgrade manipuladas.
BEAST (Browser Exploit Against SSL/TLS): vulnerabilidade em TLS 1.0 CBC
O BEAST (2011) demonstrou que o modo CBC em TLS 1.0 era vulnerável a um ataque de IV (Initialization Vector) previsível. No TLS 1.0, o IV do próximo bloco CBC era o último bloco criptografado do registro anterior — tornando o IV previsível para um atacante que observasse o tráfego.
Combinado com a capacidade do atacante de injetar texto escolhido (por exemplo, via JavaScript em uma aba do browser), o BEAST permitia descriptografar cookies de sessão.
Lição: TLS 1.0 precisava ser desabilitado. O PCI DSS formalizou essa obrigação em 2018.
DROWN (CVE-2016-0800): SSLv2 como vetor de ataque
O DROWN (2016) demonstrou que manter suporte ao SSLv2 comprometia servidores que usavam TLS — mesmo que o servidor em si não aceitasse conexões SSLv2 diretamente. A vulnerabilidade explorava que a chave privada RSA podia ser reutilizada entre um servidor TLS e um servidor que ainda aceitasse SSLv2 (como um servidor de email na mesma infraestrutura).
Aproximadamente 33% dos servidores HTTPS eram vulneráveis no momento da divulgação, principalmente pela reutilização de certificados e chaves entre diferentes serviços.
Lição: Reutilizar chaves privadas entre diferentes serviços cria superfícies de ataque cruzadas. Cada serviço deve ter seu próprio par de chaves e certificado.
RC4: a cifra que não deveria existir mais
RC4 foi uma cifra de stream amplamente usada em SSL/TLS por duas décadas por sua velocidade. Múltiplos ataques ao longo dos anos demonstraram viés estatístico nos keystreams gerados — e em 2015, o ataque RC4NOMORE demonstrou descriptografia prática de cookies protegidos por RC4 em cerca de 75 horas.
A RFC 7465 (2015) proibiu explicitamente o uso de RC4 em TLS. Qualquer servidor ainda configurado com RC4 em cipher suites está usando uma cifra com vulnerabilidades conhecidas e exploráveis.
⚠️ Atenção: Ferramentas como o Qualys SSL Labs e o testssl.sh identificam automaticamente suporte a RC4, TLS 1.0/1.1, SSL 3.0 e SSL 2.0 em uma varredura. Antes de considerar que uma configuração TLS está correta, execute esses testes e certifique-se de que o resultado é A ou A+.
Certificados TLS: a cadeia de confiança
Como a PKI funciona?
A confiança em certificados TLS baseia-se na Public Key Infrastructure (PKI) — um sistema hierárquico onde Autoridades Certificadoras (CAs) emitem certificados para organizações, que os usam para provar sua identidade aos visitantes.
A cadeia de confiança:
- Root CA — certificado raiz autoassinado, pré-instalado nos sistemas operacionais e browsers. Exemplos: DigiCert Root CA, ISRG Root X1 (Let’s Encrypt), Comodo Root CA.
- Intermediate CA — certificado emitido pela Root CA, usado para emitir certificados de entidade final. Root CAs raramente assinam certificados diretamente para minimizar exposição da chave raiz.
- End-entity certificate — o certificado do servidor, emitido pela Intermediate CA, contendo a chave pública do servidor e informações de identidade.
Quando um browser conecta a um servidor, verifica a cadeia completa — do certificado do servidor até uma Root CA confiável. Uma cadeia incompleta (sem o certificado intermediate) gera erro em muitos browsers mesmo que o certificado do servidor seja válido.
Tipos de validação
DV (Domain Validation) — a CA verifica apenas que o solicitante controla o domínio (via ACME challenge como HTTP-01 ou DNS-01). Processo automatizado, emitido em minutos. Adequado para a maioria dos sites. Let’s Encrypt emite apenas DV.
OV (Organization Validation) — além do domínio, a CA verifica informações da organização (razão social, endereço, etc.). O processo leva dias. O certificado inclui informações da organização, visíveis ao inspecionar o certificado.
EV (Extended Validation) — validação mais rigorosa da identidade da organização. Historicamente ativava uma “barra verde” nos browsers, mas Chrome e Firefox removeram essa indicação visual específica em 2019, argumentando que ela não melhorava a segurança do usuário de forma mensurável.
Certificate Transparency: o log público de todos os certificados
Desde 2018, o Chrome exige que certificados incluam SCTs (Signed Certificate Timestamps) — provas de que o certificado foi registrado em pelo menos dois logs de Certificate Transparency públicos antes de ser emitido. Isso criou um sistema onde qualquer certificado emitido para qualquer domínio aparece em logs públicos auditáveis.
A ferramenta crt.sh permite buscar todos os certificados emitidos para um domínio:
# Busca todos os certificados emitidos para example.com e subdomínios
curl -s "https://crt.sh/?q=%.example.com&output=json" | jq '.[].name_value'Para equipes de segurança, Certificate Transparency é uma ferramenta poderosa de monitoramento: qualquer certificado emitido fraudulentamente para um domínio que você controla aparece nesses logs. Serviços como SSLMate Certificate Monitor e Cloudflare Certificate Transparency alertam quando novos certificados são emitidos para domínios configurados.
OCSP e CRL: revogação de certificados
Um certificado comprometido — onde a chave privada foi exposta — precisa ser revogado para que browsers não confiem mais nele. Dois mecanismos existem para isso:
CRL (Certificate Revocation List) — lista de certificados revogados mantida pela CA. Browsers baixam periodicamente. Problema: a lista pode crescer muito, e a verificação requer download do arquivo inteiro.
OCSP (Online Certificate Status Protocol) — o browser consulta a CA para verificar o status do certificado em tempo real. Problema: cria latência adicional e revela ao servidor OCSP quais sites o usuário está acessando.
OCSP Stapling resolve o problema de privacidade e latência: o servidor TLS busca a resposta OCSP da CA e a inclui (“grampeada”) no handshake TLS. O browser recebe a prova de não-revogação sem precisar consultar a CA — mais rápido e sem vazamento de privacidade.
Configuração segura de TLS: Nginx e Apache
Nginx: configuração de referência
server {
listen 443 ssl http2;
server_name example.com;
# Certificado e chave privada
ssl_certificate /etc/ssl/certs/example.com.pem;
ssl_certificate_key /etc/ssl/private/example.com.key;
# Apenas TLS 1.2 e 1.3 — sem versões anteriores
ssl_protocols TLSv1.2 TLSv1.3;
# Cipher suites seguras para TLS 1.2
# TLS 1.3 gerencia seus próprios cipher suites automaticamente
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
# Servidor decide a cipher suite (não o cliente)
ssl_prefer_server_ciphers on;
# Curvas para ECDH/ECDHE
ssl_ecdh_curve X25519:prime256v1:secp384r1;
# Session tickets — chave rotacionada regularmente para PFS
ssl_session_ticket_key /etc/ssl/private/session_ticket.key;
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m;
# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/certs/chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
# HSTS: força HTTPS por 2 anos, incluindo subdomínios
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
# Headers de segurança adicionais
add_header X-Frame-Options SAMEORIGIN always;
add_header X-Content-Type-Options nosniff always;
}
# Redireciona HTTP para HTTPS
server {
listen 80;
server_name example.com;
return 301 https://$server_name$request_uri;
}Apache: configuração de referência
<VirtualHost *:443>
ServerName example.com
SSLEngine on
SSLCertificateFile /etc/ssl/certs/example.com.pem
SSLCertificateKeyFile /etc/ssl/private/example.com.key
SSLCertificateChainFile /etc/ssl/certs/chain.pem
# Apenas TLS 1.2 e 1.3
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
# Cipher suites seguras — sem RC4, sem DES, sem exportar, sem NULL
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder on
# OCSP Stapling
SSLUseStapling on
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
SSLStaplingResponseMaxAge 900
# HSTS
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
# Segurança adicional
Header always set X-Frame-Options SAMEORIGIN
Header always set X-Content-Type-Options nosniff
</VirtualHost>
<VirtualHost *:80>
ServerName example.com
Redirect permanent / https://example.com/
</VirtualHost>O que cada configuração faz?
ssl_protocols TLSv1.2 TLSv1.3 — desabilita SSL 3.0, TLS 1.0 e TLS 1.1 explicitamente. Qualquer versão anterior a TLS 1.2 tem vulnerabilidades conhecidas.
Cipher suites ECDHE-* — todas as cipher suites na lista usam ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), que fornece Perfect Forward Secrecy. Sem PFS, comprometer a chave privada do servidor permite descriptografar capturas passadas de tráfego. Cipher suites com RSA para troca de chaves (sem ECDHE) não têm PFS.
-AES128 antes de AES256 — AES-128-GCM é criptograficamente seguro para todos os fins práticos. Colocar AES-256 na frente é uma decisão defensiva conservadora, não uma necessidade prática atual.
HSTS com max-age=63072000 — instrui o browser a acessar o domínio apenas via HTTPS por dois anos. O atributo preload permite submissão à lista HSTS preload embutida em browsers.
Perfect Forward Secrecy: por que o modo de troca de chaves importa?
O problema com RSA puro para troca de chaves
Em TLS 1.2 com RSA para troca de chaves (sem ECDHE), o processo funciona assim:
- O servidor tem uma chave privada RSA de longa duração
- O cliente gera um segredo aleatório (pre-master secret), o criptografa com a chave pública do servidor, e envia
- O servidor descriptografa com sua chave privada para obter o pre-master secret
O problema: um atacante que captura esse tráfego e depois compromete a chave privada do servidor pode descriptografar retroativamente todas as sessões TLS que capturou. Basta guardar o tráfego criptografado e esperar pela oportunidade de obter a chave privada.
ECDHE: chaves efêmeras por sessão
Com ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), cada sessão TLS usa um par de chaves Diffie-Hellman temporário — gerado especificamente para aquela sessão e descartado após o uso. A chave privada RSA do servidor assina os parâmetros ECDHE (autenticação) mas não participa diretamente da derivação das chaves de sessão.
Mesmo que a chave privada RSA seja comprometida posteriormente, o atacante não consegue descriptografar sessões passadas porque as chaves efêmeras ECDHE daquelas sessões foram descartadas. Essa propriedade é o Perfect Forward Secrecy.
💡 Dica: Para verificar se um servidor usa PFS, o comando openssl s_client mostra o cipher suite negociado: openssl s_client -connect example.com:443 2>&1 | grep Cipher. Cipher suites com ECDHE ou DHE oferecem PFS; cipher suites com apenas RSA na parte de troca de chaves não oferecem PFS.
Gerenciamento de certificados em produção
Let’s Encrypt e automação com Certbot
Let’s Encrypt transformou o gerenciamento de certificados ao oferecer certificados DV gratuitos com automação via protocolo ACME. O Certbot automatiza obtenção e renovação:
# Instalação e obtenção de certificado para Nginx
sudo certbot --nginx -d example.com -d www.example.com
# Renovação automática (crontab ou systemd timer)
# Let's Encrypt renova quando o certificado tem menos de 30 dias de vida
sudo certbot renew --quiet
# Verificar status de renovação
sudo certbot certificatesO Certbot modifica a configuração do Nginx automaticamente, mas revisar e ajustar as cipher suites e protocolos após a instalação é importante — o Certbot configura parâmetros conservadores que nem sempre representam o estado da arte.
Wildcard Certificates: conveniência e risco
Wildcard certificates (*.example.com) protegem todos os subdomínios de um domínio com um único certificado. Convenientes para gerenciar, mas com uma implicação de segurança: a mesma chave privada protege todos os subdomínios. Se o servidor de um subdomínio for comprometido e a chave privada exposta, todos os subdomínios ficam vulneráveis.
Para sistemas de alta segurança onde diferentes subdomínios têm diferentes perfis de risco (um portal admin vs. um blog público), certificados separados por subdomínio com chaves separadas reduzem o raio de impacto de um comprometimento.
Certificate Pinning: proteção adicional em aplicações
Para aplicações móveis e clientes que controlam a lógica de verificação de certificados, certificate pinning adiciona uma camada sobre a validação padrão de CA: a aplicação aceita apenas certificados específicos ou emitidos por CAs específicas para um domínio determinado.
Mesmo que um atacante obtenha um certificado válido de outra CA para o mesmo domínio (como demonstrado nos ataques à DigiNotar), a aplicação com pinning rejeita esse certificado.
A complexidade operacional do pinning — a aplicação para de funcionar se o pin não é atualizado antes da rotação do certificado — significa que exige um processo de gestão cuidadoso com pins de backup.
Auditando a configuração TLS: ferramentas e o que verificar
Qualys SSL Labs: a referência online
O SSL Server Test do Qualys (ssllabs.com/ssltest) avalia automaticamente:
- Versões de protocolo suportadas (deve mostrar apenas TLS 1.2 e 1.3)
- Cipher suites suportadas (deve mostrar apenas AEAD sem RC4, DES, ou exportar)
- Suporte a Forward Secrecy
- Configuração HSTS
- OCSP Stapling
- Vulnerabilidades conhecidas (Heartbleed, POODLE, DROWN, ROBOT, etc.)
- Grade geral (A+ para configuração excelente)
testssl.sh: auditoria pela linha de comando
# Instalação
git clone --depth 1 https://github.com/drwetter/testssl.sh.git
cd testssl.sh
# Teste completo de um servidor
./testssl.sh example.com
# Teste de vulnerabilidades específicas
./testssl.sh --poodle --heartbleed --robot --drown example.com
# Verificar cipher suites suportadas
./testssl.sh --cipher-per-proto example.com
# Gerar relatório JSON
./testssl.sh --jsonfile report.json example.comopenssl s_client: inspeção manual
# Conectar e verificar certificado
openssl s_client -connect example.com:443 -servername example.com
# Forçar TLS 1.3 — verifica suporte
openssl s_client -connect example.com:443 -tls1_3
# Verificar OCSP Stapling
openssl s_client -connect example.com:443 -status 2>&1 | grep -A 17 "OCSP response"
# Verificar cadeia de certificados completa
openssl s_client -connect example.com:443 -showcerts
# Testar se TLS 1.0 ainda está habilitado (deveria falhar em servidor bem configurado)
openssl s_client -connect example.com:443 -tls1Checklist de auditoria TLS
Protocolos:
- SSL 2.0 desabilitado
- SSL 3.0 desabilitado
- TLS 1.0 desabilitado
- TLS 1.1 desabilitado
- TLS 1.2 habilitado (com cipher suites corretas)
- TLS 1.3 habilitado
Cipher suites:
- Sem RC4
- Sem DES / 3DES
- Sem exportar cifras
- Sem cipher suites NULL
- Apenas cipher suites AEAD (GCM, CCM, ou ChaCha20-Poly1305)
- Todas as cipher suites usam ECDHE para PFS
Certificado:
- Certificado válido e não expirado
- Cadeia de certificados completa (incluindo intermediate)
- OCSP Stapling habilitado
- Chave RSA de 2048+ bits ou ECDSA com curva P-256+
Headers de segurança:
- HSTS com max-age adequado
- Redirecionamento de HTTP para HTTPS configurado
Perguntas frequentes sobre SSL e TLS
Não — SSL e TLS são versões diferentes do mesmo protocolo com histórias de segurança completamente distintas. SSL 2.0 e SSL 3.0 têm vulnerabilidades críticas documentadas e não devem ser usados. TLS 1.0 e 1.1 também têm vulnerabilidades e os principais browsers os desabilitaram em 2020. TLS 1.2 e TLS 1.3 são as versões atuais e seguras. Quando pessoas dizem “meu site usa SSL”, geralmente descrevem TLS 1.2 ou 1.3 — o termo “SSL” persistiu no uso comum mas os protocolos SSL reais não devem existir em servidores modernos.
TLS 1.2 ainda é seguro quando configurado corretamente — com cipher suites AEAD, ECDHE para PFS, e sem cipher suites legacy. TLS 1.3 oferece melhorias reais: handshake mais rápido (1-RTT vs. 2-RTT), sem negociação de cipher suites inseguras (não há como configurar mal por acidente), e handshake criptografado que protege metadados adicionais. A recomendação atual é habilitar ambos: TLS 1.3 como preferência e TLS 1.2 como fallback para clientes que ainda não suportam TLS 1.3 (principalmente sistemas mais antigos).
PFS garante que comprometer a chave privada do servidor no futuro não permite descriptografar tráfego capturado no passado. Com PFS (usando ECDHE ou DHE), cada sessão TLS usa um par de chaves efêmero descartado após o uso. Sem PFS (troca de chaves com RSA puro), um atacante que captura tráfego criptografado e posteriormente obtém a chave privada pode descriptografar todo o tráfego capturado retroativamente. Organizações como a NSA documentaram práticas de capturar tráfego criptografado para descriptografar depois — PFS é a defesa direta contra esse modelo de ataque.
Quando um certificado expira, o browser exibe um aviso de segurança que impede a maioria dos usuários de continuar — a conexão ainda é criptografada, mas o browser não consegue verificar a identidade atual do servidor porque a prova de identidade (o certificado) expirou. O risco não é criptograficamente crítico para a sessão em si, mas o aviso cria desconfiança, reduz o tráfego, e em alguns contextos (aplicações que fazem certificate pinning ou verificação automática) pode interromper completamente o serviço. Sistemas de monitoramento como Datadog, Nagios, e o próprio SSL Labs monitoram expirações e alertam com antecedência para evitar esse problema.
HSTS (HTTP Strict Transport Security) instrui o browser a acessar o domínio apenas via HTTPS, sem tentar HTTP, pelo período definido no max-age. Na prática: mesmo que um usuário tente acessar http://example.com, o browser redireciona internamente para HTTPS antes de fazer qualquer requisição de rede — eliminando a possibilidade de um atacante MitM interceptar a requisição HTTP inicial e redirecionar para um site falso. O atributo preload vai além: o domínio entra em uma lista embutida nos browsers que força HTTPS mesmo na primeira visita (antes do browser receber qualquer header HSTS do servidor). Sem HSTS, o primeiro acesso HTTP de um usuário nunca-antes-visitante permanece vulnerável a sslstrip e ataques similares.
TLS é tão seguro quanto sua configuração
Ao longo deste artigo, SSL/TLS revelou-se um campo onde a história dos ataques é inseparável do estado atual do protocolo. POODLE, Heartbleed, BEAST, DROWN, ROBOT — cada vulnerabilidade forçou mudanças específicas que se tornaram requisitos de configuração que hoje reconhecemos como “boas práticas”.
O TLS 1.3 representa a codificação dessas lições: remove a capacidade de configurar cipher suites inseguras, torna o PFS obrigatório, criptografa o handshake, e reduz a superfície de ataque eliminando décadas de opções legacy. Servidores que suportam TLS 1.3 como primeira opção estão essencialmente protegidos contra a maioria dos ataques que comprometeram versões anteriores.
Os três pilares que definem uma configuração TLS defensável são os mesmos que definem configurações de segurança em geral: minimização de opções (só suportar TLS 1.2 e 1.3, só cipher suites AEAD com ECDHE), verificação contínua (SSL Labs, testssl.sh, monitoramento de expiração de certificados), e gestão proativa (renovação automática, OCSP Stapling, HSTS configurado).
Configurar TLS corretamente não é um projeto único — é uma prática de manutenção contínua em um campo que evolui com as ameaças.
👉 Compartilhe este artigo com administradores de sistemas, engenheiros de infraestrutura e times de segurança que precisam de uma referência técnica completa sobre TLS — pode ser o guia que transforma configurações vulneráveis em configurações que passam no SSL Labs com nota A+.
Uma resposta