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.
Kaspar
[1]
https://mail-archives.apache.org/mod_mbox/httpd-dev/200903.mbox/%3C49D0EFF7.8030902%40velox.ch%3E
[2]
https://mail-archives.apache.org/mod_mbox/httpd-dev/200903.mbox/%3c49ce8500.5060...@apache.org%3E
