when specifying the following directives in a Virtual Host context: SSLProxyEngine on ProxyRemote http://other.proxy.server:8080 ProxyPass / https://target.server/ Then the first line of the connected stream to other.proxy.server should be like that "CONNECT target.server:443 HTTP/1.0" and followed by SSL encrypted binary stream, but my apache send SSL encrypted binary stream without the CONNECT first line, and the contents of the binary stream is "GET https://target.server/ HTTP/1.0" (like HTTP proxy protocol.)
Created attachment 11552 [details] This patch has been developped and tested in a reverse proxy configuration. Some tests have been made with Apache and IIS web servers.
This is a special case configuration - marking it as an enhancement for now.
*** Bug 32155 has been marked as a duplicate of this bug. ***
It might be simpler to resolve this by extending mod_proxy_connect.
(In reply to comment #0) > when specifying the following directives in a Virtual Host context: > SSLProxyEngine on > ProxyRemote http://other.proxy.server:8080 > ProxyPass / https://target.server/ One way is to use a plug such as the plugdaemon: http://www.taronga.com/plugdaemon/ My solution is: ProxyRemoteMatch www\.dest\.com https://$plugserver:$plugport/ I hope that some one from the mod_proxy developer would fix this bug or add these feature ;-)
*** Bug 41926 has been marked as a duplicate of this bug. ***
how can it be that this bug is not solved since so long? What happens is that apache connects to the proxy and initiates an SSL negotiation directly with the proxy. That's plain wrong. I would not classify this as simple "enhancement" as this behaviour seems to be supported (at least you can configure it) but the protocol used is just the wrong one. Apache should first send "CONNECT destination.comain.com:443 HTTP/1.0" and then start SSL stuff. This is so damn simple to do (I did a micro proxy in perl doing this) that I'm a bit dissapointed that the o-so-big and great apache is not working correctly.
Hi there, we have the same problem with several Apaches (2.2.x) in our environment, too. Has someone successfully patched Apache' 2.2.x mod_proxy? Unfortunately the 2.0 patch is not applicable to 2.2 :-( Greg who filed bug 41926 never received an answer. regards Chris
I believe I've hit this too: In production, I have a hardware load balancer, but in stage, I'm trying to simulate it using httpd and mod_proxy_balancer. I think I might be getting this error regardless of SSL in use or not. LB--->PXY and PXY SSL Layer--->App Layer LB is httpd+mod_proxy_balancer The proxy layer is identical, except there are some application level rewrite rules in place for SSL, maintenance, denials, etc... Listen *:80 <VirtualHost *> ... ProxyPass / balancer://pxy_cluster/ ProxyPassReverse / balancer://pxy_cluster/ ProxyPreserveHost on ### mod_proxy balancer <Proxy balancer://pxy_cluster> BalancerMember http://pxy001.tld BalancerMember http://pxy002.tld </Proxy> </VirtualHost> ---- Listen *:443 <VirtualHost *> ... ### SSL SSLEngine On SSLProxyEngine on ### mod_proxy balancer <Proxy balancer://pxy_cluster> BalancerMember https://pxy001.tld BalancerMember https://pxy002.tld </Proxy> </VirtualHost> -------- ==> error_log <== [Tue Jan 15 01:01:47 2008] [debug] mod_proxy_balancer.c(41): proxy: BALANCER: canonicalising URL //pxy_cluster/ [Tue Jan 15 01:01:47 2008] [debug] mod_proxy_balancer.c(950): proxy: Entering byrequests for BALANCER (balancer://pxy_cluster) [Tue Jan 15 01:01:47 2008] [debug] mod_proxy_balancer.c(517): proxy: BALANCER (balancer://pxy_cluster) worker (http://pxy001.tld) rewritten to http://pxy001.tld/ [Tue Jan 15 01:01:47 2008] [debug] mod_proxy.c(819): Running scheme balancer handler (attempt 0) [Tue Jan 15 01:01:47 2008] [debug] mod_proxy_http.c(1693): proxy: HTTP: serving URL http://pxy001.tld/ [Tue Jan 15 01:01:47 2008] [debug] proxy_util.c(1852): proxy: HTTP: has acquired connection for (pxy001.tld) [Tue Jan 15 01:01:47 2008] [debug] proxy_util.c(1913): proxy: connecting http://pxy001.tld/ to pxy001.tld:80 [Tue Jan 15 01:01:47 2008] [debug] proxy_util.c(2012): proxy: connected / to pxy001.tld:80 [Tue Jan 15 01:01:47 2008] [debug] proxy_util.c(2109): proxy: HTTP: backend socket is disconnected. [Tue Jan 15 01:01:47 2008] [debug] proxy_util.c(2169): proxy: HTTP: fam 2 socket created to connect to pxy001.tld [Tue Jan 15 01:01:47 2008] [debug] proxy_util.c(2266): proxy: HTTP: connection complete to 192.168.1.165:80 (pxy001.tld) [Tue Jan 15 01:01:48 2008] [debug] mod_proxy_http.c(1478): proxy: start body send [Tue Jan 15 01:01:48 2008] [debug] mod_proxy_http.c(1567): proxy: end body send [Tue Jan 15 01:01:48 2008] [debug] proxy_util.c(1870): proxy: HTTP: has released connection for (pxy001.tld) ------ Down stream PXY's access_log (LB-->PXY) ==> access_log <== 192.168.1.49 XXXXXXXXXXXXXXXXXXXX [15/Jan/2008:01:03:06 +0000] "GET / HTTP/1.1" 200 108 "-" "Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.6) Gecko/20070819 Firefox/2.0.0.6 error_log from same server had nothing written to it.
Created attachment 21410 [details] Patch for Apache 2.2.8 This patch as been developped for Apache 2.2.8. I have performed some basic test on it, but do not consider it as my final patch. If you are interesting in testing it, please give me your feedback. Philippe
CC myself on FreeBSD related bugs
I reviewed the patch and applied a slightly modified version in r909323. Major functional change: influence forwarding proxy auth by the env var "proxy-chain-auth" in the same way as in mod_proxy_http. Concerning comment #4 by Joe: it seems this doesn not fit nicely into mod_proxy_connect. The functionality is needed during the scheme_handler hook, which is a run first hook. mod_proxy_connect implements the CONNECT method, which means it is raw TCP as a backend protocol. Here we need HTTPS as a backend protocol, but prefix the first request with an HTTP CONNECT rquest. I plan to propose this for backport to 2.2.x. Thanks for the patch and the patience.
Created attachment 24975 [details] Backport of patch applied to 2.3.x in r909323. This patch is against 2.2.x head (r909372, Feb 12, 2010). It is a straighforward backport of the fix for 2.3. Feel free to apply and test.
Trunk patch has been improved by r910079, r910081, r910124. Backported to 2.2.x as r910322. Will be released with 2.2.15 and 2.3.7. I doubt there will be enough developer interest for backporting to 2.0, since 2.2 is very mature. So closing as fixed.