Mi stavo chiedendo. Utilizziamo molti certificati SSL. Oggi usiamo quasi esclusivamente letsencrypt (grazie!). La linea di fondo di questi certificati è che la prova della proprietà dei nomi di dominio sul certificato proviene dal potere di manipolare i record DNS o il sito Web in questi domini. La prova DNS deriva dall'aggiunta di una chiave (fornita da letsencrypt) come record TXT al DNS.

Quindi, SE è una prova sufficiente per poter cambiare i record DNS per un dominio, perché non usare certificati autofirmati con l'impronta digitale nel DNS?

Direi che questo fornisce esattamente la stessa quantità di fiducia della procedura basata su DNS di letsencrypt (e di altre CA):

1. Creare una CA autofirmata (basta seguire i passaggi delle varie procedure)
2. Crea un certificato per alcuni domini
3. Firma il certificato dal passaggio 2 con la CA dal passaggio 1. Ora hai un certificato di base, firmato da una CA non attendibile
4. Aggiungi un record TXT (o dedicato) al DNS di ciascuno dei domini, dichiarando: abbiamo firmato il certificato di questo dominio con questa CA. Come: 'CA = -fingerpint of CA-'
5. Un browser scarica il certificato e lo verifica confrontando l'impronta digitale del certificato CA / CA con i dati nel DNS per il dominio specificato.

Ciò consentirebbe di creare certificati autofirmati affidabili senza interferenze di terze parti, dello stesso livello di affidabilità di qualsiasi certificato SSL di base. Finché hai accesso al DNS, il tuo certificato è valido. Si potrebbe anche aggiungere un po 'di DNSSEC come la crittografia, per creare un hash dalla CA più il record SOA, per assicurarsi che la fiducia scompaia alle modifiche nel record DNS.

Questo è stato considerato prima?

Jelmer

L'infrastruttura di base, che lo renderebbe possibile, esiste ed è chiamata autenticazione basata su DNS di entità denominate (DANE) e specificata in RFC6698 . Funziona tramite un TLSArecord di risorse, che specifica il certificato o la sua chiave pubblica dell'entità finale o una delle sue CA nella catena (in realtà ci sono quattro tipi diversi, vedi RFC per i dettagli).

Adozione

DANE non ha ancora visto un'adozione diffusa. VeriSign monitora l' adozione di DNSSEC e DANE e ne traccia la crescita nel tempo :

Per fare un confronto, secondo VeriSign, esistono circa 2,7 milioni di zone DNS, quindi un po 'più dell'1% di tutte le zone ha almeno un record TLSA.

Non posso dare alcuna risposta autorevole, perché DANE, ma ecco le mie speculazioni:

DANE soffre dello stesso problema degli elenchi di revoche di certificati (CRL) e del protocollo di stato del certificato online (OCSP). Per verificare la validità di un certificato presentato, è necessario contattare una terza parte. Hanno Böck offre una buona panoramica , perché questo è un grosso problema in pratica. Si riduce al problema di cosa fare, quando non è possibile raggiungere la terza parte. I produttori di browser hanno optato per il soft-fail (noto anche come permesso) in questo caso, il che ha reso il tutto piuttosto inutile e Chrome alla fine ha deciso di disabilitare OCSP nel 2012.

DNSSEC

Probabilmente il DNS offre una disponibilità molto migliore rispetto ai server CRL e OCSP delle CA, ma rende comunque impossibile la verifica offline. Inoltre DANE, deve essere usato solo in combinazione con DNSSEC. Poiché il DNS normale opera su UDP non autenticato, è abbastanza soggetto a contraffazione, attacchi MITM, ecc. L'adozione di DNSSEC è molto meglio dell'adozione di DANE, ma è tutt'altro che onnipresente.

E con DNSSEC ci imbattiamo di nuovo nel problema del soft-fail. Per quanto ne so, nessun sistema operativo server / client principale fornisce un resolver DNSSEC di default.

Poi c'è anche il problema della revoca. DNSSEC non ha alcun meccanismo di revoca e si affida invece a chiavi di breve durata.

Supporto software

Tutti i software partecipanti devono implementare il supporto DANE.

In teoria, potresti pensare che questo sarebbe il lavoro delle librerie di crittografia e gli sviluppatori di applicazioni non dovrebbero fare molto, ma il fatto è che le librerie di crittografia in genere forniscono solo primitive e le applicazioni devono fare molta configurazione e installarsi (e sfortunatamente ci sono molti modi per sbagliare).

Non sono a conoscenza del fatto che qualsiasi server Web importante (ad esempio Apache o nginx), ad esempio, abbia implementato DANE o abbia in programma di farlo. I server Web sono di particolare importanza qui, perché sempre più elementi si basano su tecnologie Web e quindi sono spesso i primi, in cui le cose vengono implementate.

Quando guardiamo CRL, OCSP e pinzatura OCSP come confronto, potremmo essere in grado di dedurre come andrà la storia dell'adozione DANE. Solo alcune delle applicazioni che utilizzano OpenSSL, libnss, GnuTLS, ecc. Supportano queste funzionalità. Ci sono voluti un po 'di tempo per supportarlo da importanti software come Apache o nginx e riferendosi nuovamente all'articolo di Hanno Böck, hanno sbagliato e la loro implementazione è difettosa. Altri importanti progetti software, come Postfix o Dovecot , non supportano OCSPe hanno funzionalità CRL molto limitate, che in sostanza indicano un file nel file system (che non è necessariamente rileggere regolarmente, quindi è necessario ricaricare il server manualmente ecc.). Tieni presente che si tratta di progetti che utilizzano frequentemente TLS. Quindi puoi iniziare a guardare cose in cui TLS è molto meno comune, come PostgreSQL / MySQL per esempio e forse offrono i CRL al meglio.

Quindi non ho nemmeno implementato i moderni server Web e la maggior parte degli altri software non ha nemmeno implementato OCSP e CRL, buona fortuna con l'applicazione o l'appliance aziendale di 5 anni.

Potenziali applicazioni

Quindi dove potresti effettivamente usare DANE? A partire da ora, non su Internet in generale. Se controlli il server e il client, forse è un'opzione, ma in questo caso puoi spesso ricorrere al blocco delle chiavi pubbliche.

Nello spazio di posta, DANE sta ottenendo una certa trazione, poiché SMTP non ha avuto alcun tipo di crittografia di trasporto autenticata per il tempo più lungo. I server SMTP a volte hanno utilizzato TLS tra loro, ma non hanno verificato che i nomi nei certificati corrispondessero effettivamente, ora stanno iniziando a verificarlo tramite DANE.

Diversi tipi di procedure di convalida dei certificati

Con i normali certificati firmati dalla CA, esistono diversi livelli di convalida dei certificati:

• Convalida dominio (DV)
  Viene convalidata solo la proprietà del nome dominio, nel certificato viene mostrato solo il nome dominio "Oggetto"
• Convalida dell'organizzazione (OV) Il
  nome dominio e il nome del proprietario vengono convalidati, il nome dominio e il nome del proprietario vengono visualizzati come "Oggetto" nel certificato
• Extended Validation (EV) Convalida
  più rigorosa dell'entità proprietario, il nome di dominio e il nome del proprietario vengono visualizzati come "Oggetto" nel certificato, barra verde con nome del proprietario

Il processo che descrivi e per cui proponi un sostituto si applica solo al livello più basso, Domain Validation (DV).

DV è il livello in cui la convalida è relativamente semplice da automatizzare, come ciò che LetsEncrypt ha fatto, e fornisce un livello di affidabilità simile a quello che il DNS potrebbe fornire se fosse usato come unica fonte per un trust-anchor (implicazioni UI, cert potrebbe essere attendibile ma contenere dati aggiuntivi che non sono assolutamente convalidati).

Autenticazione basata su DNS di entità denominate (DANE)

DANE si basa su DNSSEC (poiché l'autenticità dei dati DNS è fondamentale) per pubblicare informazioni sull'ancoraggio di fiducia per i client TLS in DNS.

Utilizza il TLSAtipo RR e può essere utilizzato per identificare il certificato o la chiave pubblica ( selettore ) dell'entità finale o della CA, con o senza richiedere anche la regolare convalida della catena di certificati per riuscire ( utilizzo del certificato ) e come il certificato I dati / chiave sono rappresentati nel record ( tipo corrispondente ).

Il TLSAnome del record proprietario ha un prefisso che indica la porta e il protocollo (ad esempio _443._tcp) e la RDATA indica la cert usage, selectore matching typele modalità in aggiunta al CERT / dati chiave da abbinare. Vedere la sezione 2.1 di RFC6698 per le specifiche di questi parametri.

Un TLSArecord può ad esempio assomigliare a questo:

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

Con le modalità di utilizzo 2o 3(indica l'utilizzo del trust-anchor TLSA da solo), un client compatibile con DANE accetterebbe un certificato che non è firmato da una CA generalmente attendibile ma che corrisponde al TLSArecord.
Questo è concettualmente lo stesso di quello che proponi nella tua domanda.

La presa? I client con conoscenza DANE sono attualmente più o meno inesistenti, un problema è che DNSSEC stesso non è così diffuso (in particolare la convalida sul computer client) di quanto probabilmente sarebbe necessario per il decollo di DANE. Probabilmente un piccolo problema con l'uovo e la gallina, considerando che DANE è uno dei primi nuovi casi d'uso potenzialmente grandi che si basano su dati DNS autenticati.

Esiste un plug-in del browser che aggiunge la convalida DNSSEC e DANE , a parte il fatto che non c'è molto lì vicino al mainstream a questo punto. E, essendo un plug-in piuttosto che supportato in modo nativo, serve più come prova di concetto di qualsiasi altra cosa quando si tratta di uso generale.

Potrebbe essere fatto È stato considerato. Potrebbe ancora succedere, ma non c'è stato molto movimento.