VPN-installasjon frå ein spegel? Stadfest utgjevaren først
Nedlastingskanalen avgjer kva kode som køyrer, og kven som kan oppdatera han. Kontroller signaturen, kjelda til kontrollsummen og profilutgivaren først.
Tunnelen fungerte, grensesnittet kom opp, og økta heldt seg stabil i ei veke. Ingenting av dette fortel deg kven som bygde installasjonsprogrammet. Ein VPN-klient køyrer med nok rettar til å skriva om ruter og lesa påloggingsopplysningar, så utgjevaren er ein del av trusselmodellen, ikkje ei fotnote.
Gjer kontrollane i rekkjefølgje, og stopp ved den første som feilar. Dei er billege, og kvar av dei lukkar eit ulikt hol.
Første steg: Last ned frå kanalen prosjektet nemner
Kvart prosjekt dokumenterer kvar utgjevingane ligg, og den sida er referansen. Fellesskapsbygg, butikkoppføringar og leverandørportalar er alle legitime kanalar. Kvar av dei er berre legitim når prosjektet sjølv peikar på han. Det er testen, og han er ikkje det same som å sjå offisiell ut.
Ei fil som er kalla opp etter prosjektet, beviser ingenting. Å gje installasjonsprogrammet nytt namn er ein operasjon på eitt sekund, og namnet er det eit søkjeresultat viser først.
Andre steg: Stadfest signaturen mot ein kjend identitet
Signaturstadfesting svarar godt på eit smalt spørsmål. Ho fortel deg at ein bestemd identitet har signert denne binærfila, og at fila ikkje har endra seg sidan. Ho svarar på eitt spørsmål og avviser eit anna. Ho kan ikkje fortelja deg om den identiteten er den du meinte å stola på.
# 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
Les identiteten, ikkje statusordet. Ein utanforståande utviklar med eit gyldig sertifikat produserer ein gyldig signatur. Eit operativsystem som rapporterer ein anerkjend utgjevar, har berre fortalt deg at nokon betalte for eit sertifikat.
Tredje steg: Samanlikn hashen med ein uavhengig kjelde
Ein kontrollsum beviser samsvar med ein referanseverdi. Viss referansen kom saman med nedlastinga, kan begge vera feil samstundes, og samanlikninga held likevel. Det er feilmønsteret i dei fleste rettleiingane. Hashen står på same sida som fila han skildrar.
# 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
Når eit prosjekt publiserer signerte kontrollsummar eller eit signert utgjevingsmanifest, stadfest signaturen over lista i staden for over kvar fil for seg. Slik dekkjer éin tiltruleg referanse heile utgjevinga.
Etter installasjonen: Hald oppdateringsvegen
Ein støtta kanal held fram med å bety noko etter at installasjonen er ferdig. Ompakka bygg kan ha sin eigen oppdaterar, og den oppdateraren avgjer kva som køyrer neste månad. Eit bygg som aldri vert oppdatert, er ikkje tryggare. Det er berre eldre.
Noter korleis klienten skal oppdaterast, og om eit styringssystem eig det steget. Viss svaret er ei manuell nedlasting frå eit forum, har spørsmålet om forsyningskjeda aldri egentleg blitt lukka.
To opphav, ikkje eitt
Klientutviklaren og profilutgivaren er separate partar. Ein offisiell klient som importerer ein profil frå ein utanforståande operatør, er ei normal ordning, og profilen fortener si eiga gransking: kven som gav han ut, korleis han vart levert, og om sertifikatet til tenaren samsvarar med namnet du ventar.
Hald begge opphava identifiserbare i notata dine. I det augneblinken ein klient vert erstatta eller eining vert gjenoppretta frå sikkerheitskopi, er det dei to linjene som hindrar eit ukjent bygg eller ein ukjend profil i å koma tilbake saman med resten av dataa.