William A. Rowe Jr. wrote: > 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,
It doesn't, but we clearly stated in the docs before: Don't use name based virtual hosting with SSL for exactly this reasons. > 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. How does this break forward proxies? Usually you connect to a forward proxy via HTTP. How does SNI matter here? > > 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. > > But these SSL options are not applied later. So if you have two virtual hosts: NameVirtualHost someip:443 <virtualhost someip:443> Servername strong SSLCiphersuite something strong </virtualhost> <virtualhost someip:443> Servername weak SSLCiphersuite something weak </virtualhost> Then you would be able to connect to the strong virtual host with a weak cipher just by supplying 'weak' in SNI and 'strong' in the host header. Regards Rüdiger
