en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Uma introdução à autorização da autoridade de certificação (CAA)

Por que usar o CAA?

Uma 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.

Como funciona o CAA

O CAA usa DNS

A 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 de um 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 - falaremos sobre isso a seguir). 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 de propriedade para prosseguir. A RFC 6844 deixa outras possibilidades em aberto para uso de sinalizadores definidos pelo usuário (falaremos sobre isso a seguir também).

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.)

A emitem etiqueta

A 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).

A 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.example.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 ...

A 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 são um tipo especial de subdomínio abrangente e merecem cuidados e atenção especiais ao emitir certificados curinga. o 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 certificados curinga) para example.com.

A 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.example.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.)

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

Vantagens ...

Existem várias razões excelentes para usar o CAA. A principal e mais importante vantagem é a capacidade do CAA de reduzir significativamente o risco de emissão incorreta de certificados. Isso ajuda a proteger seu domínio, sua empresa e sua identidade online. Os invasores em potencial que podem ter encontrado um bug no software de uma CA em particular não podem explorá-lo para emitir certificados SSL para seu domínio. Além disso, o uso da tag iodef permite obter um relatório se houver tentativa de exploração.

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.

... e pontos negativos

O maior problema com o CAA é que ele não foi adotado por todos os CAs. Os Requisitos Básicos do Fórum CA / B (que todos os CAs confiáveis ​​cumprem) instruem um CA a especificar o grau de suporte ao CAA em sua documentação online. No momento da redação deste artigo, no entanto, o uso de CAA é apenas Recomenda, não requerido. As autoridades de certificação que não são compatíveis com o CAA ainda podem ser direcionadas e, até que o CAA seja mais utilizado, um seqüestrador provavelmente poderá encontrar um CA não compatível disposto a emitir um certificado não autorizado.

Uma desvantagem relacionada é que, mesmo quando há registros CAA, 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 autorização da autoridade de certificação tem um potencial incrível como parte de um ecossistema de segurança mais amplo, e a ampla adoção e implementação do CAA protegerá contra a emissão incorreta de certificados. Embora seja lamentável que nem todas as autoridades de certificação atualmente suportem CAA, há uma discussão sobre como tornar isso mais fortemente sugerido ou obrigatório para todas as CAs. Embora o CAA sozinho não impeça a emissão incorreta de todos os certificados, é um bom passo na direção certa, e SSL.com gostaria de exortá-lo a considerar o uso de registros CAA você mesmo.

Referências

Precisa configurar o CAA para autorizar SSL.com a emitir certificados para seu domínio? Então por favor revise este artigo.
Obrigado por escolher SSL.com! Se você tiver alguma dúvida, entre em contato conosco por e-mail em Support@SSL.com, ligar 1-877-SSL-SECUREou clique no link de bate-papo no canto inferior direito desta página.

Artigos Relacionados

Inscreva-se no boletim informativo de SSL.com

O que é SSL /TLS?

Reproduzir Vídeo

Inscreva-se no boletim informativo de SSL.com

Não perca novos artigos e atualizações de SSL.com