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
