Are SSL encrypted requests vulnerable to Replay Attacks? If so, what are good options to prevent this?
5
-
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.– k1DBLITZNov 5, 2012 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.– CodesInChaosNov 5, 2012 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.– k1DBLITZNov 5, 2012 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.– CodesInChaosNov 5, 2012 at 15:26
-
3Did you actually read the other post? The scenario referenced a proxy server that someone had control over, aka, man in the middle.– k1DBLITZNov 5, 2012 at 18:58
Add a comment
|
1 Answer
The SSL/TLS channel itself is protected against replay attacks using the MAC (Message Authentication Code), 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).
-
1While 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). Sep 12, 2012 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.– BrunoSep 12, 2012 at 18:57
-
3Details of the handshake are essential too, else an attacker can simply replay the whole connection. Sep 12, 2012 at 19:02
-
3For reference, MAC here means "Message Authentication Code". Googling "TLS MAC" will get you lots of results about Macintosh and Layer 2 media access control addresses Jun 3, 2016 at 19:42
-
1@Abraham No, I meant the sequence number as defined in the TLS specification (it's a quote from that spec).– BrunoJan 13, 2019 at 0:18