On Mon, Mar 14, 2016 at 12:23 PM, Ryan Hamilton <r...@google.com> wrote:
> > On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating <geo...@geoffk.org> > wrote: > >> So, I don't think HTTP is generally safe against attacker-forced >> replay, and would suggest great caution in allowing it. >> > > It's worth keeping in mind this recent paper about Replay attacks against > HTTPS <http://blog.valverde.me/2015/12/07/bad-life-advice/#.VucOsJMrIxN>. > TL;DR: Attackers can already force a browser to replay requests basically > at will. As a result, it's not clear that 0-RTT replay makes this > situation worse. > Yay, this attack is finally published. Now I can argue that stateful 0-RTT resumption is secure enough to be the default 0-RTT connection mode in TLS 1.3. Summary: The stateless 0-RTT modes currently described in the TLS 1.3 spec are somewhat dangerous and should be used with caution and only by admins who know what they are doing. In contrast, 0-RTT resumption from session caches has almost the same security as session resumption in TLS 1.2. This should be the default 0-RTT mode in TLS 1.3, IMO, though stateless PSK 0-RTT should also be supported to allow advanced users to achieve even higher performance. The attack in the paper is important because it explains why I do not care about the following attack, at least for HTTPS. Suppose a company has properly implemented 0-RTT resumption using session caches. They support strong client auth, full PFS, and would like to think they prevent replay attacks. This is a large company with non-synchronized session caches in data centers around the world. The has the following steps: - The attacker captures 0-RTT packets intended for a local data center, and holds onto them without letting them through (yet). - The attacker also sends a copy of these packets to a remote data center. - The remote data center, since it does not have the session cached, drops to a 1-RTT handshake. - The TLS layer in the client completes the 1-RTT handshake, and then resends the 0-RTT data, as required by the TLS 1.3 spec. This is accepted by the remote data center. - The attacker simultaneously sends the local data center the initial 0-RTT packets, which are accepted by the local data center because the session is in the cache. If this were HTTPS traffic, this attack would work against TLS 1.2, because the browser would resend the packets rather than the TLS layer. In any case attackers can replay _any_ HTTPS packet using the attack from the paper. This attack gains the attacker nothing new against HTTPS. Because of this, I recommend that POST requests be allowed as 0-RTT data over session-cache based stateful 0-RTT resumption, but not over stateless 0-RTT resumption. The ability for an eavesdropper to infinitely replay 0-RTT data is specific to stateless 0-RTT resumption. So, is there any application that cares about this attack? Consider ssh using TLS 1.3, with 0-RTT to accelerate how fast a user's command is executed. Clearly, we cannot allow the user's command to be executed twice. Even if the destination machine is a VM in the cloud, eventually the connection is routed to the same virtual machine for both connections. The session cache on that machine would get a hit on the first connection, and execute the user's command. The second set of packets would be rejected because the session resume count would be wrong. I see no way for an attacker to succeed in a replay attack. In general, I expect applications that are inherently sensitive to replay (such as ssh) to terminate all TLS connections in the same place, where the session cache is shared and synchronized. Otherwise, random network errors would be a huge problem. Distributed applications such as HTTP that terminate all over the place have had to deal with random replay issues from the beginning, which is why no one is seems to be terribly upset by the attack described in the paper. Stateful 0-RTT resumed sessions can provide significant security guarantees not offered by stateless 0-RTT: - Effective, although imperfect, reply defense, which is good enough for real-world deployment in most cases (are there any counter-examples?) - Strong client auth works: even a replay attack will fail to forge a proof of possession or cause a server to accept a signature twice. - PFS is possible, unlike with DH 0-RTT, although it also can be done with stateless PSK 0-RTT (a good reason to prefer PSK 0-RTT over DH 0-RTT) The only new security concern I see compared to TLS 1.2 session resumption is that the TLS layer sometimes will replay packets on its own without involving the application layer. This appears not to be a problem for HTTPS and other protocols that already replay packets when there are network errors. For other applications, it should be carefully considered before choosing to use session-ID based 0-RTT resumption, but I expect it to be safe for protocols that already have to deal with noisy network connections. Bill
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
