E. SSLの下位互換 English
（準備中）
歴史的な理由と、予約されるポート番号をいたずらに消費することを避けるために、 TLS 1.0、SSL 3.0、SSL 2.0 によるセキュリティを持つアプリケーションプロトコルは、1つのコネクションポートを共有する。例えば、https プロトコル (SSL または TLS によるセキュリティを持つ HTTP) は、使用しているセキュリティプロトコルにかかわらず、ポー ト 443 を使用する。したがって、様々なプロトコルを区別し、共有するために、何らかのメカニズムが決定されなければならない。
TLS バージョン1.0 と SSL 3.0 は非常によく似ている。したがって、両方をサポートするのは簡単である。SSL 3.0 をサポートするサーバーと共有しようとしている TLS クライアントは、SSL 3.0 のレコードフォーマットと ClientHello 構造体を使用し、バージョンフィールドに {3、1}、すなわち TLS 1.0 をサポートしているということを知らせる ClientHello メッセージを送信するべきである。もしサーバーが SSL 3.0 だけをサポートしている場合、サーバーは SSL 3.0 の ServerHello で応答する。サーバーが TLS をサポートしている場合には、TLSの ServerHello で応答する。そして、共有はそのプロトコルで適切に処理される。
同様に、SSL 3.0 クライアントと通信しようとする TLS サーバーは、もし SSL 3.0 の ClientHello を受信し、そのバージョンフィールドが {3, 0} であった場合、すなわちこのクライアントはTLSをサポートしていないことが示されていた場合、 SSL 3.0 の ClientHello メッセージを受理し、SSL 3.0 の ServerHello メッセージで応答すべきである。
クライアントが既に、サーバーの最も高いプロトコルを知っている(例えば、セッションを再利用するときなどの)場合には、そのプロトコルを使用してコネクションを開始するべきである。
SSL バージョン 2.0 をサポートしている TLS 1.0 クライアントは、SSL バージョン 2.0 の ClientHello メッセージを送信しなければならない[SSL2]。TLS サーバーは、もし同じコネクションポートで SSL 2.0 クライアントをサポートしようとするならば、どちらのClientHello も受理するべきである。バージョン 2.0 の仕様と異なっている点は、バージョンの値が 3 であることを特定する能力と、CipherSpec で指定される暗号タイプがより多いことだけである。
警告： バージョン 2.0 の ClientHello メッセージを送信する機能は、迅速に、段階的に廃止されるだろう。実装者はできるだけ早く、アップデートするためのあらゆる努力をするべきである。バージョン3.0では、より新しいバージョンにアップデートするための、より良いメカニズムを提供している。
以下の暗号仕様は、SSL バージョン 2.0 から引き継がれたものである。これらは鍵交換と認証において、RSA を使用するものと仮定している。
V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };
V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 = { 0x04,0x00,0x80 };
V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };TLS 特有の暗号仕様は、以下の構文を使用することにより、バージョン 2.0 の ClientHello メ ッセージに含めることができる。最初のバイトがゼロである V2CipherSpecの要素は、バージョン 2.0 サーバーによって無視される。上記の V2CipherSpecs を送信するクライアントはまた、TLS における同等の値を含めるべきである(付録 A.5 を参照)。
V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
E.1. バージョン2の ClientHello English
バージョン 2.0 の ClientHello メッセージは、本ドキュメントでのプレゼンテーションモデルを使用して、以下のように表される。真の定義は、SSL バージョン 2.0 仕様書に記載されている。
uint8 V2CipherSpec[3];
struct {
uint8 msg_type;
Version version;
uint16 cipher_spec_length;
uint16 session_id_length;
uint16 challenge_length;
V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
opaque session_id[V2ClientHello.session_id_length];
Random challenge;} V2ClientHello;
- msg_type
- このフィールドは、versionフィールドと関連して、バージョン 2の ClientHello メッセージであることを示す。この値は 1 であるべきである。
- version
- クライアントによってサポートされた最も高いプロトコルバージョン (これは ProtocolVersion.version に等しい。付録 A.1 を参照)。
- cipher_spec_length
- cipher_specsフィールドの長さ。0 であってはならず、V2CipherSpec の長さ (3) の倍数でなければならない。
- session_id_length
- このフィールドの値は0または16でなければならない。もし0であれば、クライアントは新規セッションを生成していることを示す。もし 16 であれば、session_id フィールドには 16 バイトのセッション識別子が格納される。
- challenge_length
- サーバー認証のために、クライアントがサーバーへ送信するchallengeのバイト長。これは32でなければならない。
- cipher_specs
- クライアントが使用を望んでいる、また使用可能なすべての CipherSpec のリストを表す。ここには少なくとも、サーバーが受理可能な 1つの CipherSpec がなければならない。
- session_id
- もしこのフィールドの長さが 0 でなければ、ここにはクライアントが再利用したいと望んでいるセッション識別子が格納される。
- challenge
- サーバーを認証するための、サーバーへの、サーバーのためのクライアント challenge で、（おおよそ）任意長の乱数である。TLS サーバーは本プロトコル規定に従い、challenge データをClientHello.random データに変更する（必要であれば、0 をパディングする）。challenge の長さが 32バイトよりも長いときは、後ろの 32バイトのみを使用する。 V3 サーバーが、16バイト未満のchallengeデータを含む V2 の ClientHello を拒絶することは認められる（ただし必要というわけではない）。
注： TLS セッションの再利用リクエストでは、TLSのClientHelloを使用すべきである。
E.2. なりすましによるバージョンロールバック攻撃の回避 English
TLS クライアントがバージョン 2.0 との互換モードになった場合には、クライアントは特別な PKCS #1 ブロックフォーマットを使用すべきである。これを行うことにより、TLS サーバーは、TLS が実行可能なクライアントとの間でのバージョン 2.0 セッションを拒否することができる。
TLS クライアントがバージョン2.0との互換モードであるときには、CLIENT-MASTER-KEY メッセージの ENCRYPTED-KEY-DATA フィールドを RSA により暗号化する際に、PKCS パディング（パディングの最後のNULLを含まない）における右側（最下位）の 8つのランダムバイトを 0x03 にセットする（他のパディングバイトはランダムである）。ENCRYPTED-KEY-DATA フィールドを復号した後、TLS をサポートするサーバーでは、それら 8 つのパディングバイトが 0x03 であればエラーとすべきである。バージョン 2.0 をサポートするサーバーがこの方法によるパディングブロックを受信したときには、通常通りの処理が行われる。