php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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
View Developer Edit
 [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.
 [2014-07-12 15:19 UTC] rdlowrey@php.net
-Status: Assigned +Status: Closed
 [2014-07-12 15:19 UTC] rdlowrey@php.net 
This bug has been addressed in commit f3bf887e6d:

https://github.com/php/php-src/commit/f3bf887e6d84619fd03efc244756f68fa857b346
 [2018-08-20 17:22 UTC] cmb@php.net 
Related To: Bug #74796
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun Dec 22 06:01:30 2024 UTC