Se un MITM ha la tua chiave pubblica e tu stai facendo SSH attraverso il MITM, qual è l'attacco massimo che può perpetrare?

Con SSH, la coppia di chiavi del server viene effettivamente utilizzata per firme : il server invia al client un dato e firma . Verificando la firma, il client si assicura che il dato sia realmente dal server previsto. Quel "pezzo di dati" contiene una chiave pubblica Diffie-Hellman che il server ha appena generato e il client lo usa per fare lo scambio di chiavi crittografiche.

Per riuscire a fare un attacco Man-in-the-Middle , l'attaccante deve o ottenere la chiave privata DH (ma sfortuna, il server lo mantiene, e ricostruirlo dalla controparte pubblica è troppo costoso per essere effettivamente fatto con la tecnologia attuale), o alimentare il client con una chiave pubblica DH falso per cui l'attaccante conosce la parte privata. Ma il client non accetterà una falsa chiave pubblica DH dall'attaccante, perché quel falso non sarà firmato con una firma corrispondente alla chiave pubblica del server (la chiave pubblica "permanente", non quella DH).

Per essere brevi, tutti conoscono la chiave pubblica; è pubblico. Non è un problema se l'hacker conosce la chiave pubblica. Quale sarebbe un problema è se il client ha non conosce la chiave pubblica del server, perché in quel caso il client non sarebbe in grado di verificare la firma dal server. Senza questa verifica, il malintenzionato può sottrarre il client con un pacchetto DH falso e l'attacco MitM ha esito positivo.

Il client "conosce" la chiave pubblica del server ricordandola . Questo è il motivo per cui la prima connessione a un server è fondamentale: a quel punto, il client non conosce ancora la vera chiave pubblica del server. Il client deve verificare l'impronta digitale della chiave (ad esempio) telefonando al server sysadmin.

Tutto ciò si basa sulla magia della crittografia asimmetrica:

• Puoi verificare una firma con la chiave pubblica, ma la produzione di nuove firme richiede la conoscenza della chiave privata e la chiave privata non può essere (praticamente) dedotta dalla chiave pubblica.

• Lo scambio di chiavi DH consiste in messaggi scambiati pubblicamente, mittente e destinatario accettano infine un "segreto condiviso" ottenuto elaborando questi messaggi, e tuttavia qualcuno che osserva solo questi messaggi non può ricalcolare il messaggio stesso segreto.

La matematica è coinvolta.

Se hanno solo la tua chiave pubblica, non c'è molto che possano fare se viene utilizzata la crittografia, in quanto non saranno in grado di comunicare come se fossero te.

Questo è il motivo per cui è chiamato pubblico. . . Tutti possono avere una copia della tua chiave pubblica. Tutto ciò che crittografano con la tua chiave pubblica può essere decifrato solo dalla tua chiave privata e viceversa.

Nella crittografia asimmetrica, ognuno ha le chiavi pubbliche e solo l'entità che viene verificata dalla chiave pubblica ha la chiave privata. La chiave pubblica e la chiave privata sono collegate in modo tale che la chiave pubblica non rivela nulla sulla chiave privata, ma che il titolare della chiave privata può dimostrare la propria identità facendo verificare a qualcuno una sfida utilizzando la chiave pubblica.

Fondamentalmente, qualcosa che viene crittografato con una chiave pubblica può essere decifrato solo dalla chiave privata e qualcosa che viene crittografato con la chiave privata può essere decifrato solo con la chiave pubblica.

Per dimostrare che il server è quello che sostengono di essere, crittografano una sfida con la loro chiave privata (che solo loro hanno) e la chiave pubblica viene utilizzata per verificare che la sfida possa essere decifrata, quindi l'altra parte ha il privato chiave.

Per parlare in modo sicuro con il server, la chiave pubblica viene utilizzata per crittografare una chiave di sessione simmetrica. Quella chiave di sessione è crittografata con la chiave pubblica e inviata al server. Solo il server valido (che ha la chiave privata) può decodificare la chiave di sessione, in modo che solo il client (che ha creato la chiave di sessione) e il server con la chiave privata possano comunicare.

La chiave pubblica è attendibile dal client perché è firmata in modo simile da un'autorità di certificazione radice inclusa nel browser.

Aggiornamento: ho interpretato erroneamente la domanda come SSL, non SSH. L'idea di base è ancora più o meno la stessa, ma il certificato del server spesso non verrà firmato da una CA, nel qual caso il certificato deve essere verificato manualmente la prima volta dopo il quale il client deve tenere traccia di chi è stato connesso all'ultima volta . Lo scambio di chiavi differisce anche in base a come viene concordata una chiave, ma non conosco le strette di mano SSH e conosco le SSL, quindi vedi la risposta di Thomas Pornin per questo.

Poiché è attuale, c'è qualcos'altro che devi considerare. Il MITM senza controllo del punto finale è una cosa, ed è piuttosto sicuro (meno gli indebolimenti di alcuni terroristi di stato), ancora non tiene conto del MITM più efficace che è se hanno accesso al tuo server non criptato, game over. Possono copiare la chiave privata ed eseguire un attacco MITM MAN-AT-THE-END piuttosto tham, che è efficace al 100%, come in controllo MATE.