Sono un po 'nuovo in quest'area e ho letto gli attacchi Man-in-the-middle. Quasi ovunque la soluzione fornita sembra essere quella di utilizzare una terza parte affidabile come un'autorità di certificazione.
C'è un risultato di impossibilità che implica che questo non possa essere risolto dalle due parti comunicanti per conto proprio? C'è un modo per farlo senza usare una CA?
Non è necessario utilizzare una CA, anche con HTTPS. È sufficiente utilizzare un certificato autofirmato sul server se si fornisce al cliente una copia o simile (cioè un'impronta digitale) del certificato in un modo sicuro (a prova di manomissione) prima che il client si connetta al server in modo che il client possa verificare che parla al server previsto Se il client non è in grado di verificare il server man in the middle gli attacchi sono possibili.
Il concetto di certificati firmati CA (ad es. infrastruttura a chiave pubblica (PKI) ) viene creato solo perché la condivisione di un i certificati delle foglie firmati con tutte le parti non sono scalabili. Con CA il browser / sistema operativo dispone di un elenco di trust ancore (certificati radice) e può derivare il trust in un certificato server basato su una catena di attendibilità dalla radice attendibile al certificato foglia. Grazie a questo meccanismo, è necessario condividere solo la CA radice affidabile, ma non tutti i possibili certificati server.
Oltre a un certificato precondiviso oa informazioni pubbliche simili (come l'impronta digitale di un server SSH), le connessioni resistenti al MITM possono anche essere stabilite utilizzando un segreto condiviso su entrambi i lati. Questo è il caso tipico del Wi-Fi domestico protetto con WPA.
La protezione limitata contro MITM è ottenuta con Trust On First Use (TOFU). In questo caso l'identità del peer viene salvata dalla prima connessione e applicata alle seguenti connessioni nella speranza che l'autore dell'attacco non fosse presente alla prima connessione, cioè che l'identità ricevuta fosse la vera identità del peer previsto. Questo viene fatto ad esempio se si accetta un certificato autofirmato in HTTPS.
SSH è un esempio di TOFU (Fiducia al primo utilizzo) che non richiede una CA (o addirittura una terza parte) per essere coinvolto nello stabilire una relazione di fiducia.
La maggior parte delle chiavi pre-condivise (ad es. utilizzate per WPA in wifi o utilizzate in una soluzione VPN) possono fornire una certa protezione contro gli attacchi MitM se utilizzate correttamente e senza dover stabilire un trust tramite CA (o PKI), e senza la necessità di coinvolgere token crittografici.
Considera anche che MitM può essere facilitato da una CA (ad esempio, quando una CA è obbligata a emettere certificati senza eseguire i controlli richiesti per convalidare l'identità - a causa di un compromesso, pressione legale o malizia), e che usando una PKI non offre necessariamente alcuna protezione contro MitM - stabilisce semplicemente che un dato token (una chiave) è ragionevolmente credibile per rappresentare un'affermazione (di identità), e scarse scelte crittografiche potrebbero, per esempio, annullare qualsiasi e tutte quelle rivendicazioni / affermazioni.
Aggiornamento :
Come sottolineato da @ Steffen Ullrich nei commenti di seguito, TOFU è suscettibile di MitM durante il prima connessione. Questo potrebbe essere mitigato (ad esempio fornendo un meccanismo per convalidare le chiavi host che vengono presentate). Seguendo questa prima connessione, sei al sicuro da MitM o totalmente esposto.
Avevo intenzione di indicare il TOFU come un approccio diverso per stabilire la fiducia (lasciando gli utenti a capire, in sostanza), ma Steffen ha assolutamente ragione che TOFU e PKI adottano un approccio fondamentalmente diverso per convalidare l'identità inizialmente, con il TOFU che fa una decisione progettuale di non di affrontare il rischio di MitM durante la prima connessione - quindi i due modelli di fiducia hanno un impatto diverso sulla capacità di proteggersi contro MitM.
Poiché la domanda riguardava il motivo per cui molta letteratura MitM menziona PKI, questa è una risposta parziale: degli approcci più comuni alla protezione contro MitM, una soluzione basata su PKI fornisce una protezione maggiore rispetto ad altri approcci come il TOFU.
Il client ha bisogno di un modo per verificare che il server sia quello che dice di essere.
Ci sono vari modi per verificarlo:
Leggi altre domande sui tag authentication certificates man-in-the-middle certificate-authority