TLSハンドシェイクの仕組みをステップごとに解説

ブラウザに表示される鍵マークの裏では、実際のデータが送られる前にほんの一瞬でハンドシェイクという事前交渉が行われています。

HTTPSとTLSの関係

HTTPSは、通常のHTTP通信をTLS(Transport Layer Security)で暗号化したものです。ブラウザとサーバーは実際のデータをやり取りする前に、TLSハンドシェイクと呼ばれる事前交渉を行い、暗号化に使う鍵を安全に取り決めます。

ステップ1: ClientHello

ブラウザがまず、自分が対応しているTLSのバージョンや暗号スイート(暗号化方式)の一覧、ランダムな値を含むClientHelloメッセージをサーバーに送り、接続を提案します。

ステップ2: ServerHelloと証明書の提示

サーバーは提案された方式の中から一つを選んでServerHelloで応答し、自分が信頼できるサイトであることを証明するSSL/TLS証明書を併せて送ります。

ステップ3: 鍵交換とセッション鍵の生成

ブラウザは証明書を検証した後、公開鍵暗号方式を使って安全に値をやり取りし、以降の通信に使う共通鍵であるセッション鍵をサーバーと一緒に計算して作り出します。

ステップ4: Finishedと暗号化通信の開始

双方はこれまでやり取りした情報が途中で改ざんされていないかを確認するFinishedメッセージを交換します。これ以降のすべてのデータは、先ほど作成したセッション鍵で暗号化してやり取りされます。

TLS 1.3で速くなった点

以前のバージョンであるTLS 1.2はハンドシェイクに往復2回(2-RTT)が必要でしたが、TLS 1.3は交渉の段階を減らして往復1回(1-RTT)で完了でき、再接続時には0-RTTでさらに速く接続できます。

なぜハンドシェイクはデータの読み込みより先に行われるのか

この一連の交渉は、ブラウザが実際のウェブページをリクエストするより前に行われるため、証明書の期限切れや対応していない暗号スイート、ネットワークの問題などでハンドシェイクが遅い、または失敗すると、サーバー自体は正常に動いていてもサイトが表示されないことがあります。ブラウザに表示される「この接続は保護されていません」といった警告は、ほとんどの場合ページの内容ではなくハンドシェイクの段階で起きた問題です。

1回のハンドシェイクに使われる公開鍵暗号と共通鍵暗号

ハンドシェイクでは実は2種類の暗号技術が異なる役割のために使われています。最初の秘密の値を誰にも盗聴されずに安全にやり取りするには、遅いが安全性の高い公開鍵暗号方式を使い、その後の実際のデータ転送には、そこで作られたセッション鍵を使った高速な共通鍵暗号方式を使います。通常のウェブセッションで扱う大量のデータには、共通鍵暗号の方がはるかに効率的だからです。

よくある質問

TLS 1.3はなぜTLS 1.2より往復回数が少ないのですか?

TLS 1.3は、クライアントが最初から特定の鍵交換方式を提案する形にハンドシェイクを簡略化し、サーバーがハンドシェイクを完了するために必要な情報をまとめて一度に返せるようにしたことで、往復2回だったものを1回で済ませられるようにしました。

ハンドシェイクが速くなると、実際にページの読み込み速度に体感できる違いはありますか?

はい、特にモバイル回線のような遅延の大きい接続では顕著です。1回の往復には数十〜数百ミリ秒かかることもあるため、ハンドシェイクを2回から1回(再接続時は0回)に減らすことは、安全なページの表示が始まるまでの時間を目に見えて短縮します。