Por que não podemos usar o DNS para distribuir certificados SSL?

Question

A maioria dos provedores de certificados SSL de baixo custo realmente apenas verifica se você controla um nome de domínio. Para esses tipos de certificados, em vez de pagar a terceiros para verificar se eu controle os registros DNS do domínio, por que não "assinar" o certificado no DNS? Se eu gerar um par de chaves em um servidor e publicar a mesma chave pública no DNS para o nome do host, eu pensaria que seria um nível equivalente de segurança.

Eu vejo dois problemas com o design, mas ambos parecem mínimos:

1. Os certificados EA e os certificados de nível superior que verificam detalhes pessoais / corporativos não podem ser feitos dessa maneira. Organizações que desejam pagar para obter a barra verde em navegadores estão livres para continuar fazendo isso.
2. Uma rede mal-intencionada com servidores DNS desonestos pode redirecioná-lo para um nome de host diferente e um certificado SSL confiável diferente. Talvez o DNSSEC possa resolver esse problema de repúdio?

Não tenho conhecimento de nenhum navegador que esteja implementando algo assim, mas parece que seria um bom método pelo menos obter uma conexão confiável e criptografada sem exibir a temida caixa de diálogo "Certificado não confiável". Além das questões que mencionei acima e das autoridades de certificação comercial existentes que lutam contra a ideia, existem outras razões para fazer isso seria uma má idéia?

    

Answer 1

Já é perfeitamente possível codificar um certificado X.509 dentro de um registro DNS - veja o tipo de registro CERT em RFC 4398 .

A principal razão pela qual isso não está sendo feito com muita raiva é porque o mecanismo de transporte ainda não está seguro. Isso mudará dramaticamente no final deste ano, quando a zona de raiz receber o DNSSEC assinado e mais e mais DPNs suportarem DNSSEC.

O tamanho da consulta DNS (como mencionado em outro lugar) também é uma preocupação, embora seja interessante notar que o CERT RR também permite que você simplesmente armazene o URL do qual o certificado X.509 real pode ser baixado. Neste ponto, há um problema de galinha e ovo, embora ...

    

Answer 2

Os certificados SSL devem validar a identidade do site, para que o usuário final possa ter certeza de que sua solicitação não tenha sido desviada por um servidor DNS envenenado, transmissão BGP falsa ou outro truque sujo que também permita um falso certificado veiculado pelo DNS para parecer válido.

Eu digo "supostamente" porque então tudo ficou diluído com certificados "instantâneos" que não provam nada em particular, e para ser honesto, acho que os fornecedores de navegadores devem exibir o aviso "certificado não confiável" para todos os certificados não auditados ou em frente e permitir certificados auto-assinados sem avisar. O status quo é inconsistente.

    

Answer 3

Desde que eu fiz esta pergunta anos atrás, houve algum desenvolvimento positivo no sentido de tornar isso uma realidade. A combinação de DNSSEC para proteger seu DNS com certificados TLS publicados no DNS permite esse objetivo. O Google Chrome já suportou certificados grampeados por DNSSEC já há algum tempo e agora RFC6698 Autenticação baseada em DNS de entidades nomeadas (DANE) é uma tentativa de padronizar esse suporte.

Passarão mais alguns anos até que o suporte ao navegador para isso seja generalizado, mas estou ansioso por isso.

    

Answer 4

A falta de padronização e a sobrecarga de gerenciamento adicional (muito mais fácil simplesmente soltar uma chave / certificado em uma máquina do que ter que adicionar também uma chave - que provavelmente será bastante longa e, portanto, baterá com o pacote UDP limite) são as coisas que matam isso de uma perspectiva prática. A falta de um DNS seguro é um pouco preocupante, mas para alvos de baixo valor não é realmente uma redução prática na segurança. No entanto, para serviços internos, apenas importamos nosso próprio certificado de CA para que você não ganhe nada de verdade, e qualquer site público que SSL desejará um certificado "real" de qualquer maneira.

Eu esperaria ver uma folga massiva e FUD dos provedores de certificados comerciais se algo assim fosse seriamente empurrado (rascunhos RFC, implementações de referência, etc) - como qualquer parasita, eles ficam terrivelmente aborrecidos quando sua vaca leiteira parece que pode ser abatido.

    

Answer 5

Talvez seja melhor manter as coisas simples, ou seja, não fazer o DNS fazer mais do que deveria. Eu sou meio cauteloso em adicionar coisas, especialmente quando se trata de segurança. As vezes menos é mais. A principal razão por trás do meu pensamento é que o DNS e o SSL não estão no mesmo domínio e não possuem funcionalidade e propósito similares.