13

I'm trying to test a patch for the poodle vulnerability that involves disabling SSLv3 on my web server. In order to test this on a non-production environment first, I'm setting the SSLProtocol on a VirtualHost for a different test server. My config looks something like this:

<VirtualHost *:443>
    SSLEngine On
    SSLProtocol All -SSLv2 -SSLv3
    ServerName test.mysite.com
    # bunch of other stuff omitted
</VirtualHost>

However even after restarting apache my test site is still claimed to be vulnerable. Is this expected to work? I'm wondering if I have to set it in the global ssl config or whether there's something else subtle that's causing the setting not to take and/or work.

16

You can set the SSLProtocol only for the first VirtualHost in the configuration file. All subsequent VirtualHost entries will inherit that setting from the first entry and silently ignore their own setting due to an OpenSSL bug.

There is a corresponding bug report for mod_ssl, but as described in the bug report, the problem needs to be resolved in OpenSSL (certificate is inherited but not the protocols).

The cipher suites must be set independently for each VirtualHost, otherwise you will end up with the default list, including a lot of insecure ciphers. Also, be aware that older clients that do not support Server Name Indication (SNI) will always use the default host (unless blocked using SSLStrictSNIVHostCheck), which can confound your testing.

In short, you should be able to specify custom cipher suites and certificates for each virtual host, but until the bug is fixed do not expect correct behavior with custom protocols for each virtual host.

I encountered this problem with Apache 2.4 and modssl with OpenSSL 1.0.1k, and I expect that Apache 2.2 would be subject to the same issues.

Update (October 2016): The OpenSSL bug was marked as resolved on October 13, 2016. However, it was part of a mass closure of open issues and although a 'partial fix' was supplied, the problem was never fully addressed.

Update (April 2018): The resubmitted OpenSSL bug now has a patch available (as of April 9, 2018). This patch will change the behavior of Apache instances configured with multiple SNI virtual hosts:

Reject connections not conforming to vhost SSLProtocol

This was developed and tested with 2.4.27 and in production with that version. The patch was modified for 2.4.33 and lightly tested.

This checks the version of the connection against the SSLProtocol configured for the virtual host that is matched based on the SNI. Because the connection is initially made with the SSLProtocol configured for the default host for the port, the default host must include all protocols that will be supported by any virtual host.

This patch adds an additional return status of APR_EMISMATCH to the init_vhost function so that the ssl_callback_ServerNameIndication callback registered with OpenSSL can return fatal alert SSL_AD_PROTOCOL_VERSION. This is intended to produce the same response to the ClientHello as having an SSLProtocol specified that does not include the version in question. Because the SNI callback is called during the processing of the ClientHello and before a response is produced, it seems to do exactly that.

If you suddenly see messages of the following format:

Rejecting version [version] for servername [hostname]

Then you should double-check your SSLProtocol for your default host.

  • The additional information added by @anx regarding SSLStrictSNIVHostCheck is much appreciated. However, it should also be noted from the cited documentation that If set to on in any other virtual host, SNI unaware clients are not allowed to access this particular virtual host. – vallismortis Oct 16 '17 at 1:15
5

You can have different SSL protocols for each Vhost if they are listening on a different IP.

Example with a specific host allowing TLSv1 and all others only allowing TLSv1.1 and TLSv1.2 - and one allowing TLSv1.2 only:

<VirtualHost *:443>
  SSLEngine On
  SSLProtocol All -SSLv2 -SSLv3 -TLSv1
  ServerName test.mysite.com
  # bunch of other stuff omitted
</VirtualHost>

<VirtualHost 10.0.0.2:443>
  SSLEngine On
  SSLProtocol All -SSLv2 -SSLv3
  ServerName test2.mysite.com
</VirtualHost>

<VirtualHost 10.0.0.3:443>
  SSLEngine On
  SSLProtocol TLSv1.2
  ServerName test2.mysite.com
</VirtualHost>
  • Also, if you need it for testing purposes only, you could use another port instead of another IP, e.g. common alternative HTTPS port 8443. – Esa Jokinen May 16 '17 at 12:30
0

If you are using the Server Name Indication (SNI) with your vhost, indeed, you can't define multiple SSL version.

However, if you are using a dedicated server, you are probably able to add another IP address to your server. By this way, you will be able to use a different SSL version per IP. You just have to change your vhost settings as expected IP:443.

-2

Or you can use:

SSLProtocol TLSv1 TLSv1.1 TLSv1.2

I was tested on many servers and works for me! You can test your site in this website

  • 4
    This SSLProtocol line only looks like it is working because Apache doesn't complain about it. In reality, only the SSLProtocol in the first VirtualHost entry is used. – vallismortis Aug 7 '15 at 11:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.