カスタムVPN証明書は暗号化層を増やすものではない

VPNエンドポイントにカスタム証明書を入れると保護が増えたように感じるのは、証明書と暗号化がどこでも一緒に現れるからだ。実際に変わるのは二つである。エンドポイントが示す身元と、その相手が信頼しようとする発行者だ。どちらもデータをもう一度包み直すわけではない。本当に必要なのが二本目の保護された経路なら、必要になるのは独自のエンドポイントを持つ二本目の経路であり、もう一枚の証明書ではない。

TLS 1.3ハンドシェイクにおける三つの別個の仕事

RFC 8446 はこれらを分けており、その分離こそが答えのすべてである。Certificateメッセージはエンドポイントの証明書チェーンを運ぶ。CertificateVerifyは対応する秘密鍵の所持を証明し、ハンドシェイクの記録に結び付ける。レコード層は交渉されたトラフィック鍵で通信を保護する。

証明書を入れ替えれば、最初の二項目が変わる。レコードの保護が二重に走ることはなく、発行者が私的なものになったからといって強くもならない。

プライベートCAが実際に買うもの

買うのは統制された身元の仕組みである。誰に発行するかを自分で決め、どの発行者を相手が受け入れるかを自分で決め、自らの予定で失効させられる。両端を自分で運用するなら、これは確かに役に立つ。

ただし義務も持ち込む。信頼は意図的に配布しなければならず、相手の検証は有効なままにしておかなければならず、資格情報のライフサイクルは誰かが所有しなければならない。プライベートCAは、この三つのどれも回避する近道ではない。

二本目の経路が正解となる場合

あるアプリケーションが自分のサービスへ検証済みのHTTPSを開き、そのパケットがVPNも通るとしよう。その設計には境界が二つあり、それぞれのエンドポイントは異なりうる。二本目の保護された経路とはそういうものだ。

この区別はゲートウェイで効いてくる。アプリケーションのTLSセッションがアプリケーションではなくVPNゲートウェイで終わるなら、トンネルの先にも保護があると考えていたものはそこにない。その性質を主張する前に、どの経路を誰が終わらせるのかを書き出しておく。

インストールが何を変えるのかを問う

証明書を入れたいという要求は、三つの異なる意味を持ちうる。クライアント自身の身元を変えるのか、アプリケーション固有の信頼の基点を変えるのか、それとも 端末上のすべてに対するプラットフォーム全体の信頼 を変えるのか。これらは等価ではなく、無関係なソフトウェアに影響するのは最後の一つだけである。

三つのどれを意図しているのかを尋ね、次にそれが何を達成するはずなのかを尋ねる。答えが「より多くの暗号化」なら、提案は誤った仕組みに向いている。

境界を書き出す

経路ごとに、エンドポイント、双方が検証する身元、途中の運用者に見えるものを記録する。次に失敗時の振る舞いを記録する。検証が失敗したときに何が起きるのか、経路が拒否されたときに何が起きるのか。

一枚の紙に二行あれば、証明書の更新では決着できない論争がたいてい片付く。

三つの質問で決める

問題はエンドポイントが誰だと名乗るかだろうか、それともデータに何が起きるかだろうか。保護はVPNゲートウェイの先の特定のアプリケーションまで続く必要があるだろうか。そして二本目の経路を終わらせる二つのエンドポイントを名指しできるだろうか。

最初の問いが本当なら、身元と信頼を直す。二番目か三番目なら、二本目の経路を設計し、証明書はあるべき場所に置いておく。