Certification Authority Authorisation (CAA)

O que é CAA?

CAA (Certification Authority Authorisation) permite que você, como titular de um nome de domínio, especifique uma ou mais autoridades certificadoras autorizadas a emitir certificados para o seu nome de domínio. Uma autoridade certificadora não deve emitir um certificado, a menos que verifique que a solicitação de certificado seja consistente com os registros CAA aplicáveis.

Por que a CAA é importante?

Para uma conexão segura com seu site ou servidor de e-mail, seu certificado é crucial. Se uma parte mal-intencionada conseguir obter um certificado para o seu nome de domínio, ela poderá interceptar dados confidenciais. Ao limitar o número de autoridades certificadoras que podem emitir certificados para o seu nome de domínio, você reduz o risco de emissão incorreta.

Observe que CAA funciona de forma diferente de DANE. O objetivo do registro CAA é reduzir o risco de emissão incorreta de certificados. DANE é um mecanismo para verificar a validade dos certificados emitidos e, assim, evitar que certificados emitidos incorretamente sejam considerados confiáveis. Especialmente para e-mail, é importante aplicar DANE, pois é o padrão mais amplamente utilizado para criptografia de transporte de e-mail.

O que o TOP verifica com o teste CAA?

O TOP verifica se os servidores de nomes do seu domínio ou dos domínios dos seus servidores de e-mail (MX) contêm um ou mais registros CAA com sintaxe correta. Pelo menos um desses registros CAA deve ter a tag issue. Caso contrário, o teste resultará em falha. Não é verificado se a autoridade certificadora do certificado TLS atual corresponde a um ou mais dos valores issue e issuewild, ou seja, se o certificado atual pode ser reemitido. O resultado deste teste não influencia na pontuação total neste momento.

Se você estiver usando o padrão ACME (Automatic Certificate Management Environment) e sua autoridade certificadora o suportar, recomendamos que você use os parâmetros validationmethods e accounturi para restringir ainda mais a emissão de certificados pela autoridade certificadora. Além disso, recomenda-se adicionar issuewild, issuemail e issuevmc com um ; vazio se você não usar curingas, certificados S/MIME e/ou BIMI, respectivamente. Isso é especialmente importante para issuemail e issuevmc, pois, na ausência deles, não há retorno para issue e, portanto, qualquer autoridade certificadora ainda pode emitir certificados S/MIME e/ou BIMI para o seu domínio.

RPKI

Por que o RPKI passa a ter impacto na pontuação?

Há um ano, o teste RPKI foi adicionado aos testes de site e de e-mail. Desde então, este teste não afetou a pontuação total. No entanto, devido o RPKI ser um requisito importante para a segurança de roteamento, pois evita ataques de sequestro de prefixos e vazamento de rotas, entendemos que este é o momento de incluí-lo no cálculo da pontuação geral.

Quais são as estatísticas de uso do RPKI?

Para estatísticas sobre o RPKI, consulte a seção "Estatísticas" nas Referências para Autorização para Roteamento (RPKI).

Por que RPKI?

RPKI (Resource Public Key Infrastructure) é uma técnica que visa evitar certos vazamentos de rotas e sequestros de prefixos e evita que o tráfego de Internet seja redirecionado para uma rede não autorizada.

Tais redirecionamentos podem ser resultado de um simples erro de digitação de um administrador de rede que, involuntariamente, desvia o tráfego de Internet, ou pode ser resultado de um ataque direcionado à infraestrutura da Internet, por exemplo, para tornar sites inacessíveis ou roubar dados de usuários.

Como funciona o novo cálculo de pontuação?

A pontuação é dividida igualmente entre todas as categorias que contêm um ou mais testes obrigatórios. Portanto, a pontuação máxima para a categoria de teste RPKI, tanto no teste de site quanto no de e-mail, é de 25%. Para cada parte do teste RPKI, ou seja, teste de servidores de nomes, servidores web e servidores de e-mail, a parte "existência da configuração" contribui com 1/3 do peso da avaliação e a parte "validação da configuração" contribui com os outros 2/3.

O que mais é importante para um roteamento confiável?

Atualmente, o TOP - Teste os Padrões verifica apenas a publicação de recursos e não sua validação. Portanto, ele verifica as ROA (Route Origin Authorization) publicadas no RPKI, mas não a validação de origem ROV (Route Origin Validation). Recomendamos fortemente que você também implemente validação de origem de rotas.

Além disso, a iniciativa MANRS recomenda melhores práticas de roteamento adicionais ao RPKI, que tornam o roteamento mais confiável.

Se quiser saber mais, confira os treinamentos do NIC.br sobre RPKI: RPKI – Tutoriais NIC.br, NIC.br, Segurança no roteamento com RPKI – Semana de Capacitação 1, NIC.br e RPKI: aprenda com quem desenvolveu os validadores – Semana de Capacitação 3, NIC.br ou acesse o site do Registro.br.

Pacote Docker

A ferramenta de testes TOP foi adaptada pelo NIC.br utilizando como base o site Internet.nl, que é uma iniciativa da holandesa Internet Standards Platform. O objetivo é aumentar o uso dos padrões modernos de Internet para tornar a Internet mais acessível, segura e confiável para todos. Até agora, configurar o TOP era desafiador e trabalhoso. A partir desta versão, o código do Internet.nl foi cuidadosamente montado em um pacote de software baseado em containers Docker, o que facilita a implementação e atualização da ferramenta TOP-Teste os Padrões. O pacote Docker torna o uso do código mais amigável e contribui para a qualidade do código.

Espera-se que esta nova funcionalidade resulte em mais sites, servidores de e-mail e conexões testados para os padrões modernos de Internet. Não apenas nos servidores do Internet.nl ou do TOP, mas também em servidores de terceiros. Dessa forma, espera-se acelerar ainda mais o uso mundial dos padrões modernos de Internet, tornando a Internet mais acessível, segura e confiável para todos. Você está convidado a implantar e usar esta nova versão em seu próprio sistema, acesse GitHub do Internet.nl.

Teste Referrer-Policy extendido

O teste Referrer-Policy agora também verifica se a política é suficientemente segura e protege a privacidade. Com esta política, seu servidor web instrui os navegadores sobre o que e quando os dados de referência devem ser enviados ao site em que o usuário está navegando a partir do seu site. Os dados no cabeçalho Referrer geralmente são usados ​​para análises e registros. No entanto, pode haver riscos à privacidade e à segurança. Os dados podem ser usados, por exemplo, para rastreamento de usuários e podem vazar para terceiros que interceptam a conexão. Para mitigar esses riscos, é importante definir uma Referrer-Policy com uma política suficientemente segura e que proteja a privacidade.

Teste CSP aprimorado

Mensagens de erro específicas foram adicionadas aos detalhes técnicos no teste Content-Security-Policy (CSP) para sites. Isso torna mais claro para os usuários o que está errado com sua política CSP e permite que eles tornem sua política mais segura. Além disso, o teste CSP agora também verifica as configurações de segurança das diretivas base-uri e form-action. De acordo com a especificação CSP, ambas as diretivas não são cobertas pela política de fallback default-src e, portanto, é importante configurá-las explicitamente.

Teste security.txt aprimorado e resultado do subteste TLS mais detalhado

Para o teste security.txt, a biblioteca de validação foi atualizada e várias correções de código foram feitas. Além disso, nos subtestes para determinação da versão do TLS utilizado, os usuários agora podem ver todas as versões de TLS detectadas na tabela de detalhes técnicos.