PR

SSL/TLSダウングレード攻撃について

本記事は学習用です。作成には ChatGPT と GitHub Copilot を使用しています。

1. 概要（定義と要点）

ダウングレード攻撃（downgrade attack）とは、通信の当事者（クライアントとサーバ）がより安全なプロトコル／暗号スイートで接続できるにもかかわらず、中間者（Man-in-the-Middle; MITM）が介在し、通信を「より古く・弱い」プロトコルや暗号に強制的に切り替えさせ、既知の脆弱性を突く攻撃手法の総称です。別名：バージョンロールバック攻撃（英: bidding-down attack）。この攻撃は、クライアントとサーバ間のハンドシェイクを意図的に改ざんすることで成立します。(crowdstrike.com)

重要なポイント

  • 狙い：「古いプロトコル（例：SSL 3.0）」や「弱い暗号（例：RC4や3DES-CBC）」へ強制的に接続させ、既知の攻撃（例：POODLE、BEASTなど）を実行する。(Google Online Security Blog)
  • 前提：クライアントまたはサーバが後方互換性のため古いバージョンや弱い暗号を許容していること。
  • 対策の核心：後方互換性を適切に制御し、サーバ・クライアント双方で不要な古いプロトコルを無効化し、プロトコルレベルで降格を検出・拒否する（例：TLS_FALLBACK_SCSV、RFC 7507）。(datatracker.ietf.org)

2. 背景と重要性

理由・背景

  • SSL/TLSはインターネットの機密性と認証を支える基盤だが、プロトコルが進化する過程で後方互換性が残るため、古い仕様に起因する弱点が残り得る。こうした弱点へ攻撃者が降格させることで、実質的に平文露呈やセッション奪取につながる。IPA等の情報でも重要性が繰り返し指摘されている。(ipa.go.jp)
  • 実例（歴史的インパクト）：2014年のPOODLE（Padding Oracle On Downgraded Legacy Encryption）は、SSL 3.0 の設計欠陥を悪用してCookieなどの機密情報を抜き取る攻撃で、ダウングレード（TLS → SSL 3.0）を前提に攻撃する代表例。これにより多くのブラウザやサーバがSSL 3.0 のサポートを廃止した。(Google Online Security Blog)

業務上の影響

  • Webサービスのセッション乗っ取り、APIトークンの漏洩、モバイルアプリの通信傍受など。国内でもモバイルアプリ等でダウングレード脆弱性が報告された事例（JVN）がある。(jvn.jp)

3. 攻撃の仕組み（段階的な手順と通信フロー）

攻撃の典型的な流れ（MITM型）

  1. クライアント → サーバ：ClientHello（最新バージョン候補＋暗号スイート一覧）
  2. MITMがClientHelloを改変し、「古いバージョン／弱い暗号のみ」を提示
  3. サーバは互換性のため弱い設定で応答（ServerHello）
  4. クライアントは本来は最新設定でやり取りするが、MITMの改ざんや再送によりフォールバックを誘発
  5. 結果：通信が弱いプロトコル（例：SSL 3.0）で成立し、攻撃者は既知の脆弱性を利用してデータを窃取

簡易シーケンス図（Mermaid）

sequenceDiagram participant Client participant MITM participant Server Client->>MITM: ClientHello Note over MITM: intercept and modify MITM->>Server: ClientHello (modified) Server-->>MITM: ServerHello (old/weak) MITM-->>Client: ServerHello (modified) Note over Client: forces client fallback Note over Client,Server: now on SSL 3.0/weak cipher Note over Client,Server: attacker exploits POODLE etc.

技術的ポイント

  • 「フォールバック（fallback）ルーチン」の悪用：クライアント実装は接続失敗時に古いプロトコルを試すことがある。この挙動を誘導する。
  • ハンドシェイク中のメッセージ改ざん（中間者がClientHello/ServerHello等を書き換え）による暗号ネゴシエーションの乗っ取り。

4. 実例とケーススタディ（具体事例）

4.1 POODLE（代表例）

  • 概要：SSL 3.0 のパディング仕様の欠陥により、攻撃者が復号に必要な情報を段階的に得られる。ダウングレードが前提条件。多数のブラウザ／サーバに影響。(Google Online Security Blog)

4.2 実務で報告された脆弱性（JVN等）

  • 一部モバイルアプリの脆弱性で、通信がダウングレードされ攻撃可能になっていた事例が報告されている（JVN）。(jvn.jp)

4.3 防御プロトコルの制定（RFC 7507）

  • TLS_FALLBACK_SCSV（Signaling Cipher Suite Value）は、クライアントが意図的にフォールバックしているかをサーバに知らせ、攻撃による降格を検出して接続を拒否させるための規格。実装と設定が有効だとMITMによる無害化が難しくなる。(datatracker.ietf.org)

5. 検出と検証（ツールとコマンド）

5.1 サーバ側テスト（OpenSSL）

  • サーバが古いプロトコルを受け付けるか確認：
# TLS 1.3 を要求（接続が成功すれば TLS 1.3 をサポート）
openssl s_client -connect example.com:443 -tls1_3

# SSL 3.0 を試す（現代のOpenSSLビルドでは無効なことが多い）
openssl s_client -connect example.com:443 -ssl3

結果の見方：プロトコルバージョンと選択された暗号スイートを確認。古いプロトコルでネゴシエーションされるなら設定見直しが必要。

5.2 クライアントのフォールバック動作検査

  • ブラウザやアプリのログ、またはテスト用プロキシ（例：mitmproxy）でClientHello/ServerHelloをキャプチャし、ネゴシエーションの内容を確認。

5.3 パケットキャプチャ例（Wiresharkフィルタ）

  • TLSハンドシェイクを追う：
tls.handshake.type == 1   # ClientHello
tls.handshake.type == 2   # ServerHello
  • 異常なバージョン表記を検出する例：
tls.record.version == 0x0300   # SSL 3.0

6. 防御と実装手順（サーバ・クライアント双方）

6.1 サーバ側設定（例：nginx）

行うこと（優先順）

  1. 不要な古いプロトコル（SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1）を明示的に無効化（TLS 1.0/1.1の廃止はRFC 8996参照）。
  2. 強力な暗号スイートのみ許可（AEAD／ECDHEベース、例：TLS_AES_128_GCM_SHA256 など。RC4は禁止：RFC 7465）。
  3. TLS_FALLBACK_SCSVのサポート確認（多くのモダン実装は自動有効）。
  4. HSTS（HTTP Strict Transport Security）適用でHTTP→HTTPSの強制を行う（補助的対策）。

nginx 設定例：

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...';
ssl_prefer_server_ciphers on;
# TLS 1.3 の暗号スイートは OpenSSL/libssl 側で管理

6.2 クライアント側（アプリ／ライブラリ）

  • モバイルアプリ／組込み系では「システムTLSライブラリ」依存のため、古いライブラリ（OpenSSL 1.0系やSSLeay）を使用していないか確認。
  • 最低TLSバージョンを明示的に設定（例：TLS 1.2以上）。多くのHTTPクライアントライブラリ（curl, OkHttp, URLSession等）で設定可能。
  • フォールバックの自動試行ロジックは極力排除（接続失敗時に古いバージョンへ自動切替しない）。

6.3 実装チェックリスト

  • [ ] サーバは ssl_protocols で TLS 1.2／TLS 1.3 のみを許可しているか
  • [ ] 使用暗号はAEADで、RC4/3DES/MD5/SHA-1 等を禁止しているか
  • [ ] TLS_FALLBACK_SCSV をサポートしているか（OpenSSL/LibreSSL 等の実装バージョンで有効か）
  • [ ] クライアントは最小TLSバージョンを TLS 1.2 に設定しているか
  • [ ] HSTS を設定しているか（可能な場合）
  • [ ] 定期的に TLS 設定を外部ツール（SSL Labs 等）で確認しているか

7. よくある誤り・注意点

  • 誤り：「TLS_FALLBACK_SCSVだけ入れれば安全」
  • 補足：SCSVは有効だが、最も重要なのは不要な古いプロトコルを完全に無効化すること。SCSVはフォールバック検出を助けるが、実装や運用の穴があると効果が薄れる。(datatracker.ietf.org)
  • 誤り：互換性優先で古いプロトコルを残す
  • 補足：一時的に互換性のため残す場合でも、影響範囲（顧客の利用クライアント）を測定し、段階的廃止の運用が必要。
  • 注意：TLS 1.3 は設計上ダウングレード耐性が高いが、実装ミスや設定ミスがあるとリスクは残る。IPA等のガイドラインで最新の推奨設定を確認する。(ipa.go.jp)

8. まとめ

  • ダウングレード攻撃は「後方互換性」と「ハンドシェイク改ざん」を悪用する。POODLEは代表例。(Google Online Security Blog)
  • 早急に行うこと：サーバ／クライアントで不要な古いプロトコルを無効化、強い暗号スイートの採用、TLS_FALLBACK_SCSVの確認。(datatracker.ietf.org)
  • 運用：定期的な外部評価（SSL Labs等）、脆弱性情報の継続監視（JVN/IPA/JPCERT等）。(ScanNetSecurity)

A. 参考サイト

B. 参考書籍

コメント