メインコンテンツまでスキップ

1. Introduction (はじめに)

TLSプロトコルの主な目標は、2つの通信アプリケーション間でプライバシーとデータ完全性を提供することです。このプロトコルは2つの層で構成されています：TLSレコードプロトコル (TLS Record Protocol) とTLSハンドシェイクプロトコル (TLS Handshake Protocol) です。最下層では、何らかの信頼性のあるトランスポートプロトコル (例：TCP [TCP]) の上に層化されたTLSレコードプロトコルがあります。TLSレコードプロトコルが提供する接続セキュリティには、2つの基本的な特性があります。

  • 接続はプライベートである (private)。 対称暗号 (Symmetric cryptography) がデータ暗号化に使用されます (例：AES [AES]、RC4 [SCH]など)。この対称暗号化の鍵は、各接続に対して一意に生成され、別のプロトコル (TLSハンドシェイクプロトコルなど) によってネゴシエートされた秘密に基づいています。レコードプロトコルは、暗号化なしでも使用できます。

  • 接続は信頼性がある (reliable)。 メッセージ転送には、鍵付きMACを使用したメッセージ完全性チェックが含まれます。セキュアハッシュ関数 (Secure hash functions) (例：SHA-1など) がMAC計算に使用されます。レコードプロトコルはMACなしで動作できますが、通常、別のプロトコルがセキュリティパラメータをネゴシエートするためのトランスポートとしてレコードプロトコルを使用している場合にのみ、このモードで使用されます。

TLSレコードプロトコルは、さまざまな上位層プロトコルをカプセル化するために使用されます。そのようなカプセル化されたプロトコルの1つであるTLSハンドシェイクプロトコルは、アプリケーションプロトコルが最初のデータバイトを送信または受信する前に、サーバーとクライアントが相互に認証 (authenticate) し、暗号化アルゴリズムと暗号鍵をネゴシエートすることを可能にします。TLSハンドシェイクプロトコルが提供する接続セキュリティには、3つの基本的な特性があります。

  • ピアのアイデンティティは、非対称暗号または公開鍵暗号 (asymmetric, or public key, cryptography) を使用して認証できます (例：RSA [RSA]、DSA [DSS]など)。この認証はオプションにできますが、通常は少なくとも一方のピアに対して必要です。

  • 共有秘密のネゴシエーションは安全です： ネゴシエートされた秘密は盗聴者には利用できず、認証された接続であれば、攻撃者が接続の中間に自分自身を配置できたとしても、その秘密は取得できません。

  • ネゴシエーションは信頼性があります： 攻撃者は、通信の当事者に検出されることなく、ネゴシエーション通信を変更することはできません。

TLSの利点の1つは、アプリケーションプロトコルに依存しない (application protocol independent) ことです。上位層プロトコルは、TLSプロトコルの上に透過的に層化できます。ただし、TLS標準は、プロトコルがTLSでセキュリティを追加する方法を規定していません。TLSハンドシェイクを開始する方法と、交換された認証証明書を解釈する方法に関する決定は、TLS上で実行されるプロトコルの設計者と実装者の判断に委ねられています。

1.1. Requirements Terminology (要件用語)​

本文書におけるキーワード「MUST」(しなければならない)、「MUST NOT」(してはならない)、「REQUIRED」(必須である)、「SHALL」(しなければならない)、「SHALL NOT」(してはならない)、「SHOULD」(すべきである)、「SHOULD NOT」(すべきでない)、「RECOMMENDED」(推奨される)、「MAY」(してもよい)、および「OPTIONAL」(任意である) は、RFC 2119 [REQ] に記載されているように解釈されるものとします。

1.2. Major Differences from TLS 1.1 (TLS 1.1からの主な変更点)​

本文書は、TLS 1.1 [TLS1.1] プロトコルの改訂版であり、特に暗号アルゴリズムのネゴシエーションにおいて、改善された柔軟性を含んでいます。主な変更点は以下の通りです。

  • 擬似乱数関数 (PRF, pseudorandom function) におけるMD5/SHA-1の組み合わせが、暗号スイート指定のPRFに置き換えられました。本文書のすべての暗号スイートは、P_SHA256を使用します。

  • デジタル署名要素におけるMD5/SHA-1の組み合わせが、単一のハッシュに置き換えられました。署名要素には、使用されるハッシュアルゴリズムを明示的に指定するフィールドが含まれるようになりました。

  • クライアントとサーバーが受け入れるハッシュアルゴリズムと署名アルゴリズムを指定する機能が大幅にクリーンアップされました。これにより、TLSの以前のバージョンにおける署名アルゴリズムとハッシュアルゴリズムに対するいくつかの制約も緩和されたことに注意してください。

  • 追加データ付き認証暗号化モード (authenticated encryption with additional data modes) のサポートが追加されました。

  • TLS拡張定義とAES暗号スイートが、外部の [TLSEXT] および [TLSAES] からマージされました。

  • EncryptedPreMasterSecretバージョン番号のチェックが厳格化されました。

  • 多くの要件が厳格化されました。

  • verify_dataの長さが暗号スイートに依存するようになりました (デフォルト値は依然として12です)。

  • Bleichenbacher/Klima攻撃防御の説明がクリーンアップされました。

  • 多くの場合、アラート (Alerts) を送信しなければならない (MUST) ようになりました。

  • certificate_requestの後、利用可能な証明書がない場合、クライアントは空の証明書リストを送信しなければならない (MUST) ようになりました。

  • TLS_RSA_WITH_AES_128_CBC_SHAが、実装必須 (mandatory to implement) の暗号スイートになりました。

  • HMAC-SHA256暗号スイートが追加されました。

  • IDEAおよびDES暗号スイートが削除されました。これらは現在非推奨となり、別の文書で文書化される予定です。

  • SSLv2後方互換helloのサポートが、SHOULD (すべきである) ではなくMAY (してもよい) になり、それを送信することはSHOULD NOT (すべきでない) になりました。将来的には、サポートがSHOULD NOT (すべきでない) になる可能性があります。

  • 複数のcase分岐が同じエンコーディングを持つことを可能にするために、表現言語 (presentation language) に限定的な「fall-through」機能が追加されました。

  • 実装上の落とし穴 (Implementation Pitfalls) に関するセクションが追加されました。

  • 通常の明確化と編集作業。

に最終更新