TLS・PKI・証明書

TLSハンドシェイクてぃーえるえすはんどしぇいく

TLSSSL暗号化証明書公開鍵暗号セッション鍵

TLSハンドシェイクについて教えて

簡単に言うとこんな感じ！

HTTPS通信が始まるとき、ブラウザとサーバーが「暗号化の方式はこれにしよう」「ちゃんと本物のサーバーだよね？」って確認し合う”挨拶の儀式”だよ！これが終わってはじめて、安全な暗号化通信がスタートするんだ！

TLSハンドシェイクとは

TLS（Transport Layer Security）ハンドシェイクとは、ブラウザ（クライアント）とWebサーバーが安全な暗号化通信を始める前に行う、一連の”事前確認のやりとり”のことです。握手（ハンドシェイク）という名前のとおり、通信の相手が本物かどうかを確認し、どの暗号方式を使うかを取り決め、通信で使うセッション鍵（共通鍵）を安全に共有する、という3つのことを実現します。

私たちが「https://」で始まるURLにアクセスするとき、画面の裏では必ずこのハンドシェイクが行われています。ページが表示されるまでの一瞬の間に、サーバーの身元確認・暗号方式の合意・鍵の共有がすべて完了しているのです。これが成功してはじめて、やり取りするデータが暗号化された状態で送受信されます。

TLSハンドシェイクは、現代のインターネットセキュリティの土台です。オンラインショッピングやネットバンキングなど、機密情報を扱うあらゆるWebサービスで使われており、「鍵のかかった通信路を作る儀式」と理解しておくと実務でも役立ちます。

TLSハンドシェイクの仕組み

TLS 1.3（現在の主流バージョン）のハンドシェイクは、大きく次のステップで進みます。

ステップ	送信者	メッセージ名	内容
①	クライアント	ClientHello	対応する暗号方式のリスト・乱数を送信
②	サーバー	ServerHello	採用する暗号方式・乱数を返信
③	サーバー	Certificate	サーバー証明書（身元証明）を送付
④	サーバー	CertificateVerify	秘密鍵で署名し、証明書の正当性を証明
⑤	サーバー	Finished	ハンドシェイク完了を通知
⑥	クライアント	Finished	確認完了・暗号化通信スタート

「CHello→SHello→証明書→完了」と覚えよう

ハンドシェイクの流れは「C（クライアント）が挨拶→S（サーバー）が挨拶と証明書提示→お互い完了確認」と覚えると整理しやすいです。TLS 1.3ではTLS 1.2と比べてやりとりの往復回数（ラウンドトリップ）が削減され、1-RTT（1往復）で完了するよう設計されています。

TLS 1.2 と TLS 1.3 の比較

項目	TLS 1.2	TLS 1.3
ハンドシェイクの往復数	2-RTT	1-RTT
0-RTT再接続	非対応	対応（Session Ticket利用時）
鍵交換方式	RSA・DHなど複数	ECDHE（前方秘匿性あり）のみ
廃止された暗号方式	MD5・RC4など残存	すべて排除済み
セキュリティ強度	中	高

歴史と背景

1994年：Netscapeが前身のSSL（Secure Sockets Layer）2.0を開発。Webショッピングの普及とともに注目される
1996年：SSL 3.0登場。しかし後に深刻な脆弱性（POODLE攻撃）が発覚
1999年：IETFがSSL 3.0をベースに標準化したTLS 1.0（RFC 2246）を公開。「TLS」という名称に変更
2006年：TLS 1.1（RFC 4346）、2008年：TLS 1.2（RFC 5246）が登場し、暗号の強化が進む
2018年：TLS 1.3（RFC 8446）が策定。ハンドシェイクの高速化と古い暗号方式の一掃を実現
2020年：主要ブラウザがTLS 1.0・1.1のサポートを終了。現在はTLS 1.2・1.3が標準

ハンドシェイクの流れと証明書の役割

TLSハンドシェイクを構成する技術要素は大きく「鍵交換」「認証」「暗号化」の3つです。下図はクライアントとサーバー間のやりとりと、証明書が果たす役割を示しています。

サーバー証明書の役割

ハンドシェイクの中でもっとも重要なのがサーバー証明書の検証です。クライアントは、サーバーから受け取った証明書をCA（認証局）のルート証明書を使って検証し、「通信相手が本物のサーバーかどうか」を確認します。この検証に失敗すると、ブラウザは「この接続は安全ではありません」という警告を表示します。

サーバー証明書の検証チェーン（例）
─────────────────────────────────────────
ルートCA（DigiCert / Let's Encrypt など）
  └─ 中間CA
       └─ サーバー証明書（example.com）  ← ここを検証
─────────────────────────────────────────
ブラウザにはルートCAの証明書があらかじめ組み込まれており、
チェーンをたどって正当性を確認する

前方秘匿性（PFS）とは

TLS 1.3では**前方秘匿性（PFS: Perfect Forward Secrecy）が必須です。これは「過去の通信記録を後から解読できないようにする」仕組みで、セッションごとに異なる一時的な鍵を生成するECDHE（楕円曲線ディフィー・ヘルマン鍵交換）**によって実現されます。TLS 1.2まで使えたRSA鍵交換では、サーバーの秘密鍵が漏れた際に過去の通信も解読されるリスクがありましたが、TLS 1.3ではその心配がなくなりました。

規格・RFC番号	内容
RFC 8446	TLS 1.3の仕様（ハンドシェイク手順を含む現行標準）
RFC 5246	TLS 1.2の仕様（現在もサポートされる旧バージョン）
RFC 8422	TLSにおける楕円曲線暗号（ECC）の利用方法
RFC 5280	X.509証明書とCRL（証明書失効リスト）の仕様
RFC 8032	Ed25519など楕円曲線デジタル署名アルゴリズムの仕様