はじめに
の記事でAuthenticated Origin Pulls (mTLS)の設定をしていた時にふと以下のようなことを思った。
- クライアント証明書を送ってもらってオリジンサーバで検証するというが、このクライアント証明書を使ってなりすましできるのでは？
- サーバ証明書も同じで、証明書を送ってもらうのだからその証明を別のサーバにおいて、それを送ればなりすましできるのでは？
上記の懸念は全く不要で、証明書だけあっても意味ないことが分かったが、今回はなぜ問題ないのか？について、自身の備忘録の意味で書いていきたいと思う。
TLSハンドシェイクの詳細な流れというよりは、上記の懸念は無用という事がわかるレベルで書いています
TLSハンドシェイクの流れを理解してなりすましできない理由を理解する
サーバ証明書だけあっても意味ない理由
ずばり、共通鍵を作るためのデータ（プレマスターシークレット）を秘密鍵を持っていないと復号できないから、という事になる。
TLSハンドシェイクの流れを見ていき、どこでサーバ証明書を悪用したなりすましの防止をしているか？を見ていく。まず、TLSハンドシェイクの大まかな流れは以下のようになっている。
SSL/TLSの暗号化は共通鍵方式で、その共通鍵を生成するためにプレマスターシークレットと呼ばれるデータを交換する。このプレマスターシークレットは公開鍵暗号方式で暗号化して安全にやり取りされる。
ここで、サーバ証明書（サーバの公開鍵）を攻撃者が手に入れても、暗号化されたプレマスターシークレットを復号できない。この復号できない、という制限があるからこそ、サーバ証明書があってもなりすましできない理由。
クライアント証明書だけあっても意味ない理由
ずばり、クライアント証明書の検証のための署名データを作成できないから、という事になる。
サーバ証明書の部分でみたハンドシェイクの流れの中に、クライアント証明書の検証を書き加えると、以下のような感じになる。サーバ証明書を渡すのと同時に、クライアントあなたの証明書も頂戴というリクエストを送る。
クライアント証明書を要求されたクライアントは、クライアント証明書と証明書の検証のためのデジタル署名データをサーバに送信する。デジタル署名は秘密鍵で作成し、公開鍵で検証できるもの。
つまり、クライアント証明書（クライアントの公開鍵）を攻撃者が手に入れても、クライアント証明書を検証するための署名データを作成することができない。署名データを作成できない、という制限があることで、クライアント証明書があってもなりすましはできない。
まとめとして
頭のいい人が考えることはすごいな～と思った。よくできているというのが素直な感想。
まあクレジットカードの情報とかをやり取りできるのもSSL/TLSのおかげなので、その意味を改めて考えれば「はじめに」に書いたような懸念があるはずないか、と思った。