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

From: Date: Thu, 07 Aug 2014 18:49:34 +0000
Subject: Bug #41631 [Csd]: default_socket_timeout does not work with SSL
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-187015@lists.php.net to get a copy of this message 
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
 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:

@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


Previous Comments:
------------------------------------------------------------------------
[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

------------------------------------------------------------------------
[2014-03-19 18:02:06] alex at modula-shop-systems dot de

Currently *still* experiencing this on this build of php: 

PHP 5.4.26-1~dotdeb.0

What is quite ridiculous for a bug that has been reported nearly 7 years ago ! 

Is it really that difficult to fix this bug? 

It affects also the SoapClient and makes it quite useless / forces ugly fallbacks to CURL when there
is a need to catch timeouts over https.

This is really not an uncommon requirement for php in enterprise applications and should simply
work.

------------------------------------------------------------------------
[2013-12-13 09:39:45] lobbin at gmail dot com

Honestly, this bug has been open with a potential patch since _2007_. It also contains a perfectly
well test case to reproduce the error.

------------------------------------------------------------------------


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

Thread (67 messages)

« previous php.bugs (#187015) next »