Bug #41631 [ReO->Csd]: 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: Re-Opened +Status: Closed 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 New Comment: 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 Previous Comments: ------------------------------------------------------------------------ [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! ------------------------------------------------------------------------ [2014-08-07 16:59:21] rdlowrey@php.net Related To: Bug #48524 ------------------------------------------------------------------------ [2014-08-07 16:56:05] rdlowrey@php.net 7 years is long enough :) The problem here was that the SSL_read() function in the relevant code section would block indefinitely waiting for data on a blocking socket connection. The solution was to poll the underlying socket for readable data (adhering to any defined timeouts) before moving on to SSL_read(). If no data arrives in the prescribed time window we now report an error and pull out of the operation. This issue should be fixed by commit 6569db8 in the 5.4 branch and merged up through to master: https://github.com/php/php-src/commit/6569db88081562f68a4f79e52cba83482bdf05fc The next series of releases will reflect this fix: - 5.4.33 - 5.5.17 - 5.6.0-rc4 ------------------------------------------------------------------------ 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