Review how SSL Protocol/CipherSuite values are set

[apertome]

A user reported that they are trying to override our SSL Protocol and Ciphers with more restrictive ones than we use, and their changes are getting overwritten when they update their perfSONAR packages. We should look at how we're doing these changes and see if we can make things more flexible.

Doug Wussler wrote:

Is there some reason why you are modifying the values of “SSLProtocol” and “SSLCipherSuite” in the SSL.CONF file when updates are applied?

I have more restrictive settings for these parameters. Whenever an update runs it updates these values and we end up with a corrupt value for SSLCipherSuite and then the service can’t restart.

Does this config file need to be included in your update procedures? If not, can you please remove it so that it doesn’t overwrite custom settings?

Also:

You put the changes inside the VirtualHost. From what I can see in my testing, I cannot override those setting in another config file. If you could move them outside the virtual host then I could do as you suggest. Is this something you could do? I think that would accomplish your goal while allowing others to customize those settings.

[apertome]

Also from Doug:

My understanding is that if it is set outside the Virtual Host it will be inherited by all virtual hosts but can be
overridden by settings inside the virtual host. But once set inside a virtual host it is immune to being overridden in another file.

[arlake228]

A follow-up thread was started on this on the user list. To expand on what is already in his ticket, the following is an excerpt from an email I sent describing the desired process:

We don’t actually put the ssl.conf in place, mod_ssl creates the version that has those options in a VirtualHost, we just use sed to replace them wherever they are in the file. That being said I think below summarizes what you are suggesting which I think would work:

1. On install, update the ssl.conf installed by mod_ssl to exclude the options in question from the default VirtualHost defined by mod_ssl. After initial install, perfsonar never touches ssl.conf again.

2. Create a separate file controlled by a perfsonar package that globally sets the SSL* options we care about. This is the file that will get modified on perfsonar package update and should not be manually edited.

3. If someone wants to override our options, they can edit the VirtualHost in ssl.conf. Since it is inside the VirtualHost, those options will take precedence over the global options set by perfSONAR and we all live happily ever after.

Additionally we need to consider what we want to do for current users the first time we update with a change like above. We'll need code to do a one-off remove of the current ssl.conf file. We can probably leverage our new branching strategy to put in special code for this release and make sure it is taken out the next release.

Also, we may want to consider this for 4.1.4 instead of 4.2.0. Probably something to talk about at a next dev call.