Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 4 down vote favorite
1

Are SSL encrypted requests vulnerable to Replay Attacks? If so, what are good options to prevent this?

share|improve this question
Based on the question you posted here, security.stackexchange.com/questions/23607/… that was flagged as a duplicate - just wanted to point out that it is possible for a man in the middle utilizing a proxy to decrypt the packets. – k1DBLITZ Nov 5 '12 at 14:33
Not sure what you want to tell us. Replays and MitM are unrelated. And MitM, with proxy or otherwise, only works if the client doesn't validate the server certificate correctly. – CodesInChaos Nov 5 '12 at 15:02
I thought it was pretty obvious. I was informing "us" don't make the assumption that SSL cannot be decrypted by a man in the middle. – k1DBLITZ Nov 5 '12 at 15:19
But 1) This question is not about MitM, it's about replay attacks. 2) MitM isn't possible when you use SSL correctly. – CodesInChaos Nov 5 '12 at 15:26
Did you actually read the other post? The scenario referenced a proxy server that someone had control over, aka, man in the middle. – k1DBLITZ Nov 5 '12 at 18:58

1 Answer

up vote 3 down vote

The SSL/TLS channel itself is protected against replay attacks using the MAC, computed using the MAC secret and the sequence number. (The MAC mechanism is what ensures the TLS communication integrity). See TLS 1.1 specification Appendix F.2:

To prevent message replay or modification attacks, the MAC is computed from the MAC secret, the sequence number, the message length, the message contents, and two fixed character strings.

EDIT: As @CodesInChaos points out, the handshake must also be taken into account, otherwise the whole TLS connection could be replayed (not just some records, which is what the MAC and sequence number would protect against). If an attacker replayed the same Client Hello message, the server would return a Server Hello with a different server random value thereby altering the rest of the key exchange. In addition, in RSA key exchange mode, only the initial legitimate client would know the pre master secret it has encrypted; in DHE key exchange mode, the client and server randoms are signed together in the server key exchange message (hence the importance of good random numbers there too). (There's a bit more on these two modes in this question.)

It's not clear from your question what you're trying to protect against replay attacks. Typically, this would be a message sent above the SSL/TLS layer, used by your application.

The encryption provided by SSL/TLS certainly prevents an eavesdropper from seeing that application request, and thus from replaying it with their own separate SSL/TLS connection.

However, SSL/TLS on its own doesn't necessarily prevent the legitimate initial user from replaying a request. Protocols and applications that require this additional level of protection tend to have nonce-based mechanisms at the application level to address this problem (which is rather independent of SSL/TLS, although preventing eavesdropping helps).

share|improve this answer
While you're right that TLS protects against replay attacks, your explanation isn't very convincing to me. I know protocols which have everything you mention, and still suffer from replay attacks (at least when implemented naively). – CodesInChaos Sep 12 '12 at 18:52
@CodesInChaos, are you talking of the way TLS messages themselves are protected or at the application level? For TLS, I think a good MAC based on the sequence number should be sufficient to prevent replays, don't you? You just wouldn't process a message with the same sequence number twice. – Bruno Sep 12 '12 at 18:57
@CodesInChaos "I know protocols which have everything you mention, and still suffer from replay attacks" protocols implementing a message sequence abstraction? (ordered stream) – curiousguy Sep 12 '12 at 19:00
1  
Details of the handshake are essential too, else an attacker can simply replay the whole connection. – CodesInChaos Sep 12 '12 at 19:02
@curiousguy I believe a naive implementation of CurveCP suffers from replay attacks. A well implemented server will avoid it, but it's easy to get wrong. (See "Issue 3" in my blog entry on CurveCP crypto) – CodesInChaos Sep 12 '12 at 19:05
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.