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.