No. Part of the SSL/TLS handshake protocol is the definition of what the content of the message should include -- i.e., the HMAC. If it doesn't exist or is different from what it's supposed to be, the side that failed to validate it sends a decryption_error fatal alert and closes the connection.
The application itself doesn't need to worry about it. -Kyle H On Sun, May 17, 2009 at 4:12 AM, João Távora <joaotav...@gmail.com> wrote: > Hi, > > I've got a newbie question about a possible SSL/OpenSSL > > Consider two machines A and B and a man-in-the-middle, Z, who can snoop > traffic. > > A and B exchange certificates securely, i.e. Z lets the SSL handshake > through. Therefore A sends a first application-data message to B. > > Z cannot read the message since it is encrypted, but I guess he can block > it, right? > > My question is, can Z fake TCP ACK segments, with sequence number and > everything, and replay them to A so that A thinks that B has received the > message and B never realizes that A sent a message? > > I can't understand if legitimate TCP ACK segments also need to be > encrypted/signed in some way agreed upon during the handshake. > > In other words, do I need to implement application-level acknowledge > messages? > > If so, why? > > Thanks a lot!! > Joao > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
