On Wed, Apr 16, 2014 at 3:11 PM, Plüm, Rüdiger, Vodafone Group <[email protected]> wrote: > > >> -----Original Message----- >> From: Yann Ylavic [mailto:[email protected]] >> 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 >> <[email protected]> wrote: >> > >> >> -----Original Message----- >> >> From: Yann Ylavic [mailto:[email protected]] >> >> 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). Regards, Yann.
