Ubuntu, CentOS, RedHat ve Debian ‘da SSLv2-3 Nasıl Disable Edilir?

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.

1. Apache
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“.

2. Nginx
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:

ssl_protocols TLSv1.2;
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

3. Exim
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.

5. Dovecot
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.

Yeteneklerini kullanarak başarılı olan insanlarla bir sorunum yok, sadece başarının en üst hedef olmadığını düşünüyorum. Özgürlük, bilginin paylaşılması - genişlemesi başarının, kişiselliğin ötesinde şeyler. Kişisel başarı yanlış değil ama etkisi sınırlanmış, eğer gerektiği kadarını elde ettiyseniz hala bunun için açlık duymak ayıp, tabii doğruluk, güzellik ve adalet için durum tam tersi. / Richard Stallman