RFC 5746

<color red>注意: 自分用の翻訳ですから，間違いはたくさんあるでしょうし，表現の統一とかも全くなされていません．翻訳時期によって同じ言葉の翻訳が違うかも．</color>

クライアントもサーバも，それぞれの TLS 接続状態に対して三つの追加の値を保持する必要がある (RFC 5246, Section 6.1 参照)．これらの値はコネクション特有の値であることに注意 (TLS セッションのキャッシュに対してではない)．

• “secure_renegotiation” フラグ．このコネクションでセキュアな再ネゴシエーションが使用中かどうか
• “client_verify_data” 直前のハンドシェイクでクライアントから送出された Finished に含まれる verify_data が入る．
• “server_verify_data” 直前のハンドシェイクでサーバから送られた Finished メッセージに含まれる verify_data が入る．

この文書では新たな TLS 拡張として “regegotiation_info” を追加する (拡張タイプ: 0xff01)．これは再ネゴシエーションを実行する TLS コネクションで使われる暗号の暗号バインディングを含む．この拡張の “extension data” には “RenegotiationInfo” 構造が入る．

      struct {
          opaque renegotiated_connection<0..255>;
      } RenegotiationInfo;

この拡張のコンテンツは以下のように指定される．

• 初期のハンドシェイクの場合，ClientHello, ServerHello 共に “renegotiation_connection” フィールドは 0 が入る (0 で長さ分埋められる)．つまり，この拡張は ff 01 00 01 00 となる．最初の 2 オクテットは拡張タイプ，次の 2 オクテットは拡張の長さ，最後のオクテットは “renegotiation_connection” の長さ分 0が入る．
• 再ネゴシエーション時の ClientHello だと，ここに “client_verify_data” が入る (Section 3.1)．
• 再ネゴシエーション時の ServerHello だと，ここに “client_verify_data” と “server_verify_data” を連結したものが入る (Section 3.1)．現在の TLS のバージョンの場合，これは 24byte になる (SSLv3 だと 72byte になる)．

この拡張は Datagram TLS (DTLS) [RFC4347] でも使うことは可能だが，ここでは単純化して説明するために TLS のみに触れる．DTLS についてもこの文書の要件は同じように適用される．

SSLv3 と TLS 1.0/TLS 1.1 仕様では ClientHello で理解出来ないものがあった場合 (例えば拡張で)，無視する事が必要である．しかし，中には SSLv3 と TLS 1.0 の実装で，このような場合にハンドシェイクが失敗してしまう実装がある．これは “renegotiation_info” 拡張を提示するクライアントがハンドシェイクの失敗を引き起こす可能性があることを意味する．このようなサーバとの互換性のため，この文書では特別な Signaling Cipher Suite Value (SCSV) を使った二次的な伝達手段を定義する．この SCSV は “TLS_EMPTY_RENEGOTIATION_INFO_SCSV” であり，コードポイント {0x00, 0xFF} である．この SCSV は実際の Cipher Suite ではなく (有効なアルゴリズムには一切一致しない)，ネゴシエーションはできない．代わりに，後のセクションで述べるように，これは空の “renegotiation_info” 拡張と同じ意味を持つ．SSLv3 と TLS の実装は，知らない Cipher Suite は確実に無視するので，SCSV はどのようなサーバに対しても安全に送出可能である．さらに SCSV は SSLv2 との後方互換性のための CLIENT-HELLO をも含めることが可能である ([RFC5246]のAppendix E.2参照)．

注意: 再ネゴシエーションを全くサポートしない最小限のクライアントは，全ての初期ハンドシェイクで単純に SCSV を使うことが可能である．後のセクションのルールでは，このようなクライアントからの再ネゴシエーションの試みであることが明白な場合，仕様に準拠したサーバであればハンドシェイクを中断しようとするだろう．

このセクションと 3.5 はフルハンドシェイクとセッション再利用 (resumption) ハンドシェイクの両方に適用されることに注意すること．

• クライアントは，空の “renegotiation_info” か TLS_EMPTY_RENEGOTIATION_INFO_SCSV のどちらかを ClientHello で送出．両方を含めるのは推奨されない．
• ServerHello を受信した時 “renegotiation_info” が含まれているかどうかをチェックしなければならない．
  • 含まれない場合はサーバがセキュアな再ネゴシエーションをサポートしてないので secure_renegotiation フラグを FALSE にする．この場合は，クライアントはハンドシェイクを続ける代わりに終了してもよい．4.1 の議論を参照のこと．
  • 拡張が提示されてる場合は，secure_renegotiation フラグを true にする．クライアントは “renegotiated_connection” フィールドが 0 であることを確認しなければならない．0 でない場合はハンドシェイクを中断しなければならない．
    注意: Section 3 の後半で「ハンドシェイクを中断する」とは「致命的な handshake_failure 警告を送り，接続を終了する」を短くあらわしたものとして使われる．
• ハンドシェイク終了後は，クライアントは client_verify_data と server_verify_data の値を将来のために保存しておく必要がある．

このセクションは，コネクションの “secure_renegotiation” フラグが TRUE に設定されている時に適用される．(もし FALSE の場合は Section 4.2 を参照のこと)

• クライアントは “renegotiation_info” 拡張を ClientHello に含まなければならない．この拡張には保存してある “client_verify_data” を使う．SCSV は含めてはならない．
• “ServerHello” を受信した時，クライアントは “renegotiation_info” 拡張が含まれているかどうかチェックしなければならない．もし含まれていない場合，クライアントはハンドシェイクを中断しなければならない．
• クライアントは “renegotiated_connection” フィールドの前半分を保存してある client_verify_data と等しいかチェックし，後半分を保存してある server_verify_data と等しいかチェックしなければならない．等しくない場合，クライアントはハンドシェイクを中断しなければならない．
  • ハンドシェイクが完了したとき，クライアントは改めて新しい client_verify_data と server_verify_data を保存しておく必要がある．

この Section と Section 3.7 はフルハンドシェイクとセッション再利用 (resumption) ハンドシェイクの両方に適用されることに注意すること．

• ClientHello を受信したとき，サーバは TLS_EMPTY_RENEGOTIATION_INFO_SCSV が含まれているかどうかチェックしなければならない．もし含まれていたら，secure_renegotiation フラグを TRUE にする．
• サーバは ClientHello に “renegotiation_info” 拡張が含まれているかどうかチェックしなければならない．もし拡張が含まれている場合，secure_renegotiation フラグを TRUE にセットする．サーバは “renegotiation_connection” フィールドの長さがゼロであるかチェックしなければならない．もし違っている場合は，ハンドシェイクを中断しなければならない．
• もし TLS_EMPTY_RENEGOTIATION_INFO_SCSV も renegotiation_info も含まれていない場合，“secure_renegotiation” フラグを FALSE に設定する．この場合，サーバはハンドシェイクを続ける代わりに終了させても良い．Section 4.3 の議論を参照のこと．
• secure_renegotiation フラグが TRUE にセットされている場合，サーバは空の “renegotiation_info” 拡張を ServerHello メッセージに含めなければならない．
• ハンドシェイク終了後は，サーバは client_verify_data と server_verify_data の値を将来のために保存しておく必要がある．

この仕様を実装する TLS サーバはクライアントが示す未知の拡張を無視しなければならない．また，この TLS サーバは自分の実装する TLS のバージョン番号以上のバージョン番号を受け入れ，共通のバージョン番号のうちの最も高いバージョン番号のものでネゴシエーションしなければならない．これは既に存在する RFC5246 でかかれていることの念押しで，上位互換性のために単に書いただけである．

注意すべきは，SCSV だけが含まれている ClientHello に対して “renegotiation_info” 拡張を送ることは，特に要求されない拡張を送るサーバ上では RFC5426 の Section 7.4.1.4 の禁止項目の例外であるということである．これは，クライアントが TLS_EMPTY_RENEGOTIATION_INFO_SCSV 経由で拡張を受け取りたいという意志を表明しているというのが理由である．TLS においては，他の全ての拡張は Section 7.4.1.4 に今後も従わなければならない．

このセクションは，コネクションの “secure_renegotiation” フラグが TRUE に設定されている時に適用される．(もし FALSE の場合は Section 4.4 を参照のこと)

• ClientHello を受信したとき，サーバは TLS_EMPTY_RENEGOTIATION_SCSV が含まれていないことを確認しなければならない．もしこの SCSV が含まれているときは，サーバはハンドシェイクを中断しなければならない．
• サーバは “renegotiation_info” 拡張が含まれている事を確認しなければならない．もし含まれていない場合，サーバはハンドシェイクを中断しなければならない．
• サーバは “renegotiation_connection” の値が保存してある client_verify_data と等しい事を確認しなければならない．もし違う場合，サーバはハンドシェイクを中断しなければならない．
• サーバは，ServerHello で保存した client_verify_data と server_verify_data を含む “renegotiation_info” 拡張を含めなければならない．
• ハンドシェイクが完了したとき，サーバは新しい client_verify_data と server_verify_data の値を保存する必要がある．

この拡張をサポートしない既存の実装は広く使われており，一般的に，この機能をサポートする新しい実装と同時に運用しなければならない．この Section では，下位互換の同時運用で考慮すべき点を述べる．

<color red>怪しげなので英語併記</color>

 If a client offers the "renegotiation_info" extension or the
 TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV and the server does not reply
 with "renegotiation_info" in the ServerHello, then this indicates
 that the server does not support secure renegotiation.  Because some
 attacks (see Section 1) look like a single handshake to the client,
 the client cannot determine whether or not the connection is under
 attack.  Note, however, that merely because the server does not
 acknowledge the extension does not mean that it is vulnerable; it
 might choose to reject all renegotiations and simply not signal it.
 However, it is not possible for the client to determine purely via
 TLS mechanisms whether or not this is the case.

もしクライアントが “renegotiation_info” 拡張もしくは TLS_EMPTY_RENEGOTIATION_SCSV を提示したにも関わらず，サーバが ServerHello に “renegotiation_info” を含めて返事をしてこなかった場合，サーバがセキュアな再ネゴシエーションをサポートしていない事を示す．攻撃の中にはクライアントとの単一のハンドシェイクのように見える物もあるので，クライアントからはコネクションが攻撃下にあるかどうかを見つけ出すことができない．しかし，サーバがこの拡張の応答を返さなかったからといって，それが脆弱であるということは意味しないことに注意する必要がある．全ての再ネゴシエーションを拒絶することを選択しており，単にそれを伝えていないだけかもしれない．しかし，純粋に TLS メカニズム経由でそうであるのかないのかを判断することはできない．

 If clients wish to ensure that such attacks are impossible, they need
 to terminate the connection immediately upon failure to receive the
 extension without completing the handshake.  Such clients MUST
 generate a fatal "handshake_failure" alert prior to terminating the
 connection.  However, it is expected that many TLS servers that do
 not support renegotiation (and thus are not vulnerable) will not
 support this extension either, so in general, clients that implement
 this behavior will encounter interoperability problems.  There is no
 set of client behaviors that will guarantee security and achieve
 maximum interoperability during the transition period.  Clients need
 to choose one or the other preference when dealing with potentially
 un-upgraded servers.

クライアントがこのような攻撃が不可能であることを保証したい場合，拡張の受信が失敗した時点でハンドシェイクを完了させずに接続を即座に切断する必要がある．このようなクライアントはコネクションを終了させる前に致命的である “handshake_failure” 警告を生成しなければならない．しかし，再ネゴシエーションをサポートしない多数の TLS サーバ (つまり脆弱ではない) は，この拡張もサポートしない事が予測されるので，一般的には，このふるまいを実装しているクライアントは相互運用の問題に遭遇するだろう．セキュリティを保証し，移行期の間最大限に相互運用を達成できるクライアントの振るまいは存在しない．潜在的に存在するアップグレードしないサーバに対応する時，クライアントはこれらのふるまいのうちの一つもしくは他の選択をする必要がある．