> -----Original Message----- > From: Kaspar Brand [mailto:httpd-dev.2...@velox.ch] > Sent: Donnerstag, 12. Dezember 2013 07:01 > To: dev@httpd.apache.org > Subject: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests > > On 12.12.2013 00:15, William A. Rowe Jr. wrote: > > The rest of the SNI hostname processing steps are where the problem > > lies. We still need to perform http headers -> vhost translation after > > the connection is established. If there's any desire to do SNI hostname > > validation, that has to be limited to comparing that hostname to the > > ServerName/ServerAlias entries, not to the HTTP Host: which has a > > different semantic meaning and is the only hostname of interest to > > httpd as an HTTP server. > > The logic in ssl_hook_ReadReq was added with r757373. It wasn't in the > initial version of the patch for SNI support (r606190). I didn't find > prior discussion of r757373 on the mailing list, but perhaps it was > motivated by this statement in RFC 6066 (RFC 4366 at the time): > > If the server_name is > established in the TLS session handshake, the client SHOULD NOT > attempt to request a different server name at the application layer. > > I never really understood the reasoning for turning this into a "reject > requests if the SNI extension and the Host header differ" (see e.g. [1],
The reason is that you can define SSL parameters in Virtual hosts like SSLCiphers or SSLProtocols. If Host header and SNI host match you can be sure that the parameters that you set in the virtual host from which your request is being served have been used. If you allow a mismatch between SNI host and host header you might serve the request on a SSL connection that does not match your SSL parameters set up for the particular virtual host. Regards Rüdiger
