TLSハンドシェイクとは?
著者: Yunes Tarada
翻訳: 永 香奈子
この記事はPowerDMARCのブログ記事 What Is a TLS Handshake? Process and Importance の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。
主なポイント
- TLSハンドシェイクは、クライアントとサーバの間で安全な通信を確立するために不可欠な仕組みです。
- TLSハンドシェイクでは、クライアントとサーバが複数のメッセージを交換し、使用するTLSバージョンや暗号方式を決定します。
- TLS証明書は、ハンドシェイク時にサーバの正当性を確認するために重要な役割を果たします。
- TLS 1.3では、ハンドシェイク処理が簡素化され、セキュリティとパフォーマンスが向上しています。
- TLSは、機密情報を盗聴や改竄から保護するため、個人データを扱う企業やWebアプリケーションにとって欠かせない技術です。
TLSハンドシェイクは、安全なオンライン通信を実現するために最初に行われる重要なプロセスです。
HTTPSを使用するWebサイトへアクセスするたびに、通信の機密性と信頼性を確保するため、バックグラウンドでTLSハンドシェイクが実行されます。
TLSハンドシェイクでは、公開鍵暗号方式などを利用して安全な接続に必要な鍵を確立し、サーバの正当性を確認します。
これにより、インターネット上で送受信されるデータを保護するための基盤が構築されます。
この処理がなければ、ログイン認証情報、決済情報、個人データなどの機密情報が、攻撃者に盗聴されたり改竄されたりする可能性があります。
金融、医療、政府機関などの規制対象業界では、TLSハンドシェイクの失敗が、コンプライアンス違反、監査上の指摘、重大な業務中断につながる場合があります。
本記事では、TLSハンドシェイクの仕組みや各ステップ、暗号化・認証・安全な通信に不可欠である理由について詳しく解説します。
TLSハンドシェイクとは?
TLSハンドシェイクとは、データの送受信を始める前に、クライアントとサーバの間で暗号化された安全な接続を確立するプロセスです。
クライアントにはWebブラウザやメールクライアント、アプリケーションなどが該当します。
TLSハンドシェイクでは、クライアントとサーバが、使用するTLSバージョンや暗号スイートに合意し、サーバの正当性を確認したうえで、安全な通信に使用するセッション鍵を生成します。
このプロセスにより、パスワード、決済情報、個人データなどの機密情報が、盗聴や改竄から保護されます。
TLSハンドシェイクは、HTTPS通信を支える重要な仕組みです。
Webサイト、アプリケーション、API、メール通信において、認証、データの機密性、完全性を維持するために欠かせません。
TLSハンドシェイクの主な用語
以下の基本用語を理解しておくと、TLSハンドシェイクの仕組みを把握しやすくなります。
- 暗号スイート(Cipher Suite)
- TLS通信で使用する暗号化方式や鍵交換方式、認証方式などの組み合わせです。
- 共通鍵暗号方式(Symmetric Encryption)
- 暗号化と復号に同じ鍵を使用する方式です。
処理が高速なため、TLSハンドシェイク完了後のデータ通信に使用されます。 - 公開鍵暗号方式(Asymmetric Encryption)
- 公開鍵と秘密鍵という異なる鍵を使用する暗号方式です。
主にサーバの認証や、鍵交換を安全に行うために利用されます。 - 鍵交換(Key Exchange)
- クライアントとサーバが、安全な通信に必要な共有情報を確立するための処理です。
- 認証(Authentication)
- 通信相手が正当な相手であることを確認する処理です。
一般的なHTTPS通信ではサーバを認証し、必要に応じてクライアントも認証します。 - セッション鍵(Session Key)
- TLSハンドシェイク後の通信内容を暗号化・復号するために使用される共通鍵です。
- TLS-RPT
- メール通信におけるTLS接続の失敗や暗号化に関する問題を可視化するためのレポート機能です。
TLSハンドシェイクの仕組み
TLSハンドシェイクは、WebサイトやアプリケーションのサーバにTLS証明書が設定されている場合に実行されます。
TLS証明書には、証明書の対象となるドメイン名、発行元、公開鍵、有効期限などの情報が含まれています。
ユーザがTLS対応のWebサイトへアクセスすると、クライアントとサーバの間でTLSハンドシェイクが始まります。
その過程では、主に以下の処理が行われます。
- 使用するTLSバージョンの確認
- 使用する暗号スイートの選択
- TLS証明書によるサーバの認証
- 鍵交換
- セッション鍵の生成
TLSハンドシェイクが完了すると、クライアントとサーバの双方で、以降の通信を暗号化するためのセッション鍵が生成されます。
暗号スイートとは、安全な通信を確立するために使用する暗号アルゴリズムの組み合わせです。
TLS 1.2までの暗号スイートには、鍵交換方式、認証方式、共通鍵暗号方式、メッセージ認証方式などが含まれていました。
TLS 1.3では構成が整理され、鍵交換方式や署名方式が暗号スイートから分離されています。
TLSでは、公開鍵暗号方式やDiffie-Hellman鍵交換などを利用し、第三者に共有情報を知られることなく、クライアントとサーバの間で同じセッション鍵を生成します。
また、サーバ証明書に含まれる公開鍵や署名情報を利用することで、接続先のサーバが正当なものであるかを確認します。
公開鍵暗号方式では、公開鍵と秘密鍵が対になっています。
秘密鍵はサーバ側で厳重に管理され、証明書に含まれる公開鍵やデジタル署名を通じて、サーバの正当性を確認します。
TLSハンドシェイクに失敗すると、安全な接続を確立できず、ブラウザやアプリケーションにSSL/TLS関連のエラーが表示される場合があります。
PowerDMARCのTLS-RPT監視を利用すると、メール通信におけるTLS接続の失敗を把握し、問題の早期発見や解決に役立てることができます。
TLSとSSLの違い
SSLは「Secure Sockets Layer」の略で、暗号化通信を実現するために開発された初期のプロトコルです。
その後、SSLの後継としてTLSが登場しました。
現在、SSL 2.0およびSSL 3.0は安全性の問題から使用が推奨されておらず、実際の通信ではTLSが利用されています。
現在でも「SSL証明書」や「SSL通信」という表現が一般的に使われていますが、多くの場合、実際にはTLSを指しています。
TLSはSSLと比べて、より高いセキュリティ、優れたパフォーマンス、強力な暗号方式を提供します。
現在のブラウザやセキュリティ基準では、安全な通信を実現し、PCI DSSなどの要件へ対応するために、TLS 1.2またはTLS 1.3の利用が推奨されています。
TLSハンドシェイクはいつ行われるのか
TLSハンドシェイクは、クライアントがTLSを使用するサーバとの安全な通信を開始する際に実行されます。
代表的な例は、ブラウザからHTTPS対応のWebサイトへアクセスする場合です。
このほかにも、以下のような場面でTLSハンドシェイクが行われます。
- HTTPSを使用するAPI通信
- メールサーバ間のTLS通信
- VPNや各種クラウドサービスへの接続
- TLSで保護されたアプリケーション通信
- DNS over TLSなどの暗号化DNS通信
複数の顧客環境を管理するMSPにとって、TLSハンドシェイクがいつ行われるかを理解しておくことは、管理対象システムのセキュリティ監視やトラブルシューティングを効率化するうえで役立ちます。
それでは、クライアントとサーバの間で交換されるメッセージの流れを詳しく見ていきましょう。
TLSハンドシェイクのステップ
TLSハンドシェイクは、クライアントとサーバの間で交換される複数のメッセージで構成されます。
具体的な流れは、使用するTLSバージョン、鍵交換方式、暗号スイートによって異なります。
ここでは、一般的な流れを説明します。
ステップ1:Client Helloメッセージ
クライアントは、サーバへClient Helloメッセージを送信し、TLSハンドシェイクを開始します。
このメッセージには、主に以下の情報が含まれます。
- クライアントが対応しているTLSバージョン
- 対応している暗号スイート
- Client Randomと呼ばれるランダム値
- 対応している拡張機能
- TLS 1.3では鍵交換に使用する情報
ステップ2:Server Helloメッセージ
サーバは、Client Helloの内容を確認し、Server Helloメッセージを返します。
このメッセージには、主に以下の情報が含まれます。
- 選択したTLSバージョン
- 選択した暗号スイート
- Server Randomと呼ばれるランダム値
- 鍵交換に必要な情報
さらに、サーバは自身の正当性を証明するために、サーバ証明書をクライアントへ送信します。
ステップ3:認証と鍵交換
クライアントは、サーバから受け取った証明書を確認します。
主な確認項目は以下のとおりです。
- 信頼できる認証局によって発行されているか
- 証明書の有効期限が切れていないか
- 接続先のドメイン名と証明書の対象が一致しているか
- 証明書チェーンが正しく検証できるか
- 証明書が失効していないか
証明書が有効であれば、鍵交換処理を続行します。
鍵交換の方法は、TLSバージョンや暗号スイートによって異なります。
TLS 1.2ではRSA鍵交換やDiffie-Hellman、ECDHEなどが利用される場合があります。
TLS 1.3では、前方秘匿性を確保するため、主に一時的なDiffie-Hellman方式が使用されます。
この鍵交換により、クライアントとサーバは、安全な通信に必要な共有シークレットを生成します。
ステップ4:セッション鍵の確立
クライアントとサーバは、共有シークレットやハンドシェイク中に交換した情報をもとに、それぞれ同一のセッション鍵を生成します。
このセッション鍵は、以降の通信内容を暗号化・復号するために使用されます。
最後に、クライアントとサーバは、ハンドシェイクが正常に完了したことを確認するメッセージを交換します。
これで、安全な暗号化通信が開始されます。
TLS 1.2とTLS 1.3の違い
TLS 1.3は、TLS 1.2と比べてハンドシェイク処理が簡素化され、セキュリティとパフォーマンスが向上しています。
主な違いは以下のとおりです。
| 項目 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| 通常のハンドシェイク | 2往復 | 1往復 |
| 暗号スイート | 多数の方式に対応 | 安全性の高い方式に限定 |
| 前方秘匿性 | 使用する方式によって異なる | 必須 |
| 0-RTT | 非対応 | セッション再開時に対応 |
| 脆弱な暗号方式 | 一部利用可能 | 削除 |
| ハンドシェイクの暗号化 | 一部のみ | より広い範囲を暗号化 |
TLS 1.3の主なメリット
- 通信の高速化
- ハンドシェイクに必要な往復回数が減り、接続確立までの時間が短縮されます。
- セキュリティの強化
- 脆弱性が知られている古い暗号方式や鍵交換方式が削除されています。
- プライバシの向上
- ハンドシェイク中に暗号化される情報の範囲が拡大しています。
- 前方秘匿性の確保
- 将来サーバの秘密鍵が漏洩した場合でも、過去の通信内容を復号されにくい設計になっています。
- 最新要件への対応
- 現代のセキュリティ要件やブラウザ環境へ対応しやすくなっています。
なお、0-RTTは通信を高速化できる一方で、リプレイ攻撃への対策が必要です。
そのため、利用するデータや処理内容を慎重に検討する必要があります。
TLSハンドシェイクが重要な理由
TLSハンドシェイクは、安全なオンライン通信の基盤となる仕組みです。
接続開始時に暗号化方式やセッション鍵を確立することで、通信内容を第三者による盗聴や改竄から保護します。
また、サーバ証明書を検証することで、ユーザが接続しようとしているWebサイトやサービスが正当なものであるかを確認できます。
これにより、ユーザとWebサイトの間に信頼できる通信経路が構築されます。
ECサイト、オンラインバンキング、医療サービスなどでは、決済情報、ログイン認証情報、個人情報などの重要なデータが送受信されます。
TLSハンドシェイクが正しく行われなければ、こうした情報を安全に取り扱うことはできません。
現在の安全なWeb閲覧、オンラインショッピング、デジタルバンキング、クラウドサービスは、TLSハンドシェイクによって支えられています。
PowerDMARCでTLSを管理するメリット
PowerDMARCでは、DMARC、SPF、DKIM、TLS-RPT、MTA-STSなどのメールセキュリティ機能を一元的に管理できます。
主なメリットは以下のとおりです。
- DMARC、SPF、DKIM、TLS-RPT、MTA-STSの一元管理
- TLS-RPTレポートの可視化
- TLS接続失敗に関する問題の把握
- 自動化されたコンプライアンスチェック
- 監査に活用できるレポート
- リアルタイムアラート
- 複数ドメインの一元的な可視化
- 24時間365日のグローバルサポート
- AWSおよびAzure Marketplaceからの導入
手動でTLSを監視する場合、複数のドメインやサービスにまたがる問題を一元的に把握することは容易ではありません。
PowerDMARCを利用することで、メール通信におけるTLSの状況や問題を効率的に確認できます。
TLSハンドシェイクでよくある問題とトラブルシューティング
TLSハンドシェイクは通常、自動的に短時間で完了します。
しかし、証明書やTLS設定に問題があると、安全な接続を確立できない場合があります。
TLSハンドシェイクでよくある問題
| 問題 | 主な症状 | 対処方法 |
|---|---|---|
| 証明書の有効期限切れ | ブラウザに証明書警告が表示される | 有効な証明書へ更新する |
| ドメイン名の不一致 | 証明書エラーが表示される | 正しいドメインを含む証明書を設定する |
| 証明書チェーンの不備 | 一部の端末やブラウザで接続できない | 中間証明書を正しく設定する |
| 暗号スイートの不一致 | ハンドシェイクに失敗する | クライアントとサーバの双方が対応する暗号スイートを有効にする |
| TLSバージョンの不一致 | 互換性エラーが発生する | TLS 1.2またはTLS 1.3への対応を有効にする |
| 証明書の失効 | 接続が拒否される場合がある | 証明書の状態を確認し、必要に応じて再発行する |
| サーバ時刻のずれ | 証明書が無効と判定される | サーバの時刻同期を確認する |
| SNI設定の問題 | 別の証明書が返される | 仮想ホストとSNI設定を確認する |
トラブルシューティングのチェックリスト
□証明書の有効期限を確認する
□証明書の対象ドメインを確認する
□証明書チェーンが正しく構成されているか確認する
□クライアントとサーバが対応しているTLSバージョンを確認する
□暗号スイートの互換性を確認する
□サーバの日時が正しいか確認する
□サーバログでハンドシェイクエラーを確認する
□MTA-STSポリシーの設定を確認する
□TLS-RPTレポートを確認し、失敗の傾向を把握する
□ファイアウォールやプロキシがTLS通信を妨げていないか確認する
まとめ
TLSハンドシェイクは、インターネット上で安全な通信を実現するための重要なプロセスです。
一般のユーザからは見えませんが、通信に使用する暗号方式の決定、サーバの認証、セッション鍵の生成を行い、機密データを盗聴や改竄から保護しています。
Webサイトへの安全なログイン、オンラインショッピング、銀行取引、クラウドサービスの利用などは、すべてTLSハンドシェイクによって支えられています。
規制対象業界の企業にとって、適切なTLS設定と監視は、PCI DSS、HIPAA、GDPRなどの要件へ対応するうえでも重要です。
TLSハンドシェイクや暗号化通信に問題が発生すると、サービス停止や監査上の指摘、コンプライアンス上の問題につながる可能性があります。
PowerDMARCの統合プラットフォームを利用すると、メール通信におけるTLS-RPTレポートの一元管理、TLS接続失敗の把握、コンプライアンス確認、24時間365日のサポートを活用できます。
よくある質問
- TLSハンドシェイクの4つのフェーズとは何ですか?
- TLSハンドシェイクは、大きく以下の4つのフェーズに分けられます。
- Client Hello
クライアントが、対応しているTLSバージョンや暗号スイートなどの情報を送信します。 - Server Hello
サーバが、使用するTLSバージョンや暗号スイートを選択し、証明書などを返します。 - 認証と鍵交換
クライアントがサーバ証明書を検証し、双方が鍵交換に必要な情報をやり取りします。 - セッション鍵の確立
クライアントとサーバが同じセッション鍵を生成し、暗号化通信を開始します。
- Client Hello
- ハンドシェイクプロトコルの目的は何ですか?
- TLSハンドシェイクの目的は、通信相手を認証し、使用する暗号方式を決定し、安全な通信に必要なセッション鍵を生成することです。
これにより、その後の通信におけるデータの機密性、完全性、真正性を確保します。 - SSL/TLSハンドシェイクはどのように進行しますか?
- まず、クライアントが対応しているTLSバージョンや暗号スイートを含むClient Helloメッセージを送信します。
次に、サーバがServer Helloメッセージとサーバ証明書を返します。
クライアントは証明書の正当性を確認し、クライアントとサーバの間で鍵交換を行います。
最後に、双方が同一のセッション鍵を生成し、暗号化通信を開始します。 - TLSハンドシェイクはいつ発生しますか?
- TLSハンドシェイクは、安全な通信セッションを開始する際に実行されます。
ブラウザからHTTPS対応のWebサイトへアクセスする場合や、TLSを利用するAPI、メールサーバ、アプリケーションへ接続する場合などに行われます。
実際のデータ交換を始める前に、暗号化と認証を確立します。 - TLSハンドシェイクとSSLハンドシェイクの違いは何ですか?
- SSLはTLSの前身となるプロトコルです。
基本的なハンドシェイクの考え方は似ていますが、TLSの方が安全性と効率性に優れています。
現在でも「SSLハンドシェイク」という言葉が使われることがありますが、現在の安全な通信では主にTLSが使用されています。