Cidvise
Scan de TLS

Scan de TLS: veja quais protocolos e cifras o seu servidor ainda aceita

Veja o que o seu servidor aceita negociar: versões de protocolo, cifras, sigilo futuro e falhas conhecidas como Heartbleed e ROBOT. Resultado na tela em segundos e PDF completo.

Aceita domínio ou subdomínio, como app.suaempresa.com.br. Cada endereço é analisado separadamente.

Sem cadastro para ver o resultadoResultado em ~40 segundosVarredura externa passiva
ou analise outro vetor
Scan de HTTP headersScan de e-mail (SPF, DKIM, DMARC)Diagnóstico completo
O que é analisado

O que uma conexão TLS negocia, e o que este scan registra

ClienteServidor
1. ClientHelloversões de TLS e cifras que o cliente suporta
2. ServerHello + Certificateversão e cifra escolhidas, cadeia de certificados
3. Troca de chavessegredo da sessão: RSA, ou ECDHE/DHE com chave efêmera
sessão cifrada com os parâmetros escolhidos pelo servidor

Toda conexão HTTPS começa com um handshake. O cliente informa as versões de TLS e os conjuntos de cifras que suporta. O servidor escolhe uma combinação entre as que aceita e apresenta o certificado. A qualidade da criptografia da sessão é definida nessa escolha, e a escolha depende do que o servidor está configurado para aceitar.

O certificado responde apenas por identidade: prova que o servidor é quem diz ser. Ele não determina a versão do protocolo, o algoritmo de troca de chaves nem o conjunto de cifras. Um servidor com certificado válido pode aceitar TLS 1.0, negociar troca de chaves RSA e manter compressão TLS ativa. Nenhuma dessas condições aparece no navegador.

Como o scan mede. Ele executa handshakes sucessivos, oferecendo a cada tentativa uma versão ou uma cifra específica, e registra o que o servidor aceita. Com isso responde a três perguntas: quais versões de protocolo estão habilitadas, quais conjuntos de cifras são negociáveis e se a troca de chaves gera uma chave efêmera por sessão, o que caracteriza Perfect Forward Secrecy. Também verifica compressão TLS, renegociação segura, suporte a TLS_FALLBACK_SCSV e a resposta às sondas de Heartbleed e ROBOT.

A análise usa a mesma engine do cidguard, baseada em sslyze. Cada achado sai com severidade, a evidência do que foi negociado e a instrução de correção. Os termos do resultado estão explicados no glossário.

Verificações

O que a varredura procura

Quatro grupos de verificação. Cada um observa uma etapa do handshake e registra o parâmetro que o servidor aceitou.
01

Protocolos habilitados

SSL 2.0, SSL 3.0, TLS 1.0 e TLS 1.1 foram depreciados pela IETF. Enquanto o servidor aceitar uma dessas versões, qualquer cliente pode negociá-la. PCI DSS registra a versão aceita como não conformidade.
RFC 6176RFC 7568RFC 8996PCI DSS 4.0
02

Troca de chaves e sigilo futuro

Cifras com troca de chaves RSA derivam a chave de sessão da chave privada do certificado. Se essa chave vazar, o tráfego capturado no passado pode ser decifrado. Com ECDHE ou DHE, cada sessão usa uma chave efêmera, e o vazamento do certificado não compromete sessões anteriores.
RFC 8446 §4.2.7NIST SP 800-52r2
03

Downgrade, renegociação e compressão

TLS_FALLBACK_SCSV impede que um intermediário force a conexão a uma versão inferior. Renegociação insegura permite injetar dados no início da sessão. Compressão TLS ativa expõe a conexão ao ataque CRIME.
RFC 7507CVE-2009-3555CVE-2012-4929
04

Heartbleed e ROBOT

Heartbleed permite ler blocos de memória do servidor pela extensão heartbeat. ROBOT explora a troca de chaves RSA com padding PKCS#1 v1.5 para decifrar sessões. As duas são verificadas por sondas de detecção, sem extração de dados.
CVE-2014-0160CVE-2017-13099
Como funciona

Do domínio ao relatório

O domínio é a única informação necessária. A varredura roda no host informado, a nota aparece na tela e o relatório completo segue por e-mail.
10 s

Informe o domínio

Apenas o domínio. Sem conta, sem cartão e sem instalação.

20 s a 40 s

A varredura é executada

O mesmo scanner da plataforma é executado contra o host, em tempo real.

3~40 s

A nota aparece na tela

Score de 0 a 100, calculado pela fórmula do produto, com os achados mais graves abertos.

4Após confirmar o e‑mail

O relatório segue por e‑mail

PDF completo com evidência e instrução de correção, enviado a um e‑mail do domínio analisado.

Exemplo de resultado
acme.com.brnota71C
TLS3 achadosTLS 1.0 aceito · 4 cifras sem PFS · TLS_FALLBACK_SCSV ausente
Relatório em PDF enviado a um e‑mail de acme.com.br
Regra de entrega

Por que apenas e‑mail do domínio analisado. O relatório descreve fraquezas de um domínio específico. Entregá-lo a qualquer endereço permitiria que terceiros obtivessem esse levantamento sem relação com o domínio. Quem não tem e‑mail no domínio pode entrar em contato e receber o relatório após confirmar a relação com ele.

Escopo

O que a varredura faz no alvo

O contato com o alvo se limita ao que qualquer cliente faz ao acessar o domínio. Tudo o que exige autorização do responsável pelo ambiente fica fora.
Dentro do escopo

Abrir conexões TLS com o host

Handshakes sucessivos, cada um oferecendo uma versão de protocolo ou um conjunto de cifras, para registrar o que o servidor aceita.

Ler a cadeia de certificados

A cadeia apresentada no handshake é registrada, incluindo emissor, validade e algoritmo de assinatura.

Enviar sondas de detecção

Heartbleed e ROBOT são verificados pelo comportamento da resposta a mensagens de teste, sem extração de dados.

Consultar DNS e a página inicial

Registros SPF, DKIM e DMARC e os cabeçalhos HTTP da página inicial entram no diagnóstico completo, com achados separados por verificação.

Fora do escopo

Sondar portas e serviços

Varredura de portas alcança infraestrutura que pode pertencer ao provedor, como acontece em PaaS e CDN. Esse tipo de teste exige autorização formal do responsável pelo ambiente.

Enumerar caminhos

Não há tentativa de descobrir rotas como /admin ou /.env por lista de palavras. Esse procedimento gera volume de requisições no alvo e só é executado com autorização.

Explorar vulnerabilidades

Nenhum payload é enviado e nenhuma vulnerabilidade é explorada. As sondas observam o comportamento da resposta, sem extrair dados.

Cobrir o inventário

O resultado cobre o domínio informado. Subdomínios, ambientes de homologação e serviços auxiliares ficam fora deste diagnóstico e costumam concentrar parte relevante da exposição.

FAQ

Perguntas frequentes

O que é postura de TLS?

É o conjunto de parâmetros que o servidor aceita negociar em uma conexão TLS: versões de protocolo, conjuntos de cifras, algoritmo de troca de chaves, extensões e proteções. O certificado é um desses parâmetros, mas a postura inclui todos os outros. Dois servidores com o mesmo certificado válido podem ter posturas muito diferentes.

O scan verifica o certificado?

O scan analisa o handshake completo, incluindo a cadeia de certificados apresentada pelo servidor. O foco, porém, está nos parâmetros que o navegador não exibe: versões de protocolo aceitas, cifras negociáveis, troca de chaves com sigilo futuro, compressão TLS, renegociação segura e resposta às sondas de Heartbleed e ROBOT.

O que é Perfect Forward Secrecy e por que ele importa?

Perfect Forward Secrecy é a propriedade de uma sessão cuja chave não pode ser recuperada a partir da chave privada do servidor. Ela existe quando a troca de chaves usa ECDHE ou DHE, que geram um segredo efêmero por sessão. Sem PFS, quem tiver capturado tráfego e depois obtiver a chave privada consegue decifrar todas as sessões gravadas. Com PFS, a chave privada serve apenas para autenticar o servidor.

Aceitar TLS 1.0 ou TLS 1.1 ainda é um problema?

Sim. As duas versões foram depreciadas pela RFC 8996 em 2021 e dependem de construções com fraquezas documentadas, como o modo CBC do TLS 1.0 explorado pelo BEAST. PCI DSS exige TLS 1.2 ou superior para transmissão de dados de cartão. Se o servidor mantém a versão por compatibilidade com um cliente específico, o achado permanece válido, porque qualquer cliente pode negociar a versão enquanto ela estiver habilitada.

A varredura é intrusiva? O servidor registra alguma coisa?

A varredura abre conexões TLS e observa o que o servidor aceita negociar. No log do servidor, elas aparecem como conexões TLS, do mesmo tipo que qualquer cliente HTTPS gera. Não há envio de payload, tentativa de exploração nem varredura de portas. Heartbleed e ROBOT são verificados por sondas que observam o comportamento da resposta, sem extrair dados.

A nota desta página considera e-mail e cabeçalhos HTTP?

Não. Nesta página roda apenas o scan de TLS, e a nota reflete esse resultado. O diagnóstico completo executa TLS, cabeçalhos HTTP e e-mail no domínio informado, e cada achado indica de qual verificação veio.

Com que frequência refazer o teste?

A configuração TLS muda em trocas de CDN, balanceador, provedor de hospedagem e renovação de certificado, momentos em que o servidor pode voltar aos padrões do provedor. A referência do que é considerado seguro também muda: cifras aceitas hoje entram em listas de depreciação mais tarde. Um teste pontual descreve o estado atual. A plataforma repete a verificação a cada 35 dias e registra a evolução.