As per what should be taken as "default" if no _default_ is given and an old OpenSSL code is in use: we are in 2019, almost 2020. What is the recommended best practice for HTTPS servers? I think SSLv3 and TLSv1.0 are out of the picture, so it is on the dev team to make the judgement call on how secure they want their product out of the box to initialize the SSL subsystem without an explicit _default_ VHost. If your predefined, "hardcoded" settings are not what the admin expects, you leave for them to adjust their standards on each and every of their VHost. But perhaps a few lines of comments on the configuration files can save a lot of lines of code and maintenance down the road.
Just my $.02. -----Original Message----- From: [email protected] <[email protected]> Sent: Friday, October 25, 2019 4:32 PM To: [email protected] Subject: RE: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645) So the # global SSLProtocol TLSv1.3 is an OpenSSL-1.1.1 and onwards feature, where before it was whatever defined on the first <VirtualHost>. Oddly enough, I clearly missed... Anyway, the fact a standard Apache httpd-ssl.conf configuration file comes with a <VirtualHost _default_:443> key entry should give one a hint this is where the default settings should be applied. If the _default_ VHost is removed/renamed, then there should be no default/inheritance, only if an older OpenSSL is in use; assuming the first <VirtualHost> dictates things for all VHosts is not the right approach to me. So yes, on this scenario, it is unintuitive. I would vote on a clear _default_ VHost for defaults versus reinventing the wheel, but that's only me - and a note on the config stating the SSLProtocol under #global only applies to OpenSSL-1.1.1 and onwards: this can cause confusion/false sense of security if you set things up there and the VHost ends up not making use of these settings. -----Original Message----- From: Yann Ylavic <[email protected]> Sent: Friday, October 25, 2019 3:32 PM To: httpd-dev <[email protected]> Subject: Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645) On Fri, Oct 25, 2019 at 7:42 PM Alex Hautequest <[email protected]> wrote: > > IMHO, it *is* intuitive. If you want no default configuration, do not set one > by default, otherwise inheritance applies - just as everything else in this > daemon. Possibly the inheritance we are talking about here is not the one you are thinking of, not the usual one in httpd at least. In current httpd 2.4, the SSLProtocol which applies for name-based vhosts is the one of the base vhost (the first vhost declared on the IP:port), because until OpenSSL-1.1.1 there was no way to change the protocol of a TLS connection, and httpd needs a TLS connection first to start the handshake, and OpenSSL wants a protocol to create the connection, chicken and egg... So the SSLProtocol used to create the TLS connection is the one based on the IP:port the connection is accepted on, i.e. the base vhost's. Now we can and want to be able to configure/honor SSLProtocol per vhost, but the de facto default is the base vhost for SSLProtocol, not the global/root server where directives usually inherit from. Suppose a configuration like this: # global SSLProtocol TLSv1.3 # base vhost <VirtualHost *:443> ServerName name1 SSLProtocol TLSv1.2 </VirtualHost> # non-base vhost <VirtualHost *:443> ServerName name2 # no SSLProtocol </VirtualHost> Which SSLProtocol name2 should apply? For compatibility with 2.4, that's TLSv1.2, your/one's intuition? If unintuitve, we need some option to address both 2.4 compatibility (with some default there) and intuition/POLS (with another default for next versions). Regards, Yann.
