You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Masaoki Kobayashi <ma...@techfirm.co.jp> on 2009/12/07 03:16:08 UTC
SSL unexpected renegotiation for CGI with PATH_INFO
Hi,
I found suspicious behavior with CGI using PATH_INFO when
it is on the client authenticated SSL.
My situation is as follows.
/foo
SSLVerifyClient none
/bar
SSLVerifyClient require
Assume here're some files under /foo.
a.html - plain html file
b.cgi - regular cgi (not nph)
Then, I get somes file from browser.
What I could get without certificates are...
/foo/a.html
/foo/b.cgi
/foo/b.cgi/foo <--- (1)
What SSL session renegotiation runs, so I needed certificates
to access are...
/bar
/foo/b.cgi/bar <--- (2)
Because /foo is configured as "SSLVerifyClient none", so I expect
it does not need any certificates.
What is different between (1) and (2)?
I could see the request is processed twice because the second
request (protocol="INCLUDED") is generated in ap_add_cgi_vars().
The second request issued with uri=path_info, so that it makes
SSL renegotiation only when path_info is under "/bar".
util_script.c
370 if (r->path_info && r->path_info[0]) {
371 /*
372 * To get PATH_TRANSLATED, treat PATH_INFO as a URI path.
373 * Need to re-escape it for this, since the entire URI was
374 * un-escaped before we determined where the PATH_INFO began.
375 */
376 request_rec *pa_req;
377
378 pa_req = ap_sub_req_lookup_uri(ap_escape_uri(r->pool, r->path_info), r,
379 NULL);
Does someone have any idea for this?
Masaoki Kobayashi
Re: SSL unexpected renegotiation for CGI with PATH_INFO
Posted by Torsten Foertsch <to...@gmx.net>.
On Mon 07 Dec 2009, Masaoki Kobayashi wrote:
> I found suspicious behavior with CGI using PATH_INFO when
> it is on the client authenticated SSL.
>
> My situation is as follows.
>
> /foo
> SSLVerifyClient none
> /bar
> SSLVerifyClient require
>
> Assume here're some files under /foo.
>
> a.html - plain html file
> b.cgi - regular cgi (not nph)
>
> Then, I get somes file from browser.
>
> What I could get without certificates are...
>
> /foo/a.html
> /foo/b.cgi
> /foo/b.cgi/foo <--- (1)
>
> What SSL session renegotiation runs, so I needed certificates
> to access are...
>
> /bar
> /foo/b.cgi/bar <--- (2)
>
> Because /foo is configured as "SSLVerifyClient none", so I expect
> it does not need any certificates.
> What is different between (1) and (2)?
>
> I could see the request is processed twice because the second
> request (protocol="INCLUDED") is generated in ap_add_cgi_vars().
> The second request issued with uri=path_info, so that it makes
> SSL renegotiation only when path_info is under "/bar".
>
> util_script.c
> 370 if (r->path_info && r->path_info[0]) {
> 371 /*
> 372 * To get PATH_TRANSLATED, treat PATH_INFO as a URI path.
> 373 * Need to re-escape it for this, since the entire URI was
> 374 * un-escaped before we determined where the PATH_INFO
> began. 375 */
> 376 request_rec *pa_req;
> 377
> 378 pa_req = ap_sub_req_lookup_uri(ap_escape_uri(r->pool,
> r->path_info), r, 379 NULL);
>
> Does someone have any idea for this?
This is another occurrence of bug #48228. Mod_cgi tries to map PATH_INFO
to the file system to set an environment variable using a subrequest.
This subrequest then triggers renegotiation.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48228
Torsten
--
Need professional mod_perl support?
Just hire me: torsten.foertsch@gmx.net