> -----Original Message----- > From: Yann Ylavic [mailto:ylavic....@gmail.com] > Sent: Mittwoch, 16. April 2014 16:01 > To: httpd > Subject: Re: svn commit: r1585090 - in /httpd/httpd/trunk: CHANGES > modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c > > On Wed, Apr 16, 2014 at 3:11 PM, Plüm, Rüdiger, Vodafone Group > <ruediger.pl...@vodafone.com> wrote: > > > > > >> -----Original Message----- > >> From: Yann Ylavic [mailto:ylavic....@gmail.com] > >> Sent: Mittwoch, 16. April 2014 15:00 > >> To: httpd > >> Subject: Re: svn commit: r1585090 - in /httpd/httpd/trunk: CHANGES > >> modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c > >> > >> On Wed, Apr 16, 2014 at 2:41 PM, Plüm, Rüdiger, Vodafone Group > >> <ruediger.pl...@vodafone.com> wrote: > >> > > >> >> -----Original Message----- > >> >> From: Yann Ylavic [mailto:ylavic....@gmail.com] > >> >> This base_server directive would help prevent vhost misuse at the > >> >> source, whatever the vhosts' configs are, and however we relax the > >> >> Host vs SNI check. > >> > > >> > I don't think so. The SNI provided hostname and the HTTP host header > >> still need to match. > >> > >> Which can't be if no vhost is defined for that SNI, the option would > >> not break that (it's more a hardening feature). > > > > You are confusing me. In this case we would fall to the default vhost. > > But I guess I am currently not understanding what you try to resolve / > what goes wrong > > without a patch. Care to give an example setup to clear up my confusion? > > Before this commit, the client knew it was not reaching any vhost by > receiving an SSL alert (warning), and could stop. > Now, has you said, it will reach the default vhost, and provided the > SNI is the same as the Host header (or some other mean blocks), it > will pass through (unless this vhost has a ServerName and > UseCanonicalName is on, which would result in a 400). The certificate > used on the default vhost can alert it though, but this is out of SNI > handling. > This is not a behaviour change on the server side (the SSL alert > warning was not abortive), but for the client. > > The new option would prevent the default vhost to be used (when SNI is > available), and let the client know (still).
I don't see why we should prevent using the default host. Maybe it has a wildcard cert and everything is good. Regards Rüdiger
