SSL on Apache: How to Gain the Most from Your Certificate

May 12, 2015 | Jindřich Zechmeister

The use of an SSL certificate won't automatically ensure maximum safety for the server's visitors. The HTTPS protocol needs to be set up correctly so that the encryption methods used correspond with the current safety requirements. This article will explain to you how to best set up HTTPS on Apache and thus make the best use of the certificate

Web server security

How to Fine Tune Apache Security

The following steps will help you set up Apache server in accordance with current safety recommendations.

Disable Old Protocols SSLv3 and SSLv2

The SSL protocols are very old now and not considered safe anymore. The older of the two, SSLv2, has been considered unsafe for a while. A practical attack on SSLv3, which is usually allowed on servers only because of its compatibility with older clients, has been described recently. We informed you about this vulnerability called POODLE in the article How to Deal with POODLE SSLv3 Vulnerability. The outdated SSL protocols are not necessary anymore and only present a risk on servers (attackers use them for so called downgrade attack). They have been replaced by TLS 1.0 – 1.2 protocols which are used by modern browsers. Therefore, disable both old SSL protocols on the server and don't use them.

Set up New Order of Preferred and Strong Ciphers and Disable Weak Ones

First, client and server agree on a way to encrypt. Besides other information, they exchange a list of ciphers they support and the order in which they prefer them. The process of establishing encoded communication between client and server is called Handshake. Preferred encoding algorithms and the order they will be offered to the client are set up in Apache configuration on the server. It is an important security aspect because old and weak ciphers are ineffective and easy to break. You will find the setting in the configuration file on the given web. The setting of active web with SSL on Ubunt server is located in /etc/apache2/sites-enabled/default-ssl.conf. Find SSLCipherSuite directive, where the order of ciphers is given. If you want to disable any of them, just put an exclamation mark in front of its abbreviation. You can get inspiration from the experts of SSLlabs, who consider this setting suitable:

SSLCipherSuite "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS"

You can copy this directive into your Settings unless you have your own preference.

Disable Use of RC4

One of the steps towards higher security is limiting the use of RC4 encryption, which is related to the BEAST attack. The set up of SSLCipherSuite directive described above disables RC4. If you use your own directive, it is enough to put an exclamation mark in front of RC4 and disable it that way. However, this has a disadvantage: after disabling RC4, IE and Windows XP users won't be able to get to the server (this doesn't concern other browsers). This shouldn't be a problem in terms of compatibility though, because Windows XP is no longer a supported system.

Regenerate Certificate with SHA-2 Signature

Our magazine has reported on the end of SHA-1 support a few times, most recently in relation to the end of support in Chrome and the unpleasant browser warning. You will find more information in the article Google Chrome and SHA-1 Certificates: End of Support. Microsoft will cease supporting SHA-1 certificates on 1/1/2016. The upgrade of SHA-1 certificates to SHA-2 certificates is therefore inevitable. SSL market users can regenerate their certificates with SHA-2 for free and automatically (called reissue). Reissue can be done in customer administration in the certificate detail. After issuing a certificate with a new SHA-2 signature, it is also necessary to use the new Intermediate certificate, which SSL market will send you with the certificate. Root authority certificates are staying with SHA-1 for now and remain unchanged because their signature doesn't need to be verified. Browsers won't alert about root certificates with SHA-1 either.

Deploy (Perfect) Forward Secrecy

Forward Secrecy key exchange is a method that prevents decryption of once encrypted communication in case of knowledge of the primary key (for example, during decryption eavesdropping). The prerequisite for Forward Secrecy are two methods of key exchange, DHE and ECDH. RSA doesn't support Forward Secrecy. You can find out more about Forward Secrecy in the article Perfect Forward Secrecy – Prevent Eavesdropping of Your Server. Therefore it is necessary to set up high priority for the DHE and ECDHE key exchange methods and prefer them to RSA (or disable RSA). Visitors will then be able to profit from the support of Forward Secrecy on your server. If you use the SSLCipherSuite directive from this article, your server will support Forward Secrecy.

Verification of New Settings

After every server setting adjustment it is necessary to run a test which will show if the changes have been made correctly and if the server is working properly.

Test of HTTPS Settings

For the SSL/TLS test on your server I recommend probably the most advanced tool: SSL Server Test by Qualys. Besides detailed analysis it also assesses the security settings of the server which it summarizes in a mark. The same as at school, servers with the best settings get an A and F means insufficient security. If you follow the advice above, your Apache server will get an A and you will know you have done enough for the safety of your visitors.

Test of HTTPS Compatibility

Compatibility is a problem often solved in SSL settings. The verifier mentioned can help solve this problem because it stimulates the handshake of various combinations of browsers. If the handshake is successful, the arrange cipher is shown. If the connection was unsuccessful, you will see the error: Fail: Protocol or cipher suite mismatch. Combinations of Android 2.3.7. and versions 4.x.x, Internet Explorer on XP and newer Windows, various browsers, Java, OpenSSL and web spiders are tested. You will therefore know which visitors can connect; if the settings were too aggressive (e.g. TLS 1.2 only), they can be lowered to achieve better compatibility.

Sources:

If you are interested, there is more information in the following articles.

Ing. Jindřich Zechmeister
TLS certificate specialist
Certificated Sales Expert Plus
e-mail: jindrich.zechmeister(at)zoner.com