Edit report at https://bugs.php.net/bug.php?id=41631&edit=1
ID: 41631
Comment by: askalski at synacor dot com
Reported by: david at acz dot org
Summary: default_socket_timeout does not work with SSL
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
New Comment:
Does the attached patch (ssl_read_timeout-5.4.32.patch) help with the SoapClient issue?
Previous Comments:
------------------------------------------------------------------------
[2014-10-17 06:40:29] fredrik dot eriksson at loopia dot se
I have a problem with SOAP over SSL after the fix in 5.4.33 on FreeBSD. 5.4.32 works fine, but this
test case does not work in 5.4.33:
$client = new SoapClient('test.wsdl', array('cache_wsdl' => WSDL_CACHE_NONE,
'trace' => true, 'exceptions' => false, 'connection_timeout'
=> 15));
$data = $client->get_long_soap_response_over_https($param);
echo "__getLastRequest:\n";
echo $client->__getLastRequest();
echo "\n\n__getLastRequestHeaders:\n";
echo $client->__getLastRequestHeaders();
echo "\n\n__getLastResponse:\n";
echo $client->__getLastResponse();
After the timeout the output for last request and last request headers looks fine, but the response
is truncated after a certain size. I didn't save the failed output, but the expected response
size was 76800 bytes (+ header), but was truncated I think around 72000 bytes. The same test done
over http or with 5.4.32 works fine, so I can only assume that the "fix" for this bug is
causing this.
------------------------------------------------------------------------
[2014-10-04 02:24:27] askalski at synacor dot com
To give an update, I've started writing tests and have pushed two so far up to my github: https://github.com/Voltara/php-src/tree/bug41631
I haven't applied the code changes yet, so one of the tests currently fails. The other passes
because it tests for two bugs which are already fixed on master.
------------------------------------------------------------------------
[2014-10-02 21:39:00] askalski at synacor dot com
OK, we'll make sure the NO_SSL3 patch doesn't get clobbered.
I didn't get as far in my #65137 testing today as I would have liked. I just realized that I
was tripping over a bug in "openssl s_server", which basically invalidates all of the
troubleshooting I did today.
------------------------------------------------------------------------
[2014-10-02 19:37:41] software-php at interfasys dot ch
I'm happy to report that @askalski's updated patch is working well for us so far, using
Horde. Connections on both IMAP and Sieve work well.
Regarding bug #67850. I provided the patch because PHP would not compile if OpenSSL was not built
with SSLv3 support. That's on FreeBSd, compiling OpenSSL from source.
I'm not sure why it works for you in your setup. Maybe PHP picked another OpenSSL in your OS?
------------------------------------------------------------------------
[2014-10-02 17:05:14] askalski at synacor dot com
We should also solicit feedback about whether this addresses the mysqlnd hang on connect (bug
#68046). I tested it myself and it seems to work, but I would like to hear confirmation from the
reporter of that issue.
Also, there are two changes in 5.5.17 that my patch does not include:
1) Bug #67850, which adds two "#ifdef OPENSSL_NO_SSL3" checks to the code.
I'm very curious to know which use case this addresses. I had no trouble building PHP (without
this patch) against OpenSSL 1.0.1i built with the "no-ssl3" option. I don't mind
including this patch regardless, but I would like to satisfy my own curiosity about it (and add some
comments to the code for posterity.)
2) Bug #65137, which is intended to help code that uses select/poll on SSL streams.
Although I have not yet come up with a test case to prove it, I suspect that change is not 100%
correct. The big problem with using select() directly on an SSL socket is: even if your application
is "writing", a renegotiation behind the scenes may mean OpenSSL needs to block on a
"read" (and vice versa.)
So while it certainly helps to drain OpenSSL's internal buffers, the code could still get into
a state where it's polling in the wrong direction. This could cause unwanted blocking, or
busy-waiting in the case of a nonblocking socket.
I still need to do more testing with this latter change. We'll also want feedback from the
contributer of that fix (daverandom).
------------------------------------------------------------------------
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