Per proteggere da un attacco man-in-the-middle, almeno uno degli endpoint della comunicazione deve avere una conoscenza preliminare dell'altro endpoint. Solitamente è compito del cliente verificare che stia parlando con il server giusto, perché i server tendono a consentire potenzialmente a qualsiasi client di connettersi a loro. Il termine generale per il tipo di infrastruttura che fornisce questa conoscenza precedente è una infrastruttura a chiave pubblica .
Nel caso di HTTPS, la conoscenza precedente normalmente viene fornita con il passaggio intermedio di un'autorità di certificazione . Un browser Web contiene un elenco predefinito di CA con le loro chiavi pubbliche e accetta un sito Web come originale se può dimostrare che la sua chiave pubblica è stata firmata dalla chiave privata di una CA.
Nel caso di SSH, la conoscenza preliminare deriva normalmente dall'aver contattato il server in precedenza: il client registra la chiave pubblica del server e rifiuta di procedere se la chiave pubblica del server non è quella registrata. (Questo esiste anche per HTTPS con blocco dei certificati .) Alla prima connessione, è attivo per l'utente SSH per verificare la chiave pubblica.
Non esiste uno standard seguito dal software VPN. Devi leggere la documentazione del tuo software VPN. Nelle distribuzioni aziendali, è comune implementare il certificato del server nei computer dei dipendenti insieme al software VPN o richiedere al dipendente di effettuare una prima connessione alla VPN dall'interno della rete aziendale in cui non si teme un attacco MITM. Il certificato viene quindi archiviato nella configurazione del software VPN e il client VPN rifiuterà di connettersi se la chiave pubblica del server cambia.
Se stai distribuendo un servizio VPN per uso personale o per l'uso della tua organizzazione, dovresti occuparti del provisioning del certificato del server al momento dell'installazione, prima di uscire allo scoperto. Se una rete sicura non è disponibile, è necessario affidarsi ad altri canali di comunicazione per inviare il certificato. Potrebbe essere un'e-mail, se è così che si identificano gli utenti, ma sarebbe meglio fare affidamento su un'infrastruttura pre-esistente come le chiavi GPG (inviare il certificato in una e-mail firmata) - il che ovviamente sposta il problema solo su come verificare la chiave GPG.
Se si utilizza un servizio VPN basato su cloud, tale servizio dovrebbe fornire un modo per verificare il certificato (ad esempio una pagina Web servita su HTTPS) e deve documentare come installare il certificato o come verificarlo prima uso. Ancora una volta, non esiste un singolo processo seguito da tutto il software VPN.