How to check if SSLv3 is enabled?
The first step to do when you hear about any new vulnerability is to understand whether it is applicable for your server.
For SSLv3, an easy way to do this is to check connection on port 443 of the server using the command :
openssl s_client -connect example.com:443 -ssl3
Replace example.com with your server name and 443 with your ssl port.
If the server is safe, the result would show up as
routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Any result other than this means that server supports SSLv3.
How to disable SSLv3 in Linux?
When you know that the server is a possible target, there is a need to act fast to avoid hackers exploiting this vulnerability.
Unfortunately, a simple ready made patch for this do not exist.
The only possible way is to disable SSLv3 in the different applications used on the server. Additionally, the exact steps differs according to the type of server.
Let’s now have a close look on how our Support Engineers disable SSLv3 on each of these applications.
On Apache web server, to disable SSLv3, we edit the Protocol value in the configuration file. Then to make the changes effective, we need to restart the service.
The location of the configuration file and the service restart command varies as per the type of server.
For example, in CentOS or RedHat 4,5,6 server versions, we add the following line in the file /etc/httpd/conf.d/ssl.conf
SSLProtocol All -SSLv2 -SSLv3
This means that all protocols except SSLv2, SSLv3 will be supported on the server.
After doing this, we need to restart Apache with the command:
service httpd restart
In Centos/RedHat 7.x+ servers, Apache restart command would be:
systemctl restart httpd.service
Similarly, On Ubuntu and Debian servers, we need to do the following changes as root user.
Edit the file /etc/apache2/mods-available/ssl.conf.
Add the line “SSLProtocol All -SSLv2 -SSLv3“
Run the command “service apache2 restart“.
To disable SSLv3 in another popular web server, NGINX, we need to edit the configuration file nginx.conf.
And we add the following line to the server directive:
This is followed by a service restart which again depends on the operating system of the server.
The exact command for restart in CentOS servers would be
service nginx restart
Exim mail server also make use of secure protocols in handling emails. As a result, we need to disable SSLv3 in Exim too. To do this, we need to make changes in the exim configuration file at /etc/exim.conf.
Here, we modify the parameter tlsrequireciphers that instructs exim on the way to handle mail traffic.
To totally disable SSLv3, we set it as
Then we restart the exim service on the server.
In cPanel servers, the same changes can be done from the WHM panel.
Log in to WHM → Service Configuration → Exim Configuration Manager → Advanced Editor
Here, we make and save the changes, followed by an Exim restart.
4. Postfix SMTP
Similarly, Postfix need changes only when in mandatory SSL mode. In this mode, all email traffic is done via SSLv3.
So, our Security Specialists adjust the postfix configuration at /etc/postfix/main.cf to reflect the following change:
After the restart of Postfix, mail server will not use SSLv3 or SSLv2.
We need to make similar changes in the Dovecot configuration to disable vulnerable protocols. For Dovecot versions above 2.1, add the following line to /etc/dovecot/local.conf.
ssl_protocols = !SSLv2 !SSLv3
Then we restart the service with the command
service dovecot restart
Issues noted while disabling SSLv3
From our experience in managing servers, we see that often disabling the vulnerable protocol may not work correctly.
For instance, on a CentOS 6 server, there was problem with disabling of SSLv3 protocol.
Here, the correct SSLProtocol values set in the file /etc/httpd/conf.d/ssl.conf, SSLv3 was still enabled. This happened because Apache version 2.4.6 on the server was ignoring this value in the configuration of each website.
So, to fix the problem, our Support Engineers moved the line “SSLProtocol all -SSLv3 -SSLv2” from the file /etc/httpd/conf.d/ssl.conf to main apache file at /etc/httpd/conf/httpd.conf.
Consequently, we verified the configuration and restarted Apache.
In addition to this, we have seen cases of service failures because of human errors while editing the configuration files. The solution here is to verify the configuration before the restart of service.