RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1042908 - PHP-SOAP calls to HTTPS resources cause network timeout.
Summary: PHP-SOAP calls to HTTPS resources cause network timeout.
Keywords:
Status: CLOSED DUPLICATE of bug 1044446
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openssl
Version: 6.4
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Tomas Mraz
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-13 15:43 UTC by Glen Solsberry
Modified: 2014-01-06 14:38 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-19 09:52:49 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Minimal identify.wsdl (2.84 KB, application/xml)
2013-12-13 15:44 UTC, Glen Solsberry 		no flags Details
Minimal php test file. (860 bytes, text/php)
2013-12-13 16:12 UTC, Glen Solsberry 		no flags Details
View All

Description Glen Solsberry 2013-12-13 15:43:30 UTC 
Description of problem:

PHP-SOAP calls to HTTPS resources cause network timeout.

Version-Release number of selected component (if applicable):

php-5.3.3-26.el6 has the issue, php-5.3.3-23.el6_4 does not.

How reproducible:

Every time.

Steps to Reproduce:
1. Run php soap_test.php with 5.3.3-26.el6 or greater installed.

Actual results:

Line with "ping elapsed" reports more than 10 seconds.
"$pingresult is not set"
SOAPFAULT FAULTSTRING: Could not connect to host

Expected results:

Line with "ping elapsed" reports less than 10 seconds.
Output contains the string "Ping OK"

Additional info:

The following curl_* based php script works on any version.

<?php

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'https://identify.insightgateways.com/identify/v1_0/Identify');

curl_setopt($ch, CURLOPT_HTTPHEADER, array('User-Agent: PHP-SOAP/5.4.22', 'Content-Type: text/xml; charset=utf-8', 'SOAPAction: ""'));

curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 5);
curl_setopt($ch, CURLOPT_TIMEOUT, 5);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

$soap = new SimpleXMLElement('<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://webservice.identify.acxiom.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><SOAP-ENV:Body><ns1:ping></ns1:ping></SOAP-ENV:Body></SOAP-ENV:Envelope>');

curl_setopt($ch, CURLOPT_POSTFIELDS, $soap->asXML());

$result = curl_exec($ch);
curl_close($ch);

print $result;
Comment 1 Glen Solsberry 2013-12-13 15:44:14 UTC 
Created attachment 836357 [details]
Minimal identify.wsdl
Comment 2 Remi Collet 2013-12-13 16:09:40 UTC 
Can you please add the "soap_test.php" ?
Comment 3 Glen Solsberry 2013-12-13 16:12:07 UTC 
Created attachment 836373 [details]
Minimal php test file.

Apologies. I marked this for attachment when I created the bug. I guess it didn't make it.
Comment 4 Remi Collet 2013-12-13 17:54:27 UTC 
From a quick test, same connection issue with latest PHP 5.5.7
(tested under Fedora 19)

Adding to connect option:
	'ssl_method' => SOAP_SSL_METHOD_SSLv3,
seems to work.

Can you please confirm with php-5.3.3-27 ?
Comment 5 Glen Solsberry 2013-12-13 18:24:48 UTC 
The 'ssl_method' parameter was added in 5.5; it will not work in 5.3.
Comment 6 Remi Collet 2013-12-16 08:07:45 UTC 
* more PHP tests:
php-5.3.3-23.el6_4.x86_64 + openssl-1.0.1e-15.el6.x86_64
    none    very long timeout

php-5.3.3-23.el6_4.x86_64 + openssl-1.0.0-27.el6_4.2.x86_64
    none    OK

php-5.3.3-26.el6.x86_64 + openssl-1.0.1e-15.el6.x86_64
    none    very long timeout

php-5.3.3-26.el6.x86_64 + openssl-1.0.0-27.el6_4.2.x86_64
    none    OK

So, I think there is no regression in PHP.

* From www.ssllabs.com analysis:
Handshake Simulation
    OpenSSL 0.9.8y 	TLS 1.0 	TLS_RSA_WITH_RC4_128_MD5 (0x4)   No FS 	128
    OpenSSL 1.0.1e 	Protocol or cipher suite mismatch 	Fail3

* Test using openssl command;

$ rpm -q openssl
openssl-1.0.1e-16.el6_5.1.x86_64
$ openssl s_client -connect identify.insightgateways.com:443 -debug
CONNECTED(00000003)
write to 0x1006ed0 [0x1027e60] (263 bytes => 263 (0x107))
0000 - 16 03 01 01 02 01 00 00-fe 03 03 52 ae b0 21 79   ...........R..!y
0010 - 26 99 ad 9c 90 1e cb fd-7c 7b d7 de d9 bb be 64   &.......|{.....d
0020 - cf 38 30 dd 4b 8c 8c 0d-cc 1e 14 00 00 94 c0 30   .80.K..........0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 a3 00 9f 00 6b   .,.(.$.........k
0040 - 00 6a 00 39 00 38 00 88-00 87 c0 32 c0 2e c0 2a   .j.9.8.....2...*
0050 - c0 26 c0 0f c0 05 00 9d-00 3d 00 35 00 84 c0 12   .&.......=.5....
0060 - c0 08 00 16 00 13 c0 0d-c0 03 00 0a c0 2f c0 2b   ............./.+
0070 - c0 27 c0 23 c0 13 c0 09-00 a2 00 9e 00 67 00 40   .'.#.........g.@
0080 - 00 33 00 32 00 9a 00 99-00 45 00 44 c0 31 c0 2d   .3.2.....E.D.1.-
0090 - c0 29 c0 25 c0 0e c0 04-00 9c 00 3c 00 2f 00 96   .).%.......<./..
00a0 - 00 41 00 07 c0 11 c0 07-c0 0c c0 02 00 05 00 04   .A..............
00b0 - 00 15 00 12 00 09 00 14-00 11 00 08 00 06 00 03   ................
00c0 - 00 ff 01 00 00 41 00 0b-00 04 03 00 01 02 00 0a   .....A..........
00d0 - 00 06 00 04 00 18 00 17-00 23 00 00 00 0d 00 22   .........#....."
00e0 - 00 20 06 01 06 02 06 03-05 01 05 02 05 03 04 01   . ..............
00f0 - 04 02 04 03 03 01 03 02-03 03 02 01 02 02 02 03   ................
0100 - 01 01 00 0f 00 01 01                              .......

===> very long time

read from 0x1006ed0 [0x102d3c0] (7 bytes => -1 (0xFFFFFFFFFFFFFFFF))
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 263 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
Comment 7 Remi Collet 2013-12-16 08:18:58 UTC 
It seems there is a problem on the server side, when it receives client hello from openssl-1.0.1e, the server should reply with something.

Can you please check the server configuration ?
Comment 8 Glen Solsberry 2013-12-16 13:36:28 UTC 
Unfortunately, I do not manage the server installation in this case, only the client. However, in speaking with the owners of the server, they say that nothing has changed since well before November 27 (when we started seeing the issue).
Comment 9 Glen Solsberry 2013-12-16 16:07:50 UTC 
We are confirming with the remote server manager that nothing has changed. I'll update when I find out more.
Comment 10 Tomas Mraz 2013-12-17 09:39:54 UTC 
I don't say that the server has changed, it just should tolerate the valid client hellos from openssl-1.0.1e or at least send TLS alert message with an error if there is an error in the client hello.
Comment 11 Glen Solsberry 2013-12-18 16:39:35 UTC 
It seems to be related to an F5 device in front of their system. The URL included documents the problem.

https://www.imperialviolet.org/2013/10/07/f5update.html
Comment 12 Tomas Mraz 2013-12-19 09:52:49 UTC 

*** This bug has been marked as a duplicate of bug 1044446 ***
Note You need to log in before you can comment on or make changes to this bug.