VPN-installatör från en spegel? Verifiera utgivaren först
Nedladdningskanalen avgör vilken kod som körs och vem som kan uppdatera den. Kontrollera signaturen, källan till kontrollsumman och profilutgivaren först.
Tunneln fungerade, gränssnittet kom upp och sessionen förblev stabil i en vecka. Inget av detta säger dig vem som byggde installationsprogrammet. En VPN-klient körs med tillräckliga privilegier för att skriva om rutter och läsa inloggningsuppgifter, så utgivaren är en del av hotmodellen, inte en fotnot.
Gör kontrollerna i ordning och stanna vid den första som misslyckas. De är billiga, och var och en stänger ett annat hål.
Första steget: Ladda ner från kanalen som projektet anger
Varje projekt dokumenterar var dess utgåvor finns, och den sidan är referensen. Communitybyggen, butikslistningar och leverantörsportaler är alla legitima kanaler. Var och en är legitim bara när projektet självt pekar på den. Det är testet, och det är inte samma sak som att se officiell ut.
En fil som är uppkallad efter projektet bevisar ingenting. Att byta namn på ett installationsprogram är en operation på en sekund, och namnet är det ett sökresultat visar först.
Andra steget: Verifiera signaturen mot en känd identitet
Signaturverifiering svarar bra på en smal fråga. Den säger att en viss identitet har signerat denna binär och att binären inte har ändrats sedan dess. Den svarar på en fråga och vägrar en annan. Den kan inte säga om den identiteten är den du menade att lita 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
Läs identiteten, inte statusordet. En utomstående utvecklare med ett giltigt certifikat producerar en giltig signatur. Ett operativsystem som rapporterar en erkänd utgivare har bara sagt att någon betalade för ett certifikat.
Tredje steget: Jämför hashen med en oberoende källa
En kontrollsumma bevisar överensstämmelse med ett referensvärde. Om referensen kom bredvid nedladdningen kan båda vara fel samtidigt, och jämförelsen går ändå igenom. Det är felmönstret i de flesta guider. Hashen står på samma sida som filen den beskriver.
# 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 ett projekt publicerar signerade kontrollsummor eller ett signerat utgivningsmanifest, verifiera signaturen över listan i stället för över varje fil för sig. På så sätt täcker en betrodd referens hela utgåvan.
Efter installationen: Behåll uppdateringsvägen
En stödd kanal fortsätter att spela roll efter att installationen är klar. Ompaketerade byggen kan bära sin egen uppdaterare, och den uppdateraren avgör vad som körs nästa månad. Ett bygge som aldrig uppdateras är inte säkrare. Det är bara äldre.
Notera hur klienten ska uppdateras och om ett hanteringssystem äger det steget. Om svaret är en manuell nedladdning från ett forum har frågan om leveranskedjan aldrig riktigt stängts.
Två ursprung, inte ett
Klientutvecklaren och profilutgivaren är separata parter. En officiell klient som importerar en profil från en utomstående operatör är ett normalt arrangemang, och profilen förtjänar sin egen granskning: vem som utfärdade den, hur den levererades och om serverns certifikat matchar namnet du förväntar dig.
Håll båda ursprungen identifierbara i dina anteckningar. I det ögonblick en klient byts ut eller en enhet återställs från en säkerhetskopia är det de två raderna som hindrar ett okänt bygge eller en okänd profil från att återvända tillsammans med resten av data.