要約

  • RFC 9846の close_notify は、一方のTLS送信方向を秩序立てて終わらせ、受信側に暗号学的な切断境界を与える。アプリの解析、永続化、副作用、決済に対する確認応答ではない。
  • 信頼できる終了記録は、最後に受理したTLSレコードと警告を、別管理の取引ID、確定結果、再試行規則へ結び付ける。発生時刻が近いというだけで、前者から後者を推定してはならない。

支払いクライアントが指図を書き込み、送信バッファをフラッシュした直後に、サーバーの close_notify を受け取った場面を考える。TLSライブラリはプロトコルエラーなしのデータ終端を通知する。しかし、クライアントがその瞬間に「支払済み」と保存する根拠はどこにもない。サーバーはバイト列を読んだうえで指図を拒否したかもしれず、解析後にコミット前で停止したかもしれない。すでにコミットしたが応答だけが失われた可能性もある。いずれも通信層の観測だけでは区別できない。

RFC 9846 は2026年7月のTLS 1.3 Proposed Standardであり、RFC 8446を廃止しつつ、同じTLS 1.3プロトコル版に互換的な明確化と更新を加えた。そこでの close_notify の仕事は限定されている。接続の一方向を正常に閉じ、送信者がその接続でもうTLSメッセージを送らないと知らせることである。受信後のデータは無視され、TLS実装はアプリケーションへデータ終端を通知することが求められる。

運用上もっとも重要なのは「一方向」という語である。どちらの当事者も close_notify を送って自分の書き込み側を閉じられるが、それは読み取り側には影響しない。クライアントは送信を終えた後も応答を読み続けられ、サーバーは送信を終えた後も受信を続けられる。一つの警告は対称な接続解体でも、分散トランザクションの投票でもない。

エラー警告をすでに送った場合を除き、各当事者は書き込み側を閉じる前に close_notify を送らなければならない。一方、読み取り側を閉じる前に相手の警告を待つことまでは要求されない。ただし、待たなければ切り詰めの可能性が生じる。独立した二方向から得られるのは二件のチャネル終了事実であり、二相コミットの二票ではない。

この警告が守るのはストリームの末尾である。基礎のトランスポートが close_notify より先に閉じると、受信者は送信者が発したデータをすべて受け取ったか判断できない。現在の接続状態で保護された終了警告は、秩序ある末端と説明のつかない末尾消失を分ける。この保証には大きな価値があるが、末端より前のデータを受信アプリがどう扱ったかまでは示さない。

IANA TLS Parameters は close_notify の警告記述コードを登録している。RFC 9846は、従来の warning レベルで送る要件も復元した。「warning」は任意という意味ではなく、業務結果の軽重でもない。送信義務、警告レベル、アプリの結果は別々の問いである。エラー警告は中断的に接続を閉じ、それ以後のデータを認めないため、正常終了と同じ状態として扱えない。

TLS 1.3は、古い版で起こり得た有害な連動も改めた。かつては close_notify を受けると、保留中の書き込みを捨て、自分の警告を即座に返して閉じる動作が求められ、読み手側の送信ストリームまで途中で切れることがあった。現在の規則では読み書きが独立し、利用プロファイルは相手の送信終了後にも必要な出力を完了できる。

アプリは、警告を受けた時点で送信バッファをフラッシュし、ただちに自分の close_notify を返すこともできる。しかしRFC 9846は、攻撃者が警告やアプリパケットの配送を遅らせ、相手が何を受け取るかへ影響できると注意する。したがって、取引状態を決めるにはアプリ層の規則が要る。送信終了後に新規入力を受け付けない、完全なアプリ応答なしには確定扱いしない、といった規則である。

ここで配送順序と効果の権限を分けなければならない。TLSはレコードを保護し、その列に認証された終端を与える。信頼できる順序付きトランスポートは、書き込み側の閉鎖時に保留データを配送してから接続を破棄するという前提を支える。どちらの層もアプリのパーサーを定義せず、取引IDを検証せず、冪等性キーを割り当てず、保存をコミットせず、業務受領証を発行しない。

RFC 9293 は多くのTLS接続を支えるTCPのモデルと片方向の終了を示す。RFC 9110 と RFC 9112 は、その上にあるHTTPの意味とHTTP/1.1メッセージのフレーミングを規定する。層が組み合わされても、完了条件まで一つになるわけではない。HTTPなら要求と関連付いた最終応答と完全な本文、キューなら耐久配置後のブローカー確認、支払いなら安定した操作IDを持つ領域固有の受領証が必要になる。

逆向きの誤推論も危険である。close_notify がなかったことは、アプリ操作が失敗した証明ではない。アプリがすでにコミットし受領証も返した後で、トランスポートだけが消えた可能性がある。欠けているのはその方向のTLS切断保証であって、業務効果とは限らない。警告のない切断をすべて自動再送に変えれば、非冪等操作を重複させる。

user_canceled も取引の意味を補わない。RFC 9846では、プロトコル失敗とは無関係なハンドシェイク中止を表し、その後に close_notify を送る必要がある。受信者は終了まで読み続けるべきである。これらはTLS状態の語彙であり、払い戻し、注文取消し、同意撤回といったアプリ側の効果を符号化していない。

規格は接続ライフサイクルの権限を利用プロファイルに残す。同じ基礎トランスポートでTLS終了後に非TLSデータを扱うプロトコルなら、TLS実装は close_notify を受けるまで上位へTLSデータ終端を知らせてはならない。さらにRFC 9846は、基礎トランスポートをどう管理し、接続をいつ開閉するかを一律に決めないと明記する。

この境界が誤った一般化を防ぐ。RFC 9001 はQUICのハンドシェイク保護にTLSを使う一方、TLSレコード保護などをQUIC固有の仕組みに置き換え、接続終了にも独自の機構を持つ。RFC 9147 のDTLS 1.3にはデータグラム固有の文脈がある。順序付きTLSストリーム向けの判断を、すべての暗号化トランスポートへ貼り付けてはならない。

サービスIDも別の制御面に属する。RFC 9525 は、アプリプロトコルがサービスID検証をTLS利用規則へ組み込む方法を述べる。正常終了は相手を再認証せず、認可期間を延長せず、人間の行為者を確定せず、最後の副作用を承認しない。

インシデントの時系列では、最後のアプリ書き込み、最後に受理したTLSレコード、終了警告が近接しやすい。時間の近さは調査材料にはなるが、因果的な受領証にはならない。サーバーは作業をキューへ入れた後、ワーカーのコミット前に送信を閉じられるし、実行しないと決めた後にも閉じられる。権威ある状態を知るのは業務状態機械だけである。

RFC 5116 が示す認証付き暗号のインターフェースも、この線引きを補強する。暗号文や認証データの境界は、業務意図の境界ではない。現在の接続状態で警告が認証されたことと、相手の保存系が不可逆な処理を終えたことの間には、明示的なアプリ証拠が必要である。

採用した規範本文の追跡も欠かせない。RFC 9846 publication record は正式な状態と書誌情報を、RFC 9846 errata は訂正確認の入口を、RFC 8446 は置き換え前の仕様を提供する。これらは規則の由来を示すが、特定製品の動作、普及率、現場事故を推測する根拠にはしない。

出典