httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar Brand <>
Subject Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Date Thu, 12 Dec 2013 06:00:50 GMT
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],
where I was becoming tired of things said in [2]). Also, I think that
SSLStrictSNIVHostCheck is a pretty unnecessary knob.




View raw message