TLS encryption fails behind HTTP proxy

Bug #67609	TLS encryption fails behind HTTP proxy
Submitted:	2014-07-12 04:07 UTC	Modified:	2014-07-12 15:19 UTC
From:	rdlowrey@php.net	Assigned:	rdlowrey (profile)
Status:	Closed	Package:	OpenSSL related
PHP Version:	5.6.0RC2	OS:	centos
Private report:	No	CVE-ID:	None

[2014-07-12 04:07 UTC] rdlowrey@php.net

Description:
------------
Connection to encrypted resources from behind an HTTP proxy using 5.6.0RC2 always fails. The failure is unaffected by manually assigning the appropriate SSL stream context options. This bug only manifests when connecting via SSL/TLS through a proxy server and other use-cases are unaffected.

Test script:
---------------
<?php
// Must have exported proxy environment vars, e.g.:
// export http_proxy=http://127.0.0.1:8888
// export https_proxy=$http_proxy

// fails :(
$html = file_get_contents('https://google.com');
var_dump(strlen($html));

Expected result:
----------------
int(%d)

Actual result:
--------------
SSL operation failed with code 1. OpenSSL Error messages:
error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2014-07-12 04:18 UTC] rdlowrey@php.net

-Status: Open +Status: Assigned -Assigned To: +Assigned To: rdlowrey

[2014-07-12 04:18 UTC] rdlowrey@php.net

The problem here is two-fold:

(1) The existing ssl proxying code still uses the STREAM_CRYPTO_METHOD_SSLv23_CLIENT constant. In previous versions this constant meant "any available SSL/TLS protocol." However in 5.6 this constant now represents "only SSLv2 or SSLv3." Many servers disallow SSLv2/3 altogether as they are both known to be insecure. This results in failures for many servers. Fixing this issue requires a simple change to use the new (as of 5.6) STREAM_CRYPTO_METHOD_ANY_CLIENT crypto method constant.

(2) As of 5.6 ext/openssl automatically detects the host name from the HTTP request URI if no peer name is specified as part of the SSL stream context. For connections routed through a proxy, though, the proxy server's host name is detected and this results in handshake failures because the proxy name doesn't match the name on the remote server's certificate. The fix here is a matter of setting the appropriate server hostname if no peer_name is set in the SSL context to avoid auto-detection of the proxy server's name.

I've already fixed these issues locally. I'll commit the changes and update this report once I'm able to do due diligence and ensure I haven't missed any edge cases.