https://bz.apache.org/bugzilla/show_bug.cgi?id=55707
--- Comment #25 from Dave Schneider <dschnei...@e2open.com> --- (In reply to William A. Rowe Jr. from comment #23) > 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? Not knowing the mod_ssl internals, I suppose this may make sense from that standpoint, but going from the SSLProtocol documentation that's certainly not clear. The context for SSLProtocol is listed as "server config" and "virtual host", with no mention that only IP virtual hosts support this. The behavior described here would imply that SSLProtocol is currently ignored for all name virtual hosts except the first one (default), even when the SNI extension is passed. But why would that be more logical than treating it as applicable for for any virtual host that specifies it, regardless of whether it was IP or name based? The spec on the SNI extension isn't real specific, focusing mostly on presenting the right server certificate, but it does say the following: A server that receives a client hello containing the "server_name" extension MAY use the information contained in the extension to guide its selection of an appropriate certificate to return to the client, and/or other aspects of security policy. So it doesn't mandate that "other aspects of security policy" be determined using the SNI value, but I would argue that makes as much sense as guiding the selection of the certificate, which is already being done. -- 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
