Por que usar o CAA?
Os cientistas da computação Phillip Hallam-Baker e Rob Stradling desenvolveram o CAA em resposta às crescentes preocupações sobre a segurança de autoridades de certificação publicamente confiáveis. Esta iniciativa está sob a Internet Engineering Task Force (IETF), uma organização líder em desenvolvimento de padrões (SDO) para a Internet. A IETF cria padrões voluntários que são amplamente adotados por usuários da Internet, operadores de rede e fornecedores de equipamentos, influenciando a evolução da Internet.
O IETF documenta seus padrões técnicos em publicações conhecidas como RFCs (Requests for Comments). Esses documentos descrevem os principais aspectos da infraestrutura da Internet, incluindo tecnologias de endereçamento, roteamento e transporte. O CAA é definido especificamente em RFC 6844.
Uma autoridade de certificação (CA) sempre usa métodos de validação de domínio para garantir que cada SSL /TLS a solicitação de certificado é autorizada (geralmente, certificando-se de que está vinculada de alguma forma a um site específico usando esse domínio).
Por exemplo, uma CA pode fornecer um arquivo de verificação especial ao solicitante. A colocação desse arquivo no site prova que o solicitante também controla esse site, mas não pode garantir a legitimidade desse controle. Um hacker que obtém o controle de um site pode se disfarçar como o proprietário legítimo e pode então solicitar e receber um SSL /TLS certificado que passa em qualquer verificação padrão da CA e, portanto, parece legítimo. Eles poderiam, então, voltar e usar esse SSL /TLS certificado de dano, nesse site ou em outro lugar.
O CAA ajuda a bloquear esse tipo de exploração, definindo quais CAs têm permissão para emitir certificados para um domínio (ou mesmo restringindo totalmente a emissão de certificados). Isso limita os danos que um sequestrador pode infligir - mesmo se eles tiverem o controle de um site, eles terão drasticamente menos opções para obter um SSL / desonestoTLS certificado.
O que é um CNAME?
Um registro CNAME é um tipo de configuração DNS que permite que um domínio, como loja.meunegocio.com, para atuar como um pseudônimo para outro, como meunegócio.com. Em vez de gerenciar vários registros A para refletir alterações de endereço IP, um CNAME simplifica isso apontando o alias para o domínio de destino. Essa abordagem é altamente benéfica para empresas que trocam regularmente de hosts da web ou provedores de CDN. Além disso, os registros CNAME são inestimáveis para a construção de sistemas de failover, onde o tráfego é direcionado de um servidor primário para um secundário, garantindo a continuidade do serviço durante interrupções.
No contexto da Certificate Authority Authorization (CAA), os registros CNAME influenciam o processo redirecionando as verificações CAA para o domínio de destino. Por exemplo, se loja.meusite.net usa um CNAME para apontar para meusite.net, uma CA que realiza uma verificação de CAA avaliará os registros para meusite.net para verificar a autorização para emissão de um certificado. Se o registro CAA em meusite.net não autoriza a CA, o certificado não pode ser emitido. Isso garante a aplicação consistente das políticas da CAA, mesmo quando os domínios aproveitam os registros CNAME para aliasing de DNS.
Como funciona o CAA
O CAA usa DNS
O processo de Domain Name System (DNS) é uma parte crucial da infraestrutura da internet. O proprietário de qualquer domínio mantém registros DNS (dentro dos chamados arquivos de zona) apontando o nome do domínio para o endereço IP em que o site está hospedado e digitando google.com em uma janela do navegador em vez de 216.58.194.46.
Os registros DNS são comumente usados como “lista telefônica para a Internet”, mas o DNS também permite outros tipos de registros especiais que podem atribuir outras informações a um nome de domínio.
Registros CAA
O CAA usa um tipo especial de registro chamado de Registro do recurso de autorização da autoridade de certificação (Registro CAA). Eles são publicados usando DNS, e o proprietário do domínio simplesmente adiciona registros CAA ao lado de outros registros DNS. Um registro CAA inclui um etiqueta e uma valor, e o par de tag-valor é chamado de propriedade. Há também um bandeira indicando o quão crítica esta propriedade é. Aqui está a aparência de um:
example.com. Problema CAA 0 "ssl.com"
Aqui, example.com é o domínio ao qual esse registro se aplica e o CAA nos permite saber que tipo de registro é esse. o 0 é o sinalizador (zero é o padrão). A tag é emitem e o valor (entre aspas) é ssl. com, que juntos compõem a propriedade.
Bandeiras
Os sinalizadores têm atualmente apenas dois estados estritamente definidos: 0 (não crítico) e 1 (crítico). Um sinalizador crítico informa à CA que devo entenda completamente a tag property para prosseguir. O RFC 6844 deixa outras possibilidades abertas para uso de sinalizadores definidos pelo usuário (mais sobre isso abaixo).
Tags
O RFC 6844 define o uso de três tags comuns: emitem, questão selvagem e iodef. (Como nos sinalizadores, ele permite outros tipos de tags personalizados em potencial.)
O processo de emitem etiqueta
O processo de emitem tag especifica qual (se houver) CA está autorizada a emitir certificados para este domínio. Por exemplo, o proprietário do domínio example.com pode restringir a emissão do certificado a uma CA (aqui, SSL.com) usando o seguinte arquivo de zona DNS:
example.com. Problema CAA 0 "ssl.com"
Um proprietário de domínio pode optar por configurar vários arquivos de zona para um domínio:
example.com. Problema CAA 0 "ssl.com" example.com. CAA 0 emissão "comodoca.com"
Os registros acima limitam SSL /TLS emissão de certificado para example.com para duas CAs (SSL.com e Comodo.com).
O processo de emitem O registro também autoriza a CA nomeada a emitir certificados para qualquer subdomínio do domínio especificado. Um registro que permite SSL.com pode, portanto, permitir a emissão de certificados para example.com e subdomínios como www.example.com, mail.exemplo.com e até mesmo o subdomínio curinga especial * .exemplo.com.
Um registro CAA pode ser usado para restringir emissão de certificado, também - este registro diz às autoridades de certificação usando CAA que não SSL /TLS certificados devem ser emitidos para example.com e subdomínios por qualquer CA:
example.com. Problema CAA 0 ";"
(O ponto e vírgula neste exemplo significa “não permite nada aqui“, Mas como mostraremos mais tarde, também é usado para definir parâmetros personalizados.)
Observe que uma etiqueta de problema padrão permite que a CA emita um certificado para um caractere curinga, a menos que seja modificado por ...
O processo de questão selvagem etiqueta
Esta tag especifica que uma CA está autorizada a emitir certificados curinga para o domínio do proprietário (ou seja * .exemplo.com).
Os curingas podem ser responsáveis por um conjunto ilimitado de subdomínios, portanto, cuidados e atenção especiais são necessários ao emitir certificados curinga. questão selvagem A tag permite que o proprietário do domínio defina quais autoridades de certificação podem emitir certificados para curingas separadamente do domínio principal ou de outros subdomínios. questão selvagem tags têm precedência sobre qualquer emitem Tag. Eles usam a mesma sintaxe que o emitem tag. Alguns exemplos:
example.com. Problema CAA 0 "ssl.com" example.com. CAA 0 issuewild ";"
O acima permite que SSL.com emita certificados para example.com e todos os subdomínios exceto para o curinga * .exemplo.com. (Nem SSL.com nem qualquer outra CA tem permissão para emitir certificados curinga para example.com.)
example.com. Problema CAA 0 ";" example.com. CAA 0 issuewild "ssl.com"
Este exemplo proíbe todos os CAs para emitir certificados para example.com e seus subdomínios, mas cria uma exceção para permitir que SSL.com emita certificados curinga (e só certificados curinga) para example.com.
O processo de iodef etiqueta
A terceira tag definida é iodef. Essa tag pode ser usada para relatar solicitações de certificado inválidas ao proprietário do domínio e elas têm a seguinte aparência:
example.com. CAA 0 iodef "mailto: certissues@example.com" example.com. CAA 0 iodef "certissues.example.com"
O registro superior fornece as informações da CA necessárias para enviar uma notificação por email para o endereço certissues@example.com. O segundo instrui a CA a postar uma mensagem de incidente em um serviço da Web (configurado para esse fim pelo proprietário do domínio) em certissues.exemplo.com. (Um ou ambos os métodos podem ser usados, dependendo de como a CA e o proprietário do domínio configuraram suas operações.)
iodef as mensagens de postagem usam um formato padrão chamado Objeto de incidente Descrição Formato do Exchange ou IODEF - daí o nome. (IODEF é definido em RFC 6546.)
A tag issuemail para S/MIME
Um desenvolvimento importante na CAA é a extensão para S/MIME (Secure/Multipurpose Internet Mail Extensions), formalizados no RFC 9495. S/MIME certificados fornecem segurança de e-mail por meio de autenticação, privacidade de dados e integridade de mensagens. O CA/Browser Forum introduziu uma nova tag de propriedade CAA chamada “issuemail” especificamente para controlar a emissão de S/MIME certificados.
A partir de 15 de setembro de 2024, recomenda-se que as ACs implementem a verificação de CAA para S/MIME certificados, com implementação obrigatória exigida até 15 de março de 2025. O formulário de registro CAA padrão para endereços de e-mail seria semelhante a:
mail.client.example CAA 0 issuemail "autoridade.example"
Esta extensão do CAA para certificados de e-mail fornece aos proprietários de domínio o mesmo nível de controle sobre S/MIME emissão de certificado como eles têm para TLS certificados, reduzindo o risco de emissão não autorizada de certificados.
Sinalizadores e tags definidos pela CA
O CAA, conforme descrito na RFC 6844, define especificamente apenas dois estados de bandeira (0 e 1) e três tags (emitem, questão selvagem e iodef) No entanto, deixa o design aberto o suficiente para que as autoridades de certificação criem e utilizem tags e sinalizadores personalizados para definir seu processo de emissão de certificados. Exemplos podem ser:
example.com. Problema CAA 0 "SSL.com; política = ev"
Este registro usa um padrão emitem com um parâmetro extra que instrui a CA a usar sua política de Validação Estendida (EV) ao emitir um certificado para este domínio.
example.com. CAA 128 pca "PCA = 12345"
O proprietário do domínio pode usar esse registro com um novo código definido pela CA pca para mostrar que eles têm uma conta de cliente preferencial e define o número da conta como parâmetro. (O sinalizador também pode ser um valor personalizado de até 255.) Dependendo de como a CA configurar a conta, isso poderá permitir métodos de cobrança específicos, verificação extra definida pela conta ou outro tratamento especial.
Prós e Contras
Existem várias razões excelentes para usar o CAA. A principal e mais importante vantagem é a capacidade do CAA de reduzir muito o risco de emissão incorreta de certificados. Isso ajuda a proteger seu domínio, seu negócio e sua identidade online. Invasores em potencial que podem ter encontrado um bug no software de uma CA específica não podem explorá-lo para emitir certificados SSL para seu domínio. Além disso, usar a tag iodef permite que você obtenha um relatório se uma exploração for tentada.
O design do CAA aumenta a segurança, mas também pode permitir uma alocação mais detalhada de recursos - por exemplo, uma empresa poderia configurar registros para permitir (ou limitar) o departamento de vendas e marketing a adquirir certificados SSL para sales.example.com de uma fonte designada.
Além disso, o CAA oferece grande flexibilidade. Para um proprietário de domínio, ele usa registros de recursos DNS que estão sob seu próprio controle e podem ser alterados conforme necessário, para que não estejam vinculados a uma CA específica (e possam ter mais de uma CA autorizada com registros de problemas para qualquer nome de domínio) . Para as CAs, mesmo fora dos usos personalizados, as regras recém-adotadas pelo CA / B Forum (o grupo que define padrões para assuntos de segurança da CA e do navegador) podem permitir que os registros da CAA sejam usados para fins de validação, fornecendo outro bom motivo para utilizá-los.
Uma desvantagem é que, mesmo quando os registros CAA estão em vigor, um usuário não pode aplicar seu uso por uma autoridade de certificação. Um CA deve ser compatível com RFC 6844 para que esses registros sejam atendidos, e um CA não compatível pode simplesmente ignorar os desejos expressos do proprietário do domínio, conforme declarado em seus registros CAA.
O CAA também deve ser configurado corretamente pelo proprietário do domínio e por um CA. Vamos criptografar (que oferece suporte a CAA) recentemente relataram um pequeno problema com sua base de código o que infelizmente levou à ignorância das regras da CAA e à emissão incorreta de seis certificados. Nenhuma dessas exceções foram maliciosas (e elogios à equipe do Let's Encrypt por resolver e relatar o problema horas após a descoberta). No entanto, isso ressalta que uma autoridade de certificação compatível devo implementar CAA sem falhas.
Outro problema potencial é a confiança da CAA no DNS. A menos que o proprietário do domínio proteja seus serviços de nomes, isso pode ser um vetor de ataque. RFC 6844 sugere a implementação Extensões de segurança do sistema de nomes de domínio (DNSSEC), que usa registros DNS assinados digitalmente para autenticar dados e combater a ameaça de falsificação de DNS.
Finalmente, mesmo com o CAA instalado e implementado corretamente, um registro CAA por si só não pode impedir completamente a emissão de certificados não autorizados. Embora o CAA seja uma ferramenta útil e importante para limitar as opções de um invasor, um sequestrador com acesso suficiente (por exemplo, controlando DNS ou por meio de engenharia social) pode ser capaz de contorná-lo.
Conclusão
A Certification Authority Authorization tem um potencial fantástico como parte de um ecossistema de segurança mais amplo, e a adoção e implementação generalizadas da CAA protegerão contra a emissão incorreta de certificados. Embora a CAA sozinha não impeça toda emissão incorreta de certificados, é um bom passo na direção certa, e a SSL.com gostaria de pedir que você considere usar os registros da CAA você mesmo.
Referências
- RFC6844: Registro de recurso de autorização de autoridade de certificação DNS (CAA)
- RFC5070: O formato de troca de descrição de objeto de incidente
- RFC6546: Transporte de mensagens RID (Defense Inter-network Defense) em tempo real via HTTP /TLS
- RFC4033: Introdução e requisitos de segurança do DNS
- Boletim do Fórum CA / B 125 - Registros CAA
- Entrada da Wikipedia sobre autorização da autoridade de certificação DNS
Guias Relacionados
- Quais são os requisitos para SSL.com SSL /TLS Validação de domínio de certificado?
- Qual é o “Valor Único” Usado na Validação de Domínio (DV)?
- Nome de domínio SSL /TLS Pré-Validação
