TLS Triple Handshakes
imperialviolet.org
imperialviolet.org
At its root, the attack weaponizes unknown key share attacks by deploying them in the context of a TLS MITM. UKS attacks are a well-known but infrequently considered protocol vulnerability; the best documentation I know of them (thanks to smarter friends who pointed this out to me) is the STS paper from '99:
http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=33A...
The basic idea is that protocols assume that if Alice and Bob agree on a key, Alice and Bob must both believe they've authenticated to each other. In reality, Mallory can often exploit that assumption. For instance, Mallory can negotiate a session with Alice and Bob, arrange to have the sessions arrive at the same key, and then replay Alice's messages on the connection to Bob.
The kernel of the attack in this paper is a UKS attack that exploits the differing assumptions of two different session authentication schemes that coexist in TLS. The first is the ordinary public-key exchange that people assume happens on every TLS connection. The second is the session resumption form, which skips the public-key exchange. The problem is that the first form is cryptographically bound to the certificates on the connection, but the second form is bound instead to the shared state that is computed by both sides of the connection and not explicitly to the certificates. An attacker can MITM Alice and Bob, synchronize their keys (by waiting for Alice to compute a key and send it to the MITM, unwrapping it, and resending it to Bob), kill the session, then MITM the session resumption that happens when Alice reconnects; the attacker has laundered their involvement in the session.
Aside: to me, the funnest part of the paper is the synchronization/UKS attack that happens in classic DH TLS (which is rarely used). Instead of unwrapping and resending Alice's key, Mallory can trick Alice into accepting a bogus DH group which reveals her key to Mallory. The researchers found that WinAPI' SChannel and Chrome/Firefox NSS were susceptible to malicious DH parameters, as were 12% of the top Alexa servers. Wee!
Why "rarely used"? Because most DHE TLS connections are Elliptic Curve DH, not classic DH. Elliptic curve groups are much scarier to validate than classic DH groups (where you really just care that the DH modulus is large and prime and the generator generates the whole group --- though ironically the authors found that this doesn't reliably get validated). As a result, TLS stacks require specific ECDH groups; you can't play as many games with them.
The downside (to me, not to you) is that the attack has limited impact. Basically, what this UKS attack mostly does is revive a session resumption attack Marsh Ray found a couple years ago. Alice can connect to Bob; Bob demands a client certificate from Alice. Mallory wants to connect to Bob, and so makes a connection to Bob, sends data, and then renegotiates TLS with a handshake replayed from Alice and Bob. Mallory can't read those messages or, for that matter, anything subsequent on the connection, but Mallory's data may be accepted by Bob, despite it not being authenticated.
'cperciva, 'pbsd --- I've given you a lot to work with here. Tell everyone else here how I got this wrong! :)
Assume Alice, Bob, and Mallory, and a "TRANSACT" message from Alice to Bob.
Mallory can negotiate a connection to Bob. Bob knows it's talking to Mallory.
If Mallory can arrange to negotiate a key with Bob that is the same as a key under which Alice has sent TRANSACT, Mallory can replay Alice's message: it it encrypted under the same key Mallory shares with Bob.
Bob is counting on the fact that all messages from Mallory and Alice are encrypted under different keys. Bob assumes the session negotiation between Mallory and Bob cryptographically binds all the messages on that session to the session.
But that's not the case: messages Mallory has taken from Alice are "portable" to Mallory's session with Bob, because they're encrypted under the same key. Bob is talking to Mallory and trusting that any message it receives from Mallory must come from Mallory. That's not a valid assumption. Bob trusts the TRANSACT message, but shouldn't.
In TLS, you can replace the TRANSACT message with the client certificate handshake. Mallory snips the client handshake message from a session between Mallory and Alice, then replays it on a session between Mallory and Bob. Mallory puts malicious application data on the session to Bob, then "authenticates" it with the replayed key exchange, tricking Bob into accepting the application data.
Mallory can get client certificate handshakes to replay from Alice, because browsers will send the same client certs to arbitrary sites; the browser's client certificate functionality assumes the same CA model that server certificates use, so as far as the browser knows, there's no problem showing its certificate to arbitrary sites. It shouldn't be, but for the unknown key share problem.
Alice ------> Bob: Hello, I'm Alice, my public key is A and here's a random number, R1.
Alice <----- Bob: Hello Alice, I'm Bob, my public key is B and heres another random number, R2.
Alice ------> Bob: OK Bob, I know B, here's Proof1 that I have arrived at a session key between us. I've used both R1 and R2 in my math, which you can verify, and be assured that this proof is fresh and unique to this handshake.
Alice <----- Bob: Thanks Alice, I accept Proof1, here's Proof2 that I have arrived at the same session key. I've have also used R1 and R2 in my math, which you can verify and be assured that this proof is fresh and unique to this handshake.
Is the problem in client auth TLS that R1 simply doesn't exist or that Proof1 can be replayed?
I agree, although I think the break of channel bindings is going to turn up some interesting cases that are harder to fix than client-cert auth in browsers.
Being a Montgomery curve, the order is a multiple of at least 4, and it is possible to try and slip a point of order <= 4 past Alice, which would have the same effect as sending {0,1,-1} in DH. No implementation of curve25519 that I know of checks for low-order input points. NIST curves, being of prime order, have no such pitfall (unless you allow some way of representing the point at infinity in affine coordinates). On the other hand, you can try to slip invalid points past NIST curves, whereas curve25519 and friends are protected against this.
PS: I haven't really anything to correct: TLS minutia are not really my area of expertise. It must be some kind of achievement to be lumped together with the likes of 'cperciva, though.
The idea of that attack is similar to what we did in CRIME, but applies to HTTP responses. Basically you inject enough data to split the response into two records and drop the second one. Some browsers would happily accept the truncated response, and change their state. As a result you could remove the Secure flag on the Set-Cookie header, and steal the cookies if the server or the client doesn't support HSTS.
Yay it's broken! I can't help but be impressed by this.
An error occurred during a connection to
www.imperialviolet.org:6628.
Renegotiation is not allowed on this SSL socket.
(Error code: ssl_error_renegotiation_not_allowed)Firefox is AFAIK not vulnerable to this.
Firefox enforces that the renegotiation certificate chain are valid for the site name which solves the renegotiation issue.
Is that anything like McDonald's Triple Thick Milkshakes?
EDIT: I REGRET NOTHING!!!