Prevenire un attacco uomo in mezzo con un certificato autofirmato usando IP non DNS

1

Ho cercato domande simili ma non riesco a trovare la risposta di cui ho bisogno.

Prevenire uno spoofing nell'attacco centrale?

Dopo aver letto questa domanda:

Man "Autorizzato" nel mezzo

Penso di poter cogliere il problema (semplificato).

Il client tenta di stabilire una connessione con un server di destinazione. Un proxy dirotta la connessione. Il proxy avvia una connessione crittografata al server di destinazione. Il proxy crea un certificato contraffatto e lo invia al client e avvia una connessione crittografata. Il proxy è quindi un uomo nel mezzo.

Senza una CA il client non sa se ha effettuato una connessione autentica.

La mia domanda riguarda il modo in cui il proxy riesce a dirottare la connessione. Se il client DNS è stato compromesso, potrei vedere un caso in cui l'IP risolto potrebbe essere l'IP dei proxy.

Se il client effettua una connessione direttamente utilizzando un indirizzo IP, il proxy sarebbe ancora in grado di intercettare il traffico? Forse un router ostile potrebbe farlo.

    
posta Uzer 10.02.2017 - 19:22
fonte

3 risposte

2

Se il proxy si trova nel percorso della connessione, può intercettare il traffico. Questo è il caso di un proxy definito esplicitamente nel browser e anche con proxy trasparenti installati su un dispositivo in cui tutto il traffico in uscita deve passare attraverso (come un firewall). È anche il caso in cui un utente malintenzionato nella rete locale reindirizza il traffico utilizzando lo spoofing ARP. Lo spoofing del DNS è rilevante solo se gli hostname sono coinvolti, ma tutti gli altri casi funzionano anche con l'indirizzo IP come target.

    
risposta data 10.02.2017 - 19:35
fonte
1

Fondamentalmente tutte le comunicazioni possono essere intercettate se vengono tolte dal cavo, non importa dove vanno. TCP / IP deve essere instradabile, quindi i pacchetti possono essere ispezionati (sola lettura) ma anche manomessi (riscritti) da qualsiasi nodo tra mittente e destinatario.

I router e i firewall Layer-3 con ispezione dei pacchetti possono farlo facilmente, anche su larga scala a causa della scarsa potenza di calcolo (10000 pacchetti al secondo non sono un problema). Indovina cosa sta facendo l'NSA, usano esattamente queste parti hardware.

Nella mia azienda, ad esempio, utilizziamo un cosiddetto acceleratore WAN che tenta di memorizzare il traffico http (s) per non avere così tanto carico sui nostri collegamenti WAN intra-aziendali. L'idea è buona, ma ecco il problema: molti siti usano già https, quindi l'acceleratore WAN non ha potuto accelerare nulla.

Per essere in grado di farlo, tutti i nostri computer ottengono un certificato attendibile spinto dal criterio di gruppo in Windows o archiviato in AD, non conosco lo sfondo. Quindi, l'acceleratore WAN trova un pacchetto che ha uno scambio https (SSL) all'interno e si sostituisce quando hai descritto la chiave pubblica (Fornirà anche un certificato "falsificato" con il nome DNS che il client ha richiesto o probabilmente un indirizzo IP se non viene fornito alcun nome) in modo che il cliente sia ingannato nel pensare che stia comunicando in modo sicuro con il destinatario finale.

Invece sta comunicando con l'acceleratore WAN e ora può memorizzare nella cache / accelerare qualsiasi cosa.

Il punto è che la mia azienda (oi miei componenti IT della mia azienda) possono (in teoria) leggere tutto il mio traffico bancario privato ecc. su questo nodo di accelerazione. Che bello!

Vedrai ancora che questi siti non hanno il "badge verde" nella barra del browser, ma non ci saranno avvisi riguardo all'intercettazione.

    
risposta data 10.02.2017 - 19:34
fonte
1

il proxy intercetta sempre il traffico.

No non può leggere il traffico se si utilizza il certificato della destinazione desiderata.

può leggere il traffico se falsifica la chiave pubblica, ma il browser visualizza un avviso, quindi

No non c'è modo di intercettare e leggere il traffico senza generare un avviso del browser.

La mia spiegazione inizia con questa frase:

The proxy creates a public key and sends it to the client and starts an encrypted connection.

Questo non è esattamente il modo in cui funziona. Il proxy dovrebbe inviare un falso certificato al browser, che includerebbe la chiave pubblica ma dovrebbe anche contenere altre informazioni, come il dominio che possiede la chiave. Inoltre, l'intero certificato è firmato digitalmente e quindi resistente alle manomissioni. La firma può essere verificata utilizzando la chiave pubblica dell'organizzazione che ha emesso il certificato. Quella chiave pubblica è a sua volta verificata da un altro certificato SSL, lungo tutta la catena, fino a quando non si raggiunge la CA. Il certificato CA è installato come parte del tuo sistema operativo, quindi la sua chiave pubblica è ben nota.

Quindi, a meno che il proxy non abbia una delle chiavi private della catena di trust, è impossibile che il proxy fornisca al browser un certificato falso o una chiave pubblica alternativa senza che il browser sappia che è falso-- può generare la firma

Se il proxy non può fornire un falso, non c'è modo di convincere il browser che la chiave pubblica e il nome del dominio vanno insieme, e il browser visualizzerà un avviso di phishing, trasformando la barra degli indirizzi in rosso.

Anche se si accede a un host tramite l'indirizzo IP, il certificato è ancora richiesto e il nome del dominio sul certificato può ancora essere visualizzato dall'utente finale. Il browser girerà sempre la barra degli indirizzi in rosso. Inoltre, l'utente finale può fare clic su un pulsante nel browser per visualizzare il certificato e determinare manualmente se il nome del dominio è corretto. Se il nome del dominio è sospetto, l'utente dovrebbe chiudere il browser e smettere di usare quell'endpoint.

    
risposta data 11.02.2017 - 02:39
fonte