You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@gmail.com> on 2014/07/11 22:25:31 UTC
mod_ssl post-read-request error checking on internal redirects
A patch:
Index: modules/ssl/ssl_engine_kernel.c
===================================================================
--- modules/ssl/ssl_engine_kernel.c (revision 1609790)
+++ modules/ssl/ssl_engine_kernel.c (working copy)
@@ -164,7 +164,7 @@
return DECLINED;
}
#ifdef HAVE_TLSEXT
- if (r->proxyreq != PROXYREQ_PROXY) {
+ if (!r->prev && r->proxyreq != PROXYREQ_PROXY) {
if ((servername = SSL_get_servername(ssl,
TLSEXT_NAMETYPE_host_name))) {
char *host, *scope_id;
apr_port_t port;
This path in the post-read-request hook is performing some SNI-related
error checking, catching situations where it will return 400 or 403.
I noticed with StrictSNIVHostCheck failures that this code is triggering an
error on a subrequest to generate an error document after catching the same
error on the initial request.
Is there a reason either of the checks here needs to be made on a
subrequest?
Thanks!
--
Born in Roswell... married an alien...
http://emptyhammock.com/
http://edjective.org/
Re: mod_ssl post-read-request error checking on internal redirects
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Jul 11, 2014 at 5:09 PM, Yann Ylavic <yl...@gmail.com> wrote:
> On Fri, Jul 11, 2014 at 10:25 PM, Jeff Trawick <tr...@gmail.com> wrote:
> > A patch:
> >
> > Index: modules/ssl/ssl_engine_kernel.c
> > ===================================================================
> > --- modules/ssl/ssl_engine_kernel.c (revision 1609790)
> > +++ modules/ssl/ssl_engine_kernel.c (working copy)
> > @@ -164,7 +164,7 @@
> > return DECLINED;
> > }
> > #ifdef HAVE_TLSEXT
> > - if (r->proxyreq != PROXYREQ_PROXY) {
> > + if (!r->prev && r->proxyreq != PROXYREQ_PROXY) {
> > if ((servername = SSL_get_servername(ssl,
> > TLSEXT_NAMETYPE_host_name))) {
> > char *host, *scope_id;
> > apr_port_t port;
> >
> >
> > This path in the post-read-request hook is performing some SNI-related
> error
> > checking, catching situations where it will return 400 or 403.
> >
> > I noticed with StrictSNIVHostCheck failures that this code is triggering
> an
> > error on a subrequest to generate an error document after catching the
> same
> > error on the initial request.
> >
> > Is there a reason either of the checks here needs to be made on a
> > subrequest?
>
> I don't see any, the post-read-request hooks are always run on the
> initial request, and the SSL* will always be the one of the initial
> request for all its subrequests (unless some third-party module plays
> really bad with subr->connection).
>
> You probably could use !ap_is_initial_req(r) but post-read-request
> hooks are never run on ap_sub_req()uests (having r->main) AFAIK.
>
Thanks for looking, Yann. I did change it to use ap_is_initial_req()
(without the ! :) )
r1609914
Re: mod_ssl post-read-request error checking on internal redirects
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Jul 11, 2014 at 10:25 PM, Jeff Trawick <tr...@gmail.com> wrote:
> A patch:
>
> Index: modules/ssl/ssl_engine_kernel.c
> ===================================================================
> --- modules/ssl/ssl_engine_kernel.c (revision 1609790)
> +++ modules/ssl/ssl_engine_kernel.c (working copy)
> @@ -164,7 +164,7 @@
> return DECLINED;
> }
> #ifdef HAVE_TLSEXT
> - if (r->proxyreq != PROXYREQ_PROXY) {
> + if (!r->prev && r->proxyreq != PROXYREQ_PROXY) {
> if ((servername = SSL_get_servername(ssl,
> TLSEXT_NAMETYPE_host_name))) {
> char *host, *scope_id;
> apr_port_t port;
>
>
> This path in the post-read-request hook is performing some SNI-related error
> checking, catching situations where it will return 400 or 403.
>
> I noticed with StrictSNIVHostCheck failures that this code is triggering an
> error on a subrequest to generate an error document after catching the same
> error on the initial request.
>
> Is there a reason either of the checks here needs to be made on a
> subrequest?
I don't see any, the post-read-request hooks are always run on the
initial request, and the SSL* will always be the one of the initial
request for all its subrequests (unless some third-party module plays
really bad with subr->connection).
You probably could use !ap_is_initial_req(r) but post-read-request
hooks are never run on ap_sub_req()uests (having r->main) AFAIK.