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

Aprovado : Endereço IP moderno (IPv6)

Muito bem! Seu servidor de e-mail pode ser acessado pelos remetentes usando endereços modernos (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(es) de e-mail

Resultado:

Todos os servidores de recebimento de e-mail em seu domínio têm um endereço IPv6.

Detalhes técnicos:

Servidor de e-mail (MX) 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 cada servidor de recebimento de e-mail (MX). Caso nenhum servidor de e-mail esteja definido, enviamos uma notificação e executamos outros subtestes do teste de e-mail que também são relevantes.

Resultado:

Todos os seus servidores de recebimento de e-mail com endereço IPv6 são acessíveis via IPv6.

Descrição do teste:

Verificamos se podemos nos conectar com seus servidores de e-mail (MX) via IPv6 na porta 25. Testamos todos os endereços IPv6 que recebemos dos servidores de nomes do(s) seu(s) domínio(s) de servidor de e-mail. 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.

Aprovado : Nomes de domínio assinados (DNSSEC)

Muito bem! O domínio do seu endereço de e-mail e o(s) domínio(s) do servidor de e-mail são assinados com uma assinatura válida (DNSSEC), portanto, os remetentes com validação de assinatura de domínio habilitada podem consultar, de forma confiável, o endereço IP do(s) seus(s) servidor(es) de recebimento de e-mail.
Domínio do endereço de e-mail

Resultado:

Seu domínio de endereço de e-mail é assinado com DNSSEC.

Detalhes técnicos:

Domínio do endereço de e-mail Registro de domínios
mmhospedagem.com.br Nenhum(a)

Descrição do teste:

Verificamos se o seu domínio, mais especificamente seu registro SOA, possui assinatura DNSSEC. Com uma assinatura DNSSEC os remetentes que validam assinaturas de domínio podem verificar a autenticidade da resposta DNS que contém seus domínios de servidor de e-mail (MX). Isto impede que um atacante manipule a resposta DNS, a fim de redirecionar os e-mails enviados a você para o domínio do servidor de e-mail do atacante.

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 de endereço de e-mail é seguro, pois sua assinatura DNSSEC é válida.

Detalhes técnicos:

Domínio de endereço de e-mail Status
mmhospedagem.com.br seguro

Descrição do teste:

Verificamos se o seu domínio, mais especificamente seu registro SOA, é assinado com uma assinatura válida, o que o torna 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.

Domínio(s) do(s) servidor(es) de e-mail

Resultado:

Todos os seus domínios de servidores de e-mail possuem assinatura DNSSEC.

Detalhes técnicos:

Domínio do servidor de e-mail (MX) DNSSEC existente
mmhospedagem.com.br. sim

Descrição do teste:

Verificamos se os domínios dos seus servidores de e-mail (MX), mais especificamente seus registros SOA, possuem assinatura DNSSEC. Com uma assinatura DNSSEC os remetentes que validam as assinaturas de domínio podem verificar a autenticidade da resposta DNS contendo os endereços IP e os registros DANE do(s) seu(s) servidor(es) de e-mail. Isto impede que um atacante manipule a resposta DNS para redirecionar e-mails enviados a você para um endereço IP controlado pelo atacante ou para interceptar a conexão segura do servidor de e-mail.

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:

Todos os domínios dos seus servidores de e-mail assinados são seguros, pois suas assinaturas DNSSEC são válidas.

Detalhes técnicos:

Domínio do servidor de e-mail (MX) Status
mmhospedagem.com.br. seguro

Descrição do teste:

Verificamos se os domínios dos seus servidores de recebimento de e-mail (MX), mais especificamente seus registros SOA, estão assinados com uma assinatura válida que os torna seguros.

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 : Marcas de autenticidade contra phishing (DMARC, DKIM and SPF)

Muito bem! Seu domínio contém todas as marcas de autenticidade contra falsificação de e-mail (DMARC, DKIM and SPF), portanto, os destinatários são capazes de separar, de forma confiável, e-mails de phishing e spam que abusam do seu domínio no endereço do remetente, dos seus e-mails autênticos.
DMARC

Resultado:

Seu domínio tem um registro DMARC.

Detalhes técnicos:

Registro DMARC Encontrado
v=DMARC1;p=reject;pct=100;rua=mailto:abuse@mmhospedagem.com.br;ruf=mailto:abuse@mmhospedagem.com.br mmhospedagem.com.br

Descrição do teste:

Verificamos se o DMARC está disponível para seu domínio. Um servidor de recebimento de e-mail pode usar sua política de DMARC para avaliar como tratar um e-mail recebido, tendo seu domínio como remetente, que não pôde ser autenticado tanto com DKIM como com SPF. Além disso pode usar seu endereço de e-mail do registro de DMARC para lhe fornecer relatórios de feedback com informações sobre a autenticação. Ter mais de um registro de DMARC no mesmo domínio não é válido e resultará em reprovação no teste.

Nota: O alinhamento de DMARC requer que o domínio SPF do remetente do envelope, ou seja, o caminho de retorno (return-path) que é disponível no campo MAIL FROM, e o domínio DKIM (d=) estejam alinhados com o domínio do corpo do e-mail (From:). Uma referência sobre o processo de alinhamento de DMARC pode ser encontrado em DMARC and the Email Authentication Process.

Resultado:

Sua política de DMARC é suficientemente rigorosa.

Descrição do teste:

Verificamos se a sintaxe do seu registro DMARC está correta e se ela contém uma política suficientemente rigorosa (p=quarantine ou p=reject), a fim de evitar abusos de seu domínio por parte de phishers e spammers. Mesmo sem uma política rigorosa, o DMARC pode ser útil para obter mais informações sobre fluxos de e-mail de saída legítimos e ilegítimos através dos relatórios DMARC. Entretanto, para ser eficaz contra o abuso do seu domínio, uma política liberal (p=none) é insuficiente.

Também verificamos se os endereços dos e-mails em rua= e ruf= são válidos. Caso contenham um endereço de e-mail externo, verificamos se o domínio externo está autorizado a receber relatórios DMARC. Certifique-se de que o registro de autorização DMARC no domínio externo contenha pelo menos "v=DMARC1;".

Boas práticas para domínios sem e-mail:

  • Não envia e-mail: Utilize as políticas mais rigorosas de DMARC (p=reject) e de SPF (-all) para domínios que você não utiliza para envio de e-mail, com o objetivo de prevenir abuso, ou seja, falsificação de endereço de remetente. Note que o DKIM não é necessário neste caso.

  • Não recebe e-mail: Ver a descrição do subteste STARTTLS disponível para mais informação sobre "Null MX" e "No MX".

Abaixo, você encontrará dois exemplos básicos de configurações de DNS para nomes de domínio que não são usados para enviar e receber e-mails.

A. Domínio único sem registro A ou AAAA

 `exemplo.br. TXT "v=spf1 -all"`
 `*.exemplo.br. TXT "v=spf1 -all"`
 `_dmarc.exemplo.br. TXT "v=DMARC1; p=reject;"`

B. Domínio único sem e-mail com registro A or AAAA

 `exemplo.br. AAAA 2001:db8::712:94:198:159:35`
 `exemplo.br. A 192.0.2.35`
 `exemplo.br. MX 0 .`
 `exemplo.br. TXT "v=spf1 -all"`
 `*.exemplo.br. TXT "v=spf1 -all"`
 `www.exemplo.br. CNAME exemplo.br`
 `_dmarc.exemplo.br. TXT "v=DMARC1; p=reject;"`
DKIM

Resultado:

Seu domínio oferece suporte a registros DKIM.

Descrição do teste:

Verificamos se o seu domínio oferece suporte a registros DKIM. Um servidor de recebimento de e-mail pode usar a chave pública de seu registro DKIM para validar a assinatura em um e-mail tendo um usuário do seu domínio como remetente e determinar sua autenticidade.

  • No momento não conseguimos consultar e avaliar a chave pública em seu registro DKIM, pois, para isso, precisaríamos do seletor de DKIM que deveria estar nos e-mails que você envia.
  • Para passar neste teste esperamos que o seu servidor de nomes responda NOERROR à nossa consulta para _domainkey.exemplo.br. Quando _domainkey.exemplo.br for um "empty-non-terminal" alguns servidores de nomes, que não estão de acordo com a RFC 2308: Negative Caching of DNS Queries (DNS NCACHE), respondem incorretamente NXDOMAIN em vez de NOERROR. Isto faz com que não possamos detectar o suporte para os registros DKIM.
  • Para este teste assumimos um alinhamento estrito que está de acordo com DMARC. O domínio informado é considerado como sendo o remetente do domínio no corpo do e-mail (From:) e este deve ser idêntico ao domínio DKIM (d=) e ao domínio SPF do remetente do envelope, ou seja, o caminho de retorno que é disponível no campo MAIL FROM. Uma referência sobre o processo de alinhamento de DMARC pode ser encontrado em ""DMARC and the Email Authentication Process**.

Ver a descrição do subteste Política de DMARC para boas práticas sobre domínios sem e-mail.

SPF

Resultado:

Seu domínio tem um registro SPF.

Detalhes técnicos:

Registro SPF
v=spf1 +a +mx +a:servidor.hospedagemdesite.goiania.br +ip4:167.114.41.239 +ip6:2607:5300:60:846f:: -all

Descrição do teste:

Verificamos se seu domínio tem um registro SPF. Um servidor de recebimento de e-mail pode usar sua relação de servidores de envio de e-mail permitidos e a correspondente política do seu registro SPF para determinar a autenticidade de um e-mail recebido com seu domínio como remetente. Ter mais do que um registro SPF no mesmo domínio não é válido e conduzirá a falha no teste..

Ver a descrição do subteste Política de DMARC para boas práticas sobre domínios sem e-mail.

Resultado:

Sua política de SPF é suficientemente rigorosa.

Descrição do teste:

Verificamos se a sintaxe do seu registro SPF está correta e se contém uma política suficientemente rigorosa, ou seja, ~all (softfail) ou -all (hardfail) a fim de evitar abuso por parte de phishers e spammers. Para ser eficaz contra abuso do seu domínio, uma política liberal, isto é, +all (pass) ou?all (neutral) é insuficiente. Se all estiver faltando e um modificador redirect não estiver presente em seu registro SPF, o padrão é ?all.

Também consideramos include e redirect para registros SPF válidos. Um máximo de 10 consultas de DNS são permitidas quando eles forem considerados. Se o domínio include ou redirect consistir de macros, não os consideraremos, pois não temos as informações necessárias sobre uma conexão real de e-mail ou servidor de e-mail para expandir essas macros.

Ver a descrição do subteste Política de DMARC para boas práticas sobre domínios sem e-mail.


Falha : Conexão segura com servidor de e-mail (STARTTLS e DANE)

Que pena! Os servidores de envio de e-mail que oferecem suporte ao transporte seguro de e-mail (STARTTLS e DANE) não podem estabelecer ou estabelecem uma conexão insuficientemente segura com seu(s) servidor(es) de recebimento de e-mail. Os atacantes passivos e/ou ativos poderão, portanto, ler e-mails em trânsito enviados para você. Solicite ao seu provedor de serviço de e-mail que habilite STARTTLS e DANE, e configure ambos de maneira segura.
TLS

Resultado:

Todos os seus servidores de e-mail oferecem STARTTLS.

Detalhes técnicos:

Servidor de e-mail (MX) STARTTLS
mmhospedagem.com.br. sim

Descrição do teste:

Verificamos se seus servidores de recebimento de e-mail (MX) oferecem suporte a STARTTLS. Em caso afirmativo, também verificamos nos subtestes desta categoria se o STARTTLS está configurado de maneira suficientemente segura.

Observe que por razões de desempenho, no máximo dez servidores de e-mail com IPv6 ou IPv4 são testados para STARTTLS e DANE.

Domínio que não recebe e-mails:

  1. "Null MX": No caso em que você não queira receber e-mails em seu domínio que contenham registros A/AAAA, recomendamos o uso de "Null MX" (RFC 7505: A "Null MX" No Service Resource Record for Domains That Accept No Mail). Observe que um registro "Null MX" não deve ser combinado com um registro MX normal que aponta para um host de e-mail.

  2. "No MX": Caso seu domínio não tenha registros A/AAAA e você não queira receber e-mails nele, recomendamos que você não configure nenhum registro MX, nem mesmo um registro "Null MX". Observe que o teste de e-mail não utiliza os registros A/AAAA para servidores de e-mail no caso de ausência de um registro MX.

  3. Se detectarmos qualquer um dos dois casos acima, os subtestes nas categorias STARTTLS e DANE não são aplicáveis. Isso também se aplica aos subtestes específicos do servidor de e-mail nas categorias IPv6 e DNSSEC. Outros subtestes do teste de e-mail ainda são aplicáveis, por exemplo, para DMARC.

  4. Observe que ter um registro "Null MX" ou não ter um registro MX também poderia impactar o envio de e-mail, porque muitos servidores de recebimento rejeitam e-mails com endereço de retorno inválido.

Ver a descrição do subteste Política de DMARC para boas práticas sobre domínios sem e-mail.

Resultado:

Todos os seus servidores de e-mail oferecem suporte apenas a versões de TLS seguras.

Detalhes técnicos:

Servidor de e-mail (MX) Versões de TLS afetadas
mmhospedagem.com.br. Nenhum(a)

Descrição do teste:

Verificamos se seus servidores de e-mail (MX) oferecem suporte apenas a versões seguras de TLS.

Um servidor de e-mail pode oferecer suporte a mais de uma versão de TLS.

Observe que alguns servidores de e-mail oferecem suporte apenas a versões de TLS mais antigas. Se os servidores de envio e recebimento de e-mail não oferecerem suporte a mesma versão de TLS, ambos realizarão normalmente o transporte de e-mail não criptografado. Por isso, é aconselhável continuar oferecendo suporte as versões de TLS com o status desatualizado por algum tempo. Tome uma decisão fundamentada com base em dados de log sobre quando desabilitar essas versões de TLS com status desatualizado.

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:

Todos os seus servidores de e-mail oferecem suporte apenas a cifras seguras.

Detalhes técnicos:

Servidor de e-mail (MX) Primeiras cifras afetadas encontradas
mmhospedagem.com.br. Nenhum(a)

Descrição do teste:

Verificamos se seus servidores de recebimento de e-mail (MX) oferecem suporte somente a cifras seguras, ou seja, cifras Boas e/ou Suficientes, também conhecido como seleções de algoritmos.

Para não atingirmos os limites operacionais dos servidores de recebimento de e-mail, o resultado do teste contém apenas as primeiras seleções de algoritmos afetadas encontradas.

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.

Os servidores de recebimento de e-mail podem 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 usa a convenção de nomes 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 da 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:

Todos os seus servidores de e-mail impõem sua própria preferência de cifra (I) e oferecem cifras de acordo com a ordem recomendada (II).

Detalhes técnicos:

Servidor de e-mail (MX) Primeiro par de cifras afetado encontrado
mmhospedagem.com.br. Nenhum(a)

Descrição do teste:

Verificamos se seus servidores de recebimento de e-mail (MX) impõem sua própria preferência de cifras (I) e oferecem cifras de acordo com a ordem recomendada (II).

Quando seus servidores de e-mail oferecem 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: Os servidores de recebimento de e-mail impõem sua própria preferência de cifra enquanto negociam com os servidores de envio de e-mail, e não aceitam qualquer preferência dos servidores de envio de e-mail;

II. Ordem recomendada: As cifras são oferecidas pelo servidor de recebimento de e-mail, 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:

Todos os seus servidores de e-mail oferecem suporte a parâmetros seguros para troca de chaves Diffie-Hellman.

Detalhes técnicos:

Servidor de e-mail (MX) Parâmetros afetados
mmhospedagem.com.br. Nenhum(a)

Descrição do teste:

Verificamos se os parâmetros públicos usados na troca de chaves Diffie-Hellman por seus servidores de recebimento de e-mail (MX) 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:

Todos os seus servidores de e-mail oferecem suporte a funções de hash seguras para troca de chaves.

Detalhes técnicos:

Servidor de e-mail (MX) Suporte SHA2 para assinaturas
mmhospedagem.com.br. sim

Descrição do teste:

Verificamos se seus servidores de recebimento de e-mail (MX) oferecem suporte a funções de hash seguras para criar a assinatura digital durante a troca de chaves.

Um servidor de recebimento de e-mail usa uma assinatura digital durante a troca de chave para comprovar a propriedade da chave secreta correspondente ao certificado. O servidor de e-mail 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:

Nenhum dos seus servidores de e-mail oferece suporte à compressão TLS.

Detalhes técnicos:

Servidor de e-mail (MX) Compressão TLS
mmhospedagem.com.br. não

Descrição do teste:

Verificamos se seus servidores de recebimento de e-mail (MX) oferecem 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
  • Insuficiente: Compressão TLS

Resultado:

Todos os seus servidores de e-mail oferecem suporte à renegociação segura.

Detalhes técnicos:

Servidor de e-mail (MX) Renegociação segura
mmhospedagem.com.br. sim

Descrição do teste:

Verificamos se seus servidores de e-mail (MX) oferecem suporte à 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:

Todos os seus servidores de e-mail não permitem a renegociação iniciada pelo cliente.

Detalhes técnicos:

Servidor de e-mail (MX) Renegociação iniciada pelo cliente
mmhospedagem.com.br. não

Descrição do teste:

Verificamos se um servidor de envio de e-mail pode iniciar uma renegociação com seus servidores de recebimento de e-mail (MX).

Permitir que servidores de envio de e-mail iniciem renegociação geralmente não é necessário e abre o servidor de recebimento de e-mail para 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:

Este subteste não é aplicável, pois seus servidores de e-mail não oferecem suporte a TLS 1.3.

Detalhes técnicos:

Servidor de e-mail (MX) 0-RTT
mmhospedagem.com.br. não

Descrição do teste:

Verificamos se seus servidores de e-mail (MX) oferecem 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 seus servidores de e-mail não oferecem suporte a TLS 1.3, o teste não é aplicável. Para servidores de e-mail que oferecem suporte a TLS 1.3, o comando STARTTLS é enviado e uma sessão TLS é iniciada. É verificado o limite suportado de early data do servidor de e-mail. Quando for maior do que zero, uma segunda conexão é feita, reutilizando os detalhes da sessão TLS da primeira conexão, mas enviando o comando EHLO antes do processo de handshake de TLS e depois do comando STARTTLS, ou seja, sem a 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 de e-mail responder, então se considera que o servidor de e-mail oferece 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
Certificado

Resultado:

A cadeia de confiança de todos os seus certificados de servidor de e-mail está completa e assinada por uma autoridade certificadora raiz confiável.

Detalhes técnicos:

Servidor de e-mail (MX) Cadeia não confiável de certificados
mmhospedagem.com.br. Nenhum(a)

Descrição do teste:

Verificamos se somos capazes de construir uma cadeia de confiança válida para os seus certificados de servidor de e-mail.

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

Os servidores de envio de e-mail geralmente ignoram se um certificado de servidor de e-mail é emitido por uma autoridade certificadora publicamente confiável. Sem o DNSSEC, a pesquisa de domínio do servidor de e-mail é vulnerável à manipulação. Assim, um certificado emitido por uma autoridade certificadora publicamente confiável não acrescenta nenhum valor de autenticidade. Alguns servidores de recebimento de e-mail estão usando certificados autoassinados, muitas vezes emitidos por uma autoridade certificadora interna (privada). Para fins de autenticidade, um servidor de e-mail deve usar DNSSEC e DANE.

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

Nível de exigência: Opcional

Resultado:

As assinaturas digitais de todos os seus certificados de servidor de e-mail utilizam parâmetros seguros.

Detalhes técnicos:

Servidor de e-mail (MX) Parâmetros de assinatura afetados
mmhospedagem.com.br. Nenhum(a)

Descrição do teste:

Verificamos se a assinatura digital (ECDSA ou RSA) de cada um de seus certificados de servidor de e-mail 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:

Todos os seus certificados de servidor de e-mail são assinados usando um algoritmo de hash seguro.

Detalhes técnicos:

Servidor de e-mail (MX) Algoritmo de hash afetado
mmhospedagem.com.br. Nenhum(a)

Descrição do teste:

Verificamos se a assinatura de cada um dos seus certificados de servidor de e-mail 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 pelo menos um dos seus servidores de e-mail não corresponde ao nome de domínio no certificado do servidor de e-mail.

Detalhes técnicos:

Servidor de e-mail (MX) Domínios sem correspondência no certificado
mmhospedagem.com.br. servidor.hospedagemdesite.goiania.br

Descrição do teste:

Verificamos se o nome de domínio de cada um dos seus servidores de recebimento de e-mail (MX) corresponde ao nome de domínio nos certificados apresentados.

Os servidores de envio de e-mail geralmente ignoram o domínio no certificado. Sem DNSSEC, a pesquisa de domínio do servidor de e-mail é vulnerável à manipulação. Assim, a correspondência do domínio no certificado com o domínio do servidor de e-mail não acrescenta nenhum valor de autenticidade. Alguns servidores de recebimento de e-mail estão usando certificados autoassinados, muitas vezes emitidos por uma autoridade certificadora interna (privada).

Para fins de autenticidade, um servidor de e-mail deve usar DNSSEC e DANE. Um certificado com um domínio que corresponda ao domínio do servidor de e-mail só é necessário quando a Trust anchor assertion DANE (DANE-TA, 2) for utilizada.

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

Nível de exigência: Opcional / Exigido (apenas quando DANE-TA for usado)

DANE

Resultado:

Ao menos um dos seus domínios de servidor de e-mail não fornece um registro TLSA para DANE.

Detalhes técnicos:

Servidor de e-mail (MX) Registro TLSA para DANE existente
mmhospedagem.com.br. não

Descrição do teste:

Verificamos se os servidores de nomes de cada um dos seus servidores de recebimento de e-mail (MX) fornecem um registro TLSA para DANE.

Como o DNSSEC é pré-condição para DANE, este teste apresentará um resultado de reprovação, caso o DNSSEC esteja ausente no(s) domínio(s) do(s) servidor(es) de e-mail.

Observe que o teste ignora os registros TLSA dos tipos PKIX-TA(0) ou PKIX-EE(1), pois eles não devem ser usados por servidores de recebimento de e-mail.

Além disso, o teste resultará em reprovação, se não houver prova DNSSEC de Negação de Existência (Denial of Existence) para registros TLSA. Se há um registro TLSA assinado, mas ao mesmo tempo houver um NXDOMAIN inseguro para o mesmo domínio, devido a um software de assinatura com problemas, o teste também indicará reprovação. Os dois últimos cenários de reprovação podem resultar na não entrega de e-mails endereçados a você por remetentes com validação DANE.

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

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:

Servidor de e-mail (MX) Registro TLDS para DANE válido
mmhospedagem.com.br. não testado

Descrição do teste:

Verificamos se as assinaturas DANE apresentadas por seus domínios de servidor de e-mail são válidas para os seus certificados de servidor de e-mail.

DANE permite que você publique informações sobre seus certificados de servidor de e-mail em um registro DNS especial, chamado registro TLSA. Os servidores de envio de e-mail podem verificar a autenticidade dos seus certificados não apenas através da autoridade certificadora, mas também pelos registros TLSA. Um servidor de envio de e-mail também pode usar o registro TLSA como um sinal para se conectar apenas via STARTTLS e não sem criptografia. Quando a assinatura DANE de um servidor de recebimento de e-mail é verificada pelo servidor de envio de e-mail, um atacante ativo capaz de manipular o tráfego de e-mail não pode descriptografar o protocolo STARTTLS.

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:

Servidor de e-mail (MX) Esquema de substituição de DANE
mmhospedagem.com.br. não testado

Descrição do teste:

Verificamos se há um esquema ativo com pelo menos dois registros TLSA para DANE para lidar de forma confiável com a substituição de certificados em seus servidores de recebimento de e-mail (MX).

Esse esquema será útil quando houver a necessidade de atualizar seu(s) certificado(s) no servidor de e-mail. Isso pode evitar que o DANE fique inválido durante o período de transição, o que poderia colocar em risco a entrega de e-mail em seu domínio. Um esquema de substituição pode, mas não precisa ficar "ativo" o tempo todo.

Recomendamos que você aplique um dos dois esquemas a seguir com registros TLSA para DANE duplos:

  1. Current + Next ("3 1 1" + "3 1 1"): publique dois registros "DANE-EE(3) SPKI(1) SHA2-256(1)", um para o atual e um para o próximo certificado TLS do seu servidor de e-mail.
  2. Current + Issuer CA ("3 1 1" + "2 1 1"): publique um registro "DANE-EE(3) SPKI(1) SHA2-256(1)" para o certificado TLS atual do seu servidor de e-mail e também um registro "DANE-TA(2) SPKI(1) SHA2-256(1)" para o certificado atual raiz ou intermediário da autoridade certificadora, não necessariamente pública.

O teste também aceita outras combinações de registros TLSA para DANE, ou seja, "3 x x" + "3 x x" ou "3 x x" + "2 x x". No entanto, outros tipos que não os acima geralmente serão mais propensos a erros e menos interoperáveis.

Nível de exigência: Opcional

Teste outro site

Teste outro e-mail

Teste TOP - IPv6 e DNSSEC da sua rede


Apoiadores