Installer VPN da un mirror? Verificate prima l'editore

Il tunnel funzionava, l'interfaccia si è avviata e la sessione è rimasta stabile per una settimana. Niente di tutto ciò vi dice chi ha costruito l'installer. Un client VPN viene eseguito con privilegi sufficienti per riscrivere le rotte e leggere le credenziali, quindi l'editore fa parte del modello di minaccia, non è una nota a piè di pagina.

Eseguite i controlli in ordine e fermatevi al primo che fallisce. Sono economici e ciascuno chiude una lacuna diversa.

Primo passo: Scaricate dal canale che il progetto indica

Ogni progetto documenta dove risiedono le sue versioni, e quella pagina è il riferimento. Le build della community, le schede degli store e i portali dei fornitori sono tutti canali legittimi. Ciascuno è legittimo solo quando il progetto stesso lo indica. Questo è il test, e non è la stessa cosa che sembrare ufficiale.

Un file che porta il nome del progetto non dimostra nulla. Rinominare un installer è un'operazione di un secondo, e il nome è ciò che un risultato di ricerca mostra per primo.

Secondo passo: Verificate la firma rispetto a un'identità nota

La verifica della firma risponde bene a una domanda ristretta. Vi dice che una particolare identità ha firmato questo binario e che il binario non è cambiato da allora. Risponde a una domanda e ne rifiuta un'altra. Non può dirvi se quell'identità è quella di cui volevate fidarvi.

# macOS: who signed this app, and is the signature intact?
codesign -dv --verbose=4 /Applications/Tunnel.app
spctl -a -vvv -t install /Applications/Tunnel.app

# Windows: signature and publisher of the installer
Get-AuthenticodeSignature .\tunnel-setup.exe | Format-List Status, SignerCertificate

# Linux: detached signature from the project's release page
gpg --verify tunnel-1.4.2.tar.gz.asc tunnel-1.4.2.tar.gz

Leggete l'identità, non la parola di stato. Uno sviluppatore estraneo con un certificato valido produce una firma valida. Un sistema operativo che segnala un editore riconosciuto vi ha solo detto che qualcuno ha pagato per un certificato.

Terzo passo: Confrontate l'hash con una fonte indipendente

Un checksum dimostra la corrispondenza con un valore di riferimento. Se il riferimento è arrivato accanto al download, entrambi possono essere sbagliati insieme e il confronto passa comunque. È la modalità di errore nella maggior parte delle guide. L'hash si trova sulla stessa pagina del file che descrive.

# Linux and macOS
shasum -a 256 tunnel-1.4.2.dmg

# compare against the value published on the project's own release page
# not against a value copied from the same mirror

Quando un progetto pubblica checksum firmati o un manifest di rilascio firmato, verificate la firma sull'elenco anziché su ogni singolo file. Così un unico riferimento fidato copre l'intera release.

Dopo l'installazione: Mantenete il percorso di aggiornamento

Un canale supportato continua a contare dopo la fine dell'installazione. Le build reimpacchettate possono portare il proprio aggiornatore, e quell'aggiornatore decide cosa verrà eseguito il mese prossimo. Una build che non si aggiorna mai non è più sicura. È semplicemente più vecchia.

Annotate come dovrebbe aggiornarsi il client e se un sistema di gestione possiede quel passaggio. Se la risposta è un download manuale da un forum, la questione della catena di fornitura non è mai stata davvero chiusa.

Due origini, non una

Lo sviluppatore del client e l'emittente del profilo sono parti separate. Un client ufficiale che importa un profilo da un operatore estraneo è un assetto normale, e il profilo merita il proprio esame: chi lo ha emesso, come è stato consegnato e se il certificato del server corrisponde al nome che vi aspettate.

Tenete entrambe le origini riconoscibili nelle vostre note. Nel momento in cui un client viene sostituito o un dispositivo viene ripristinato da un backup, sono queste due righe a impedire che una build sconosciuta o un profilo sconosciuto tornino con il resto dei dati.