SSL will return SSL_ERROR_WANT_READ if it needs to read more. It will return SSL_ERROR_WANT_WRITE if it needs to write things out on that socket before it can do anything else (for example, during a renegotiation). (There is no fixed upper bound of times this can happen, so beware of going into an infinite loop until the OS decides that the remote has died and closes the socket.)
You can suppress this behavior (and ensure that you could loop like that) by calling SSL[_CTX]_set_mode(ctx, SSL_MODE_AUTO_RETRY). Generally, SSL_read will try to behave like read(), and SSL_write will try to behave like write() -- that is, you can request of the library that it return you a maximum number of bytes, and it'll buffer the rest. SSL should be the only thing that handles things like MAX_RECORD_SIZE. Instead of select(), you can use a loop through your available SSL objects with SSL_pending() to see if there is any application data in the queue that can be read. select() should be used only on the OS-level sockets, to figure out if the SSL layer needs to be called to handle that data. (This is a problem of a "leaky abstraction" -- you need to be aware of the difference between the "application layer" (i.e., your app, that uses the services of the library) and the "OS layer" (which is only manipulated by the library, though you have to read and respond to its state by calling the library)... and realize that if you also handle unencrypted connections, the "application layer" and the "OS layer" are the same on those connections.) -Kyle H On Mon, Mar 30, 2009 at 11:03 AM, Francis GASCHET <f...@numlog.fr> wrote: > Hello David, > > Thank you for this explanation. > I've a good book from Eric Rescorla, but may be I jumped too quickly to the > API and didn't learn enough the concepts! > > So If I correctly understand, I must try to read a MAX_RECORD_SIZE buffer > (16383 bytes) when select says "There is something ready to be read", and > I'll receive the error "SSL_WANT READ" until the complete record will be > processed by SSL. And only then, the SSL_read will return the record and its > real length. > It looks like if SSL says to the system "I've something ready" when it > begins to receive a new record. So if I read only the beginning of the > record because I use a too small buffer, I'll never be notified for the > remaining bytes. > > Am I right or did I missed something. > > Thanks anyway. > Best regards, > > -- > Francis GASCHET / NUMLOG > http://www.numlog.fr > Tel.: +33 (0) 130 791 616 > Fax.: +33 (0) 130 819 286 > > > > > Le 03/27/2009 06:29 AM David Schwartz a écrit : >>> >>> the application read the first >>> 1500 bytes, then "select(...)" no more indicates that something has to >>> be read on the fd. So the OFTP application behind the gateway doesn't >>> send the new "credit authorisation" because it didn't receive the >>> complete previous credit. And the sender waits until its inactivity >>> timer (more or less 2 minutes) triggers. >>> >> >> You cannot call 'select' to wait for data to be received if that data has >> already been received. You should not ever assume that OpenSSL is waiting >> for data to arrive on the socket unless it tells you this. >> >> You have broken the fundamental rule of OpenSSL. You *assumed* that >> encrypted data received over the wire would mean decrypted data received >> from OpenSSL. So because you wanted decrypted data from OpenSSL, you >> waited >> for encrypted data on the wire. >> >> Now this is *sometimes* true. But in this case, it was not true. So your >> assumption was false. >> >> Do not ever, ever, ever assume that you know what OpenSSL needs to make >> further progress. Because if you assume wrong, you are screwed. There is >> no >> reason you should ever need to make this assumption, since OpenSSL will >> tell >> you what it needs. >> >> DS >> >> >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-us...@openssl.org >> Automated List Manager majord...@openssl.org >> >> >> > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
