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 <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
