TLSと安全な通信｜サイバーセキュリティ

← サイバーセキュリティ一覧

🎓 レベル：標準　|　重要度：A（必須） 📎 前提：デジタル署名と証明書（PKI） ⚠️ 推奨設定は更新される（要最新確認）。本稿は TLS 1.3 を現行標準として記述。

要点（BLUF）

TLS は暗号の道具（対称鍵・公開鍵・署名・証明書）を組み合わせ、通信の機密性・完全性・真正性をまとめて守るプロトコル。HTTPS の土台。
核心はハンドシェイク：公開鍵の仕組みでセッション鍵を安全に合意し、以降は速い対称鍵で本文を暗号化する（ハイブリッド）。
現行標準は TLS 1.3。常に**前方秘匿性（forward secrecy）**を持ち、旧来の弱い方式を排除。TLS 1.2 以前は限定的に。

概念：暗号の道具を組み合わせる

ここまでの道具を1つに束ねたのが TLS です。

相手が本物か → 証明書と署名（デジタル署名と証明書（PKI））で真正性
セッション鍵を安全に共有 → 鍵交換（公開鍵側の技術）（公開鍵暗号）
本文を速く暗号化 → 対称鍵暗号 AEAD（対称鍵暗号とハッシュ）で機密性＋完全性

「相手確認 → 鍵合意 → 本文暗号化」の流れを自動でやってくれるのが TLS です。

仕組み：TLS 1.3 ハンドシェイク

TLS 1.3 は1往復（1-RTT）で鍵合意まで終え、旧バージョンより速く安全になりました。守る側が知っておく流れはこうです。

ClientHello：クライアントが対応する暗号方式と、鍵交換用の材料（(EC)DHE の公開値）を送る。
ServerHello＋証明書：サーバが方式を選び、自分の証明書（デジタル署名と証明書（PKI））と署名、鍵交換材料を返す。
鍵合意：双方が交換した材料から共有のセッション鍵を各自で計算する。鍵そのものは回線に流れない。
暗号化通信：以降は AEAD（AES-GCM など）でアプリデータを暗号化。

sequenceDiagram
    participant C as クライアント
    participant S as サーバ
    C->>S: ClientHello（対応方式・鍵交換材料）
    S->>C: ServerHello・証明書・署名・鍵交換材料
    Note over C,S: 双方が共有のセッション鍵を各自計算（鍵は流れない）
    C->>S: Finished（ここから暗号化）
    S->>C: 暗号化されたアプリデータ

仕組み：前方秘匿性（forward secrecy）

TLS 1.3 は鍵交換に毎回使い捨ての一時鍵（(EC)DHE）を使います。これにより前方秘匿性が得られます。すなわち、将来サーバの長期秘密鍵が漏れても、過去に記録された通信は復号できない。セッション鍵は使い捨ての一時値から作られ、長期鍵だけでは再現できないからです。TLS 1.3 は前方秘匿性のない方式（旧来の RSA 鍵交換）を廃止しました。

防御側の使い方／設定

TLS 1.3 を既定に、1.0/1.1 は無効化：1.2 を使う場合も前方秘匿性のある方式に限定（NIST/NSA 推奨、要最新確認）。
証明書を正しく運用：信頼された CA の証明書、適切な有効期限、自動更新（短命証明書）、失効対応。
HSTS を有効化：一度 HTTPS で来たクライアントに以後 HTTPS を強制し、平文へのダウングレードを防ぐ。
弱い暗号方式を無効化：古い・前方秘匿性のないスイートを切る。設定は定期的に見直す。
ネットワーク上での HTTPS の位置づけ（ポート・プロトコル階層）は VPNと暗号化通信・コンピュータネットワーク分野へ。

なぜ安全か：3つの保証を1つの流れで

TLS が通信を守れるのは、ハンドシェイクの中で3つを同時に達成するからです。(1) 証明書と署名で相手が本物だと確かめ（真正性）、(2) 一時鍵の交換で盗聴者には作れないセッション鍵を共有し（機密性）、(3) AEAD で改ざんを検知する（完全性）。前方秘匿性により、長期鍵が将来漏れても過去ログは守られます。

仕組みの直観

TLS は初対面の二人が、公証人の身分証（証明書）で相手を確認し、その場限りの合言葉（セッション鍵）を周りに聞かれず作って、以降はその合言葉で素早く会話する手順です。合言葉は毎回作り直すので、後日どちらかの金庫の鍵が盗まれても、昔の会話は再現できません。

⚠️ よくある誤解・設定ミス

古い TLS/SSL を残す：SSL 3.0・TLS 1.0/1.1 は既知の弱点あり。無効化する。
証明書エラーを無視する設定：検証スキップは中間者に道を開く（デジタル署名と証明書（PKI））。
混在コンテンツ（HTTPS ページに HTTP 読み込み）：一部が平文になり保護が崩れる。
「TLS があるからアプリは安全」と思う：TLS は通信路を守るだけ。アプリ側の脆弱性（アプリケーションセキュリティ目次）は別問題。
証明書の更新漏れで失効：可用性事故になる。自動更新と監視を。

対応 lab

TLS は複数の道具の組み合わせのため専用 lab は置かず、構成要素を security-study/labs/ の各デモで確認します（鍵＝対称/公開鍵、証明書＝署名 digital_signature_demo.py、本文暗号＝symmetric_aead_demo.py）。