Ottieni informazioni crittografate su un proxy MITM

L'errore non è nel protocollo, è nelle persone . O, discutibilmente, negli strumenti , chi dovrebbe gestire le questioni che sono troppo tecniche per gli utenti umani per fare correttamente.

Il protocollo SSL indica come vanno le cose e che la connessione sarà sicura, in particolare contro Man-in-the-Middle attack :

-  The negotiation of a shared secret is secure: the negotiated
   secret is unavailable to eavesdroppers, and for any authenticated
   connection the secret cannot be obtained, even by an attacker who
   can place himself in the middle of the connection.

Ma questo contiene solo se il protocollo è veramente seguito fino in fondo, e, in particolare, se la convalida della chiave pubblica del server non è "scorciatoia".

Pertanto non c'è nulla da cambiare nel protocollo . Quando gli strumenti non implementano correttamente il protocollo, l'errore di solito risiede negli strumenti, non nel protocollo.

Potremmo obiettare che se i browser consentono ancora di bypassare l'avviso di "certificato scadente" (sebbene tale avviso sia aumentato nella scarsità rossastra nel corso degli anni), ciò potrebbe indicare che i presupposti del protocollo non sono realisticamente sostenibili. Vale a dire, richiedendo che tutti i server Web abbiano un certificato SSL che i browser client possono validare potrebbe essere un po 'troppo chiedere. Ma, onestamente, la sicurezza deve iniziare da qualche parte . La crittografia non crea trust, trasferisce fiducia . Non puoi avere un protocollo che garantisca che il client parlerà sempre con il server "giusto" senza avere, almeno, una nozione precisa di cosa "giusto" significhi in quel contesto.

Se il phishing o MitM attacca con un falso certificato del server, cliccato dall'utente, diventa troppo diffuso, prevedo che i produttori di browser rimuovano del tutto il bypass e applichino la rigorosa convalida X.509. Vedremo tra qualche anno.

MitM può verificarsi in alcuni modi. Nello scenario di cui parli, stai descrivendo dove il MitM sta effettuando due connessioni, una per il client e una per il server. Non sta decodificando o spezzando TLS. L'avviso del certificato ti consente di sapere che le informazioni non provengono direttamente dal server.

Allo stesso tempo, se si conoscono le chiavi di crittografia o in un secondo momento possono apprenderle e aver salvato il traffico, è possibile decifrare il messaggio. Se è possibile imitare il mittente in tempo reale, è sufficiente decrittografare il traffico, creare nuovo traffico e crittografare nuovamente come se si trattasse del mittente legittimo. L'obiettivo di MitM può essere quello di origliare o manipolare.

Negli ambienti aziendali, gli amministratori di sistema possono spesso "interrompere" TLS o altra crittografia perché controllano i PC client e possono installare i certificati appropriati sul client per fidarsi del firewall di decodifica TLS / SIEM / ecc. In questo caso, l'utente finale sul client non saprebbe che il loro traffico viene decodificato.

L'intercettazione e la manipolazione dei dati possono anche essere eseguite non sulla rete, ma sul mittente o sul destinatario utilizzando malware o tecniche man-in-the-browser.

A meno che non si usi un sistema honeypot / honeynet per iniettare traffico falso o usare intenzionalmente una cattiva crittografia, non sono sicuro di come si possa far credere all'aggressore di aver avuto successo quando in realtà non lo faceva. Avranno o dati inutili o avranno dati che possono elaborare. Ad esempio, con HTTPs, decodificalo e hai qualcosa che è comprensibile per un utente e un pezzo di software, o hai un linguaggio senza senso che non può essere elaborato. Sebbene sia possibile, è altamente improbabile che il messaggio crittografato venga decifrato in un formato che sembra comprensibile, ma non è vero senza conoscere il sistema reale.

Se sai quali chiavi ha già l'hacker e le tecniche che stanno utilizzando potrebbe essere possibile iniettare traffico sulla rete che sarebbero in grado di intercettare e decodificare per pensare di aver ricevuto il messaggio, ma probabilmente si interrogheranno su tutto il resto del traffico che non stanno decodificando e che sta usando chiavi diverse.

L'utente è sempre il link più debole. Se hai il protocollo migliore e più incredibilmente sicuro di sempre, ma l'attaccante convince l'utente a mandargli un assegno, non significa che ci sia un problema con il protocollo, significa che c'è un problema con gli utenti. L'utente deve ottenere informazioni da qualche parte per dire loro che il server è chi dicono di essere o non hanno modo di fidarsi della connessione. SSL è meglio avvisare l'utente di non fidarsi della connessione, ma offre comunque l'opzione. In teoria un client potrebbe semplicemente non consentire all'utente di accettare un certificato non attendibile, ma ciò potrebbe frustrare l'utente nel provare altri mezzi come l'utilizzo di una connessione non https.

Non esiste un modo magico per scoprire informazioni sul server legittimo (a meno che tu non abbia una conoscenza pregressa) che non può essere attaccato da un uomo nel mezzo che cambia le informazioni che pretendono di essere il server legittimo. Questo è il motivo per cui i sistemi più sicuri richiedono la gestione fisica delle precedenti chiavi di conoscenza che vengono trasportate sotto scorta armata. L'iniziale affermazione della fiducia è il tallone d'Achille della comunicazione di fiducia. Se l'utente sceglie attivamente di fidarsi delle persone sbagliate, questo è il loro problema, non un problema che può essere risolto con misure tecnologiche.

Per quanto riguarda qualcosa in cui l'utente malintenzionato potrebbe pensare di aver avuto successo ma in realtà non lo ha fatto, stai parlando del regno della crittografia denegabile lì e sarebbe piuttosto difficile o impossibile farlo con un flusso di cifratura a causa del modo in cui i dati è memorizzato. Avresti bisogno di dati che potrebbero essere decifrati con 2 chiavi diverse e che una decifrazione darebbe il risultato reale mentre l'altra darebbe qualcosa di falso.

Il problema è di due volte, tuttavia, quando si tenta di applicare questo a un codice di flusso. Primo, hai una relazione generalmente 1 a 1 tra testo cifrato e testo in chiaro. La crittografia più denegata richiede un volume di dati molto più ampio, alcuni dei quali sembrano essere spazzatura (ma in realtà è un segnale per l'altra chiave). Dato che ci si aspetterebbe una relazione 1 a 1, i dati in eccesso genererebbero bandiere.

Il secondo problema è la divulgazione chiave. Forti misure protettive contro il MITM richiedono che lo scambio di chiavi sia protetto. La maggior parte degli attacchi MITM quindi attacca lo scambio di chiavi e impedisce lo scambio di chiavi con il server previsto. Pertanto, non ci sarebbe un modo per fornire al server reale la chiave corretta e al contempo dare al MITM la chiave di diversione.