Bug 29744 - CONNECT does not work over existing SSL connection
CONNECT does not work over existing SSL connection
Status: RESOLVED FIXED
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy
2.2.9
All All
: P2 enhancement with 113 votes (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
: FixedInTrunk
: 11232 50508 (view as bug list)
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2004-06-22 19:45 UTC by Rusty Ryan
Modified: 2014-03-26 20:45 UTC (History)
39 users (show)



Attachments
Use normal I/O routines in proxy_connect.c (5.21 KB, patch)
2004-11-10 23:33 UTC, Brad Boyer
Details | Diff
proxy_connect.c patch modified to work with 2.1 (7.80 KB, patch)
2005-01-22 00:01 UTC, Brad Boyer
Details | Diff
proxy_connect patch updated for 2.1.6 (8.53 KB, patch)
2005-08-18 22:27 UTC, Brad Boyer
Details | Diff
Fixed patch with read loops and updated to 2.2.0 (18.37 KB, patch)
2006-05-03 22:27 UTC, Brad Boyer
Details | Diff
Fix broken patch 18222 for 2.2.0; includes cleanups (see text) (12.01 KB, patch)
2007-02-03 09:25 UTC, Mark Cave-Ayland
Details | Diff
Patch for proxytunnel 1.7.0 to have two proxies with second one SSL encrypted (8.89 KB, patch)
2007-03-16 07:43 UTC, Julian Gilbey
Details | Diff
Fixed patch updated to 2.2.4 (11.75 KB, patch)
2007-06-08 13:30 UTC, Fabrice Durand
Details | Diff
Port of the patch from 2.2.2 to 2.2.4 (15.02 KB, patch)
2007-06-21 06:00 UTC, David GENCE
Details | Diff
Port of the patch from 2.2.4 to 2.2.6 (3.15 KB, patch)
2007-10-03 09:39 UTC, Dag Wieers
Details | Diff
Working port of the patch from 2.2.4 to 2.2.6 (12.08 KB, patch)
2007-10-08 11:00 UTC, Tim Dodge
Details | Diff
Working patches for 2.2.4 and 2.2.6 with i686 dropin binaries. (39.87 KB, application/x-compressed-tar)
2008-03-05 09:56 UTC, Per Gunnar Hans
Details
Dropin binary for win32 (2.2x?) based on Per Gunnar Hans' patch (attachment 21628) (11.68 KB, patch)
2008-03-23 06:24 UTC, Emmanuel Elango
Details | Diff
proxy_connect patch updated for 2.2.9 (12.05 KB, patch)
2008-07-11 14:53 UTC, Kevin Croft
Details | Diff
Drop in binaries for 2.2.10 and possibly below (14.00 KB, application/octet-stream)
2008-11-15 02:50 UTC, Emmanuel Elango
Details
Updated patch for Apache 2.2.11 mod_proxy_connect.c to implement CONNECT over SSL (12.61 KB, patch)
2009-06-21 15:08 UTC, Rudolf Cardinal
Details | Diff
Close backend connection when client disconnects (1.68 KB, patch)
2009-09-12 15:28 UTC, Stefan Fritsch
Details | Diff
Patch for version 2.2.14 (12.25 KB, patch)
2009-11-25 10:31 UTC, Ivan Krivyakov
Details | Diff
Win32 binary for patched version 2.2.14 (14.00 KB, application/octet-stream)
2009-11-25 10:38 UTC, Ivan Krivyakov
Details
Port of pach from 2.2.14 to 2.2.16/2.2.17 (12.05 KB, patch)
2010-10-29 05:13 UTC, Sergey Anufrienko
Details | Diff
Port of the patch to Apache 2.2.22 (Win32) (13.00 KB, application/octet-stream)
2012-07-18 01:35 UTC, Ivan Krivyakov
Details
Patch for Apache 2.2.22 (tested on Linux machine against the Debian version of apache; should work on vanilla apache too) (11.86 KB, patch)
2013-04-03 19:24 UTC, Julian Gilbey
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Rusty Ryan 2004-06-22 19:45:28 UTC
connect method don't work if the client is connecting to the apache proxy 
through ssl socket.
Comment 1 Rik Snel 2004-07-09 19:44:57 UTC
I have this problem also, let me explain a little bit further. I have configured
apache/mod_proxy to allow CONNECT requests to port 25 (and I have an http server
on port 80 and an https server on port 443).

On port 80 there is no problem:
---- transcript ----
> telnet <server> 80
Trying 192.168.2.2...
Connected to server.
Escape character is '^]'.
CONNECT localhost:25 HTTP/1.0

HTTP/1.0 200 Connection Established
Proxy-agent: Apache/2.0.49 (Gentoo/Linux) mod_ssl/2.0.49 OpenSSL/0.9.7d DAV/2
SVN/1.0.4

220 <server> ESMTP Postfix
----

When I do the same (using openssl s_client as ssl-aware telnet) on port 443,
something interesting happens:
----
>openssl s_client -connect server:443 -debug
[SNIP]
CONNECT localhost:25 HTTP/1.0
write to 080ADC10 [080B8098] (106 bytes => 106 (0x6A))
0000 - 17 03 00 00 20 be 08 8a-42 af f3 ee 82 a3 ca f2   .... ...B.......
0010 - 49 9a 74 f1 d4 28 f1 9e-3f 47 21 32 8a 7b 3b 85   I.t..(..?G!2.{;.
0020 - e5 03 11 8e 34 17 03 00-00 40 93 02 51 1d d9 86   ....4....@..Q...
0030 - 19 a2 bd ee 51 d2 75 39-ce 2c 8e 3f 7c 0f b1 26   ....Q.u9.,.?|..&
0040 - b0 43 5b 4b 25 5e 93 3d-f4 bb 0a 23 29 d5 25 49   .C[K%^.=...#).%I
0050 - 2f 61 46 c7 84 f9 ac cd-a4 77 e6 9e 74 09 60 2f   /aF......w..t.`/
0060 - f2 13 af ef f0 46 7c 61-60 e3                     .....F|a`.

write to 080ADC10 [080B8098] (74 bytes => 74 (0x4A))
0000 - 17 03 00 00 20 0c 0d 67-8e 91 3e f8 ed b0 19 97   .... ..g..>.....
0010 - 57 9d 84 b0 ff d4 ed 92-cb 4f a0 48 19 9a cb 2b   W........O.H...+
0020 - 0d 0e 74 f3 82 17 03 00-00 20 7c a3 fb 93 7c ef   ..t...... |...|.
0030 - 90 e2 ce bd 40 21 34 b9-17 40 58 7e 0a f8 b0 1d   ....@!4..@X~....
0040 - ed 65 1e cd a8 9b 49 52-cf c4                     .e....IR..
read from 080ADC10 [080B3888] (5 bytes => 5 (0x5))
0000 - 48 54 54 50 2f                                    HTTP/
write to 080ADC10 [080B8098] (37 bytes => 37 (0x25))
0000 - 15 54 54 00 20 3b 18 d2-4b 20 6f 47 59 c5 84 99   .TT. ;..K oGY...
0010 - 6d d6 14 ac c7 e2 c9 03-b2 89 22 dd 4c 29 52 b7   m.........".L)R.
0020 - 14 94 34 ec 53                                    ..4.S
2069:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:2
86:
write to 080ADC10 [080B8098] (37 bytes => 37 (0x25))
0000 - 15 54 54 00 20 60 90 0f-be 91 f6 5e c7 ea 5a 14   .TT. `.....^..Z.
0010 - 93 23 97 de ac ac 00 6c-8a c6 d0 74 88 3f 96 cf   .#.....l...t.?..
0020 - 46 5b 80 c9 d9                                    F[...

So the CONNECT request is sent to the server. It is received (according to
ssl_request_log) and accepted (according to ssl_access_log). The ssl client
bails out with an error because apache sends nonsense.

Speculation: the nonsense is "HTTP/" (as seen in the debug output above). It
seems that apache/mod_proxy is bypassing the ssl encryption and is answering
unencrypted. Since https is supposed to be 'http over ssl', the ssl encryption
should not be bypassed and be maintained until the connection is closed.

I hope this description is helpful.
Comment 2 Joe Orton 2004-07-12 14:02:02 UTC
Well, I wouldn't expect that to work.  The CONNECT request is supposed to
establish an end-to-end tunnel, not a tunnel through an SSL connection.  Did
this work using mod_ssl for Apache 1.3?

The error handling is clearly bad though.
Comment 3 Rik Snel 2004-07-13 17:25:01 UTC
I can't test if it works with mod_ssl of apache 1.3, but I think mod_ssl
is not the guilty party; it is entirely bypassed by mod_proxy as soon as
mod_proxy starts answering (HTTP/1.0 200 Connection Established...).

I read through modules/proxy/proxy_connect.c and the author states
that he is using the wrong functions to write to the client (i.e. apr_send
directly on the client socket, instead of using ap_rwrite), IMO that is easily
to fix fixed.

The bigger problem is that proxy_connect also reads from the client through the
client socket (and not the chain of filters, which includes the ssl encryption),
I also don't know if it is even possible to read from the client in a clean way
if the HTTP request is complete ( CONNECT bla:22 HTTP/1.0\r\n\r\n ).

The standards are not explicit about allowing/disallowing CONNECT over https,
they only state https = http + TLS (or SSL) from which I conclude that the
tunnel should traverse the currently established connection (so tunnel over ssl
in the case of https).

Short explanation why I even bother with this: suppose you have a firewall
somewhere which only allows traffic through port 443 and you want to ssh home.
You could, of course, run ssh on port 443, but then you can not run
apache+mod_ssl there. It would be an elegant solution to tunnel a connection to
port 22 though the https server.
Comment 4 Brad Boyer 2004-11-10 23:33:57 UTC
Created attachment 13393 [details]
Use normal I/O routines in proxy_connect.c
Comment 5 Brad Boyer 2004-11-10 23:37:27 UTC
The patch I just attached converts proxy_connect.c to use the bb/filter routines
to do I/O instead of directly using apr_send/apr_recv on the sockets. I've
tested it both with a normal web browser using it for SSL proxying (uses normal
HTTP), and with a custom written client that uses HTTPS to talk to the proxy. It
works for me. It's against 2.0.52, but it doesn't look like that stuff has
changed any time recently.
Comment 6 Rik Snel 2004-11-11 17:54:36 UTC
I tested your patch on the 2.0.52 release and it seems to work fine. Thanks
Brad. Hopefully the maintainer of mod_proxy_connect will review and accept the
patch. 
Comment 7 Brad Boyer 2005-01-22 00:01:59 UTC
Created attachment 14066 [details]
proxy_connect.c patch modified to work with 2.1

Here's a new version of the patch that applies cleanly to 2.1.2-alpha. It's a
little longer due to the new error checking to match the changes that already
got done in CVS. The changes are the same at a fundamental level.
Comment 8 Paul Querna 2005-06-20 01:25:16 UTC
*** Bug 11232 has been marked as a duplicate of this bug. ***
Comment 9 Brad Boyer 2005-08-18 22:27:28 UTC
Created attachment 16105 [details]
proxy_connect patch updated for 2.1.6

This version of the patch is updated for the file rename that happened after
2.1.2. It also has some minor fixes to the error handling.
Comment 10 satinder singh 2006-03-02 10:08:23 UTC
(In reply to comment #9)
> Created an attachment (id=16105) [edit]
> proxy_connect patch updated for 2.1.6
> This version of the patch is updated for the file rename that happened after
> 2.1.2. It also has some minor fixes to the error handling.

patch is not working when ssl client talks chunked encoding with CONNECTed 
server. I am using patch over 2.0.53
Comment 11 Emmanuel Elango 2006-03-02 10:27:44 UTC
Hi,
I think the issue has been resolved since apache 2.0.54. I can confirm that this
bug dosent exist on WinXP. If someone can confirm on other platforms we could
close this bug.
Thanks,
Emmanuel
Comment 12 Brad Boyer 2006-03-02 18:28:22 UTC
(In reply to comment #10)
How are you trying to use chunked encoding? The RFC seems to say it's a straight
channel with no encoding of any sort. The httpd server is just forwarding bytes
as soon as the connection is established.
Comment 13 Brad Boyer 2006-03-02 18:58:22 UTC
(In reply to comment #11)
The bug is definitely still present in 2.0.55. I am testing on Linux, and I
suspect most of the others involved have been testing on something that uses the
unix build of httpd in one way or another.

However, I would be surprised if this is a platform specific bug, based on what
the real problem is (bug is in proxy_connect, not in mod_ssl). Are you sure you
understand the original test case? For my testing, I am using "openssl s_client
-connect 127.0.0.1:443" on the same machine running the server, and sending a
CONNECT request to the server through this SSL channel. The client errors out
with "15949:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:286:" when the proxy_connect module starts to send data because
proxy_connect is writing to the socket directly instead of going through the
filter stack. Because it skips the filter stack, the SSL module doesn't get
called and the data is sent in the clear.
Comment 14 Emmanuel Elango 2006-03-04 04:50:37 UTC
Hi Everyone,

Firstly chunked encoding could possibly fail because of this if mod_proxy_http
also has some direct writes to the socket instead of through the ap_rwrite. I
havent combed through the source but I am fairly sure that chunked transfer
seems to work fine in my experience.

Secondly I do understand what you are saying in the test case. I am actually
running a proxy on an SSL enabled apache server. Since browsers so far cant be
easily tweaked to communicate over SSL to a proxy I've written a small Perl
script which acts as another proxy between the browser and the SSL enabled
proxy. The browser talks normal HTTP to the Perl script. The Perl script talks
SSL to the SSL enabled proxy. I ran into problems when the browser tried to
CONNECT to a secure site over this setup. The Perl script would negotiate SSL
allright but then as soon as the CONNECT request went through mod_proxy_connect
would hijack the connection and send back normal HTTP. There seems to be no
problem with mod_proxy, mod_proxy_http and mod_proxy_ftp.

Thats how I came across this bug. I had a hard time compiling apache on Windows
but after very clear instructions from www.devside.net I finally managed to
compile the patch. The patch worked great with 2.0.52. Recently I decided to set
up another machine as a similar proxy. This time also as usual I picked up the
precompiled binary at http://www.apache.org/dist/perl/win32-bin/. The version
had been upgraded to 2.0.54. On a whim I decided to check it out without
installing the patch. Surprisingly it worked fine. Thats how I came to the
conclusion that mod_proxy_connect seems to have been fixed. I really dont have
another spare machine to test this again to reconfirm. But let me see what I can do.

Emmanuel
Comment 15 Dag Wieers 2006-03-20 14:56:14 UTC
We have discovered the same problem while trying to connect proxytunnel over a
local proxy to a remote apache/ssl proxy on port 443. You can find a description
of the setup (and why this is useful) at:

    http://dag.wieers.com/howto/ssh-http-tunneling/

It works fine without SSL, but using SSL it fails to handle the CONNECT.
Comment 16 Joe Orton 2006-03-20 15:51:56 UTC
Really, nobody should ever be doing this.  I'd leave this bug open because the
patches are a reasonable cleanup and/or the error handling is bad, not because
the bug has a reasonable motivation.

CONNECT is defined to allow tunneling an SSL connection through a proxy.  You do
not connect to a proxy via SSL, *then* send a CONNECT request.  It's
non-sensical and it's behaviour not specified by any RFC.
Comment 17 Alexander K 2006-03-20 18:20:19 UTC
I think we all can agree on that we should refrain from telling people on what
they should and what they should not do. Even if some things are not advisable
someone might have no alternative.
SSL is supposed to be a layer upon which an application may run its own
protocol. In that regard I think Apache should not behave differently whether
I'm talking to it through SSL or not.
Comment 18 Alexander K 2006-03-20 20:58:28 UTC
Ok, back to the subject, 
the good news first, s_client can connect through the proxy, no patch needed,
but ONLY with ssl2!
Then I tried sslwrap:
(sslwrap  -nocert -state -bugs -debug -ssl2 -port 443 -addr 10.1.1.1 -accept 2001)
which yielded:

SSL_accept:before/accept initialization
SSL_accept:error in SSLv2 read client hello B
ERROR
2411:error:140EC0AF:SSL routines:SSL2_READ_INTERNAL:non sslv2 initial
packet:/cakebox/src/secure/lib/libssl/../../../crypto/openssl/ssl/s2_pkt.c:187:

or similary for ssl3:

SSL_accept:before/accept initialization
SSL_accept:error in SSLv3 read client hello B
ERROR
2416:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:/cakebox/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_pkt.c:297:

I also tried stunnel3:
(stunnel3 -f -D 7 -c -d 2001 -r ns:443)

2006.03.20 21:35:12 LOG6[2378:134633472]: SSL connected: previous session reused
2006.03.20 21:35:17 LOG7[2378:134633472]: SSL alert (write): fatal: handshake
failure
2006.03.20 21:35:17 LOG3[2378:134633472]: SSL_read: 1408F10B: error:1408F10B:SSL
routines:SSL3_GET_RECORD:wrong version number
2006.03.20 21:35:17 LOG5[2378:134633472]: Connection reset: 44 bytes sent to
SSL, 0 bytes sent to socket
2006.03.20 21:35:17 LOG7[2378:134633472]: stunnel3 finished (0 left)

and finally s_client:
(openssl s_client -connect cakebox:443 -tls1 -bugs -state -debug)
fter sucessfully conting, requesting the tunnel aborts with:
SSL3 alert write:fatal:protocol version
2431:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:/cakebox/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_pkt.c:286:
write to 0808D700 [080B4000] (37 bytes => 37 (0x25))
0000 - 15 54 54 00 20 01 6e f3-14 fc bb f8 fc 4b 1e 3e   .TT. .n......K.>
0010 - 7e 73 89 3a cb 3e f0 d2-43 e2 45 01 9b 12 88 dc   ~s.:.>..C.E.....
0020 - ff 3e 90 5a ed                                    .>.Z.
SSL3 alert write:warning:close notify

and very similar with ssl3:
(openssl s_client -connect cakebox:443 -ssl3 -bugs -state -debug)
SSL3 alert write:fatal:handshake failure
2451:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:/cakebox/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_pkt.c:286:
write to 0808D700 [080B4000] (37 bytes => 37 (0x25))
0000 - 15 54 54 00 20 14 70 c4-f8 7e b4 9d bc 18 5b a2   .TT. .p..~....[.
0010 - a4 66 33 43 7b 89 00 b8-75 25 7f 92 8e 8e 0a 64   .f3C{...u%.....d
0020 - b7 03 f3 46 80                                    ...F.
SSL3 alert write:warning:close notify

All of this was tested against Apache2.0.55 (FreeBSD) PHP/4.4.2 mod_ssl/2.0.55
running FreeBSD 6.1-PRERELEASE on the server and the client.
OpenSSL 0.9.7e-p1 25 Oct 2004 was installed on both systems.
I also applied the patch for 2.0.52 which still applies just fine on 2.0.55, but
the behaviour didnt change.
I hope this helps.
Comment 19 Ruediger Pluem 2006-03-20 21:00:54 UTC
(In reply to comment #17)
> I think we all can agree on that we should refrain from telling people on what
> they should and what they should not do. Even if some things are not advisable
> someone might have no alternative.

It is not about telling people what they should do. If you want to use httpd for
word processing I won't tell you that you should not do, but I would not accept
any bug that says, that it fails to print. Furthermore I would not support any
enhancement requests to teach httpd to do so (This report here is an enhancement
request).

Connecting via SSL to a proxy and issuing a CONNECT command is not specified in
any RFC and thus it is no bug.
As you can currently see, there is no conviction that this is useful or no
priority on this issue by the developers working on the reports in bugzilla.
But it is open source. So feel free to prepare a patch that solves this issue
test it and try to convince the developer community on the dev@httpd.apache.org
list that this is something useful that it should be added to httpd.
And if the developers do not like it, you can use it at least for own.
Comment 20 William A. Rowe Jr. 2006-03-20 22:24:22 UTC
"Connecting via SSL to a proxy and issuing a CONNECT command is not specified 
in any RFC and thus it is no bug."

I can concur this is an enhancment request, but please cite where RFC 2818
cites POST or GET?  Should these be unsupported as well?  Suggestion to all
on this issue thread; stop making it personal.  The request is legitimate,
for example, to proxy through the DMZ to a private subnet using http: - the
request would not be encrypted (the backend only honoring http:) and should
therefore be carried with HTTP/1.1 CONNECT over ssl through the public net.

That said, there are two concerns;

1. Memory growth; there are already potential issues of unbounded memory
growth from bucket/brigade reallocations which have been reported by folks
attempting to serve or proxy streaming feeds such as audio/video.  Whatever
issues occur there, will also be evidenced here in this use case.  Not only
does the underlying bug need to be addressed but the 

2. Double-encryption; carrying an https: connection over a proxy CONNECT
tunnel would result in the client performing double SSL encryption, which
would be sub-optimal.  The client to proxy stream would reencrypt the client
to backend server encrypted channel.  This means it's especially important
for the client to backend server to employ any deflation of the stream first,
because no compression of the client to proxy connection is possible with
encrypted data.

There is no benefit to the double-encryption example cited above.
Comment 21 William A. Rowe Jr. 2006-03-20 22:30:17 UTC
"Not only does the underlying bug need to be addressed but the "...

...new code must be evaluated against the corrected use of brigades and buckets
to ensure the issue doesn't occur in CONNECT streams either.

One additional observation, it's necessary for the patch to drill back down
to only connection-oriented filters, beyond any body filters that are in the
filter stack, to avoid corruption the CONNECT stream. 
Comment 22 Brad Boyer 2006-03-21 02:46:02 UTC
(In response to comment #21)
Is setting r->output_filters = NULL not enough to kill all the filters above the
connection level? The current patch does leave that in the code, and it seems to
work. I must say I'm no expert in the way apache filters work internally.
Comment 23 Brad Boyer 2006-03-21 02:52:01 UTC
(In response to the "should we" comment thread)
1) The comments in the original code specifically state that it is doing things
the wrong way, and the way the patch does it is more or less the suggested fix
from the old comments.

2) Just as a use-case, I am actually using the CONNECT method to tunnel an
unencrypted protocol (don't ask) and taking advantage of the SSL handling in
apache to add security and authentication to an otherwise completely unsecured
connection. I know this isn't the original intended use of CONNECT, but it seems
to me to be a valid usage.
Comment 24 William A. Rowe Jr. 2006-03-21 03:52:39 UTC
Nope, you can't null the output_filter.

You -can- set input_filter and output_filter to the conn_rec's input and
output filter, stripping the connection of all http/body filters.

 
Comment 25 Dag Wieers 2006-03-22 20:57:33 UTC
> There is no benefit to the double-encryption example cited above.

The way I see it is that the double encryption in this case is a trade-off to
have the initial connection to the remote (HTTPS) proxy encrypted (the SSH
connection string). The overhead is a calculated one in the case you use this
setup (or one that you are forced to use in case there is layer 7 inspection).
Comment 26 Emmanuel Elango 2006-04-05 05:30:56 UTC
Hi Everyone,

I was finally able to check the issue again and yes the bug does exist in the
2.0.54 release on WinXP. Brad's patch works great. Thanks Brad. Sorry about the
bad testing earlier.

Emmanuel

(In reply to comment #14)
> Hi Everyone,
> 
> Firstly chunked encoding could possibly fail because of this if mod_proxy_http
> also has some direct writes to the socket instead of through the ap_rwrite. I
> havent combed through the source but I am fairly sure that chunked transfer
> seems to work fine in my experience.
> 
> Secondly I do understand what you are saying in the test case. I am actually
> running a proxy on an SSL enabled apache server. Since browsers so far cant be
> easily tweaked to communicate over SSL to a proxy I've written a small Perl
> script which acts as another proxy between the browser and the SSL enabled
> proxy. The browser talks normal HTTP to the Perl script. The Perl script talks
> SSL to the SSL enabled proxy. I ran into problems when the browser tried to
> CONNECT to a secure site over this setup. The Perl script would negotiate SSL
> allright but then as soon as the CONNECT request went through mod_proxy_connect
> would hijack the connection and send back normal HTTP. There seems to be no
> problem with mod_proxy, mod_proxy_http and mod_proxy_ftp.
> 
> Thats how I came across this bug. I had a hard time compiling apache on Windows
> but after very clear instructions from www.devside.net I finally managed to
> compile the patch. The patch worked great with 2.0.52. Recently I decided to set
> up another machine as a similar proxy. This time also as usual I picked up the
> precompiled binary at http://www.apache.org/dist/perl/win32-bin/. The version
> had been upgraded to 2.0.54. On a whim I decided to check it out without
> installing the patch. Surprisingly it worked fine. Thats how I came to the
> conclusion that mod_proxy_connect seems to have been fixed. I really dont have
> another spare machine to test this again to reconfirm. But let me see what I
can do.
> 
> Emmanuel
Comment 27 Brad Boyer 2006-05-03 22:27:40 UTC
Created attachment 18222 [details]
Fixed patch with read loops and updated to 2.2.0

This is a new version of the patch to use the filter I/O in proxy_connect. Some
modules don't return everything with a single ap_get_brigade() call, so this
version loops until there is no data pending. The filter chains in the request
are now set to the ones from the connection instead of NULL. I also have
updated to 2.2.0 and changed some log messages.
Comment 28 Arnaud 2006-08-10 13:46:23 UTC
Hello,
I'd like to see this feature integrated in the official apache distribution,
because it can be very convenient in some cases. It is the only solution I have
found in order to access my home computer from my office.

Indeed, here at work we have a firewall/proxy that filters applicative content
and will only accept HTTP on port 80 and SSL on port 443
I could have run an stunnel server on port 443 at home, but i have an apache
server there that i want to also handle ssl requests.

So, what i needed is that apache be able to behave also as a "stunnel" server. I
have been thinking of writing a patch like the one attached until i found this
bug report and saw that someone had already written it.

I've been using this patch for some time (now against 2.0.59) and it is working
perfectly.
Comment 29 Lionel VICTOR 2007-01-10 13:40:38 UTC
I've downloaded recently the source code from apache 2.2.0 but the patch won't 
apply... Which other patches are required ?

I'm running a 2.2.3 apache server and none of the patches here seem to apply. 
This is why I'm now trying with the 2.2.0 official distrib, but I get more or 
less the same result.

I tried to debug the code myself but I barely know the apache API. I'm 
wondering what the backconn socket in the patch represent, where does it come 
from ? there are references to some c-> structure but I don't have any c 
variable in my https 2.2.0 original code ??? then there is this "packet 
brigade" stuff that is used to copy blocks but I dont have it in the original 
source eihter ?? then finally there are thes input/ouput filters.. ???

can anyone point my out of this stuff ? or just mail me a plain patched 
mod_proxy_connect.c file from the 2.2.0 distrib so I can start from something 
concrete instead of some patch work that makes no sense to me so far ?

why isn't the 2220 patch working on the httpd2.2.0 original source code ? 
applying a patch is as easy as patch -u -p0 < patch_file... damn what could I 
miss ???

many many many thx in advance for your tips/hints help.

(In reply to comment #27)
> Created an attachment (id=18222) [edit]
> Fixed patch with read loops and updated to 2.2.0
> This is a new version of the patch to use the filter I/O in proxy_connect. 
Some
> modules don't return everything with a single ap_get_brigade() call, so this
> version loops until there is no data pending. The filter chains in the 
request
> are now set to the ones from the connection instead of NULL. I also have
> updated to 2.2.0 and changed some log messages.

Comment 30 Emmanuel Elango 2007-01-10 20:22:32 UTC
maybe you could check out the 2.0.5x version. at least it works there.

(In reply to comment #29)
> I've downloaded recently the source code from apache 2.2.0 but the patch won't 
> apply... Which other patches are required ?
> 
> I'm running a 2.2.3 apache server and none of the patches here seem to apply. 
> This is why I'm now trying with the 2.2.0 official distrib, but I get more or 
> less the same result.
> 
> I tried to debug the code myself but I barely know the apache API. I'm 
> wondering what the backconn socket in the patch represent, where does it come 
> from ? there are references to some c-> structure but I don't have any c 
> variable in my https 2.2.0 original code ??? then there is this "packet 
> brigade" stuff that is used to copy blocks but I dont have it in the original 
> source eihter ?? then finally there are thes input/ouput filters.. ???
> 
> can anyone point my out of this stuff ? or just mail me a plain patched 
> mod_proxy_connect.c file from the 2.2.0 distrib so I can start from something 
> concrete instead of some patch work that makes no sense to me so far ?
> 
> why isn't the 2220 patch working on the httpd2.2.0 original source code ? 
> applying a patch is as easy as patch -u -p0 < patch_file... damn what could I 
> miss ???
> 
> many many many thx in advance for your tips/hints help.
> 
> (In reply to comment #27)
> > Created an attachment (id=18222) [edit] [edit]
> > Fixed patch with read loops and updated to 2.2.0
> > This is a new version of the patch to use the filter I/O in proxy_connect. 
> Some
> > modules don't return everything with a single ap_get_brigade() call, so this
> > version loops until there is no data pending. The filter chains in the 
> request
> > are now set to the ones from the connection instead of NULL. I also have
> > updated to 2.2.0 and changed some log messages.
> 
> 

Comment 31 Mark Cave-Ayland 2007-02-03 09:25:22 UTC
Created attachment 19504 [details]
Fix broken patch 18222 for 2.2.0; includes cleanups (see text)

I discovered that the last patch posted for 2.2.0 is faultly since it appears
the diff was taken against an older 2.1.6 tree rather than the 2.2.0 tree.
Hence I have merged these changes into a patch that works for me when applied
against 2.2.2.

Note that I have tidied up parts of the patch, in particular removing the
entries for changes in white space and changes to/from
ap_log_error/ap_log_rerror, plus changing the order of parts of the patch in
order to fit the newer code in 2.2.2.
Comment 32 Lionel VICTOR 2007-02-05 05:26:02 UTC
Thank you so much everyone... actually I did managed to patch the sources I 
had downloaded but I did not post anything here becaus I was not sure that it 
would work for everybody (at least it is still working for what I wanted to 
achieve).

I did it based on what I read about the bug (module is outputing data directly 
to the socket instead of using a filter) and a book a firend borrowed me on 
apache API... (you can guess how ugly it finally gets)

I believe that your new attachement will save time to other people so thank 
you very much again. I will probably try to apply it sooner or later and 
replace my ugly code... It will eventually save me from my own bugs !

many many thanks indeed.

(In reply to comment #31)
> Created an attachment (id=19504) [edit]
> Fix broken patch 18222 for 2.2.0; includes cleanups (see text)
> I discovered that the last patch posted for 2.2.0 is faultly since it appears
> the diff was taken against an older 2.1.6 tree rather than the 2.2.0 tree.
> Hence I have merged these changes into a patch that works for me when applied
> against 2.2.2.
> Note that I have tidied up parts of the patch, in particular removing the
> entries for changes in white space and changes to/from
> ap_log_error/ap_log_rerror, plus changing the order of parts of the patch in
> order to fit the newer code in 2.2.2.

Comment 33 Julian Gilbey 2007-02-21 01:09:51 UTC
I tried the latest patch given (by Mark, the one against the 2.2.2 version), and
applied it to the 2.2.3 tree.  It did not work, in the sense that proxytunnel
said the following:

burnside:~ $ ssh -p 8080 localhost
SSL enabled
localhost is 127.0.0.1
Connected to localhost:443
Tunneling to localhost:8080 (destination)
Connect string sent to Proxy: 'CONNECT localhost:8080 HTTP/1.0
Proxy-Connection: Keep-Alive

'
DEBUG: recv: ''analyze_HTTP: borken
Unsupported HTTP version number
ssh_exchange_identification: Connection closed by remote host


So it seems that the problem may still be there.  Any suggestions?

   Julian
Comment 34 Lionel VICTOR 2007-02-21 03:13:03 UTC
Well.. I have not tested the latest patch. I did not post mine because it is 
more a hack than a patch...

You can get my source file here:

http : lionel.victor.free.fr/mod_proxy_connect.c

I did not produce a diff so you can diff it yourself from your source and 
verify what I did. (be carefull, i changed indentation so you'd better use -w 
when using diff)

the source above is modified from the original 2.2.3 source code downloaded 
from the apache project.

Now, concerning your problem, I advise you to really debug step by step. I 
first though that i would use proxytunnel alone (with the encrypt option) but 
I was wrong... I definitely had a problem similar to yours.
However, I am using mutual authentication on some parts of my HTTPS host, I 
therefore though that proxytunnel could not handle the special SSL handshake. 
Maybe it just does not work at all with SSL...

I'm now using proxytunnel to link to my machine (and listen to local 
connections), then stunnel to open the ssl tunnel and present the client 
certificate... then another proxytunnel to do what I have to do.

hope it helps

(In reply to comment #33)
> I tried the latest patch given (by Mark, the one against the 2.2.2 version), 
and
> applied it to the 2.2.3 tree.  It did not work, in the sense that proxytunnel
> said the following:
> burnside:~ $ ssh -p 8080 localhost
> SSL enabled
> localhost is 127.0.0.1
> Connected to localhost:443
> Tunneling to localhost:8080 (destination)
> Connect string sent to Proxy: 'CONNECT localhost:8080 HTTP/1.0
> Proxy-Connection: Keep-Alive
> '
> DEBUG: recv: ''analyze_HTTP: borken
> Unsupported HTTP version number
> ssh_exchange_identification: Connection closed by remote host
> So it seems that the problem may still be there.  Any suggestions?
>    Julian

Comment 35 Julian Gilbey 2007-02-21 16:57:18 UTC
Thanks for your comments (comment #34).  I tried your version of
mod_proxy_connect.c, but it made no difference.  It seems that the issue is in
proxytunnel: it appears to send plain HTTP headers, even over an HTTPS
connection.  Hmmm.

Please could you describe your solution a little more fully - I've never played
with stunnel and don't understand the setup you've described.

Thanks!
Comment 36 Lionel VICTOR 2007-03-16 07:15:13 UTC
Sorry for that late answer.

What you described with the Unsupported HTTP version number message seems to 
be a bug from proxytunnel... I haven't had the time to investigate the -e 
option which is used to specify that proxytunnel must use SSL so I cannot 
comment on that.

Basically, as it did not work for me I used an extra tool called stunnel that 
simply listen to a port locally and open an SSL session to a remotehost. You 
just send traffic in clear to the local port and stunnel makes the connection 
to the remote host:port with ssl and deals with the crypto.

Now, if you want to connect through an HTTP proxy, you use
proxytunnel.exe -p proxy:proxyport -d targethost:targetport -a anylocalport

If you have to proxy other SSL, you must first launch stunnel with an entry 
like that in your stunnel.conf
[ssh-tunnel]
accept = porttolistento
connect = ssltargethost:ssltargetport
client = yes

Then any combination is possible... in my case:

proxytunnel-1 creates a tunnel to a remote host with apache-proxy-ssl
proxytunnel-1 listent to port 443 (-a 443)
here is the command line
proxytunnel.exe -p proxy:proxyport -d apache-proxy-ssl-host:443 -a 443

then stunnel unwrap the ssl layer:
here is the entry for ssl-tunnel.conf
[ssh-tunnel]
accept = 8080
connect = 127.0.0.1:443
client = yes

then another proxytunnel creates the tunnel through apache-proxy:
proxytunnel.exe -p localhost:8080 -d anywhere:anyport

Of course, anywhere anyport must match your configuration on the apache-proxy-
ssl-host, otherwise, you will be rejected.

The second proxytunnel.exe is not necessary.. you can also configure your 
explorer to use localhost:8080 as a proxy instead...

Well you get the idea:
- proxytunnel just connect to an http host throug a proxy
- stunnel manages the ssl traffic: it converts https into http for you if you 
prefer...

now, based on your needs, you must embedd tunnels to jump from host to host 
and decrypt the traffic... the exact config depends on what you want to 
achieve.

The nice thing is that you can now secure the apache-proxy module with ssl 
(including client authentication) and it opens some new opportunities to 
secure a network.

hope it helps


(In reply to comment #35)
> Thanks for your comments (comment #34).  I tried your version of
> mod_proxy_connect.c, but it made no difference.  It seems that the issue is 
in
> proxytunnel: it appears to send plain HTTP headers, even over an HTTPS
> connection.  Hmmm.
> Please could you describe your solution a little more fully - I've never 
played
> with stunnel and don't understand the setup you've described.
> Thanks!

Comment 37 Julian Gilbey 2007-03-16 07:43:34 UTC
Created attachment 19723 [details]
Patch for proxytunnel 1.7.0 to have two proxies with second one SSL encrypted

Thanks for this advice!  Amusingly, I fixed the problem just yesterday: I used
the SVN version of proxytunnel, patched so that I could do the following:

putty -> proxytunnel -> local proxy (unencrypted) -> remote Apache HTTPS
encrypted -> SSH

(The firewall required the second CONNECT to be encrypted.)  The patch is
attached; it includes recent SVN fixes, as well as my patch to introduce -R,
meaning encrypt from the second proxy.	The command line will then read:

proxytunnel -q -R -p proxy.local:8000 -r proxy.remote.org:443 -d
ssh.remote.org:22

I hope this is of help to others.

Julian
Comment 38 Parwinder Sekhon 2007-05-17 16:06:27 UTC
Hi Julian, I was very excited about this patch as its exactly what I'm looking
for.  I tried applying this patch to "proxytunnel 1.7.0 2007-02-25 11:46".  On
executing ssh with something akin to:

proxytunnel -q -R -p proxy.local:8080 -r proxy.remote.org:443 -d ssh.remote.org:22

it CONNECTs through the first proxy, CONNECTs through the second proxy to
ssh.remote.org:22, however is immediately disconnected.  When I look at
/var/log/secure all I see is a message like:

May 17 22:25:16 server1 sshd[31530]: Did not receive identification string from
127.0.0.1

for every connect attempt.  Did you experience anything similar, any ideas? 
I've tried testing with 2 proxies where the second proxy is running without SSL
(and so also without using the -R option) and everything works okay.  Its only
when I make the second proxy use SSL and add the -R option that I get immediate
disconnect from the sshd daemon.

Regards
Parwy Sekhon

(In reply to comment #37)
> Created an attachment (id=19723) [edit]
> Patch for proxytunnel 1.7.0 to have two proxies with second one SSL encrypted
> 
> Thanks for this advice!  Amusingly, I fixed the problem just yesterday: I used
> the SVN version of proxytunnel, patched so that I could do the following:
> 
> putty -> proxytunnel -> local proxy (unencrypted) -> remote Apache HTTPS
> encrypted -> SSH
> 
> (The firewall required the second CONNECT to be encrypted.)  The patch is
> attached; it includes recent SVN fixes, as well as my patch to introduce -R,
> meaning encrypt from the second proxy.	The command line will then read:
> 
> proxytunnel -q -R -p proxy.local:8000 -r proxy.remote.org:443 -d
> ssh.remote.org:22
> 
> I hope this is of help to others.
> 
> Julian

(In reply to comment #37)
> Created an attachment (id=19723) [edit]
> Patch for proxytunnel 1.7.0 to have two proxies with second one SSL encrypted
> 
> Thanks for this advice!  Amusingly, I fixed the problem just yesterday: I used
> the SVN version of proxytunnel, patched so that I could do the following:
> 
> putty -> proxytunnel -> local proxy (unencrypted) -> remote Apache HTTPS
> encrypted -> SSH
> 
> (The firewall required the second CONNECT to be encrypted.)  The patch is
> attached; it includes recent SVN fixes, as well as my patch to introduce -R,
> meaning encrypt from the second proxy.	The command line will then read:
> 
> proxytunnel -q -R -p proxy.local:8000 -r proxy.remote.org:443 -d
> ssh.remote.org:22
> 
> I hope this is of help to others.
> 
> Julian

Comment 39 Julian Gilbey 2007-05-17 23:47:01 UTC
Have you tried running proxytunnel with the -v (verbose) flag instead of -q to
see exactly what is happening?
Comment 40 Parwinder Sekhon 2007-05-18 11:14:35 UTC
Yes, as expected from the /var/log.secure I get

SSL local to remote proxy enabled
Proxy basic auth is xxxx
Local proxy proxy.local.org resolves to xxxx
Connected to proxy.local.org:8080 (local proxy)
Tunneling to proxy.remote.org:443 (remote proxy)
Connect string sent to local proxy:
-> CONNECT proxy.remote:443 HTTP/1.0
-> Proxy-authorization: Basic xxxx
-> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32)
-> Proxy-Connection: Keep-Alive
Data received from local proxy:
<- HTTP/1.0 200 Connection established
<- Proxy-Agent: NetCache NetApp/6.0.3D2
Tunneling to ssh.remote.org:22 (destination)
Connect string sent to remote proxy:
-> CONNECT ssh.remote.org:22 HTTP/1.0
-> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32)
-> Proxy-Connection: Keep-Alive
Received from remote proxy:
error: Socket read error.
ssh_exchange_identification: Connection closed by remote host

PS: machines names and basic authorisation changed to hide details.

(In reply to comment #39)
> Have you tried running proxytunnel with the -v (verbose) flag instead of -q to
> see exactly what is happening?
Comment 41 Fitzgerald Krudde 2007-05-23 12:13:31 UTC
I am experiencing the same problem (when hopping with http through the first
proxy and ssl through the second proxy to an ssh server):

Received from remote proxy:
error: Socket read error.
ssh_exchange_identification: Connection closed by remote host

Anyone got suggestions or solutions?
Comment 42 Fabrice Durand 2007-06-08 13:30:35 UTC
Created attachment 20331 [details]
Fixed patch updated to 2.2.4
Comment 43 David GENCE 2007-06-21 06:00:37 UTC
Created attachment 20379 [details]
Port of the patch from 2.2.2 to 2.2.4

Hi,

I tried the patch join in the "20331: Fixed patch updated to 2.2.4" message,
but it didn't work for me.
I had those kind of message:
=> In the standar output
...
Received from remote proxy:
error: Socket read error.
ssh_exchange_identification: Connection closed by remote host

=> In the ssh log
Jun 21 13:34:48 [sshd] Did not receive identification string from
XXX.XXX.XXX.XXX

I made this patch by porting the existing one for apache 2.2.2, and now it work
for me.
I hope it will help.
Comment 44 Ioldanach 2007-08-17 12:51:28 UTC
Who should I talk to to suggest that this patch be moved into the official
distribution?  Whether or not CONNECT is specified to work over ssl it would be
useful if it did.  There are certainly circumstances where it might be desirable
to securely proxy the first leg of a connection, regardless of the underlying
connection's protocol.  I'd like to be able to use the functionality without
having to move to a patched apache server.
Comment 45 Per Gunnar Hans 2007-09-14 01:56:24 UTC
With the behaviour of encrypted CONNECT not specified by an RFC and obviously
two different uses of CONNECT are proven to be in demand (and the original
writer leaving comments in the code stating that the current state of affairs
isn't necessarily the right way of doing things) I don't see why this feature
isn't included in the official distribution. 

All that is needed is a new directive to control the behaviour, for instance
CONNNECTEncryption plain | encrypted | sameAsOrigin. The default may very well
be todays behaviour to ensure compatibility.

Today, I have to use at least a day to add this patch to my servers each time
there is a new Debian release of Apache2. I loose the ease of use of a
distribution, and my servers are potentially less secure because this perpetual
patch doesn't get the amount of competent eyeballing and feedback it deserve.
Comment 46 Dag Wieers 2007-10-03 09:39:46 UTC
Created attachment 20911 [details]
Port of the patch from 2.2.4 to 2.2.6
Comment 47 Ioldanach 2007-10-05 11:28:21 UTC
(In reply to comment #46)
> Created an attachment (id=20911) [edit]
> Port of the patch from 2.2.4 to 2.2.6
> 

I applied this patch to fresh 2.2.6 source and it didn't work.  Afterwards
though I upgraded to 2.2.6 through yum and was able, with no issues, to get the
source rpm for 2.2.4, apply the patch to that, compile it with mod_proxy_connect
as shared, and then copy the mod_proxy_connect.so file into the 2.2.6 modules
directory and it worked just fine.

Incidentally, the command that works in my ssh config is:

        ProxyCommand /usr/tunnel/proxytunnel/trunk/proxytunnel/proxytunnel.exe
-p proxy.com:443 -d sshhost.com:22 -u myuser -s mypass -E
Comment 48 Tim Dodge 2007-10-08 11:00:22 UTC
Created attachment 20946 [details]
Working port of the patch from 2.2.4 to 2.2.6

A working port of the patch from 2.2.4 to 2.2.6.
Comment 49 bugmenot 2007-10-10 11:58:21 UTC
Yes, can we please get this into the official release?  I use apt and don't want
to have to patch and recompile for every release.

Thanks.
Comment 50 Mark Cave-Ayland 2007-10-18 12:54:49 UTC
I don't think that any developers are following this bug anymore; I'd imagine
we'd have to bring up the topic on one of the mailing lists...
Comment 51 Sudhaker 2008-03-04 15:17:50 UTC
Bump... +1 from me too.

This is more than 3-1/2 year old issue. Committers, please consider this so-very-obvious fix for merging. This is certainly a good feature and nice to have. 

SSL is a transport layer feature and SSL-inside-SSL is a very valid use-case. Not sure why bug-fix team is reluctant in this.

Thanks,
Comment 52 Dag Wieers 2008-03-04 16:33:54 UTC
This report is opened against 2.0-HEAD so I doubt anyone from the developers is actually looking at it. I guess we have to move it to 2.3-HEAD ?

Or someone need to bring it up on the developers mailinglist as suggested in #50. Anyone willing to describe the possible use-cases and a well written rationale ?

Comment 53 Nick Kew 2008-03-04 23:14:44 UTC
If any patch is to be applied, it needs to be evaluated.  A patch that works against current /trunk/ and any usage cases / test cases would reduce the developer time required to evaluate it, and could thus improve your chances.  All I see here is inconclusive to merit evaluating (patches that work for some but fail for others, etc).
Comment 54 Dag Wieers 2008-03-05 05:34:01 UTC
I do not agree, we first need closure on the fact whether the Apache developers want to support CONNECT over an SSL connection. There are cases where this functionality is needed and useful, but as long as this is not acknowledge by any of the developers, why should we bother with patches ?

I also do not agree with your assessement of this bugreport. Did you try or use the functionality yourself ? Did you have a problem with it ?
Comment 55 Nick Kew 2008-03-05 07:03:13 UTC
(In reply to comment #54)
> I do not agree, we first need closure on the fact whether the Apache developers
> want to support CONNECT over an SSL connection.

You won't get that by posting here.  This isn't the dev list.

>    There are cases where this
> functionality is needed and useful, but as long as this is not acknowledge by
> any of the developers, why should we bother with patches ?

People have lots of demands on their time, and a chronic shortage of round tuits.  Evidently no committer sees a need for this (or it would have got their attention before now).  If anyone wants a patch, you have to convince us it's worth our time and effort to review it.

> I also do not agree with your assessement of this bugreport. Did you try or use
> the functionality yourself ? Did you have a problem with it ?

I have no use for it.

I took a look, because the sheer number of people subscribed seems to indicate a real demand.  But when I see numerous competing patches, and lots of comments about them not working, it's too much effort to figure out where to start.
Comment 56 Sudhaker 2008-03-05 08:03:06 UTC
We can possibly fork this effort and someone can publish various pre-compiled and patched "mod_proxy_connect.so". This can take away the pain of individually re-compiling the module ;-)

Last night I compiled "mod_proxy_connect" for 2.2.3 using patch given at https://issues.apache.org/bugzilla/attachment.cgi?id=20379 (had to fix httpd-2.2.3 that comes with CentOS5). It worked great after I replace the original "mod_ssl_connect.so" with this patched one :-)

I use Stunnel at client-end to theoretically abstracts me from underlying SSL connections and get a normal local http-proxy at localhost:8080 which bridges to apache running at my home machine (over SSL). FYI, my <Proxy> settings are inside SSL VirtualHost and it is not exposed without encryption.

This technique works great for ssh-over-connect with dynamic-forward enabled at port 1080. Then I can then set socks-proxy to localhost:1080 in any application and it works.

Other use-case is when I configure my applications to use http-proxy at localhost:8080 ; This is where things get complicated and I see "SSL3_GET_RECORD:bad decompression" in my stunnel log file. Setting "sslVersion  = TLSv1" in my "stunnel.conf" eventually fixes it (not tested comprehensively). Guess there are some combinations of protocols which breaks even with this patch.

Followings are possible combinations we may need to test 

Plain-over-SSLv2, SSLv2-over-SSLv2, SSLv3-over-SSLv2, TSLv1-over-SSLv2
Plain-over-SSLv3, SSLv2-over-SSLv3, SSLv3-over-SSLv3, TSLv1-over-SSLv3
Plain-over-TSLv1, SSLv2-over-TSLv1, SSLv3-over-TSLv1, TSLv1-over-TSLv1

Question for SSL expert:- Are there any technical challenges in implementing SSL-inside-SSL?

Cheers,
Sudhaker
Comment 57 Emmanuel Elango 2008-03-05 09:07:12 UTC
I dont see why CONNECT should not be supported over an SSL connection. I mean after all a proxy is a proxy and ssl is ssl. The proxy should do its job and ssl should do its.

I think writing directly to the socket instead of the handler that called it not a great idea on the part of mod_proxy.

This is becoming a much needed functionality given the increasing restrictiveness of corporate firewalls. If I (and others) get access only to port 443 and I need to run a secure webserver as well as a proxy then apache is the only solution. If I use SSHD then only I will benefit and others cannot use the secure web server (since I cant be handing out ssh logins to all and sundry). Most people do not get 2 IP addresses to run both SSHD and Apache separately.

I have been running this patch on winxp for over 3 years now and it works great. Managed to compile it using MSVC++. One can get a free one month ssl certificate from rapidssl. Since this certificate will be verifiable from the certificate store of all browsers (except for the expired date) it provides fairly good security against a man in the middle attack too.

I think if this patch is made mainstream, interesting apps on bypassing restrictive firewalls will make their appearance. I myself have one which I have not released because of this unfixed issue.

Havent had problems with plain over SSLv3 or SSLv3 over SSLv3 using putty and/or mozilla and my own app which does what stunnel does except that it verifies the certificate (unlike stunnel).

Sometimes disconnects are a problem, but it could be because of intermediate proxies. Setting keep-alives in putty does keep the connection going for a fairly long time (a couple of hours at least).

In any case I think Apache has a rather intimidating attitude towards requests. The default hypothesis seems to be that most requests are worthless. But then I guess that the problem with the world. A few people control resources that affect far too many people, some of whom may not even be aware of how it is affecting or not affecting them. Look at our politicians or bureaucrats or even our bosses within the organization. Some requests may be worthless, some may be worth it, but demand is never a very great indicator at least in this case. I am sure not many really cared whether man had to go to the moon, or whether Mozart should have composed his famous pieces. After all these were paid for by the majority since Mozart didnt possibly go farming in the mornings.

But why intimidation and sarcasm should always be part of the response I often fail to understand.

Enough said I guess. Glad to help in case anyone needs help compiling or setting up. I'd really like this to be included or else a fork to happen. Que sera sera.


(In reply to comment #55)
> (In reply to comment #54)
> > I do not agree, we first need closure on the fact whether the Apache developers
> > want to support CONNECT over an SSL connection.
> 
> You won't get that by posting here.  This isn't the dev list.
> 
> >    There are cases where this
> > functionality is needed and useful, but as long as this is not acknowledge by
> > any of the developers, why should we bother with patches ?
> 
> People have lots of demands on their time, and a chronic shortage of round
> tuits.  Evidently no committer sees a need for this (or it would have got their
> attention before now).  If anyone wants a patch, you have to convince us it's
> worth our time and effort to review it.
> 
> > I also do not agree with your assessement of this bugreport. Did you try or use
> > the functionality yourself ? Did you have a problem with it ?
> 
> I have no use for it.
> 
> I took a look, because the sheer number of people subscribed seems to indicate
> a real demand.  But when I see numerous competing patches, and lots of comments
> about them not working, it's too much effort to figure out where to start.
> 

Comment 58 Per Gunnar Hans 2008-03-05 09:39:12 UTC
(In reply to comment #55)
> (In reply to comment #54)
[snip]

> If anyone wants a patch, you have to convince us it's
> worth our time and effort to review it.
> 
[snip]
> 
> I took a look, because the sheer number of people subscribed seems to indicate
> a real demand.  But when I see numerous competing patches, and lots of comments
> about them not working, it's too much effort to figure out where to start.

Thanks for taking a look. The two patches I attach here, positively work for us on their respective Apache versions, daily and with concurrent users on several servers. Using .deb install of Apache2 on Debian with kernel 2.6.18-5-686.

I once upon a time downloaded these patches from the attachments on this thread, but I fail to remember exactly which post, which is why I post these two again.

What this patch solves for us:

We host a web based service that uses Apache2 to serve Java Applets that in turn connects back to the server on port 443. The Java applets use CONNECT and mod_proxy to connect to other Java applets connected to that server. This works like a charm, even with the network restrictions of unsigned Java applets. Since we use port 443, our service work behind most corporate firewalls too.

The reason we in some cases use unsigned Java applets is that they work on all jre (even 1.1.7 from MS), while signed Java applets fail on some of them. Regrettably, there are still a lot of 1.1.7 in active use.

The alternative would be to implement encryption and a decent web server into our simple home-brewed proxy component. Which would be expensive enough to make the whole project infeasible.

Well, that's our story.

I believe a generic use case is that you can bind any service to the loopback interface and use Apache and mod_proxy to provide secure access, without sacrificing secure web hosting on that very server.

Many corporate firewalls allow only port 80 and 443 for outbound connections.

An additional bonus is that user access can be administered by using certificates and existing Apache management tools.

Comment 59 Per Gunnar Hans 2008-03-05 09:56:59 UTC
Created attachment 21628 [details]
Working patches for 2.2.4 and 2.2.6 with i686 dropin binaries.
Comment 60 Ruediger Pluem 2008-03-05 13:01:14 UTC
(In reply to comment #57)

> In any case I think Apache has a rather intimidating attitude towards requests.
> The default hypothesis seems to be that most requests are worthless. But then I

It may look intimidating to the outsider, but in fact it is not. It simply works differently from what you expect. As Nick said please come over to the dev@httpd.apache.org list with a patch against trunk and some reasoning. This will give you the highest chance of getting this added. Why?

- The audience on dev@ is much bigger than here in this single report.
- As the patch needs to be applied to trunk first anyway and might be backported afterwards most committers will not take care of it, because the first step is not straight forward for them, as they need to review the patch in a context different from the one were it was created and need to forward port it eventually. The easier you make it for committers to review your work, the most likely it is that it gets applied. BTW: The same is true for me if I want to get my peer committers to review my patches which is required for backports.
- As Nick correctly explained the developer resources are very tight. So many of us focus on two things: Fixing bugs (this report is an enhancement) and scratching our own itches and the itches of our employers as long as the solutions for these itches fit into the project which is not always the case. Obviously and thats back luck this report currently does not scratch the itch of any committer having read this report.

And yes, I admit that even the approach above is no guarantee that the patch gets applied but it increases the chance.
Comment 61 Sudhaker 2008-03-06 12:45:19 UTC
@ Nick & Pluem 

Thanks for your nice words and helping us understand how things work in apache-developer world. Many kudos for putting your hard work to apache project.

@ Emmanuel Elango

I agree with your statement.

> I dont see why CONNECT should not be supported over an SSL connection. I mean
> after all a proxy is a proxy and ssl is ssl. The proxy should do its job and
> ssl should do its.

@ Others 

I still don't see any email on mailing list (dev@httpd.apache.org) related to this issue. Can someone please take care of this - preferably the patch maker or someone who understands it well?

It was nice to see the convincing from "Per Gunnar Hans". At least we have one person who is requesting this patch for genuine reasons. I don’t want to start debate on worth-fullness of our intended proxy-avoidance but simply request committers to accept the patch for the sake of "doing right thing in right way". Writing directly to socket in-place of handler is really not a great idea and should be fixed ASAP.

Cheers,
Sudhaker

Comment 62 Brad Boyer 2008-03-06 13:45:32 UTC
As the original patch author, I'll be quite honest and say that the project for which I wrote the original patch is dead and buried. For this reason, I'm not really in a position to spend a lot of time on updating it to the latest version and push for its acceptance on the mailing list. If I find some time on the side, I'll update the patch and maybe clean it up a bit but no guarantees.

It would be best if someone who needs this patch going forward would take ownership of the issue.
Comment 63 Per Gunnar Hans 2008-03-07 04:22:50 UTC
(In reply to comment #62)
> As the original patch author, I'll be quite honest and say that the project for
> which I wrote the original patch is dead and buried. For this reason, I'm not
> really in a position to spend a lot of time on updating it to the latest
> version and push for its acceptance on the mailing list. If I find some time on
> the side, I'll update the patch and maybe clean it up a bit but no guarantees.
> 
> It would be best if someone who needs this patch going forward would take
> ownership of the issue.
> 

My C programming skills currently stretch to type "make all", and deploying this patch introduced me to the 'patch' program, so I don't know about ownership of the patch.

But if you can update the patch to HEAD, I'll run some tests and front it on the dev mailinglist.

Comment 64 Sudhaker 2008-03-07 09:18:27 UTC

Then guess, I'm on it.

Thanks,
Comment 65 Marek 2008-03-12 02:25:23 UTC
Hi to all,

because I'm not allowed to run my own apache modules on the server I use, I'm thinking about workaround.

For security reasons I really want to use HTTPS with basic auth.
I have one server listening on port 443, which removes SSL and through mod_proxy sends the requests to other apaches (which listen on other ports).

I was thinking about doing the same with proxytunnel: master (first) apache would remove the HTTPS and slave (second) apache would do base auth with the original (from ASF) mod_connect.

Do you think it could somehow work?

Thank you,
Marek
Comment 66 Sudhaker 2008-03-12 05:46:54 UTC
The only benefit of using patched mod_connect is that you get client's real IP address. So your filtering rules, log files operate on real IPs. 

Simply use stunnel at other end. 

[Browser] <=> [Stunnel client] <=> {INTERNET} <=> [Stunnel server] <=> [Apache mod_proxy] 

I've been using this flawlessly for a long time with only problem that every request has 127.0.0.1 as client IP.

Hope this helps.

Thanks,
Comment 67 William A. Rowe Jr. 2008-03-12 11:23:52 UTC
With respect to comments 65 / 66,

#1 never hijack bugs; create a new incident (if a legitimate bug exists).

#2 bugzilla is NOT a user support forum, refer to the appropriate channels
   for peer support, not this issue tracking service.

thank you.
Comment 68 Emmanuel Elango 2008-03-23 06:24:48 UTC
Created attachment 21703 [details]
Dropin binary for win32 (2.2x?) based on Per Gunnar Hans' patch (attachment 21628 [details])

Replace the mod_proxy_connect.so file in the apache install directory, typically 
\Apache2.2\modules, with this file.

Optionally back up the existing mod_proxy_connect.so file.

Compiled with a lot of pain using MS VC++ Express 8.0.

See http://www.apachelounge.com/forum/viewtopic.php?p=8304. Grab the perl script from there. Eases some amount of pain.

libhttpd, mod_proxy and mod_proxy_connect have to be almost manually compiled as they fail at the step rc.exe is invoked.

See workaround at http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=593794&SiteID=1
Delete Preprocessor options and add additional options by hand. Works only once. If you want to repeat you will have to manually modify the .proj file again.

Tested on 2.2.8. Should work on 2.2.6 and maybe on 2.2.x
Comment 69 alef 2008-04-21 10:05:12 UTC
mod_proxy_connect.c at comment #34 works for apache2 2.2.3 on Debian 4.0:
$ apt-get source apache2
copy the file above in modules/proxy
$ ./configure --enable-proxy --enable-proxy-connect --enable-mods-shared="proxy proxy-connect"
$ make
Use the DLL in modules/proxy/.libs/mod_proxy_connect.so
OpenSSH ProxyCommand and Putty 0.60 local proxy command:
proxytunnel -q -E -p proxy:443 -d host:22
Comment 70 Fitzgerald Krudde 2008-05-22 13:33:23 UTC
I have just successfully tested the following scenario:

- Apache 2.2.8 (on Gentoo)
- the patch from Per Gunnar Hans (the .so binary)
- the new version of proxytunnel (v.1.9.0), using SSL encryption from the first to the second proxy using the new --encrypt-remproxy option. Proxytunnel, what a great tool!

It works great!

And yes, it would be nice if the mod_proxy_connect patch would be accepted...

regards,
Fitzgerald.
Comment 71 Kevin Croft 2008-07-11 14:53:19 UTC
Created attachment 22248 [details]
proxy_connect patch updated for 2.2.9

Tested under Gentoo (x86_64 build) with the following steps:

Download sources & patch to /tmp
  cd /tmp
  tar jxf httpd-2.2.9.tar.bz2 
  cd httpd-2.2.9/
  cat /tmp/httpd-2.2.9-proxytunnel.patch | patch -p1

set your CFLAGS (on gentoo): 
  source /etc/make.conf

config and build:
  ./configure --enable-modules=all --enable-mods-shared=all --enable-proxy --enable-proxy-connect --enable-proxy-ftp --enable-proxy-http --enable-ssl
  gmake all -j3

install and restart:
  find -name "*proxy*.so" | xargs cp -t /usr/lib64/apache2/modules
  apache2ctl configtest && /etc/init.d/apache2 restart


test from the remote machine:

cat ~/.ssh/config
Host remote.machine.org
        ProxyCommand proxytunnel -v -E -p remote.machine.org:443 -d %h:%p

ssh remote.machine.org
SSL client to proxy enabled
Local proxy remote.machine.org resolves to 123.321.111.222
Connected to remote.machine.org:443 (local proxy)
Tunneling to remote.machine.org:22 (destination)
Communication with local proxy:
 -> CONNECT remote.machine.org:22 HTTP/1.0
 -> Proxy-Connection: Keep-Alive
 <- HTTP/1.0 200 Connection Established
 <- Proxy-agent: Apache

Tunnel established.
Comment 72 Julian Gilbey 2008-09-11 16:34:50 UTC
(In reply to comment #71)
> Created an attachment (id=22248) [details]
> proxy_connect patch updated for 2.2.9
> 
> Tested under Gentoo (x86_64 build) with the following steps:

I've tried this on my Debian testing system, and it hasn't worked for me.  Does anyone have any clue why not?

Here's what I'm getting, using Debian's apache 2.2.9-7, patched with this 2.2.9 proxy_connect_patch:

burnside:~ $ ssh -p 8080 localhost
Linux burnside 2.6.26-1-686 #1 SMP Thu Aug 28 12:00:54 UTC 2008 i686
[...]

so ssh itself works (and there's nothing exciting in ~/.ssh/config).  However:


burnside:~ $ proxytunnel -E -v -p machine.internet.net:443 -d localhost:8080
Local proxy machine.internet.net resolves to 1.2.3.4
Connected to machine.internet.net:443 (local proxy)

Tunneling to localhost:8080 (destination)
Communication with local proxy:
 -> CONNECT localhost:8080 HTTP/1.0
 -> Proxy-Connection: Keep-Alive
error: Socket write error.
burnside:~ $ 

This is a relatively new error, due most likely to either the upgraded apache or the upgraded ssh, and I'm not sure where it originates or why.  Any ideas what I can do about it?

Many thanks,

Julian
Comment 73 Julian Gilbey 2008-09-16 13:07:43 UTC
(In reply to comment #72)
> I've tried this on my Debian testing system, and it hasn't worked for me.  Does
> anyone have any clue why not?
> [...]

D'oh - it was an Apache configuration error: my ssl site had
<VirtualHost _default_:443>
while my main site had
<VirtualHost _default_>
instead of
<VirtualHost _default_:80>

So panic over and all works again!

Julian
Comment 74 Alexey Pelykh 2008-10-07 04:05:33 UTC
Hi everyone.
I think I've found a bug, that is connected with this bug.
I have Apache vhost, that is configured to allow CONNECT to 13128 port, and SQUID proxy server at 13128, on same server. When I try to establish tunnel connection
External SQUID Proxy :: CONNECT home_server:443 using SSL =>
Home Apache server :: CONNECT home_server:13128 =>
Home SQUID server :: CONNECT gmail.com:443(for example, really this does not matter what request to feed to SQUID)
it replies 400 Bad request.

But if to do same, but without SSL in tunnel, everything is OK, like
External SQUID Proxy :: CONNECT home_server:443 (SSL is disabled at my Apache server) =>
Home Apache server :: CONNECT home_server:13128 =>
Home SQUID server :: CONNECT gmail.com:443(for example, really this does not matter what request to feed to SQUID)
it replies 200 Connection Established

So I think it's Apache mod_proxy_connect has some bug.. Can I have some feedback? I know that such way is rarely used (if used by someone else except me), but this is the only solution acceptable :(

Comment 75 Thomas Stewart 2008-10-07 05:59:19 UTC
Just to confirm, applying the latest patch: "proxy_connect patch updated for 2.2.9" fixes the problem for me.

before:
$ gnutls-cli some.ssl.apache.proxy -p 443
<SNIP>
- Simple Client Mode:

CONNECT localhost:22 HTTP/1.0

*** Fatal error: A record packet with illegal version was received.
*** Server has terminated the connection abnormally.
$

after:
$ gnutls-cli some.ssl.apache.proxy -p 443
<SNIP>
- Simple Client Mode:

CONNECT localhost:22 HTTP/1.0

HTTP/1.0 200 Connection Established
Proxy-agent: Apache/2.2.9 (Debian) PHP/5.2.6-5 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g

SSH-2.0-OpenSSH_5.1p1 Debian-2
$ 

Any idea when this will be applied?

Regards
--
Tom
Comment 76 Stefan Fritsch 2008-11-09 13:20:33 UTC
The current patch ("proxy_connect patch updated for 2.2.9") has the following problem: If the client disconnects but the backend server continues to send data fast, apache will continue to read the data and not abort the connection to the backend (or only after a long time).

I think proxy_connect_transfer() should exit the loop and return an error if c_o->aborted. And proxy_connect_handler() should forcibly close the backend connection in this case and not call ap_lingering_close().


Another issue is that mod_status does not give useful output for the tunnel. The child stays in R (reading request) state and the transferred data is not counted in the Conn, Child, and Slot fields.

BTW, I also tested for memory leaks and couldn't find any: The process size did not increase even after transfer of >20GB.
Comment 77 Emmanuel Elango 2008-11-15 02:50:24 UTC
Created attachment 22877 [details]
Drop in binaries for 2.2.10 and possibly below

Applied Kevin Croft's patch to 2.2.10 source on Win 32. Should work fine as the svn apache repository says mod_proxy_connect.c has been unchanged for the last 7 months. (http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/)

mod_proxy_connect.c 	 645455 	 7 months 	 pquerna 	 Remove all references to CORE_PRIVATE.
mod_proxy_connect.dsp 	 495126 	 22 months 	 wrowe 	 Embed the .manifest files of all httpd binaries as a post-build operation. This...

Just two warnings about unreferenced local variables "i" and "o" in line 133, but otherwise works fine.

The patch could possibly be updated to remove declarations of variables "i" and "o".

Tested and works fine on windows xp.

Cheers,
Emmanuel
Comment 78 Philp M. Gollucci 2009-01-18 16:19:19 UTC
CC myself on FreeBSD related bugs
Comment 79 Ryan Underwood 2009-02-07 17:23:47 UTC
Works without modification now on 2.2.11 on Debian.

A bit tired of waiting for this patch to be included...
Comment 80 Viktor Štujber 2009-03-04 05:23:15 UTC
Apache's mod_proxy supports tunneling ssh over plaintext HTTP, as suggested on http://httpd.apache.org/docs/2.2/mod/mod_proxy_connect.html. But in this scenario, an eavesdropping adversary will see
1. that you're trying to proxy a connection
2. the destination server's address
3. your proxy credentials (!!)
4. that you're tunneling ssh
5. the sshd's version string
6. the ssh handshake and subsequent encrypted data

To avoid being compromised, one could instead talk to the proxy using HTTP over SSL (a.k.a. HTTPS). That way, the adversary can only observe a SSL handshake with the proxy. Since the proxy also acts as a web-server, the adversary cannot directly discern between a normal legitimate https page request and an ssh tunnel negotiation.

So the only difference between the two is that we add an extra crypto layer. This layer would transparent to the HTTP channel - no modification necessary. The only requirement is that the server properly maintains this layered model.

From comment #1 and others, it is shown that Apache actually does use this model, but only for client -> server traffic: the SSL layer is established and the HTTP CONNECT request parsed. But in the server -> client direction, the SSL layer is skipped and data written directly to socket.

So unless I made a mistake, I can only see this problem as a defect in mod_proxy's code logic - code that only works when there are no extra communication layers.
Comment 81 Rudolf Cardinal 2009-06-21 15:08:37 UTC
Created attachment 23840 [details]
Updated patch for Apache 2.2.11 mod_proxy_connect.c to implement CONNECT over SSL

I found that Kevin Croft's excellent patch for 2.2.9 (2008-07-11) no longer worked on Apache 2.2.11; this patch addresses minor changes to line numbering in mod_proxy_connect.c and seems to work fine.
Comment 82 Ine Ya 2009-07-19 11:38:54 UTC
Bug or feature request,.. this functionality is missing. This feature seems like a very nice solution for people behind very restrictive company proxies. Of course I could just turn off apache and use stunnel on port 443, but I prefer 'enhanced' mod_proxy to do that. Other option is to multiplex tls traffic by completely new module. I wrote one as excerise, but eventually revisited idea with mod_proxy.

Is it really that difficult to include some kind of switch to allow CONNECT to work over SSL? I'm completely fine with the default as 'off'.
Comment 83 Lionel VICTOR 2009-07-20 02:04:50 UTC
(In reply to comment #82)

Well stunnel won't let you to enforce a security policy based on SSL mutual auth to allow proxy_connect access (for instance): so you can have both a ssl web site for everyone PLUS a proxy for authenticated users... Indeed you are right, the feature is missing...

From comment #60 someone suggested that we push a patch on the @dev mailing list... I guess most people agree with the fact the patch is acceptable (if it does not introduce any kind of regression)

From what I could gather from the archives of the apache dev mailing list there were a few posts by "Sudhaker Raj" but not patch proposal ?

So it's up to us... we took something at some point we should give it back now...

Sudhaker ? did you manage to build something out of trunk (at some point in time) and propose a patch ?

Can we help ?

I suppose the apache team has validation campaings to validate their code both in terms of bugs (regression) and performances... I will not be able to support that, but I can probably checkout trunk patch and propose a fix on the dev mailing list if it hasn't been done...

This bug is marked 'ASSIGNED' can the bug owner write some kind of directions ? or simply confirm that we must keep pushing on the dev mailing list ?

cheers

> Bug or feature request,.. this functionality is missing. This feature seems
> like a very nice solution for people behind very restrictive company proxies.
> Of course I could just turn off apache and use stunnel on port 443, but I
> prefer 'enhanced' mod_proxy to do that. Other option is to multiplex tls
> traffic by completely new module. I wrote one as excerise, but eventually
> revisited idea with mod_proxy.
> 
> Is it really that difficult to include some kind of switch to allow CONNECT to
> work over SSL? I'm completely fine with the default as 'off'.
Comment 84 evanc 2009-07-29 09:10:12 UTC
One side effect of this change is that mod_logio byte counting seems to work better (not rigorously verified, but previously the output bytes was always 0, and now is something relatively aligned with my expectations).  Oddly, the standard byte count (%b/%B) is still not set.

Also, I noticed that the mod_log_config connection status (%X) is now "X" for CONNECT, which seems more correct than the previous "+".

I assume these changes are because the core filters are not being NULLed as in the original implementation.

So, this patch's behaviour has benefit even if one doesn't need an SSL proxy service.  We are using the proxy for controlling access to an internal network and having correct byte counting alone is of high interest.
Comment 85 Lionel VICTOR 2009-08-06 16:26:42 UTC
FYI
I've pushed a patch on the dev mailing list...
http://mail-archives.apache.org/mod_mbox/httpd-dev/200907.mbox/%3C1924324104.1978811248793507749.JavaMail.root@spooler10-g27.priv.proxad.net%3E

The patch itself has been mailed in another message whose date is "Sun, 02 Aug, 13:31" but I can't get a peralink to it... so you'll need to browse mailing list archive...

Someone answered he would take a look:
http://mail-archives.apache.org/mod_mbox/httpd-dev/200908.mbox/%3C4A75B32E.9040105@sharp.fm%3E

hope it helps... and many thanx to the people here who posted diffs... the patch really helps me on a daily basis !
Comment 86 Graham Leggett 2009-09-09 16:57:39 UTC
Applied to httpd-trunk in r813178, can you test and verify it works on trunk?
Comment 87 Stefan Fritsch 2009-09-12 15:26:32 UTC
The version in trunk has two issues:

1) If the client disconnects and the backend continues to send data fast, the backend connection will be closed only after a long time, if at all. 

2) If the backend closes the connection, but the client doesn't, the apache thread hangs and will not close the connection to the client. Here is a stack trace:

#0  0xf7fca430 in __kernel_vsyscall ()
No symbol table info available.
#1  0xf7e22e2b in poll () from /lib/i686/cmov/libc.so.6
No symbol table info available.
#2  0xf7f25f84 in apr_wait_for_io_or_timeout (f=0x0, s=0x8511f40, for_read=1) at support/unix/waitio.c:51
        pfd = {fd = 12, events = 1, revents = 0}
        rc = <value optimized out>
        timeout = 300000
#3  0xf7f1f370 in apr_socket_recv (sock=0x8511f40, buf=0x8525f60 "\r\nNNECT localhost:5555 HTTP/1.0\r\n", len=0xff8263b4)
    at network_io/unix/sendrecv.c:87
        rv = <value optimized out>
        arv = <value optimized out>
#4  0xf7f5b997 in socket_bucket_read (a=0x8521fb8, str=0xff8263b8, len=0xff8263b4, block=APR_BLOCK_READ)
    at buckets/apr_buckets_socket.c:36
        p = (apr_socket_t *) 0x8511f40
        buf = 0x8525f60 "\r\nNNECT localhost:5555 HTTP/1.0\r\n"
        rv = <value optimized out>
        timeout = <value optimized out>
#5  0x08083882 in ap_core_input_filter (f=0x85126d0, b=0x855a650, mode=AP_MODE_READBYTES, block=APR_BLOCK_READ,
    readbytes=8192) at core_filters.c:242
        e = (apr_bucket *) 0x8521fb8
        e = <value optimized out>
        rv = <value optimized out>
        net = <value optimized out>
        ctx = (core_ctx_t *) 0x8512700
        str = <value optimized out>
        len = <value optimized out>
#6  0x080bceae in logio_in_filter (f=0x85126a8, bb=0x855a650, mode=AP_MODE_READBYTES, block=APR_BLOCK_READ,
    readbytes=4294966780) at mod_logio.c:125
        length = -580820504886116352
        status = <value optimized out>
#7  0x080e7ce9 in ap_discard_request_body (r=0x8523f88) at http_filters.c:1345
        bucket = (apr_bucket *) 0x8523f88
        bb = (apr_bucket_brigade *) 0x855a650
        rv = 139607944
#8  0x08077472 in ap_finalize_request_protocol (r=0x8523f88) at protocol.c:1141
No locals.
#9  0x080e75a8 in ap_process_async_request (r=0x8523f88) at http_request.c:329
        c = (conn_rec *) 0x85120d8
        access_status = 0
#10 0x080e762d in ap_process_request (r=0x8523f88) at http_request.c:346
        bb = <value optimized out>
        b = <value optimized out>
        c = (conn_rec *) 0x85120d8
        rv = <value optimized out>
#11 0x080e44aa in ap_process_http_connection (c=0x85120d8) at http_core.c:194
No locals.
#12 0x0808b8f9 in ap_run_process_connection (c=0x85120d8) at connection.c:41
        n = 0
        rv = 300000
#13 0x0811e363 in child_main (child_num_arg=<value optimized out>) at prefork.c:660
        current_conn = <value optimized out>
        csd = (void *) 0x8511f40
        thd = (apr_thread_t *) 0x850ff38
        osthd = 4157912816
        ptrans = (apr_pool_t *) 0x8511f00
        allocator = (apr_allocator_t *) 0x8465440
        status = <value optimized out>
        i = <value optimized out>
        lr = <value optimized out>
        pollset = (apr_pollset_t *) 0x8510190
        sbh = (ap_sb_handle_t *) 0x8510188
        bucket_alloc = (apr_bucket_alloc_t *) 0x8521f40
        last_poll_idx = 0
#14 0x0811e6a3 in make_child (s=0x83ea9b0, slot=0) at prefork.c:754
No locals.
#15 0x0811ee1a in prefork_run (_pconf=0x83df0a8, plog=0x845b408, s=0x83ea9b0) at prefork.c:772
        index = <value optimized out>
        remaining_children_to_start = 5
        rv = <value optimized out>
#16 0x080726d7 in ap_run_mpm (pconf=0x83df0a8, plog=0x845b408, s=0x83ea9b0) at mpm_common.c:88
        n = 0
        rv = 300000
#17 0x0806dcb4 in main (argc=138326344, argv=0x845b408) at main.c:782
        c = 0 '\0'
        configtestonly = 0
        showcompile = 0
        confname = 0x8120df9 "conf/httpd.conf"
        def_server_root = 0x8120e09 "/usr/local/apache2"
        temp_error_log = 0x0
        error = <value optimized out>
        process = (process_rec *) 0x83dd130
        pconf = (apr_pool_t *) 0x83df0a8
        plog = (apr_pool_t *) 0x845b408
        ptemp = (apr_pool_t *) 0x83eb148
        pcommands = (apr_pool_t *) 0x83e1120
        opt = (apr_getopt_t *) 0x83e11c0
        rv = 135581348
        mod = (module **) 0x814cea4
        optarg = 0xf7e68a09 "\201???\003"
Comment 88 Stefan Fritsch 2009-09-12 15:28:32 UTC
Created attachment 24252 [details]
Close backend connection when client disconnects

This patch fixes the first of the two issues above.
Comment 89 Ruediger Pluem 2009-09-13 04:18:36 UTC
(In reply to comment #88)
> Created an attachment (id=24252) [details]
> Close backend connection when client disconnects
> 
> This patch fixes the first of the two issues above.

Thanks for the patch, but the key question that needs to be answered first and that I already posted on dev@ is: Why don't we stick with direct socket communication with the backend, but wrap a connection around it.
Comment 90 Graham Leggett 2009-09-13 04:28:51 UTC
I would argue for the exact opposite - if you're using a connection to communicate on the front, then use a connection to communicate on the back. Mixing the two is ugly, as the comment in the original code (now removed as it is fixed) stated.
Comment 91 Ruediger Pluem 2009-09-13 04:39:09 UTC
(In reply to comment #90)
> I would argue for the exact opposite - if you're using a connection to
> communicate on the front, then use a connection to communicate on the back.
> Mixing the two is ugly, as the comment in the original code (now removed as it
> is fixed) stated.

Moving over to dev@ where it belongs.
Comment 92 Lionel VICTOR 2009-09-13 13:00:04 UTC
(In reply to comment #86)
> Applied to httpd-trunk in r813178, can you test and verify it works on trunk?

As far as I'm concerned, the version in trunk works. I haven't tested it as thoroughly as what is described in Comment #87 though.

What Stefan Fritsch writes reminds me of something I read... I though it was fixed in the patch I proposed... I guess I was wrong. Sorry about that.

I have a frequent use of the patch but it is set up on low bandwidth server with very few authenticated clients. Never setup a test environment for the patch.


About the other issue (Why don't we stick with direct socket communication with the backend)... well... my answer would be that if we use SSL that's probably because we do not want that traffic in clear...so having apache ignoring our security policy and replying directly into the socket hence bypassing the ssl layer is not nice (and IS buggy). I admit that the security issue is not a deadly one though :o) ! (but well... with some time and pain... that may be a nice door to something... use it as an oracle or... Shame I don't have time to dig and think about it...)
Comment 93 Ruediger Pluem 2009-09-13 13:55:29 UTC
(In reply to comment #92)
> (In reply to comment #86)

> About the other issue (Why don't we stick with direct socket communication with
> the backend)... well... my answer would be that if we use SSL that's probably
> because we do not want that traffic in clear...so having apache ignoring our
> security policy and replying directly into the socket hence bypassing the ssl
> layer is not nice (and IS buggy). I admit that the security issue is not a
> deadly one though :o) ! (but well... with some time and pain... that may be a
> nice door to something... use it as an oracle or... Shame I don't have time to
> dig and think about it...)

I still see confusion here over my comment. So I try to rephrase it:
The old code uses direct socket communication to the client *and* to the backend.
In order to get the connection to the client encrypted the communication to the client needed to be changed to go through the httpd connection filter stack which
brings mod_ssl and its features in the game. I don't argue with this.
My point is the communication to the backend: There is *no* SSL encryption from httpd side here, on the contrary it is explicitly turned off by calling ap_proxy_ssl_disable(backconn). So where is the point of shoving all the data through the filter stack when we do *not* want the filters to touch the data?
Comment 94 Brad Boyer 2009-09-13 16:08:08 UTC
(In reply to comment #93)
> The old code uses direct socket communication to the client *and* to the
> backend.
> In order to get the connection to the client encrypted the communication to the
> client needed to be changed to go through the httpd connection filter stack
> which
> brings mod_ssl and its features in the game. I don't argue with this.
> My point is the communication to the backend: There is *no* SSL encryption from
> httpd side here, on the contrary it is explicitly turned off by calling
> ap_proxy_ssl_disable(backconn). So where is the point of shoving all the data
> through the filter stack when we do *not* want the filters to touch the data?

As the author of the first version of the patch, I'd like to add some justification. There were two reasons I considered for wanting the full connection and filter stack on the back connection.

The original reason is that I liked the symmetry of it. That's not a great justification, but it really is why I did it that way initially.

After some thought, I realized it should be possible to allow SSL on the backconn as well. However, I didn't really have the time to spend doing that properly. It would have needed some extra care to make sure that the backconn was only SSL when that was desired. I was too lazy to do the more complete set of work that would have allowed that, but I didn't want to make it harder for someone in the future.

The original usage I had was one where the httpd setup was effectively being used as a poor man's VPN. Because of this, the link from the real client to the proxy in httpd was untrusted, but everything behind it was trusted. Other people might want to use it as a proxy with untrusted networks on both sides. I'm sure that's a relatively obscure usage by comparison, but it should be possible with a few more changes.
Comment 95 Ivan Krivyakov 2009-11-25 10:31:36 UTC
Created attachment 24615 [details]
Patch for version 2.2.14

This is a patch for version 2.2.14. It is more or less mechanically derived from the 2.2.11 patch. I compiled this version and it seems to work fine for me.
Comment 96 Ivan Krivyakov 2009-11-25 10:38:37 UTC
Created attachment 24616 [details]
Win32 binary for patched version 2.2.14

Compiled patched version 2.2.14. It is installed on my server and seems to work OK.
Comment 97 Kevin Croft 2009-11-28 08:33:26 UTC
(In reply to comment #95)
> Created an attachment (id=24615) [details]
> Patch for version 2.2.14
> 
> This is a patch for version 2.2.14. It is more or less mechanically derived
> from the 2.2.11 patch. I compiled this version and it seems to work fine for
> me.

Have you tried applying this patch to the 2.2.14 sources?

# wget -O - http://apache.mirror.rafal.ca/httpd/httpd-2.2.14.tar.bz2 | tar jx
# cd httpd-2.2.14/modules/proxy
# curl https://issues.apache.org/bugzilla/attachment.cgi?id=24615 | patch -p1 --verbose

Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- 2.2.14/mod_proxy_connect.c 2009-11-22 00:24:14.762000000 -0500
|+++ 2.2.14-new/mod_proxy_connect.c     2009-11-22 00:29:27.954000000 -0500
--------------------------
Patching file mod_proxy_connect.c using Plan A...
Hunk #1 FAILED at 21.
Hunk #2 FAILED at 73.
Hunk #3 FAILED at 125.
Hunk #4 FAILED at 208.
Hunk #5 FAILED at 253.
Hunk #6 FAILED at 314.
Hunk #7 FAILED at 326.
Hunk #8 FAILED at 351.
Hunk #9 FAILED at 369.
Hunk #10 FAILED at 379.
Hunk #11 FAILED at 420.
11 out of 11 hunks FAILED -- saving rejects to file mod_proxy_connect.c.rej
done
Comment 98 Ivan Krivyakov 2009-11-28 21:02:20 UTC
(In reply to comment #97)
> 
> Have you tried applying this patch to the 2.2.14 sources?
>

Hm... Yes I have. Can't get to it now, but I will investigate ASAP.
Comment 99 Colin Dean 2009-11-29 07:20:58 UTC
Can I just put in another plea that this patch be incorporated into the 2.2 stream, so people don't have to keep updating it and re-applying it.

In my case I'm using it with a browser based application that provides web access to VNC consoles of virtual machines.  The user sees the available machines in a conventional dynamic web page, and when selecting a console to view, a Java applet is run.  With this patch, the VNC (RFB) connection can be securely tunneled over the same HTTPS connection as the main page - without it lots of VNC ports have to be opened to the outside world.

Although I can patch my Apache installation, I have users of the same application in other organizations who want to use a standard distribution and aren't comfortable patching and recompiling.

By the way, I'm also puzzling over the best way to enable HTTP CONNECT proxying but not generic HTTP 0.9/1.0/1.1, AJP13 and FTP.  The best I've managed so far is:

  ProxyRequests On
  AllowCONNECT 5900

  <ProxyMatch /.*/>
    Order deny,allow
    Deny from all
  </ProxyMatch>

which does seem to allow CONNECT proxying only, because the ProxyMatch doesn't seem to match this (unlike <Proxy *>, which matches all kinds of forward proxying).  But this seems very ugly!  I guess I'm looking for a <ProxyMatchProtocol> feature.
Comment 100 Ivan Krivyakov 2009-11-29 10:55:12 UTC
> 
> Have you tried applying this patch to the 2.2.14 sources?
>
> # wget -O - http://apache.mirror.rafal.ca/httpd/httpd-2.2.14.tar.bz2 | tar jx
> # cd httpd-2.2.14/modules/proxy
> # curl https://issues.apache.org/bugzilla/attachment.cgi?id=24615 | patch -p1
> --verbose
>

I have double-checked it -- it works fine with Win32 sources.

unzip httpd-2.2.14-win32-src.zip 
cd httpd-2.2.14\modules\proxy  
patch -p1 <mod_proxy_connect.patch 

patching file mod_proxy_connect.c

The resulting file is identical to my modified version, so the patch worked. 

It could be the end-of-line thing, GNU patch.exe for Windows insists on line endings to be /r/n, so this is what went into the patch file. I don't have a Linux instance handy to check this.
Comment 101 Kevin Croft 2009-11-30 22:03:28 UTC
(In reply to comment #100)
> > 
> > Have you tried applying this patch to the 2.2.14 sources?
> >
> > # wget -O - http://apache.mirror.rafal.ca/httpd/httpd-2.2.14.tar.bz2 | tar jx
> > # cd httpd-2.2.14/modules/proxy
> > # curl https://issues.apache.org/bugzilla/attachment.cgi?id=24615 | patch -p1
> > --verbose
> >
> 
> I have double-checked it -- it works fine with Win32 sources.
> 
> unzip httpd-2.2.14-win32-src.zip 
> cd httpd-2.2.14\modules\proxy  
> patch -p1 <mod_proxy_connect.patch 
> 
> patching file mod_proxy_connect.c
> 
> The resulting file is identical to my modified version, so the patch worked. 
> 
> It could be the end-of-line thing, GNU patch.exe for Windows insists on line
> endings to be /r/n, so this is what went into the patch file. I don't have a
> Linux instance handy to check this.

Ivan, that was it. Converted the patch using 'dos2unix', and it applies cleanly to the generic sources httpd-2.2.14.tar.bz2. Thanks again for the patch, and sorry for the false alarm!
Comment 102 somebody 2009-12-12 20:04:19 UTC
I tried the patch.

Patch applied successfully but it still does not work with SSL.

This is my configuration in httpd.conf
#=====================================================
<VirtualHost 123.123.123.123:443>
ServerName lol.mydomain.com
SSLEngine on
SSLCertificateFile /root/SSL/ssh-proxy/server.crt
SSLCertificateKeyFile /root/SSL/ssh-proxy/server.key

CustomLog "/root/empty/ssh-access.log" common
ErrorLog "/root/empty/ssh-error.log"

HostnameLookups On
ProxyRequests on
AllowCONNECT 22 2022
ProxyVia on

<ProxyMatch lol.mydomain.com>
Order deny,allow
Deny from all
Allow from 59.93
</ProxyMatch>
</VirtualHost> 
#=====================================================

It works if I disable SSL
Comment 103 Stefan Fritsch 2010-03-17 20:10:38 UTC
Comment on attachment 24252 [details]
Close backend connection when client disconnects

patch commited as r924455
Comment 104 Julian Gilbey 2010-03-24 01:45:53 UTC
(In reply to comment #103)
> (From update of attachment 24252 [details])
> patch commited as r924455

What is this for?  Is it relevant to this bug (about mod_proxy CONNECT forwarding over SSL connections?)

Julian
Comment 105 Julian Gilbey 2010-03-24 01:45:55 UTC
(In reply to comment #103)
> (From update of attachment 24252 [details])
> patch commited as r924455

What is this for?  Is it relevant to this bug (about mod_proxy CONNECT forwarding over SSL connections?)

Julian
Comment 106 William A. Rowe Jr. 2010-03-24 04:05:58 UTC
Just a typo... see

http://svn.apache.org/viewvc?view=revision&revision=813178

that would be the fix, no?  Please validate against 2.2.15 before reopening.
Comment 107 William A. Rowe Jr. 2010-03-24 04:43:33 UTC
That was the patch, it is not backported, here is the log to watch;

http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/modules/proxy/mod_proxy_connect.c?view=log
Comment 108 Julian Gilbey 2010-03-24 12:21:29 UTC
Indeed, it has not been backported to 2.2.x.  Furthermore, some change between 2.2.14 and 2.2.15 has meant that, even applying the patch attached to this report to 2.2.15, CONNECTing over SSL now drops the connection very quickly, say after about 15-100 keystrokes and data transfers, making it fairly unusable.

I have no idea what has caused this, or whether it is not in apache.

Julian
Comment 109 Stefan Fritsch 2010-03-28 22:23:25 UTC
(In reply to comment #105)
> (In reply to comment #103)
> > (From update of attachment 24252 [details] [details])
> > patch commited as r924455
> 
> What is this for?  Is it relevant to this bug (about mod_proxy CONNECT
> forwarding over SSL connections?)

It fixes the first of the two issues described in comment 87:

> 1) If the client disconnects and the backend continues to send data fast, the
> backend connection will be closed only after a long time, if at all. 

I expect that the second issue is still there, but I haven't checked:

> 2) If the backend closes the connection, but the client doesn't, the apache
> thread hangs and will not close the connection to the client.
Comment 110 Stefan Fritsch 2010-03-28 22:25:56 UTC
(In reply to comment #108)
> Indeed, it has not been backported to 2.2.x.  Furthermore, some change between
> 2.2.14 and 2.2.15 has meant that, even applying the patch attached to this
> report to 2.2.15, CONNECTing over SSL now drops the connection very quickly,
> say after about 15-100 keystrokes and data transfers, making it fairly
> unusable.

If you have mod_reqtimeout enabled, that's probably (another) bug there. I will look at it when I have time.
Comment 111 Julian Gilbey 2010-03-28 23:05:54 UTC
Yes, I have mod_reqtimeout enabled.  I'll try disabling this and see what happens...

Thanks for the idea!

Julian
Comment 112 Mark Nieuwenhuis 2010-03-30 14:39:53 UTC
(In reply to comment #109)
> (In reply to comment #105)
> > (In reply to comment #103)
> > > (From update of attachment 24252 [details] [details] [details])
> > > patch commited as r924455
> > 
> > What is this for?  Is it relevant to this bug (about mod_proxy CONNECT
> > forwarding over SSL connections?)
> 
> It fixes the first of the two issues described in comment 87:
> 
@Stefan: I am working with Apache 2.2.15 on a Windows environment. I have
no idea how to compile this patch. Would it be possible for you to post
the binary mod_proxy.so file?
Many thanks in advance.
Comment 113 nings 2010-07-21 15:54:06 UTC
The patch for version 2.2.9 worked very well but after update on a debian lenny. I have an error again : Error on auth.log : sshd[6042]: Bad protocol version identification '\025TT' from 127.0.0.1

Change during this update :

Setting up cpio (2.9-13lenny1) ...^M
Setting up libssl0.9.8 (0.9.8g-15+lenny7) ...^M
Setting up libssl-dev (0.9.8g-15+lenny7) ...^M
Setting up nano (2.0.7-5) ...^M
Setting up libapr1 (1.2.12-5+lenny2) ...^M
Setting up apache2-utils (2.2.9-10+lenny8) ...^M
Setting up apache2.2-common (2.2.9-10+lenny8) ...^M
Setting up apache2-mpm-prefork (2.2.9-10+lenny8) ...^M
Starting web server: apache2.^M
Setting up apache2 (2.2.9-10+lenny8) ...^M
Setting up libgtk2.0-common (2.12.12-1~lenny2) ...^M
Setting up libxext6 (2:1.0.4-2) ...^M
Setting up libgtk2.0-0 (2.12.12-1~lenny2) ...^M
Setting up libgtk2.0-bin (2.12.12-1~lenny2) ...^M
Setting up libpoppler3 (0.8.7-3.1) ...^M
Setting up libpoppler-qt4-3 (0.8.7-3.1) ...^M
Setting up linux-headers-2.6.26-2-common (2.6.26-24) ...^M
Setting up linux-headers-2.6.26-2-686 (2.6.26-24) ...^M
Setting up linux-libc-dev (2.6.26-24) ...^M
Setting up openssl (0.9.8g-15+lenny7) ...^M
Setting up python-support (0.8.4lenny2) ...^M
Setting up usbutils (0.73-10lenny2) ...^M

I have read the patch note and say that fixed something in mod_proxy.
Someone have the same problem with this version and Lenny ?
Comment 114 Lionel VICTOR 2010-07-22 17:44:29 UTC
(In reply to comment #113)

Not sure I get what you did... You patched apache then updated your distro ?
If I get it right, that defeats the point totally. The update obviously swept away your patching... Sorry it seems so stupid : I must be missing something.

BTW I still don't get what is missing with the proposed work-around and why it does not make its way into the trunk ?
Can someone who understands the details of the patch summarize what regression it could bring ? And why after all this time it did not officially passed to production ?

I tried to push it back to the developpers mailing list at some point but got only few answers from very busy guys... Then I've been busy myself and got flooded by the mail flow on the list. I could not keep the pace and stopped reading/waiting for someone to actually look into the patch from there...

Cheers,
Lionel

> The patch for version 2.2.9 worked very well but after update on a debian
> lenny. I have an error again : Error on auth.log : sshd[6042]: Bad protocol
> version identification '\025TT' from 127.0.0.1
> 
> Change during this update :
> 
> Setting up cpio (2.9-13lenny1) ...^M
> Setting up libssl0.9.8 (0.9.8g-15+lenny7) ...^M
> Setting up libssl-dev (0.9.8g-15+lenny7) ...^M
> Setting up nano (2.0.7-5) ...^M
> Setting up libapr1 (1.2.12-5+lenny2) ...^M
> Setting up apache2-utils (2.2.9-10+lenny8) ...^M
> Setting up apache2.2-common (2.2.9-10+lenny8) ...^M
> Setting up apache2-mpm-prefork (2.2.9-10+lenny8) ...^M
> Starting web server: apache2.^M
> Setting up apache2 (2.2.9-10+lenny8) ...^M
> Setting up libgtk2.0-common (2.12.12-1~lenny2) ...^M
> Setting up libxext6 (2:1.0.4-2) ...^M
> Setting up libgtk2.0-0 (2.12.12-1~lenny2) ...^M
> Setting up libgtk2.0-bin (2.12.12-1~lenny2) ...^M
> Setting up libpoppler3 (0.8.7-3.1) ...^M
> Setting up libpoppler-qt4-3 (0.8.7-3.1) ...^M
> Setting up linux-headers-2.6.26-2-common (2.6.26-24) ...^M
> Setting up linux-headers-2.6.26-2-686 (2.6.26-24) ...^M
> Setting up linux-libc-dev (2.6.26-24) ...^M
> Setting up openssl (0.9.8g-15+lenny7) ...^M
> Setting up python-support (0.8.4lenny2) ...^M
> Setting up usbutils (0.73-10lenny2) ...^M
> 
> I have read the patch note and say that fixed something in mod_proxy.
> Someone have the same problem with this version and Lenny ?
Comment 115 Lionel VICTOR 2010-07-22 17:46:03 UTC
(In reply to comment #113)

Not sure I get what you did... You patched apache then updated your distro ?
If I get it right, that defeats the point totally. The update obviously swept away your patching... Sorry it seems so stupid : I must be missing something.

BTW I still don't get what is missing with the proposed work-around and why it does not make its way into the trunk ?
Can someone who understands the details of the patch summarize what regression it could bring ? And why after all this time it did not officially passed to production ?

I tried to push it back to the developpers mailing list at some point but got only few answers from very busy guys... Then I've been busy myself and got flooded by the mail flow on the list. I could not keep the pace and stopped reading/waiting for someone to actually look into the patch from there...

Cheers,
Lionel

> The patch for version 2.2.9 worked very well but after update on a debian
> lenny. I have an error again : Error on auth.log : sshd[6042]: Bad protocol
> version identification '\025TT' from 127.0.0.1
> 
> Change during this update :
> 
> Setting up cpio (2.9-13lenny1) ...^M
> Setting up libssl0.9.8 (0.9.8g-15+lenny7) ...^M
> Setting up libssl-dev (0.9.8g-15+lenny7) ...^M
> Setting up nano (2.0.7-5) ...^M
> Setting up libapr1 (1.2.12-5+lenny2) ...^M
> Setting up apache2-utils (2.2.9-10+lenny8) ...^M
> Setting up apache2.2-common (2.2.9-10+lenny8) ...^M
> Setting up apache2-mpm-prefork (2.2.9-10+lenny8) ...^M
> Starting web server: apache2.^M
> Setting up apache2 (2.2.9-10+lenny8) ...^M
> Setting up libgtk2.0-common (2.12.12-1~lenny2) ...^M
> Setting up libxext6 (2:1.0.4-2) ...^M
> Setting up libgtk2.0-0 (2.12.12-1~lenny2) ...^M
> Setting up libgtk2.0-bin (2.12.12-1~lenny2) ...^M
> Setting up libpoppler3 (0.8.7-3.1) ...^M
> Setting up libpoppler-qt4-3 (0.8.7-3.1) ...^M
> Setting up linux-headers-2.6.26-2-common (2.6.26-24) ...^M
> Setting up linux-headers-2.6.26-2-686 (2.6.26-24) ...^M
> Setting up linux-libc-dev (2.6.26-24) ...^M
> Setting up openssl (0.9.8g-15+lenny7) ...^M
> Setting up python-support (0.8.4lenny2) ...^M
> Setting up usbutils (0.73-10lenny2) ...^M
> 
> I have read the patch note and say that fixed something in mod_proxy.
> Someone have the same problem with this version and Lenny ?
Comment 116 Ivan Krivyakov 2010-07-23 09:54:55 UTC
(In reply to comment #115)
In a nutshell, in standard Apache distribution, proxy functionality (CONNECT request) does not work when connecting via HTTPS. Some people argue this is by design, because it is not in the RFC. Other people say this is useful and not prohibited by the RFC, so it should be included.

Current status quo is that this feature is not in the Apache trunk, and if someone needs it, they have to apply a patch to their version of Apache, or port a patch from an older version.

I believe that if this feature is included in the trunk, it would be THE GOOD THING. I will make the server more useful and will alleviate the need for patches, thus improving security and stability.
Comment 117 Stefan Fritsch 2010-07-27 16:49:35 UTC
(In reply to comment #116)
> Current status quo is that this feature is not in the Apache trunk

That's not correct. It is in trunk, it is in 2.3.6-alpha and it will be in 2.4 (unless some severe issues are found).
Comment 118 Sergey Anufrienko 2010-10-29 05:13:37 UTC
Created attachment 26225 [details]
Port of pach from 2.2.14 to 2.2.16/2.2.17
Comment 119 Evgeny.Sabelskiy 2010-12-21 18:16:18 UTC
*** Bug 50508 has been marked as a duplicate of this bug. ***
Comment 120 Ubik 2010-12-27 10:43:38 UTC
(In reply to comment #118)
> Created an attachment (id=26225) [details]
> Port of pach from 2.2.14 to 2.2.16

I tried this patch on debian squeeze(apache 2.2.16-4) and still get error:
ssh_exchange_identification: Connection closed by remote host
Comment 121 Ubik 2010-12-27 10:45:33 UTC
(In reply to comment #118)
> Created an attachment (id=26225) [details]
> Port of pach from 2.2.14 to 2.2.16

I tried this patch on debian squeeze(apache 2.2.16-4) and still get error:
ssh_exchange_identification: Connection closed by remote host
Comment 122 patrick camus 2011-01-04 04:08:57 UTC
Patch from Sergey Anufrienko work successfully for me with Apache 2.2.16 on ubuntu Maverik. I can now use the SSL layer.
Cheers.
Comment 123 Laurent 2011-02-20 11:30:06 UTC
What would be required in order to get this patch backported to the current official stable branch (2.2)?
Comment 124 jonathan 2011-05-16 07:48:40 UTC
Is this patch in 2.2.16? I'm running the latest possible apache on the latest debian, and this bug still appears to be there. Its so strange that there seems to have been a fix for years and still the popular version of apache doesn't support this in its trunk. Pleeeeeeaaase Pleaaase help? What will it take to get this in 2.2 and into the latest debian? Money? My first born? Community Service? Please please please, I'm begging for this bug to be fixed after years.
Comment 125 Sergey Anufrienko 2011-05-16 07:52:30 UTC
See above, the patch for this bug is in 2.3.6-alpha and it will be in 2.4
(unless some severe issues are found).
Comment 126 Tom 2011-05-28 05:14:19 UTC
When I try to use the above 2.2.14 fix (or 2.2.8 fix) with Apache on Win32, I get a "incoming packet garbled on decryption" error in putty.

Would it be possible to compile a win32 port of this patch for the latest version 2.2.19?

Currently I am copying mod_proxy_connect.so into the modules directory and restarting the apache service. Is this correct?

Thanks everyone.
Comment 127 Stefan Fritsch 2012-02-26 16:34:03 UTC
fixed in 2.4.1
Comment 128 Sri 2012-03-08 19:10:08 UTC
(In reply to comment #127)
> fixed in 2.4.1

I got the Win 32 version of 2.4.1 because I need this funcitonality discussed on this thread - CONNECT method over HTTPS (connecting to mod_proxy over HTTPS/SSL connection)Can someone please tell me how to configure httpd for this? I am fairly new to httpd and mod_proxy. I have this so far:

<VirtualHost _default_:443>

CustomLog "C:/Sri/installs/httpd-2.4.1-win32-ssl_0.9.8t/Apache24/logs/ssl_request.log" \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

ServerName sbasavanahal-xp.rim.net
HostnameLookups On
ProxyRequests on
AllowCONNECT 443
ProxyVia On
<Proxy *>
	
  Order deny,allow
  Allow from all
  AuthType Basic
  AuthName "Password Required"
  AuthBasicAuthoritative On
  AuthUserFile password.file
  Require user admin
</Proxy>

SSLEngine on
SSLCertificateFile "C:/Sri/installs/httpd-2.4.1-win32-ssl_0.9.8t/Apache24/conf/apache.crt"
SSLCertificateKeyFile "C:/Sri/installs/httpd-2.4.1-win32-ssl_0.9.8t/Apache24/conf/apache2.key"
</VirtualHost>

With this I get apache listening on SSL, but CONNECT does not seem to work over SSL.

Thanks for any help.
Comment 129 Stefan Fritsch 2012-03-19 20:06:40 UTC
(In reply to comment #128)
> I got the Win 32 version of 2.4.1 because I need this funcitonality discussed
> on this thread - CONNECT method over HTTPS (connecting to mod_proxy over
> HTTPS/SSL connection)Can someone please tell me how to configure httpd for
> this? I am fairly new to httpd and mod_proxy. I have this so far:

> With this I get apache listening on SSL, but CONNECT does not seem to work over
> SSL.

There should not be any configuration necessary besides what you have. Please consult a user mailing list to sort out the details.
Comment 130 Ivan Krivyakov 2012-07-18 01:35:17 UTC
Created attachment 29072 [details]
Port of the patch to Apache 2.2.22 (Win32)

I just compiled Apache with Visual Studio 2010 and applied the patch. Seems to work fine. 

IMPORTANT: since this is a VS2010 compilation, it depends on MSVCR100.DLL, which you may or may not have on your system. If you don't, Apache won't start claiming it cannot load the module.
Comment 131 Michal 2012-11-14 15:45:56 UTC
(In reply to comment #130)
> Created attachment 29072 [details]
> Port of the patch to Apache 2.2.22 (Win32)
> 
> I just compiled Apache with Visual Studio 2010 and applied the patch. Seems
> to work fine. 
> 
> IMPORTANT: since this is a VS2010 compilation, it depends on MSVCR100.DLL,
> which you may or may not have on your system. If you don't, Apache won't
> start claiming it cannot load the module.

Can you attach your patch for 2.2.22 please
Comment 132 matjes 2012-12-15 15:18:52 UTC
(In reply to comment #95)
> Created attachment 24615 [details]
> Patch for version 2.2.14
> 
> This is a patch for version 2.2.14. It is more or less mechanically derived
> from the 2.2.11 patch. I compiled this version and it seems to work fine for
> me.

I applied this patch in debian squeeze for version 2.2.16-6+squeeze10. However I get the error

Bad packet length 1349676916.
Disconnecting: Packet corrupt


More precisely:

> ssh -vv host
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug2: ssh_connect: needpriv 0
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: permanently_drop_suid: 1000
debug1: ssh_exchange_identification: HTTP/1.0 200 Connection Established


debug1: ssh_exchange_identification: Proxy-agent: Apache/2.2.16 (Debian)


debug1: ssh_exchange_identification: 


debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze2
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
debug2: fd 5 setting O_NONBLOCK
debug2: fd 4 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Bad packet length 1349676916.
Disconnecting: Packet corrupt


Does anyone have an idea how to fix this?
Thank you very much.
Comment 133 Dmitry 2012-12-21 00:34:59 UTC
You're trying HTTP with SSH client? Hm...
Try this:
$ openssl s_client -connect localhost:443
CONNECT thathost:25
Or this:
$ proxytunnel -E -v -p localhost:443 -d thathost:25

Patch works OK for Debian Apache 2.2.22-12.
Comment 134 lars 2013-04-03 19:16:03 UTC
Does anyone have a patch for Apache 2.2.22 (Linux)?
Comment 135 Julian Gilbey 2013-04-03 19:24:58 UTC
Created attachment 30144 [details]
Patch for Apache 2.2.22 (tested on Linux machine against the Debian version of apache; should work on vanilla apache too)
Comment 136 lars 2013-04-03 20:26:56 UTC
Thanks!

But do I have to recompile Apache completely for this? Or is there any chance I can just recompile mod_proxy_connect and then replace mod_proxy_connect.so by the patched version?
Comment 137 Julian Gilbey 2013-04-03 22:34:38 UTC
(In response to comment 136.)

You could possibly just recompile that one module, but the effort required to find the correct build flags and to compile any dependencies and so on seems to be excessive.  Assuming that you're working with a standard Linux distribution (Debian or a derivative or Red Hat or a derivative or similar), you should be able to download the source package, patch the file and then rebuild it; the effort required is minimal.

On Debian, you can do something like the following, assuming that you have a line such as:
  deb-src http://ftp.debian.org/debian/ testing main
in your /etc/apt/sources.list; here '#' indicates commands to be run as root (if you have a more complex setup, such as with chroots, you will know what you are doing!):

~ # aptitude install build-essential fakeroot quilt devscripts
~ # aptitude build-dep apache2
~ $ cd /tmp
/tmp $ apt-get source apache2
/tmp $ cd apache2-2.2.22
/tmp/apache2-2.2.22 $ quilt new 999_mod_proxy.patch
/tmp/apache2-2.2.22 $ quilt add modules/proxy/mod_proxy_connect.c
/tmp/apache2-2.2.22 $ patch -p1 < /tmp/999_mod_proxy   # or whatever you've called the patch file you download from this bug report
/tmp/apache2-2.2.22 $ quilt refresh
/tmp/apache2-2.2.22 $ dch --nmu 'Apply mod-proxy patch'
/tmp/apache2-2.2.22 $ debuild -us -uc
~ # dpkg -i /tmp/apache2_2.2.22-13.1_*.deb ...    # list all of the .deb files you wish to install - this should be every apache2-derived package that you have installed, so that the versions correctly match

HTH,

Julian
Comment 138 lars 2013-04-04 16:32:08 UTC
(In reply to comment #137)
> (In response to comment 136.)
> 
> You could possibly just recompile that one module, but the effort required
> to find the correct build flags and to compile any dependencies and so on
> seems to be excessive.  Assuming that you're working with a standard Linux
> distribution (Debian or a derivative or Red Hat or a derivative or similar),
> you should be able to download the source package, patch the file and then
> rebuild it; the effort required is minimal.
> 
> On Debian, you can do something like the following, assuming that you have a
> line such as:
>   deb-src http://ftp.debian.org/debian/ testing main
> in your /etc/apt/sources.list; here '#' indicates commands to be run as root
> (if you have a more complex setup, such as with chroots, you will know what
> you are doing!):
> 
> ~ # aptitude install build-essential fakeroot quilt devscripts
> ~ # aptitude build-dep apache2
> ~ $ cd /tmp
> /tmp $ apt-get source apache2
> /tmp $ cd apache2-2.2.22
> /tmp/apache2-2.2.22 $ quilt new 999_mod_proxy.patch
> /tmp/apache2-2.2.22 $ quilt add modules/proxy/mod_proxy_connect.c
> /tmp/apache2-2.2.22 $ patch -p1 < /tmp/999_mod_proxy   # or whatever you've
> called the patch file you download from this bug report
> /tmp/apache2-2.2.22 $ quilt refresh
> /tmp/apache2-2.2.22 $ dch --nmu 'Apply mod-proxy patch'
> /tmp/apache2-2.2.22 $ debuild -us -uc
> ~ # dpkg -i /tmp/apache2_2.2.22-13.1_*.deb ...    # list all of the .deb
> files you wish to install - this should be every apache2-derived package
> that you have installed, so that the versions correctly match
> 
> HTH,
> 
> Julian

Thank you for your excellent illustration! (I wasn't familiar with Debian patch/build utilities like quilt)

This solution works perfectly. I assume I have to repeat this for every new version of Apache released in Debian Wheezy until this patch is included?
Comment 139 Sergey Anufrienko 2013-04-04 16:35:31 UTC
This was fixed in 2.4, which is the current recommended branch.
Comment 140 Julian Gilbey 2013-04-04 16:47:37 UTC
Yes, this process needs doing for every new version of apache2 that Debian releases in the 2.2 series.  But unless there are security bugs, Debian will its next major release with 2.2.22-13 as the apache version (we are in deep freeze right now, and Debian 8.0 or whatever it is to be called will be released in the very near future).  In the meantime, apache 2.4.4 is waiting in experimental, and will probably be installed in unstable shortly thereafter, and that contains this patch as applied upstream.
Comment 141 Nikolaus Rath 2013-09-12 00:55:25 UTC
Hmm. When I test the above patch, I'm getting a different result:

$ gnutls-cli www.rath.org
[...]
- Handshake was completed

- Simple Client Mode:

CONNECT www.web.de:80 HTTP/1.0
Host: www.rath.org

HTTP/1.1 400 Bad Request
Date: Thu, 12 Sep 2013 00:52:24 GMT
Vary: Accept-Encoding
Content-Length: 293
Connection: close
Content-Type: text/html; charset=iso-8859-1

And the server log says:

[Thu Sep 12 00:52:29 2013] [error] Hostname www.rath.org provided via SNI and hostname www.web.de provided via HTTP are different

Has anyone else tried to use this with name based virtual TLS hosts? It looks as if Apache is trying to match the SNI with the host specified in CONNECT, rather than the one given in the host header.
Comment 142 Dmitry 2013-12-16 01:00:18 UTC
(In reply to Stefan Fritsch from comment #127)
> fixed in 2.4.1

I am testing Apache 2.4.6-3 (Debian):

$ proxytunnel.exe -v -X -p proxy:443 -d localhost:25
SSL local to remote proxy enabled
Local proxy proxy resolves to 10.15.2.100
Connected to proxy:443 (local proxy)

Tunneling to localhost:25 (destination)
Communication with local proxy:
 -> CONNECT localhost:25 HTTP/1.0
 -> Proxy-Connection: Keep-Alive
analyze_HTTP: readline failed: Connection closed by remote host

I have the same symptoms as without this patch being present in source. Can anyone confirm that 2.4 is really working?
Comment 143 Dmitry 2013-12-16 03:05:32 UTC
Sorry for my last comment: Apache 2.4.6 is working fine. I have forgotten to include "-E" switch:

proxytunnel.exe -v -E -p proxy:443 -d localhost:25
Comment 144 patrick camus 2014-03-26 20:45:17 UTC
Thanks to Julian Gilbey for the patch.
Works great for httpd.2.2.22 on Ubuntu precise.