Come prevenire attacchi man-in-the-middle a fianco di SSL?

Bene, ci sono molte opzioni diverse da SSL per prevenire un attacco uomo nel mezzo, ma la maggior parte di esse ha una base crittografica simile. Fondamentalmente, per garantire che una comunicazione non possa essere attaccata da un uomo nel mezzo, è necessario essere in grado di dimostrare che a) entrambe le parti possono convalidare l'altra eb) che nessun'altra parte può monitorare la comunicazione.

Entrambi questi sono più comunemente realizzati attraverso un segreto condiviso. Le operazioni crittografiche asimmetriche possono essere utilizzate anche quando entrambe le parti hanno una chiave pubblica attendibile per l'altra, tuttavia questo è molto più difficile (a livello computazionale) rispetto allo scambio di un segreto condiviso e quindi al suo utilizzo.

Il segreto condiviso può essere pre-condiviso, come nel caso di una rete wifi crittografata, oppure può essere negoziato attraverso un processo di autenticazione. Ad esempio, con SSL, il server si convalida con il client tramite la firma della chiave pubblica, il client stabilisce quindi un segreto condiviso con il server utilizzando il certificato attendibile del server e il server quindi convalida il client tramite un login tradizionale (o eventualmente un certificato cliente in rari casi.)

Questo processo generale non è univoco per SSL, ma i passaggi fondamentali per verificare l'identità di una o entrambe le parti e stabilire una chiave di comunicazione sicura sono i bit critici. Se, tuttavia, la radice del trust per quel certificato fosse stata compromessa, sarebbe stato possibile per qualcuno avere un ruolo centrale in quanto potevano fingere di essere il server e aprire la propria connessione con il server e la propria connessione con il client.

In caso di perdita di una chiave privata, il certificato deve essere revocato tramite un elenco di revoche. Questo è generalmente pubblicato da una CA ed è incluso come parte del certificato firmato. Come condizione per convalidare la validità del certificato, l'elenco di revoca dovrebbe essere controllato per la validità.

Sembra che quello che stai chiedendo è: come posso prevenire un MITM se la mia chiave privata potrebbe essere compromessa? E a questo, la risposta è ottenere una nuova chiave privata (e quindi nuovo certificato).

Se la tua politica di sicurezza è così disastrosa che uno stagista è in grado di caricare la tua chiave privata SSL su github, allora che è il tuo problema. Le chiavi private sono private e devono essere protette come tali. Nessuno dovrebbe avere accesso alla propria chiave privata, il che significa che le persone dovrebbero essere fisicamente o tecnologicamente impossibilitate ad accedervi. Non è sufficiente istituire una politica che dice "non caricare la chiave privata per usenet". Devi effettivamente impedire l'accesso indesiderato ai dati privati.

A meno che tu non possa farlo, non hai alcuna speranza di mantenere alcuna parvenza di sicurezza dei dati.

Inoltre, sembra che tu stia confondendo la chiave privata con il certificato. Puoi fare quello che vuoi con il certificato (che include i certificati firmati); mandalo via email agli amici, pubblicalo sul tuo muro di Facebook, pubblicalo su Github, tutto è sicuro. Ma la chiave privata non dovrebbe mai lasciare il computer in cui è stata generata.

Mentre il MITM si svolge nella fase di scambio delle chiavi, puoi applicare la crittografia basata su ID , dove il pubblico la chiave è l'ID del destinatario per impedirlo.