|
Internet Engineering Task Force (IETF) Request for Comments： 5746 Updates: 5246, 4366, 4347, 4346, 2246 分類： スタンダードトラック ISSN: 2070-1721 |
E. Rescorla RTFM, Inc. M. Ray S. Dispensa PhoneFactor N. Oskov Microsoft. 2010年2月 |
(作業中)
English(作業中)
SSL (Secure Socket Layer)とTLS (Transport Layer
Security)再交渉(renegotiation)は、ある攻撃に対して脆弱である。
その攻撃においては、攻撃者は、
標的とするサーバとのTLSコネクションを形成し、
of his choice
contentを注入し、
そして、クライアントからの新しいTLSコネクション中につなぎ合わせる。
そのサーバは、クライアントの初期TLSハンドシェイクを再交渉として扱い、
それゆえ、
「攻撃者によって転送された初期データは、
the subsequentクライアントデータと同一主体からのものである」と信じる。
この仕様は、暗号技術的に再交渉を
they are being performed over
the TLSコネクションsに結びつけるTLS拡張を定義するので、
この攻撃を防ぐ。
これは、Internet Standards Track documentである。
本書は、IETF (Internet Engineering Task Force)の成果物である。 これは、IETFコミュニティのコンセンサスを表現している。 これは、パブリックレビューを受け、IESG (Internet Engineering Steering Group)によって発行を承認されたものである。 Internet Standards についての詳細は、RFC 5741の2章から得られる。
本書の現在の位置づけ(status)についての情報、 あらゆる誤記(errata)および「どのように、これについてフィードバックを提供するか？」は、 「http://www.rfc-editor.org/info/rfc6066」から入手できる。
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
本書は、本書の発行日において有効なIETF Documents (http://trustee.ietf.org/license-info)に関するBCP 78およびIETF Trustの法的規制の対象となる。 これらの文書を注意深く読み返していただきたい。 なぜならば、それらは、 本書に関するあなたの権利と制約を記述しているからである。 本書から抽出されたコードComponentsは、 Trust Legal Provisionsの4.e節に記述されているようにSimplified BSD License textを含まなければならないし、 Simplified BSD Licenseに記述されているように保証なしで提供されなければならない。
(作業中)
TLS [RFC5246] は、
クライアントかあるいはサーバのいずれかが、
再交渉(新しい暗号技術的パラメータを確立する新しいハンドシェイク)を開始できるようにする。
残念ながら、新しいハンドシェイクは、
当初のハンドシェイクによって確立された暗号技術的パラメータを使って行われるが、
両者の間に暗号技術的bindingは無い。
これは、
in which the 攻撃者 who can
intercept a クライアントの transport layer connection can inject
traffic of
his own as a prefix to the クライアントの interaction with the サーバ
an攻撃の機会を創り出す。
この攻撃 [Ray09] の一形態は、
下記のように進行する。：
Client Attacker Server
------ ------- ------
<----------- Handshake ---------->
<======= Initial Traffic ========>
<-------------------------- Handshake ============================>
<======================== Client Traffic ==========================>
この攻撃を開始するために、攻撃者は、
forms a TLS コネクション to the サーバ
(perhaps in response to an initial intercepted connection from
the クライアント)。
彼は、次に、
any traffic of his choice to the サーバ
を送る。これは、
may involve multiple requests and responses at the application
layer,
or may simply be a partial application layer request intended
to prefix the クライアントのデータ。
この traffic は、
it is encrypted
を示すために、「==」と共に示されている。彼は、次に、
allows the クライアントのTLSハンドシェイク
to proceed with the サーバ。
そのハンドシェイクは、
is in the clear to the 攻撃者
but encrypted over the 攻撃者の TLS コネクション to the
サーバ。
ひとたび、そのハンドシェイクが完了すると、そのクライアントは、
over the newly established セキュリティ パラメータs with
the サーバ
the サーバと通信する。
攻撃者は、この traffic を読めないが、そのサーバは、
「the initial traffic to and from the 攻撃者
は、
is the same as that to and from the クライアント」
と信じる。
証明書-basedクライアント認証(authentication)が使われている場合、
そのサーバは、
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 クライアントの証明書。
In some プロトコルs (notably HTTPS),
no distinction is made between pre- and post-authentication
stages and the bytes are handled uniformly,
resulting in the サーバbelieving that the initial traffic
corresponds to the authenticated クライアント identity。
Even without 証明書-based 認証,
多様な攻撃
in which the 攻撃者 convinces the サーバ to accept データ from
it as データ from the クライアント
が可能である可能性がある。
例えば、HTTPS [RFC2818] が HTTP
cookies [RFC2965] と共に使われている場合、
その攻撃者は、
a request を
of his choice validated by the クライアントの cookie
生成できる可能性がある。
(IMAPもしくはSMTPのような)プロトコルには、
more explicit transitions between authenticated and
unauthenticated phases
をもち、
require that 「the プロトコル state machine be partly or fully
reset at such transitions」
ものがある。
厳密に従った場合、これらのルールは、
攻撃の影響を制限する可能性がある。
残念ながら、
there is no requirement for state machine resets at TLS 再交渉。
そして、それゆえ、
there is still a potential window of 脆弱性,
例えば、
by prefixing a command that writes to an area visible by the 攻
撃者 with a command by the クライアント that includes his
password,
thus making the クライアントのpassword visible to the 攻撃者
(「この precise 攻撃は、challenge-response authentication schemes
では作用しないが、他の攻撃は、
be possible
可能性があること」に注意)。
同様の攻撃は、
are available with SMTP,
and in fact do not necessarily require the 攻撃者 to have an
account on the target サーバ。
「in both cases、
これらの攻撃は、
the クライアントが
sends unsolicited 認証(authentication)情報without requiring any
specific データ from the サーバ over the TLS connection
ので、可能であること」
を注意することは、重要である。
a round trip to the サーバ over TLS before the クライアント
sends sensitive 情報
を要求するプロトコルは、相対的に脆弱でない傾向がある。
これらの攻撃は、暗号技術的に再交渉ハンドシェイクを
the enclosing TLS 暗号技術的パラメータs
に結合することによって、予防される可能性がある。それゆえ、
allowing the サーバ to differentiate 再交渉from 初期交渉, as
well as preventing 再交渉s from being spliced in between
connections。
An attempt by an 攻撃者 to
inject himself as described above
は、
a mismatch of the 暗号技術的 binding and can thus be detected
をもたらす。
この拡張中に使われているデータは、
is similar to, but not the same as,
the データ used in the tls-unique and/or tls-unique-for-telnet
channel bindings described in
[TLS-CHANNEL-BINDINGS]。;
しかし、この拡張は、
a general-purpose RFC 5056 [RFC5056]
channel binding facility
ではない。
本書中のMUST、MUST NOT、 REQUIRED、SHALL、 SHALL NOT、SHOULD、 SHOULD NOT、RECOMMENDED、 MAY、OPTIONAL は、 [RFC2119] に記述されたように解釈されるべきものである。
(作業中)
クライアントとサーバの両方は、
to store 3 additional values for each
TLSコネクションstate (RFC 5246, 6.1 節を参照)
必要がある。「こららの値は、
(not a TLS session cache entry)
connection
に固有であること」に注意。
(作業中)
本書は、
新しいTLS拡張, "renegotiation_info" (with 拡張 type 0xff01),
which contains a 暗号技術的 binding to the
enclosing TLS コネクション (if any) for which the 再交渉 is
being performed
を定義する。
この拡張の "extension data" field は、
"RenegotiationInfo" structureを格納する。：
struct {
opaque renegotiated_connection<0..255>;
} RenegotiationInfo;
この拡張の contents は、下記のように
are specified。
この拡張は、Datagram TLS (DTLS) [RFC4347]
と共に使われる可能性もある。
Although,
for editorial simplicity,
本書は、
refers to TLS,
all requirements in 本書 apply equally to DTLS。
(作業中)
SSLv3とTLS 1.0/TLS 1.1の両方の仕様は、実装に
following the ClientHello (i.e., 拡張s) if they do not understand it
データを無視することを要求する。
しかし、SSLv3とTLS 1.0の実装には、
incorrectly fail the ハンドシェイク in such a case
ものがある。これは、
「that offer the "renegotiation_info" 拡張
クライアントは、
ハンドシェイク失敗に直面する可能性があること」を意味する。
In order to enhance compatibility with このようなサーバs,
本書は、
a 2nd signaling メカニズム via a special SCVP(Signaling Cipher
Suite Value)"TLS_EMPTY_RENEGOTIATION_INFO_SCSV", with code point
{0x00, 0xFF}
を定義する。
このSCSVは、
a true cipher suite ではなく(it does not correspond to any
valid set of algorithms)、
cannot be negotiated。
代わりに、これは、
(以降の節に記述されているように)空の"renegotiation_info"拡張と同一のsemanticsをもつ。
SSLv3とTLSの実装は、
reliably ignore unknown cipher suites
ので、SCSVは、あらゆるサーバ宛に安全に送られる可能性がある。
SCSVは、
SSLv2 backward compatible CLIENT-HELLO(Appendix E.2 of
[RFC5246] 参照)
中に含められることもできる。
Note:
再交渉をまったくサポートしていないminimalクライアントは、
simply use the SCSV in all initial ハンドシェイクs
できる。下記の節において、そのルールは、
will cause any compliant サーバ to abort the
ハンドシェイク when it sees an apparent attempt at 再交渉 by such a
クライアント。
(作業中)
「本節および 3.5 節は、
apply to both full ハンドシェイクs
and session resumption ハンドシェイクs」
に注意。
Note:
later in 3 章,
「abort the ハンドシェイク」は、
for "send a fatal handshake_failure alert and
terminate the connection"
shorthand として使われる。
(作業中)
この text は、
applies
if the connection's "secure_renegotiation" フラグ is
set to TRUE
( it is set to FALSE
場合、
4.2節を参照)。
(作業中)
「本節と 3.7節は、
apply to
full ハンドシェイクと session-resumption ハンドシェイクの両方」
に注意。
この仕様を実装するTLSサーバは、
offered by the クライアント
あらゆるunknown拡張を無視しなければならない(MUST)。
そして、それらは、
accept version numbers higher than their highest version number
and negotiate the highest common version
ならない(MUST)。
これらふたつの要件は、
reiterate preexisting requirements in RFC 5246 and are merely
stated here in the interest of forward compatibility。
Note that
「a "renegotiation_info" 拡張 in response to a ClientHello
containing only the SCSV
を送信することは、
an explicit exception to the prohibition in RFC 5246, 7.4.1.4節,
on the サーバ sending unsolicited 拡張s
であり、
is only allowed because the クライアント is signaling its
willingness to receive the 拡張 via the
TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV」。
TLS実装は、
7.4.1.4節 for all 他の拡張s
に準拠し続けなければならない(MUST)。
(作業中)
このtextは、
そのconnectionの"secure_renegotiation"フラグにTRUEがセットされている場合、
applies。
(it is set to FALSE
場合、4.4節を参照。)
(作業中)
この拡張をサポートしていない既存の実装は、
are widely deployed and,
in general, must interoperate with newer 実装s that do support it。
本章は、下位互換なinteroperationについての考慮事項を記述する。
(作業中)
あるクライアントが
offers the "renegotiation_info" 拡張 or the
TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV and the サーバ does not
reply with "renegotiation_info" in the ServerHello
場合、これは、「そのサーバは、
セキュアな再交渉をサポートしていないこと」を示す。
some 攻撃s (1章を参照)look like a single ハンドシェイク to the
クライアント
ので、そのクライアントは、「そのconnectionは、現在、
攻撃にさらされているか否か？」を判定できない。しかし、
「merely because the サーバ does not acknowledge the 拡張 does
not mean that it is vulnerable ;
it might choose to reject all 再交渉s and simply not signal it」
に注意。しかし、そのクライアントにとって、純粋TLSメカニズム経由で
「whether or not this is the case？」を判定することは、不可能である。
クライアントが「このような攻撃が不可能であること」を確認することを望む場合、
それらは、
to terminate the connection immediately upon failure to receive
the拡張 without completing the ハンドシェイク
必要がある。このようなクライアントは、
a fatal "handshake_failure" alert prior to terminating the
connection
を生成しなければならない(MUST)。しかし、
it is expected that many TLS サーバs that do not support 再交渉
(and thus are not vulnerable) will not support この拡張 either,
so in general,
that implement this behavior
クライアントは、相互運用可能性問題に直面する。
There is no set of クライアントの振る舞いs that will guarantee
セキュリティ and achieve maximum interoperability during the
transition period。
クライアントは、
to choose one or the other preference when dealing with
potentially un-upgraded サーバs
必要がある。
(作業中)
このtextは、
applies if the connection's "secure_renegotiation" フラグ is set
to FALSE。
It is possible that un-upgraded サーバs will request that the クライアント
renegotiate。
It is RECOMMENDED that
「クライアントs refuse this 再交渉 request」。
クライアントs 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 サーバ is in fact
an 攻撃者 who is then allowing the クライアント to renegotiate
with a different, legitimate, upgraded サーバ。
クライアントが
nevertheless choose to renegotiate
場合、theyは、
behave as described below
ならない(MUST)。
that choose to renegotiate
クライアントは、
either the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV
or "renegotiation_info" in their ClientHello
提供しなければならない(MUST)。
In a legitimate 再交渉 with an un-upgraded サーバ,
that サーバ should ignore both of these signals。
しかし、
the サーバ (incorrectly) fails to ignore 拡張s
場合、
sending the"renegotiation_info" 拡張 may cause a ハンドシェイク failure。
それゆえ、
it is permitted,
though NOT RECOMMENDED,
for the クライアント to simply send the SCSV。
これは、
is the only situation in which クライアントs are permitted to
not send the "renegotiation_info" 拡張 in a ClientHello that is
used for 再交渉。
Note that
「in the case of a downgrade 攻撃,
if this is an initialハンドシェイク from the サーバ's
perspective,
then use of the SCSV from the クライアント precludes detection
of this 攻撃 by the サーバ
(if this is a 再交渉 from the サーバ's perspective, then it will
detect the 攻撃)」。
しかし、その攻撃は、
will be detected by the クライアント when the サーバ sends an
empty "renegotiation_info" 拡張 and theクライアント is expecting
one containing the previous verify_data。 |
By contrast,
the クライアント sends the "renegotiation_info" 拡張
場合、そのサーバは、
will immediately detect the 攻撃。
ServerHelloが
is received
とき、そのクライアントは、
verify that
「it does not contain the "renegotiation_info" 拡張」
ならない(MUST)。
it does
場合、そのクライアントは、
abort the ハンドシェイク
ならない(MUST)。
(Because the サーバ has already indicated it does not support セ
キュアな再交渉,
the only way that this can happen is if the サーバ is broken or
there is an 攻撃。)
(作業中)
the クライアントが
does not offer the "renegotiation_info" 拡張 or the
TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV
場合、これは、
「the クライアント does not support セキュアな再交渉」
を示す。
Although the攻撃 described in Section 1 looks like two ハンドシェ
イクs to theサーバ,
他の攻撃s may be possible in which the 再交渉 is seen only by
the クライアント。
サーバs が
wish to ensure that such 攻撃s are impossible
場合、
they need to terminate the connection immediately upon failure
to negotiate the use of セキュアな再交渉。
Servers that do choose to allow connections from unpatched クラ
イアントs
は、
can still prevent the 攻撃 described in Section 1 by refusing to
renegotiate over those connections。
In order to enable クライアントs to probe,
even サーバs that do not support再交渉
は、
implement the minimal version of the 拡張described in 本書 for
initial ハンドシェイクs, thus signaling that they have been
upgraded
ならない(MUST)。
(作業中)
このtextは、
applies
if the connection's "secure_renegotiation" フラグ is set to
FALSE。
It is RECOMMENDED that
「サーバs not permit legacy 再交渉」。
サーバs nevertheless do permit it
場合、they は、
follow the requirements in this section
ならない(MUST)。
(作業中)
While SSLv3 is not a プロトコル under IETF change control (
[SSLv3]参照),
it was the original basis for TLS and most TLS実装s also support
SSLv3。
The IETF は、
encourages SSLv3実装s to adopt the "renegotiation_info" 拡張 and
SCSV as defined in 本書。
The semantics of the SCSV and 拡張
は、
are identical to TLS stacks except for the size of the
verify_data values,
which are 36 bytes long each。
「これは、
adding at least minimal 拡張 processing to such stacks
を要求すること」に注意。
SSLv3 をサポートし、
offer セキュアな再交渉 (either via SCSV or"renegotiation_info")
クライアントは、
the "renegotiation_info" 拡張from the サーバ, even if the サーバ
version is {0x03, 0x00}, and behave as described in この仕様
許容しなければならない(MUST)。
that supportセキュアな再交渉 and support SSLv3
TLS サーバは、
SCSV or the "renegotiation_info" 拡張 and respond as described
in this specification even if the offered クライアント version
is {0x03, 0x00}
許容しなければならない(MUST)。
SSLv3は、"no_renegotiation" alertを定義していない。
(そして、
does not offer a way to indicate a refusal to renegotiate at a
"warning" level。)
再交渉を拒絶するSSLv3クライアントは、
fatal handshake_failure alertを使う必要がある(SHOULD)。
(作業中)
本書中に記述された拡張は、TLSについての、ある攻撃を予防する。
この拡張が使われない場合、TLS再交渉は、
an攻撃 in which the 攻撃者 can inject their own conversation
with the TLS サーバ as a prefix to the クライアントの
conversation
の対象となる。この攻撃は、
is invisible to the クライアント and looks like an ordinary 再交渉
to the サーバ。
The 拡張 defined in 本書
は、
allows再交渉 to be performed safely。
Serversは、
allowクライアントs to renegotiate without using この拡張
いけない(SHOULD NOT)。
多くのサーバは、
mitigate この攻撃 simply by refusing to renegotiate at all
できる。
While この拡張 mitigates the man-in-the-middle 攻撃 described in
the overview,
これらは、
all possible 問題 an application may face if it is unaware of 再
交渉
解決しない。例えば、再交渉において、
either the クライアント
or the サーバ can present a異なる証明書 than was used earlier。
これは、
may come as a surprise to application developers
(who might have expected,
例えば、
that a "getPeerCertificates()" API call returns the same value
if called twice),
and might be handled in an insecure way。
TLS実装は、 再交渉を不能にしたり可能にしたりするためのメカニズムを提供する必要がある(SHOULD)。
TLS実装者は、
are encouraged to clearly document how 再交渉interacts with the
APIs offered to アプリケーション
(例えば、
which API calls might return different values on different
calls, or which callbacks might get called multiple times)。
To make life simpler for アプリケーション that use 再交渉 but do
not expect the 証明書 to change once it has been authenticated,
TLS実装は、
may also wish to offer the アプリケーション the option to abort
the 再交渉 if the peer tries to authenticate with a different 証
明書 and/or different サーバ名
(in the server_name 拡張) than was used earlier。
TLS実装は、
alternatively offer the option to disable 再交渉 once the
クライアント証明書 has been authenticated
可能性がある。しかし、
enabling これらのoptions by default for all アプリケーション
could break 既存のアプリケーション that depend on using 再交渉
to change from one証明書 to another。
(例えば、long-lived TLS コネクションは、
could change to a renewed 証明書。;
or 再交渉 could select a different cipher suite that requires
using a different証明書。)
最後に、再交渉に依拠するアプリケーションの設計者には、
「多くの TLS API が
represent application データ as a simple
octet stream」
が推奨される。アプリケーションは、
not be able to determine exactly which application データ octets
were received before, during, or after再交渉
可能性がある。特に、
the peer presents a 異なる証明書 during 再交渉
場合、
「どのように
the application should handle the データ？」
を規定するとき、配慮を要する。
(作業中)
IANAは、拡張code point 65281(0xff01)を追加した。これは、
has been used for prototype 実装s,
for the "renegotiation_info" 拡張 to the TLS ExtensionType values
registry。
IANAは、TLS cipher suite number 0x00,0xFFをname TLS_EMPTY_RENEGOTIATION_INFO_SCSVと共にTLS Cipher Suite registryに追加した。
(作業中)
この脆弱性は、当初、Marsh Rayによって発見され、独立してMartin
Rexによって再発見された。
described here
the 拡張の背後にある一般概念は、
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。
| [RFC2119] |
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997年3月. |
| [RFC5246] |
Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, 2008年8月. |
| [RFC4347] |
Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, 2006年4月. |
| [RFC5056] |
Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, 2007年11月. |
| [TLS-CHANNEL-BINDINGS] |
Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", Work in Progress, 2009年10月. |
| [RFC2818] |
Rescorla, E., "HTTP Over TLS", RFC 2818, 2000年5月. |
| [RFC2965] |
Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, 2000年10月. |
| [Ray09] |
Ray, M., "Authentication Gap in TLS Renegotiation", 2009年11月, <http://extendedsubset.com/?p=8>. |
| [SSLv3] |
Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol Version 3.0", Work in Progress, 1996年11月. |
Eric Rescorla
RTFM, Inc.
2064 Edgewood Drive
Palo Alto, CA 94303
USA
EMail: ekr＠rtfm.com
Marsh Ray
PhoneFactor
7301 W 129th Street
Overland Park, KS 66213
USA
EMail: marsh＠extendedsubset.com
Steve Dispensa
PhoneFactor
7301 W 129th Street
Overland Park, KS 66213
USA
EMail: dispensa＠phonefactor.com
Nasko Oskov
Microsoft
One Microsoft Way
Redmond, WA 98052
USA
EMail: nasko.oskov＠microsoft.com