もしインターネットの１秒が１年だったら 第3回（vol.49掲載）

10月30日 午前4時34分　TLS終了アラート送信

FINパケットを受け取ったクライアントは、まずTCPコネクションを切断する前に、TLSの切断を示す、closure alert をサーバーに送信します。
この直後に送信されるTCPの切断パケットは、当然暗号化されていないので、中間攻撃者が簡単に偽造することができます。なので、攻撃者は任意のタイミングで通信を打ち切り、通信を妨害するtruncation attack が可能となります。
これによってログアウトなどの操作を堰き止め、セッションを悪用されるなどの被害を軽減するために、TLSではどのタイミングで暗号通信を終了するのかという情報を暗号化された状態で共有しなくてはなりません。それを行うのが、このclosure alertです。
クライアントちゃんはこの手順を正しく踏み、文通を終了する前に暗号通信の最後の手紙を送ります。半年間使い続けたmaster secretも、他の人にバレたら大変なのでこの段階で破棄します。なんだかちょっと寂しいですね。10月30日 午前6時4分　TCP切断送信

暗号通信の終了通知に続いて、クライアントは今度はTCPの切断を自分からも伝えます。手順はサーバーと同じで、FINフラグを立てたパケットをこちらからも送ります。
未練は少しありますが、サーバーちゃんからFINパケットが届いている以上、これ以上手紙を送ってもサーバーちゃんから返事を受け取ることはできません。クライアントちゃんはサーバーちゃんへ手紙のやり取りを終了するための最後の手紙を送りました。

11月14日 午後2時6分　TLS終了アラート受信

冷ややかな秋風が身に沁みる頃、クライアントちゃんからclosure alertを受信したサーバーちゃんは、クライアントちゃんと同じく、各種暗号に使った情報をそっと破棄します。もう、暗号のお便りが届くことはないのです。

11月15日 午前1時42分　TLS終了アラート送信

立て続けにクライアントちゃんからTCPの最後の切断メッセージが届きます。ACKフラグとFINフラグが立てられた、ヘッダーだけの味気ないパケットですが、半年以上クライアントちゃんと通信してきたサーバーちゃんは、クライアントちゃんがどんな気持ちでこのパケットを送ったのかが手に取るように分かります。

11月15日 午前1時50分 TCP切断に対する応答送信

先だって届いた手紙を受けて、サーバーちゃんはいよいよこの通信の最後の手紙を送ります。
またクライアントちゃんと文通したいという万感の思いを込めて、指定されたFINパケットに対するACKレスポンスを返します。

11月30日 午後9時27分 TCP切断に対する応答受信

さて、ついにサーバーちゃんからの最後の手紙が届きました。クライアントちゃんが送ったFINに対する最後のACK を受け取り、すべてのやり取りは終焉を迎えます。
1月1日、新しい年が始まると同時にARPリクエストから始まったこの通信は、次の年を目前に迎えた334日目*2に、その全過程を終了しました。これは実時間に換算して914.8ミリ秒に相当します。
今回使用したインターネット回線がだいぶ貧弱だったためか、実際のシチュエーションで想定される時間よりもだいぶ時間がかかっていますが、それでも、ネットワークの世界では、わずか1秒の間にこれだけのことが起こっています。皆さんもたまにはパケットキャプチャを行ってネットワークの深い世界に潜ってみてはいかがでしょうか。

*2 阪神は関係ない。