https://bz.apache.org/bugzilla/show_bug.cgi?id=55707
William A. Rowe Jr. <wr...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #21 from William A. Rowe Jr. <wr...@apache.org> ---
"This is bad because we want to disable TLSv1 everywhere possible. As far as I
know, only one host really needs TLSv1. Now I had to enable TLSv1 on all vhosts
(that share the same ip)."
It's not bad, it is correct. You need to move the named host off of the
IP which you wish to lock down to TLSv1.1. Doing anything else is
circumventing the security policy you were given to enforce.
The handshake dictated by SSLProtocol is not an authnz restriction, it is
the hardwired handshake exchanged by the client and server. One and only
one configuration applies, which is the one in the first-matched vhost
found for the given IP:Port (otherwise known as the connection or physical
vhost.)
If you want to refuse traffic afterwards, clever use of SSL variables can
let you evaluate the negotiated protocol, but that's beyond the scope of
mod_ssl's task.
To Stefan's question, the confg would look like
<vhost A0>
SSLProtocol +TLSV1.1 +TLSV1.2
</vhost A0>
<vhost A>
SSLProtocol +TLSV1.1
</vhost A>
<vhost B>
SSLProtocol +TLSV1.2
</vhost B>
But that is still nonsense. Confusing the protocol with authnz is going to
lead to further configuration confusion. Detecting and alerting mismatched
SSLProtocol configs between same physical vhosts would be more helpful for
users trying to avoid misconfigs.
It seems the reporter desires SSLRequireSSL TLSV1.0/SSLRequireSSL TLSV1.2
in the respective hosts, which is not supported today. This would be very
radically different from SSLProtocol, because we can't suddenly up and
disconnect the TLSv1.0 connection to the second host without confusing the
client and therefore the user, but we can't send an error response on the
second host if the security policy prohibits all TLSv1.0/1.1 traffic.
SSLProtocol +TLSv1 +TLSV1.1 +TLSV1.2
SSLRequireSSL TLSV1.2
would be unambiguous.
The right solution, not mentioned before in this thread, is simply using
two different IP:Port assignments for traffic which must follow a TLSv1.2
security policy, and the alternate assignment for traffic allows legacy
protocols.
--
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
