Stavo leggendo questo articolo link e questa linea ha attirato la mia attenzione, "Con TLS configurato correttamente, DNSSEC non aggiunge nulla. " La mia reazione istintiva era di non essere d'accordo, ma più ci pensavo, mi sono reso conto che non potevo pensare a un contro esempio. Certo, ho solo una comprensione superficiale di DNSSEC, ma sembra corretto. Mi manca qualcosa?
TL; TR: In alcuni casi d'uso come HTTPS (web) DNSSec non è realmente necessario. In altri casi d'uso come SMTP (mail) lo spoofing del DNS non verrà notato da TLS, che è man-in-the-middle possibile se il DNS può essere falsificato anche se TLS stesso è usato correttamente.
dettagli:
Se utilizzato all'interno di HTTPS (web) e del sistema CA attualmente stabilito, non è necessario DNSSec, perché il browser controlla il nome nell'URL rispetto al nome nel certificato e convalida la catena di fiducia utilizzando uno spazio memorizzato localmente (pre- trusted) root-CA. Tuttavia, tieni presente che il corretto rilascio del certificato stesso potrebbe essere influenzato dallo spoofing del DNS (vedi sotto).
Con SMTP (trasporto della posta) la situazione è diversa. Per ottenere l'hop successivo all'interno della consegna della posta, l'agente di trasferimento della posta (MTA) deve sapere quale server è responsabile del dominio del destinatario. Questo è fatto cercando il record MX in DNS. Se questo record può essere falsificato (cosa che può essere eseguita senza DNSSec), il MTA recapiterà la posta al server di posta sbagliato. Anche se la consegna viene eseguita con TLS, l'MTA di invio non noterà se MX segnala il server degli hacker come server di destinazione, poiché il nome host del server degli autori di attacchi e il nome all'interno del certificato continueranno a corrispondere. Un meccanismo simile a MX per la posta esiste per SIP (VoIP) sotto forma di record SRV e ha quindi gli stessi problemi.
A parte questo ci sono altri protocolli che si basano su DNS sicuri. Il più importante è il probabile DANE che tenta di sostituire il sistema CA attualmente utilizzato ma guasto con un sistema in cui il certificato previsto è archiviato nello stesso posto del nome host, che si trova all'interno del DNS. Allo stesso modo è possibile anche memorizzare chiavi host SSH.
Inoltre, nel sistema attuale con CA pubblica pre-attendibile, la maggior parte dei controlli di identità effettuati durante l'emissione di un certificato di dominio convalidato può essere falsificata se l'utente malintenzionato è in grado di eseguire lo spoofing DNS nel posto giusto. Ciò include il caso in cui la convalida del dominio viene eseguita con la posta o in cui viene eseguita la convalida accedendo a un file specifico sul sito solo con HTTP (perché il sito non ha ancora HTTPS). Mentre nel primo caso il record MX dovrà essere spoofato, nel secondo caso è necessario spoofare record A / AAAA o CNAME. E una volta che l'attaccante ha ottenuto il certificato per il sito in questione, l'attacco MITM contro il sito non verrà più notato.