TLSとセキュアチャネル

トランスポート層セキュリティ（TLS）は、ほとんどのインターネット通信を保護するプロトコルであり、認証された鍵交換と認証付き暗号化を組み合わせることで、2つのエンドポイント間で機密性、完全性保護されたチャネルを確立します。

Definition

TLSのようなセキュアチャネルプロトコルは、2つの当事者間で、認証された鍵交換とそれに続くトラフィックの認証付き暗号化を実行することにより、交換されるすべてのデータの機密性、完全性、および認証を保証するセッションを確立します。

Scope

このトピックでは、TLSを主要な例として、セキュアチャネルプロトコルについて説明します。具体的には、サーバー（およびオプションでクライアント）を認証し、セッション鍵を確立するハンドシェイク、認証付き暗号化を提供するレコード層、前方秘匿性とダウングレード保護、および過去の攻撃から得られた教訓について扱います。暗号学的構成要素がどのように組み合わされて展開されたプロトコルになるかについて説明します。証明書インフラストラクチャ（PKI）と個々のプリミティブについては、関連トピックで扱われるため、ここでは除外します。

Core questions

• TLSハンドシェイクはどのようにサーバーを認証し、セッション鍵を合意するのですか？
• レコード層はどのように認証付き暗号化で各メッセージを保護するのですか？
• 前方秘匿性（forward secrecy）はどのように達成され、記録されたトラフィックにとってなぜ重要なのでしょうか？
• ダウングレード攻撃や再ネゴシエーション攻撃はどのように防がれるのですか？
• 過去の攻撃（BEAST、POODLE、Heartbleed）はプロトコルと実装の設計について何を教えてくれましたか？

Key concepts

• TLSハンドシェイク
• レコード層
• 認証付き暗号化（AEAD）
• 短命鍵交換（ECDHE）
• 前方秘匿性
• サーバーおよびクライアント認証
• ダウングレード攻撃および再ネゴシエーション攻撃
• セッション再開
• 暗号スイートネゴシエーション

Key theories

ハンドシェイクとレコードプロトコル

TLSは、証明書を介して身元を確認し、セッション鍵を導出する認証付き鍵交換ハンドシェイクと、その鍵でアプリケーションデータを暗号化および認証するレコード層を分離し、認証、鍵合意、および一括保護をきれいに構成しています。

前方秘匿性とダウングレード保護

TLS 1.3は、前方秘匿性のために短命な（楕円曲線）Diffie-Hellmanを義務付け、ハンドシェイクトランスクリプトを鍵スケジュールにバインドすることで、アクティブな攻撃者が検知されずに弱いパラメータへのダウングレードを強制できないようにしています。

Mechanisms

TLS 1.3では、クライアントは鍵交換シェアとサポートされるパラメータを送信します。サーバーは自身の短命なDiffie-Hellmanシェア、証明書、およびハンドシェイクトランスクリプトに対する署名で応答し、両者は鍵導出関数（HKDF）を介してセッション鍵を導出します。その後、レコード層はAEAD暗号（AES-GCMやChaCha20-Poly1305など）ですべてのデータを保護します。トランスクリプトは改ざんやダウングレードを防ぐために認証され、ハンドシェイクは1回のラウンドトリップで完了し、オプションでゼロラウンドトリップでの再開が可能です。

Clinical relevance

TLSは、インターネットトラフィックの圧倒的多数を保護しています。ウェブ用のHTTPS、セキュアな電子メール転送、API、VPN、メッセージングはすべてTLS上で動作します。その正確性は、パスワード、支払い、個人データがネットワーク攻撃者から保護されるかどうかを直接決定します。欠陥のあるSSL/初期TLSからTLS 1.3への移行、およびそれに伴う分析は、現実世界の圧力下でのプロトコル進化のモデルとなっています。

Evidence & guidelines

TLS 1.3はRFC 8446で標準化されており、推奨されています。SSL 3.0、TLS 1.0、およびTLS 1.1は非推奨です（RFC 8996）。NIST SP 800-52は構成ガイダンスを提供しています。TLS 1.3は広範な形式的分析を経て開発され、BEAST、POODLE、および実装上の欠陥であるHeartbleedなどの初期の攻撃を可能にした従来の脆弱性（静的RSA鍵交換、CBCモード、再ネゴシエーション）が排除されています。

History

Netscapeは1994年から1995年にかけてSSLを作成しました。SSL 3.0はIETFによってTLS 1.0として再設計され（1999年）、TLS 1.2（2008年）まで改良されました。BEAST、CRIME、POODLE、Heartbleedの実装バグ、Logjam、FREAKといった10年間の攻撃により、従来のモードやダウングレード処理の脆弱性が露呈しました。TLS 1.3（RFC 8446、2018年）は、必須の前方秘匿性、より高速なハンドシェイク、および形式的なセキュリティ分析を伴う大規模な再設計でした。

Key figures

• Eric Rescorla
• Hugo Krawczyk
• Kenny Paterson
• Taher ElGamal

Seminal works

• rfc8446
• stallings2017
• katz2020

Frequently asked questions

SSLとTLSの違いは何ですか？

TLSはSSLの後継です。SSL（バージョン2.0および3.0）は廃止され、安全ではありません。「SSL」は口語的な用語として残っていますが、現在のすべての安全なウェブ接続はTLSを使用しており、TLS 1.3が最新バージョンです。

TLSは悪意のあるウェブサイトから私を保護してくれますか？

TLSは、証明書に記載されたサーバーへの機密性のある認証されたチャネルがあることを保証するだけです。つまり、そのドメインと通信していることを確認しますが、そのドメインが信頼できるものであることを保証するものではありません。フィッシングサイトは、自身の（よく似た）ドメインに対して有効な証明書を提供できるため、TLSはサイトの誠実さを保証するものではありません。