On Wed, Jul 26, 2017 at 12:28:55PM -0700, Kevin McArthur wrote: > > No, it needs it to select the certificate to present. Then it should match > > it against the Host header field, and use the Host header field to select > > the vhost. The difference is subtle but it's important to keep each protocol > > element one in its role. In the end for HTTP it's always the Host which > > decides, regardless of the transport. > Perhaps how it should work but this isn't actually how apache matches vhosts > in a ssl context. They use the SNI, which selects the vhost in use. The host > header can be gibberish and it will still select the vhost via sni when > configured with ServerName directive.
Well it's the first time I hear about this and find this a bit shocking, as Apache tends to try to follow standards and ignoring Host clearly doesn't fall into that category and would even cause some security issues when used as a reverse-proxy by routing the requests to the wrong places. Also the doc here tends to disagree as well : https://httpd.apache.org/docs/2.4/vhosts/name-based.html "With name-based virtual hosting, the server relies on the client to report the hostname as part of the HTTP headers." So maybe you want to double-check what happens when you do this : $ printf "GET / HTTP/1.1\r\nHost: domain1\r\n\r\n | openssl s_client -connect host:port -servername domain2 $ printf "GET / HTTP/1.1\r\nHost: domain2\r\n\r\n | openssl s_client -connect host:port -servername domain1 My guess is that either you'll get a 4xx error because there's a mismatch or you'll get the domain referenced in the Host header delivered. And by the way I'm seeing this in their changelog for v2.2.26 and v2.2.27 : *) mod_ssl: Check SNI hostname against Host header case-insensitively. *) mod_ssl: Do not perform SNI / Host header comparison in case of a forward proxy request This tends to confirm that by default the comparison is performed. Willy
