VPN-ynstallearder fan in spegel? Kontrolearje earst de útjouwer

De tunnel wurke, de ynterface kaam omheech en de sesje bleau in wike stabyl. Nimmen fan dy dingen fertelt dy wa't de ynstallearder boud hat. In VPN-klant rint mei genôch privileezjes om rûtes oer te skriuwen en oanmeldgegevens te lêzen, dus de útjouwer is part fan it bedrigingsmodel, net in fuotnoat.

Wurkje de kontrôles op folchoarder ôf en stop by de earste dy't mislearret. Se binne goedkeap, en elk slút in oare gat.

Stap ien: Download fan it kanaal dat it projekt neamt

Elk projekt dokumintearret wêr't syn útjeften steane, en dy side is de referinsje. Mienskipsbuilds, winkelfermeldings en leveransiersportalen binne allegear legitime kanalen. Elk is allinnich legitime as it projekt sels dernei wiist. Dat is de test, en it is net itselde as offisjeel lykje.

In bestân neamd nei it projekt bewiist neat. In ynstallearder omneame is in operaasje fan ien sekonde, en de namme is wat in sykresultaat earst sjen lit.

Stap twa: Kontrolearje de handtekening tsjin in bekende identiteit

Handtekeningferifikaasje beantwurdet in smelle fraach goed. It fertelt dy dat in beskate identiteit dit binêre bestân ûndertekene hat en dat it bestân sûnt net feroare is. It beantwurdet ien fraach en wegeret in oare. It kin dy net fertelle oft dy identiteit dejinge is dy'tst fertrouwe woe.

# 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 de identiteit, net it statuswurd. In net besibbe ûntwikkelder mei in jildich sertifikaat produsearret in jildige handtekening. In bestjoeringssysteem dat in erkende útjouwer meldt, hat dy allinnich ferteld dat immen foar in sertifikaat betelle hat.

Stap trije: Ferlykje de hash mei in ûnôfhinklike boarne

In kontrôlesom bewiist oerienkomst mei in referinsjewearde. As de referinsje njonken de download oankaam, kinne beide tegearre ferkeard wêze en de ferliking slagget noch. Dat is de faalmodus yn 'e measte tutorials. De hash stiet op deselde side as it bestân dat er beskriuwt.

# 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

Wannear't in projekt ûndertekene kontrôlesommen of in ûndertekene útjefte-manifest publisearret, ferifisearje dan de handtekening oer de list ynstee fan oer elk bestân apart. Sa dekt ien fertroude referinsje de hiele útjefte.

Nei de ynstallaasje: Hâld it bywurkingspaad

In stipe kanaal bliuwt fan belang nei't de ynstallaasje klear is. Werpakke builds kinne har eigen bywurker drage, en dy bywurker beslút wat folgjende moanne rint. In build dy't nea bywurke wurdt is net feiliger. Hy is gewoan âlder.

Skriuw op hoe't de klant bywurke wurde moat en oft in behearssysteem dy stap hat. As it antwurd in hânmjittige download fan in foarum is, is de fraach fan 'e leveringsketen nea echt sletten.

Twa oarsprongen, net ien

De klantûntwikkelder en de profylútjower binne aparte partijen. In offisjele klant dy't in profyl ymportearret fan in net besibbe operator is in normale regeling, en it profyl fertsjinnet syn eigen ûndersyk: wa't it útjûn hat, hoe't it levere is en oft it server-sertifikaat oerienkomt mei de namme dy'tst ferwachtet.

Hâld beide oarsprongen werkenber yn dyn notysjes. It momint dat in klant ferfongen wurdt of in apparaat fan in reservekopie werombrocht wurdt, binne it dy twa rigels dy't foarkomme dat in ûnbekende build of in ûnbekend profyl mei de rest fan 'e gegevens weromkomt.