Bug 19188 - ProxyPass'ing to HTTPS server via proxy does not work
ProxyPass'ing to HTTPS server via proxy does not work
Status: RESOLVED FIXED
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy
2.0.55
Sun Solaris
: P2 enhancement with 19 votes (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
: PatchAvailable
: 32155 41926 (view as bug list)
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2003-04-21 07:56 UTC by Haruyuki Kawabe
Modified: 2010-02-16 10:17 UTC (History)
7 users (show)



Attachments
This patch has been developped and tested in a reverse proxy configuration. Some tests have been made with Apache and IIS web servers. (8.01 KB, patch)
2004-05-14 16:01 UTC, Philippe Dutrueux
Details | Diff
Patch for Apache 2.2.8 (4.57 KB, patch)
2008-01-22 02:55 UTC, Philippe Dutrueux
Details | Diff
Backport of patch applied to 2.3.x in r909323. (11.19 KB, patch)
2010-02-12 13:29 UTC, Rainer Jung
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Haruyuki Kawabe 2003-04-21 07:56:48 UTC
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.)
Comment 1 Philippe Dutrueux 2004-05-14 16:01:39 UTC
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.
Comment 2 Graham Leggett 2004-05-21 21:35:47 UTC
This is a special case configuration - marking it as an enhancement for now.
Comment 3 Joe Orton 2004-11-11 20:13:15 UTC
*** Bug 32155 has been marked as a duplicate of this bug. ***
Comment 4 Joe Orton 2004-11-11 20:16:08 UTC
It might be simpler to resolve this by extending mod_proxy_connect.
Comment 5 Alexander Lazic 2005-12-04 11:11:15 UTC
(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 ;-)
Comment 6 jfclere 2007-06-28 00:19:22 UTC
*** Bug 41926 has been marked as a duplicate of this bug. ***
Comment 7 Georges Kesseler 2007-10-12 06:47:53 UTC
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.
Comment 8 Chris Martin 2007-12-19 07:48:20 UTC
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
Comment 9 Philp M. Gollucci 2008-01-14 17:05:28 UTC
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.
Comment 10 Philippe Dutrueux 2008-01-22 02:55:31 UTC
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
Comment 11 Philp M. Gollucci 2009-01-18 16:19:22 UTC
CC myself on FreeBSD related bugs
Comment 12 Rainer Jung 2010-02-12 10:05:17 UTC
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.
Comment 13 Rainer Jung 2010-02-12 13:29:58 UTC
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.
Comment 14 Rainer Jung 2010-02-16 10:06:18 UTC
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.