You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Martin Kraemer <ma...@apache.org> on 2008/01/08 18:41:08 UTC

proxy-SSL-woes in 2.2.7 [was:Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available]

Okay, I found a new bug in the 2.2.7 proxy while testing SSL
and non-SSL CONNECTions both with and without a ProxyRemote
directive.

<verbose>
  To recap, totally different things happen in the presence or
  absence of a ProxyRemote:
  
  * with ProxyRemote, the web server acts as a forwarder, and
    connects to an "upstream" proxy in a proxy chain (speaking
    the HTTP protocol to it), 

  while

  * without ProxyRemote, the web server connects directly to the
    origin server, speaking the native protocol to it (i.e., speaking
    FTP when executing a ftp://originserver/ proxy URL, or
    simply tunnelling the net data when doing http:// or ssl
    CONNECT proxy requests)
</verbose>

In the test matrix, the forwarder situation was working allright.
The direct connection, however, breaks in SSL mode, and the
connection is closed by the 2.2.7 proxy too early (before
receiving the 1st response to the SSL CLIENT-HELLO).

The chunk_filter patch seems to improve the situation: the
connection "sometimes" succeeds. But in most cases, I get
(with a slightly patched openssl s_client that can use a
HTTP proxy):

--snip--
% openssl s_client -connect originserver:443 -proxy apacheproxy227:8227 -verify 0 -msg
verify depth is 0
HTTP/1.0 200 Connection Established
CONNECTED(00000005)
>>> SSL 2.0 [length 00c5], CLIENT-HELLO
    01 03 01 00 9c 00 00 00 20 00 c0 14 00 c0 0a 00
    00 39 00 00 38 00 00 88 00 00 87 00 c0 0f 00 c0
    05 00 00 35 00 00 84 00 c0 12 00 c0 08 00 00 16
    00 00 13 00 c0 0d 00 c0 03 00 00 0a 07 00 c0 00
    c0 13 00 c0 09 00 00 33 00 00 32 00 00 9a 00 00
    99 00 00 45 00 00 44 00 c0 0e 00 c0 04 00 00 2f
    00 00 96 00 00 41 00 00 07 05 00 80 03 00 80 00
    c0 11 00 c0 07 00 c0 0c 00 c0 02 00 00 05 00 00
    04 01 00 80 00 00 15 00 00 12 00 00 09 06 00 40
    00 00 14 00 00 11 00 00 08 00 00 06 04 00 80 00
    00 03 02 00 80 b8 a2 32 64 e5 0b 51 ae ec a1 2f
    f0 f9 6e b1 8f ab af 9c 97 c2 de a1 d4 f3 34 1d
    a9 c3 9c ef 10
38921:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:631:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 199 bytes
---
New, (NONE), Cipher is (NONE)
Compression: NONE
Expansion: NONE
---
--snip--

so the connection is closed before the response has arrived.
On the server side, the proxy_connect (with DEBUGGING) logs:

--snip--
[Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(145): proxy: CONNECT: connecting to remote host originserver
[Tue Jan 08 15:00:44 2008] [debug] proxy_util.c(1525): proxy: CONNECT: fam 2 socket created to connect to originserver
[Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(241): proxy: CONNECT: Returning 200 OK Status
[Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(262): proxy: CONNECT: setting up poll()
[Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(299): proxy: CONNECT: woke from select(), i=1
[Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(344): proxy: CONNECT: client was set
[Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(353): proxy: CONNECT: read 199 from client
[Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(299): proxy: CONNECT: woke from select(), i=1
[Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(344): proxy: CONNECT: client was set
[Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(371): proxy: CONNECT: client: apr_socket_recv() => rv=70014 = End of file found
[Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(404): proxy: CONNECT: finished with poll() - cleaning up
--snip--

so it gets an EOF when there should be more data available.

On Sun, Jan 06, 2008 at 07:47:03PM +0100, Ruediger Pluem wrote:
> 
> Ok, next one. I missed to set the correct state in some situations.
> Can you please give it a try again?

As I said, without this patch, the connection apparently never
succeeds. With the patch, *sometimes* it succeeds:

--snip--
HTTP/1.0 200 Connection Established
Proxy-agent: Apache/2.2.8-dev (Unix) mod_ssl/2.2.8-dev OpenSSL/0.9.7d-p1 DAV/2

CONNECTED(00000005)
>>> SSL 2.0 [length 00c5], CLIENT-HELLO
    01 03 01 00 9c 00 00 00 20 00 c0 14 00 c0 0a 00
    ...
    7c ef c1 73 83
<<< TLS 1.0 Handshake [length 004a], ServerHello
    02 00 00 46 03 01 47 83 b4 82 03 e4 d2 49 95 34
    ...
    0b 57 ce 53 cb c4 4f 00 16 00
<<< TLS 1.0 Handshake [length 0335], Certificate
    0b 00 03 31 00 03 2e 00 03 2b 30 82 03 27 30 82
    ...
    80 d2 18 87 92
...
SSL handshake has read 1367 bytes and written 389 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : EDH-RSA-DES-CBC3-SHA
    Session-ID: 6E931441168A6742E4155B0ED687B8CAA9CC3BC20E18B802A00B57CE53CBC44F
    Session-ID-ctx: 
    Master-Key: 98FE7321DCEE24063FE2B9B57DA8D534656FD85621E41F0985DEA84CCB9C68BD24BDB412DE7F701E4DA0E516E56FF326
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1199813762
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---
--snip--

Hmmm. The failure is reproduceable for me on both a ix86/FreeBSD
and a BS2000 machine.

   Martin
-- 
<Ma...@Fujitsu-Siemens.com>        |     Fujitsu Siemens
http://www.fujitsu-siemens.com/imprint.html | 81730  Munich,  Germany

Re: proxy-SSL-woes in 2.2.7 [was:Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available]

Posted by Martin Kraemer <ma...@apache.org>.
On Tue, Jan 08, 2008 at 08:37:10PM +0100, Ruediger Pluem wrote:
> 
> Very, very strange because in the SSL proxy forward case you
> 
> 1. use mod_proxy_connect which wasn't touched in 2.2.x for the last 11 month,
>    so I doubt that this is a regression-

I must confess that I have always tested the proxy as a forwarder,
and only found the bug now. It may have been lingering there for
a long time already.

> 2. The HTTP_IN filter does not do anything in the SSL proxy forward case (it
>    is not in the filter chain) as in contrast to non SSL proxying mod_proxy_connect
>    does not care about the contents of the backend at all and is a pure data pump
>    on TCP level.

Then perhaps the patch really did not change it at all, and
I only happened to get a few successful connections after having
tried the patch (and would have gotten them without it, too, had I
tried hard enough :-)

> Or are you talking about reverse proxying a SSL backend?

Nope, this is the forward proxy situation.

SSL-Browser <--CONNECT--> httpd-2.2.7-proxy <--> origin server

  Martin
-- 
<Ma...@Fujitsu-Siemens.com>        |     Fujitsu Siemens
http://www.fujitsu-siemens.com/imprint.html | 81730  Munich,  Germany

Re: proxy-SSL-woes in 2.2.7 [was:Re: Pre-release test tarballs of httpd 1.3.40, 2.0.62 and 2.2.7 available]

Posted by Ruediger Pluem <rp...@apache.org>.

On 01/08/2008 06:41 PM, Martin Kraemer wrote:
> Okay, I found a new bug in the 2.2.7 proxy while testing SSL
> and non-SSL CONNECTions both with and without a ProxyRemote
> directive.
> 
> <verbose>
>   To recap, totally different things happen in the presence or
>   absence of a ProxyRemote:
>   
>   * with ProxyRemote, the web server acts as a forwarder, and
>     connects to an "upstream" proxy in a proxy chain (speaking
>     the HTTP protocol to it), 
> 
>   while
> 
>   * without ProxyRemote, the web server connects directly to the
>     origin server, speaking the native protocol to it (i.e., speaking
>     FTP when executing a ftp://originserver/ proxy URL, or
>     simply tunnelling the net data when doing http:// or ssl
>     CONNECT proxy requests)
> </verbose>
> 
> In the test matrix, the forwarder situation was working allright.
> The direct connection, however, breaks in SSL mode, and the
> connection is closed by the 2.2.7 proxy too early (before
> receiving the 1st response to the SSL CLIENT-HELLO).
> 
> The chunk_filter patch seems to improve the situation: the
> connection "sometimes" succeeds. But in most cases, I get
> (with a slightly patched openssl s_client that can use a
> HTTP proxy):
> 
> --snip--
> % openssl s_client -connect originserver:443 -proxy apacheproxy227:8227 -verify 0 -msg
> verify depth is 0
> HTTP/1.0 200 Connection Established
> CONNECTED(00000005)
>>>> SSL 2.0 [length 00c5], CLIENT-HELLO
>     01 03 01 00 9c 00 00 00 20 00 c0 14 00 c0 0a 00
>     00 39 00 00 38 00 00 88 00 00 87 00 c0 0f 00 c0
>     05 00 00 35 00 00 84 00 c0 12 00 c0 08 00 00 16
>     00 00 13 00 c0 0d 00 c0 03 00 00 0a 07 00 c0 00
>     c0 13 00 c0 09 00 00 33 00 00 32 00 00 9a 00 00
>     99 00 00 45 00 00 44 00 c0 0e 00 c0 04 00 00 2f
>     00 00 96 00 00 41 00 00 07 05 00 80 03 00 80 00
>     c0 11 00 c0 07 00 c0 0c 00 c0 02 00 00 05 00 00
>     04 01 00 80 00 00 15 00 00 12 00 00 09 06 00 40
>     00 00 14 00 00 11 00 00 08 00 00 06 04 00 80 00
>     00 03 02 00 80 b8 a2 32 64 e5 0b 51 ae ec a1 2f
>     f0 f9 6e b1 8f ab af 9c 97 c2 de a1 d4 f3 34 1d
>     a9 c3 9c ef 10
> 38921:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:631:
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 7 bytes and written 199 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Compression: NONE
> Expansion: NONE
> ---
> --snip--
> 
> so the connection is closed before the response has arrived.
> On the server side, the proxy_connect (with DEBUGGING) logs:
> 
> --snip--
> [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(145): proxy: CONNECT: connecting to remote host originserver
> [Tue Jan 08 15:00:44 2008] [debug] proxy_util.c(1525): proxy: CONNECT: fam 2 socket created to connect to originserver
> [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(241): proxy: CONNECT: Returning 200 OK Status
> [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(262): proxy: CONNECT: setting up poll()
> [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(299): proxy: CONNECT: woke from select(), i=1
> [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(344): proxy: CONNECT: client was set
> [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(353): proxy: CONNECT: read 199 from client
> [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(299): proxy: CONNECT: woke from select(), i=1
> [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(344): proxy: CONNECT: client was set
> [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(371): proxy: CONNECT: client: apr_socket_recv() => rv=70014 = End of file found
> [Tue Jan 08 15:00:44 2008] [debug] mod_proxy_connect.c(404): proxy: CONNECT: finished with poll() - cleaning up
> --snip--
> 
> so it gets an EOF when there should be more data available.
> 
> On Sun, Jan 06, 2008 at 07:47:03PM +0100, Ruediger Pluem wrote:
>> Ok, next one. I missed to set the correct state in some situations.
>> Can you please give it a try again?
> 
> As I said, without this patch, the connection apparently never
> succeeds. With the patch, *sometimes* it succeeds:

Very, very strange because in the SSL proxy forward case you

1. use mod_proxy_connect which wasn't touched in 2.2.x for the last 11 month,
   so I doubt that this is a regression-
2. The HTTP_IN filter does not do anything in the SSL proxy forward case (it
   is not in the filter chain) as in contrast to non SSL proxying mod_proxy_connect
   does not care about the contents of the backend at all and is a pure data pump
   on TCP level.

Or are you talking about reverse proxying a SSL backend?


Regards

RĂ¼diger