L'autenticazione della chiave pubblica in SSH impedisce la maggior parte degli attacchi MITM?

Question

L'autenticazione della chiave pubblica in SSH impedisce la maggior parte degli attacchi MITM?

#1 da (2 voti)
#2 da (1 voti)

4

Ho trovato questo articolo che afferma che la firma crittografica asimmetrica della chiave ottenuta da DH impedisce MITM:

link

Idea chiave:

The value of 'signature' is a signature by the corresponding private key over the following data, in the following order:
string    session identifier
byte      SSH_MSG_USERAUTH_REQUEST
Now the attacker has a problem, as the client and the server have different ideas about what session identifier is supposed to be. Obviously, the server will reject the signature supplied by the client and public-key authentication will fail.

Vorrei verificare se la mia comprensione di ciò è corretta:

Lascia che Alice ( A ) sia client, MITM ( M ) un utente malintenzionato e Bob ( B ) un server ssh.

Ipotesi:

M si trova nel mezzo della comunicazione, intercettando tutte le comunicazioni tra A e B
M in qualche modo ingannato A nel pensare che sia B e anche ingannato B a pensare che sia A (re impronte digitali ecc.)
Tuttavia, M non è riuscito a penetrare nella macchina di A né nella macchina di B , lasciando la chiave pubblica di A nell'account A su B macchina intatta

Finché le condizioni sopra riportate rimangono sopra:

The session identifier is calculated based on (among other things) the shared secret negotiated by the peers using Diffie-Hellman algorithm.

= > mentre M può falsificare gli scambi DH in A e B , quelli necessariamente dovranno essere 2 diversi (finti) segreti condivisi (a meno che non ci sia un modo per M di comprometterli con modificando scambiati i numeri DH, non osservandoli).

Quando questo segreto condiviso viene utilizzato come componente della creazione di dati da firmare (parte o l'intero identificatore di sessione), una cosa che M non può falsificare e non sa è la chiave privata di A che verrà utilizzata per la firma dell'ID di sessione basato sul (1) segreto condiviso simulato.

Pertanto, la firma digitale dell'ID di sessione (+ altri dati di sessione per descrizione sopra) non riesce la verifica a B , oppure gli ID di sessione non corrispondono, interrompendo in modo efficace la comunicazione.

Domande:

questo ragionamento è corretto? se no, dove sono gli errori?
l'ID sessione crea il "link più debole" in questa catena? Cioè, se M potrebbe prevederlo (ad esempio se è prevedibile hash unidirezionale che è suscettibile di attacco statistico, anche se DH non lo è) e indovinarlo in qualche modo (molto improbabile, sì, ma è anche teoricamente impossibile ?), quindi M avrebbe l'ID di sessione "genuino" firmato da A e quindi B penserebbe che la firma dell'autenticazione sia OK?

Mi rendo conto che è praticamente impossibile in pratica, ma è completamente teoricamente impossibile?

ssh vulnerability man-in-the-middle diffie-hellman asymmetric

posta wtfantastic 11.09.2014 - 20:00

fonte

2 risposte

Leggi altre domande sui tag ssh vulnerability man-in-the-middle diffie-hellman asymmetric

Dove inviare il malware raccolto dal mio honeypot? Privacy all'interno delle nuove leggi U.K. per gli ISP

score 2 · Answer 1

1. Sì è corretto. Ci sono 2 modi possibili:

A) Alice blindly accepts the new fingerprint from the attacker mallory. Alice and Mallory could connect and authenticate each other. Problem here for Mallory is, that he couldn't sign the session id, exchanged with Bob. Because Mallory doesn't own Alice's private key. And also Mallory couldn't redirect the signed session id from Alice to Bob, because the session id would be, with high probability, different.

B) When Alice doesn't blindy accept the new fingerprint, Mallory could send the public key and thereof the fingerprint from Bob. Problem here would be that Mallory couldn't authenticate to Alice, because Mallory didn't own the private key from Bob.

AVVISO: nel caso A), quando Alice accetta anche un'autenticazione tramite password, la mallory configura il suo server per autenticare il client con l'autenticazione della password e quindi la mallory otterrebbe il nome utente e la password.

2. Sì, teoricamente sarebbe possibile. Vedi in A), perché Alice non dovrebbe accettare il giusto ID firmato da Bob? Avrebbe accettato :) E anche Alice avrebbe accettato l'id firmato da Bob. Mallory ha bisogno solo di mostrare ad Alice la chiave pubblica di Bob al momento della creazione della connessione.

score 1 · Answer 2

Ecco dove fallisce questo. Presumi:

M somehow tricked A into thinking that he's B and also tricked B into thinking he's A (re fingerprints etc).

Le impronte digitali sono qualcosa che non può essere duplicato. Un'impronta digitale (altrimenti nota come HMAC) è un hash della chiave segreta. La chiave segreta non viene mai trasmessa, ma calcolata indipendentemente dal client e dal server utilizzando la chiave master preshsared .

In PKI, la chiave privata e pubblica sono utili perché a) la chiave privata non può essere derivata dalla chiave pubblica eb) la chiave pubblica può essere utilizzata per crittografare i dati che possono essere decifrati con la chiave privata del server e vice versa.

Pertanto, senza conoscere la chiave privata del server, non è mai possibile eseguire un attacco MITM utile su una sessione SSH. Inoltre, la maggior parte delle volte SSH riprenderà semplicemente una sessione invece di negoziarne una nuova. Ciò comporta l'invio dell'ID di sessione in testo semplice, ma la ripresa della crittografia con la suite di cifratura predeterminata, che è sconosciuta all'attaccante o [M], in questo scenario.