[要約] RFC 7457は、Transport Layer Security (TLS) および Datagram TLS (DTLS) に対する既知の攻撃を要約し、これらのセキュリティプロトコルの脆弱性に対する認識を高めることを目的としています。この文書は、TLSやDTLSを使用するアプリケーションの開発者やネットワーク管理者にとって有用な情報源となり、より安全な通信システムの設計や運用に役立ちます。関連するRFCには、TLSおよびDTLSの仕様を定義するRFC 5246（TLS 1.2）やRFC 6347（DTLS 1.2）などがあります。RFC 7457は、これらのプロトコルのセキュリティを強化するためのガイドラインとして機能します。
Internet Engineering Task Force (IETF) Y. Sheffer
Request for Comments: 7457 Porticor
Category: Informational R. Holz
ISSN: 2070-1721 Technische Universitaet Muenchen
P. Saint-Andre
&yet
February 2015
Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)
トランスポート層セキュリティ（TLS）およびデータグラムTLS（DTLS）に対する既知の攻撃の要約
Abstract
概要
Over the last few years, there have been several serious attacks on Transport Layer Security (TLS), including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and Datagram TLS (DTLS).
過去数年にわたって、最も一般的に使用されている暗号や動作モードへの攻撃など、トランスポート層セキュリティ（TLS）に対する深刻な攻撃がいくつかあります。このドキュメントでは、TLSとデータグラムTLS（DTLS）の使用に関する一般的なプロトコル固有の推奨事項を動機付けることを目的として、これらの攻撃をまとめています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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 http://www.rfc-editor.org/info/rfc7457.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7457で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
1. Introduction ....................................................3
2. Attacks on TLS ..................................................3
2.1. SSL Stripping ..............................................3
2.2. STARTTLS Command Injection Attack (CVE-2011-0411) ..........4
2.3. BEAST (CVE-2011-3389) ......................................4
2.4. Padding Oracle Attacks .....................................4
2.5. Attacks on RC4 .............................................5
2.6. Compression Attacks: CRIME, TIME, and BREACH ...............5
2.7. Certificate and RSA-Related Attacks ........................5
2.8. Theft of RSA Private Keys ..................................6
2.9. Diffie-Hellman Parameters ..................................6
2.10. Renegotiation (CVE-2009-3555) .............................6
2.11. Triple Handshake (CVE-2014-1295) ..........................6
2.12. Virtual Host Confusion ....................................7
2.13. Denial of Service .........................................7
2.14. Implementation Issues .....................................7
2.15. Usability .................................................8
3. Applicability to DTLS ...........................................8
4. Security Considerations .........................................8
5. Informative References ..........................................8
Acknowledgements ..................................................13
Authors' Addresses ................................................13
Over the last few years, there have been several major attacks on TLS [RFC5246], including attacks on its most commonly used ciphers and modes of operation. Details are given in Section 2, but a quick summary is that both AES-CBC and RC4, which together make up for most current usage, have been seriously attacked in the context of TLS.
過去数年間、TLS [RFC5246]に対するいくつかの主要な攻撃がありました。これには、最も一般的に使用されている暗号や操作モードへの攻撃が含まれます。詳細はセクション2に記載されていますが、簡単にまとめると、AES-CBCとRC4の両方が、現在のほとんどの使用法を構成しており、TLSのコンテキストで深刻な攻撃を受けています。
This situation was one of the motivations for the creation of the UTA working group, which was tasked with the creation of generic and protocol-specific recommendations for the use of TLS and DTLS [RFC6347] (unless otherwise noted under Section 3, all of the information provided in this document applies to DTLS).
この状況は、TLSおよびDTLS [RFC6347]の使用に関する一般的でプロトコル固有の推奨事項の作成を任されたUTAワーキンググループの作成の動機の1つでした（セクション3で特に明記されていない限り、すべてのこのドキュメントで提供される情報はDTLSに適用されます）。
There is an old saying attributed, ironically enough, to the US National Security Agency (NSA): "Attacks always get better; they never get worse." Unfortunately, that saying is true, so any description of security attacks can only be a snapshot in time. Therefore this document reflects our knowledge as of this writing. It seems likely that new attacks will be discovered in the future.
皮肉なことに、米国国家安全保障局（NSA）による古い格言があります。「攻撃は常に改善され、悪化することはありません。」残念ながら、そのことは真実であるため、セキュリティ攻撃の説明はいずれもスナップショットにすぎません。したがって、このドキュメントは、この執筆時点での私たちの知識を反映しています。今後、新たな攻撃が発見される可能性が高いです。
For a more detailed discussion of the attacks listed here, the interested reader is referred to [Attacks-iSec].
ここに挙げられている攻撃の詳細については、[Attacks-iSec]を参照してください。
This section lists the attacks that motivated the current recommendations in [SECURE-TLS]. This list is not intended to be an extensive survey of the security of TLS.
このセクションでは、[SECURE-TLS]の現在の推奨事項を動機付けた攻撃をリストします。このリストは、TLSのセキュリティに関する広範な調査を目的としたものではありません。
While there are widely deployed mitigations for some of the attacks listed below, we believe that their root causes necessitate a more systematic solution, which we have attempted to develop in [SECURE-TLS].
下記の攻撃の一部には広く展開されている緩和策がありますが、その根本原因はより体系的な解決策を必要とすると私たちは考えています。これは[SECURE-TLS]で開発しようとしました。
When an identifier exists for an attack, we have included its Common Vulnerabilities and Exposures (CVE) ID. CVE [CVE] is an extensive, industry-wide database of software vulnerabilities.
攻撃の識別子が存在する場合は、そのCommon Vulnerabilities and Exposures（CVE）IDを含めました。 CVE [CVE]は、ソフトウェアの脆弱性に関する業界全体の広範なデータベースです。
Various attacks attempt to remove the use of Secure Socket Layer / Transport Layer Security (SSL/TLS) altogether by modifying unencrypted protocols that request the use of TLS, specifically modifying HTTP traffic and HTML pages as they pass on the wire. These attacks are known collectively as "SSL Stripping" (a form of the more generic "downgrade attack") and were first introduced by Moxie Marlinspike [SSL-Stripping]. In the context of Web traffic,
TLSの使用を要求する暗号化されていないプロトコルを変更することにより、Secure Socket Layer / Transport Layer Security（SSL / TLS）の使用を完全に削除しようとするさまざまな攻撃、特にHTTPトラフィックとHTMLページがネットワーク上を通過するときに変更します。これらの攻撃は総称して「SSLストリッピング」（より一般的な「ダウングレード攻撃」の形式）として知られており、Moxie Marlinspike [SSL-Stripping]によって最初に導入されました。 Webトラフィックのコンテキストでは、
these attacks are only effective if the client initially accesses a Web server using HTTP. A commonly used mitigation is HTTP Strict Transport Security (HSTS) [RFC6797].
これらの攻撃は、クライアントが最初にHTTPを使用してWebサーバーにアクセスする場合にのみ効果があります。一般的に使用される緩和策は、HTTP Strict Transport Security（HSTS）[RFC6797]です。
Similarly, there are attacks on the transition between unprotected and TLS-protected traffic. A number of IETF application protocols have used an application-level command, usually STARTTLS, to upgrade a cleartext connection to use TLS. Multiple implementations of STARTTLS had a flaw where an application-layer input buffer retained commands that were pipelined with the STARTTLS command, such that commands received prior to TLS negotiation are executed after TLS negotiation. This problem is resolved by requiring the application-level command input buffer to be empty before negotiating TLS. Note that this flaw lives in the application layer code and does not impact the TLS protocol directly.
同様に、保護されていないトラフィックとTLSで保護されているトラフィック間の移行に対する攻撃があります。多くのIETFアプリケーションプロトコルは、アプリケーションレベルのコマンド（通常はSTARTTLS）を使用して、クリアテキスト接続をアップグレードしてTLSを使用します。 STARTTLSの複数の実装には、アプリケーション層の入力バッファーがSTARTTLSコマンドでパイプライン化されたコマンドを保持するという欠陥があり、TLSネゴシエーションの前に受信されたコマンドはTLSネゴシエーションの後に実行されます。この問題は、TLSをネゴシエートする前にアプリケーションレベルのコマンド入力バッファーを空にすることで解決されます。この欠陥はアプリケーション層のコードに存在し、TLSプロトコルに直接影響しないことに注意してください。
STARTTLS and similar mechanisms are vulnerable to downgrade attacks, whereby the attacker simply removes the STARTTLS indication from the (unprotected) request. This cannot be mitigated unless HSTS-like solutions are added.
STARTTLSおよび同様のメカニズムは、ダウングレード攻撃に対して脆弱です。これにより、攻撃者は（保護されていない）要求からSTARTTLSの表示を削除するだけです。 HSTSのようなソリューションを追加しない限り、これを緩和することはできません。
The BEAST attack [BEAST] uses issues with the TLS 1.0 implementation of Cipher Block Chaining (CBC) (that is, the predictable initialization vector) to decrypt parts of a packet, and specifically to decrypt HTTP cookies when HTTP is run over TLS.
BEAST攻撃[BEAST]は、Cipher Block Chaining（CBC）のTLS 1.0実装（つまり、予測可能な初期化ベクトル）の問題を使用して、パケットの一部を復号化し、特にHTTPがTLSで実行されている場合にHTTP Cookieを復号化します。
A consequence of the MAC-then-encrypt design in all current versions of TLS is the existence of padding oracle attacks [Padding-Oracle]. A recent incarnation of these attacks is the Lucky Thirteen attack (CVE-2013-0169) [CBC-Attack], a timing side-channel attack that allows the attacker to decrypt arbitrary ciphertext.
TLSの現在のすべてのバージョンでMAC-then-encrypt設計の結果は、パディングオラクル攻撃[Padding-Oracle]の存在です。これらの攻撃の最近の化身は、ラッキーサーティーン攻撃（CVE-2013-0169）[CBC-Attack]です。これは、攻撃者が任意の暗号文を復号化できるようにするタイミングサイドチャネル攻撃です。
The Lucky Thirteen attack can be mitigated by using authenticated encryption like AES-GCM [RFC5288] or encrypt-then-MAC [RFC7366] instead of the TLS default of MAC-then-encrypt.
Lucky Thirteen攻撃は、TLSデフォルトのMAC-then-encryptの代わりに、AES-GCM [RFC5288]またはencrypt-then-MAC [RFC7366]のような認証された暗号化を使用することで軽減できます。
An even newer variant of the padding oracle attack, one that does not use timing information, is the POODLE attack (CVE-2014-3566) [POODLE] on SSL 3.0. This attack has no known mitigation.
タイミング情報を使用しない、パディングオラクル攻撃のさらに新しい変種は、SSL 3.0でのPOODLE攻撃（CVE-2014-3566）[POODLE]です。この攻撃には既知の緩和策はありません。
The RC4 algorithm [RC4] has been used with TLS (and previously, SSL) for many years. RC4 has long been known to have a variety of cryptographic weaknesses, e.g., [RC4-Attack-Pau], [RC4-Attack-Man], and [RC4-Attack-FMS]. Recent cryptanalysis results [RC4-Attack-AlF] exploit biases in the RC4 keystream to recover repeatedly encrypted plaintexts.
RC4アルゴリズム[RC4]は、TLS（および以前はSSL）と共に長年使用されてきました。 RC4には、[RC4-Attack-Pau]、[RC4-Attack-Man]、[RC4-Attack-FMS]など、さまざまな暗号の弱点があることが古くから知られています。最近の暗号化の結果[RC4-Attack-AlF]は、RC4キーストリームのバイアスを悪用して、繰り返し暗号化された平文を復元します。
These recent results are on the verge of becoming practically exploitable; currently they require 2^26 sessions or 13x2^30 encryptions. As a result, RC4 can no longer be seen as providing a sufficient level of security for TLS sessions. For further details, the reader is referred to [CIPHER-SUITES] and the references it cites.
これらの最近の結果は、実際に悪用可能になる寸前です。現在、2 ^ 26セッションまたは13x2 ^ 30暗号化が必要です。その結果、RC4は、TLSセッションに十分なレベルのセキュリティを提供するとは見なされなくなりました。詳細については、[CIPHER-SUITES]とその引用文献を参照してください。
The CRIME attack [CRIME] (CVE-2012-4929) allows an active attacker to decrypt ciphertext (specifically, cookies) when TLS is used with TLS-level compression.
CRIME攻撃[CRIME]（CVE-2012-4929）では、TLSがTLSレベルの圧縮で使用されている場合、アクティブな攻撃者が暗号文（特にCookie）を復号化できます。
The TIME attack [TIME] and the later BREACH attack [BREACH] (CVE-2013-3587, though the number has not been officially allocated) both make similar use of HTTP-level compression to decrypt secret data passed in the HTTP response. We note that compression of the HTTP message body is much more prevalent than compression at the TLS level.
TIME攻撃[TIME]とその後のBREACH攻撃[BREACH]（CVE-2013-3587。ただし、数値は正式には割り当てられていません）は、HTTPレベルの圧縮を同様に使用して、HTTP応答で渡される秘密データを復号化します。 HTTPメッセージ本文の圧縮は、TLSレベルでの圧縮よりもはるかに普及していることに注意してください。
The TIME attack can be mitigated by disabling TLS compression. We are not aware of mitigations at the TLS protocol level to the BREACH attack, and so application-level mitigations are needed (see [BREACH]). For example, implementations of HTTP that use Cross-Site Request Forgery (CSRF) tokens will need to randomize them. Even the best practices and recommendations from [SECURE-TLS] are insufficient to thwart this attack.
TIME攻撃は、TLS圧縮を無効にすることで軽減できます。 TLSプロトコルレベルでのBREACH攻撃に対する緩和策については認識していないため、アプリケーションレベルの緩和策が必要です（[BREACH]を参照）。たとえば、クロスサイトリクエストフォージェリ（CSRF）トークンを使用するHTTPの実装では、トークンをランダム化する必要があります。 [SECURE-TLS]のベストプラクティスと推奨でさえ、この攻撃を阻止するには不十分です。
There have been several practical attacks on TLS when used with RSA certificates (the most common use case). These include [Bleichenbacher98] and [Klima03]. While the Bleichenbacher attack has been mitigated in TLS 1.0, the Klima attack, which relies on a version-check oracle, is only mitigated by TLS 1.1.
RSA証明書（最も一般的な使用例）と共に使用した場合、TLSに対するいくつかの実際的な攻撃がありました。これらには、[Bleichenbacher98]と[Klima03]が含まれます。 Bleichenbacher攻撃はTLS 1.0で軽減されていますが、バージョンチェックオラクルに依存するKlima攻撃はTLS 1.1でのみ軽減されます。
The use of RSA certificates often involves exploitable timing issues [Brumley03] (CVE-2003-0147), unless the implementation takes care to explicitly eliminate them.
RSA証明書を使用すると、実装で明示的に排除されない限り、悪用可能なタイミングの問題[Brumley03]（CVE-2003-0147）が含まれることがよくあります。
A recent certificate fuzzing tool [Brubaker2014using] uncovered numerous vulnerabilities in different TLS libraries related to certificate validation.
最近の証明書ファジングツール[Brubaker2014using]は、証明書の検証に関連するさまざまなTLSライブラリの多数の脆弱性を発見しました。
When TLS is used with most non-Diffie-Hellman cipher suites, it is sufficient to obtain the server's private key in order to decrypt any sessions (past and future) that were initiated with that server. This technique is used, for example, by the popular Wireshark network sniffer to inspect TLS-protected connections.
ほとんどの非Diffie-Hellman暗号スイートでTLSを使用する場合、サーバーで開始されたセッション（過去および将来）を復号化するには、サーバーの秘密鍵を取得するだけで十分です。この手法は、たとえば、人気のあるWiresharkネットワークスニファによってTLSで保護された接続を検査するために使用されます。
It is known that stolen (or otherwise obtained) private keys have been used as part of large-scale monitoring [RFC7258] of certain servers.
特定のサーバーの大規模監視[RFC7258]の一部として、盗まれた（または取得された）秘密鍵が使用されていることが知られています。
Such attacks can be mitigated by better protecting the private key, e.g., using OS protections or dedicated hardware. Even more effective is the use of cipher suites that offer "forward secrecy", the property where revealing a secret such as a private key does not expose past or future sessions to a passive attacker.
このような攻撃は、たとえばOS保護や専用ハードウェアを使用して、秘密鍵をより適切に保護することで軽減できます。さらに効果的なのは、「前方秘密」を提供する暗号スイートの使用です。これは、秘密鍵などの秘密を明らかにしても、過去または将来のセッションがパッシブな攻撃者に公開されない特性です。
TLS allows the definition of ephemeral Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman parameters in its respective key exchange modes. This results in an attack detailed in [Cross-Protocol]. Using predefined DH groups, as proposed in [FFDHE-TLS], would mitigate this attack.
TLSを使用すると、それぞれの鍵交換モードで一時的なDiffie-Hellman（DH）パラメータとElliptic Curve Diffie-Hellmanパラメータを定義できます。これにより、[クロスプロトコル]で説明されている攻撃が発生します。 [FFDHE-TLS]で提案されているように、事前定義されたDHグループを使用すると、この攻撃を軽減できます。
In addition, clients that do not properly verify the received parameters are exposed to man-in-the-middle (MITM) attacks. Unfortunately, the TLS protocol does not mandate this verification (see [RFC6989] for analogous information for IPsec).
さらに、受信したパラメーターを適切に検証しないクライアントは、中間者（MITM）攻撃にさらされます。残念ながら、TLSプロトコルはこの検証を義務付けていません（IPsecの類似情報については[RFC6989]を参照してください）。
A major attack on the TLS renegotiation mechanism applies to all current versions of the protocol. The attack and the TLS extension that resolves it are described in [RFC5746].
TLS再ネゴシエーションメカニズムに対する主要な攻撃は、プロトコルの現在のすべてのバージョンに適用されます。攻撃とそれを解決するTLS拡張は[RFC5746]で説明されています。
The triple handshake attack [BhargavanDFPS14] enables the attacker to cause two TLS connections to share keying material. This leads to a multitude of attacks, e.g., man-in-the-middle, breaking safe renegotiation, and breaking channel binding via TLS Exporter [RFC5705] or "tls-unique" [RFC5929].
トリプルハンドシェイク攻撃[BhargavanDFPS14]により、攻撃者は2つのTLS接続に鍵情報を共有させることができます。これは、中間者攻撃、安全な再ネゴシエーションの破壊、TLS Exporter [RFC5705]または "tls-unique" [RFC5929]によるチャネルバインディングの破壊など、多数の攻撃につながります。
A recent article [Delignat14] describes a security issue whereby SSLv3 fallback and improper handling of session caches on the server side can be abused by an attacker to establish a malicious connection to a virtual host other than the one originally intended and approved by the server. This attack is especially serious in performance critical environments where sharing of SSLv3 session caches is very common.
最近の記事[Delignat14]は、サーバー側のSSLv3フォールバックとセッションキャッシュの不適切な処理が攻撃者によって悪用され、サーバーによって本来意図され、承認された仮想ホスト以外の仮想ホストへの悪意のある接続を確立できるというセキュリティの問題について説明しています。この攻撃は、SSLv3セッションキャッシュの共有が非常に一般的である、パフォーマンスが重要な環境で特に深刻です。
Server CPU power has progressed over the years so that TLS can now be turned on by default. However, the risk of malicious clients and coordinated groups of clients ("botnets") mounting denial-of-service attacks is still very real. TLS adds another vector for computational attacks, since a client can easily (with little computational effort) force the server to expend relatively large computational work. It is known that such attacks have in fact been mounted.
サーバーのCPUパワーは長年にわたって進歩しており、TLSをデフォルトでオンにすることができます。ただし、悪意のあるクライアントやクライアントの調整されたグループ（「ボットネット」）がサービス拒否攻撃を仕掛けるリスクは依然として非常に現実的です。 TLSを使用すると、計算攻撃の別のベクトルが追加されます。これは、クライアントが（計算の労力がほとんどなく）簡単にサーバーに比較的大きな計算作業を費やすためです。そのような攻撃が実際に行われていることが知られています。
Even when the protocol is properly specified, this does not guarantee the security of implementations. In fact, there are very common issues that often plague TLS implementations. In particular, when integrating into higher-level protocols, TLS and its PKI-based authentication are sometimes the source of misunderstandings and implementation "shortcuts". An extensive survey of these issues can be found in [Georgiev2012].
プロトコルが適切に指定されていても、実装のセキュリティは保証されません。実際、TLSの実装を悩ませる非常に一般的な問題があります。特に、上位レベルのプロトコルに統合する場合、TLSとそのPKIベースの認証が誤解と実装の「ショートカット」の原因になることがあります。これらの問題に関する広範な調査は、[Georgiev2012]にあります。
o Implementations might omit validation of the server certificate altogether. For example, this is true of the default implementation of HTTP client libraries in Python 2 (e.g., CVE-2013-2191).
o 実装によっては、サーバー証明書の検証が完全に省略される場合があります。たとえば、これはPython 2のHTTPクライアントライブラリのデフォルトの実装（CVE-2013-2191など）に当てはまります。
o Implementations might not validate the server identity. This validation typically amounts to matching the protocol-level server name with the certificate's Subject Alternative Name field. Note: this same information is often also found in the Common Name part of the Distinguished Name, and some validators incorrectly retrieve it from there instead of from the Subject Alternative Name.
o 実装によっては、サーバーIDが検証されない場合があります。この検証は通常、プロトコルレベルのサーバー名と証明書の[サブジェクトの別名]フィールドを照合することになります。注：この同じ情報は、識別名の共通名部分にも含まれていることが多く、一部のバリデーターはサブジェクトの別名からではなく、そこから誤って取得します。
o Implementations might validate the certificate chain incorrectly or not at all, or use an incorrect or outdated trust anchor list.
o 実装により、証明書チェーンが正しく検証されないか、まったく検証されないか、不正または古いトラストアンカーリストが使用される場合があります。
An implementation attack of a different kind, one that exploits a simple coding mistake (bounds check), is the Heartbleed attack (CVE-2014-0160) that affected a wide swath of the Internet when it was discovered in April 2014.
単純なコーディングミス（境界チェック）を悪用する別の種類の実装攻撃は、ハートブリード攻撃（CVE-2014-0160）で、2014年4月に発見されたときにインターネットの広範囲に影響を及ぼしました。
Many TLS endpoints, such as browsers and mail clients, allow the user to explicitly accept an invalid server certificate. This often takes the form of a UI dialog (e.g., "do you accept this server?"), and users have been conditioned to respond in the affirmative in order to allow the connection to take place.
ブラウザやメールクライアントなどの多くのTLSエンドポイントでは、ユーザーが無効なサーバー証明書を明示的に受け入れることができます。これは多くの場合、UIダイアログ（たとえば、「このサーバーを受け入れますか？」）の形をとっており、ユーザーは、接続を確立するために肯定応答するように条件付けられています。
This user behavior is used by (arguably legitimate) "SSL proxies" that decrypt and re-encrypt the TLS connection in order to enforce local security policy. It is also abused by attackers whose goal is to gain access to the encrypted information.
このユーザー動作は、ローカルセキュリティポリシーを実施するために、TLS接続を復号化および再暗号化する（間違いなく正当な）「SSLプロキシ」によって使用されます。また、暗号化された情報にアクセスすることを目的とする攻撃者によって悪用されます。
Mitigation is complex and will probably involve a combination of protocol mechanisms (HSTS, certificate pinning [KEY-PINNING]), and very careful UI design.
緩和策は複雑で、おそらくプロトコルメカニズム（HSTS、証明書のピン留め[キーピニング]）の組み合わせ、および非常に注意深いUI設計が含まれます。
DTLS [RFC4347] [RFC6347] is an adaptation of TLS for UDP.
DTLS [RFC4347] [RFC6347]は、UDPに対するTLSの適応です。
With respect to the attacks described in the current document, DTLS 1.0 is equivalent to TLS 1.1. The only exception is RC4, which is disallowed in DTLS. DTLS 1.2 is equivalent to TLS 1.2.
現在のドキュメントで説明されている攻撃に関しては、DTLS 1.0はTLS 1.1と同等です。唯一の例外はRC4です。RC4はDTLSでは許可されていません。 DTLS 1.2はTLS 1.2と同等です。
This document describes protocol attacks in an informational manner and in itself does not have any security implications. Its companion documents, especially [SECURE-TLS], certainly do.
このドキュメントでは、情報攻撃によるプロトコル攻撃について説明しており、それ自体はセキュリティへの影響はありません。その付属文書、特に[SECURE-TLS]は確かにそうです。
[Attacks-iSec] Sarkar, P. and S. Fitzgerald, "Attacks on SSL, a comprehensive study of BEAST, CRIME, TIME, BREACH, Lucky13 and RC4 biases", August 2013, <https://www.isecpartners.com/media/106031/ ssl_attacks_survey.pdf>.
[攻撃-iSec] Sarkar、P。およびS.フィッツジェラルド、「SSL攻撃、獣、犯罪、時間、侵害、ラッキー13およびRC4バイアスの包括的な研究」、2013年8月、<https://www.isecpartners.com / media / 106031 / ssl_attacks_survey.pdf>。
[BEAST] Rizzo, J. and T. Duong, "Browser Exploit Against SSL/TLS", 2011, <http://packetstormsecurity.com/files/105499/ Browser-Exploit-Against-SSL-TLS.html>.
[BEAST] Rizzo、J。およびT. Duong、「ブラウザのSSL / TLSに対するエクスプロイト」、2011年、<http://packetstormsecurity.com/files/105499/ Browser-Exploit-Against-SSL-TLS.html>。
[BREACH] Prado, A., Harris, N., and Y. Gluck, "The BREACH Attack", 2013, <http://breachattack.com/>.
[BREACH]プラド、A。、ハリス、N。、およびY.グラック、「The BREACH Attack」、2013、<http://breachattack.com/>。
[BhargavanDFPS14] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, A., and P. Strub, "Triple handshakes and cookie cutters: breaking and fixing authentication over tls", 2014, <https://secure-resumption.com/tlsauth.pdf>.
[BhargavanDFPS14] Bhargavan、K.、Delignat-Lavaud、A.、Fournet、C.、Pironti、A。、およびP. Strub、「トリプルハンドシェイクとCookieカッター：tlsを介した認証の破壊と修正」、2014、<https： //secure-resumption.com/tlsauth.pdf>。
[Bleichenbacher98] Bleichenbacher, D., "Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1", 1998, <http://archiv.infsec.ethz.ch/education/fs08/secsem/ Bleichenbacher98.pdf>.
[Bleichenbacher98] Bleichenbacher、D。、「RSA Encryption Standard PKCS＃1に基づくプロトコルに対する選択された暗号文攻撃、1998年、<http://archiv.infsec.ethz.ch/education/fs08/secsem/ Bleichenbacher98.pdf> 。
[Brubaker2014using] Brubaker, C., Jana, S., Ray, B., Khurshid, S., and V. Shmatikov, "Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations", 2014, <https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf>.
[Brubaker2014using] Brubaker、C.、Jana、S.、Ray、B.、Khurshid、S.、and V. Shmatikov、 "Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL Validations"、2014、<https： //www.cs.utexas.edu/~shmat/shmat_oak14.pdf>。
[Brumley03] Brumley, D. and D. Boneh, "Remote Timing Attacks are Practical", 2003, <http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf>.
[Brumley03] Brumley、D.およびD. Boneh、「Remote Timing Attacks are Practical」、2003、<http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf>。
[CBC-Attack] AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking the TLS and DTLS Record Protocols", IEEE Symposium on Security and Privacy, 2013, <http://www.ieee-security.org/ TC/SP2013/papers/4977a526.pdf>.
[CBC攻撃] AlFardan、N。およびK. Paterson、「ラッキー13：TLSおよびDTLSレコードプロトコルの破壊」、セキュリティとプライバシーに関するIEEEシンポジウム、2013、<http://www.ieee-security.org/ TC /SP2013/papers/4977a526.pdf>。
[CIPHER-SUITES] Popov, A., "Prohibiting RC4 Cipher Suites", Work in Progress, draft-ietf-tls-prohibiting-rc4-01, October 2014.
[CIPHER-SUITES] Popov、A。、「Prohibiting RC4 Cipher Suites」、Work in Progress、draft-ietf-tls-prohibiting-rc4-01、2014年10月。
[CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", EKOparty Security Conference, 2012.
[犯罪] Rizzo、J.およびT. Duong、「The CRIME Attack」、EKOparty Security Conference、2012年。
[CVE] MITRE, "Common Vulnerabilities and Exposures", <https://cve.mitre.org/>.
[CVE] MITRE、「Common Vulnerabilities and Exposures」、<https://cve.mitre.org/>。
[Cross-Protocol] Mavrogiannopoulos, N., Vercauteren, F., Velichkov, V., and B. Preneel, "A cross-protocol attack on the TLS protocol", Proceedings of the 2012 ACM Conference in Computer and Communications Security, pages 62-72, 2012, <http://doi.acm.org/10.1145/2382196.2382206>.
[クロスプロトコル] Mavrogiannopoulos、N.、Vercauteren、F.、Velichkov、V。、およびB. Preneel、「TLSプロトコルに対するクロスプロトコル攻撃」、2012 ACM Conference in Computer and Communications Security、Proceedings、ページ62-72、2012、<http://doi.acm.org/10.1145/2382196.2382206>。
[Delignat14] Delignat-Lavaud, A. and K. Bhargavan, "Virtual Host Confusion: Weaknesses and Exploits", Black Hat 2014, 2014, <https://bh.ht.vc/vhost_confusion.pdf>.
[Delignat14] Delignat-Lavaud、A。およびK. Bhargavan、「仮想ホストの混乱：弱点と悪用」、Black Hat 2014、2014、<https://bh.ht.vc/vhost_confusion.pdf>。
[FFDHE-TLS] Gillmor, D., "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS", Work in Progress, draft-ietf-tls-negotiated-ff-dhe-05, December 2014.
[FFDHE-TLS]ギルモア、D。、「TLSの交渉済み有限体Diffie-Hellman一時パラメータ」、作業中、draft-ietf-tls-negotiated-ff-dhe-05、2014年12月。
[Georgiev2012] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, D., and V. Shmatikov, "The most dangerous code in the world: validating SSL certificates in non-browser software", Proceedings of the 2012 ACM conference on Computer and Communications Security, pages 38-49, 2012, <http://doi.acm.org/10.1145/2382196.2382204>.
[Georgiev2012] Georgiev、M.、Iyengar、S.、Jana、S.、Anubhai、R.、Boneh、D。、およびV. Shmatikov、「世界で最も危険なコード：非ブラウザーソフトウェアでのSSL証明書の検証"、コンピュータと通信のセキュリティに関する2012 ACM会議の議事録、38〜49ページ、2012年、<http://doi.acm.org/10.1145/2382196.2382204>。
[KEY-PINNING] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", Work in Progress, draft-ietf-websec-key-pinning-21, October 2014.
[キーピニング] Evans、C.、Palmer、C。、およびR. Sleevi、「HTTPの公開キー固定拡張機能」、Work in Progress、draft-ietf-websec-key-pinning-21、2014年10月。
[Klima03] Klima, V., Pokorny, O., and T. Rosa, "Attacking RSA-based Sessions in SSL/TLS", 2003, <https://eprint.iacr.org/2003/052.pdf>.
[Klima03] Klima、V.、Pokorny、O。、およびT. Rosa、「Attacking RSA-based Sessions in SSL / TLS」、2003、<https://eprint.iacr.org/2003/052.pdf>。
[POODLE] Moeller, B., Duong, T., and K. Kotowicz, "This POODLE Bites: Exploiting the SSL 3.0 Fallback", September 2014, <https://www.openssl.org/~bodo/ssl-poodle.pdf>.
[POODLE] Moeller、B.、Duong、T。、およびK. Kotowicz、「This POODLE Bites：Exploiting the SSL 3.0 Fallback」、2014年9月、<https://www.openssl.org/~bodo/ssl-poodle .pdf>。
[Padding-Oracle] Vaudenay, S., "Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS...", EUROCRYPT 2002, 2002, <http://www.iacr.org/cryptodb/archive/2002/ EUROCRYPT/2850/2850.pdf>.
[パディング-オラクル] Vaudenay、S。、「SSL、IPSEC、WTLSなどへのCBCパディングアプリケーションによって引き起こされるセキュリティの欠陥」、EUROCRYPT 2002、2002、<http://www.iacr.org/cryptodb/archive/2002 / EUROCRYPT / 2850 / 2850.pdf>。
[RC4] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and Source Code in C", Second Edition, October 1996.
[RC4] Schneier、B。、「Applied Cryptography：Protocols、Algorithms、and Source Code in C」、Second Edition、1996年10月。
[RC4-Attack-AlF] AlFardan, N., Bernstein, D., Paterson, K., Poettering, B., and J. Schuldt, "On the Security of RC4 in TLS", Usenix Security Symposium 2013, August 2013, <https://www.usenix.org/conference/usenixsecurity13/ security-rc4-tls>.
[RC4-Attack-AlF] AlFardan、N.、Bernstein、D.、Paterson、K.、Poettering、B.、and J. Schuldt、 "On the Security of RC4 in TLS"、Usenix Security Symposium 2013、August 2013、 <https://www.usenix.org/conference/usenixsecurity13/security-rc4-tls>。
[RC4-Attack-FMS] Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses in the Key Scheduling Algorithm of RC4", Selected Areas in Cryptography, August 2001, <http://www.crypto.com/papers/others/rc4_ksaproc.pdf>.
[RC4-Attack-FMS] Fluhrer、S.、Mantin、I。、およびA. Shamir、「RC4のキースケジューリングアルゴリズムの弱点」、暗号化の選択された領域、2001年8月、<http：//www.crypto。 com / papers / others / rc4_ksaproc.pdf>。
[RC4-Attack-Man] Mantin, I. and A. Shamir, "A Practical Attack on Broadcast RC4", April 2001, <http://saluc.engr.uconn.edu/refs/stream_cipher/ mantin01attackRC4.pdf>.
[RC4-Attack-Man] Mantin、I.およびA. Shamir、「A Practical Attack on Broadcast RC4」、2001年4月、<http://saluc.engr.uconn.edu/refs/stream_cipher/ mantin01attackRC4.pdf>。
[RC4-Attack-Pau] Paul, G. and S. Maitra, "Permutation After RC4 Key Scheduling Reveals the Secret Key", August 2007, <http://dblp.uni-trier.de/db/conf/sacrypt/ sacrypt2007.html#PaulM07>.
[RC4-Attack-Pau] Paul、G。、およびS. Maitra、「RC4鍵スケジューリング後の順列は秘密鍵を明らかにする」、2007年8月、<http://dblp.uni-trier.de/db/conf/sacrypt/ sacrypt2007.html＃PaulM07>。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006, <http://www.rfc-editor.org/info/rfc4347>.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、RFC 4347、2006年4月、<http://www.rfc-editor.org/info/rfc4347>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月、<http://www.rfc-editor.org/info/rfc5246>。
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008, <http://www.rfc-editor.org/info/rfc5288>.
[RFC5288] Salowey、J.、Choudhury、A。、およびD. McGrew、「AES Galois Counter Mode（GCM）Cipher Suites for TLS」、RFC 5288、2008年8月、<http://www.rfc-editor.org / info / rfc5288>。
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, March 2010, <http://www.rfc-editor.org/info/rfc5705>.
[RFC5705] Rescorla、E。、「Keying Material Exporters for Transport Layer Security（TLS）」、RFC 5705、2010年3月、<http://www.rfc-editor.org/info/rfc5705>。
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010, <http://www.rfc-editor.org/info/rfc5746>.
[RFC5746] Rescorla、E.、Ray、M.、Dispensa、S。、およびN. Oskov、「Transport Layer Security（TLS）Renegotiation Indication Extension」、RFC 5746、2010年2月、<http：//www.rfc- editor.org/info/rfc5746>。
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010, <http://www.rfc-editor.org/info/rfc5929>.
[RFC5929] Altman、J.、Williams、N。、およびL. Zhu、「TLSのチャネルバインディング」、RFC 5929、2010年7月、<http://www.rfc-editor.org/info/rfc5929>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、2012年1月、<http://www.rfc-editor.org/info/rfc6347>。
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, November 2012, <http://www.rfc-editor.org/info/rfc6797>.
[RFC6797] Hodges、J.、Jackson、C。、およびA. Barth、「HTTP Strict Transport Security（HSTS）」、RFC 6797、2012年11月、<http://www.rfc-editor.org/info/rfc6797 >。
[RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 6989, July 2013, <http://www.rfc-editor.org/info/rfc6989>.
[RFC6989] Sheffer、Y。およびS. Fluhrer、「インターネットキー交換プロトコルバージョン2（IKEv2）の追加Diffie-Hellmanテスト」、RFC 6989、2013年7月、<http://www.rfc-editor.org/ info / rfc6989>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、2014年5月、<http://www.rfc-editor.org/info/rfc7258>。
[RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7366, September 2014, <http://www.rfc-editor.org/info/rfc7366>.
[RFC7366] Gutmann、P。、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）の暗号化後MAC」、RFC 7366、2014年9月、<http://www.rfc-editor.org/ info / rfc7366>。
[SECURE-TLS] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of TLS and DTLS", Work in Progress, draft-ietf-uta-tls-bcp-08, December 2014.
[SECURE-TLS] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「TLSおよびDTLSの安全な使用に関する推奨事項」、作業中、draft-ietf-uta-tls-bcp-08、12月2014。
[SSL-Stripping] Marlinspike, M., "sslstrip", February 2009, <http://www.thoughtcrime.org/software/sslstrip/>.
[SSL除去] Marlinspike、M。、「sslstrip」、2009年2月、<http://www.thoughtcrime.org/software/sslstrip/>。
[TIME] Be'ery, T. and A. Shulman, "A Perfect CRIME? Only TIME Will Tell", Black Hat Europe 2013, 2013, <https://media.blackhat.com/eu-13/briefings/Beery/ bh-eu-13-a-perfect-crime-beery-wp.pdf>.
[TIME] Be'ery、T。およびA. Shulman、「A Perfect Crime？Only Time Will Tell」、Black Hat Europe 2013、2013、<https://media.blackhat.com/eu-13/briefings/Beery / bh-eu-13-a-perfect-crime-beery-wp.pdf>。
Acknowledgements
謝辞
We would like to thank Stephen Farrell, Simon Josefsson, John Mattsson, Yoav Nir, Kenny Paterson, Patrick Pelletier, Tom Ritter, Rich Salz, and Meral Shirazipour for their feedback on this document. We thank Andrei Popov for contributing text on RC4, Kohei Kasamatsu for text on Lucky13, Ilari Liusvaara for text on attacks and on DTLS, Aaron Zauner for text on virtual host confusion, and Chris Newman for text on STARTTLS command injection. Ralph Holz gratefully acknowledges the support of NICTA (National ICT of Australia) in the preparation of this document.
このドキュメントに関するフィードバックを提供してくださった、Stephen Farrell、Simon Josefsson、John Mattsson、Yoav Nir、Kenny Paterson、Patrick Pelletier、Tom Ritter、Rich Salz、およびMeral Shirazipourに感謝いたします。 RC4に関するテキストの寄稿、Andrei Popov、Lucky13に関するテキストに対する笠松浩平、攻撃とDTLSに関するテキストに対するIlari Liusvaara、仮想ホストの混乱に関するテキストに対するAaron Zauner、およびSTARTTLSコマンドインジェクションに関するテキストに対するChris Newmanに感謝します。 Ralph Holzは、この文書の作成においてNICTA（オーストラリアのICT）のサポートに感謝します。
During IESG review, Richard Barnes, Barry Leiba, and Kathleen Moriarty caught several issues that needed to be addressed.
IESGのレビュー中に、Richard Barnes、Barry Leiba、およびCathleen Moriartyは、対処する必要があるいくつかの問題を発見しました。
The authors gratefully acknowledge the assistance of Leif Johansson and Orit Levin as the working group chairs and Pete Resnick as the sponsoring Area Director.
執筆者は、作業グループの議長としてのLeif JohanssonとOrit Levinの支援、および後援のArea DirectorとしてのPete Resnickの支援に感謝しています。
The document was prepared using the lyx2rfc tool, created by Nico Williams.
このドキュメントは、Nico Williamsが作成したlyx2rfcツールを使用して作成されました。
Authors' Addresses
著者のアドレス
Yaron Sheffer Porticor 29 HaHarash St. Hod HaSharon 4501303 Israel
Yaron Sheffer Porticor 29 HaHarash St. Hod HaSharon 4501303イスラエル
EMail: yaronf.ietf@gmail.com
Ralph Holz Technische Universitaet Muenchen Boltzmannstr. 3 Garching 85748 Germany
ミュンヘンのラルフホルツ工科大学ボルツマン通り。 3 Garching 85748ドイツ
EMail: holz@net.in.tum.de
Peter Saint-Andre &yet
ピーターサンタンドレ＆まだ
EMail: peter@andyet.com
URI: https://andyet.com/