#ハンドシェイク（TLS1.3,ServerHello,証明書..）を9秒で理解！

はじめに

基本知識

TLS 1.3のハンドシェイクプロセスは、インターネット上で安全な通信を行うための準備プロセスです。このプロセスでは、クライアントとサーバーが通信するための暗号化情報を交換し、お互いが信頼できる相手であることを確認します。以下では、TLS 1.3のハンドシェイクの流れと各メッセージの役割について、具体的に解説します。

TLS 1.3 ハンドシェイクの目的

TLSハンドシェイクの主な目的は以下の2つです：

1. 暗号鍵の共有：通信内容を暗号化するための共通鍵をクライアントとサーバーで安全に生成・共有する。
2. 相手の認証：サーバーが正当な通信相手であることをクライアントが確認する。また、クライアント証明書が要求される場合は、クライアントも認証される。

TLS 1.3ハンドシェイクの流れ

1.ClientHello（クライアント→サーバー）

クライアントが接続要求を送ります。ClientHelloメッセージには以下の情報が含まれます：

• サポートする暗号スイートのリスト：クライアントが使用可能な暗号化方式（例：AES, ChaCha20, SHA256など）。
• サポートするTLSのバージョン：TLS 1.3を含む、クライアントが対応しているTLSバージョン。
• クライアントのランダム値：暗号鍵生成に必要な乱数。
• 鍵交換パラメータ：鍵交換方式（通常はECDHE）に基づく公開鍵情報。

2.ServerHello（サーバー→クライアント）

サーバーがClientHelloに応答し、以下の情報をクライアントに送ります：

• 選択した暗号スイート：クライアントが提案した暗号スイートの中からサーバーが選んだもの。

• サーバーのランダム値：クライアントのランダム値と組み合わせて暗号鍵を生成するための乱数。

• 鍵交換パラメータ：サーバー側の鍵交換に必要な公開鍵情報。

3.EncryptedExtensions（サーバー→クライアント）

このメッセージには、追加の拡張機能・プロトコル機能に関する情報が含まれます。たとえば、セッション再開に関するオプションや、サーバー側がサポートする特定の拡張機能に関する情報が含まれます。

4.Certificate Request（サーバー→クライアント）[オプション]

サーバーがクライアント証明書を要求する場合に、このメッセージを送ります。クライアントの認証が必要な場面（例えば、企業内のVPN接続など）で使用されますが、通常のウェブサイトでは省略されることが多いです。

5.Certificate（サーバー→クライアント）

サーバーは自身の公開鍵証明書をクライアントに送信します。公開鍵証明書には、以下が含まれます：

• サーバーの公開鍵。
• サーバーのドメイン名などの識別情報。
• 信頼された第三者機関（CA：Certificate Authority）の署名。CAが署名することで、その公開鍵が正当であることが保証されます。

6.CertificateVerify（サーバー→クライアント）

サーバーが送信した公開鍵証明書に対し、自分がその秘密鍵の正当な所有者であることを証明するために、サーバーは自身の秘密鍵で署名を行います。このメッセージの役割は、サーバーが証明書に対応する秘密鍵を確実に持っていることをクライアントに保証することです。

7.Finished（サーバー→クライアント）

サーバーがハンドシェイクを完了したことを示すメッセージです。HMAC（ハッシュベースのメッセージ認証コード）を使って、ここまでのハンドシェイクが改ざんされていないことを確認します。このメッセージを受け取ることで、クライアントはサーバーとのハンドシェイクが正常に完了したことを確認し、安全な通信が開始されます。

8.Certificate（クライアント→サーバー）[オプション]

サーバーがクライアント証明書を要求していた場合、クライアントは自身の証明書を送信します。ほとんどのウェブサイトではクライアント証明書は必要ありませんが、企業の内部システムなどでは使用されることがあります。

9.CertificateVerify（クライアント→サーバー）[オプション]

クライアントが送信した証明書に対して、クライアントは自身の秘密鍵で署名を行い、正当な持ち主であることを証明します。

10.Finished（クライアント→サーバー）

クライアントがハンドシェイクを完了したことをサーバーに通知します。サーバーと同様、HMACを使ってこれまでのハンドシェイクが改ざんされていないことを確認します。これにより、双方向のハンドシェイクが完了し、暗号化された通信が行われる準備が整います。

証明書（公開鍵証明書）の役割と必要性

CA（Certificate Authority）：

CAは信頼された第三者機関であり、サーバーの公開鍵に署名を行い、その公開鍵が正当なものであることを証明します。クライアントはCAの公開鍵を使用して、サーバーの公開鍵証明書が信頼できるかどうかを確認します。これにより、サーバーが悪意ある攻撃者に成り代わられていないことを保証します。

• なりすましの防止： クライアントが正当なサーバーと通信しているかどうかは、この公開鍵証明書によって確認されます。証明書がない場合、クライアントは公開鍵が偽装されたものであるかどうかを判別する手段がなくなり、攻撃者による「中間者攻撃」にさらされるリスクが高まります。

まとめ

要するに…

TLS 1.3のハンドシェイクは、インターネット上で安全な通信を確立するための手順であり、その主な目的は暗号鍵を共有し、通信相手を認証することです。従来のTLS 1.2と比べて、TLS 1.3ではセキュリティが強化され、プロセスも簡略化されています。TLS 1.3のハンドシェイクは、クライアントとサーバーの間で暗号化された通信を開始するために、双方が共通の暗号鍵を生成し、通信相手の正当性を確認する手順を踏むものです。

このハンドシェイクの最初のステップとして、クライアントは「ClientHello」というメッセージをサーバーに送信します。このメッセージには、クライアントがサポートしている暗号スイート（暗号方式のリスト）、使用可能なTLSのバージョン、クライアント側のランダム値、そして鍵交換のためのパラメータが含まれています。次に、サーバーは「ServerHello」というメッセージをクライアントに送信し、ここでサーバーが選択した暗号スイート、サーバーのランダム値、鍵交換用のパラメータが返されます。この時点で、クライアントとサーバーの間で暗号化通信を開始するための鍵交換が完了するため、TLS 1.3ではServerHelloの直後から通信が暗号化されます。

次に、サーバーからクライアントに「Encrypted Extensions」というメッセージが送信され、これには追加の拡張情報が含まれます。また、サーバーが必要であれば、クライアントに対して「Certificate Request」メッセージを送り、クライアント証明書を要求する場合があります。これはオプションであり、特定のセキュリティ要件がある場合にのみ使用されます。サーバーはさらに、「Certificate」というメッセージをクライアントに送信し、自身の公開鍵証明書を提示します。公開鍵証明書は、サーバーの公開鍵が信頼できる第三者（認証局）によって発行されており、そのサーバーが実際に主張している団体や企業であることを証明するものです。次に、サーバーは「Certificate Verify」メッセージを送り、サーバーが自身の秘密鍵を使って過去のハンドシェイクメッセージに署名し、正当な通信相手であることを証明します。その後、サーバーは「Finished」メッセージを送信し、ここまでのハンドシェイクが改ざんされずに正常に行われたことを確認します。

サーバーがクライアント証明書を要求していた場合、クライアントは自身の公開鍵証明書を「Certificate」メッセージとして送信し、続けて「Certificate Verify」メッセージを送って秘密鍵で署名を行い、自身が正当なクライアントであることを証明します。最終的に、クライアントも「Finished」メッセージをサーバーに送信し、ハンドシェイクが完了します。

TLS 1.3のハンドシェイクにおける重要な要素の一つは、公開鍵証明書です。公開鍵証明書は、単に公開鍵と秘密鍵のペアを持っているだけでは防ぐことのできない「なりすまし」を防止するために使用されます。公開鍵自体は公開されており、誰でも「この公開鍵は自分のものだ」と主張できてしまうため、その公開鍵の持ち主が本当に信頼できる団体や企業であるかを確認する必要があります。ここで、信頼できる第三者である認証局（CA）が介入し、公開鍵証明書を発行します。認証局は、その公開鍵が実際に正当な持ち主によるものであることを確認し、その企業や団体が存在していることを保証します。この証明書があることで、クライアントは通信相手であるサーバーが本当に信頼できる存在であることを確認し、安全に通信を開始することができます。

TLS 1.3では、従来のTLS 1.2に比べて、ハンドシェイクのプロセスがより効率的になり、暗号化が早期に開始されるため、セキュリティが強化され、通信のパフォーマンスも向上しています。また、不要な暗号方式が廃止され、現代の暗号技術に対応したより安全な通信プロトコルとなっています。

おわりに