Through that connection I transfer $100 to my friend. However, it just so happens that my friend controls a proxy somewhere between A and B (at say M) and is watching the encrypted packets go by (he can't see them unencrypted, but he is capturing the encrypted contents).

A -> M -> B

Scenario A) The ssl connection is still active, and my friend replays the packet that gave him $100.

Scenario B) I send another request to the bank for something unrelated. But this time my friend, at M, modifies my packet in transit to be the same packet that gave him $100 earlier.

Not sure if these scenarios would be handled differently, so I considered them separately.

What does SSL/TLS do to prevent these type of live replay attacks? I get that SSL generates a nonce during the initial handshake, but that would only prevent replay attacks for another ssl session down the road once new nonces are generated.

1 Answer
1

SSL connections use a stream cipher (RC4) or a block cipher in CBC mode (AES, DES), i.e. (very roughly speaking) ciphers where the next encrypted block is a function of all previously encrypted blocks.

While SSL is immune to replay-attacks, your reasons are invalid. In particular if it used just AES-CBC it'd be vulnerable in Scenario A. What prevents replays within the connection is that each fragment is protected by a MAC that includes a sequence number.
–
CodesInChaosNov 5 '12 at 11:49

Well, I am not an expert in this field, but from what I understand of how CBC works, the previous encrypted block is used as the initialization vector when encrypting the next one, so that the two packets giving your friend $100 will actually differ, rendering a replay attack impossible (see for instance: en.wikipedia.org/wiki/File:Cbc_encryption.png). Maybe you are mistaking CBC for ECB?
–
zakkNov 5 '12 at 17:37