SSL/TLS暗号化とは？仕組み・制限・確認方法・関連概念を整理する

SSL/TLS暗号化の定義と目的

SSL/TLS暗号化は、ネットワーク上の通信を暗号化し、第三者による盗み見や改ざんを起こりにくくするための仕組みです。ブラウザとWebサーバの間（HTTPSなど）を例にすると、平文のやり取りをそのまま流すのではなく、通信途中で意味のある形にできないようにします。

ただし、ここで大事なのは「暗号化すれば何でも完全に守れる」わけではない点です。暗号化の対象は主に“通信路上のデータ”であり、端末側の不正（マルウェア）や、ユーザーが入力する認証情報の扱いまでは直接的に保証しません。さらに、TLSのバージョンや設定、鍵の扱いなどによって安全性は変わり得ます。

SSL/TLSの基本イメージは、概ね次の流れで理解すると整理しやすいです。

接続の開始クライアント（例：ブラウザ）がサーバに接続し、TLSを使いたいことを伝えます。
ネゴシエーション（合意）双方が、どの暗号方式や鍵の作り方を使うかを話し合います。ここで使われる方式によって、暗号化の強さや、実際の安全性に影響します。
鍵の共有とセッションの確立以降のデータを保護するための“セッション用の鍵”が作られます（仕組みの詳細は方式により異なります）。以後の通信は、このセッション鍵を使って暗号化されます。
データ転送（暗号化＋完全性）送受信されるデータは暗号化され、加えて改ざんが起きても検知できる形になります。改ざんが検知されると、通信は成立しない／遮断される方向になります。

この結果、通信路上で第三者が内容を覗いたり、途中で意味のある改変をしたりしにくくなります。

TLSを語るときに頻出する要素を、役割ベースで押さえます。

HTTPSでは、サーバは証明書を提示して「このドメインに対応するサーバです」といった根拠を示します。クライアントは、証明書が信頼できるか（発行元・署名・有効性など）を検証します。これにより、“通信先が本物のサーバかもしれない”という判断に近づきます。

※ただし、証明書が適切に検証されないケースや、ユーザーが警告を無視する運用があると、期待した防御が弱まります。証明書の検証は重要な境目です。

ハンドシェイクは、暗号方式や鍵の扱いを合意し、セッションを開始するための段階です。ここでの選択や設定が、結果としての暗号化強度や挙動に影響します。

TLSは一般に、暗号化（機密性）だけでなく、完全性（改ざん検知）も意識された設計です。単に“見えなくする”だけでなく、“途中で書き換えられたら分かる”ことを狙います。

SSL/TLSは重要ですが、万能ではありません。代表的な制限を整理します。