TLSは「通信を暗号化する仕組み」として語られることが多いが、実際には暗号化だけではなく、相手が本物かを確かめ、さらに途中で改ざんされていないことまでまとめて面倒を見る。だからHTTPSは「HTTPを暗号化したもの」というより、「HTTPを安全に運ぶための一式」だと捉えた方が理解しやすい。
このページでは、証明書ページで触れたTLSの流れをもう一段だけ具体化し、用語と図の対応が取れる状態まで落とす。
TLSで守りたいのは、だいたい次の3つに集約される。
- 機密性:通信内容を読めないようにする(盗み見対策)
- 真正性:相手が本物であることを確かめる(なりすまし対策)
- 完全性:途中で改ざんされていないことを確かめる(改ざん対策)
- 機密性:封筒に入れて中身が見えない状態
- 真正性:差出人の身分証で本人確認した状態
- 完全性:封が破られていない、割印が一致する状態
TLSは、暗号の方式だけではなく、この3つを成立させるための「手順」と「確認」をまとめて提供している。
- 専門用語:TLS Handshake
- 解説:暗号化通信を始める前に、方式の合意と本人確認と鍵の準備をするやり取り
- 身近な例:会話を始める前の「名刺交換」と「合言葉の決定」
- 専門用語:Cipher Suite
- 解説:鍵交換・暗号化・ハッシュなど、TLSで使う技術セットの組み合わせ
- 身近な例:料理の「コースメニュー」(前菜、メイン、デザートがセットになっている)
- 専門用語:Key Exchange
- 解説:暗号化に使う共通鍵を安全に作るための仕組み
- 身近な例:人に聞かれない場所で合言葉を決める
- 専門用語:Symmetric Encryption
- 解説:通信の暗号化に使う鍵が「同じ」方式。速いので通信本体はこれが主役
- 身近な例:2人だけが持つ合鍵で、同じ鍵で施錠も解錠もする
- 専門用語:Certificate
- 解説:サーバの公開鍵が本物であることをCAが保証したデータ
- 身近な例:役所が発行した身分証。名札付きで「この鍵はこの人のもの」と言い切れる
ここは暗号の細部よりも、順番が命。まず「何が起きるか」の順番だけ掴む。
この図で見たいポイントは、証明書はTLSの入口で必ず出てくるということと、通信の本体は共通鍵で暗号化されるということ。
TLSの考え方はシンプルで、最初に本人確認をしてから、2者だけが知っている共通鍵を作り、その後は共通鍵で高速に暗号化する。
- 本人確認:身分証(証明書)を見せてもらう
- 共通鍵:会話用の合言葉を2人だけで決める
- 暗号化通信:合言葉で会話する
ここまで来れば「暗号化できているか」は見えるが、さらに重要なのは「偽物に暗号化していないか」。だから証明書の検証が先頭に来る。
厳密な仕様差は別ページに逃がして、ここでは運用で効く差だけ押さえる。
- TLS1.3は古い方式を整理して安全側に寄せている
- TLS1.3はハンドシェイクが軽くなり、通信開始が速い傾向がある
- サーバ設定で「TLS1.2は許可するが古いSSLは切る」が基本になる
- TLS1.2:古い道も残しつつ整備した高速道路
- TLS1.3:危ない脇道を閉鎖して、本道だけにした高速道路
運用で詰まりやすいのは「暗号方式」よりも、証明書とSNIと期限切れ。だから確認コマンドを先に決めておくと強い。
- どの証明書が返ってきているか(CN/SAN、発行者、期限)
- SNIを付けたときに正しい証明書が返るか
- チェーンが欠けていないか(中間証明書)
openssl s_client -connect example.com:443 -servername example.com |
openssl x509 -noout -subject -issuer -dates
この確認は「TLSが通るか」ではなく「どの証明書が出ているか」を確認するためのもの。
TLSは暗号化だけの仕組みではなく、本人確認と改ざん検知まで含めた「安全な通信のための一式」になっている。
- 証明書はTLSの入口で本人確認を成立させる
- 通信本体は共通鍵で暗号化される
- 運用では「証明書の中身」と「SNI」と「期限」が詰まりやすい
次は「HTTPSとは(HTTPとの違いをもう少し具体化)」か「認証局と信頼チェーン(失効の話も含める)」に進むと、証明書運用に直結する。