Eu só estava pensando. Usamos muitos certificados SSL. Hoje em dia, usamos quase exclusivamente letsencrypt (obrigado!). A linha inferior desses certificados é que a prova de propriedade do (s) nome (s) de domínio no certificado vem do poder de manipular os registros DNS ou o site sob esses domínios. A prova do DNS vem da adição de alguma chave (fornecida por letsencrypt) como um registro TXT ao DNS.

Portanto, se há provas suficientes para alterar os registros DNS de um domínio, por que não usar certificados autoassinados com a impressão digital no DNS?

Eu diria que isso oferece exatamente a mesma confiança que o procedimento baseado em DNS do letsencrypt (e outras autoridades de certificação):

1. Crie uma autoridade de certificação autoassinada (basta seguir as etapas das várias instruções)
2. Crie um certificado para alguns domínios
3. Assine o certificado da etapa 2 com a CA da etapa 1. Agora você tem um certificado básico, assinado por uma CA não confiável
4. Adicione um registro TXT (ou dedicado) ao DNS de cada um dos domínios, declarando: assinamos o certificado deste domínio com essa CA. Como: 'CA = -pintão de CA-'
5. Um navegador baixa o certificado e o verifica comparando a impressão digital da CA / certificado da CA com os dados no DNS para o domínio especificado.

Isso tornaria possível criar certificados autoassinados confiáveis ​​sem interferência de terceiros, com o mesmo nível de confiança que qualquer certificado SSL básico. Desde que você tenha acesso ao DNS, seu certificado é válido. Pode-se até adicionar alguns DNSSEC como criptografia, fazer um hash da CA mais o registro SOA, para garantir que a confiança desapareça nas alterações no registro DNS.

Isso já foi considerado antes?

Jelmer

A infraestrutura básica, que tornaria isso possível, existe e é chamada de autenticação baseada em DNS de entidades nomeadas (DANE) e especificada na RFC6698 . Ele funciona por meio de um TLSAregistro de recurso, que especifica o certificado ou sua chave pública da entidade final ou uma de suas CAs na cadeia (na verdade, existem quatro tipos diferentes, consulte a RFC para obter detalhes).

Adoção

No entanto, o DANE ainda não viu uma adoção generalizada. A VeriSign monitora a adoção de DNSSEC e DANE e acompanha seu crescimento ao longo do tempo :

Para comparação, de acordo com a VeriSign, existem cerca de 2,7 milhões de zonas DNS, o que significa que um pouco mais de 1% de todas as zonas possui pelo menos um registro TLSA.

Não posso dar nenhuma resposta oficial, por que DANE, mas aqui estão minhas especulações:

O DANE sofre do mesmo problema que as Listas de revogação de certificados (CRLs) e o Online Certificate Status Protocol (OCSP). Para verificar a validade de um certificado apresentado, um terceiro deve ser contatado. Hanno Böck dá uma boa visão geral , por que esse é um grande problema na prática. Tudo se resume à questão do que fazer, quando você não pode alcançar terceiros. Neste caso, os fornecedores de navegadores optaram pela falha suave (também conhecida como permissão), o que tornou tudo inútil e o Chrome decidiu finalmente desativar o OCSP em 2012.

DNSSEC

Indiscutivelmente, o DNS oferece uma disponibilidade muito melhor do que os servidores CRL e OCSP das CAs, mas ainda impossibilita a verificação offline. Além disso, o DANE, deve ser usado apenas em conjunto com o DNSSEC. Como o DNS normal opera com UDP não autenticado, é bastante propenso a falsificações, ataques MITM etc. A adoção do DNSSEC é muito melhor do que a adoção do DANE, mas ainda está longe de ser onipresente.

E com o DNSSEC, nos deparamos novamente com o problema de falha leve. Que eu saiba, nenhum sistema operacional servidor / cliente principal fornece um resolvedor DNSSEC de validação por padrão.

Depois, há também a questão da revogação. O DNSSEC não possui mecanismo de revogação e depende de chaves de vida curta.

Suporte de software

Todo o software participante deve implementar o suporte ao DANE.

Em teoria, você pode pensar que esse seria o trabalho das bibliotecas de criptografia e os desenvolvedores de aplicativos não precisariam fazer muito, mas o fato é que as bibliotecas criptográficas normalmente fornecem apenas primitivas e os aplicativos precisam fazer muita configuração e se (e infelizmente existem muitas maneiras de errar).

Não sei que qualquer servidor Web importante (por exemplo, Apache ou nginx), por exemplo, implementou o DANE ou tem planos para fazê-lo. Os servidores da Web são de particular importância aqui, porque cada vez mais coisas são construídas nas tecnologias da Web e, portanto, geralmente são as primeiras onde as coisas são implementadas.

Quando olhamos para CRL, OCSP e OCSP Stapling como comparação, podemos inferir como será a história de adoção da DANE. Apenas alguns dos aplicativos que usam OpenSSL, libnss, GnuTLS etc. suportam esses recursos. Demorou um pouco para que softwares importantes como Apache ou nginx o suportassem e, novamente, consultando o artigo de Hanno Böck, eles entenderam errado e sua implementação é falha. Outros grandes projetos de software, como Postfix ou Dovecot , não são compatíveis com OCSPe possui uma funcionalidade CRL muito limitada, basicamente apontando para um arquivo no sistema de arquivos (que não é necessariamente relido regularmente, portanto, você teria que recarregar o servidor manualmente etc). Lembre-se de que são projetos que freqüentemente usam TLS. Então você pode começar a olhar para as coisas, onde o TLS é muito menos comum, como o PostgreSQL / MySQL, por exemplo, e talvez eles ofereçam CRLs, na melhor das hipóteses.

Portanto, nem os servidores Web modernos o implementam e a maioria dos outros softwares nem sequer conseguiu implementar o OCSP e a CRL, boa sorte com seu aplicativo ou dispositivo corporativo de 5 anos.

Aplicações potenciais

Então, onde você poderia realmente usar o DANE? A partir de agora, não na Internet em geral. Se você controla o servidor e o cliente, talvez seja uma opção, mas nesse caso, geralmente é possível recorrer à Public-Key Pinning.

No espaço para correio, o DANE está obtendo alguma tração, porque o SMTP não possui nenhum tipo de criptografia de transporte autenticada há mais tempo. Às vezes, os servidores SMTP usam TLS entre si, mas não verificam se os nomes dos certificados realmente correspondem, agora eles estão começando a verificar isso através do DANE.

Diferentes tipos de procedimentos de validação de certificado

Com os certificados assinados pela CA regulares, há vários níveis de validação de certificado:

• Validação de domínio (DV)
  Somente a propriedade do nome de domínio é validada, apenas o nome do domínio é mostrado como "Assunto" no certificado
• Validação da organização (OV) O
  nome de domínio e o nome do proprietário são validados, o nome do domínio e o nome do proprietário são exibidos como "Assunto" no certificado
• Validação estendida (EV) A
  validação mais rigorosa da entidade proprietária, nome do domínio e nome do proprietário é exibida como "Assunto" no certificado, barra verde com o nome do proprietário

O processo que você descreve e propõe uma substituição se aplica apenas ao nível mais baixo, Validação de Domínio (DV).

DV é o nível em que a validação é relativamente simples de automatizar, como o que o LetsEncrypt fez, e fornece um nível de confiança semelhante ao que o DNS poderia fornecer se fosse usado como a única fonte de uma âncora de confiança (implicações na interface do usuário, cert pode confiável, mas contém dados adicionais que não são de forma alguma validados).

Autenticação baseada em DNS de entidades nomeadas (DANE)

O DANE se baseia no DNSSEC (como a autenticidade dos dados DNS é crucial) para publicar informações de ancoragem de confiança para clientes TLS no DNS.

Ele usa o TLSAtipo RR e pode ser usado para identificar o certificado ou a chave pública ( seletor ) da entidade final ou da CA, com ou sem exigir também que a validação regular da cadeia de certificados seja bem-sucedida ( uso do certificado ) e como o certificado / key data é representado no registro ( tipo correspondente ).

O TLSAnome do proprietário ficha tem um prefixo que indica que a porta e de protocolo (por exemplo _443._tcp) e o RDATA indica o cert usage, selectore matching typemodos para além do cert / dados-chave para corresponder. Consulte a seção 2.1 da RFC6698 para obter as especificações desses parâmetros.

Um TLSAregistro pode, por exemplo, ter esta aparência:

_443._tcp.www.example.com. IN TLSA  2 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971

Com os modos de uso 2ou 3(indica o uso apenas da âncora confiável TLSA), um cliente compatível com DANE aceitaria um certificado que não seja assinado por uma CA geralmente confiável, mas que corresponda ao TLSAregistro.
Conceitualmente, é o mesmo que você propõe em sua pergunta.

A pegada? Atualmente, os clientes que reconhecem o DANE são mais ou menos inexistentes, um problema é que o próprio DNSSEC não é tão amplamente implantado (especialmente a validação na máquina do cliente) quanto o que provavelmente seria necessário para o DANE decolar. Provavelmente um problema de galinha e ovo, considerando que o DANE é um dos primeiros casos de uso potencialmente grandes que dependem de dados DNS autenticados.

Há um plug-in de navegador que adiciona validação DNSSEC e DANE , além disso, não há muito o que esteja próximo do mainstream neste momento. E, sendo um plug-in e não suportado nativamente, ele serve mais como prova de conceito do que qualquer outra coisa quando se trata de uso geral.

Isso poderia ser feito. Foi considerado. Ainda poderia acontecer, mas não houve muito movimento.