Perché RFC4255 (SSHFP) non è utilizzato per https?

13

Ho avuto questa idea qualche ora fa, ma ovviamente esiste già e c'è persino un RFC .. .
Perché non pubblichiamo l'impronta digitale per il certificato SSL / TLS tramite DNS? Abbiamo bisogno di DNSSEC per assicurarci che la risposta sia legittima e dobbiamo assicurarci che i server dei nomi siano in un ambiente sicuro, ma a parte questo non vedo problemi che SSL / TLS non ha già.

Questa modifica sposterebbe l'autorità per proteggere tutto il nostro traffico crittografato dalle autorità di certificazione (CA) ai server dei nomi DNS. Questo potrebbe essere un problema perché in questo caso, tutti i provider DNS (che hanno DNSSEC) dovrebbero diventare ambienti ad alta sicurezza come le CA ora. Ma non dovrebbero essere già tutti i nameserver? La maggior parte dei siti Web utilizza semplicemente http per il traffico sensibile e la maggior parte delle persone non noterebbe se non è presente un lucchetto quando accede a Google. Direi che hanno già un'enorme responsabilità.

Se non ci si fida dei server dei nomi del dominio, potremmo includere invece le impronte digitali nei server di root, ma non sono sicuro di quanto carico extra sarebbe.

Un altro problema è che DNSSEC non è ancora ampiamente implementato. Ma il motivo della mia richiesta è perché l'IETF sta considerando di supportare la crittografia in http / 2.0 senza richiedere la verifica del certificato "per semplificare la distribuzione".

A mio parere, la sicurezza dovrebbe essere fatta correttamente o per nulla. Non dare alle persone un falso senso di sicurezza. Ma se cambieremo comunque i protocolli (aggiorneremo tutti i server web), potremmo anche implementare DNSSEC e farlo nel modo giusto (autenticato).

I problemi / modifiche in breve:

  • dobbiamo fidarci dei nameserver (root?) invece di una tonnellata di CA;
  • dobbiamo aggiungere un tipo di record dns o estendere l'uso del record sshfp; e
  • dobbiamo supportare più ampiamente dnssec.

Mi manca qualcosa? Perché stiamo pagando un dollaro superiore per i certificati SSL / TLS quando tutto ciò che dobbiamo fare è pubblicare l'impronta digitale del certificato su un canale autenticato?

Il punto di crittografia non autenticato in http 2.0 è di incoraggiarlo abilitandolo senza dover modificare alcuna altra configurazione. Sono contrario perché è inutilmente lento (un altro roundtrip per lo scambio di chiavi, che è particolarmente grave all'estero o con qualsiasi perdita di pacchetti) e difficilmente aggiunge sicurezza. Potrebbe anche fornire un falso senso di sicurezza. Dal lato positivo, offusca il traffico.

Questa proposta di utilizzare il DNS rende un po 'più di lavoro implementare la crittografia sui server Web, ma lo rende (almeno quasi) sicuro quanto il normale SSL / TLS mantenendo comunque una disponibilità diffusa di crittografia molto elevata (non mi aspetto che manterremo i prezzi incredibilmente alti per un server dei nomi sshfp / httpfp / tlsfp abilitato come con i certificati). La crittografia non autenticata potrebbe essere ancora l'ultima risorsa quando tutte le altre opzioni (certificato firmato, certificato memorizzato, impronta digitale pubblicata in modo sicuro) non sono disponibili (anche se non dovrebbero essere mostrate all'utente perché fornisce un senso di sicurezza completamente falso), ma io sono non sono sicuro che valga anche il rallentamento.

Se non è possibile utilizzare i server di root per questo, potremmo anche utilizzare i server dei nomi del dominio come "ambienti ragionevolmente sicuri" (normale lucchetto) e utilizzare un certificato firmato da una CA per EV (barra verde). Quindi chiedi alle persone di cercare la barra verde quando fanno banking online. I server dei nomi hanno già una grande responsabilità, quindi potrebbe essere abbastanza sicuro anche se non possiamo aspettarci che siano sicuri come una CA. Almeno sarebbe un sistema molto più flessibile; Sono limitato al mio dominio e a un sottodominio per qualsiasi certificato a prezzi ragionevoli (e il sottodominio è già occupato da "www.").

Di nuovo la mia domanda in breve: c'è qualche ragione per cui non usiamo un sistema simile a SSHFP per https, se DNSSEC erano ampiamente disponibili?

    
posta Luc 27.08.2013 - 21:00
fonte

3 risposte

16

C'è RFC per questo . Fa parte di ciò che DNSSEC intende fare.

Ora non fidarti troppo del "miglior dollaro" o della sua riduzione. La necessità di "certificare" in qualche modo le chiavi pubbliche per quanto riguarda i nomi dei server non viene rimossa magicamente passando a DNSSEC. Il ruolo "CA" viene spostato e i costi associati sono ancora lì. Si può prevedere che se i registrar devono assumersi questi costi, i loro prezzi aumenteranno. Prima o poi qualcuno dovrà pagare per questo, e ho il strong sospetto che sarà il proprietario del server SSL.

Filosoficamente , non è chiaro se la fusione della struttura di certificazione (PKI) e della struttura di denominazione (il DNS) sia una buona idea. L'unione semplificherà sicuramente le comunicazioni tra DNS e PKI quando si tratta del caso specifico dell'emissione di certificati associati ai nomi host; ma significa anche che le due responsabilità si intrecciano. Ci vuole una buona dose di pio desiderio di credere che chiunque sia un buon registrar sarebbe anche un buon CA; i due tipi di attività sono vagamente simili, ma non identici.

Inoltre, i certificati dovrebbero avere un ambito oltre i server HTTPS; dovrebbero essere utilizzabili in contesti che non hanno alcuna relazione con i nomi DNS e host, ad esempio quando si firmano software (applicazione, driver ...).

Economicamente , non cambierebbe molto. Tra le CA commerciali, la più utilizzata è VeriSign, alias Symantec. Passare a DNSSEC significa che l'autorità di certificazione definitiva non sarà più VeriSign, ma chiunque gestirà la maggior parte del DNS root, cioè VeriSign. Ora QUELLO sarebbe cambiato, non sarebbe?

Politicamente , ci sarebbero problemi con "stato CA". Molte delle dozzine di CA che sono considerate attendibili da un sistema Windows sono "vanity CA" sponsorizzate o addirittura gestite da vari governi. Gli stessi governi non hanno intenzione di gestire infrastrutture relative al DNS che richiedono molta più larghezza di banda e disponibilità; e si sarebbero risentiti nel vedere i loro certificati precioouuuss diventare "cittadini di seconda classe".

Per sicurezza , si tratta principalmente di un problema. Gli eventi di certificati falsi sono molto rari; sentiamo parlare di uno di questi eventi all'anno . La maggior parte delle frodi e phishing e altri attacchi legati a Internet non si basa sull'assuefazione alla CA esistente. In altre parole, l'attuale sistema CA funziona . Non aggiustare ciò che non è rotto. Sì, il sistema CA sembra fragile e incline ai fallimenti, ma nonostante molta pubblicità sulle violazioni occasionali, il fatto è che sopravvive.

Riepilogo: gli standard sono pronti, gli RFC sono pubblicati, il software è scritto. Ora tutto ciò che manca è un motivo per passare da un mondo "commerciale CA X.509" a un mondo "registrar commerciale DNSSEC". È difficile capire che cosa potrebbe effettivamente fare.

    
risposta data 27.08.2013 - 21:44
fonte
6

Il CERT RR è stato deprecato. L'attuale proposta di inserire materiale di chiave pubblica in DNS si chiama DANE. Hanno definito un tipo di record TLSA che è documenti in RFC 6698 . Ciò consente a un amministratore di dominio di dichiarare un certificato specifico o una CA per un servizio specifico.

    
risposta data 28.08.2013 - 07:12
fonte
3

Esiste - si chiama DANE - link (il CERT RFC non ha visto alcuna trazione, Non so perché).

Per generare i record puoi usare questo:

link

Questo plugin per Firefox può convalidarli:

link

sfortunatamente non è completo.

Il team di pattuglie di certificati ha un plug-in aggiornato:

link

ma non sembra che la dose funzioni: (

Non sembra esserci alcun altro supporto per altri browser, chrome ha il supporto scritto ma non pubblicato, vedi questo post del blog (Se TLSA è importante per te, forse invia un'email ad Adam?):

link

Si noti che TLSA non solo consente di convalidare un certificato, ma consente anche al proprietario del sito di affermare che il certificato utilizzato sul proprio sito sarà firmato solo da una CA particolare, il che va in qualche modo a mettere il ladro / hackerato Problemi di CA per riposare.

Ricorda che qualsiasi CA (o affiliata di una CA, o una filiale di una CA ecc.) può firmare un certificato per qualsiasi dominio . Perché l'ecosistema CA sia sicuro ogni CA deve essere sicuro!

    
risposta data 09.09.2013 - 18:04
fonte

Leggi altre domande sui tag