On Thu, 12 Dec 2013 09:28:16 +0000 "Plüm, Rüdiger, Vodafone Group" <ruediger.pl...@vodafone.com> wrote:
> > > > -----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. Yes, and? Why would this differ from the historical handling of the Host: header? The HTTP Host header is not the dns name of this hop, but the hostname component of the uri. This logic has completely broken forward proxies in httpd on the 2.4 and 2.2.25 releases. The SSL settings come from first the IP/port search, then the resolved SNI hostname's vhost, and finally from the corresponding Host: named vhost where applicable. Of course the Host: vhost config may override the SNI hostname vhost, that's the correct httpd behavior, just as changing SSL options within a <location > block overrides the vhost.
