Bobcares

How to Disable SSLv3 in Linux (Ubuntu, CentOS, RedHat, Debian)

by | Nov 21, 2018

A stitch in time saves nine!

This is perfectly applicable in the case of server security vulnerabilities.

SSLv3 is a weak method of data transfer between servers. And this can cause leakage of sensitive data from the server.

That’s why, we help our customers to disable SSLv3 on their servers as part of our Support Services for Web Hosts.

Today, we’ll discuss on how to disable SSLv3 in various Linux operating systems.

 

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.

  1. Edit the file /etc/apache2/mods-available/ssl.conf.
  2. Add the line “SSLProtocol All -SSLv2 -SSLv3
  3. 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

ALL:!ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-SSLv3:-EXP

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:

smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3

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.

 

Conclusion

Nowadays, disabling SSLv3 on servers is a requirement to avoid hack attempts on servers. The exact sequence of steps varies with the type of server. Today, we’ve discussed how our Security Engineers disable SSLv3 on different applications on the servers.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

SEE SERVER ADMIN PLANS

var google_conversion_label = "owonCMyG5nEQ0aD71QM";

4 Comments

  1. Jim C Miotke

    Sijin, I just wanted to let you know that, after searching many sites, I found the solution to my problem in your excellent article above. Thank you!

    Reply
    • Sijin George

      Hello Jim,
      Glad to know that article helped 🙂

      Reply
  2. Buti Doubata

    Thanks a lot. this saved me a lot of time.

    Reply
    • Hiba Razak

      Hi,
      Thanks for the feedback. We are glad to know that our article was helpful for you 🙂 .

      Reply

Submit a Comment

Your email address will not be published. Required fields are marked *

Never again lose customers to poor
server speed! Let us help you.