【入門編】 TLS 1.3ハンドシェイクにおける1-RTTと0-RTTのセキュリティ特性 – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

こんにちは！日々の開発やインフラのお仕事、本当にお疲れ様です。セキュリティの世界へようこそ！

私たちが普段何気なく使っているインターネットの通信。その裏側では、目に見えないところで大切なデータを守るための「暗号のやり取り」が毎秒行われています。WebサイトのURLの頭にある「https://」がまさにそれですね。

今回は、最新の通信規格であるTLS 1.3における「ハンドシェイク（通信の最初に行う挨拶と鍵の共有）」の仕組み、そしてそのスピードを極限まで高める1-RTTと0-RTTの秘密について、身近な例えを交えながら一歩ずつ紐解いていきましょう。

小難しい専門用語が出てきても大丈夫です。一つひとつ、一緒に仕組みを覗いてみませんか？

—

1. そもそも「ハンドシェイク」って何？家の鍵の受け渡しに例えてみよう

インターネットで安全に通信をするためには、まず「これから二人だけの秘密の暗号で会話しましょうね」という合意（ハンドシェイク）を最初に済ませる必要があります。

これを身近な例えで考えてみましょう。

あなたは遠くに住む友人（サーバー）と、誰にも盗み聞きされたくない秘密の手紙のやり取りをしたいと思っています。
手紙をそのままポストに入れたら、郵便配達員（途中のルーターや悪意あるハッカー）に中身を読まれてしまいますよね。だから、二人は「専用の南京錠」をかけたいわけです。

しかし、その南京錠の「鍵」をどうやって相手に渡せばいいでしょうか？
鍵を普通の手紙に入れて送ったら、その瞬間に鍵を合鍵屋さんに複製されてしまいますよね。

この「どうやって安全に共通の鍵を作るか・共有するか」のドラマが、まさにTLSハンドシェイクの正体です。

—

2. 従来の「お上品な挨拶」：1-RTTハンドシェイクの仕組み

TLS 1.3の標準的なハンドシェイクである 1-RTT（1-Round-Trip Time：往復時間1回） は、この鍵の受け渡しをいかにスマートに行うかの結晶です。

1-RTTの流れ（郵便のやり取りに例えると）

1. あなたからの挨拶（ClientHello）：
「こんにちは！私はこの暗号方式（アルゴリズム）が使えます。あと、これ私の鍵の『半分（公開鍵のパラメータ）』ね！」と手紙を出します。
2. サーバーからの返事（ServerHello + 鍵の確定）：
サーバーは「OK、じゃあその方式でいこう。これが私の鍵の『半分』だよ！」と返事をします。
この瞬間、お互いの手元にある「自分の半分」と「相手の半分」を合わせることで、二人だけの共通の秘密の鍵（セッションキー）が完成します！
3. 通信スタート：
鍵ができたので、その直後から本当のデータ（Webサイトの中身など）のやり取りを暗号化して送ることができます。

「往復1回（行きの便と帰りの便）」のやり取りだけで安全な鍵が作れるため、TLS 1.3の1-RTTは非常にスピーディです。これだけでも十分に速いのですが、エンジニアの探究心はここで終わりませんでした。

「ねえ、2回目以降のアクセスなんだから、毎回の挨拶（往復）すら面倒くさくない？もっと速くできないの？」

そこで登場したのが、今回主役となる0-RTTです。

—

3. 究極のスピード狂「0-RTT」：ノックなしで家に飛び込むリスク

0-RTT（Zero-Round-Trip Time）は、過去に一度そのサーバーと通信したことがあるクライアント（ブラウザなど）が、「往復の挨拶（ハンドシェイク）を完全にゼロにして、最初のデータと一緒に鍵のパラメータも投げつけちゃう」という超ウルトラCの技術です。

0-RTTのイメージ

通常（1-RTT）： 「こんにちは」「こんにちは、鍵これね」 …… （よし、鍵ができた！） …… 「データを送ります」
0-RTT： 「こんにちは！挨拶と鍵の準備は飛ばすけど、これ最初のエンドデータね！！ドーーーン！！」

挨拶の往復すら待たずに、最初のリクエストデータ（Early Data）が飛んでいくため、体感速度は爆速になります。スマホでアプリを開いた瞬間、一瞬で画面が表示されるのはこうした技術の恩恵です。

しかし、セキュリティのプロとして、ここで警鐘を鳴らさなければなりません。
「便利さの裏には、必ずリスクが潜んでいる」のです。

—

4. 0-RTTが抱える最大の弱点：「リプレイ攻撃」の恐怖

0-RTTの最大の弱点は、「過去の通信をそっくりそのまま悪意ある第三者にコピー＆ペースト（リプレイ）されるリスク」にあります。

泥棒の「合鍵使い回し」の例え

あなたがホテルの自動チェックイン機（サーバー）の前にいます。
あなたは過去に一度ホテルに泊まったことがあり、スマホの中に「ドアを開けるための暗号データ（チケット）」が入っています。

0-RTTの世界では、あなたはホテルのドアに向かって、「ノックも挨拶もなしで、その暗号データを投げつけて即座にドアを開けさせる」ことができます。

ここで、もしあなたとホテルの通信を、物陰に隠れた悪意あるハッカー（泥棒）がこっそり録音・録画（傍受）していたらどうなるでしょうか？

ハッカーは、あなたが過去に送信した「0-RTTの初回データ（お金を払うリクエストや、重要なパスワード変更のリクエストなど）」のパケットを丸ごとコピーします。
そして、あなたが寝静まった真夜中に、まったく同じデータをホテルのサーバーに向けて何千回、何万回と一斉に送りつけるのです。

これがリプレイ攻撃（再送攻撃）です。
もしサーバー側が「おっ、いつものデータだね、どうぞ！」と無条件で受け入れてしまったら……何回も同じ決済処理が実行されたり、不正なデータが大量に登録されたりして大惨事になりますよね。

—

5. 現場の防衛策：Anti-Replay（アンチリプレイ）メカニズムを理解する

「じゃあ0-RTTなんて危険だから使わないほうがいいの？」いいえ、正しく対策をすれば強力な武器になります。

サーバー側は、このコピー＆ペースト攻撃を防ぐために、以下のようなAnti-Replay（アンチリプレイ）メカニズムという防衛線を張っています。

1. タイムスタンプの検証：
送られてきたデータに「今この瞬間の時間」が刻まれており、あまりにも古いデータ（例えば数秒以上前）は問答無用でゴミ箱行きにします。
2. 一度きりの使い捨てチケット（Nonce / トークン管理）：
サーバーは、クライアントに渡した「0-RTT用のチケット」が使われたかどうかをデータベースやメモリ上で厳しく管理します。「一度使われたチケットは二度と使えない（1回限り）」というルールを徹底するのです。

—

6. 実務で役立つ設定・実装のヒント

実際のインフラ構築（例えば、NginxやApache、あるいはWebアプリケーションサーバー）でTLS 1.3や0-RTTを扱う際の設定の考え方を見てみましょう。

セキュリティの鉄則として、「安全性が完全に担保できない書き込み系の処理（POSTメソッドなど）には、0-RTTのEarly Dataを絶対に許可しない」という設定が求められます。

以下に、Nginxを例にした設定のイメージと解説を記載します。

# NginxにおけるTLS設定のサンプル

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

    # 最新のTLS 1.3を有効化する（TLS 1.2以下はレガシーなので注意）
    ssl_protocols TLSv1.3;

    # 【重要】0-RTT（early_data）の有効化
    # 速度向上と引き換えにリプレイ攻撃のリスクが生じるため、
    # アプリケーションの特性（読み取り専用か、書き込みを伴うか）を考慮して慎重に判断します。
    ssl_early_data on;

    location / {
        proxy_pass http://backend_servers;

        # バックエンドのアプリケーションサーバーへ「これは0-RTTのデータだよ」という文脈を伝える
        proxy_set_header X-Forwarded-Proto $scheme;
        
        # ※注意: 決済やデータ更新（POST）を行うエンドポイントでは、
        # アプリケーション側で重複リクエスト（べき等性）のチェックや、
        # 0-RTTデータの受け入れを拒否するミドルウェアの導入が必須です。
    }
}

開発者が意識すべきポイント

アプリケーション側（Node.js, Python, Ruby, PHPなど）を開発する際も、フレームワークレベルで「安全ではないリクエスト（POST, PUT, DELETEなど）」が0-RTT経由で飛んできた場合にどう弾くか、あるいはフレームワークがどのようにリプレイを防いでいるかのミドルウェア仕様を確認しておくことが、プロとしての腕の見せ所になります。

—

まとめ

いかがでしたでしょうか？今回のポイントを最後にサクッと振り返ってみましょう。

TLS 1.3の1-RTTハンドシェイクは、往復1回で安全かつ高速に共通の鍵を作る優れた仕組み。
さらに高速な0-RTTは、挨拶なしで初回データも一緒に送るため爆速だが、リプレイ攻撃（データのコピー＆ペースト）の危険が伴う。
安全に運用するためには、サーバー側のAnti-Replayメカニズム（タイムスタンプやチケットの使い捨て管理）と、アプリケーション側での適切なリクエスト制御が不可欠。

セキュリティは「速さ（利便性）」と「堅牢性（安全性）」の絶妙なバランスの上に成り立っています。
「おっ、この技術は速くて便利そうだな」と思った時こそ、「待てよ、裏で泥棒に真似される隙はないか？」と一歩立ち止まれるエンジニアを目指していきましょう！

一歩ずつ、確実に知識を身につけていけば大丈夫です。これからも一緒にセキュリティの旅を楽しんでいきましょうね！