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. On Wed, Feb 19, 2014 at 2:24 AM, Pavel Matěja <pa...@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 > >
