RE: Does Openssl cache App data -- 2nd Try..

[David Schwartz]

>        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.

I was thinking SSL_peek does a buffer copy internally and gives that

to the application, and the actual bytes are still available in the

TCP receive queue..the idea is although I tried to peek, the data is still

available for a read by kernel, and so I neednt make use of the cache, inspite

of one being available.

     No, that is not what it does and that would not work.

>        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.

 

This is exactly what we want to do, but is not an FD required in the userspace

to POLL and read the SSL Control Packets? Once the KERNEL sees the 1st Control Pkt

on an FD, it will handover control back to the userspace module to continue processing

that FD, until an application data packet is received, wherein control will be

switched back to the KERNEL.

 

    Yes, an FD is required in userspace to poll and read the SSL control packets. Have the user-space SSL engine open a special listening socket to accept new control connections. When an SSL connection is made, create a special SSL control socket and let the user-space SSL protocol engine accept it and poll on it. 

> 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.

 

Yes, I wanted to call them from userspace openssl module only inorder to process

control packets, as SSL_read is the one which receives control packets as well

and internally triggers renegotiations and change cipher specs..so if I can peek

and check if its an application data packet, I can simply discard the buffer

given by peek and give back control to KERNEL, which will READ the TCP receive queue

and get back the same DATA, hoping SSL_peek is same as TCP_PEEK!! This is the

clarification I require. From KERNEL openssl will never be invoked, we have our

own kernel library which can only encrypt/decrypt. SSL_accept is done from userspace.

 

    Sorry, that won't work. SSL_peek provides the same semantics as a TCP peek but not the same way. SSL_peek does not consume the data but it implements this lack of consumption by caching the data.

 

    Perhaps someone else will chime in with the opinion that the way you're trying to do it makes sense, but it does not make sense to me. And I would suggest the split fd architecture instead of the shared fd architecture. The primary reason is that your scheme requires complex handovers of control where such are not needed and your scheme requires extra passes to peek at the data when such are not needed. Just have the kernel read the data, determine if it's data or control, and hand it to the appropriate process.

 

    Again, I suggest that the user-space SSL engine and the program that opened/accepted the SSL connection (say, a web server) each have a socket that is not the same as the socket the kernel uses internally for its end of the TCP connection to the other machine. I suggest the kernel process incoming SSL records as either application or protocol. If protocol, it should pass them to the connection to the user-space SSL protocol engine. If application, it should decrypt them and pass them to the application program.

 

    I'm suggesting basically that the kernel operate like a tee, not like someone playing hot potato.

 

    DS