On Sat, Apr 5, 2014 at 2:57 PM, <kbr...@apache.org> wrote: > Author: kbrand > Date: Sat Apr 5 12:57:43 2014 > New Revision: 1585090 > > URL: http://svn.apache.org/r1585090 > Log: > Bring SNI behavior into better conformance with RFC 6066: > > - no longer send a warning-level unrecognized_name(112) alert > when no matching vhost is found (PR 56241)
>From a client perspective, it is a loss of information, couldn't the admin have an option ... > + /* > + * RFC 6066 section 3 says "It is NOT RECOMMENDED to send > + * a warning-level unrecognized_name(112) alert, because > + * the client's behavior in response to warning-level alerts > + * is unpredictable." > + * > + * To maintain backwards compatibility in mod_ssl, we > + * no longer send any alert (neither warning- nor > fatal-level), > + * i.e. we take the second action suggested in RFC 6066: > + * "If the server understood the ClientHello extension but > + * does not recognize the server name, the server SHOULD take > + * one of two actions: either abort the handshake by sending > + * a fatal-level unrecognized_name(112) alert or continue > + * the handshake." > + */ for the first action suggested in the RFC? 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. Thus one can trust httpd's (base) config to know whether or not the handshake has reached the requested vhost. This is already/always the case currently, the difference is when it takes place (before vhosting), and the SSL level alert (vs "400 Bad Request" now) that would help the client to know what's happening. That option would cause empty SNI to be refused too, and maybe multiple SSL vhosts on the same IP:port to be error-ed on startup (when SNI is available in the underlying lib). Whether it should be on/off by default depends on the change introduced by this commit (SSL alert warning => 400) and how clients handle warning level SSL alerts. I may be misleaded though... Regards, Yann.
