Basic と Digest によるプロキシ認証
クライアントとプロキシの両方が対応する認証方式を選び、Digest チャレンジと暗号化通信を区別します。
Basic や Digest を強制する前に、プロキシの Proxy-Authenticate チャレンジを確認してください。クライアントはサービスが提供する方式に対応している必要があります。Digest を選んでも、Basic 専用のプロキシにその機能が追加されるわけではありません。
Digest 対応のエンドポイントでは、curl で次のように指定できます。
curl --proxy http://proxy.example:3128 --proxy-digest --proxy-user alice --connect-timeout 5 --max-time 15 https://example.com/実際のエンドポイントとアカウントを使います。パスワードを付けずにユーザー名だけを指定すると、curl が入力を求められます。Basic では --proxy-basic を選びます。オリジンサーバーの認証には別のオプションを使います。チャレンジだけでなく、実行する curl ビルドの対応機能も確認してください。
| 方式 | 認証情報の交換 | 評価すべき保護 |
|---|---|---|
| Basic | エンコードされたユーザー名とパスワードの組。 | エンコードは暗号化ではありません。 |
| Digest | チャレンジから生成した応答。 | 保護の程度はアルゴリズム、チャレンジのパラメーター、クライアント実装によって決まります。この方式自体ではリクエストとレスポンスの内容は暗号化されません。 |
どちらにも適切なクライアント・プロキシ間の通信方式が必要です。宛先の HTTPS は始まる時点が遅く、それ以前の平文プロキシログインを保護できません。
サーバー側では、Digest ヘルパーが realm 固有の認証用データと独自の形式を要求する場合があります。Basic の NCSA ファイルが自動的に Digest のバックエンドになるわけではありません。選んだヘルパーの文書に従った形式を使い、送信元と宛先の制限を有効に保ったまま、認証情報なし、誤った認証情報、許可されたリクエストを確認してください。