TLS プロトコルの主な目標は、通信を行っているふたつのアプリケーション間にプライバシおよびデータインテグリティを提供することにある。このプロトコルは、ふたつの層（TLS レコードプロトコルおよび TLS ハンドシェイクプロトコル）から成る。最下位において、何らかの信頼できるトランスポートプロトコル （例： TCP [TCP])上に配置されるのは、TLS レコードプロトコルである。TLS レコードプロトコルは、ふたつの基本属性をもつ接続（connection）セキュリティを提供する。：

• その接続（connection）は、private である。共通鍵暗号技術（例： AES [AES], RC4 [SCH] 等）がデータ暗号化用に使われる。この共通鍵暗号化用の鍵は、各接続について一意に生成され、（TLS ハンドシェイクプロトコルのような）別のプロトコルによって交渉された secret に基づく。レコードプロトコルは、暗号化無しに使われる可能性もある。
  
  
• その接続は、信頼できる（reliable）。メッセージ transport は、鍵付き MACを使うメッセージ integrity check を含む。Secure hash 関数（例： SHA-1 等）が MAC 計算用に使われる。レコードプロトコルは、MAC 無しに運用できるが、一般に、このモードでのみ使える。一方、別のプロトコルが、レコードプロトコルをセキュリティパラメータを交渉するためのトランスポートとして使っている。

TLS レコードプロトコルは、様々な上位層プロトコルのカプセル化用に使われる。そのようなカプセル化されたプロトコルのひとつとして、TLS ハンドシェイクプロトコルは、そのサーバおよびクライアントが相互に認証（authenticate）し、そのアプリケーションプロトコルが、データの最初のバイトを転送もしくは受信する前に、暗号化アルゴリズムおよび暗号鍵を交渉できるようにする。TLS ハンドシェイクプロトコルは、3 つの基本属性をもつ接続セキュリティを提供する。：

• そのピアのアイデンティティは、共通鍵暗号技術もしくは公開鍵暗号技術（例： RSA [RSA]、DSA [DSS] 等）を使って本人認証されうる。 この認証（authentication）は、optional とすることができるが、一般に、少なくともピアの片方には要求される。
  
  
• shared secret の交渉は、セキュアである。： 交渉される secret は、盗聴者が盗聴して入手することはできない。そして、あらゆる認証された（authenticated）接続について、その secret を、その接続の中間に身をおくことができる攻撃者でさえ、盗聴して入手することは不可能である。
  
  
• その交渉は、信頼できる（reliable）。： その通信に関わる主体によって検知されること無しに交渉通信を改変（modify）できる攻撃者は、いない。

TLS の優位性のひとつは、「これは、アプリケーションプロトコルと独立であること」である。上位層プロトコルは、TLS プロトコルの最上位に transparently
配置できる。しかし、TLS standard は、「どのようにプロトコルは、セキュリティを TLSで加えるか？」を規定しない。： 「どのように TLS handshaking を開始するか？」および「どのように交換された本人認証（authentication）証明書を解釈するか？」についてのい判断は、TLS 上で動作するプロトコルの設計者および実装者の判断に委ねられている。

この文書中のキーワード、"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY"および"OPTIONAL"は、 RFC 2119 [REQ] に記述されたように解釈されるべき用語である。

本書は、TLS 1.1 [TLS1.1] プロトコルの改訂である。これは、（特に暗号アルゴリズムの交渉について）向上された flexibility を含む。主要な変更は、下記のとおり。：

• PRF（pseudorandom function）中の MD5/SHA-1 の組み合わせは、cipher-suite-specified PRFs と置き換えられてきた。本書中のすべての cipher suites は、P_SHA256 を使う。
  
  
• digitally-signed 要素における MD5/SHA-1 の組み合わせは、単一のハッシュと置き換えられてきた。署名された要素は、今や、使われるハッシュアルゴリズムを明示的に規定するフィールドを含む。
  
  
• 「どのハッシュアルゴリズムおよび署名アルゴリズムをクライアントおよびサーバが受容するか？」を規定するために、クライアントの能力およびサーバの能力について十分に、きれいにした。「これは、以前のバージョンの TLS と比べて署名アルゴリズムおよびハッシュアルゴリズムについてのいくつかの制約も緩和すること」に注意。
  
  
• 追加的なモードを伴う本人認証（authenticated）された暗号化についてのサポートの追加。
  
  
• TLS 拡張（Extension）定義および AES Cipher Suites は、外部の [TLSEXT] および [TLSAES] から統合された。
  
  
• EncryptedPreMasterSecret バージョン番号のより厳密なチェック。
  
  
• 数多くの要件を厳密にした。
  
  
• Verify_data 長は、今や、その cipher suite に依存する。（default は、いまだに 12 である。）
  
  
• Bleichenbacher/Klima 攻撃・防護の記述をきれいにした。
  
  
• アラートは、今や多くの場合において送られねばならない（MUST）。
  
  
• certificate_request の後、入手可能な証明書が無い場合、クライアントは、今や、空の証明書リストを送らなければならない（MUST）。
  
  
• TLS_RSA_WITH_AES_128_CBC_SHA は、今や、cipher suite を実装することが必須である。
  
  
• HMAC-SHA256 cipher suites を追加した。
  
  
• IDEA および DES の cipher suites を削除した。これらは、今や、反対されており、独立した文書中に記述される。
  
  
• SSLv2 下位互換 hello についてのサポートは、今や、SHOULD ではなく、「送信については SHOULD NOT」を伴う MAYである。Support は、おそらく、将来、SHOULD NOT となる。
  
  
• 複数の case arms が同一の符号化をもつことを許容するために限定された "fall-through" が表現言語に追加された。
  
  
• 実装上の落とし穴（Implementation Pitfalls）についての節を追加した。
  
  
• 通常の明確化および編集上の作業。

index -> 2