TLS｜インターネット通信の暗号化標準

2025.10.04

TLS

TLS（Transport Layer Security）は、インターネット上の通信に機密性・完全性・真正性を与える標準的な暗号プロトコルである。HTTPS、SMTPのSTARTTLS、IMAPS、POP3S、MQTT、OPC UAなど多様なアプリケーションで用いられ、TCP上で動作し、公開鍵基盤（PKI）によりサーバ（必要に応じてクライアント）を認証し、(EC)DHEで共有秘密を合意し、対称鍵とAEADで暗号化・認証を行う。現在の主流はTLS 1.3であり、ハンドシェイクの往復回数削減、前方秘匿性（PFS）の強制、脆弱な機能の削除により安全性と性能が大きく向上した。旧来のSSLは歴史的名称であり、実務では非推奨である。

Table Of Contents

目的と脅威モデル

主たる目的は盗聴防止（機密性）、改ざん検出（完全性）、通信相手の正当性確認（真正性）である。攻撃者はネットワーク上でパケットを傍受・改変・挿入できると仮定するため、TLSは暗号強度だけでなく、バージョンダウングレード耐性、乱数品質、証明書検証、パラメータ交渉の堅牢性など総合的な対策を備える。

プロトコル構成

TLSは大きくレコード層とハンドシェイクで構成される。レコード層はフラグメント化・圧縮（1.3では廃止）・暗号化・MAC/AEAD適用を担い、ハンドシェイクは暗号スイートや鍵共有、証明書検証を行う。拡張としてSNI（仮想ホスト識別）、ALPN（上位アプリ選択）、OCSP stapling、セッションチケットなどがある。1.3ではChangeCipherSpecの実質的役割を廃し、暗号仕様を簡素化した。

TLS 1.3のハンドシェイク概要

  • ClientHello：supported_versions、key_share、signature_algorithms、SNI等を提示
  • ServerHello：暗号群と楕円曲線等を選択し、以降のメッセージは暗号化
  • EncryptedExtensions／Certificate／CertificateVerify／Finishedの順で検証を完了
  • HelloRetryRequest：鍵共有グループ不一致時の再提示
  • 0-RTT：再開時の早期データを許容するがリプレイ耐性に注意

1.3は標準で1-RTT、再開時PSK-(EC)DHEによりPFSを維持しつつ遅延を抑制する。0-RTTは冪等な要求に限定して用いるべきである。

暗号アルゴリズムとスイート

  • AEAD：AES-GCM、ChaCha20-Poly1305
  • 鍵共有：ECDHE（x25519、P-256等）
  • 署名：RSA-PSS、ECDSA（RSA PKCS#1 v1.5は段階的非推奨）
  • ハッシュ：SHA-256/384（MD5・SHA-1は不適）

CBCやRSA鍵交換は1.3で除去された。実装は定数時間化と高品質な乱数生成器が必須である。

証明書とPKI

X.509証明書はCA連鎖で検証され、SANによりホスト名を束縛する。失効確認はOCSP/CRLで行い、OCSP staplingによりオンライン依存を低減できる。Certificate Transparencyは不正発行の監視に有用である。クライアント証明書を用いるmTLSは相互認証を提供し、組込み・産業用途や社内システムで多用される。発行運用では有効期限、鍵長、鍵用途（EKU）、自動更新（ACME）を適切に管理する。

レコード層と性能

レコードサイズはMTUやアプリの遅延要求に応じて調整する。1.3の早期暗号化とAEADの採用によりCPU負荷は抑えられるが、ハードウェアではAES-NIや専用エンジンの活用が有効である。セッション再開やセッションチケット鍵のローテーションは性能と安全性のトレードオフを伴うため設計指針を明確にする。

運用設定の要点

  • 許可バージョンはTLS 1.3（必要時のみ1.2を併用）、1.0/1.1は無効化
  • 暗号はAES-GCM/ChaCha20-Poly1305＋ECDHE、PFSを強制
  • 曲線はx25519/P-256を優先し、古いパラメータを除外
  • OCSP staplingと適切な失効戦略、セッションチケット鍵の定期更新
  • ALPNでh2/http/1.1等を適切選択、SNI/ECHでプライバシ保護を強化
  • 監査ログと計測（ハンドシェイク失敗理由、暗号分布、証明書期限）

組込み・産業用途の注意

リソース制約環境ではコードサイズとRAM、乱数源、真性乱数（TRNG）、安全な鍵格納、時刻同期が鍵となる。長寿命接続やMQTT/OPC UAでは再開とKeep-Aliveを組み合わせ、遅延揺らぎを抑える。証明書ピンニングは運用更新と衝突しやすく、ローテーション計画を伴う設計が必要である。FIPS等の適合要件がある場合、検証済みライブラリを選定する。

よくある誤設定と対策

  • 古いプロトコル・暗号の残置 → 最小バージョン/スイートを明示的に設定
  • 名前検証の欠落 → SANでのホスト名検証を必須化
  • 乱数不足 → CSPRNGとエントロピ監視
  • 長期固定のチケット鍵 → ローテーションと失効戦略
  • 0-RTTの乱用 → 冪等要求のみに限定

TLSは単なる暗号化機能ではなく、設計・実装・運用の三位一体で安全性が担保されるプロトコルである。最新仕様の理解、PKI運用、計測に基づく継続改善が信頼できる通信基盤を支える。

コメント（β版）