You should secure your web site using TLS. No, that`s not a typo, it`s TLS and not SSL. SSL is dead and should not be used anymore. Praise TLS. This may sound complicated at first, but it`s not. First step is to deactivate HTTP and activate HTTPS. How to do this depends on your web server. Luckily, there are a lot of good documentations on this available. For free. Thanks Internet. To help you evaluate your setup, there is an online service available that tests your HTTPS setup: ssllabs.com. Just enter your server name and you get a result: A to F. You have a secure site when you get an A. Problem with this documentation is that is shows you how to activate TLS, but not how to get to a setup secure enough to earn you an A rating from SSL labs. Now, what is a secure setup for TLS? You can argue here for eternity. So (too?) many parameters available. Let me try to show you what I did to get an A rating.
First, let`s take a look at the SSL labs service and check some sites to get an understanding of how the service works. SAP`s site (sap.com) get`s an A rating:
If something is wrong, the rating is downgraded and a justification of the rating is given. For instance, if you run a check against service.sap,com (18.104.22.168), you get a C rating.
The problems that caused the C rating are all related to protocol support. Don`t worry, service.sap.com is the old support site, support.sap.com get an A rating. Only showing this here to demonstrate the impact the supported protocols have on the rating. The other 3 criteria were rated equally. Some sites can get an even worse result (that site is not related to SAP).
While it is nice to know that an A rating is possible, how to get one for your own server? Let me show this using my very own web server as an example: https://www.itsfullofstars.de:8081
First step is to get a valid certificate. This is done by creating a CSR and send it to a CA. To create the CSR, you can use openssl.
openssl req -new -newkey rsa:4096 -nodes -keyout itsfullofstars.de.key -out itsfullofstars.de.csr -sha256
The output is a key file and a CSR file. The certificate is of 4096 bit strength and uses SHA-256 as signature. Send the CSR to your CA (I use StartSSL) and you get back the certificate (CRT), and normally also the intermediate certificate.
The server certificate is the CRT file. It is already in PEM format. To make this clear, I renamed it to .PEM. Uploading the certificate to the web server and activating it in the Apache configuration for HTTPS.
Base Apache configuration
SSLEngine on SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2 SSLCompression Off SSLCipherSuite HIGH:MEDIUM:-RC4:-EXP:!kEDH:!aNULL SSLCertificateFile /etc/ssl/certs/www.itsfullofstars.de.2016.pem SSLCertificateKeyFile /etc/ssl/private/itsfullofstars.de.2016.key
Running SSL Labs test gives now a B rating.
The rating is capped to B because of an incomplete certificate chain. Remember the 1_root_bundle.crt file delivered by the CA? That`s the intermediate CA certificate. That`s the certificate the web server is not providing, but should. Add the parameter SSLCertificateChainFile to Apache`s conf file.
Running SSL Labs test gives now an A- rating.
Already A- for just fixing the certificate chain problem. The report shows that I do get an A- and not better because the web server is not supporting forward secrecy (PFS). It’s not like I`ll need to have forward secrecy. I do not run an e-commerce site or let people log on.
What is PFS? It protects your users as it makes it really hard to decrypt the traffic. To decrypt the session, the session key must be known. In case the session key was created using a weak algorithm (e.g. RC4, RSA), all it takes is the server’s private key. If someone gets access to my server private key, an attacker can decrypt all traffic (even recorded one). Changing the algorithm to ephemeral Diffie Hellman makes this more secure, as the attacker needs to crack the session key. In my case the session key is exchanged with a 4096 bit certificate, should take them some time. As the session key is unique per session, the attacker will have to decrypt the key for each session. Just having the server’s private key is not enough.
While forward secrecy is a little bit of an overkill for my site, it`s possible to do and “it`s too much” does not count in regards to security. Therefore, I will activate forward secrecy on my server. Basically, PFS is done by activating the correct cipher suites and instruct the web server to ignore what the browser wants to do. This enforces the browser to use the ephemeral DH ciphers send by the server and those allow PSF.
SSLEngine on SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2 SSLCompression Off SSLHonorCipherOrder on SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+AESGCM EECDH EDH+AESGCM EDH+aRSA HIGH !MEDIUM !LOW !aNULL !eNULL !LOW !RC4 !MD5 !EXP !PSK !SRP !DSS" SSLCertificateFile /etc/ssl/certs/www.itsfullofstars.de.2016.pem SSLCertificateKeyFile /etc/ssl/private/itsfullofstars.de.2016.key SSLCertificateChainFile /etc/ssl/1_root_bundle.crt
Running SSL Labs test gives now an A rating.
Mission accomplished, my web site is now rated A by SSL labs.