Thanks once again for the responses...I would like to add few more points here..there seems to be a callback function (msg_callback) within the ssl_st structure, which when registered by the application for a specific content type, SSL_read, seems to call that if a pkt of that content type is seen on the wire. I was thinking of making use of this, now my questions are
a. Does this msg_callback get executed after peek? or after read? if former, I could simply discard the buffer as peek does not dequeue the pkt, so the kernel can read it again. If its a "read", then I need to pass on that buffer to the kernel module which does the actual decryption. b. I dont see this msg_callback getting called for content type "Application data", I see the code only for the other ssl record types..now am I missing something here. As you said, kernel has to do a lot of processing wherein it should read the ssl record header, and if not(application data) hand the fd control back to userspace. We are going to somehow poll from userspace as well as kernel for the same connection, and do a fd transfer from userspace to kernel. so what I have now learnt from the responses is that I can expect that openssl will end up caching application data, as as the control pkts gets processed, userspace could endup reading app data..so if I do an SSL_peek before every SSL_read can I prevent processing of application data? Also there seems to be no low/high level api to access this read buffer cache of ssl.. or is there? This read buffer anyhow is a pointer to the application read buffer rite? or is there some bufcopy happening internally within openssl? Coz if its just a pointer I am thinking if I could just pass a minimal buffer size wherein it can read only handshake record size pkts, then indirectly I could end up controlling the read. PS: If i am not making sense in more than 1 way(s) beg apoligies, am a newbie.. Thanks --Gayathri -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Schwartz Sent: Friday, July 07, 2006 1:47 AM To: openssl-users@openssl.org Subject: RE: Does Openssl cache App data -- 2nd Try.. > Thanks david..let me add more clarity to my requirement... > Is there someway for the application to know before calling ssl_read, > that some app data buffer can be got for sure? Only by putting that data in a buffer, which seems to be what you don't want. > Or can SSL_peek prevent me > from hitting the case you have mentioned? SSL_peek does precisely what you claim you don't want, which is to put the data in a cache. > The reason is we are in > a scenerio > wherein all ssl control pkts are gonna be processed from userspace using > openssl > and all app data pkts are gonne be processed from kernel using our own ssl > implementation. So when userspace openssl does manage to read app data, I > need > to ensure that whatever it has cached (add data bytes), has to be cleared > and > copied into our ssl library in kernel, so that it can wait for > the remaining > bytes and do the decryption. > So in a crux, what can I do to ensure that openssl does not read app data > pkts > at all.. You have to separate the data in the kernel. I would not recommend trying to hack OpenSSL's high-level functions for this purpose but use the low-level ones instead. Ignore SSL_read/SSL_peak/SSL_write and the like. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
