Internet Engineering Task Force (IETF)                       E. Rescorla
Request for Comments: 5746                                    RTFM, Inc.
Updates: 5246, 4366, 4347, 4346, 2246                             M. Ray
Category: Standards Track                                    S. Dispensa
ISSN: 2070-1721                                              PhoneFactor
                                                                N. Oskov
                                                           February 2010

Transport Layer Security (TLS) Renegotiation Indication Extension




Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack.

セキュア・ソケット・レイヤー(SSL)およびTransport Layer Security(TLS)再ネゴシエーションは、攻撃者は、ターゲット・サーバーとのTLS接続を形成して彼の選択の内容を注入し、クライアントからの新しいTLS接続にスプライスした攻撃に対して脆弱です。サーバが再ネゴシエーションとして、クライアントの初期TLSハンドシェイクを扱うため、攻撃者が送信した初期データは、その後のクライアントデータと同じエンティティからであると考えています。この仕様は、彼らがこのようにして、この攻撃を防ぐ、オーバー実行されているTLS接続に暗号タイ再ネゴシエーションにTLS拡張子を定義します。

Status of This Memo


This is an Internet Standards Track document.


This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース(IETF)の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ(IESG)によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント(に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents


   1. Introduction ....................................................3
   2. Conventions Used in This Document ...............................4
   3. Secure Renegotiation Definition .................................4
      3.1. Additional Connection State ................................4
      3.2. Extension Definition .......................................5
      3.3. Renegotiation Protection Request Signaling Cipher
           Suite Value ................................................6
      3.4. Client Behavior: Initial Handshake .........................6
      3.5. Client Behavior: Secure Renegotiation ......................7
      3.6. Server Behavior: Initial Handshake .........................7
      3.7. Server Behavior: Secure Renegotiation ......................8
   4. Backward Compatibility ..........................................9
      4.1. Client Considerations ......................................9
      4.2. Client Behavior: Legacy (Insecure) Renegotiation ..........10
      4.3. Server Considerations .....................................10
      4.4. Server Behavior: Legacy (Insecure) Renegotiation ..........11
      4.5. SSLv3 .....................................................11
   5. Security Considerations ........................................12
   6. IANA Considerations ............................................13
   7. Acknowledgements ...............................................13
   8. References .....................................................13
      8.1. Normative References ......................................13
      8.2. Informative References ....................................13
1. Introduction
1. はじめに

TLS [RFC5246] allows either the client or the server to initiate renegotiation -- a new handshake that establishes new cryptographic parameters. Unfortunately, although the new handshake is carried out using the cryptographic parameters established by the original handshake, there is no cryptographic binding between the two. This creates the opportunity for an attack in which the attacker who can intercept a client's transport layer connection can inject traffic of his own as a prefix to the client's interaction with the server. One form of this attack [Ray09] proceeds as shown below:

新しい暗号化パラメータを確立し、新たな握手 - TLS [RFC5246]は、クライアントまたはサーバが再交渉を開始することを可能にします。新しいハンドシェイクは、オリジナルのハンドシェイクによって確立された暗号化パラメータを用いて行われるが、残念ながら、2間の結合一切の暗号はありません。これは、クライアントのトランスポート層接続を傍受することができ、攻撃者がサーバーとクライアントの相互作用のプレフィックスとして彼自身のトラフィックを注入可能な攻撃の機会を作成します。この攻撃[Ray09】進行の一の形態を以下に示すとおり

   Client                        Attacker                        Server
   ------                        -------                         ------
                                     <----------- Handshake ---------->
                                     <======= Initial Traffic ========>
   <--------------------------  Handshake ============================>
   <======================== Client Traffic ==========================>

To start the attack, the attacker forms a TLS connection to the server (perhaps in response to an initial intercepted connection from the client). He then sends any traffic of his choice to the server. This may involve multiple requests and responses at the application layer, or may simply be a partial application layer request intended to prefix the client's data. This traffic is shown with == to indicate it is encrypted. He then allows the client's TLS handshake to proceed with the server. The handshake is in the clear to the attacker but encrypted over the attacker's TLS connection to the server. Once the handshake has completed, the client communicates with the server over the newly established security parameters with the server. The attacker cannot read this traffic, but the server believes that the initial traffic to and from the attacker is the same as that to and from the client.


If certificate-based client authentication is used, the server will see a stream of bytes where the initial bytes are protected but unauthenticated by TLS and subsequent bytes are authenticated by TLS and bound to the client's certificate. In some protocols (notably HTTPS), no distinction is made between pre- and post-authentication stages and the bytes are handled uniformly, resulting in the server believing that the initial traffic corresponds to the authenticated client identity. Even without certificate-based authentication, a variety of attacks may be possible in which the attacker convinces the server to accept data from it as data from the client. For instance, if HTTPS [RFC2818] is in use with HTTP cookies [RFC2965], the attacker may be able to generate a request of his choice validated by the client's cookie.

証明書ベースのクライアント認証を使用する場合、サーバーは最初のバイトはTLSによって認証され、クライアントの証明書にバインドされている保護されたが、TLSとその後のバイトによって認証されていないされているバイトのストリームが表示されます。いくつかのプロトコル(特にHTTPS)において、区別は前後の認証段階の間に行われず、バイトが最初のトラフィックが認証されたクライアントIDに対応していることを信じるサーバで、その結果、均一に処理されます。でも、証明書ベースの認証なしに、さまざまな攻撃は、攻撃者がクライアントからのデータと、それからのデータを受け入れるようにサーバーを説得することも可能です。 HTTPS [RFC2818]はHTTPクッキー[RFC2965]で使用している場合たとえば、攻撃者は、クライアントのクッキーによって検証彼の選択の要求を生成することができるかもしれません。

Some protocols -- such as IMAP or SMTP -- have more explicit transitions between authenticated and unauthenticated phases and require that the protocol state machine be partly or fully reset at such transitions. If strictly followed, these rules may limit the effect of attacks. Unfortunately, there is no requirement for state machine resets at TLS renegotiation, and thus there is still a potential window of vulnerability, for instance, by prefixing a command that writes to an area visible by the attacker with a command by the client that includes his password, thus making the client's password visible to the attacker (note that this precise attack does not work with challenge-response authentication schemes, but other attacks may be possible). Similar attacks are available with SMTP, and in fact do not necessarily require the attacker to have an account on the target server.

いくつかのプロトコル - 例えばIMAPやSMTPなど - は認証され、認証されていない相の間のより明確な遷移を有し、プロトコル状態機械は、部分的に又は完全にそのような遷移時にリセットされることを必要とします。厳密に従っている場合、これらのルールは、攻撃の効果を制限する可能性があります。残念ながら、TLS再ネゴシエーションのステート・マシンがリセットのための要件が​​ないため、例えば、含むクライアントによってコマンドを使用して、攻撃者によって表示領域に書き込みコマンドを付けることによって、まだ脆弱性の電位窓があり、彼パスワード、これ攻撃者にクライアントのパスワードを可視化(この正確な攻撃がチャレンジレスポンス認証方式では動作しませんのでご注意ますが、他の攻撃が可能かもしれません)。同様の攻撃はSMTPで利用可能であり、実際には必ずしもターゲットサーバのアカウントを持っている攻撃者を必要としません。

It is important to note that in both cases these attacks are possible because the client sends unsolicited authentication information without requiring any specific data from the server over the TLS connection. Protocols that require a round trip to the server over TLS before the client sends sensitive information are likely to be less vulnerable.


These attacks can be prevented by cryptographically binding renegotiation handshakes to the enclosing TLS cryptographic parameters, thus allowing the server to differentiate renegotiation from initial negotiation, as well as preventing renegotiations from being spliced in between connections. An attempt by an attacker to inject himself as described above will result in a mismatch of the cryptographic binding and can thus be detected. The data used in the extension is similar to, but not the same as, the data used in the tls-unique and/or tls-unique-for-telnet channel bindings described in [TLS-CHANNEL-BINDINGS]; however, this extension is not a general-purpose RFC 5056 [RFC5056] channel binding facility.

これらの攻撃は、このように、サーバが初期ネゴシエーションから再交渉を区別することができ、ならびに接続間でスプライシングされてから再交渉を防止する、封入TLS暗号パラメータと、暗号バインディング再ネゴシエーションハンドシェイクによって防止することができます。上記のように自分自身を注入する攻撃者による試みは、暗号結合の不整合になり、したがって、検出することができます。拡張で使用されるデータは次のように、しかし[TLSチャネルバインディング]に記載ユニークTLS-及び/又はため、telnetの固有-TLSチャネルバインディングで使用されるデータと同じではありません。ただし、この拡張は、汎用RFC 5056 [RFC5056]のチャネル結合機構はありません。

2. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。

3. Secure Renegotiation Definition
3.1. Additional Connection State
3.1. 追加の接続状態

Both client and server need to store three additional values for each TLS connection state (see RFC 5246, Section 6.1). Note that these values are specific to connection (not a TLS session cache entry).

クライアントとサーバの両方が(RFC 5246、セクション6.1を参照)、各TLS接続状態のための3つの追加の値を格納する必要があります。これらの値は、接続(ないTLSセッションキャッシュエントリ)に固有であることに注意してください。

o a "secure_renegotiation" flag, indicating whether secure renegotiation is in use for this connection.

I S「安全な再ネゴシエーション」フラグ、安全な再ネゴシエーションが、この接続のために使用されているか否かを示します。

o "client_verify_data": the verify_data from the Finished message sent by the client on the immediately previous handshake. For currently defined TLS versions and cipher suites, this will be a 12-byte value; for SSLv3, this will be a 36-byte value.

O「client_verify_data」:直前の握手にクライアントから送信されたFinishedメッセージからverify_data。現在定義されているTLSバージョンと暗号スイートの場合、これは12バイトの値となります。 SSLv3のために、これは36バイトの値になります。

o "server_verify_data": the verify_data from the Finished message sent by the server on the immediately previous handshake.


3.2. Extension Definition
3.2. 拡張定義

This document defines a new TLS extension, "renegotiation_info" (with extension type 0xff01), which contains a cryptographic binding to the enclosing TLS connection (if any) for which the renegotiation is being performed. The "extension data" field of this extension contains a "RenegotiationInfo" structure:


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

The contents of this extension are specified as follows.


o If this is the initial handshake for a connection, then the "renegotiated_connection" field is of zero length in both the ClientHello and the ServerHello. Thus, the entire encoding of the extension is ff 01 00 01 00. The first two octets represent the extension type, the third and fourth octets the length of the extension itself, and the final octet the zero length byte for the "renegotiated_connection" field.

これは接続のための初期ハンドシェークの場合、O、次いで「renegotiated_connection」フィールドはのClientHelloとのServerHello両方におけるゼロ長さのものです。このように、延長部の全体の符号化は、最初の2つのオクテットが「renegotiated_connection」フィールドの拡張タイプ、第三及び第四オクテット拡張自体の長さ、及び最終的なオクテット長さがゼロのバイトを表すFF 01 00 01 00であります。

o For ClientHellos that are renegotiating, this field contains the "client_verify_data" specified in Section 3.1.


o For ServerHellos that are renegotiating, this field contains the concatenation of client_verify_data and server_verify_data. For current versions of TLS, this will be a 24-byte value (for SSLv3, it will be a 72-byte value).

O再交渉されているServerHellosの場合、このフィールドはclient_verify_dataとserver_verify_dataの連結が含まれています。 TLSの現在のバージョンでは、これは24バイトの値(のSSLv3ために、それは72バイトの値となる)であろう。

This extension also can be used with Datagram TLS (DTLS) [RFC4347]. Although, for editorial simplicity, this document refers to TLS, all requirements in this document apply equally to DTLS.

この拡張はまた、データグラムTLS(DTLS)[RFC4347]と一緒に使用することができます。 、社説簡単にするために、このドキュメントはTLSに言及しているが、この文書のすべての要件は、DTLSにも同様に適用されます。

3.3. Renegotiation Protection Request Signaling Cipher Suite Value
3.3. 再交渉の保護要求シグナリング暗号スイート値

Both the SSLv3 and TLS 1.0/TLS 1.1 specifications require implementations to ignore data following the ClientHello (i.e., extensions) if they do not understand it. However, some SSLv3 and TLS 1.0 implementations incorrectly fail the handshake in such a case. This means that clients that offer the "renegotiation_info" extension may encounter handshake failures. In order to enhance compatibility with such servers, this document defines a second signaling mechanism via a special Signaling Cipher Suite Value (SCSV) "TLS_EMPTY_RENEGOTIATION_INFO_SCSV", with code point {0x00, 0xFF}. This SCSV is not a true cipher suite (it does not correspond to any valid set of algorithms) and cannot be negotiated. Instead, it has the same semantics as an empty "renegotiation_info" extension, as described in the following sections. Because SSLv3 and TLS implementations reliably ignore unknown cipher suites, the SCSV may be safely sent to any server. The SCSV can also be included in the SSLv2 backward compatible CLIENT-HELLO (see Appendix E.2 of [RFC5246]).

SSLv3およびTLS 1.0 / TLSの両方が1.1の仕様は、彼らがそれを理解していない場合のClientHello(すなわち、拡張)次のデータを無視するように実装する必要があります。しかし、いくつかのSSLv3およびTLS 1.0実装が誤ってこのような場合にハンドシェイクに失敗します。これは、「renegotiation_info」の拡張子を提供し、クライアントがハンドシェイクの失敗が発生する可能性があることを意味します。そのようなサーバとの互換性を高めるために、この文書は、コードポイント{0x00で、0xFFを}と、特別なシグナリング暗号スイート値(SCSV)「TLS_EMPTY_RENEGOTIATION_INFO_SCSV」を介して第2のシグナリングメカニズムを定義します。このSCSVは真の暗号スイートではありません(それはアルゴリズムの任意の有効なセットに対応していない)と交渉することはできません。次のセクションで説明するように代わりに、それは、空の「renegotiation_info」の拡張子と同じ意味を持っています。 SSLv3とTLSの実装は確実に未知の暗号スイートを無視しているので、SCSVは安全に任意のサーバに送信することができます。 SCSVはまた、([RFC5246]の付録E.2参照)SSLv2の後方互換性のあるクライアントハローに含めることができます。

Note: a minimal client that does not support renegotiation at all can simply use the SCSV in all initial handshakes. The rules in the following sections will cause any compliant server to abort the handshake when it sees an apparent attempt at renegotiation by such a client.


3.4. Client Behavior: Initial Handshake
3.4. クライアントの動作:初期ハンドシェイク

Note that this section and Section 3.5 apply to both full handshakes and session resumption handshakes.


o The client MUST include either an empty "renegotiation_info" extension, or the TLS_EMPTY_RENEGOTIATION_INFO_SCSV signaling cipher suite value in the ClientHello. Including both is NOT RECOMMENDED.


o When a ServerHello is received, the client MUST check if it includes the "renegotiation_info" extension:


* If the extension is not present, the server does not support secure renegotiation; set secure_renegotiation flag to FALSE. In this case, some clients may want to terminate the handshake instead of continuing; see Section 4.1 for discussion.

*拡張子が存在しない場合、サーバは安全な再ネゴシエーションをサポートしていません。 FALSEにsecure_renegotiationフラグを設定します。この場合、一部のクライアントが継続するのではなく、ハンドシェイクを終了することもできます。議論のためのセクション4.1を参照してください。

* If the extension is present, set the secure_renegotiation flag to TRUE. The client MUST then verify that the length of the "renegotiated_connection" field is zero, and if it is not, MUST abort the handshake (by sending a fatal handshake_failure alert).


Note: later in Section 3, "abort the handshake" is used as shorthand for "send a fatal handshake_failure alert and terminate the connection".


o When the handshake has completed, the client needs to save the client_verify_data and server_verify_data values for future use.


3.5. Client Behavior: Secure Renegotiation
3.5. クライアントの動作:セキュア再ネゴシエーション

This text applies if the connection's "secure_renegotiation" flag is set to TRUE (if it is set to FALSE, see Section 4.2).


o The client MUST include the "renegotiation_info" extension in the ClientHello, containing the saved client_verify_data. The SCSV MUST NOT be included.

Oクライアントが保存されてclient_verify_dataを含むのClientHelloで「renegotiation_info」の拡張子を含まなければなりません。 SCSVを含んではいけません。

o When a ServerHello is received, the client MUST verify that the "renegotiation_info" extension is present; if it is not, the client MUST abort the handshake.


o The client MUST then verify that the first half of the "renegotiated_connection" field is equal to the saved client_verify_data value, and the second half is equal to the saved server_verify_data value. If they are not, the client MUST abort the handshake.


o When the handshake has completed, the client needs to save the new client_verify_data and server_verify_data values.


3.6. Server Behavior: Initial Handshake
3.6. サーバーの動作:初期ハンドシェイク

Note that this section and Section 3.7 apply to both full handshakes and session-resumption handshakes.


o When a ClientHello is received, the server MUST check if it includes the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. If it does, set the secure_renegotiation flag to TRUE.

ClientHelloを受信した場合、それはTLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSVが含まれている場合は、O、サーバがチェックしなければなりません。それがない場合は、TRUEにsecure_renegotiationフラグを設定します。

o The server MUST check if the "renegotiation_info" extension is included in the ClientHello. If the extension is present, set secure_renegotiation flag to TRUE. The server MUST then verify that the length of the "renegotiated_connection" field is zero, and if it is not, MUST abort the handshake.


o If neither the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV nor the "renegotiation_info" extension was included, set the secure_renegotiation flag to FALSE. In this case, some servers may want to terminate the handshake instead of continuing; see Section 4.3 for discussion.

TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSVも「renegotiation_info」拡張子のいずれもが含まれている場合は、O、FALSEにsecure_renegotiationフラグを設定します。この場合、一部のサーバーが継続するのではなく、ハンドシェイクを終了することもできます。議論のためのセクション4.3を参照してください。

o If the secure_renegotiation flag is set to TRUE, the server MUST include an empty "renegotiation_info" extension in the ServerHello message.


o When the handshake has completed, the server needs to save the client_verify_data and server_verify_data values for future use.


TLS servers implementing this specification MUST ignore any unknown extensions offered by the client and they MUST accept version numbers higher than their highest version number and negotiate the highest common version. These two requirements reiterate preexisting requirements in RFC 5246 and are merely stated here in the interest of forward compatibility.

この仕様を実装するTLSサーバは、クライアントが提供するすべての未知の拡張を無視しなければならないと、彼らは彼らの最高のバージョン番号より高いバージョン番号を受け入れて、最高の一般的なバージョンを交渉しなければなりません。これらの2つの要件がRFC 5246で既存の要件を改めて表明し、単に前方互換性の利益のためにここに記載されています。

Note that sending a "renegotiation_info" extension in response to a ClientHello containing only the SCSV is an explicit exception to the prohibition in RFC 5246, Section, on the server sending unsolicited extensions and is only allowed because the client is signaling its willingness to receive the extension via the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. TLS implementations MUST continue to comply with Section for all other extensions.

ClientHelloに応じて「renegotiation_info」の拡張子を送信することだけSCSVはRFC 5246での禁止を明示的に例外で含むことに注意してください、セクション7.4.1.4、サーバー上で迷惑拡張を送信し、クライアントがその意思をシグナリングしているためにのみ許可されていますTLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV経由で拡張を受信します。 TLSの実装は、他のすべての拡張機能については、セクション7.4.1.4に準拠し続けなければなりません。

3.7. Server Behavior: Secure Renegotiation
3.7. サーバーの動作:セキュア再ネゴシエーション

This text applies if the connection's "secure_renegotiation" flag is set to TRUE (if it is set to FALSE, see Section 4.4).


o When a ClientHello is received, the server MUST verify that it does not contain the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. If the SCSV is present, the server MUST abort the handshake.

ClientHelloを受信した場合、O、サーバはそれがTLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSVが含まれていないことを確かめなければなりません。 SCSVが存在する場合、サーバは握手を中止しなければなりません。

o The server MUST verify that the "renegotiation_info" extension is present; if it is not, the server MUST abort the handshake.


o The server MUST verify that the value of the "renegotiated_connection" field is equal to the saved client_verify_data value; if it is not, the server MUST abort the handshake.


o The server MUST include a "renegotiation_info" extension containing the saved client_verify_data and server_verify_data in the ServerHello.


o When the handshake has completed, the server needs to save the new client_verify_data and server_verify_data values.


4. Backward Compatibility

Existing implementations that do not support this extension are widely deployed and, in general, must interoperate with newer implementations that do support it. This section describes considerations for backward compatible interoperation.


4.1. Client Considerations
4.1. クライアントの考慮事項

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_INFO_SCSV SCSVを提供し、サーバはServerHelloメッセージで「renegotiation_info」と応答しない場合、これは、サーバーが安全な再ネゴシエーションをサポートしていないことを示しています。いくつかの攻撃は(セクション1を参照)、クライアントに単一のハンドシェイクのように見えるので、クライアントは接続が攻撃を受けているかどうかを判断することはできません。サーバが認めていないため、単に拡張子はそれが脆弱であることを意味しないこと、しかし、注意してください。それは、すべての再交渉を拒否することを選択すると、単純にそれを通知しない場合があります。しかし、クライアントがそうであるか否かの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.


4.2. Client Behavior: Legacy (Insecure) Renegotiation
4.2. クライアントの動作:レガシー(安全でない)再交渉

This text applies if the connection's "secure_renegotiation" flag is set to FALSE.


It is possible that un-upgraded servers will request that the client renegotiate. It is RECOMMENDED that clients refuse this renegotiation request. Clients that do so MUST respond to such requests with a "no_renegotiation" alert (RFC 5246 requires this alert to be at the "warning" level). It is possible that the apparently un-upgraded server is in fact an attacker who is then allowing the client to renegotiate with a different, legitimate, upgraded server. If clients nevertheless choose to renegotiate, they MUST behave as described below.

非アップグレードサーバは、クライアントが再交渉することを要求する可能性があります。クライアントがこの再交渉要求を拒否することが推奨されます。そうするクライアントは、「no_renegotiation」警告(RFC 5246には、「警告」レベルになるように、このアラートが必要)で、このような要求に応答しなければなりません。明らかに非アップグレードしたサーバは、クライアントが異なる、正当な、アップグレードされたサーバーとの再交渉することができますされ、攻撃者が実際にあることも可能です。クライアントはそれにもかかわらず、再交渉することを選択した場合は後述のように、彼らが振る舞う必要があります。

Clients that choose to renegotiate MUST provide either the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV or "renegotiation_info" in their ClientHello. In a legitimate renegotiation with an un-upgraded server, that server should ignore both of these signals. However, if the server (incorrectly) fails to ignore extensions, sending the "renegotiation_info" extension may cause a handshake failure. Thus, it is permitted, though NOT RECOMMENDED, for the client to simply send the SCSV. This is the only situation in which clients are permitted to not send the "renegotiation_info" extension in a ClientHello that is used for renegotiation.

再交渉することを選択したクライアントは、TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSVまたはそののClientHelloで「renegotiation_info」のいずれかを提供しなければなりません。未アップグレードサーバと正当な再交渉において、そのサーバは、これらの信号の両方を無視すべきです。ただし、サーバーが(間違って)ハンドシェイクの失敗を引き起こす可能性があり、「renegotiation_info」の拡張子を送信する、拡張子を無視に失敗した場合。したがって、単にSCSVを送信するために、クライアントのために、推奨されていないが、許可されています。これは、クライアントが再交渉のために使用されたClientHelloに「renegotiation_info」の拡張子を送信しないことが許可されている唯一の状況です。

Note that in the case of a downgrade attack, if this is an initial handshake from the server's perspective, then use of the SCSV from the client precludes detection of this attack by the server (if this is a renegotiation from the server's perspective, then it will detect the attack). However, the attack will be detected by the client when the server sends an empty "renegotiation_info" extension and the client is expecting one containing the previous verify_data. By contrast, if the client sends the "renegotiation_info" extension, then the server will immediately detect the attack.


When the ServerHello is received, the client MUST verify that it does not contain the "renegotiation_info" extension. If it does, the client MUST abort the handshake. (Because the server has already indicated it does not support secure renegotiation, the only way that this can happen is if the server is broken or there is an attack.)

ServerHelloを受信した場合、クライアントは、それが「renegotiation_info」の拡張子が含まれていないことを確かめなければなりません。それがない場合、クライアントは握手を中止しなければなりません。 (サーバはすでにそれが安全な再ネゴシエーションをサポートしていない示しているので、サーバーが壊れているか、攻撃が行われている場合は、これが起こることを唯一の方法です。)

4.3. Server Considerations
4.3. サーバーの考慮事項

If the client does not offer the "renegotiation_info" extension or the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV, then this indicates that the client does not support secure renegotiation. Although the attack described in Section 1 looks like two handshakes to the

クライアントが「renegotiation_info」拡張子やTLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSVを提供していない場合、これはクライアントが安全な再ネゴシエーションをサポートしていないことを示しています。第1節で説明した攻撃は、には2つのハンドシェイクのように見えますが、

server, other attacks may be possible in which the renegotiation is seen only by the client. If servers wish to ensure that such attacks are impossible, they need to terminate the connection immediately upon failure to negotiate the use of secure renegotiation. Servers that do choose to allow connections from unpatched clients can still prevent the attack described in Section 1 by refusing to renegotiate over those connections.


In order to enable clients to probe, even servers that do not support renegotiation MUST implement the minimal version of the extension described in this document for initial handshakes, thus signaling that they have been upgraded.


4.4. Server Behavior: Legacy (Insecure) Renegotiation
4.4. サーバーの動作:レガシー(安全でない)再交渉

This text applies if the connection's "secure_renegotiation" flag is set to FALSE.


It is RECOMMENDED that servers not permit legacy renegotiation. If servers nevertheless do permit it, they MUST follow the requirements in this section.


o When a ClientHello is received, the server MUST verify that it does not contain the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. If the SCSV is present, the server MUST abort the handshake.

ClientHelloを受信した場合、O、サーバはそれがTLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSVが含まれていないことを確かめなければなりません。 SCSVが存在する場合、サーバは握手を中止しなければなりません。

o The server MUST verify that the "renegotiation_info" extension is not present; if it is, the server MUST abort the handshake.


4.5. SSLv3
4.5. SSLv3

While SSLv3 is not a protocol under IETF change control (see [SSLv3]), it was the original basis for TLS and most TLS implementations also support SSLv3. The IETF encourages SSLv3 implementations to adopt the "renegotiation_info" extension and SCSV as defined in this document. The semantics of the SCSV and extension are identical to TLS stacks except for the size of the verify_data values, which are 36 bytes long each. Note that this will require adding at least minimal extension processing to such stacks. Clients that support SSLv3 and offer secure renegotiation (either via SCSV or "renegotiation_info") MUST accept the "renegotiation_info" extension from the server, even if the server version is {0x03, 0x00}, and behave as described in this specification. TLS servers that support secure renegotiation and support SSLv3 MUST accept SCSV or the "renegotiation_info" extension and respond as described in this specification even if the offered client version is {0x03, 0x00}. SSLv3 does not define the "no_renegotiation" alert (and does not offer a way to indicate a refusal to renegotiate at a "warning" level). SSLv3 clients that refuse renegotiation SHOULD use a fatal handshake_failure alert.

SSLv3は([のSSLv3]参照)IETF変更制御下プロトコルではありませんが、それはTLSの元の基礎であり、ほとんどのTLSの実装ものSSLv3をサポートします。 IETFは、この文書で定義されている「renegotiation_info」拡張子とSCSVを採用するのSSLv3実装を奨励しています。 TLSは、各36バイト長であるverify_data値の大きさを除いてスタックにSCSV及び拡張の意味は同一です。このようなスタックに少なくとも最小の伸長処理を追加する必要があることに注意してください。 SSLv3をサポートし、安全な再交渉を提供する(いずれかSCSV又は「renegotiation_info」を介して)クライアントは、サーバから「renegotiation_info」拡張子を受け入れるサーバのバージョンであっても、{0x03の、0x00を}、及び本明細書に記載されるように動作しなければなりません。安全な再交渉やサポートのSSLv3をサポートするTLSサーバはSCSVまたは「renegotiation_info」の拡張子を受け入れ、この仕様書で説明するように提供されたクライアントのバージョンがある場合にも対応{0x03を、0x00の}しなければなりません。 SSLv3は「no_renegotiation」アラートを定義していない(と「警告」レベルで再交渉の拒否を指示する方法を提供していません)。再交渉を拒否するのSSLv3クライアントは、致命的な握手_アラートを使用すべきです。

5. Security Considerations

The extension described in this document prevents an attack on TLS. If this extension is not used, TLS renegotiation is subject to an attack in which the attacker can inject their own conversation with the TLS server as a prefix to the client's conversation. This attack is invisible to the client and looks like an ordinary renegotiation to the server. The extension defined in this document allows renegotiation to be performed safely. Servers SHOULD NOT allow clients to renegotiate without using this extension. Many servers can mitigate this attack simply by refusing to renegotiate at all.


While this extension mitigates the man-in-the-middle attack described in the overview, it does not resolve all possible problems an application may face if it is unaware of renegotiation. For example, during renegotiation, either the client or the server can present a different certificate than was used earlier. This may come as a surprise to application developers (who might have expected, for example, that a "getPeerCertificates()" API call returns the same value if called twice), and might be handled in an insecure way.


TLS implementations SHOULD provide a mechanism to disable and enable renegotiation.


TLS implementers are encouraged to clearly document how renegotiation interacts with the APIs offered to applications (for example, which API calls might return different values on different calls, or which callbacks might get called multiple times).


To make life simpler for applications that use renegotiation but do not expect the certificate to change once it has been authenticated, TLS implementations may also wish to offer the applications the option to abort the renegotiation if the peer tries to authenticate with a different certificate and/or different server name (in the server_name extension) than was used earlier. TLS implementations may alternatively offer the option to disable renegotiation once the client certificate has been authenticated. However, enabling these options by default for all applications could break existing applications that depend on using renegotiation to change from one certificate to another. (For example, long-lived TLS connections could change to a renewed certificate; or renegotiation could select a different cipher suite that requires using a different certificate.)

再ネゴシエーションを使用しますが、それが認証された後、証明書を変更するには期待していないアプリケーションのためのシンプルな生活を作るために、TLSの実装はまた、ピアが異なる証明書で認証しようとすると、アプリケーションに再交渉を中止するオプションを提供することを望むかもしれないと/以前に使用されたよりも、(サーバー名の拡張子で)、または別のサーバー名。 TLSの実装は、代わりにクライアント証明書が認証された後再ネゴシエーションを無効にするオプションを提供することがあります。ただし、すべてのアプリケーションのために、デフォルトでは、これらのオプションを有効にすると、別の証明書から変更するには再交渉を使用してに依存する既存のアプリケーションを中断する可能性があります。 (例えば、長寿命のTLS接続が更新された証明書を変更することができ、または再ネゴシエーション異なる証明書を使用する必要が異なる暗号スイートを選択することができます。)

Finally, designers of applications that depend on renegotiation are reminded that many TLS APIs represent application data as a simple octet stream; applications may not be able to determine exactly which application data octets were received before, during, or after renegotiation. Especially if the peer presents a different certificate during renegotiation, care is needed when specifying how the application should handle the data.

最後に、再交渉に依存するアプリケーションの設計者は、多くのTLS APIは、単純なオクテットストリームなどのアプリケーションデータを表すことを思い出しています。アプリケーションは、データオクテットが中、または再交渉の後、前に受信されたアプリケーションを正確に決定することができない場合があります。ピアは再ネゴシエーション中に異なる証明書を提示する場合は特に、アプリケーションがデータをどのように処理するかを指定する際に、注意が必要とされています。

6. IANA Considerations
6. IANAの考慮事項

IANA has added the extension code point 65281 (0xff01), which has been used for prototype implementations, for the "renegotiation_info" extension to the TLS ExtensionType values registry.

IANAは、TLS ExtensionType値レジストリに「renegotiation_info」拡張のために、プロトタイプの実装のために使用されている拡張コードポイント65281(0xff01)を加えました。

IANA has added TLS cipher suite number 0x00,0xFF with name TLS_EMPTY_RENEGOTIATION_INFO_SCSV to the TLS Cipher Suite registry.


7. Acknowledgements

This vulnerability was originally discovered by Marsh Ray and independently rediscovered by Martin Rex. The general concept behind the extension described here was independently invented by Steve Dispensa, Nasko Oskov, and Eric Rescorla with refinements from Nelson Bolyard, Pasi Eronen, Michael D'Errico, Stephen Farrell, Michael Gray, David-Sarah Hopwood, Ben Laurie, David Makepeace, Bodo Moeller, Martin Rex, Peter Robinson, Jesse Walker, Nico Williams, and other members of the Project Mogul team and the TLS WG.

この脆弱性は、もともとマーシュレイによって発見され、独立してマーティン・レックスによって再発見されました。ここで説明する拡張機能の背後にある一般的な概念は、独立ネルソンBolyard、パシEronen、マイケルD'エリコ、スティーブン・ファレル、マイケル・グレイ、デビッド・サラ・ホップウッド、ベン・ローリー、デビッドからの改良でスティーブDispensa、Nasko Oskov、そしてエリックレスコラによって発明されましたメイクピース、ボードーメラー、マーティン・レックス、ピーター・ロビンソン、ジェシーウォーカー、ニコ・ウィリアムズ、およびプロジェクトモーグルチームの他のメンバーとTLS WG。

8. References
8.1. Normative References
8.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ(TLS)プロトコルバージョン1.2"、RFC 5246、2008年8月。

8.2. Informative References
8.2. 参考文献

[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.

[RFC4347]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。

[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.

"チャネルを確保するチャネルバインディングの使用について" [RFC5056]ウィリアムズ、N.、RFC 5056、2007年11月。

[TLS-CHANNEL-BINDINGS] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", Work in Progress, October 2009.

[TLS-CHANNEL-BINDINGS]アルトマン、J.、ウィリアムズ、N.、およびL.朱、 "TLSのためのチャネルバインディング"、進歩、2009年10月に作業。

[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[RFC2818]レスコラ、E.、 "TLSオーバーHTTP"、RFC 2818、2000年5月。

[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.

[RFC2965]クリストル、D.およびL. Montulli、 "HTTP状態管理機構"、RFC 2965、2000年10月。

[Ray09] Ray, M., "Authentication Gap in TLS Renegotiation", November 2009, <>.

【Ray09]レイ、M.、 "TLS再ネゴシエーション中に、認証ギャップ" 2009年11月、<>。

[SSLv3] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol Version 3.0", Work in Progress, November 1996.

[のSSLv3]フライアー、A.、Karlton、P.、およびP.コッヘル、 "SSLプロトコルバージョン3.0"、進歩、1996年11月での作業。

Authors' Addresses


Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA

エリックレスコラRTFM、Inc.の2064エッジウッドドライブパロアルト、CA 94303 USA



Marsh Ray PhoneFactor 7301 W 129th Street Overland Park, KS 66213 USA

129番目のストリートオーバーランドパーク、KS 66213 USA WマーシュレイPhoneFactor 7301



Steve Dispensa PhoneFactor 7301 W 129th Street Overland Park, KS 66213 USA

スティーブDispensa PhoneFactor 7301 W 129通りオーバーランドパーク、カンザス州66213 USA



Nasko Oskov Microsoft One Microsoft Way Redmond, WA 98052 USA

Nasko Oskovaマイクロソフト1マイクロソフト道、レッドモンド、ワシントン98052 USA