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
--
<[EMAIL PROTECTED]> | Fujitsu Siemens
http://www.fujitsu-siemens.com/imprint.html | 81730 Munich, Germany
