On Fri, Dec 13, 2013 at 10:46 AM, Ruediger Pluem <rpl...@apache.org> wrote:
> > William A. Rowe Jr. wrote:> > > The SSL settings come from first the IP/port search, then the resolved > > SNI hostname's vhost, and finally from the corresponding Host: named > > vhost where applicable. Of course the Host: vhost config may override > > the SNI hostname vhost, that's the correct httpd behavior, just as > > changing SSL options within a <location > block overrides the vhost. > > > > > > But these SSL options are not applied later. So if you have two virtual > hosts: > > NameVirtualHost someip:443 > > <virtualhost someip:443> > Servername strong > SSLCiphersuite something strong > </virtualhost> > > <virtualhost someip:443> > Servername weak > SSLCiphersuite something weak > </virtualhost> > > Then you would be able to connect to the strong virtual host with a weak > cipher just by supplying 'weak' in SNI and > 'strong' in the host header. > Without SNI (in 2.2.x, I can't tell for 2.4), doesn't this lead to a (secure/full) renegotiation? With the configuration above, the client would first reach the "strong" vhost (first in config) and then the "weak" one (when the Host: is read, according to the "strong" SSL parameters), resulting in a renego. Yes this is huge pain and expensive, but an administrator issue AFAICT. Why would it be different with SNI? Except that the client reaches "weak" first, couldn't a renego be issued if finally it asks for "Host: strong"?
