Given a NDA forbids me from giving you more details let me give you an analogy with postal services: I assume you know of postal services where you can get a delivery receipt. you can get a receipt that the recipient was notified, if the postman gets shot along the way, the postal service will send more postman. If they run out of postmen I get a receipt stating the delivery was impossible.
In many situations, like the state wanting you to appear in court to testify, all it needs is one such little receipt of notification. If you fail to appear in court, that's your problem. It's completely OK and encouraged for applications to rely on services provided to them by inferior layers. When writing a TCP application I don't need to look inside the TCP layer for acnowledgement information, I just get an errno set in my next "write()" call which will say "connection reset, broke or anything". And, my little Schwartz-friend. don't bother with more pedantic metaphysical considerations about my "misunderstandings" and "nonsenses". I'm sorry about the original quote from wikipedia if that's what pissed you off. On Mon, May 18, 2009 at 11:10 PM, David Schwartz <dav...@webmaster.com> wrote: > > 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-us...@openssl.org > Automated List Manager majord...@openssl.org > -- João Távora joaotav...@gmail.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
