TLS鍵共有とクライアント証明書：ログインするのはどちらか

ハンドシェイクで公開鍵交換の値を持ち運ぶことと、クライアントがログインすることは同じ出来事ではありません。前者は接続の暗号学的状態を確立し、後者はクライアントが誰かを示しますが、それはサーバーが要求し、交換が支える場合にのみ起こります。前者を後者と取り違えると、VPNが何を隠し何を隠さないかについて誤った結論に至ります。メッセージを読み、そのうえで四つの性質のうち実際に観察したものを判断してください。

キャプチャで似て見える二つの対象

TLS 1.3のクライアントは、証明書を一切提示せずに最初のフライトで鍵交換の材料を提供できます。その提供は、サーバーが共有秘密を導出するのに必要となるため、設計上公開されています。クライアント証明書は別のメッセージであり、サーバーが要求した後にだけ送られます。それはサーバーが後に検証する識別情報を運び、相互認証は暗号スイートが含意する性質ではなくサーバーが下す判断です。アプリケーション識別はまったく別の第三のもので、ログインフォーム、ベアラートークン、クッキーなどです。それらはいずれもハンドシェイクに現れず、いずれもネットワーク経路の変化を生き延びます。

四つの行は独立しています。接続が一行目と二行目を持ち、三行目を飛ばしても、四行目をクッキーヘッダーで運ぶことはできます。

捕捉したハンドシェイクが証明できることを決める

ハンドシェイクだけから、観察者は交渉されたバージョン、暗号スイート、サーバーの証明書、公開鍵交換の値を知ります。それだけでクライアント実装の指紋を取り、どのサーバーに接続したかを見るのに足ります。与えないのは接続を復号するのに必要な秘密状態であり、その秘匿性は公開された共有部分ではなく一時的な交換に支えられています。また、そもそもハンドシェイクに存在しなかったアカウント識別も与えません。

したがって正直な結論は狭いもので、この交換ではクライアント証明書は提示されていません。クライアントが結び付けられるものを何も送らなかったという話でも、セッションが識別子を一切持たなかったという話でもありません。

暗号名ではなくメッセージを読む

暗号スイートから推測するのではなく、サーバーが何を要求するかを尋ねてください。証明書要求を含むTLS 1.3のハンドシェイクは記録に現れ、その不在も同じように現れます。

openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'

次にクライアント証明書を設定して繰り返し、比較します。二回目の実行では証明書が送られ受け入れられるはずで、一回目には何も現れないはずであり、それが議論の具体的な違いです。

openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet

通常の閲覧の場合だけが必要なら、クライアントの詳細出力でプロトコルのバージョン、検証結果、クライアント証明書が提示されたかどうかを見るのに十分です。証明書要求を一度も送らないサーバーは、それを受け取っていようがありません。

再開が答えを変える箇所

TLS 1.3の再開は秘密状態に結び付いたチケットを使うため、後の接続は完全な証明書交換なしに完了できます。それは観察者の見るものを減らし、記録が証明するものを変えます。存在しなかった識別を新たに作るわけではありません。再開されたセッションは同じアプリケーションセッションに属したままで、そのセッションのクッキーやトークンが重要な識別子であり続けます。

だからこそ「クライアント証明書がない」で止まるプライバシー確認は面白い部分を取り逃します。問うべきはどちらの当事者が安定した識別子を持つかであり、一回のハンドシェイクからどのメッセージが欠けていたかではありません。

判定一つではなく四つの性質を記録する

鍵合意、サーバー検証、クライアント認証、アプリケーション識別を四つの別々の行として、それぞれの根拠とともに書き留めてください。その一覧はプロトコルのバージョンが変わっても生き残り、プライバシーに関する主張を他人が検証できるものにします。次にネットワーク経路の寄与を加えます。VPNはサービスが見る送信元アドレスを変えますが、アプリケーションがすでに持つログイン、クッキー、端末の指紋を消すものではありません。

接続の交渉済みバージョンと証明書要求の結果を、第三者が自分のキャプチャなしにあなたの結論を再現するのに必要な対だから、一緒に記録してください。