Instal·lador de VPN des d'un mirall? Verifiqueu primer l'editor

El túnel funcionava, la interfície va aparèixer i la sessió va romandre estable durant una setmana. Res d'això no us diu qui va construir l'instal·lador. Un client VPN s'executa amb prou privilegis per reescriure rutes i llegir credencials, així que l'editor forma part del model d'amenaces, no és una nota a peu de pàgina.

Feu les comprovacions en ordre i atureu-vos a la primera que falli. Són barates i cadascuna tanca una escletxa diferent.

Primer pas: Baixeu del canal que el projecte anomena

Cada projecte documenta on viuen les seves versions, i aquella pàgina és la referència. Les compilacions comunitàries, les fitxes de les botigues i els portals de proveïdors són tots canals legítims. Cadascun és legítim només quan el projecte mateix hi apunta. Aquesta és la prova, i no és el mateix que semblar oficial.

Un fitxer amb el nom del projecte no demostra res. Canviar el nom d'un instal·lador és una operació d'un segon, i el nom és el que un resultat de cerca mostra primer.

Segon pas: Verifiqueu la signatura contra una identitat coneguda

La verificació de la signatura respon bé una pregunta estreta. Us diu que una identitat concreta va signar aquest binari i que el binari no ha canviat des d'aleshores. Respon una pregunta i en refusa una altra. No us pot dir si aquesta identitat és la que volíeu confiar.

# 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

Llegiu la identitat, no la paraula d'estat. Un desenvolupador no relacionat amb un certificat vàlid produeix una signatura vàlida. Un sistema operatiu que informa d'un editor reconegut només us ha dit que algú va pagar un certificat.

Tercer pas: Compareu el hash amb una font independent

Una suma de verificació demostra la concordança amb un valor de referència. Si la referència va arribar al costat de la descàrrega, totes dues poden ser errònies alhora i la comparació encara passa. Aquest és el mode de fallada de la majoria de tutorials. El hash és a la mateixa pàgina que el fitxer que descriu.

# 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

Quan un projecte publica sumes de verificació signades o un manifest de versió signat, verifiqueu la signatura sobre la llista en lloc de cada fitxer per separat. Així una referència de confiança cobreix tota la versió.

Després de la instal·lació: Manteniu el camí d'actualització

Un canal amb suport continua important després que acabi la instal·lació. Les compilacions reempaquetades poden portar el seu propi actualitzador, i aquest actualitzador decideix què s'executa el mes vinent. Una compilació que mai no s'actualitza no és més segura. Simplement és més antiga.

Anoteu com se suposa que s'ha d'actualitzar el client i si un sistema de gestió s'encarrega d'aquest pas. Si la resposta és una descàrrega manual d'un fòrum, la pregunta de la cadena de subministrament no s'ha tancat mai de veritat.

Dos orígens, no un

El desenvolupador del client i l'emissor del perfil són parts separades. Un client oficial que importa un perfil d'un operador no relacionat és un arranjament normal, i el perfil mereix la seva pròpia revisió: qui el va emetre, com es va lliurar i si el certificat del servidor coincideix amb el nom que espereu.

Manteniu tots dos orígens identificables a les vostres notes. En el moment que es substitueix un client o es restaura un dispositiu des d'una còpia de seguretat, aquestes dues línies són el que impedeix que una compilació desconeguda o un perfil desconegut tornin amb la resta de les dades.