Ho letto molto su Superfish (e simili ad-ware) ultimamente e fondamentalmente capisco la vulnerabilità agli attacchi MITM. Ma in realtà mi chiedo se la " scansione sicura della connessione " di Kaspersky Antivirus sia infranta come nell'esempio Superfish?
Voglio dire che Kaspersky installa un certificato di root sul mio computer e "man in the middles" tutte le connessioni per cercare malware. Per quanto ne so, questo non è migliore del disastro Superfish ... cosa rende Kaspersky più sicuro?
Speriamo che qualcuno esegua i test e fornisca una risposta definitiva per Kaspersky. Nel frattempo, ecco una risposta per il caso generale:
Dipende.
L'esecuzione di un proxy SSL contro di te indebolisce la tua posizione di sicurezza? Certamente. Qualunque prodotto dato indebolirà la tua postura di sicurezza tanto quanto Superfish? Questo è molto dipendente dall'implementazione e anche soggetto alle minacce contro il singolo prodotto stesso.
Superfish fallito in due punti critici.
Ha usato una password debole per proteggere una chiave privata che non era univoca per ogni sistema. Questo ha portato la chiave a essere facilmente irrintracciabile e divulgata pubblicamente in modo che chiunque potesse fingere di essere il tuo proxy Superfish autorizzato.
Non è riuscito a convalidare correttamente alcune condizioni sui certificati SSL, che hanno permesso al proxy Superfish di accettare certificati altrimenti non validi e di presentare il sito web all'utente finale come se fosse legittimo.
Mentre la prima parte è un'interruzione importante, è la seconda parte che è probabilmente il difetto più critico. Senza il secondo difetto, gli utenti sarebbero comunque relativamente ben protetti finché la chiave restasse segreta. (Principio di Kerckhoffs in azione). Tuttavia, dato questo secondo difetto, un utente malintenzionato non avrebbe nemmeno bisogno della chiave per lanciare un attacco Man-in-the-Middle convincente tra un utente Superfish e un sito Web altrimenti sicuro.
Tenendo conto di ciò, esistono alcune semplici contromisure che possono proteggere in larga misura gli utenti.
Genera chiavi radice univoche per ogni installazione, proteggili con password forti e uniche e non distribuire le chiavi oltre l'host su cui risiede il proxy. Ciò impedisce che la divulgazione della chiave per un sistema abbia un impatto sostanziale sulla sicurezza di altri.
Convalidare i certificati SSL correttamente e fornire notifiche appropriate all'utente quando qualcosa non va. Senza questo, la chiave non ha molta importanza: un utente malintenzionato deve solo convincere il proxy che il suo sito è legittimo, sfruttando un difetto nel processo di convalida e il proxy presenterà il sito come tale all'utente.
Fai in modo che queste cose siano corrette, e sei a posto - giusto? Bene, non proprio.
Vedi, ora incontriamo un problema con la presentazione del certificato all'utente. Poiché il proxy deve intercettare il traffico e ridigitarlo con le proprie credenziali, l'utente non vede mai le credenziali originali del sito. Ogni sito sembra avere un certificato emesso dal proxy, con data e ora in base a quando il proxy ha generato il certificato MitM. Ciò rimuove completamente la capacità dell'utente di decidere quali CA o attendibili i percorsi ritenuti credibili o di riconoscere le modifiche nel certificato nel tempo. Inoltre impedisce la convalida del certificato con altre entità esterne attendibili.
Si prenda il caso di DigiNotar, in cui un utente malintenzionato è stato in grado di utilizzare una CA radice comunemente utilizzata per generare certificati fasulli per i servizi Google. Senza un proxy SSL in atto, l'utente può essere avvisato di attività sospette con uno o più mezzi diversi.
Con un proxy, tutte queste opzioni non sono più disponibili per l'utente finale. Il proxy stesso può essere configurato per controllare e segnalare questi problemi (proprio come alcuni plug-in del browser) ma alla fine l'utente finale perde comunque la capacità di vederlo da solo.
Leggi altre domande sui tag network malware tls certificates man-in-the-middle