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
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（DTL）的已知攻击
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（DTL）的使用提出通用和协议特定的建议。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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).
这种情况是创建UTA工作组的动机之一，该工作组的任务是为TLS和DTL的使用制定通用和特定于协议的建议[RFC6347]（除非第3节另有说明，否则本文件中提供的所有信息均适用于DTL）。
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].
有关此处列出的攻击的更详细讨论，请参考[攻击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.
当存在针对攻击的标识符时，我们会将其常见漏洞和暴露（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的未加密协议，特别是在HTTP流量和HTML页面通过线路时修改这些协议，从而完全取消安全套接字层/传输层安全性（SSL/TLS）的使用。这些攻击统称为“SSL剥离”（更通用的“降级攻击”的一种形式），最初由Moxie Marlinspike[SSL剥离]引入。在网络流量方面，
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严格传输安全（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指示。除非添加类似HST的解决方案，否则无法缓解这一问题。
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]利用TLS 1.0实现的密码块链接（CBC）（即可预测的初始化向量）的问题来解密数据包的一部分，特别是在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加密设计的结果是存在填充oracle攻击[padding oracle]。这些攻击的最新体现是幸运十三攻击（CVE-2013-0169）[CBC攻击]，这是一种定时边通道攻击，允许攻击者解密任意密文。
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.
通过使用AES-GCM[RFC5288]或encrypt-then MAC[RFC7366]等经过身份验证的加密，而不是使用TLS默认的MAC-then-encrypt，可以减轻Lucky十三攻击。
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.
不使用时间信息的填充oracle攻击的一个更新版本是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攻击Pau]、[RC4攻击Man]和[RC4攻击FMS]。最近的密码分析结果[RC4攻击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.
当TLS与TLS级压缩一起使用时，犯罪攻击[犯罪]（CVE-2012-4929）允许主动攻击者解密密文（特别是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]和后来的违约攻击[Breake]（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.
可以通过禁用TLS压缩来缓解时间攻击。我们不知道TLS协议级别的漏洞攻击缓解措施，因此需要应用程序级别的漏洞缓解措施（请参见[漏洞]）。例如，使用跨站点请求伪造（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中得到缓解，但依赖oracle版本检查的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.
当TLS与大多数非Diffie-Hellman密码套件一起使用时，获取服务器的私钥就足以解密使用该服务器启动的任何会话（过去和未来）。例如，流行的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.
通过更好地保护私钥（例如，使用操作系统保护或专用硬件），可以减轻此类攻击。更有效的方法是使用提供“前向保密”的密码套件，这一特性使得泄露秘密（如私钥）不会将过去或未来的会话暴露给被动攻击者。
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）和椭圆曲线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重新协商机制的主要攻击适用于协议的所有当前版本。[RFC5746]中描述了该攻击以及解决该攻击的TLS扩展。
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].
三重握手攻击[Bhargavandfs14]使攻击者能够使两个TLS连接共享密钥材料。这会导致大量攻击，例如中间人攻击、破坏安全重新协商以及通过TLS导出器[RFC5705]或“TLS唯一”[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 实现可能不会验证服务器标识。此验证通常相当于将协议级服务器名称与证书的Subject Alternative name字段相匹配。注意：在可分辨名称的公共名称部分也经常可以找到相同的信息，一些验证器错误地从该部分而不是从主题替代名称中检索该信息。
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.
另一种利用简单编码错误（边界检查）的实现攻击是Heartbleed攻击（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.
这种用户行为由（可以说是合法的）“SSL代理”使用，它们解密和重新加密TLS连接，以强制实施本地安全策略。它还被攻击者滥用，攻击者的目标是获取对加密信息的访问。
Mitigation is complex and will probably involve a combination of protocol mechanisms (HSTS, certificate pinning [KEY-PINNING]), and very careful UI design.
缓解措施非常复杂，可能涉及协议机制（HST、证书固定[密钥固定]）和非常仔细的UI设计的组合。
DTLS [RFC4347] [RFC6347] is an adaptation of TLS for UDP.
DTLS[RFC4347][RFC6347]是TLS对UDP的一种改编。
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，这在DTL中是不允许的。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>.
[Attacks iSec]Sarkar，P.和S.Fitzgerald，“SSL攻击，野兽、犯罪、时间、破坏、幸运13和RC4偏见的综合研究”，2013年8月<https://www.isecpartners.com/media/106031/ ssl\u攻击调查.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/ 针对SSL TLS.html>的浏览器攻击。
[BREACH] Prado, A., Harris, N., and Y. Gluck, "The BREACH Attack", 2013, <http://breachattack.com/>.
[Breake]Prado，A.，Harris，N.，和Y.Gluck，“漏洞攻击”，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，“三重握手和切饼干器：通过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加密标准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.，和V.Shmatikov，“在SSL/TLS实施中使用Frankencert进行证书验证的自动对抗性测试”，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>.
[Brumley 03]Brumley，D.和D.Boneh，“远程定时攻击是可行的”，2003年<http://crypto.stanford.edu/~dabo/papers/ssl timening.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，“幸运十三：打破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.，“禁止RC4密码套件”，正在进行的工作，草稿-ietf-tls-Banking-RC4-01，2014年10月。
[CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", EKOparty Security Conference, 2012.
[犯罪]Rizzo，J.和T.Duong，“犯罪袭击”，EKOparty安全会议，2012年。
[CVE] MITRE, "Common Vulnerabilities and Exposures", <https://cve.mitre.org/>.
[CVE]MITRE，“常见漏洞和风险敞口”<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计算机和通信安全会议记录，第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]Gillmor，D.，“TLS的协商有限域Diffie-Hellman瞬时参数”，正在进行的工作，草稿-ietf-TLS-协商-ff-dhe-052014年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.
[KEY-PINNING]Evans，C.，Palmer，C.，和R.Sleevi，“HTTP的公钥锁定扩展”，正在进行的工作，草稿-ietf-websec-KEY-PINNING-212014年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，“在SSL/TLS中攻击基于RSA的会话”，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，“这只卷毛狗咬人：利用SSL 3.0回退”，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>.
[Padding Oracle]Vaudenay，S.，“CBC将应用程序填充到SSL、IPSEC、WTLS中导致的安全缺陷…”，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.“应用密码学：C语言的协议、算法和源代码”，第二版，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攻击AlF]AlFardan，N.，Bernstein，D.，Paterson，K.，Poettering，B.，和J.Schuldt，“关于TLS中RC4的安全”，Usenix安全研讨会2013，2013年8月<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攻击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袭击者]Mantin，I.和A.Shamir，“对广播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攻击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，“数据报传输层安全”，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，“传输层安全（TLS）协议版本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，“用于TLS的AES伽罗瓦计数器模式（GCM）密码套件”，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.“传输层安全（TLS）关键材料导出器”，RFC 57052010年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，“传输层安全（TLS）重新协商指示扩展”，RFC 57462010年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 59292010年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，“数据报传输层安全版本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严格传输安全（HSTS）”，RFC 67972012年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 69892013年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，“普遍监控是一种攻击”，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]谢弗，Y.，霍尔茨，R.，和P.圣安德烈，“TLS和DTL的安全使用建议”，正在进行的工作，草案-ietf-uta-TLS-bcp-082014年12月。
[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>.
[时代]Be'ery，T.和A.Shulman，“完美的犯罪？只有时间才能证明”，黑帽欧洲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对本文件的反馈。我们感谢安德烈·波波夫（Andrei Popov）对RC4的贡献，科海·卡萨马祖（Kohei Kasamatsu）对Lucky13的贡献，伊拉里·柳斯瓦拉（Ilari Liusvaara）对攻击和DTL的贡献，艾伦·扎伊纳（Aaron Zauner）对虚拟主机混乱的贡献，克里斯·纽曼（Chris Newman）对STARTTLS命令注入的贡献。拉尔夫·霍尔茨衷心感谢NICTA（澳大利亚国家信息通信技术协会）在编写本文件过程中给予的支持。
During IESG review, Richard Barnes, Barry Leiba, and Kathleen Moriarty caught several issues that needed to be addressed.
在IESG审查期间，Richard Barnes、Barry Leiba和Kathleen 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担任工作组主席，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
EMail: yaronf.ietf@gmail.com
Ralph Holz Technische Universitaet Muenchen Boltzmannstr. 3 Garching 85748 Germany
拉尔夫·霍尔茨技术大学。3加兴85748德国
EMail: holz@net.in.tum.de
EMail: holz@net.in.tum.de
Peter Saint-Andre &yet
彼得·圣安德烈&还没有
EMail: peter@andyet.com
URI: https://andyet.com/
EMail: peter@andyet.com
URI: https://andyet.com/