VPN-installer van een mirror? Controleer eerst de uitgever

De tunnel werkte, de interface kwam op en de sessie bleef een week stabiel. Niets daarvan vertelt je wie de installer heeft gebouwd. Een VPN-client draait met genoeg rechten om routes te herschrijven en inloggegevens te lezen, dus de uitgever hoort bij het dreigingsmodel, niet in een voetnoot.

Werk de controles op volgorde af en stop bij de eerste die mislukt. Ze zijn goedkoop, en elk sluit een ander gat.

Eerste stap: Download van het kanaal dat het project noemt

Elk project documenteert waar zijn releases staan, en die pagina is de referentie. Community-builds, winkelvermeldingen en leveranciersportalen zijn allemaal legitieme kanalen. Elk daarvan is alleen legitiem wanneer het project er zelf naar verwijst. Dat is de test, en het is niet hetzelfde als er officieel uitzien.

Een bestand dat naar het project is vernoemd, bewijst niets. Een installer een andere naam geven is een operatie van één seconde, en de naam is wat een zoekresultaat als eerste toont.

Tweede stap: Controleer de signatuur tegen een bekende identiteit

Signatuurverificatie beantwoordt een smalle vraag goed. Het vertelt je dat een bepaalde identiteit deze binary heeft ondertekend en dat de binary sindsdien niet is veranderd. Het beantwoordt de ene vraag en weigert de andere. Het kan je niet vertellen of die identiteit degene is die je wilde vertrouwen.

# 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

Lees de identiteit, niet het statuswoord. Een onbetrokken ontwikkelaar met een geldig certificaat levert een geldige signatuur. Een besturingssysteem dat een erkende uitgever meldt, heeft je alleen verteld dat iemand voor een certificaat heeft betaald.

Derde stap: Vergelijk de hash met een onafhankelijke bron

Een controlesom bewijst overeenstemming met een referentiewaarde. Als de referentie samen met de download arriveerde, kunnen beide tegelijk fout zijn en de vergelijking slaagt nog steeds. Dat is het faalpatroon in de meeste handleidingen. De hash staat op dezelfde pagina als het bestand dat hij beschrijft.

# 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

Wanneer een project ondertekende controlesommen of een ondertekend release-manifest publiceert, verifieer dan de signatuur over de lijst in plaats van over elk bestand afzonderlijk. Zo dekt één vertrouwde referentie de hele release.

Na de installatie: Houd het updatepad

Een ondersteund kanaal blijft belangrijk nadat de installatie klaar is. Herverpakte builds kunnen hun eigen updater meebrengen, en die updater bepaalt wat er volgende maand draait. Een build die nooit wordt bijgewerkt, is niet veiliger. Hij is simpelweg ouder.

Noteer hoe de client hoort te worden bijgewerkt en of een beheersysteem die stap bezit. Als het antwoord een handmatige download van een forum is, is de vraag naar de toeleveringsketen nooit echt gesloten.

Twee herkomsten, niet één

De clientontwikkelaar en de profieluitgever zijn aparte partijen. Een officiële client die een profiel importeert van een onbetrokken operator is een normale regeling, en het profiel verdient zijn eigen onderzoek: wie het heeft uitgegeven, hoe het is geleverd en of het servercertificaat overeenkomt met de naam die je verwacht.

Houd beide herkomsten herkenbaar in je notities. Op het moment dat een client wordt vervangen of een apparaat uit een back-up wordt hersteld, zijn het die twee regels die voorkomen dat een onbekende build of een onbekend profiel met de rest van de gegevens terugkeert.