SSLとdumpの基礎知識と復号化技術を詳しく解説するブログ

2025 10/29

2025/10/29

はじめに

本調査の概要

本調査は「ssl dump」関連の技術情報を整理したものです。SSL/TLS通信の監視や解析の基本、トラブルシューティングで必要となるログの取り方、Wiresharkを用いた復号化の手順などを分かりやすくまとめます。加えて、暗号化プロトコルの仕組み、デジタル証明書の役割と安全性、RSAからDiffie‑Hellmanへの移行理由、そしてメモリダンプを用いたセキュリティ調査の実務的な応用を解説します。

目的と期待される効果

目的は、現場で役立つ実践的な知識を提供することです。通信の可視化や証明書の確認、鍵交換の違いを理解することで、障害対応や脆弱性調査の精度を高められます。手順や注意点を丁寧に示すため、実務で再現しやすい内容にしています。

想定読者

ネットワークやサーバー管理を担当する技術者、セキュリティ担当者、またはSSL/TLSの動作を学びたいエンジニアを想定しています。基礎知識を持つ方向けに書きますが、専門用語は必要最小限に留め、具体例で補足します。

本書の読み方

各章で理論と実践を交互に扱います。まず概念を整理し、次に具体的な手順やツールの使い方を示します。章ごとに独立して参照できる構成にしてありますので、必要な箇所からお読みください。

SSLデバッグとは何か

定義

SSLデバッグは、SSL/TLS接続の内部状態ややり取りをログに出力する仕組みです。通信の成立過程や異常発生時の情報を可視化できるため、問題解析に役立ちます。例えると、通信の「やり取り」を録音してあとで再生するようなものです。

ログに含まれる主な情報

証明書チェーンや発行者情報
サーバー設定（使用するプロトコルや暗号スイート）
鍵情報や証明書の指紋（フル秘密鍵は通常出力されませんが注意が必要です）
SSLレコードやハンドシェイクの詳細
スタックトレースやI/Oエラー情報

利用シーン

接続が確立できない原因追跡
証明書チェーンの誤り確認
特定クライアントとの互換性問題の切り分け

有効化の注意点

ログには機密情報が含まれる可能性があるため、取得時は出力先を限定し、短時間だけ有効にしてください。運用環境で長時間有効にすると情報漏えいのリスクが高まります。オペレーション手順を用意し、必要時のみ実行する運用をおすすめします。

読み方のポイント

ハンドシェイク開始から終了までの順序を追うと原因が見つかりやすくなります。まずクライアント・サーバーのネゴシエーション結果を確認し、次に証明書やエラーの記録を照合してください。

簡単な例

WebLogic Serverで有効化すると、ALERT発生時にスタックトレースと上記情報がダンプされ、問題の切り分けが素早く行えます。

SSLダンプの必要性と活用シーン

説明

SSLダンプは、クライアント側とサーバー側の双方でデバッグを有効にして取得することで、問題発生箇所を正確に特定できます。ログにはハンドシェイクの各段階やALERT（警告／致命的エラー）とその直後のトレース情報が含まれ、どちらの当事者で障害が起きたかを判断できます。これによりIT管理者は原因を絞り込み、再発防止に役立てます。

活用シーン（具体例）

ハンドシェイク失敗：証明書の期限切れやSNI不一致、プロトコルのミスマッチが原因のとき、ダンプでどのメッセージが最後に交わされたか分かります。
暗号スイート不一致：クライアントとサーバーが対応する暗号を持たない場合、ネゴシエーションのログで判別できます。
中間機器の干渉：ロードバランサやプロキシによる切断や改変が疑われるとき、両端のログを突き合わせて特定します。
再現性の低い障害：断続的な切断やタイムアウトを解析するとき、時刻付きダンプを蓄積して相関解析します。

実践手順（簡潔）

問題を再現できる環境で、クライアントとサーバー双方のデバッグを有効にします。
問題発生時のログをタイムスタンプ付きで収集します。
ALERTメッセージ（例：certificate_unknown、handshake_failure、bad_record_mac）とその直後のトレースを確認します。ALERTの種別とトレースから障害側を割り出します。

セキュリティ注意点

デバッグログには機密情報が含まれる場合があります。ログの保存・転送は暗号化経路で行い、解析後は不要なログを削除してください。アクセス権を限定し、最小限の範囲で取得することを心がけてください。

Wiresharkを使用したSSL/HTTPS通信の復号化

概要

WiresharkでHTTPS通信を復号化するには、セッションごとのプレマスターシークレットを使う方法がもっとも確実です。サーバーの秘密鍵での復号はRSA鍵交換に限られ、Perfect Forward Secrecy（PFS）を使うセッションでは無効になります。

準備

最新のWiresharkを用意します。2. 復号に使えるプレマスターシークレットを取得します（ブラウザやアプリが対応している必要があります）。

ブラウザでのプレマスターシークレット取得例

環境変数SSLKEYLOGFILEを設定し、ブラウザを起動します。ブラウザがセッションごとにキーをそのファイルへ書き出します。例: export SSLKEYLOGFILE=~/sslkeys.log

Wiresharkでの設定と復号化手順

Wiresharkを起動し、キャプチャファイルを開きます。2. メニューの「Edit」→「Preferences」→「Protocols」→「TLS」を開き、(Pre)-Master-Secret log filenameに先ほどのsslkeys.logを指定します。3. 該当のTLSセッションを選ぶと、Wiresharkが自動で復号化し、HTTP/2やHTTPのペイロードを表示します。

RSA鍵での復号（限定的）

サーバーの秘密鍵を使う方法は古い設定（RSA鍵交換）でのみ有効です。多くの現代サイトはECDHE/DHEを使い、ディスク上の鍵ではなくRAM内の一時鍵を用いるため、この方法は役に立たないことが多いです。

注意点

セキュリティとプライバシーに配慮し、権限のある環境でのみ復号を行ってください。- ログファイルは機密情報を含むため、安全に保管または削除してください。

モダンなSSL/TLS暗号化プロトコルの仕組み

はじめに

SSLは古く、現在はTLSが主流です。TLSは通信内容を守る仕組みで、主に「対称暗号」と「非対称暗号」を組み合わせて使います。ここでは、実際の動きと分かりやすい例で説明します。

対称暗号と非対称暗号

対称暗号は同じ鍵で暗号化と復号を行います。速く大量のデータに向きます。非対称暗号は公開鍵と秘密鍵という2つの鍵を使い、安全に情報をやり取りします。例えると、対称は家の鍵を共有するようなもので、非対称は郵便受けのように配達用の鍵（公開）と取り出す鍵（秘密）を分けるイメージです。

鍵交換の仕組み（Diffie-Hellman/ECDH）

鍵を安全に共有するために、Diffie-Hellman（DH）や楕円曲線DH（ECDH）を使います。簡単な例だと、二人がそれぞれ色を混ぜて共通の色（共有鍵）を作るような手順です。相手の秘密を直接送らずに同じ鍵を作るため、盗聴されても鍵を特定されにくい設計です。

TLSハンドシェイクと暗号スイート

通信開始時にハンドシェイクを行い、使う暗号アルゴリズムの組み合わせ（暗号スイート）を決めます。ここで非対称で相手を認証し、対称鍵を安全に決定します。暗号スイートには暗号化方式、鍵交換方式、ハッシュ関数などが含まれます。

前方秘匿（PFS）

PFSは過去の通信が将来に漏れないための仕組みです。鍵交換で毎回新しい一時鍵を使うことで、もし長期の秘密鍵が漏れても過去のやり取りは保護されます。実務ではこれを必須で使うことが多いです。

設計上のポイント

速さと安全性のバランス、証明書での認証、そして前方秘匿の採用が重要です。実例として、ブラウザとサーバーはまず互いの対応可能な暗号を確認し、共通の安全な方法で短期鍵を作ってから本格的にデータをやり取りします。

デジタル証明書による認証と中間者攻撃の防止

証明書の役割

サーバーが自分の正当性を示す書類がデジタル証明書です。証明書にはサーバーの公開鍵とドメイン名、発行者情報、有効期限などが含まれます。認証局（CA）がその情報に電子署名を付け、第三者が発行内容を保証します。

検証の流れ（簡単な手順）

クライアントがサーバーへ接続すると、サーバーは証明書を送ります。
クライアントは証明書の署名を信頼できるCAの公開鍵で検証します。
ドメイン名や有効期限、失効状態を確認します。これらが正しければ接続を続けます。

中間者攻撃（MITM）と防止

攻撃者が通信を傍受して偽のサーバーを立てても、正しいCAの署名がなければ証明書検証で不一致になります。ブラウザやクライアントは警告を出し、安全な接続を拒否します。したがって、正しいCAと鍵管理が重要です。

補助的な対策

証明書ピンニングやHTTP Strict Transport Security（HSTS）、失効情報（OCSP/CRL）の確認を併用するとより堅牢になります。自己署名証明書は警告が出るため、公開サービスでは避けるべきです。

RSA鍵復号化の廃止とDiffie-Hellman鍵交換への移行

概要

近年、RSAを使ったSSL復号化は実務で使いにくくなりました。Perfect Forward Secrecy（PFS）の普及により、サーバーの秘密鍵を持っていても過去の通信を復号できないことが普通になっています。

なぜRSA復号が機能しないのか

RSA鍵交換ではサーバー秘密鍵からセッション鍵を導けました。PFSを使うDiffie-Hellman系（DHE/ECDHE）は毎回新しい一時鍵を生成します。これにより、長期秘密鍵で過去のセッションを復号できなくなります。

Diffie-Hellmanを見分ける方法

キャプチャしたTLSハンドシェイクの暗号スイートに「DHE」または「ECDHE」が含まれていると、DH系鍵交換が使われています。
サーバーがServerKeyExchangeを送る場合、DHパラメータが交換されます。

実務的なデバッグ手順

WiresharkのRSA鍵アップロードはPFS下では無効です。RSAでの復号はサーバーがRSA鍵交換を使う場合のみ有効です。
ブラウザやクライアントでSSLKEYLOGFILEを有効にすれば、プリマスターシークレットを取得できます。これをWiresharkに読み込むとECDHEでも復号可能になります。