https://bz.apache.org/bugzilla/show_bug.cgi?id=69743
--- Comment #24 from Dan Mahoney <apacheb...@gushi.org> --- (In reply to Yann Ylavic from comment #8) > Without an SNI provided by the client, there is nothing httpd can do to > determine which vhost/configuration should be used to provide the correct > certificate (and TLS authentication eventually) whenever multiple vhosts > listen on the same ip:port. That's because reading the HTTP Host header > necessarily has to happen after the TLS handshake/auth/decryption (and later > renegotiation is not an option with TLSv1.3). > So those connections fall back to the first vhost declared on the ip:port > for the TLS handshake part, and if the request Host header finally matches a > different vhost with a different TLS configuration it's rejected with > AH02032. > Before 2.4.64 the check was not accurate and would allow that, with security > implications. > > I don't think it's fixable on the httpd side, besides maybe adding a new > UnsafeNoSNIBypass flag to restore the old behaviour, which almost no one > would use... > > Note that AH02032 is different from "SSLStrictSNIVHostCheck on" which > dissallows connections with no SNI to access any vhost, while the default > allows to reach all the vhosts with the same TLS configuration than the > first vhost (hence wildcard certs work). I mentioned this on -users a few weeks ago and thought that one of the fixes had inadvertently changed the value of SSLStrictSNIVhostCheck, which now seems to not be the case. (Nobody responded there and pointed back to this bug, either). For us, this didn't break production, but it did break some nagios checks. All the check was for was "is apache answering and responding with a reasonable response code". We had relied on the "if multiple hosts are configured and you don't send SNI, you get the first-configured host" behavior. To the best of my knowledge, there's no config knob to restore that behavior. Arguably, this change makes things both more correct and more secure, in a world where SNI is *mostly* a regular expection, at least for user-agents (not so much for backend appliances). Our fix is going to be to fix our checks and move on with our day, but IMO, the bug is: I am not sure if the developers considered would be broken with this change. This broke the principle of least astonishment. It makes operational changes to how httpd operates. *It SHOULD have been called out in the release notes and announcement*. And the knob I mentioned above (to restore the old behavior) should have been added, at least as a temporary fix (default off), because in many cases, reverting is not an option, and would involve pulling in a version that's subject to other CVE's. And re-engineering your whole SSL/Wildcard process is not a change that should be done under duress. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
