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

From: Date: Fri, 19 Sep 2014 11:05:59 +0000
Subject: Bug #41631 [Com]: default_socket_timeout does not work with SSL
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-187599@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
 Comment by:         arhimede at gmail dot com
 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:

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


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

------------------------------------------------------------------------
[2014-08-07 16:59:21] rdlowrey@php.net

Related To: Bug #48524

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


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 (#187599) next »