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: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Date Thu, 20 Feb 2014 12:47:41 GMT
Dne St 19. února 2014 21:09:10, William A. Rowe Jr. napsal(a):
> I believe that Kaspar and Ruediger are still entirely at odds with my
> position, but this 'enhancement' should never have been unilaterally
> applied as it was to 2.2.26 and must be reverted (even as the feature
> is 'fixed' with corrections they have blessed), e.g. the comparison
> must be constrained to apply only to SSLStrictSNIVHostCheck enforcing
> hosts under 2.2 to not break existing configurations.
> 
> It similarly aught to be constrained to SSLStrictSNIVHostCheck on the
> 2.4 branch, but I'm just not going to participate in that debate at
> all, which is why I say 'aught to'.  Time for a few more committers to
> review the relevant specs and chime in with opinions on productive vs.
> disruptive rules that are out-of-spec.

Last note:
when I go to the reverse proxy without hostname I can't get website at all.
wget --no-check-certificate https://a.b.c.d will always return HTTP Error 500:
AH01084: pass request body failed to..
AH00898: Error during SSL Handshake with remote server returned by /
AH01097: pass request body failed to..

Any idea how to rework configuration without the downgrade to SSLv3?
-- 
Pavel Matěja
 
> On Wed, Feb 19, 2014 at 2:24 AM, Pavel Matěja <pavel@netsafe.cz> wrote:
> > Dne Út 18. února 2014 10:16:15, Daniel Kahn Gillmor napsal(a):
> >> On 02/18/2014 08:14 AM, Pavel Matěja wrote:
> >> > 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 seems like an administrator could avoid this risk by doing hostname
> >> 
> >> canonicalization via external redirect at the proxy itself. This
> >> 
> >> probably isn't a currently common practice, but for sites who should
> >> 
> >> canonicalize their hostnames, i don't see it as particularly onerous.
> >> 
> >> 
> >> 
> >> The main concern would be for non-canonicalized hostnames. e.g.
> >> 
> >> *.example.com, where each user of a service gets to set up
> >> 
> >> https://$USERNAME.example.com/. A proxy would need to pass this
> >> 
> >> information through to the origin server -- so in the scenario you
> >> 
> >> describe, a reverse proxy could run into serious trouble.
> >> 
> >> 
> >> 
> >> --dkg
> > 
> > I know.
> > 
> > We have two slightly different webs like foo.com and bar.eu which shared
> > one virtual server on reverse proxy. Backend server distinguishes between
> > them by hostname in handler.
> > 
> > I had to create two separate vitual servers on reverse proxy using two
> > different fake hostnames for backend server with same ip to distinguish
> > workers in ap_proxy_get_worker().
> > 
> > 
> > 
> > Another workaround I know about is to downgrade proxy - backend connection
> > to SSLv3 only.
> > 
> > --
> > 
> > Pavel Matěja



Mime
View raw message