L'autenticazione reciproca ha qualche impatto sulle possibilità MiTM?

Question

L'autenticazione reciproca ha qualche impatto sulle possibilità MiTM?

#1 da (8 voti)

6

Quando si effettua un attacco Man-in-the-middle contro un classico server di autenticazione unidirezionale, l'autore dell'attacco deve solo:

Utilizza un certificato sufficientemente credibile per essere considerato attendibile dalla vittima,
Agire come client standard verso il server reale, inoltrando le richieste della vittima.

Tuttavia, mi chiedevo se l'utilizzo dell'autenticazione reciproca TLS potesse avere un impatto in questo schema?

Può un utente malintenzionato:

Impersonare il server durante il passaggio autenticazione server ,
Avvia l'handshake TLS verso il server reale,
Trasmettere la comunicazione tra il server reale e la vittima (sfide, risposte, ...) per passare il passaggio autenticazione client ,
E quindi essere ancora in grado di decifrare, spiare e alterare la comunicazione tra i due host?

Questo scenario è sempre possibile, dipende forse dalla suite di cifratura utilizzata?

In particolare nel passaggio 3) l'attaccante è costretto a inoltrare dati autentici di handshake (anche se firmati dal suo falso cert) dal server al client, possono essere usati questi dati di handshake per stabilire un segreto tra il vero client e server che impedisce ulteriori azioni da parte dell'utente malintenzionato (ad esempio una magia Diffie-Hellman-Merckle) o annulla la sessione (ogni parte ha i segreti mancanti, nessuno è più in grado di perseguire la comunicazione)?

tls man-in-the-middle

posta WhiteWinterWolf 08.05.2015 - 16:45

fonte

1 risposta

Leggi altre domande sui tag tls man-in-the-middle

L'uso degli emoji può rendere la password di qualcuno più sicura? In che modo Facebook può interrompere un attacco bruteforce su un account?

score 8 · Accepted Answer

Un Man-in-the-Middle è in realtà una doppia imitazione simultanea: gli attaccanti si pongono come server falso quando si parla al client e come client falso quando si parla al server. La bellezza del MitM è che poiché la rappresentazione è simultanea, l'attaccante può sperare di riutilizzare le risposte dal vero client o server, quando risponde al vero server o client.

I dettagli contano. TLS utilizza i certificati X.509 e li usa correttamente, il che lo rende efficace contro alcuni possibili attacchi.

Supponiamo che l'autore dell'attacco sia riuscito in qualche modo a fingersi un server falso, ad es. corrompendo o compromettendo una CA per rilasciare un certificato falso o, più probabilmente, convincendo l'utente umano a ignorare l'avvertenza del browser sul certificato del server non valido. L'hacker ora trasmette le informazioni avanti e indietro tra client e server. Il server ora desidera autenticare il client con un protocollo basato su password (ad esempio il protocollo "mostra la password" semplice e molto comune), dentro il tunnel TLS. L'attaccante può semplicemente lasciare che il flusso del protocollo, e, una volta fatto e il server è contenuto, davvero dirottare il flusso di dati e iniettare i propri comandi.

Ora prova di nuovo, ma con un certificato client . Quando un certificato client viene utilizzato in SSL / TLS, il client dimostra la sua padronanza della sua chiave privata calcolando una firma su una "sfida" dal server. In modo cruciale , questa "sfida" è in realtà la concatenazione di tutti i precedenti messaggi di handshake (vedi lo standard ). In particolare, il certificato del server è parte di ciò che è firmato dal client. Il nostro aggressore potrebbe raggiungere quel punto nel MitM inviando al client un certificato falso del server, ovvero un certificato distinto da ciò che il vero server ha inviato. Quindi, ciò che il cliente firma e ciò che il server usa per verificare quella firma sarà una sequenza distinta di byte, e la firma non corrisponderà.

Riepilogo: se per "autenticazione reciproca" si intende "autenticazione con un certificato client, gestito a livello SSL / TLS", l'autenticazione impedirà il MitM. O, più precisamente, l'aggressore avrà successo solo se riuscirà a ottenere un falso certificato del server che convincerà il client e un falso certificato client che convincerà il server.

Tuttavia, se le due autenticazioni non sono accoppiate (come accade nel protocollo password-in-TLS), un utente malintenzionato che riesce a impersonare il server può facilmente trasformarlo in un MitM completo riutilizzando le risposte del client.