> -----Original Message----- > From: Yann Ylavic [mailto:ylavic....@gmail.com] > Sent: Mittwoch, 16. April 2014 14:16 > 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 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.
I don't think so. The SNI provided hostname and the HTTP host header still need to match. Regards Rüdiger
