HTTPSプロキシはTLS接続が二つ、一つではない

HTTPSプロキシという呼び名は、クライアントとプロキシのあいだの転送だけを指し、それ以上は何も語りません。その背後にあるウェブサイトが同じ接続で暗号化されているとも、プロキシがページを読めるとも言っていません。二つの接続を切り離して考えれば、証明書のエラーは謎ではなくなり、VPNとの比較も具体的になります。

二組の端点、二つの検証

通常のトンネルモードには二つのTLS関係があります。一つ目はクライアントからプロキシへ向かい、プロキシを認証します。二つ目はクライアントからトンネル内のウェブサイトへ向かい、ウェブサイトを認証します。両者は独立に失敗し、独立に設定されます。

両者は別々の信頼判断、別々の証明書チェーン、別々の失敗メッセージを持っています。組織のCAを使うプロキシと公開チェーンを使う公開ウェブサイトが、正当に異なる検証設定を必要とすることはあり、それは設定ミスではありません。

実際にそうなのですから、たまたま同じソケットを共有している二つの接続として扱ってください。

CONNECTが実際にトンネルするもの

クライアントはホストとポートを指定したCONNECTリクエストを送り、プロキシはその宛先へのTCP接続を開きます。プロキシが応答したあと、続くバイトは解釈されずに中継されるため、ウェブサイトのTLSハンドシェイクはそのままプロキシを通ります。こうしてプロキシは宛先の名前と接続のメタデータを知りますが、この仕組みから復号されたページを受け取ることはありません。

この区別がトンネルモードのセキュリティ論拠のすべてであり、同時にその限界でもあります。

プロキシホップにTLSがないHTTPプロキシでも、CONNECTを通じてHTTPSのウェブサイトを運びます。クライアントとプロキシのあいだのやり取りは平文ですが、ウェブサイトへの接続はそうではなく、全体をHTTPSプロキシと呼ぶとこの違いが隠れます。

どの証明書が失敗したのか

検証が失敗したら、信頼設定を変える前にエラーに示された端点を読んでください。二つの失敗は端末では似て見え、まったく異なる修正を指し示すので、最初の問いは常にどちらの接続が拒否したのかです。

curlがオプションを分けているのはまさにこの理由です。プロキシのCAファイルはプロキシの検証を設定し、CAファイルはサーバーの検証を設定しますが、適用される信頼ストアの挙動はcurlがどうビルドされたかにも依存します。

curl -v --proxy https://proxy.example.net:443 \
  --proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/

検査を抑え込むことは修理ではありません。どちらの端点についても何も証明しません。

検査は別の仕組みです

TLS検査はトンネルではありません。検査する中間者はウェブサイトへの信頼関係を終端し、自分自身の証明書をクライアントに提示するため、クライアントはサイトではなく中間者を検証します。これは承認された設計のもとでは正当であり得ますが、バイト単位の中継とは本質的に異なる主張です。すべてのプロキシが検査すると決めつけず、暗号化されたプロキシホップがそれを排除すると決めつけないでください。

信頼ストアにある組織のCAは、どの仕組みにいるかの手がかりであって証拠ではありません。証明書チェーンから推測するのではなく、設計を尋ねてください。

この二つの仕組みは、誰がページを読めるかという問いに異なる答えを出します。

同じ四行でプロキシとVPNを比較する

両方の配備を同じ方法で説明してはじめて、比較は役に立ちます。

一つのリクエスト向けに設定されたプロキシは、そのリクエストだけを対象にします。端末のすべてのプロセスを通過させるわけではなく、例のコマンドもまさにそれだけ狭いものです。VPNの範囲はそのルーティングとアプリケーションポリシーに依存し、これらも推測ではなく確認が必要です。インストールしたという理由だけで、どちらの選択肢もすべてを対象にはしません。

各選択肢について四行を書き出せば、議論はたいてい自然に決着します。有用な比較は、どちらのラベルがより暗号化されて聞こえるかではありません。どの区間が保護され、その両端で誰が検証され、どの中間者を信頼し、ポリシーが実際にどの通信を含むのか、です。