Confrontiamo i flussi di lavoro dei due processi, in particolare il modo in cui la chiave di handle compromette.
Segreto precondiviso
Il server genera una coppia di chiavi, la copia su ogni macchina client (manualmente, tramite uno script, ecc.). Durante la connessione al server, il client verificherà che la chiave pubblica presentata corrisponda a quella che hanno memorizzato nella cache per quel server (concettualmente, questo è lo stesso metodo di identificazione delle impronte digitali di SSH).
Upside : non è necessario l'inconveniente di ottenere un certificato firmato da una CA. È possibile generare la coppia di chiavi del server e avviare immediatamente la distribuzione ai client.
Lato negativo : il recupero da un compromesso chiave è difficile o impossibile perché non esiste alcun meccanismo per il server che notifica i client di un compromesso chiave, tranne che spinge una nuova coppia di chiavi a tutti i client. Si consideri che un utente malintenzionato ha la chiave privata del server e può intercettare il traffico tra il client e il server (sia per bloccare il push della coppia di chiavi aggiornato, sia per man-in-the-middle la connessione del client al server). Il client si fiderà dell'attaccante e crede che stia parlando con il server autentico e non c'è nulla che tu possa fare per impedirlo perché a un livello fondamentale, i segreti pre-condivisi non hanno meccanismi di revoca.
Certificato
Sì, è fastidioso (ea volte costoso) ottenere un certificato, ma la fiducia non dipende più dalla possibilità di spingere la chiave precondivisa ai client.
Parte del processo di convalida di un certificato è che il client raggiunga la CA e si assicuri che il certificato non venga revocato e che se non riesce a raggiungere la CA, ciò viene considerato un errore. Lo spoofing di questo controllo di revoca richiede che l'hacker comprometta non solo la chiave privata del server, ma anche la chiave privata della CA. Se il server si rende conto che la sua coppia di chiavi è stata compromessa e chiede alla CA di revocarla, tutti i client lo sapranno immediatamente perché i controlli di revoca online falliranno.
La revoca è la ragione principale per utilizzare i certificati qui, ma considera anche che un utente malintenzionato può intercettare il push della chiave pubblica iniziale e sostituirlo con la propria chiave pubblica. Forse sei l'amministratore di rete e puoi garantire la distribuzione sicura delle chiavi pubbliche, ma i certificati rendono questo un punto controverso perché anche se l'attaccante può intercettare la distribuzione del certificato, lo spoofing di un certificato richiede di compromettere la CA.