David,
I think we're drifting a little bit from my original question here. I
certainlly don't mean to imply that there's anything wrong with SSL or
the OpenSSL's implementation, I just want to discover if it does what
I want.
TCP specifically does *not* communicate ACKs up to the application
because
these ACKs do *not* indicate that higher levels on the other end have
received the data.
Certainly! I never said it did. TCP ensures delivery to the host, not
the application. But it does ensure it up to the host, or if that cant
be achieved the peer host is appropriately notified.
My problem is that a a TCP hijack might prevent this notification
without *any* host ever being alerted. Incidentally, the system I'm
working on does a similar kind of hijacking, although for "enrichment"
purposes, not attacks.
In particular the problem I presented is connected with an
implementation of a distributed licensed feature control system, where
both server and client application are controlled by me.
In *my* problem, I can assume the client application will never crash
and I don't care if it processed the data correctly. I just need to
know that no client silently blocked the message that my server sent
and noone ever noticed.
Without SSL, the solution would then be to implement application-level
acknowledges, sequence numbering, and digests of message contents
concatenated with a private key to avoid blocking, replay and forgery
attacks, respectively.
But apparently the SSL protocol does a lot of this!
Since what I've read from the RFC, SSL is just an application running
on top of TCP transport, if there is such a thing as SSL acknowledges,
also encrypted with a secret key agreed on during handshake, the
client cannot forge these (easily). In that case, in my
application_level2 on top of SSL, I don't need to implement
acknowledge messages.
In that case I could just write to the SSL socket and, if I get no
errors, be sure the data arrived at the other side.
J
