メインコンテンツへスキップ

🗑️ TLS1.3で廃止された仕組みとその理由

🌱 はじめに

TLS1.3は「速く、安全でシンプル」なプロトコルを目指し、多くの古い暗号方式や仕組みを大胆に廃止しました。互換性のために残され続けてきた技術は、時代が進むにつれて脆弱性の温床となり、攻撃者に利用されるリスクが高まっていました。この記事では、TLS1.3で廃止された主な機能と、その背景をまとめます。

⏳ 歴史的経緯

  • TLS1.0〜1.2では「後方互換性」を重視し、多数の暗号スイートや鍵交換方式をサポート。

  • その結果、安全性が低い方式も生き残り続けた。

  • しかしインターネット利用の爆発的拡大に伴い、「脆弱性を突かれたら即座に被害拡大」という状況になり、抜本的な見直しが必要になった。

TLS1.3では「安全ではないものは一切残さない」という方針が採られた。

🔐 廃止された主な暗号と仕組み

1. RSA鍵交換

  • 問題点

    • Forward Secrecyを保証できない（サーバー秘密鍵が漏れたら過去通信も解読可能）。

    • 実装によってはBleichenbacher攻撃などの脆弱性が存在。

  • TLS1.3での対応

    • ECDHE（楕円曲線Diffie-Hellman Ephemeral）のみ採用。

    • セッションごとに一時的な鍵を生成し、Forward Secrecyを必須化。

2. CBC（Cipher Block Chaining）モード

  • 問題点

    • パディングオラクル攻撃（BEAST, Lucky13など）の対象。

    • 実装が複雑でバグが入りやすい。

  • TLS1.3での対応

    • AEAD（Authenticated Encryption with Associated Data）方式に一本化。

    • AES-GCMやChaCha20-Poly1305のみをサポート。

3. SHA-1

  • 問題点

    • 衝突攻撃が実証され、証明書署名に不適。

    • 継続利用は攻撃者に偽造証明書作成の余地を与える。

  • TLS1.3での対応

    • SHA-256/384のみ使用可能。

4. Static DH（固定Diffie-Hellman）

  • 問題点

    • 鍵が固定のためForward Secrecyが得られない。

  • TLS1.3での対応

    • Ephemeral DH/ECDH（使い捨て鍵）以外は廃止。

5. 圧縮（TLS-level Compression）

  • 問題点

    • CRIME攻撃により機密情報（Cookieなど）が漏洩する可能性。

  • TLS1.3での対応

    • TLSレベルでの圧縮機能は完全に削除。

    • 必要ならアプリケーション層（HTTP/2やHTTP/3）で圧縮を行う。

6. レガシーな暗号スイート

  • RC4, 3DES, IDEA, MD5を利用したスイートなどはすべて廃止。

  • 理由: 既に実用的な攻撃が可能で、安全性が保証できないため。

🛡️ 廃止によるメリット

  • 安全性の向上

    • 過去の脆弱性を突かれるリスクを排除。

  • 実装のシンプル化

    • 選択肢が減り、コードが整理される。

    • 実装者が「間違った暗号を選ぶ」リスクがなくなる。

  • 性能向上

    • AEAD方式（AES-GCM/ChaCha20-Poly1305）は並列化に強く、ハードウェア最適化済み。

TLS1.3の「大胆な断捨離」は、セキュリティとパフォーマンスの両立に直結した。

🎯 まとめ

TLS1.3で廃止された仕組みは、一見すると便利だったが脆弱性や運用負担を抱えていたものです。

  • RSA鍵交換、CBCモード、SHA-1、圧縮などはすべてリスクが高く不適切

  • Forward SecrecyとAEADに一本化することで、よりシンプルで安全な設計に進化

もし運用環境で古いTLSバージョンを有効のまま残していると、これらの危険な暗号がまだ使われてしまう。必ずTLS1.3または最低限TLS1.2に移行する必要がある。


上に戻る