メインコンテンツまでスキップ

RFC 2818 - TLS 上の HTTP (HTTPS) - 3. エンドポイント識別 (Endpoint Identification)

3. エンドポイント識別 (Endpoint Identification)​

3.1. サーバーアイデンティティ (Server Identity)​

中核要件: クライアントは中間者攻撃を防ぐために、サーバーのアイデンティティを検証しなければならない (MUST)。

アイデンティティ検証プロセス (Identity Verification Process)​

1. クライアントは URI からホスト名を取得
   例: https://www.example.com

2. サーバーは TLS ハンドシェイクで証明書を提供

3. クライアントはホスト名が証明書のアイデンティティと一致するか確認

アイデンティティフィールドの優先順位 (Identity Field Priority)​

優先順位 1: subjectAltName (主体別名)

証明書内の subjectAltName 拡張 (dNSName タイプ):
dNSName: www.example.com
dNSName: api.example.com

← このフィールドを使用しなければならない (MUST) (存在する場合) →

優先順位 2: Common Name (共通名)

証明書の Subject フィールド内の CN:
CN=www.example.com

← subjectAltName がない場合のみ使用 →
← 非推奨、CA は dNSName を使用すべきである →

マッチングルール (Matching Rules)​

1. ワイルドカードマッチング:

証明書: *.example.com
✅ マッチ: foo.example.com
❌ マッチしない: bar.foo.example.com

証明書: f*.com
✅ マッチ: foo.com
❌ マッチしない: bar.com

2. IP アドレス:

URI: https://192.168.1.1/
証明書は以下を含む必要がある: iPAddress subjectAltName
値は正確に一致する必要がある: 192.168.1.1

3. 複数のアイデンティティ:

証明書が複数の dNSName を含む場合:
- www.example.com
- api.example.com
- *.app.example.com

← いずれか 1 つにマッチすれば許容される →

マッチしない場合の動作 (Behavior When No Match)​

ユーザー指向クライアント (ブラウザ):

  • ✅ ユーザーに通知しなければならない (MUST)
  • ⚠️ ユーザーに続行のオプションを提供してもよい (MAY)
  • または接続を終了

自動化クライアント (API クライアント):

  • ✅ 監査ログにエラーを記録しなければならない (MUST)
  • ✅ 接続を終了すべきである (SHOULD)
  • ⚠️ チェックを無効にする設定オプションを提供してもよい (MAY)

セキュリティ警告 (Security Warning)​

信頼できない URI ソース:

攻撃シナリオ:
1. ユーザーが HTTP ページ内のリンクをクリック
2. HTTP ページ自体は暗号化されていない
3. 中間者が URI を置き換えた可能性がある

防御:
ユーザーはサーバー証明書を注意深く確認すべきである

3.2. クライアントアイデンティティ (Client Identity)​

通常の場合: サーバーはクライアントのアイデンティティに関する外部知識を持ちません。

サーバーが外部知識を持つ場合 (HTTP または TLS 外から):

  • 上記のようにアイデンティティを確認すべきである

クライアント証明書認証:

一般的なシナリオ:
- 企業内部システム
- API アクセス制御
- 相互 TLS (mTLS)

検証:
- 適切な CA にルート化された証明書チェーン
- オプション: 特定のクライアントアイデンティティを検証