Capire SSL man-in-the-middle e le sue limitazioni

Question

Capire SSL man-in-the-middle e le sue limitazioni

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

1

Sto cercando di sviluppare un buon senso di come funziona un SSL man-in-the-middle (s) (MITM). A quanto ho capito, i MITM fanno il loro lavoro in due modi:

Decifra il protocollo SSL con una copia della chiave privata del server. A rigor di termini, questo non è il MITM poiché il "dispositivo MITM" sta semplicemente ascoltando. La sessione SSL non è stata modificata
Genera nuovi certificati al volo. Qui, il dispositivo MITM inoltra il client ciao, intercetta il server cert, genera e ne firma uno nuovo e inoltra al client. Il cliente si fida del certificato o gli viene chiesto di fidarsi (se è autofirmato)

Ci sono limitazioni (e attenuazioni), però:

Il client e il server potrebbero accettare di generare e scambiare le chiavi utilizzando DHE_RSA (o una variante). Il MITM non parteciperebbe alla generazione delle chiavi. Ma un MITM abbastanza sofisticato non può ancora generare chiavi di sessione che creano sessioni ssl distinte su entrambi i lati?
Non sarebbe lo stesso per il Master Secret esteso? Come sopra, se il MITM stava effettivamente calcolando distinte chiavi di sessione, il Master Secret esteso non aiuterebbe a sconfiggere il MITM
Il server potrebbe richiedere un certificato client. Ma se il MITM potesse acquisire il proprio certificato client e la corrispondente chiave privata, potrebbe firmare con successo i messaggi di verifica del certificato Verify

Sto comprendendo tutto questo correttamente? Sembra che se un MITM avesse accesso a un numero sufficiente di materiale chiave, potrebbe decodificare con successo qualsiasi sessione SSL.

tls certificates man-in-the-middle diffie-hellman ssl-interception

posta The_Glidd 03.05.2017 - 18:57

fonte

2 risposte

Leggi altre domande sui tag tls certificates man-in-the-middle diffie-hellman ssl-interception

Quando utilizzare le chiavi private e quando evitare in SSL? È sicuro imparare il nuovo telecomando per il suo normale codice aperto (rolling-code)?

score 1 · Answer 1

Penso che tu abbia alcuni dei concetti giusti, ma ci sono anche alcuni malintesi o inesattezze.

La decrittografia del traffico in un uomo passivo nell'attacco intermedio (cioè solo lo sniffing) utilizzando la chiave privata del server è possibile solo quando viene utilizzato lo scambio di chiavi RSA. Non può essere fatto con lo scambio di chiavi Diffie-Hellman. Contrariamente allo scambio di chiavi RSA, lo scambio di chiavi DH causa anche inoltro segreto che significa che le connessioni precedentemente sniffate non possono essere decodificate una volta che l'attaccante ha ottenuto la chiave privata del certificato.
Un uomo attivo nell'attacco intermedio consiste in una sessione SSL dal client al MITM e dal MITM al server. Queste sono sessioni completamente separate che hanno chiavi diverse e possono anche usare un diverso codice, versione del protocollo ecc. Se l'aggressore MITM ha la chiave privata originale del server, può impersonare perfettamente il server usando il certificato originale. In caso contrario è necessario utilizzare un certificato falso (spesso creato dinamicamente). L'attacco ha esito positivo solo nel secondo caso se il cliente si fida già della CA che rilascia il certificato falso o il client non esegue la convalida del certificato corretta.
I certificati client sono simili ai certificati server: l'utente malintenzionato ha la chiave privata del certificato originale e quindi può utilizzarlo o il server deve in qualche modo fidarsi del certificato falso degli attaccanti che non riesce a validare correttamente il certificato.

score 1 · Answer 2

La minaccia più ovvia con il MITM è dove l'interazione è semplificata, come tra un sito Web e un browser. Nella maggior parte dei casi l'utente digita semplicemente l'URL e si aspetta di vedere una notifica che la connessione è sicura. Se il sito presentato corrisponde alla loro aspettativa, fanno i loro affari.

In modo divertente MITM viene utilizzato all'ingrosso da gateway di sicurezza per eseguire il filtro dei contenuti sulle connessioni HTTPS. In questi casi il gateway funge da proxy per tutto il traffico in uscita; la connessione HTTPS è tra il client e il gateway. Negli ambienti aziendali, il reparto IT ha generalmente eliminato la CA radice per il gateway di tutte le macchine in-house, consentendo al client di accedere al certificato del gateway e mostrare la connessione come sicura. Il gateway quindi decrittografa la richiesta, filtra come appropriato e rende la propria connessione sicura al server. Questo vale anche per proteggere le connessioni SMTP e qualsiasi altro protocollo che sia forzato con proxy.

Uno degli omaggi nello scenario sopra riportato è che il certificato utilizzato dal gateway di solito identifica la connessione come con un fornitore di gateway (sia esso Sophos, Checkpoint, Fortinet, ecc.)

Nel caso di attori malintenzionati l'obiettivo è l'intercettazione surrettizia. Affinché questo abbia successo, l'attore avrà compromesso una CA radice genericamente affidabile. Attraverso tale compromesso l'attore può emettere un nuovo certificato con tutti i dettagli attesi per il server.

Supponiamo che gli ospiti dell'hotel (Alice) soggiornino in un locale ostile. Vogliono usare i servizi di Bob.com. L'attore Malory sta provando il MITM.

Malory si collega a Bob.com e copia tutti i dettagli aziendali del certificato SSL di Bob.com. Malory ha precedentemente compromesso la CA Root WeTrust che è integrata in Windows, macos, ios e Android.

Malory si inserisce nella rete dell'hotel (può essere un tocco fisico, un reindirizzamento della porta all'interruttore o anche un semplice attacco DHCP). Malory reindirizza tutto il traffico attraverso il suo proxy trasparente in cerca di accesso a Bob.com.

Quando Alice accede a Bob.com, il proxy di Malory si presenta ad Alice come Bob.com utilizzando il certificato contraffatto. Nel frattempo, Malory si connette a Bob.com e inoltra richieste / tira / spinge / mette / ecc tra i due. A meno che Alice non guardi l'emittente della CA principale e sappia chi è l'emittente del certificato SSL di Bob.com (e anche a condizione che l'emittente del certificato SSL di Bob.com non sia la stessa compromessa da Malory) non avrebbe modo di rilevare il MITM.

MITM riguarda l'inserimento di se stessi nello scambio di chiavi, senza violare la crittografia e utilizzando il semplice monitoraggio del traffico wireshark / Netflow.