connect method don't work if the client is connecting to the apache proxy through ssl socket.
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.
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.
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.
Created attachment 13393 [details] Use normal I/O routines in proxy_connect.c
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.
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.
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.
*** Bug 11232 has been marked as a duplicate of this bug. ***
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.
(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
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
(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.
(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.
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
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.
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.
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.
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.
(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.
"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.
"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.
(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.
(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.
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.
> 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).
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
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.
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.
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.
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. > >
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.
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.
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
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
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!
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!
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
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
Have you tried running proxytunnel with the -v (verbose) flag instead of -q to see exactly what is happening?
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?
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?
Created attachment 20331 [details] Fixed patch updated to 2.2.4
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.
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.
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.
Created attachment 20911 [details] Port of the patch from 2.2.4 to 2.2.6
(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
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.
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.
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...
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,
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 ?
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).
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 ?
(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.
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
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. >
(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.
Created attachment 21628 [details] Working patches for 2.2.4 and 2.2.6 with i686 dropin binaries.
(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.
@ 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
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.
(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.
Then guess, I'm on it. Thanks,
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
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,
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.
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
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
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.
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.
(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
(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
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 :(
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
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.
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
CC myself on FreeBSD related bugs
Works without modification now on 2.2.11 on Debian. A bit tired of waiting for this patch to be included...
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.
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.
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'.
(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'.
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.
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 !
Applied to httpd-trunk in r813178, can you test and verify it works on trunk?
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"
Created attachment 24252 [details] Close backend connection when client disconnects This patch fixes the first of the two issues above.
(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.
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.
(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.
(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...)
(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?
(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.
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.
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.
(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
(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.
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.
> > 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.
(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!
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 on attachment 24252 [details] Close backend connection when client disconnects patch commited as r924455
(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
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.
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
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
(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.
(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.
Yes, I have mod_reqtimeout enabled. I'll try disabling this and see what happens... Thanks for the idea! Julian
(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.
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 ?
(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 ?
(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.
(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).
Created attachment 26225 [details] Port of pach from 2.2.14 to 2.2.16/2.2.17
*** Bug 50508 has been marked as a duplicate of this bug. ***
(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
Patch from Sergey Anufrienko work successfully for me with Apache 2.2.16 on ubuntu Maverik. I can now use the SSL layer. Cheers.
What would be required in order to get this patch backported to the current official stable branch (2.2)?
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.
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).
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.
fixed in 2.4.1
(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.
(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.
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.
(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
(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.
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.
Does anyone have a patch for Apache 2.2.22 (Linux)?
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)
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?
(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
(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?
This was fixed in 2.4, which is the current recommended branch.
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.
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.
(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?
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
Thanks to Julian Gilbey for the patch. Works great for httpd.2.2.22 on Ubuntu precise.
So there is a set of patches that further correct the behavior of this enhancement http://home.apache.org/~ylavic/patches/httpd-2.2.x-mod_proxy_connect-transfer.patch I'd like to get this into 2.2.32 - is anyone who has deployed the patch above able to test this revised patch? The delta to the current 2.2.22 patch above, with the fixes to that patch already in 2.4, can be found here; http://home.apache.org/~ylavic/patches/httpd-2.2.x-mod_proxy_connect-transfer.patch I intend to tag 2.2.32 tomorrow, so confirmation of the net patch would be helpful.
One more ping, if anyone is still using httpd 2.2.31 and is interested in this patch finally making it into 2.2.32, please see new patch directions in Comment #145 and report your results back here over the next week? Thanks for your patience folks, glad we have this resolved on 2.4.x.
Correction, the proposed delta to the current 2.2.22 patch above, with the fixes to that patch already in 2.4, can be found here; http://home.apache.org/~ylavic/patches/mod_proxy_connect-id30144_vs_r1670324.diff The complete patch proposed for backport into 2.2.32 can be found at; http://home.apache.org/~ylavic/patches/httpd-2.2.x-mod_proxy_connect-transfer.patch This is the last call for review before the issue is dismissed and excluded from consideration for 2.2, we are still missing one reviewer.