Bug #41631 [Csd->ReO]: default_socket_timeout does not work with SSL

Edit report at https://bugs.php.net/bug.php?id=41631&edit=1 ID: 41631 Updated by: rdlowrey@php.net Reported by: david at acz dot org Summary: default_socket_timeout does not work with SSL -Status: Closed +Status: Re-Opened Type: Bug Package: OpenSSL related Operating System: * PHP Version: 5.2, 5.3, 5.4, 5.5, 5.6 Assigned To: rdlowrey Block user comment: N Private report: N Previous Comments: ------------------------------------------------------------------------ [2014-09-19 11:05:57] arhimede at gmail dot com The fix make the bundled Horde on Plesk 11.5, Centos 6.5 useless Horde/Imap/Client/Socket/Connection/Socket.php line 116 feof($this->_stream) used to return TRUE, now is returning false ------------------------------------------------------------------------ [2014-09-09 16:41:35] rdlowrey@php.net This issue should now be resolved via 3728449 which will make its way into the next round of bugfix releases: https://github.com/php/php-src/commit/372844918a318ad712e16f9ec636682424a65403 ------------------------------------------------------------------------ [2014-08-27 15:03:52] rdlowrey@php.net It seems there is a minor issue with the original fix as outlined in this thread: https://github.com/php/php-src/commit/6569db88081562f68a4f79e52cba83482bdf05fc I'll update this issue once resolved. ------------------------------------------------------------------------ [2014-08-07 18:49:34] rdlowrey@php.net @arkadi Yes, it's unfortunate but the openssl docs are often unclear on details. As far as I can tell from the relevant openssl source code in the current master branch this should be a non-issue. In the case you mention it appears that SSL_read will simply return the WANT_READ state, not block indefinitely. The initial problem was due to PHP blindly assuming there was data to be read on the socket before launching into a blocking read operation that wouldn't return until *something* was available to consume. It should be noted that this scenario is a non-issue in non-blocking applications where an fread() on the encrypted stream would only be attempted when data is known to be available. The https:// stream wrapper, though, is fully blocking. References: https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L1006 https://github.com/openssl/openssl/blob/master/ssl/bio_ssl.c#L140 ------------------------------------------------------------------------ [2014-08-07 18:28:49] arkadi dot shishlov at gmail dot com Does the fix work for a situation when some data is available on socket, but SSL_read() wants to read more to process whole record (block encryption)? That may happen on IP packet boundary, depending on the sender. SSL_read() manual is not particularly clear on blocking behavior, but they have the following: ...If no more bytes are in the buffer, SSL_read() will trigger the processing of the next record. Only when the record has been received and processed completely, SSL_read() will return reporting success. https://www.openssl.org/docs/ssl/SSL_read.html Thank you for the fix in any case! ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=41631 -- Edit this bug report at https://bugs.php.net/bug.php?id=41631&edit=1