Bug 1042908

Summary:

PHP-SOAP calls to HTTPS resources cause network timeout.

Product:

Red Hat Enterprise Linux 6

Reporter:

Glen Solsberry <gms8994>

Component:

openssl

Assignee:

Tomas Mraz <tmraz>

Status:

CLOSED DUPLICATE

QA Contact:

BaseOS QE Security Team <qe-baseos-security>

Severity:

medium

Docs Contact:

Priority:

unspecified

Version:

6.4

CC:

davids, fedora, gms8994, pt, rcollet

Target Milestone:

Target Release:

---

Hardware:

x86_64

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2013-12-19 09:52:49 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
Minimal identify.wsdl	none
Minimal php test file.	none

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 ***