【テクニカル・上級編】HTTP/1.1の認証ヘッダー(Authorization: Basic/Digest) – HTTPプロトコル・通信規格実践ガイド

HTTP認証の「裸の王様」と「盾」：BasicとDigestが教えるプロトコルの美学

インフラエンジニアの端くれなら、一度は目にする `Authorization` ヘッダー。だが、これが単なる文字列の羅列だと思っているなら、ネットワークスペシャリストとしては失格だ。HTTP/1.1という、現代のWebの基礎を作り上げた古強者のプロトコルにおいて、認証という「信頼の橋渡し」がどのようにパケットレベルで構築されているのか。その深淵を覗いてみよう。

1. Basic認証：Base64という名の「裸」を理解する

Basic認証を「セキュリティ機能」と呼ぶのは、もはやジョークに近い。`Authorization: Basic ` の `` 部分は、`username:password` を単にBase64でエンコードしているに過ぎない。

Base64は暗号化ではない。ただの符号化だ。
echo -n “admin:password” | base64
YWRtaW46cGFzc3dvcmQ=
Authorization: Basic YWRtaW46cGFzc3dvcmQ=

なぜこれがダメなのか。パケットキャプチャを一度でも取れば明白だ。TCPストリームを再構成し、ペイロードを覗けば、認証情報は丸裸である。TLSを強制しないHTTP/1.1環境下では、中間者攻撃（MitM）に対して無防備そのものだ。

しかし、「TLSによるトランスポート層の保護」を前提とするならば、話は変わる。現代のアーキテクチャにおいて、Basic認証は「TLSという強固なトンネル」の中に閉じ込めることで、初めて実用に耐える存在となる。

2. Digest認証：ハッシュで語る「秘密の証明」

Digest認証は、HTTP/1.1が提示した「パスワードをネットワークに流さない」という極めて合理的な回答だ。ここには、チャレンジ・レスポンス方式という、現代の認証プロトコルの原型がある。

Digest認証のフローはこうだ。
1. Challenge: サーバーは `401 Unauthorized` と共に `nonce`（使い捨ての乱数）を返す。
2. Response: クライアントは `MD5(パスワード + nonce + …)` を計算し、ハッシュ値のみを送信する。

これにより、たとえパケットを盗聴されても、攻撃者が得られるのは「ある時点のnonceに基づいたハッシュ」のみであり、元のパスワードを直接復元することは不可能に近い。

アーキテクトが懸念すべきMD5の脆弱性

ここで一つ釘を刺しておこう。Digest認証の仕様（RFC 7616）はMD5をデフォルトとして設計されている。しかし、MD5は衝突耐性が崩壊しており、現代のセキュリティ要件としては極めて脆弱だ。もし可能であれば、`algorithm=SHA-256` を選択できる環境を構築すべきだ。

3. パフォーマンスの真髄：RTT削減とTCPチューニング

認証のオーバーヘッドは、往々にして「RTT（Round Trip Time）」の増加に直結する。特にDigest認証のようなチャレンジ・レスポンス方式は、認証完了までに最低でも2回のRTTを消費する。

この遅延を最小化するために、インフラ側で取り組むべきは以下のチューニングだ。

TCP Fast Open (TFO):

TLSハンドシェイクとHTTPリクエストを最初のTCPパケットで同時に送ることで、1RTTを削減する。

# Linuxカーネルパラメータでの有効化
sysctl -w net.ipv4.tcp_fastopen=3

TLS Session Resumption (Session IDs / Tickets):

認証が必要なセッションにおいて、毎回TLSハンドシェイクからやり直すのは愚策だ。セッション再開を有効にし、クライアントが過去の握手を再利用できるように設定せよ。

ヘッダー圧縮の意識:

HTTP/1.1ではヘッダーの圧縮が効かないため、Authorizationヘッダーが長いとMTUを圧迫する可能性がある。不必要な冗長ヘッダーを避け、キープアライブ（`Connection: keep-alive`）でTCPコネクションを温存し、認証済みのコネクションを使い回すことが、UXを劇的に改善する。

4. まとめ：プロトコル設計者に求められる「防御的思考」

Basic認証やDigest認証は、Webの歴史における「古典」だ。しかし、これらを現代のインフラに実装する際、我々が守るべき原則は変わらない。

1. Transport層を信じるな: HTTP層の認証だけに頼らず、必ず信頼できるTLS（できればTLS 1.3）でカプセル化すること。
2. ハッシュの強度を見極める: 古いDigest認証をそのまま使うのではなく、SHA-256等の強固なハッシュアルゴリズムへの移行を検討すること。
3. パケットの「重さ」を理解する: 認証フローによるRTTの増加を、TCP Fast Openやコネクションプーリングで相殺する。

ネットワークは生き物だ。コマンドを叩くだけでは見えないパケットの挙動を想像し、プロトコルの裏側にある意図を理解する。それこそが、真のインフラアーキテクトが持つべき「視点」なのだ。

次回の記事では、HTTP/2以降で標準化された認証のあり方と、現代のAPIゲートウェイにおける認証オフロードについて深掘りしていこう。現場からは以上だ。