Breaking and Fixing Authentication over TLS Reporter: Pan Hao

What is TLS Transparent Transport Layer The main Internet Standard for secure communications Protect any application against a network attacker effortlessly

Two main protocols of TLS Handshake Protocol Record Protocol

Four myths about TLS The principal at the other end cannot change The master secret is shared only between the two peers, so it can be used to derive fresh application-level keys The tls-unique channel binding uniquely identifies the connection The connection authenticates the whole data stream, so it is safe to start processing application data as it arrives 许多持续存在的问题可能因在应用程序所期望的认证保证与TLS实际提供的认证保证之间的不匹配而被指责。 为了论述我们的观点，我们下面列出了关于这些保证的几个神话，其中我们在本文中揭晓 建立连接后： 1）另一方的校长不能改变; 2）主机秘密仅在两个对等体之间共享，因此可以用来获取新的应用级密钥; 3）tls唯一通道绑定[6]唯一标识连接; 4）连接认证整个数据流，所以它在应用数据到达时开始处理是安全的 第一个被普遍认为是通过TLS重新协商扩展[49]来保证的。 第二和第三个用于隧道协议（如PEAP和PEAP）中的中间人员保护SASL和GSS-API中的一些认证模式。 第四个形成了网络上HTTPS会话的基础 这些假设是假的，这样可以实现各种攻击，甚至可以使用最新的，完全打补丁的应用程序TLS 1.2实现。 这些攻击是否应该是归咎于协议或其使用，我们认为运输并且应用协议必须一起分析来实现可靠，有意义的应用级安全性。

New Attacks Over TLS Triple Handshakes considered harmful Client-authenticated TLS renegotiation Compound authentication in tunneled protocols Channel bindings for app-level challenge-response protocols Channel bindings for bearer tokens Truncating Headers & Forcing Cookies Defeat cookie-based authentication Cookie-forcing and used for login CSRF Building new app-level protocols such as sign-on and synchronization protocols using cookies is foolhardy 我们首先指出RSA/DHE中的未知密钥共享漏洞，简短握手，我们组合实现可以同步的恶意TLS代理与诚实的同伴分开连接的钥匙。这些漏洞本身并不构成攻击 TLS的完整性和保密性保证。但是，我们表明它们启用了新的中间人攻击，破坏了通过TLS构建的各种认证机制，包括（a）客户端认证的TLS重新协商 - 例如，如果客户端将证书颁发给两个TLS服务器，另一方可以模仿客户; （b）混合隧道协议认证; （c）渠道绑定应用级挑战响应协议;和（d）频道绑定用于承载令牌。我们举报具体的攻击发布的规格和流行的应用程序在这些类别，包括主流浏览器和HTTP客户端图书馆，VPN应用程序，无线应用程序和邮件聊天服务器 Web浏览器和服务器经常忽略TLS断开并容忍不良信息，从而启用消息截断。 虽然这个漏洞是已知的，我们展示如何应用截断到HTTP头和HTML表单，打开新的漏洞。 在特别是，我们的攻击彻底打败了基于cookie的认证。 我们还显示基于已知攻击的新漏洞向量像cookie强制和它用于登录CSRF。特别是，我们展示了构建新的应用程序级别协议如单点登录和同步协议使用cookie是愚蠢的; 他们放大登录CSRF攻击并使网络攻击者窃取用户的私有文件。

A Man-in-the-middle TLS Proxy Server RSA/DHE Full Handshake 假设C发送客户端你好到A提供RSA密码。然后转发客户端当S响应服务器你好，A转发它到C.因此，客户端和服务器只是用一次的 cr，sr和会话标识符sid对于两个连接都是相同的。接下来，当S将证书证书发送给A，A时将自己的证书certA发送到C.现在，C生成一个预主机密钥pms，在pk A下进行加密，并将其发送到A. A解密pms，在pk S下重新加密，并将其发送到S. 因此，两个连接都具有相同的pms和（因为相同）主密钥和连接密钥相同，所有这些现在在C，S和A之间共享。最后，A使用ms来完成两个连接的握手计算正确的验证数据。被A篡改的信息是如图3（连接1）所示。在这一点上，C和S缓存了同一个会话与A（如由C上的certA表示），并且可选地，A的客户证书）。两个新纪元连接只能由客户端和服务器区分验证数据，这两个连接有所不同。然而，来自一个连接的消息可以自由转发到其他，因为键匹配。因此，如果A走出来方式，C和S可以继续交换消息意识到另一方的委托人已经改变了。

Session Resumption and Renegotiation I Abbreviated handshake for session resumption 假设C，A和S具有同步的会话和连接，如上所述。如果C尝试恢复与A的会话通过一个新的连接，A可以同步这个新的连接到一个新的连接到S.实际上，简单握手更容易同步完全握手。当C发送客户端请求会话恢复时，在新的连接上，A简单地将请求转发给S，和转发S对C的响应不变。 C和S完成握手通过A，重新使用主秘密知道到C，S和A，如连接2的上半部分所示图3. 在两个连接上产生的历元都有相同的钥匙，也与A共享。事实上，新的时代，比原始连接的时代更加同步：客户端和服务器验证这些纪元上的数据也是相同。因此，恢复后，唯一显着的差异两个连接之间是C-A连接与A-S连接的服务器身份证书A的会话具有与服务器身份证书的会话。所有其他差异已被删除。

Session Resumption and Renegotiation II Secure renegotiation handshake 如果会话恢复在新连接上怎么办？该第一次握手现在是简短握手;只有认证会话主机的秘密，而不是整个会话。因此，重新谈判对策没有约束力与旧会话的新连接。这将重新启用其意图修复的中间假模拟人造成的攻击。假设对手A设置了同步会话以及与C和S的连接。如果C恢复会话新的连接，A可以恢复一个新的同一个会话连接到S.如§V-C中所讨论的缩写握手，两个连接上的验证数据都是一样。现在，如果C或S启动客户端认证的TLS重新协商，A可以将所有消息从C转发到S回来，没有改变。客户端和服务器hellos将会请参考缩写握手中的验证数据从而被双方接受。这三次握手图3中描绘了两个连接。在重新谈判结束时，从TLS的角度来看，CS共享一个新的相互认证的会话。 A不有这个新会话的关键，但它可能已经注入在重新协商之前的双向数据，以及这些数据现在可能被C错误地归因于S，反之亦然。换句话说，连接上的TLS对等体已经改变，应用程序可能无法实现，击败目的的安全重新协商扩展。 这个安全问题的起因在于，应用层和加密传输层因为分层的设计，几乎没有互动。举个例子来说，重协商可以发生在一次HTTP请求过程的中间，但应用层并不知晓。 此外，还有可能的一种情况是，Web服务器会将重协商之前的接收数据缓存，和重协商之后的数据一起转发给应用服务器。当然重协商之后参数会发生变化，如可能使用了不同的客户端证书，从而最终导致了TLS和Web应用出现mismatch（不协调）。

Summary of Mitigations Do not allow the peer to renegotiate its certificate Do not use tls-unique after session resumption To derive application keys from the TLS master secret, hash the session’s certificates into the derivation Buffer application data until its semantics is unambiguous; discard it if the TLS connection is torn down. Do not share secret cookies between HTTP and HTTPS connections, or between different origins 独立地，依赖现有TLS API的应用程序可以通过遵循一些保守的设计原则来减轻本文的攻击，并以其功能为代价。 1）不允许对等体重新协商其证书。 2）在会话恢复后不要使用tls-unique。 3）从TLS主密钥导出应用密钥，将会话的证书散列到派生中。 4）缓冲应用数据直到其语义是明确的; 如果TLS连接被拆除，则将其丢弃。 5）不要在HTTP和HTTPS之间共享秘密cookie连接，或不同来源之间

Towards Verified Application Security Proposed TLS Extensions Propose two new TLS extensions that prevent the attacks without the need to change applications Apply to all protocol versions from SSL3 to TLS1.2 as well as DTLS Simple Verified HTTP over TLS Carefully-written applications can defend against these attacks Program miHTTPs, which is a proof-of-concept: Does not nearly provide the flexibility required by modern browsers and web services But automatically handles all the details of the underlying TLS connections, including multiple handshakes, resumption and negotiation, and trunction 原则上，精心编写的应用程序可以防御这些攻击，而不需要更改TLS。 为了我们的主要建议，并表明“透明”的应用安全可以通过TLS实现，我们编程miHTTPS： 我们指定其预期的安全属性我们使用F7验证它们，一种基于类型的验证工具。因此，我们正式关联了精确的低级TLS API由miTLS提供给一个更简单，更抽象的HTTPS API。结合起来，我们获得了第一个加密验证实现HTTPS。 在目前状态下，miHTTPS是一个概念证明：它几乎不提供现代浏览器和Web服务所需的灵活性。 但是呢自动处理底层TLS的所有细节连接，包括多次握手，恢复和谈判和截断

Conclusion Describe a new class of man-in-the-middle attacks against authentication over TLS, targeting the resumption and renegotiation features of the handshake Present new exploits on HTTPS sessions based on cookie-forcing and truncation Apply these attacks to break the expected authentication guarantees of several state-of-art protocols, libraries, applications, and web services Present TLSlevel proposals which are consolidated in patches for OpenSSL and miTLS, also build and verify a basic high-level HTTPS API on top of miTLS 1. 描述针对TLS认证的新一代中间人攻击，针对握手的恢复和重新协商功能 2. 基于cookie强制和截断，在HTTPS会话上展示新的漏洞 3. 应用这些攻击来打破几个最先进的协议，库，应用程序和Web服务的预期认证保证 4. 现在的TLS级别提案被整合到OpenSSL和miTLS的补丁中，同时构建并验证了基于miTLS的基本高级HTTPS API