Darryl Miles
Sun, 18 Mar 2007 17:56:12 -0800
Robin Redeker wrote:
On Sat, Mar 17, 2007 at 09:36:45PM -0700, David Schwartz wrote: I would be even more trustfull if someone of the openssl developers would say a word about this. Something like: 'Yes yes, the man pages are a bit obsolete, you can pass different buffers to SSL_read for retries.'
And if there is a developer around able to do that I'm sure the community would much appreciate taking 60 seconds of your time to:
* improve the man pages covering the options being questioned (SSL_MODE_ENABLE_PARTIAL_WRITE and SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER)
* add a new comment covering the impact in respect to SSL_read()* clarify Bodo's implication that SSL_write() can return WANT_READ or WANT_WRITE and have copied at least 1 byte from the application supplied buffer into some internal OpenSSL buffer for later use. This interpretation is of his opening comment on the matter I still find confusing. http://www.mail-archive.com/openssl-users@openssl.org/msg45462.html
Personally I can't see how SSL_read() was much of an issue, if it returns data into the application suppled buffer it returns a value >0 or if no data was returned it returns <=0.
This is just like the Unix read() system call.The real gotcha with these flags has always been with SSL_write() as per my 3rd bullet point above. This would be like the write() system call pushing one or more bytes into the layer below and having no way to revoke that/those byte(s) as part of the error return path and then returning -1. This situation within OpenSSL seems an be an entirely avoidable one to me.
It would be far better to make the application detect the short write and then call a function to enquire what the current WANT_READ and WANT_WRITE situation is after that. Or if you don't mind calling SSL_write() again because you're just a lazy programmer then calling SSL_write() again will return WANT_WRITE.
From what I can make out in my understanding of how OpenSSL works, it always has internal buffer space for one full record. If a record is still outstanding the next SSL_write() will try to push that record into the layer below again before starting to assemble the next packet. So there is no possibility of a loop causing the reassembly of a packet and reencryption of a packet to keep occurring over and over. Which could be a performance killer.
Darryl ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]