はじめに
「SSLネゴシエーションって、接続するときに何をやり取りしているの？」
「TLS 1.2とTLS 1.3では通信の流れがどう違うの？」と疑問に感じていませんか。
Webサーバーの設定や通信エラーを確認していると、ClientHelloやServerHello、証明書といった言葉が並び、どの順番で暗号化通信が始まるのか分からず迷うことがありますよね。
この記事では、SSLネゴシエーションの仕組みと通信開始までの流れ、TLS 1.2とTLS 1.3で手順がどう変わるのかをわかりやすく解説します。
SSLネゴシエーションとは？
SSLネゴシエーションとは、クライアントとサーバーが暗号化通信を始める前に、通信に必要な条件を確認するやり取りです。
ここでは、SSLネゴシエーションの役割と、やり取りの中で決まる主な通信条件を順番に説明します。
SSLネゴシエーションは安全な通信を始めるためのやり取り
SSLネゴシエーションは、クライアントとサーバーが暗号化通信を始める前に、必要な条件を確認するやり取りです。
接続時にTLSのバージョンや暗号方式を確認し、サーバー証明書を使って接続先を検証します。
さらに暗号化に必要な鍵を確立し、準備が整うと安全な通信が始まります。
ネゴシエーションで決まる主な通信条件
SSLネゴシエーションでは、クライアントとサーバーの双方が対応しているTLSのバージョンや暗号方式を確認し、実際に使用する条件を決めます。
たとえば、双方が対応しているTLS 1.2やTLS 1.3などから、利用できるバージョンと暗号方式を選びます。
対応する条件が一致しない場合はネゴシエーションが完了せず、暗号化通信を開始できません。
SSLネゴシエーションの流れを順番に解説
SSLネゴシエーションでは、クライアントとサーバーが複数のメッセージを交換し、暗号化通信を始めるための準備を進めます。
まずClient Helloで対応可能なTLSバージョンなどを提示し、Server Helloで実際に使用する通信条件を決めます。その後、証明書によるサーバーの確認と鍵交換を行い、暗号化通信に必要な鍵を確立します。
最後にFinishedで一連のやり取りを確認し、問題がなければ暗号化されたデータ通信を開始します。
Client Helloで対応するTLSバージョンなどを提示する
SSLネゴシエーションは、クライアントがサーバーへClient Helloを送るところから始まります。
Client Helloには、対応しているTLSバージョンや暗号方式の候補などが含まれており、サーバーは自身が対応する条件と照合します。
ここで提示された情報をもとに、その後の通信で使用する条件が選ばれます。
Server Helloで使用する通信条件を決定する
サーバーはClient Helloを確認すると、Server Helloをクライアントへ返します。
双方が対応しているTLSバージョンや暗号方式から、実際の通信で使用する条件が選ばれます。
利用できる条件が一致しない場合は、ネゴシエーションを続けることができません。
証明書でサーバーの正当性を確認する
サーバーから証明書が送られると、クライアントは接続先が正しいサーバーかを確認します。
証明書の有効期限やホスト名、認証局による署名などを検証し、問題がなければ処理を続けます。
検証に失敗すると、ブラウザに証明書エラーが表示されたり、接続が中止されたりします。
鍵交換によって暗号化通信に使う鍵を確立する
クライアントとサーバーは鍵交換を行い、暗号化通信に必要な鍵を確立します。
TLS 1.2では暗号スイートによって鍵交換方式が異なり、TLS 1.3では主にECDHEを使って共有秘密を生成します。
双方はこの共有秘密をもとに、通信データの暗号化に使用する鍵を生成します。
Finishedで確認して暗号化通信を開始する
最後にFinishedメッセージを使い、それまでのハンドシェイクに問題がないことを双方で確認します。
検証に成功するとSSLネゴシエーションが完了し、確立した鍵を使った暗号化通信へ移ります。
その後は、HTTPなどのデータが暗号化された状態で送受信されます。
TLS 1.2とTLS 1.3のネゴシエーションの違い
TLS 1.2とTLS 1.3では、暗号化通信を開始するまでに必要なメッセージ交換の流れが異なります。
ここでは、それぞれのネゴシエーションの流れと違いを順番に説明します。
TLS 1.2は複数のやり取りで通信条件を確立する
TLS 1.2では、クライアントとサーバーが複数回メッセージを交換して通信条件を決めます。
Client HelloとServer HelloでTLSバージョンや暗号スイートを決めたあと、証明書の確認や鍵交換を行います。
最後にFinishedメッセージを交換し、準備が整うと暗号化通信が始まります。
TLS 1.3はやり取りを減らして接続を高速化している
TLS 1.3では、Client Helloで鍵交換に必要な情報も送ることで、ハンドシェイクのやり取りを減らしています。
新規接続は基本的に1往復の1-RTTで完了するため、TLS 1.2より早く暗号化通信を始められます。
さらに、再接続では条件を満たすと0-RTTでデータを送信でき、接続開始までの待ち時間を短縮できます。
SSLネゴシエーションで問題が起きる主な原因
SSLネゴシエーションに失敗すると、クライアントとサーバーの間で暗号化通信を開始できず、接続エラーが発生します。
ここでは、SSLネゴシエーションで問題が起きる主な原因を順番に説明します。
TLSバージョンや暗号スイートが対応していない
クライアントとサーバーで共通して使えるTLSバージョンや暗号スイートがないと、SSLネゴシエーションは失敗します。
たとえば、サーバーがTLS 1.2以上に対応していても、クライアントがTLS 1.0までしか対応していなければ接続できません。
TLS 1.2では、双方が利用できる暗号スイートがない場合もハンドシェイクを完了できません。
サーバー証明書の検証に失敗している
サーバー証明書を正常に検証できない場合も、SSLネゴシエーションに失敗することがあります。
証明書の有効期限切れやホスト名の不一致、証明書チェーンの不備などが主な原因です。
検証に問題があると証明書エラーが発生し、安全な接続を続けられない場合があります。
証明書の有効期限やホスト名だけでなく、証明書そのものが正しく検証できない原因を詳しく確認したい場合はこちらも参考にしてください。
▶Failed SSL Validationが発生する原因とは？SSL証明書の検証エラーと対処法
クライアントとサーバーの設定が一致していない
TLSの設定を変更したことで、クライアントとサーバーの通信条件が合わなくなる場合もあります。
たとえば、サーバー側でTLS 1.3だけを有効にし、クライアント側がTLS 1.2までしか使えない設定では接続できません。
設定変更後にエラーが発生した場合は、双方で有効になっているTLSバージョンや暗号方式を確認してみましょう。
TLSの設定を確認しても原因が分からない場合は、SSLハンドシェイクが失敗する原因を整理して確認してみましょう。
▶SSL Handshake failedとは？SSLハンドシェイクに失敗する原因と対処法
まとめ
SSLネゴシエーションは、クライアントとサーバーが暗号化通信を始める前に、TLSバージョンや暗号方式を確認し、証明書の検証や鍵の確立を行うやり取りです。
Client HelloからServer Hello、証明書の確認、鍵交換、Finishedまで進み、問題がなければ暗号化されたデータ通信が開始されます。
TLS 1.2では複数回のメッセージ交換が必要ですが、TLS 1.3では新規接続を基本1-RTTで完了できるよう手順が短縮されています。
接続できない場合は、TLSバージョンや暗号スイート、サーバー証明書、クライアントとサーバー双方のTLS設定を確認すると、ネゴシエーションが失敗している原因を切り分けやすくなります。
