VPN-installeerder van 'n spieël? Verifieer eers die uitgewer

Die aflaairigting bepaal watter kode loop en wie dit kan opdateer. Kontroleer eers die handtekening, die bron van die kontrolesom en wie die profiel uitgereik het.

Die tonnel het gewerk, die koppelvlak het opgekom en die sessie het 'n week lank stabiel gebly. Niks daarvan sê vir jou wie die installeerder gebou het nie. 'n VPN-kliënt loop met genoeg voorreg om roetes te herskryf en geloofsbriewe te lees, so die uitgewer is deel van die bedreigingsmodel, nie 'n voetnoot nie.

Werk die kontroles in volgorde deur en stop by die eerste een wat misluk. Hulle is goedkoop, en elkeen sluit 'n ander gaping.

Stap een: Laai af uit die kanaal wat die projek noem

Elke projek dokumenteer waar sy uitgawes woon, en daardie bladsy is die verwysing. Gemeenskapsboue, winkelinskrywings en verskaffersportale is almal wettige kanale. Elkeen is slegs wettig wanneer die projek self daarna wys. Dit is die toets, en dit is nie dieselfde as om amptelik te lyk nie.

'n Lêer wat na die projek vernoem is, bewys niks. Om 'n installeerder te hernoem is 'n een-sekonde-operasie, en die naam is wat 'n soekresultaat eerste wys.

Stap twee: Verifieer die handtekening teen 'n bekende identiteit

Handtekeningverifikasie beantwoord 'n nou vraag goed. Dit sê vir jou dat 'n bepaalde identiteit hierdie program onderteken het en dat die program sedertdien nie verander het nie. Dit beantwoord een vraag en weier 'n ander. Dit kan nie vir jou sê of daardie identiteit die een is wat jy bedoel het om te vertrou nie.

# 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 die identiteit, nie die statuswoord nie. 'n Onverwante ontwikkelaar met 'n geldige sertifikaat lewer 'n geldige handtekening. 'n Bedryfstelsel wat 'n erkende uitgewer rapporteer, het jou net gesê dat iemand vir 'n sertifikaat betaal het.

Stap drie: Vergelyk die hash met 'n onafhanklike bron

'n Kontrolesom bewys ooreenstemming met 'n verwysingswaarde. As die verwysing saam met die aflaai aangekom het, kan albei saam verkeerd wees en die vergelyking slaag steeds. Dit is die foutmodus in die meeste handleidings. Die hash staan op dieselfde bladsy as die lêer wat dit beskryf.

# 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

Waar 'n projek ondertekende kontrolesomme of 'n ondertekende uitgawe-manifes publiseer, verifieer die handtekening oor die lys eerder as elke lêer afsonderlik. So dek een vertroude verwysing die hele uitgawe.

Na installasie: Hou die opdateringspad

'n Ondersteunde kanaal bly saak maak nadat die installasie klaar is. Herverpakte boue kan hul eie opdaterer saamdra, en daardie opdaterer besluit wat volgende maand loop. 'n Bou wat nooit opdateer nie, is nie veiliger nie. Dit is bloot ouer.

Teken aan hoe die kliënt veronderstel is om op te dateer en of 'n bestuurstelsel daardie stap besit. As die antwoord 'n handmatige aflaai van 'n forum is, het die vraag oor die voorsieningsketting nooit regtig gesluit nie.

Twee oorspronge, nie een nie

Die kliëntontwikkelaar en die profieluitreiker is aparte partye. 'n Amptelike kliënt wat 'n profiel van 'n onverwante operateur invoer, is 'n normale reëling, en die profiel verdien sy eie ondersoek: wie dit uitgereik het, hoe dit afgelewer is, en of die sertifikaat van die bediener ooreenstem met die naam wat jy verwag.

Hou albei oorspronge identifiseerbaar in jou notas. Die oomblik wanneer 'n kliënt vervang word of 'n toestel uit rugsteun herstel word, is daardie twee reëls wat keer dat 'n onbekende bou of 'n onbekende profiel saam met die res van die data terugkeer.

Verwante artikels