既知のエンドポイントに対する事前 Basic プロキシ認証

チャレンジを待つクライアントは、プロキシが要求するのを待ちます。事前 Basic クライアントは選択済みのエンドポイントをすでに知っており、最初の該当リクエストで資格情報を送ります。このやり取りを省くと便利な場合があります。それでも、パスワードがどこへ行くかという判断であることに変わりはありません。

最適化の前にエンドポイントを知る

認証ポリシーが既知の固定プライベートプロキシは、未知の中間装置を選ぶ可能性のあるルーティング層より明確なケースです。アカウントを想定するプロキシの識別情報とプロトコルに結び付けます。すべてのチャレンジに 1 つの社内パスワードで応答する汎用コールバックを作らないでください。

Basic は暗号化された証明ではなく、アカウントの base64 表現を運びます。プロキシのリスナーまでの TLS は、サイトの HTTPS セッションとは別の接続選択です。サイトの HTTPS トンネルは、暗号化されていないクライアントからプロキシへの接続で送られた Basic 資格情報を遡って保護することはありません。プライベート LAN は場所であり、暗号化の性質ではありません。

仕組みを限定して保つ

事前 Basic は Digest、NTLM、Negotiate の万能な近道ではありません。これらの仕組みには独自のやり取り要件があります。対応スキームを発見したクライアントが追加のトランザクションを行うことは正当です。

選択したライブラリのプロキシ認証インターフェースを使い、そのうえで実際のスキームとスコープを確認します。宛先の事前認証の設定がプロキシのハンドシェイクを制御しない場合があります。既存の認証済み接続があると、新しい接続でチャレンジが行われるかどうかも隠れます。

操作全体を比較します。やり取りの回数、完了時間、必要なトランスポート保護、プロキシが変わったときの挙動です。ログがきれいになることが役立つのは、アプリケーションが今も想定した中間装置に対して認証し、その取り決めを確立できないときに停止する場合だけです。