Usa DANE per autenticare il mittente della posta

1

Ho la mia infrastruttura DNS virtuale, dalla radice al server di posta mail.example.com . Tutto è firmato usando DNSSEC.

[email protected] può inviare email a [email protected] , firmato digitalmente con il suo certificato. Poiché entrambi i client si fidano della stessa CA, client2 può convalidare questo messaggio.

Che cosa succede se la CA è compromessa? Discutere della verosimiglianza di un tale evento non è il punto. Quindi voglio aggiungere un ulteriore livello di sicurezza. Voglio aggiungere il record DANE per il certificato di client1.

Come posso aggiungere un record DANE per il certificato del mittente dell'e-mail?

Qualcosa come:

[email protected]   IN TLSA ...   AwAeKhf...
    
posta TomatoGuy 13.05.2015 - 11:08
fonte

2 risposte

3

Questo non è ciò per cui DANE è stato inventato. I record TLSA devono fornire maggiore sicurezza principalmente per connettersi a endpoint di trasporto (ad esempio, porte TCP) su host denominati , in modo che i certificati per i nomi host possano essere indipendenti dal certificato autorità. Con DNSSEC, questo può essere ottenuto in modo crittograficamente sicuro.

Alcuni lo considerano uno svantaggio, che qualcuno che controlla un livello di nomi di dominio può controllare tutti i nomi e i certificati presenti su quei nomi. In realtà i proprietari del dominio radice (.) Possono falsificare in modo sicuro qualsiasi nome host e con DANE, anche un certificato sicuro.

RFC6698 lo spiega in questo modo:

DNS-Based Authentication of Named Entities (DANE) offers the option
to use the DNSSEC infrastructure to store and sign keys and
certificates that are used by TLS.  DANE is envisioned as a
preferable basis for binding public keys to DNS names...

Esiste (almeno una) proposta correlata di memorizzare la posizione delle chiavi PGP dell'utente nel DNS dei loro domini di posta nei record TXT, ma lo scopo principale è rendere più semplice la ricerca di una chiave, non di verificare effettivamente esso.

C'è IS uno standard proposto RFC4398 per archiviare effettivamente i certificati, ma poiché è stato creato prima che DNSSEC fosse diffuso, si consiglia di non memorizzare interi certificati se causerebbero una risposta UDP superiore a 512 byte. Nemmeno a me sembra che sia ampiamente utilizzato.

Dal momento che tutte le verifiche degli utenti avvengono nel software server che richiede una configurazione aggiuntiva, di solito c'è poco bisogno di aspettarsi certificati client emessi dalla CA ufficiale e / o un modo standardizzato di memorizzare copie aggiuntive di detti certificati. Sei effettivamente libero di implementare tali verifiche nel tuo programma / sito.

Se ritieni che la compromissione della CA possa rendere non validi i certificati utente, potresti essere più semplice aggiungere ogni certificato utente singolarmente come certificato attendibile, ad esempio.

    
risposta data 22.12.2015 - 21:15
fonte
2

DMARC e DKIM sono usati per lo scopo che descrivi. Nessuna infrastruttura CA è necessaria.

Per DKIM, tutto ciò che devi fare è generare una coppia di chiavi RSA pubblica / privata, pubblicare la chiave pubblica in DNS e dire al tuo software di firma di usare quella chiave privata.

Il client riceverà un'email con una firma DKIM nell'intestazione. Utilizzerà quindi le informazioni incorporate per navigare verso la voce DNS e ottenere la chiave pubblica. E verifica

DKIM è speciale poiché ti consente di firmare molti account di posta con la stessa chiave. In alternativa, puoi utilizzare un ambito diverso per utente e pubblicare quelle chiavi in DNS.

    
risposta data 23.12.2015 - 01:33
fonte

Leggi altre domande sui tag