SSL/TLS暗号化とは

SSLとTLSは、インターネット通信を保護するための暗号化プロトコルの系統を指します。実際には、現在の主流はTLSで、Web通信などで「HTTPS」として利用されます。SSL/TLS暗号化の目的は主に次の2つです。

  • 盗聴の抑制：通信内容を第三者が読み取れない形に変換する
  • 改ざんの検出（抑制）：途中で内容が書き換えられていないかを確認する

加えて、TLSはサーバー（通信先）を証明書で検証することで、なりすましを減らす役割も担います。これらは「暗号化だけ」ではなく、相手の正しさの確認と**整合性（改ざん検出）**がセットになっている点が重要です。

仕組みの全体像：ハンドシェイクとセッション鍵

TLS通信は大きく分けて、接続の最初に行う「ハンドシェイク」と、その後の「暗号化データ送受信」で構成されます。

1) ハンドシェイク：暗号方式と鍵の合意

接続が始まると、クライアント（利用者側）とサーバーは、通信を保護するための共通の仕組みを決めます。典型的には次の流れになります。

  • 暗号スイート（暗号方式の組み合わせ）の候補を交換する
  • サーバーが証明書を提示し、クライアントがそれを検証する
  • その後、通信で使う**セッション鍵（実際の暗号化に使う鍵）**を合意する

ここで使われる公開鍵暗号の考え方により、双方は最終的に「同じセッション鍵」を導き、以降のデータをその鍵で保護します。

2) 暗号化データ送受信：保護しながら通信

ハンドシェイクが終わると、以降の通信では、セッション鍵を使ってデータを暗号化し、さらに改ざん検出のための仕組み（整合性）を併用しながら送受信します。結果として、第三者が途中で内容を覗いたり改変したりしても、正しく復元・検証できない可能性が高くなります。

証明書検証で何が守られ、何が限界か

TLSの重要な要素である証明書検証は、「暗号化されているか」だけでなく、「その相手が本物か」を手助けします。一般的に、ブラウザ等は次のような観点で証明書を扱います。

  • 発行者（認証局）に対する信頼
  • 有効期限
  • 対象名（アクセス先のドメイン等）との一致
  • 署名の整合性

ここでの限界も理解しておくと安心です。

  • 暗号化していても端末が安全とは限らない：端末にマルウェアがいる場合、通信自体が安全でも別経路で情報が奪われることがあります。
  • 証明書が正しくても、アプリの挙動は別問題：ログイン後の設定ミスや不正な操作誘導（フィッシングなど）まで自動で防ぐわけではありません。
  • 設定や方式の適切性に依存する：古い方式や不適切な設定は、保護の有効性を下げる可能性があります。

また、TLSは通信の保護に強い一方で、通信経路の外側（端末・アカウント・利用者の判断）までは直接保証できません。ここが「万能ではない」というポイントです。

HTTP/HTTPSや関連概念との違い

混同しやすい点を整理します。