TQ
dev.com
Blog about software development
29 Jul 2017 - by 'Maurits van der Schee'
After postponing setting up SSL for this site for about one and a half year I finally did it. Like anything I do with this blog I wanted to make it fast and secure. In order to find out whether or not I configured SSL correctly I used SSL Labs. They have a form where you can enter your domain. After a minute or two and you will receive an extensive report on your SSL setup (for free). The report is also summarized in a rating and the highest rating is an "A+". I configured this site to receive such an A+ rating and in this post I will explain how you can do the same.
One of the most important things that you need to configure are the cipher suites. There are several ciphers that are enabled by default, but are no longer secure. One of the ciphers that is often enabled, but should not be used is "RC4". How to disable RC4 and other insecure ciphers can be found on the site Cipherli.st. It will tell you exactly which lines to put in the configuration file of your webserver in order to get an A+ rating on SSL Labs. It also applies some other best practices, such as "OCSP stapling" and headers against "Clickjacking", "Cookie hijacking" and "Content sniffing".
"OCSP checking potentially impairs users' privacy and slows down browsing, since it requires the client to contact a third party (the CA) to confirm the validity of each certificate that it encounters." - source
"The key to speeding up OCSP is to get rid of the requests that go back to the CA. Rather than needing to request the OCSP response from the CA directly, the OCSP response can be included in the initial SSL handshake (step 3 in the example above). In this sense, the OCSP response is "stapled" to the initial SSL handshake. While it seems like this approach would be less secure, the response is signed by the CA's root certificate so the browser can verify its authenticity even if it is not delivered directly from the CA's OCSP server" - source
The "X-Frame-Options" headers protects against "Clickjacking" by disallowing embedded into other sites (source). The "Strict-Transport-Security" header prevents "Cookie hijacking" by automatically converting all attempts to access the site using HTTP to HTTPS (source). The "X-Content-Type-Options" header disabled the dangerous "Content sniffing" that IE browsers do that may turn a non-executable file into an executable one (source).
Next I used Mozilla Observatory to further scan the site and I have found three more headers that should be added. First is the "Content-Security-Policy" header that protects against "Cross site scripting (XSS)" and second is the "X-XSS-Protection" header protects against the same (source). And last but not least the "Referrer-Policy" header that improves privacy by protecting against an information leak via the "Referer" header when navigating away from the site (source). I chose not to load the HPKP (HTTP Public Key Pinning) header that could protect against "man in the middle" attacks when the CA is compromised, as it seemed that you could easily break the site for everybody for a long time (source).
If you also want to serve your site over SSL you now know how to do this. I shamefully admit that I use a paid certificate from Comodo, but you may do better and use a free Let's Encrypt certificate. All you have to do is setup a cron job that takes care of the monthly certificate renewal.
PS: Liked this article? Please share it on Facebook, Twitter or LinkedIn.
Subscribe