https://bz.apache.org/bugzilla/show_bug.cgi?id=55707
William A. Rowe Jr. <wr...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
--- Comment #23 from William A. Rowe Jr. <wr...@apache.org> ---
Re comment #21, I think you are suggesting the correspondence of SNI and
SSLCipherSuite? The client hello is processed by invoking the OpenSSL read
client hello which corresponds to the SSLProtocol defined by the first
(physical matching) IP:Port vhost. Once that happens I guess we can trust
the version reported as you suggest, provided that processing all occurs
prior to the server hello. If the SNI callback is being invoked before
the server hello, I believe your patch may be sufficient. (It is currently
missing SSLV3 and TLSV1_3 logic, easy fixes.) I'd be concerned about future
maintenance, but there are enough other places we can trip over TLSV1_4 that
it probably isn't a fair objection.
I think we can document the somewhat crazy example Stefan was looking for;
<vhost A0>
SSLProtocol +TLSV1.1 +TLSV1.2
</vhost A0>
<vhost A>
SSLProtocol +TLSV1.1
</vhost A>
<vhost B>
SSLProtocol +TLSV1.2
</vhost B>
(If vhost A is both 1.1 and 1.2, then the extra phys-vhost isn't needed and
the least-restrictive SSLProtocol should be stated first as the default
vhost.) This isn't too much different than the docs warning for
https://httpd.apache.org/docs/2.4/mod/core.html#limitrequestfieldsize
However, because you've just changed the meaning of SSLProtocol in all
vhost cases, this doesn't appear to be a suitable change for an httpd 2.4.x
revision. The patch invalidates apparently-working-today configurations
which were coded to the current phys-vhost semantics.
Right now, SSLProtocol is inherited global -> phys vhost. The behavioral
change causes this to be global -> virt vhost. That may require admins to
make major changes to all 'default' name based vhosts, and seems like an
unwise side-effect of a configuration already carefully audited for
security considerations, for simply a subversion bump. Thoughts?
--
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
