Below is basic guide for changing SSL/TLS cipher suites that Windows Server IIS and Linux Ubuntu Apache2 use. Allowing only secure ciphers to be negotiated between your web server and client is essential. This guide will go through how to change and select the different ciphers for both Windows server 2012 R2 and Ubuntu 14.04 in order to help mitigate the vulnerabilities in the SSL/TLS protocols.
Web servers whether they are windows or Linux based start there lives from within the IT Team, Development team or Joe blogs out on the net, as a fresh install (or gold image) of either a Windows or Linux Server whether it be a VPS out in the cloud or an on premise physical or virtual server. From here on hopefully it follows a rigorous build guide for security hardening (GPO, Microsoft Security Compliance baselines, Firewall, HIPS,AV, unused services, permissions, admin/user account separation etc etc – that’s another post in its own right) – however all too often once the server is built and even fully patched the cipher suites within schannel from Microsoft or OpenSSL for Linux get ignored and forgotten about once the server is commissioned.
SSL version 3 is considered insecure and should be disabled, there are also various other cipher suites that also shouldn’t be used as they are also now considered vulnerable.
As an example in certain scenarios where the TLS 1.0 protocol is used, connections that use cipher block chaining (CBC) mode should also not be used. A sophisticated attacker is able to decrypt data using this method that matches a specific scenario, this is known as the BEAST vulnerability. Other vulnerabilities also exist, look them up, know what they are.
Whilst recommended cipher suites constantly evolve a minimum baseline should be set and updated periodically and then baked into the security hardening policy or build guide. This should not only be set at the time of build, administrators should constantly update the cipher lists in order for their systems to evolve with security recommendations from the industry as well as with their own business requirements.
Changing Cipher Suites in Linux Ubuntu 14.04
Assuming that you are already using HTTPS we will be working in the ssl.conf file located here:
The main focus will be around the three lines of code below:
SSLProtocol all -SSLv3 -SSLv2
SSLHonorCipherOrder on – here we are specifying the prioritization order from the server of the cipher suites it should actively use.
SSLProtocol all -SSLv3 -SSLv2 – here we are specifying the protocols to use, so in this example we are allowing all SSL Protocols except SSLv3 and SSLv2 with the ‘–‘ character before each. This is a key line as we are disabling SSLv2 and v3 here.
SSLCipherSuites – here we are specifying the various cipher suites to use with keywords that match the cipher suites in OpenSSL. Above is an example of cipher suites that are selected from the TLS protocol using the keywords listed. You should select which ciphers you want to support here, ideally inline with industry standards and within your business requirements.
: seperates the keywords
– Removes all cipher suites that have this appended to them
! Removes all cipher suites permanently and doesn’t allow them to be added back in due to another keyword.aNULL Stipulates no authentication
eNull Stipulates no encryption
So for example; you could construct the following :!RC4 to permanently remove RC4 and not allow it back in should another keyword specify it.
Its important to remember here that Apache2 is using OpenSSL and so you should be selecting cipher suites that are supported by your OpenSSL installation. At this point it would be a good idea to look into which version of OpenSSL you have and which ciphers are supported by that version. For example if you have an older installation of Linux and thus OpenSSL you may not be able to support the likes of TLS 1.2 and 1.1. A few commands to verify what ciphers you have available and the version of OpenSSL are listed below, also remember to consult the man pages in Linux for further syntax:
openssl -v ALL
Apache2 will need to be restarted in order for the new cipher suites to take affect. This is anout of hours job as brief downtime will be required from your business.
Changing Cipher Suites in Windows Server 2012 R2
Disabling deprecated ciphers suites is just as fun in windows, honest. For this example I will be using a fresh install of Server 2012 R2 on a virtual machine. Here we will see the before and after affects of disabling the likes of SSLv3. In order to test this I have simply setup IIS and presented a basic HTML page and added SSL/443 in the bindings with the use of a self signed certificate. A self signed certificate is appropriate in this instance as we just want to negotiate a secure connection. Disabling the cipher suites in windows server 2012 R2 along with the previous versions of windows is achieved through the registry, under the following reg keys:
Rather backwards – you have to add a registry key per cipher in order to remove the cipher from schannel. The majority of the registry keys that need to be added are for the ‘CipherSuites’ and ‘Protocols’ folder.
Below is an SSLscan of the webserver before the ciphers were altered we can clearly see SSLv3 displayed in the cipher list.
You can manually add the keys to the registry or alternatively there is very useful tool that will do it for you with a nice GUI interface called IISCrypto from Nartac Software. As can be seen from the below screen shot the tool allows you to specify very specifically what cipher suites, protocols etc. you want your webserver to use. There are also some predefined settings that can be selected such as ‘Best Practice’, ‘FIPS 140-2’, ‘PCI’ and ‘Defaults’ this simply selects various ciphers based on the settings you selected.
Here I have selected the ‘Best Practice’ setting which has removed our goal of removing SSLv3.
Any changes to schannel will require a reboot before the new settings can take effect, IIS Crypto warns you of this after you have clicked apply. This again is something to consider as down time will be required.
Scanning the server after the reboot shows the following:
As we can now see our WINWEB server is now not displaying SSLv3 as an available Protocol and its subsequent cipher suites.
It clearly goes without saying you should first test these methods for yourself in a safe test environment first before diving into your main production web servers.