Joao Tavora wrote: > 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.
Right, none of which has any application-level consequences. These are all internal details of how TCP implements the guarantees that it does provide to the application. The internal details of TCP don't matter, there is no rational reason an application should care how TCP does its job. They should just care what TCP provides to higher-level protocols. > 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. It doesn't matter. As I explained, this has no application-level consquences. So an attacker can keep the TCP layer or the SSL layer misinformed, so what? So long as the *applications* aren't misinformed (and SSL ensures this is so), who cares? > 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. You are making a nonsensical claim. You are saying "I don't care whether my client application got the data or not, I just need to make sure nothing stopped the data from getting to my client application". If you need assurance the client application got the data, the client application needs to send an acknowledgement. Otherwise, you can look inside TCP and SSL for state information, but you will be destroying the security assurances SSL *to* *the* *application* that are specifically dependent on it not making its own bogus assumptions. > 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! It may do all or some of what you need. But it cannot, in principle, provide confirmation of delivery to the application on the other side. You say you don't need this, but you do. > 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. Then how will you know that the other side got the data? Even if SSL did provide such a thing, it doesn't pass them on to the application. Are you going to find some way to look inside the SSL state to get this information? > 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. You cannot. If you need application-level acknowledgements, you need to implement them. Since it is your application that needs to know this, you *do* need application-level acknowledgements. SSL-level acknowledgements won't help you since you're not the SSL layer, you're the application. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
