はじめに
Lantern Room は小規模な紙ランタンのワークショップを開催しています。予約アプリケーションは HTTPS を使うため、通常のキャプチャには予約の詳細ではなく暗号化された通信が表示されます。この管理された学習用サービスと合成された利用者を解析する許可があります。まず正常な参照記録を読み、次に自分で新しいアクセスを行ってキャプチャします。
別の許可された解析者が開ける、実際の PCAPNG ファイルと独立した TLS 鍵ログを作成します。基本的な Wireshark の操作、表示フィルター、簡単な端末入力とパスの知識が必要です。プログラミングや証明書管理は不要です。Desktop の Terminal Emulator と Wireshark ウィンドウを使います。このラボは独立してファイルとローカルサービスを準備します。所要時間は読解や通常の入力ミスへの対応を含む作者の見積もりです。
正常な参照記録を読めるようにする
このステップでは正常な予約を復号し、結果を確定するフィールドを学びます。
Desktop から始めます。左下の Applications → Terminal Emulator を開き、次の完全なコマンドを実行します。Wireshark を閉じるまで、この端末は使用中になります。
wireshark -C Booking /home/labex/project/booking/input/casebook.pcapng
-C Booking は、準備済みで初期状態が空の設定プロファイル Booking を選びます。プロファイルは解析ウィンドウの設定を保存します。タイトルバーの最大化ボタンで Wireshark を最大化します。入力キャプチャと input/casebook.keys は読み取り専用の原本です。作業結果は output/ に保存してください。
HTTPS は、アプリケーションの会話を暗号化する TLS 内で HTTP を運ぶ仕組みです。TCP は端点間で TLS レコードを運びます。この記録は TLS 1.3 と HTTP/1.1 を使用します。ローカルサービスは 127.0.0.1:18443、Hazel のローカルテスト用識別アドレスは 127.0.0.21 です。これらのアドレスは同じ学習用コンテナを共有し、別々の物理マシンではありません。
表示フィルターバーに http を入力して Enter を押します。最初は復号済み HTTP 行がありません。バーを空にして TLS ハンドシェイクと暗号化された Application Data を確認します。ハンドシェイクはセッションを確立し、Application Data は予約メッセージを運びます。キャプチャだけでは、その平文は得られません。
TLS 鍵ログには、許可されたクライアントが特定のセッション用に意図的に記録した秘密情報が含まれます。パスワード一覧やサーバー証明書ではありません。サーバー証明書や RSA 秘密鍵では、この TLS 1.3 セッションの秘密情報を代用できません。実務ではキャプチャと鍵ログを機密情報として扱い、許可された解析範囲内だけで共有します。ここでの識別情報、予約、秘密情報はすべてローカル演習のものです。
Edit → Preferences を開きます。Protocols を展開し、プロトコル一覧をクリックして tls と入力し、TLS を選びます。**(Pre)-Master-Secret log filename** に次の絶対パスを入力します。Reassemble TLS records spanning multiple TCP segments と Reassemble TLS Application Data spanning multiple TLS records は有効のままにして OK をクリックします。
/home/labex/project/booking/input/casebook.keys
再び http 表示フィルターを適用します。POST リクエストと HTTP レスポンスが 1 つずつ表示されます。空のままならフィルターを消し、ファイル名の綴りを確認して TLS 設定へ戻ります。間違った鍵ログや無関係なログは Application Data が復号されない原因になりますが、リクエストが存在しない証拠にはなりません。
POST を選びます。HTTP はリクエストとレスポンスのプロトコルです。POST はデータを送信し、/api/bookings は予約リソースを示す URI です。リクエストを右クリックし、Follow → TLS Stream を選びます。Follow TLS Stream は復号されたアプリケーションバイトを表示します。Follow TCP Stream は暗号化された転送バイトのままです。必要ならスクロールし、両方を読みます。文字色から送信者を判断せず、リクエスト行とレスポンスのステータス行を読んでください。
リクエスト本文は JSON、つまり波括弧で囲まれた名前付き値の集合です。visitor、attempt、workshop、slot を読みます。レスポンスはこれらを繰り返し、accepted、reason、confirmation を加えます。Hazel の正常な予約は accepted: true、reason: "confirmed" で、確認値は hazel-01 に属します。JSON の true は真偽値、引用符で囲まれた値は文字列、null は値がないことを表します。
HTTP/1.1 200 OK は、サーバーがこの HTTP リクエストを処理したことを意味します。予約のアプリケーション結果は JSON フィールドから判断します。この違いは次のラボで重要になります。JSON の後の大きな空白は意図的な学習用パディングで、実際のレスポンスを複数の TLS/TCP セグメントに分割します。別の予約ではありません。
レスポンスで繰り返される attempt と accepted、reason、confirmation を読みます。HTTP ステータスだけでは不十分です。
Close で Follow を閉じます。Wireshark は tcp.stream eq ... フィルターを残し、ハンドシェイクとセグメントを含む選択済み TCP 接続全体を表示します。表示フィルターは表示だけを変えます。メインウィンドウを閉じてプロファイル設定を保存し、端末を解放します。Booking が参照記録の完全なリクエストとレスポンスを復号できれば設定完了です。
自分のアクセスをキャプチャして開き直す
このステップでは、新しい許可済みアクセスをキャプチャし、実際に保存したパケットを独立して開き直します。
参照ウィンドウを閉じた後の Desktop の Terminal Emulator プロンプトから始めます。参照記録の鍵ログでは別の TLS セッションを復号できません。新しいアクセスをキャプチャし、その固有の秘密情報をキャプチャの隣に保存します。
準備済みのキャプチャ起動プログラムを実行します。
python3 /opt/labex/booking/capture.py
別の BookingLive プロファイルで、実際の Wireshark ライブキャプチャ画面が開きます。固定のパケット入力は、ループバック上のコース用ポート 18443 の TCP 通信だけを対象とし、15 分および 4 MB に制限されています。これは再生ではなく、Wireshark にライブバイトを渡すパイプを使用します。一般的なキャプチャ権限を付与したり、ログイン設定を変更したりしません。端末と Wireshark を開いたままにし、通信を送る前に端末の Live packet feed ready と動作中のキャプチャウィンドウを確認します。
Applications → Terminal Emulator から 2 つ目の Terminal Emulator を開きます。下部パネルで 2 つの端末と Wireshark を切り替えられます。新しい端末で許可済みクライアントを実行します。
python3 /opt/labex/booking/booking.py client
クライアントはローカルサービスの証明書とホスト名を検証し、実際の予約リクエストを 1 つ送信して、新しいセッションの秘密情報を /home/labex/project/booking/output/live.keys に記録します。回答を表示せず、アクセス完了を表示します。新しい attempt は実行ごとに異なります。your-visit クライアントは 127.0.0.26 を使用します。
下部パネルから Wireshark に戻ります。最後の TCP 接続終了パケットを含め、パケットが実際に表示されるまで待ってから、ツールバーの赤い Stop 四角を押します。クライアントの完了は、キャプチャ画面への全パケット到着を意味しません。ハンドシェイク、暗号化アプリケーション通信、最後の FIN または RST が見えるはずです。FIN は TCP の片方向を閉じ、RST は接続を直ちに終了します。この管理されたクライアントの終了 RST は予約結果ではありません。
File → Save As、または未保存のキャプチャで Ctrl+S を選び、形式 pcapng のまま次へ保存します。
/home/labex/project/booking/output/live.pcapng
パケット一覧のテキストや画像ではなく、実際のキャプチャを保存します。鍵ログは別に保ち、Inject TLS Secrets は使いません。保存後、キャプチャのメインウィンドウを閉じます。最初の端末では起動プログラムが native dumpcap status: 0 で終了し、プロンプトに戻ります。ウィンドウを閉じるとコースの入力も終了します。端末への再接続は予約サービスをリセットしません。
どちらかの端末で、初期状態が空の確認用プロファイルを使って保存ファイルを開きます。
wireshark -C BookingReview /home/labex/project/booking/output/live.pcapng
http を適用すると、最初は再び空です。Edit → Preferences → Protocols → TLS で、まずステップ 1 の完全な絶対パスを用いて参照鍵ログ input/casebook.keys を試し、OK を押します。それでも新しいセッションは復号されません。次に対応する新しい鍵ログへ置き換えます。
/home/labex/project/booking/output/live.keys
OK を押して http を適用します。POST と対応するレスポンスが 1 つずつ見えます。POST を右クリックして Follow → TLS Stream を選びます。新しい attempt を読み、レスポンスが同じ値を返すこと、accepted、reason、固有の confirmation を確認します。有効な結果は sat-14 の paper-lantern 予約の確認です。Follow とメインウィンドウを閉じます。参照セッションの秘密を借りずに、実際の保存ファイルを独立して開き直せました。
リクエストとレスポンスは同じ新規 attempt を示します。生成値は例と異なりますが、重要なのは対応関係です。
停止が早すぎた場合、再試行前に不完全な試行を保管します。以前の出力 2 ファイルが両方ある場合だけ、端末で次のコマンドを実行します。mv は各ファイルの名前を変えます。パスに空白はないため引用符は不要です。入力ファイルもサービスも変更しません。
mv /home/labex/project/booking/output/live.pcapng /home/labex/project/booking/output/live-previous.pcapng
mv /home/labex/project/booking/output/live.keys /home/labex/project/booking/output/live-previous.keys
その後、起動プログラム → 2 つ目の端末でクライアント → 最終パケットの表示 → Stop → Save → Close → 開き直す、を繰り返します。live-previous が既にあれば、先に別の未使用バックアップ名を選びます。対応する秘密情報を失わせないため、クライアントは意図的に live.keys の上書きを拒否します。保存先の間違いは File → Save As で直せるので、再アクセスは不要です。フィルターを入力ミスしたら消して http を再入力し、環境をリセットしないでください。
まとめ
Wireshark で許可された参照記録を復号し、新しい実際の HTTPS アクセスをキャプチャして、その固有の鍵ログで保存済み PCAPNG を開き直しました。間違った参照用秘密情報では新しいセッションは復号できません。再利用できる成果は output/live.pcapng と output/live.keys です。
HTTP ステータスと予約結果を区別し、レスポンスで繰り返される attempt も読みました。次のラボでは、同じ持続接続上の失敗した予約と再試行にこの違いを適用します。
