AFAIK, SSL will encrypt the message under secure. But I still have the concern whether or not a man in the middle can catch the package and duplicate it e.g. 1000 times

  • 3
    Sure, they could duplicate the encrypted data. Wouldn't do them much good, though. What exactly are you fearing? – ceejayoz Apr 5 '14 at 15:35
  • Yes, under at least one specific circumstance that a proper implementation should never encounter, see: security.stackexchange.com/questions/3664/… – Brian Apr 5 '14 at 17:25

Sure, a passive man-in-the-middle attacker can catch the encrypted packet - that's why you do encryption. But because each SSL connection uses a unique encryption key the attacker cannot use this sniffed encrypted packet later to inject it into another connection. And as long as the encryption key is not compromised (which means for RSA key exchange that the private key of the certificate is not compromised) the attacker can not decode the sniffed packet.

Apart from that an active man-in-the-middle attacker might put itself in-between the parties, e.g. instead of Alice talking to Bob Alice will talk to Mallory and Mallory to Bob. To make this impossible you need the identification part of SSL, e.g. certificate checking and verification of the host name (one alone is not enough). Only this makes true end-to-end encryption possible.


Can an encrypted payload be retransmitted - sure. Would it be accepted at a later time - not likely. Different logical applications of cryptographic techniques have differing characteristics. SSL (now a days called TLS) is designed to provide 'tamper proofing' and 'end point authentication' and optionally 'opacity'. Tamper proofing is ensuring that if someone changes what was sent the recipient will not it happened. End point authentication is the ability to know with whom you are speaking (not necessarily what person, only what asymmetric cryptographic key was used as an identity). Opacity is what most folks think of as encryption.

Being able to inject a chunk of an SSL session at a later point into another SSL session is a form of replay-attack and there are quite a few characteristics of TLS that prevent that from working. By design the tamper-proofing characteristic would provide this since the client (or server, depending on which way you toss the replay package) would notice that it was not what the other side just sent - that is the data was tampered with. The math behind it is a bit fancy but you can find it by reading up at the IETF [an organizationt that tracks and organizes standardization efforts for the Internet] http://datatracker.ietf.org/wg/tls/charter/ or at Wikipedia http://en.wikipedia.org/wiki/Transport_Layer_Security .

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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