> 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.
I can't quite follow you. The whole thing you are trying to avoid is
caching of application data, but this is SSL_peek's whole point. The main
difference between SSL_read and SSL_peek is that SSL_peek caches the
application data (so you can peek at it again or read it later) whereas
SSL_read discards it.
> 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.
This seems like an overly-complex solution. The kernel should always own
the SSL connection. It should analyze received data to determine if it is
protocol or application. If application data, it should decrypt it and
return it as application data. If protocol data, it should pass it to
user-space for SSL protocol processing. This seems like a clean and simple
approach.
> 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?
I don't understand what SSL_peek and SSL_read are meant to be in the
context you are using them. These are user-space OpenSSL functions and you
are supposed to be doing SSL in kernel.
> PS: If i am not making sense in more than 1 way(s) beg apoligies, am a
> newbie..
I guess I can't seem to follow your main architecture. Again, I
recommend
the following:
1) The kernel should always manage the SSL connection, it should probably
present the SSL connection to the SSL user-space code and to the application
using the connection as two separate objects.
2) For received data, the kernel should analyze it and determine if it's
application or protocol.
3) Received application data should be decrypted in the kernel and returned
as normal data to the application using the SSL connection.
4) Received protocol data should be passed to the user-space SSL protocol
engine application.
5) Sent application data should be encrypted by the kernel and sent.
6) SSL protocol data should be accepted by the kernel from the user-space
SSL protocol engine and sent.
For connection establishment, for example, you have an application that
asks the kernel to setup an SSL connection. The kernel makes the underlying
TCP connection and informs the SSL user-space application about the new
connection. Then the user-space SSL application uses the kernel to manage
the establishment of the connection and then tells the kernel the connection
is ready. Then the kernel unblocks the socket in the application that
requested the connection.
For inbound connections, the kernel must know that some sockets always
get
SSL connections. When they get a new connection, they inform both the
user-space SSL application and the application that opened the socket in the
first place. The user-space SSL application manages the negotiation and
passes the symettric key to the kernel, which then lets the application that
opened the socket send and receive.
Again, you should totally ignore high-level functions like SSL_read and
SSL_peek, they don't do anything even remotely resembling what you want.
The way you seem to want to do it seems much, much harder to me.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
