Un installateur VPN depuis un miroir ? Vérifiez d'abord l'éditeur
Le canal de téléchargement décide quel code s'exécute et qui peut le mettre à jour. Vérifiez d'abord la signature, la source de la somme de contrôle et l'émetteur du profil.
Le tunnel fonctionnait, l'interface est apparue et la session est restée stable pendant une semaine. Rien de tout cela ne vous dit qui a construit l'installateur. Un client VPN s'exécute avec assez de privilèges pour réécrire des routes et lire des identifiants, donc l'éditeur fait partie du modèle de menace, pas d'une note de bas de page.
Faites les vérifications dans l'ordre et arrêtez-vous à la première qui échoue. Elles sont peu coûteuses, et chacune comble une lacune différente.
Première étape : Téléchargez depuis le canal que le projet nomme
Chaque projet documente où vivent ses versions, et cette page fait référence. Les builds communautaires, les fiches de boutique et les portails de fournisseurs sont tous des canaux légitimes. Chacun n'est légitime que lorsque le projet lui-même le désigne. C'est le test, et ce n'est pas la même chose que de paraître officiel.
Un fichier portant le nom du projet ne prouve rien. Renommer un installateur est une opération d'une seconde, et le nom est ce qu'un résultat de recherche affiche en premier.
Deuxième étape : Vérifiez la signature par rapport à une identité connue
La vérification de signature répond bien à une question étroite. Elle vous dit qu'une identité particulière a signé ce binaire et que le binaire n'a pas changé depuis. Elle répond à une question et en refuse une autre. Elle ne peut pas vous dire si cette identité est celle à laquelle vous vouliez faire confiance.
# 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
Lisez l'identité, pas le mot d'état. Un développeur sans rapport avec un certificat valide produit une signature valide. Un système d'exploitation qui signale un éditeur reconnu ne vous a dit qu'une chose : quelqu'un a payé pour un certificat.
Troisième étape : Comparez le hachage à une source indépendante
Une somme de contrôle prouve la concordance avec une valeur de référence. Si la référence est arrivée à côté du téléchargement, les deux peuvent être fausses ensemble et la comparaison passe quand même. C'est le mode de défaillance de la plupart des tutoriels. Le hachage se trouve sur la même page que le fichier qu'il décrit.
# 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
Lorsqu'un projet publie des sommes de contrôle signées ou un manifeste de version signé, vérifiez la signature sur la liste plutôt que sur chaque fichier séparément. Ainsi, une référence de confiance couvre toute la version.
Après l'installation : Conservez le chemin de mise à jour
Un canal pris en charge continue de compter après la fin de l'installation. Les builds reconditionnés peuvent embarquer leur propre outil de mise à jour, et cet outil décide de ce qui s'exécutera le mois prochain. Un build qui ne se met jamais à jour n'est pas plus sûr. Il est simplement plus ancien.
Notez comment le client est censé se mettre à jour et si un système de gestion prend en charge cette étape. Si la réponse est un téléchargement manuel depuis un forum, la question de la chaîne d'approvisionnement n'a jamais vraiment été close.
Deux origines, pas une
Le développeur du client et l'émetteur du profil sont des parties distinctes. Un client officiel qui importe un profil d'un opérateur sans rapport est un arrangement normal, et le profil mérite son propre examen : qui l'a émis, comment il a été livré et si le certificat du serveur correspond au nom que vous attendez.
Gardez les deux origines identifiables dans vos notes. Au moment où un client est remplacé ou où un appareil est restauré depuis une sauvegarde, ce sont ces deux lignes qui empêchent un build inconnu ou un profil inconnu de revenir avec le reste des données.