httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Matěja <pa...@netsafe.cz>
Subject Re: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Date Tue, 18 Feb 2014 13:14:31 GMT
Dne Út 17. prosince 2013 18:35:50, Kaspar Brand napsal(a):
> On 26.11.2013 06:31, Kaspar Brand wrote:
> > As far as PR 55782 is concerned, the problem might be that
> > proxy_util.c:ap_proxy_determine_connection() does not take Host: header
> > differences into account when checking if an existing connection can be
> > reused (not sure). With SNI this would have the effect that the hostname
> > from the TLS handshake is causing the mismatch with the Host: header.
> 
> To clear this up: the above guess was a red herring. mod_proxy's current
> behavior is fine in this aspect and does not conflict with any IP resolution
> "coincidence" when reverse proxying SNI-based URLs (I'm aware that this
> thread is supposed to deal with forward proxying only, but am adding this
> for posterity, in case someone is sifting through archives).
> 
> It's not ap_proxy_determine_connection() which is really relevant, but
> proxy_util.c:ap_proxy_get_worker() instead. mod_proxy (only) reuses workers
> for reverse proxying based on the target URL; looking at
> proxy_util.c:ap_proxy_get_worker() in 2.4 e.g we see:
> 
>     /*
>      * Do a "longest match" on the worker name to find the worker that
>      * fits best to the URL, but keep in mind that we must have at least
>      * a minimum matching of length min_match such that
>      * scheme://hostname[:port] matches between worker and url.
>      */
> 
>     if (balancer) {
>         proxy_worker **workers = (proxy_worker **)balancer->workers->elts;
>         for (i = 0; i < balancer->workers->nelts; i++, workers++) {
>             worker = *workers;
>             if ( ((worker_name_length = strlen(worker->s->name)) <=
> url_length) && (worker_name_length >= min_match)
>                 && (worker_name_length > max_match)
>                 && (strncmp(url_copy, worker->s->name, worker_name_length)
> == 0) ) { max_worker = worker;
>                 max_match = worker_name_length;
>             }
> 
>         }
>     } else {
>         worker = (proxy_worker *)conf->workers->elts;
>         for (i = 0; i < conf->workers->nelts; i++, worker++) {
>             if ( ((worker_name_length = strlen(worker->s->name)) <=
> url_length) && (worker_name_length >= min_match)
>                 && (worker_name_length > max_match)
>                 && (strncmp(url_copy, worker->s->name, worker_name_length)
> == 0) ) { max_worker = worker;
>                 max_match = worker_name_length;
>             }
>         }
>     }
> 
> I.e., there's no risk of two workers for reverse proxying, say,
> https://foo.example.net and https://bar.example.net, ever being reused for
> each other, irrespective of whether foo.example.net and bar.example.net
> resolve to the same IP address.
> 
> Kaspar

Hi,
sorry for late follow-up but you are wrong.
There is one big risk when someone uses reverse HTTPS proxy with ServerAlias.

Let say you have on both - backend and proxy servers options:
ServerName www.example.com
ServerAlias example.com

In old non-SNI days everything was working just fine.

Now when one client connects to proxy and requires www.example.com, connection 
is established to backend server with SNI hostname set to www.example.com.
Second client connects to proxy and requires example.com. Worker is matched 
because there is just one. Connection is reused but you will get 4xx Bad 
Request because there is mismatch between old and current SNI hostname.

It's kind of heisenbug because even tons of request to example.com only or to 
www.example.com only are just fine. You have to request both sites at the same 
time to realize what's going on.
-- 
Pavel Mateja


Mime
View raw message