ミラー配布のVPNインストーラー？まず発行元を確認する

トンネルは動き、インターフェースは立ち上がり、セッションは一週間安定していた。しかし、それだけではインストーラーを誰が作ったかは分からない。VPNクライアントはルートを書き換え、認証情報を読むだけの権限で動作する。だからこそ発行元は脚注ではなく、脅威モデルの一部だ。

チェックは順番に行い、最初に失敗したところで止める。どれも安価で、それぞれが別の隙間を塞ぐ。

第一段階：プロジェクトが示す経路からダウンロードする

各プロジェクトはリリースの置き場所を文書化しており、そのページが基準になる。コミュニティビルド、ストアの掲載、ベンダーのポータルはいずれも正当な経路だ。ただし、プロジェクト自身がそこを指している場合に限り正当だ。それが判定基準であり、公式に見えることとは同じではない。

プロジェクト名を冠したファイルは何も証明しない。インストーラーの名前を変えるのは一秒の作業であり、検索結果が最初に示すのは名前だ。

第二段階：既知の身元に対して署名を検証する

署名の検証は、狭い問いにはよく答える。特定の身元がこのバイナリに署名したこと、そしてそのバイナリがそれ以降変わっていないことを教えてくれる。一つの問いには答え、別の問いには答えない。その身元が本当に信頼したかった相手かどうかは分からない。

# 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

状態の言葉ではなく、身元を読む。有効な証明書を持つ無関係な開発者でも、有効な署名は作れる。認識済みの発行元を報告するOSは、誰かが証明書に料金を払った、と告げているだけだ。

第三段階：ハッシュを独立した情報源と比較する

チェックサムは基準値との一致を証明する。基準値がダウンロードの隣に届いたのなら、両方が同時に間違っていても比較は通る。ほとんどの解説にある失敗の型はこれだ。ハッシュは、それが説明するファイルと同じページに置かれている。

# 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

プロジェクトが署名済みチェックサムや署名済みリリースマニフェストを公開している場合は、各ファイルではなく一覧に対して署名を検証する。そうすれば、一つの信頼できる基準がリリース全体を覆う。

インストール後：更新経路を保つ

サポートされた経路は、インストールが終わった後も重要だ。再パッケージされたビルドは独自の更新プログラムを同梱でき、その更新プログラムが来月何を動かすかを決める。決して更新されないビルドは、より安全ではない。ただ古いだけだ。

クライアントがどう更新されるべきか、その手順を管理システムが担うかを記録する。答えがフォーラムからの手動ダウンロードなら、サプライチェーンの問いは本当には閉じていない。

二つの出自、一つではない

クライアントの開発者とプロファイルの発行者は別の当事者だ。公式クライアントが無関係な事業者のプロファイルを取り込むのは普通の構成であり、プロファイルには独自の確認が要る。誰が発行したか、どう届けられたか、サーバー証明書が期待する名前と一致するかだ。

メモの中に両方の出自を識別できる形で残す。クライアントが交換されたり、端末がバックアップから復元されたりした瞬間、その二行があるからこそ、正体不明のビルドやプロファイルが他のデータと一緒に戻ってこない。