失敗した予約と再試行を追跡する

はじめに

Alder は、Lantern Room の予約ページが 2 回の試行を処理したものの、予約になったのは 1 回だけだと言っています。サポートチームには許可された HTTPS 記録と対応する TLS 鍵ログがあります。2 回とも同じ URI と TCP 接続を使用し、ファイルには別の利用者も含まれます。

実際の Wireshark 画面で各アプリケーション結果を特定し、短い証拠表と独立して読める完全なキャプチャ一式を作成します。Read Your Authorized HTTPS Session を完了しているか、TLS 鍵ログ設定と Follow TLS Stream を理解していることが前提です。基本的な端末入力とパスの知識も必要です。このラボは固有の管理された記録で独立して始まります。所要時間の見積もりには読解と通常のミス対応を含みます。

各試行を対応する業務結果と結び付ける

各元リクエストフレームを、その固有の完全なレスポンスに結び付け、両方の結果を記録します。

Desktop → Applications → Terminal Emulator から始めます。空の Booking プロファイルで準備された入力を開きます。

wireshark -C Booking /home/labex/project/booking/input/casebook.pcapng

Wireshark を最大化します。読み取り専用入力は casebook.pcapng と casebook.keys です。すべての成果物は /home/labex/project/booking/output/ に置きます。データは合成ですが、各 TLS ハンドシェイク、HTTP 交換、TCP セグメントは実際の管理されたローカルアプリケーションが生成しました。

Edit → Preferences → Protocols → TLS の (Pre)-Master-Secret log filename を次に設定します。

/home/labex/project/booking/input/casebook.keys

TLS の両再構成オプションを有効のまま OK を押します。鍵ログはこの記録のセッションを復号するためのもので、任意の HTTPS 接続を解く共通鍵ではありません。

次の表示フィルターを適用し Enter を押します。

ip.addr == 127.0.0.22 && http

ip.addr はどちらかの端点に一致します。&& は両条件が必要という意味なので、Alder の復号済み HTTP メッセージが両方向に表示されます。POST が 2 件、200 OK が 2 件あるはずです。両試行で URI /api/bookings と TCP ストリームが共通なので、どちらか単独では 1 件の処理を特定できません。

最初の POST を選びます。中央の詳細ペインで小さな三角を使い Hypertext Transfer Protocol を展開します。下方の [Response in frame: ...] を読みます。この生成フィールドは、Wireshark が実際に対応付けたレスポンスへリクエストを結びます。そのレスポンス内の [Request in frame: ...] は元を指します。一覧から対応レスポンスを選びます。No. 列が元のフレーム番号です。再構成 HTTP は最後のセグメントに表示される場合があるため、隣接 TCP 行から推測せず、この解析フレーム参照を使います。

展開済み HTTP 詳細の [Response in frame: 21] を確認します。これは選択中の最初のリクエストのリンクであり、2 つ目のリクエストには別のレスポンスがあります。

リクエストを右クリックし Follow → TLS Stream を選びます。完全なリクエストとそのレスポンスを読みます。リクエスト JSON は attempt、workshop、slot を示し、レスポンスも同じ値を返します。accepted、reason、confirmation を組み合わせて読みます。同じストリームを下へ読み、2 つ目のリクエストとレスポンスも確認します。

Alder の最初の試行は満席で拒否され、accepted は false、reason は "session_full"、confirmation は null です。再試行は受け付けられ、その固有の確認コードがあります。両 HTTP ステータス行は 200 OK です。サーバーは両リクエストを処理しましたが、業務結果は異なります。同じ流れの別の場所や Birch のアクセスに見つけた確認コードを、拒否された試行に流用してはいけません。

Close で Follow を閉じます。残るストリームフィルターには接続全体が含まれます。上記の Alder と HTTP の元フィルターへ戻し、4 つの元フレーム番号を記録します。表の作成中は常に元入力ファイルを使います。エクスポートすると番号が付け直されます。

別の解析者がキャプチャと照合できる小さな引き継ぎ索引 attempts.csv を準備します。CSV はカンマ区切り値で、見出し行が列名、以降の各行が 1 試行です。7 列あります。

下部パネルで端末へ移るか、最初の端末が Wireshark 使用中なら別の Terminal Emulator を開きます。テキストエディターを起動します。

mousepad /home/labex/project/booking/output/attempts.csv

次の見出しを正確に入力し、元キャプチャから読み取った 2 行を加えます。confirmation 列に単語 null を書かず、拒否行をカンマで終えて最後の空フィールドを表します。このデータの値にはカンマがないため、CSV フィールドの引用符は不要です。見出しと値が対応していれば、行や列の順序は変えて構いません。

attempt,request_frame,response_frame,slot,accepted,reason,confirmation

File → Save で保存してエディターを閉じます。異なる各試行が 1 行ずつあり、それぞれ自分のレスポンスを指すか確認します。入力ミスは同じコマンドで同じファイルを開いて修正・保存できます。新しいキャプチャや VM リセットは不要です。次のステップに向け Wireshark は開いたままにします。

独立して読める証拠一式を渡す

対象接続全体をエクスポートし、引き渡す鍵ログを使って開き直します。

Desktop で Wireshark が元の input/casebook.pcapng を開いた状態から始めます。表は元記録を索引にしますが、引き渡すキャプチャはAlder の完全な TCP 接続だけにします。アプリケーションデータの復号と再構成には TLS ハンドシェイクと先行セグメントが必要です。

表示フィルターを次へ置き換えます。

ip.addr == 127.0.0.22

Alder の両方向と全プロトコル層を残します。復号済み POST の 1 つを選び、右クリックで Follow → TLS Stream を開きます。両試行が Alder と確認したら Close で閉じ、tcp.stream eq ... を残します。これは HTTP と表示された行だけでなく、選択した接続全体を含めます。

File → Export Specified Packets を選びます。形式 pcapng、範囲 Displayed、その表示集合内で All packets を選び、次へ保存します。

/home/labex/project/booking/output/evidence.pcapng

ダイアログは Displayed と All packets、対象 38 パケットを示します。元ファイルは 65 パケットなので、Captured では別の利用者も含まれます。

要約を出す Export Packet Dissections は使いません。http 行だけでは復号や再構成に必要なハンドシェイクや先行 TLS/TCP セグメントを落とすことがあります。Inject TLS Secrets で秘密を埋め込まず、別の鍵ログを使います。

Terminal Emulator で、許可された鍵ログを出力の隣にコピーします。cp は第 1 パスを第 2 パスにコピーし、元入力は名前を変えずに残します。

cp /home/labex/project/booking/input/casebook.keys /home/labex/project/booking/output/booking.keys

学習用の引き渡しは同じ許可範囲内です。提供ログには元記録の合成セッションの秘密が含まれ、項目の最小化や削除はこの演習の範囲外です。それでもキャプチャは Birch のパケットを除外する必要があります。両対象レスポンスを独立して復号できれば、等価な対応鍵ログも受け付けられます。

メインウィンドウを閉じ、初期状態が空の BookingReview で実際のエクスポートを開きます。

wireshark -C BookingReview /home/labex/project/booking/output/evidence.pcapng

Edit → Preferences → Protocols → TLS の (Pre)-Master-Secret log filename に次の出力鍵ログを設定し、OK を押します。

/home/labex/project/booking/output/booking.keys

http を適用し、POST を Follow → TLS Stream で読みます。両リクエストとレスポンスの完全な本文を再読します。Alder の拒否と確認が各自の attempt 参照とともに見え、Birch のアクセスがない必要があります。元入力鍵のパスに暗黙依存せず、出力鍵ログで動作することを確認します。

各結果の隣の attempt を読みます。拒否には確認コードがなく、再試行だけが ALDER-02-CONF を持ちます。タイトルの evidence.pcapng は出力ファイルを示します。

Follow を閉じ、表示フィルターを消してハンドシェイクと他の TCP パケットも確認します。このファイルは独自の番号を持ちますが、attempts.csv は元入力のフレームを参照し続けます。メインウィンドウを閉じます。

出力が空、または本文が欠ける場合は元入力を開き、完全な Alder 接続フィルターに戻して Displayed → All packets で Export Specified Packets をやり直し、不完全な出力を置き換えます。暗号化されたままなら TLS 設定の出力鍵パスを直します。鍵不足は復号を妨げますが、キャプチャにないセグメントは設定変更では復元できないという違いがあります。

成果は attempts.csv、evidence.pcapng、booking.keys の実ファイル 3 つです。キャプチャと鍵が表を独立して裏付けなければなりません。画像や成功と書いた文章は実際のパケット証拠の代わりにはなりません。

まとめ

同じ HTTP ステータスが運ぶ 2 つの業務結果を区別し、各リクエストを固有のレスポンスに対応付け、元のフレーム参照を短い証拠表に記録しました。対象 TCP 接続全体をエクスポートし、別の鍵ログで実際の出力を開き直しました。

3 ファイルの成果は自分の Wireshark プロファイルがなくても確認できます。この管理された予約通信の内容を示すもので、本番の支払い、在庫更新、サーバー内部の欠陥を証明するものではありません。