Hi
I'm glad for your negative answer and that's also what I suspect :-)
... but I didn't really understand why.
Maybe I didn't really fully explain myself, the problem is not really
ensuring secrecy and integrity, it's ensuring delivery.
As I understand it this is normally done with TCP ACK segments: in a
normal (non-SSL) TCP application, the receiver B sends back a TCP
segment containing the sequence number of any messages received so
far, and piggybacks any reply to it.
If no reply is needed the payload of this ACK is empty I suppose.
If this is the case with SSL/TCP as well, then I suppose an attacker
could fake the ACK, because he wouldn't have to place any encrypted
data on it, just tweak the sequence number fields. Thus he could block
the original message and send this fake reply back to A.
In this case A doesn't expect anything else, it wouldn't know that B
didn't actually receive the message! Also B would be unaware that A
has actually sent a message!
In this case the attacker would have tampered with the delivery
assurance of TCP but none of the sides would be aware of that.
João
On May 17, 2009, at 5:26 PM, Kyle Hamilton wrote:
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
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
