Ir para o conteúdo
Logo NIC.br Logo CGI.br

Aprovado : Endereço IP moderno (IPv6)

Muito bem! Seu site é acessível aos visitantes por um endereço IP moderno de Internet (IPv6), tornando-o parte integrante da Internet moderna.

Servidores de nomes

Resultado:

Dois ou mais servidores de nomes de seu domínio têm um endereço IPv6.

Detalhes técnicos:

Servidor de nomes Endereço IPv6 Endereço IPv4
ns1.mmhospedagem.com.br. 2607:5300:60:846f::1 158.69.55.111
ns2.mmhospedagem.com.br. 2607:5300:60:846f::2 54.39.13.7

Descrição do teste:

Verificamos se seu nome de domínio tem pelo menos dois servidores de nomes com um endereço IPv6. Isto é consistente com a RFC 2182: Selection and Operation of Secondary DNS Servers que recomenda que cada domínio deve ter um servidor de nomes primário e pelo menos um secundário, que devem ser redundantes e instalados em redes topológica e fisicamente independentes.

Resultado:

Todos os servidores de nomes que têm um endereço IPv6 são acessíveis via IPv6.

Descrição do teste:

Verificamos se todos os servidores de nomes, que têm um registro AAAA com endereço IPv6, são acessíveis via IPv6.

Servidor web

Resultado:

Ao menos um dos seus servidores web tem um endereço IPv6.

Detalhes técnicos:

Servidor web Endereço IPv6 Endereço IPv4
mmhospedagem.com.br 2607:5300:60:846f::1 158.69.55.111

Descrição do teste:

Verificamos se há pelo menos um registro AAAA com endereço IPv6 para o seu servidor web.

Resultado:

Todos os seus servidores web com um endereço IPv6 são acessíveis via IPv6.

Descrição do teste:

Verificamos se podemos nos conectar ao(s) seu(s) servidor(es) web via IPv6 em qualquer das portas disponíveis (80 e/ou 443). Testamos todos os endereços IPv6 que recebemos dos seus servidores de nomes. Uma pontuação parcial será dada se nem todos os endereços IPv6 forem acessíveis. Se um endereço IPv6 for sintaticamente inválido, será considerado inacessível.

Resultado:

Seu site com endereço IPv6 parece ser o mesmo que o seu site com endereço IPv4.

Descrição do teste:

Comparamos o conteúdo web que recebemos do seu servidor web em endereços IPv6 e IPv4 em qualquer das portas disponíveis (80 e/ou 443). Caso haja múltiplos endereços IPv6 e IPv4, escolhemos um endereço IPv6 e um endereço IPv4. Se a diferença de conteúdo não for superior a 10%, esperamos que o conteúdo web principal seja o mesmo, portanto, sites com pequenas diferenças, por exemplo, devido a alterações em anúncios, também serão aprovados neste subteste.

Aprovado : Nome de domínio assinado (DNSSEC)

Muito bem! Seu domínio é assinado com uma assinatura válida (DNSSEC), portanto, visitantes com validação de assinatura de domínio habilitada, estão protegidos contra a tradução manipulada de seu domínio para endereços falsos de Internet.

Resultado:

Seu domínio possui assinatura DNSSEC.

Detalhes técnicos:

Domínio Registro de domínios
mmhospedagem.com.br Nenhum(a)

Descrição do teste:

Verificamos se seu domínio, mais especificamente seu registro SOA, possui assinatura DNSSEC.

Se um domínio for redirecionado para outro domínio via CNAME, também verificamos se o domínio apontado pelo CNAME é assinado, o que é compatível com a recomendação para DNSSEC. Se o domínio apontado pelo CNAME não estiver assinado, o resultado deste subteste será negativo.

Nota: A validade da assinatura não faz parte deste subteste, mas do próximo.

Resultado:

Seu domínio é seguro, pois sua assinatura DNSSEC é válida.

Detalhes técnicos:

Domínio Status
mmhospedagem.com.br seguro

Descrição do teste:

Verificamos se seu domínio, mais especificamente seu registro SOA, é assinado com uma assinatura válida, tornando-o seguro.

Se um domínio for redirecionado para outro domínio assinado via CNAME, também verificamos se a assinatura do domínio apontado pelo CNAME é válida, o que é compatível com a recomendação para DNSSEC. Se a assinatura do domínio apontado pelo CNAME não for válida, o resultado deste subteste será negativo.


Aprovado : Conexão segura (HTTPS)

Muito bem! A conexão com seu site é suficientemente segura (HTTPS), portanto, as informações em trânsito entre seu site e seus visitantes são protegidas contra interceptação e adulteração.

HTTP

Resultado:

Seu site oferece HTTPS.

Detalhes técnicos:

Endereço IP do servidor web HTTPS existente
158.69.55.111 sim
2607:5300:60:846f::1 sim

Descrição do teste:

Verificamos se seu site está acessível por HTTPS.

Em caso afirmativo, também verificamos nos subtestes abaixo se o HTTPS está configurado de maneira suficientemente segura de acordo com a IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL.

O HTTPS garante a confidencialidade e a integridade das informações trocadas. Para garantir a privacidade de dados sensíveis e de informações importantes, uma configuração HTTPS segura é importante para todos os sites. Mesmo as informações públicas triviais podem ser extremamente confidenciais e valiosas para o usuário.

Nota: Por razões de desempenho, os testes da seção HTTPS somente são realizados para o primeiro endereço IPv6 e IPv4 disponível.

Resultado:

Seu servidor web redireciona automaticamente os visitantes do HTTP para o HTTPS no mesmo domínio.

Detalhes técnicos:

Endereço IP do servidor web Redirecionamento para HTTPS
158.69.55.111 sim
2607:5300:60:846f::1 sim

Descrição do teste:

Verificamos se seu servidor web redireciona automaticamente os visitantes de HTTP para HTTPS no mesmo domínio, por meio de um código de status de redirecionamento 3xx como 301 e 302, ou se ele oferece suporte apenas para HTTPS e não para HTTP.

Em caso de redirecionamento, um domínio deve primeiro atualizar-se, redirecionando para sua versão HTTPS antes de redirecionar para outro domínio. Isto também garante que a política do HSTS será aceita pelo navegador web. Exemplos de ordem correta de redirecionamento:

  • http://exemplo.brhttps://exemplo.brhttps://www.exemplo.br
  • http://www.exemplo.brhttps://www.exemplo.br

Observe que este subteste avalia apenas se o domínio fornecido redireciona corretamente de HTTP para HTTPS. Um eventual redirecionamento adicional para um domínio diferente, incluindo um subdomínio do domínio em teste, não é considerado. Você pode iniciar um teste separado para o domínio para o qual está sendo redirecionado.

Ver Protecting Your Website With Always On SSL, Internet Society.

Resultado:

Seu servidor web não oferece suporte à compressão HTTP.

Detalhes técnicos:

Endereço IP do servidor web Compressão HTTP
158.69.55.111 não
2607:5300:60:846f::1 não

Descrição do teste:

Verificamos se o seu servidor web oferece suporte à compressão HTTP.

A compressão HTTP torna a conexão segura com seu servidor web vulnerável ao ataque BREACH. No entanto, a compressão HTTP é comumente utilizada para tornar mais eficiente o uso da banda de Internet disponível. Avalie se compensa utilizar compressão HTTP. Se você optar pelo uso da compressão, verifique se é possível mitigar ataques no nível de aplicação. Um exemplo é limitar quanto um atacante pode influenciar as respostas de um servidor.

Este subteste verifica se o servidor web oferece suporte à compressão HTTP no nível do diretório raiz. No entanto, não verifica fontes adicionais no site, como imagens e scripts.

Ver IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL, diretriz B7-1 e tabela 11.

Nível de exigência: Opcional


Opções de compressão

  • Bom: Sem compressão
  • Suficiente: Compressão no nível da aplicação (no caso de uso de compressão HTTP)
  • Insuficiente: Compressão TLS

Resultado:

Seu servidor web oferece uma política de HSTS.

Detalhes técnicos:

Endereço IP do servidor web Política de HSTS
158.69.55.111 max-age=63072000; includeSubDomains
2607:5300:60:846f::1 max-age=63072000; includeSubDomains

Descrição do teste:

Verificamos se seu servidor web oferece suporte a HSTS.

Os navegadores se "lembram" do HSTS por (sub)domínio. Não adicionar um cabeçalho HSTS a cada (sub)domínio, em uma cadeia de redirecionamento, pode deixar os usuários vulneráveis a ataques do tipo MITM (man-in-the-middle), portanto, verificamos a existência de HSTS no primeiro contato, ou seja, antes de qualquer redirecionamento.

O HSTS força um navegador web a se conectar diretamente via HTTPS ao revisitar seu site. Isto ajuda a prevenir ataques MITM. Consideramos um período de validade do cache HSTS de pelo menos um ano (max-age=31536000) para ser suficientemente seguro. Um período longo é benéfico pois também protege os visitantes pouco frequentes. Entretanto, se você quiser parar de dar suporte a HTTPS, o que não é uma boa ideia, terá que esperar mais tempo até que a validade da política do HSTS em todos os navegadores que visitaram seu site tenha expirado.

Ver Best Practices: Infrastructure Security, Internet Society, diretriz 5.

TLS

Resultado:

Seu servidor web oferece suporte apenas a versões seguras de TLS.

Detalhes técnicos:

Endereço IP do servidor web Versão de TLS afetada
158.69.55.111 Nenhum(a)
2607:5300:60:846f::1 Nenhum(a)

Descrição do teste:

Verificamos se seu servidor web oferece suporte apenas a versões seguras de TLS.

Um servidor web pode oferecer suporte a mais de uma versão de TLS.

Observe que os fabricantes de navegadores anunciaram que deixarão de oferecer suporte a TLS 1.1 e 1.0. Isto fará com que os sites que não oferecem suporte a TLS 1.2 e/ou 1.3 fiquem inacessíveis.

Ver IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL, diretriz B1-1 e tabela 1.


Versão

  • Bom: TLS 1.3
  • Suficiente: TLS 1.2
  • Desatualizado: TLS 1.1 e 1.0
  • Insuficiente: SSL 3.0, 2.0 e 1.0

Resultado:

Seu servidor web oferece suporte apenas a cifras seguras.

Detalhes técnicos:

Endereço IP do servidor web Cifras afetadas
158.69.55.111 Nenhum(a)
2607:5300:60:846f::1 Nenhum(a)

Descrição do teste:

Verificamos se seu servidor web oferece suporte somente a cifras seguras, ou seja, cifras Boas e/ou Suficientes. Cifras também são conhecidas como seleções de algoritmos.

Uma seleção de algoritmos consiste em cifras para quatro funções criptográficas:

  • 1) troca de chaves;

  • 2) verificação de certificados;

  • 3) criptografia do conteúdo principal;

  • 4) hash.

Um servidor web pode oferecer suporte a mais de uma seleção de algoritmos.

  • A partir da versão de TLS 1.3, o termo "conjunto de cifras" (cipher suite) compreende apenas cifras usadas para criptografia do conteúdo principal e hash. Ao utilizar TLS 1.3, as cifras para troca de chaves e verificação de certificados são negociáveis e não fazem parte do "conjunto de cifras". Como isto torna o termo "conjunto de cifras" ambíguo, a NCSC-NL usa o termo seleção de algoritmos para compreender todas as quatro funções de cifras.

  • A NCSC-NL usa a convenção de nomes da IANA para seleções de algoritmos. O TOP utiliza a convenção de nomes do OpenSSL. A partir da versão de TLS 1.3 o OpenSSL segue a convenção de nomes da IANA. Uma tradução entre ambas as convenções pode ser encontrada na documentação do OpenSSL.

  • Observe que as cifras que usam PSK ou SRP para troca de chaves, que não são suficientemente seguras, não são detectadas neste teste devido a uma limitação relacionada ao nosso método de teste.

Ver IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL, diretriz B2-1 a B2-4 e tabelas 2, 4, 6 e 7.


Abaixo você encontrará as seleções de algoritmos com status Bom, Suficiente e Desatualizado na ordem pré-determinada pela NCSC-NL, com base no apêndice C das IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL. Ao lado de cada seleção de algoritmos está a versão mínima de TLS (por exemplo, [1.2]) que oferece suporte a esta seleção de algoritmos e que tenha no mínimo o status desatualizado.

Bom:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 na versão 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 na versão 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 na versão 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 na versão 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 na versão 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 na versão 1.3) [1.2]

Suficiente:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Desatualizado:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]

Resultado:

Seu servidor web impõe sua própria cifra de preferência (I) e oferece cifras de acordo com ordem recomendada (II).

Detalhes técnicos:

Endereço IP do servidor web Primeiro par de cifras afetado encontrado
158.69.55.111 Nenhum(a)
2607:5300:60:846f::1 Nenhum(a)

Descrição do teste:

Verificamos se seu servidor web impõe sua própria preferência de cifras (I) e oferece cifras de acordo com a ordem recomendada (II).

Quando seu servidor web oferece suporte apenas a cifras Boas, este teste não é aplicável, pois a ordem não apresenta vantagem significativa em termos de segurança.

I. Servidor impõe sua preferência de cifra: O servidor web impõe sua própria preferência de cifra enquanto negocia com um navegador web, e não aceita qualquer preferência do navegador web;

II. Ordem recomendada: As cifras são oferecidas pelo servidor web, de acordo com a ordem recomendada, onde cifras Boas são preferíveis sobre Suficientes que são preferíveis sobre Desatualizadas.

Na tabela acima, com os detalhes técnicos, estão listadas somente as primeiras seleções de algoritmos encontradas na ordem recomendada.

Ver IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL, diretriz B2-5.

Resultado:

Seu servidor web oferece suporte a parâmetros seguros para a troca de chaves Diffie-Hellman.

Detalhes técnicos:

Endereço IP do servidor web Parâmetros afetados
158.69.55.111 Nenhum(a)
2607:5300:60:846f::1 Nenhum(a)

Descrição do teste:

Verificamos se os parâmetros públicos usados na troca de chaves Diffie-Hellman por seu servidor web são seguros.

ECDHE: A segurança da troca de chaves que utiliza o método Diffie-Hellman Efêmero com curva elíptica (ECDHE) depende da curva escolhida. Verificamos se a quantidade de bits das curvas elípticas usadas é de pelo menos 224 bits. Atualmente não somos capazes de verificar o nome da curva elíptica.

DHE: A segurança da troca de chaves que utiliza Diffie-Hellman Efêmero (DHE) depende do comprimento das chaves públicas e secretas usadas no grupo de campos finitos escolhido. Verificamos se sua chave pública DHE usa um dos grupos de campos finitos pré-definidos especificados em RFC 7919: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS). Os grupos autogerados são Insuficientes.

As chaves de tamanhos maiores, necessárias para o uso de DHE, penaliza o desempenho de processamento. Se puder, avalie e use o ECDHE ao invés do DHE.

RSA como uma alternativa: Além do ECDHE e do DHE, a RSA pode ser usada para a troca de chaves. No entanto, ela pode se tornar insuficientemente segura, pois seu status atual é desatualizado. Os parâmetros públicos da RSA são testados no subteste Chave pública do certificado. Observe que a RSA é considerada boa para verificação de certificados.

Ver IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL, diretriz B5-1 e tabela 9 para ECDHE, e diretriz B6-1 e tabela 10 para DHE.


Curvas elípticas para ECDHE

  • Bom: secp384r1, secp256r1, x448, e x25519.
  • Desatualizado: secp224r1
  • Insuficiente: Outras curvas

Grupo de campo finito para DHE

  • Suficiente:

    • ffdhe4096 (RFC 7919) sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919) sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • Observe que também testamos para ffdhe8192 e ffdhe6144. No entanto, seu ganho limitado em segurança raramente supera a perda de desempenho.
  • Desatualizado:

    • ffdhe2048 (RFC 7919) sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b
  • Insuficiente: Outros grupos

Resultado:

Seu servidor web oferece suporte a uma função hash segura para troca de chaves.

Detalhes técnicos:

Endereço IP do servidor web Suporte SHA2 para assinaturas
158.69.55.111 sim
2607:5300:60:846f::1 sim

Descrição do teste:

Verificamos se seu servidor web oferece suporte a funções de hash seguras para criar a assinatura digital durante a troca de chaves.

O servidor web usa uma assinatura digital durante a troca de chaves para comprovar a propriedade da chave secreta correspondente ao certificado. O servidor web cria esta assinatura digital ao assinar a saída de uma função hash.

Ver IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL, tabela 5.

Nível de exigência: Recomendado


Suporte SHA2 para assinaturas

  • Bom: Sim (SHA-256, SHA-384 ou SHA-512 suportados)
  • Desatualizado: Não (SHA-256, SHA-384 ou SHA-512 não suportados)

Resultado:

Seu servidor web não oferece suporte à compressão TLS.

Detalhes técnicos:

Endereço IP do servidor web Compressão TLS
158.69.55.111 não
2607:5300:60:846f::1 não

Descrição do teste:

Verificamos se seu servidor web oferece suporte à compressão TLS.

O uso de compressão pode dar ao atacante informações sobre partes secretas da comunicação criptografada. Um atacante capaz de determinar ou controlar partes dos dados enviados pode reconstruir os dados originais realizando um grande número de solicitações. A compressão TLS é usada tão raramente que desativá-la geralmente não é um problema.

Ver IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL, diretriz B7-1 e tabela 11.


Opções de compressão

  • Bom: Sem compressão
  • Suficiente: Compressão no nível da aplicação (no caso de uso de compressão HTTP)
  • Insuficiente: Compressão TLS

Resultado:

Seu servidor web oferece suporte a uma renegociação segura.

Detalhes técnicos:

Endereço IP do servidor web Renegociação segura
158.69.55.111 sim
2607:5300:60:846f::1 sim

Descrição do teste:

Verificamos se seu servidor web oferece suporte a uma renegociação segura.

As versões mais antigas de TLS, anteriores a TLS 1.3, permitem forçar um novo processo de handshake. Esta renegociação era insegura em seu projeto original. O padrão foi reparado e um mecanismo de renegociação mais seguro foi adicionado. A versão antiga é, desde então, chamada de renegociação insegura e deve ser desativada.

Ver IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL, diretriz B8-1 e tabela 12.


Renegociação insegura

  • Bom: Desativada (ou não aplicável para TLS 1.3)
  • Insuficiente: Ativada

Resultado:

Seu servidor web não permite a renegociação iniciada pelo cliente.

Detalhes técnicos:

Endereço IP do servidor web Renegociação iniciada pelo cliente
158.69.55.111 não
2607:5300:60:846f::1 não

Descrição do teste:

Verificamos se um cliente, normalmente um navegador web, pode iniciar uma renegociação com o seu servidor web.

Permitir aos clientes iniciar a renegociação geralmente não é necessário e deixa o servidor web aberto a ataques DoS dentro de uma conexão TLS. Um atacante pode realizar ataques DoS semelhantes sem a renegociação iniciada pelo cliente, abrindo muitas conexões TLS paralelas, mas estas são mais fáceis de detectar e de se defender, usando ações de mitigação padrão. Observe que a renegociação iniciada pelo cliente afeta a disponibilidade e não a confidencialidade.

Ver IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL, diretriz B8-1 e tabela 13.

Nível de exigência: Opcional


Renegociação iniciada pelo cliente

  • Bom: Desativada (ou não aplicável para TLS 1.3)
  • Suficiente: Ativada

Resultado:

Seu servidor web não oferece suporte a 0-RTT.

Detalhes técnicos:

Endereço IP do servidor web 0-RTT
158.69.55.111 não
2607:5300:60:846f::1 não

Descrição do teste:

Verificamos se o seu servidor web oferece suporte a Zero Round Trip Time Resumption (0-RTT).

0-RTT é uma opção na versão TLS 1.3 que transporta dados de aplicação durante a primeira mensagem de handshake. O 0-RTT não oferece proteção contra ataques de repetição na camada TLS e, portanto, deve ser desativado. Embora seja possível mitigar o risco ao não permitir 0-RTT para solicitações não idempotentes, essa configuração geralmente não é trivial, depende da lógica da aplicação e, portanto, está sujeita a erros.

Se seu servidor web não oferece suporte a TLS 1.3, o teste não é aplicável. Para servidores web que oferecem suporte a TLS 1.3, a página de índice / do site é obtida usando TLS 1.3 e o limite suportado de early data do servidor é verificado. Quando for maior do que zero, uma segunda conexão é feita, reutilizando os detalhes da sessão TLS da primeira conexão, mas enviando a solicitação HTTP antes do processo de handshake de TLS, ou seja, sem necessidade de round trips (0-RTT) antes dos dados de aplicação para o servidor. Se o processo de handshake de TLS for concluído e o servidor web responder com qualquer resposta que não seja HTTP 425 Too Early, o servidor web será considerado como oferecendo suporte a 0-RTT.

Ver IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL, diretriz B9-1 e tabela 14.


0-RTT

  • Bom: Desativado (ou não aplicável antes da versão de TLS 1.3)
  • Insuficiente: Ativado

Resultado:

Seu servidor web oferece suporte a OCSP stapling e os dados na resposta são válidos.

Detalhes técnicos:

Endereço IP do servidor web OCSP stapling
158.69.55.111 sim
2607:5300:60:846f::1 sim

Descrição do teste:

Verificamos se seu servidor web oferece suporte à RFC 6961: The Transport Layer Security (TLS) Multiple Certificate Status Request Extension, também conhecida como OCSP stapling.

O navegador web pode verificar a validade do certificado apresentado pelo servidor web entrando em contato com a autoridade certificadora, usando o protocolo OCSP. O OCSP fornece informações sobre navegadores que se comunicam com o servidor web à autoridade certificadora: isso pode acarretar um risco à privacidade. Um servidor web também pode fornecer respostas OCSP aos próprios navegadores web por OCSP stapling. Isto resolve este risco à privacidade, não requer conectividade entre o navegador web e a autoridade certificadora e é mais rápido.

Ao conectarmos ao seu servidor web, usamos a extensão TLS Certificate Status para solicitar que os dados OCSP sejam incluídos na resposta do servidor. Se seu servidor web incluir dados OCSP na resposta, verificaremos se os dados OCSP são válidos, ou seja, se são assinados corretamente por uma autoridade certificadora conhecida.

Nota: Não utilizamos os dados do OCSP para avaliar a validade do certificado.

Ver IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL, tabela 15.

Nível de exigência: Opcional


OCSP Stapling

  • Bom: Ativado
  • Suficiente: Desativado

Certificado

Resultado:

A cadeia de confiança do certificado do seu site está completa e assinada por uma autoridade certificadora raiz confiável.

Detalhes técnicos:

Endereço IP do servidor web Cadeia não confiável de certificados
158.69.55.111 Nenhum(a)
2607:5300:60:846f::1 Nenhum(a)

Descrição do teste:

Verificamos se somos capazes de construir uma cadeia de confiança válida para o certificado do seu site.

Para ter uma cadeia de confiança válida, seu certificado deve ser publicado por uma autoridade certificadora publicamente confiável, e seu servidor web deve apresentar todos os certificados intermediários necessários.

Ver IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL, diretriz B3-4.

Resultado:

A assinatura digital do certificado de seu site usa parâmetros seguros.

Detalhes técnicos:

Endereço IP do servidor web Parâmetros de assinatura afetados
158.69.55.111 Nenhum(a)
2607:5300:60:846f::1 Nenhum(a)

Descrição do teste:

Verificamos se a assinatura digital (ECDSA ou RSA) do certificado do seu site utiliza parâmetros seguros.

A verificação dos certificados utiliza assinaturas digitais. Para garantir a autenticidade de uma conexão, deve-se usar um algoritmo confiável para a verificação do certificado. O algoritmo utilizado para assinar um certificado é selecionado pelo fornecedor daquele certificado. O certificado especifica o algoritmo para assinaturas digitais que é usado pelo seu proprietário durante a troca de chaves. É possível configurar vários certificados para oferecer suporte a mais de um algoritmo.

A segurança das assinaturas digitais ECDSA depende da curva escolhida. A segurança RSA para criptografia e assinaturas digitais é vinculada ao comprimento da chave pública.

Ver IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL, diretriz B5-1 e tabela 9 para ECDSA, e diretriz B3-3 e tabela 8 para RSA.


Curvas elípticas para ECDSA

  • Bom: secp384r1, secp256r1, x448, e x25519.
  • Desatualizado: secp224r1
  • Insuficiente: Outras curvas

Comprimento das chaves RSA

  • Bom: Ao menos 3072 bits
  • Suficiente: 2048 - 3071 bits
  • Insuficiente: Menos de 2048 bits

Resultado:

O certificado do seu site é assinado usando um algoritmo de hash seguro.

Detalhes técnicos:

Endereço IP do servidor web Algoritmo de hash afetado
158.69.55.111 Nenhum(a)
2607:5300:60:846f::1 Nenhum(a)

Descrição do teste:

Verificamos se a assinatura do certificado do site foi criada com um algoritmo de hash seguro.

Ver IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL, diretriz B3-2 e tabela 3.


Funções de hash para verificação de certificados

  • Bom: SHA-512, SHA-384, SHA-256
  • Insuficiente: SHA-1, MD5

Resultado:

O nome de domínio de seu site corresponde ao nome de domínio no certificado do seu site.

Detalhes técnicos:

Endereço IP do servidor web Domínios sem correspondência no certificado
158.69.55.111 Nenhum(a)
2607:5300:60:846f::1 Nenhum(a)

Descrição do teste:

Verificamos se o nome de domínio de seu site corresponde ao nome de domínio no certificado.

Poderia ser útil incluir mais de um domínio como Subject Alternative Name (SAN) no certificado, por exemplo, com e sem www.

Ver IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL, diretriz B3-1.

DANE

Resultado:

O domínio do seu site não contém um registro TLSA para DANE.

Detalhes técnicos:

Endereço IP do servidor web Registro TLSA para DANE existente
158.69.55.111 não
2607:5300:60:846f::1 não

Descrição do teste:

Verificamos se os servidores de nomes do domínio do seu site contêm um registro TLSA assinado corretamente para o protocolo DANE.

Como DNSSEC é pré-requisito para o DANE, este teste terá um resultado negativo, caso não haja DNSSEC no domínio do site, ou se houver problemas no DANE relacionados ao DNSSEC, como, por exemplo, ausência de prova de Negação de Existência (Denial of Existence).

Ver IT Security Guidelines for Transport Layer Security (TLS) v2.1, NCSC-NL, Apêndice A, em Certificate pinning and DANE.

Nível de exigência: Opcional

Resultado:

Este subteste não foi realizado, porque um teste principal, do qual este subteste depende, apresentou um resultado negativo, ou porque não há informações suficientes disponíveis para realizá-lo.

Detalhes técnicos:

Endereço IP do servidor web Registro TLSA para DANE válido
158.69.55.111 não testado
2607:5300:60:846f::1 não testado

Descrição do teste:

Verificamos se a assinatura DANE apresentada pelo seu domínio é válida para o seu certificado web.

DANE permite que você publique informações sobre o seu certificado de site em um registro DNS especial, chamado registro TLSA. Clientes, como navegadores web, podem verificar a autenticidade do seu certificado não apenas através da autoridade certificadora, mas também pelo registro TLSA. Um cliente também pode usar o registro TLSA como um sinal para usar apenas HTTPS e não HTTP. O DNSSEC é pré-requisito para DANE. Infelizmente ainda não há muitos navegadores na Web que ofereçam suporte à validação de DANE.

Nível de exigência: Recomendado (apenas se passar no subteste para Existência de DANE)


Recomendação : Opções de segurança

Aviso: Nem todas as opções de segurança de aplicação recomendadas estão configuradas para o seu site (Opções de segurança). Com estas opções você pode ativar mecanismos de navegador para proteger os visitantes contra ataques como, por exemplo, cross-site scripting (XSS) ou inclusão em frames (framing). Observe que consideramos o HTTPS uma exigência para esta categoria de teste, e que estas opções de segurança não são relevantes para sites que foram redirecionados permanente ou provisoriamente (redirect 301 / 302).

Cabeçalhos de segurança HTTP

Resultado:

Seu servidor web oferece X-Frame-Options configuradas de maneira segura.

Detalhes técnicos:

Endereço IP do servidor web Valor de X-Frame-Options
158.69.55.111 SAMEORIGIN
2607:5300:60:846f::1 SAMEORIGIN

Descrição do teste:

Verificamos se seu servidor web fornece um cabeçalho HTTP para X-Frame-Options que tenha uma política suficientemente segura. Com este cabeçalho HTTP você informa aos navegadores web se deseja permitir que seu site seja incluído em frames (framed) ou não. A prevenção de inclusão em frames (framing) defende os visitantes contra ataques como clickjacking. Consideramos que os seguintes valores são suficientemente seguros:

  • DENY (inclusão em frames (framing) não permitido); ou
  • SAMEORIGIN (permitido somente a inclusão em frames (framing) pelo seu próprio site).

Embora o valor ALLOW-FROM, que permite que apenas sites específicos realizem a inclusão em frames (framing) seu site, faça parte da especificação X-Frame-Options (RFC 7034: HTTP Header Field X-Frame-Options), não é compatível com a maioria dos navegadores modernos, portanto, não consideramos esse valor como suficientemente seguro.

Observe que Content-Security-Policy (CSP) oferece proteção semelhante por frame-ancestors e, além disso, é muito mais adequado para visitantes com navegadores modernos. Entretanto, as X-Frame-Options ainda poderiam proteger os visitantes de navegadores web mais antigos que não oferecem suporte a CSP. Além disso, as X-Frame-Options poderiam oferecer proteção valiosa para todos os visitantes quando o CSP não estiver configurado corretamente para o site em questão.

Ver também Content Security Policy Level 2, W3C Recommendation.

Nível de exigência: Opcional

Resultado:

Seu servidor web oferece opções de X-Content-Type.

Detalhes técnicos:

Endereço IP do servidor web Valor do X-Content-Type
158.69.55.111 nosniff
2607:5300:60:846f::1 nosniff

Descrição do teste:

Verificamos se seu servidor web fornece um cabeçalho HTTP para X-Content-Type. Com este cabeçalho HTTP você permite que os navegadores web saibam que eles não devem fazer "MIME type sniffing" e sempre devem seguir o Content-Type conforme declarado pelo seu servidor web. O único valor válido para este cabeçalho HTTP é nosniff. Quando ativado, um navegador bloqueará os pedidos de style and script quando eles não tiverem um Content-Type correspondente, ou seja, text/css ou um "JavaScript MIME type" como application/javascript.

"MIME type sniffing" é uma técnica em que o navegador escaneia o conteúdo de um arquivo para detectar o formato de um arquivo independentemente do Content-Type declarado pelo servidor web. Esta técnica é vulnerável ao chamado "ataque MIME confusion", no qual o atacante manipula o conteúdo de um arquivo de forma que ele seja tratado pelo navegador como um Content-Type diferente, como um executável.

Nível de exigência: Recomendado

Resultado:

Seu servidor web não oferece Content-Security-Policy (CSP), ou oferece CSP com certas configurações inseguras.

Detalhes técnicos:

Endereço IP do servidor web Valor da CSP
158.69.55.111 upgrade-insecure-requests;
2607:5300:60:846f::1 upgrade-insecure-requests;

Descrição do teste:

Verificamos se o seu servidor web fornece um cabeçalho HTTP para Content-Security-Policy (CSP). Além disso, verificamos várias configurações de CSP (in)seguras, embora não testemos exaustivamente a eficácia de sua configuração de CSP.

O CSP protege um site contra ataques de injeção de conteúdo, incluindo cross-site scripting (XSS). Ao usar o CSP para configurar uma lista de permissões (allowlist) com origens de conteúdo aprovadas, você evita que os navegadores obtenham conteúdo malicioso de atacantes.

Testamos as configurações abaixo, que são a base de uma configuração CSP segura.

  1. default-src deve ser definido para ter uma política de retorno ao padrão restritivo para os tipos de origens de conteúdo que são usados em seu site para os quais nenhuma política específica foi definida. O valor deve ser 'none' ou 'self'. Além disso, o próprio domínio, ou um subdomínio ou superdomínio também pode ser definido. Na sequência a esses valores, 'report-sample' pode ser usado, caso você queira que as amostras de código sejam enviadas junto com os relatórios de violação. Além disso, permitimos https:, embora você não precise dele se seguir as configurações abaixo.

  2. frame-src deve ser usado, ou por definição ou retornando para child-src e default-src, e ter o valor 'none', 'self' ou um URL específico, a fim de evitar que outras origens de conteúdo carregadas em seu site realizem a inclusão de frames (framing) ou incorporem origens de conteúdo externas com elementos HTML, como <frame> e <iframe>.

  3. frame-ancestors devem ser definidos e ter o valor 'none', 'self' ou um URL específico, a fim de evitar que outros sites realizem a inclusão de frames (framing) ou incorporem seu site usando elementos HTML <frame>, <iframe>, <object>, <embed> ou <applet>.

  4. unsafe-inline, unsafe-eval e unsafe-hashes não devem ser usados, porque habilitam ataques XSS.

  5. data: não deve ser usado em default-src, script-src e object-src, porque permite ataques XSS.

  6. http: não deve ser usado como um esquema, porque permite que os recursos sejam baixados por uma conexão insegura. Use https: em vez disso.

  7. * asterisco para o esquema e host como parte de qualquer URL, não deve ser usado em qualquer diretiva, porque isso permite qualquer origem de conteúdo externa.

  8. 127.0.0.1 não deve ser usado em nenhuma diretiva, porque permite ataques de injeção de conteúdo em um sistema comprometido.

Observe que, em geral, recomendamos que você permita domínios nas diretivas CSP tão específicos quanto possível, que é testado automaticamente até certo ponto neste subteste para CSP. Além disso, não recomendamos permitir todos os domínios sob um TLD (*.br) ou SLD (*.gov.br), embora atualmente não façamos testes para isso. Também não recomendamos permitir um domínio diferente em um SLD em default-src, por exemplo, permitir exemplo1.gov.br para exemplo2.gov.br, embora atualmente tampouco testemos isso.

Além disso, recomendamos que você use primeiro o cabeçalho HTTP para Content-Security-Policy-Report-Only para experimentar a configuração do seu CSP, monitorando seu efeito sem aplicá-lo.

Ver também Content-Security-Policy, MDN Web Docs.

Nível de exigência: Recomendado

Resultado:

Seu servidor web oferece Referrer-Policy.

Detalhes técnicos:

Endereço IP do servidor web Valor da Referrer-Policy
158.69.55.111 no-referrer-when-downgrade
2607:5300:60:846f::1 no-referrer-when-downgrade

Descrição do teste:

Verificamos se seu servidor web fornece um cabeçalho HTTP para Referrer-Policy. Com este cabeçalho HTTP você informa aos navegadores quais informações de referência, enviadas no cabeçalho Referer, devem fazer parte da solicitação do site. O cabeçalho Referer contém o endereço da página anterior, a partir da qual o visitante seguiu um link para a página solicitada.

As informações no cabeçalho Referer são utilizadas principalmente para análise e registro (logging). No entanto, pode haver riscos à privacidade e à segurança. As informações poderiam ser usadas, por exemplo, para rastreamento de usuários e poderiam vazar para terceiros que interceptassem a conexão. Com o cabeçalho HTTP para Referrer-Policy você pode mitigar estes riscos.

Atualmente nós não avaliamos a eficácia do valor configurado da Referrer-Policy. Entretanto, sugerimos tomar uma decisão fundamentada, tendo em mente os riscos de privacidade e segurança, sobre o uso de um dos valores da política das duas primeiras categorias abaixo.

Valores recomendados da política:

  1. Sem dados confidenciais para terceiros

    • no-referrer
    • same-origin
  2. Dados confidenciais para terceiros somente por conexões seguras (HTTPS)

    • strict-origin
    • strict-origin-when-cross-origin

Valores não recomendados da política:

  1. Dados confidenciais para terceiros possivelmente por conexões inseguras (HTTP)
    • no-referrer-when-downgrade (política padrão dos navegadores)
    • origin-when-cross-origin
    • origin
    • unsafe-url

Nível de exigência: Recomendado

Teste outro site

Teste outro e-mail

Teste TOP - IPv6 e DNSSEC da sua rede


Apoiadores