HTTPSのBasic認証とIPsecの比較：それぞれが守るもの

開発者ツールを開き、社内アプリを読み込み、ページが描画される前に一つのリクエストが四つのチェックポイントを通る様子を観察します。まず名前が解決され、次にTCP接続が開き、次にTLSハンドシェイクがサーバーが誰かを確定し、その後にだけアプリケーションがあなたが誰かを尋ねます。それぞれが異なる証拠で失敗し、それぞれが異なるチームの担当なので、これらは別々の出来事として扱ってください。インシデントでの混乱の多くは、401をトンネルの問題として読むこと、あるいはトンネルの問題を間違ったパスワードとして読むことから生じます。

チェックポイント一：これは本当に話したかったサーバーか

TLSハンドシェイクは、資格情報が送られる前にその問いに答えます。クライアントは証明書チェーンをトラストストアに対して検証し、証明書の名前が入力したホストと一致するか確認します。これが失敗すると、ブラウザは証明書エラーを表示し、Authorizationヘッダーを一切送りません。したがってパスワード入力の促しは、サーバーが本物である証拠ではなく、アプリケーションが応答した証拠です。

ここで最初の境界が現れます。TLSは終端地点までしか接続を守りません。ロードバランサーがTLSを終端し、平文のHTTPをアプリケーションへ転送する場合、暗号化された区間はロードバランサーで終わり、資格情報は最初の区間でしか守られません。

チェックポイント二：401のやり取りで実際に何が運ばれるか

HTTPのBasic認証は、ユーザー識別子とパスワードをBase64で符号化してヘッダーで送ります（仕様はRFC 7617）。Authorization: Basic dXNlcjpwYXNzがその形で、符号化はリクエストを読める人なら誰でも戻せるため、機密性はすべて下のトランスポートから来ます。curl -vはWWW-Authenticate: Basicチャレンジと、返送するヘッダーの両方を表示します。

そのヘッダーはアプリケーションに誰が尋ねているかを伝えます。ネットワークに誰が接続できるかは伝えず、それ自体では何も暗号化しません。アプリケーションは依然として資格情報をストアに対して確認し、そのアカウントが何をしてよいかを決める必要があり、それが認可で、認証の後に行われます。

その経路でIPsecトンネルはどこに位置するか

ここでブラウザから外側へ歩いてみましょう。ゲートウェイ間のIPsecトンネルは、二つのセキュリティゲートウェイ間の選択されたトラフィックを守るのであって、あなたのノートPCとアプリケーションプロセスの間を守るのではありません。トンネルモードのESPは元のパケットを包み、ゲートウェイがそれを暗号化して認証し、内側のアドレスはそのまま残るので、遠端はリクエストをアプリケーションへルーティングできます。

選択の部分が人をつまずかせます。ポリシーベースのトンネルはトラフィックセレクターを使い、しばしばアクセス制御リストとして表現され、どのパケットがトンネルに入るかを決めます。ルートベースのトンネルは代わりに仮想インターフェースとルーティングテーブルを使います。Linuxではip xfrm policyがセレクターを、ip xfrm stateが確立されたセキュリティアソシエーションを示し、ファイアウォール装置では同等のものがトンネルのSAテーブルとパケットトレーサーです。

結果ははっきり述べる価値があります。パケットは完全に健全なトンネルの中にありながら、アプリケーションが拒否するHTTPSリクエストを運ぶことができ、ルーティングが許せば、正しい資格情報がトンネルのない経路で届くこともあります。

報告した層で障害を読む

401はアプリケーションが資格情報を受け入れなかったことを意味します。403は身元を受け入れ、操作を拒否したことを意味します。TLSエラーはクライアントがサーバーを受け入れなかったことを意味します。ルートがない、またはポリシーの不一致は、パケットが遠端のゲートウェイに届かなかったことを意味します。四つの異なる障害、四つの異なる担当者、そしてどれもログインフォームを見つめることでは診断できません。

状態とヘッダーにはブラウザのネットワークパネル、証明書チェーンにはopenssl s_client -connect host:443、トンネルのトラフィックにはゲートウェイのSAカウンターとログ、アカウントの判断にはアプリケーションのログという、各層が生み出す証拠を使ってください。二つの層が同時にエラーを報告するときは、死んだトンネルは認証の失敗を容易に覆い隠し、その逆も起こるので、下の層を先に直してください。

一つのサービスを端から端まで地図にする

調査しているサービスのために、トンネルがどのピアを接続するか、セレクターがどのサブネットとポートを許可するか、TLSがどこで終わり証明書がどの身元を主張するか、どのアプリケーションアカウントとロールが使われるか、各層がどこにログを出すかという五行を書きます。地図の目的は、ある層の責任がどこで終わり次がどこで始まるかを示すことなので、一ページに収めてください。

次に層ごとに一つの否定ケースを試します。間違ったパスワードを使い、タイムアウトではなく401が返ることを確認します。セレクターの外のサブネットから接続し、パケットがトンネルを通らないことを確認します。間違った名前の証明書を提示し、クライアントが資格情報を送る前に拒否することを確認します。この三つの結果は、どんな箱の図よりも設計について多くを教えてくれます。

最後に、各関係にどの保護が必要かを意図的に決めます。TLS上のBasic認証は、ゲートウェイの後ろにある小さな社内ツールには妥当な選択であり、ユーザーごとの認可やTLS終端の先のトラフィック保護の代わりにはなりません。トンネルは経路を、証明書は区間を、401はアカウントを守り、あなたが誰かを知っているのは最後のものだけです。