It seems that Firefox is doing a better job at warning users that a website is insecure because it was only through using Firefox that I even thought to secure my website. I couldn’t believe that this only dawned on me when I logged into the my WordPress.
Securing my blog was important to me because of course when you log into a WordPress website, if somebody is listening to the connection between your browser and your server and there’s no encryption, you’re open to a whole slew of types of attacks such as Man-in-the-Middle attacks, identity theft, information leakage, and so much more. So, I went on a journey to secure this connection.
There was no way in hell that I was going to pay a company like DigiCert or Symantec for an SSL certificate when I have never played with SSL before meaning there was no guarantee I would be able to set it up in the end making that a total waste of money, and when this blog makes literally no money at this point in time. With that being said, I chose Let’s Encrypt, a free and open-source SSL encryption alternative that’s easy to set up and install for newbies to SSL like me.
Once configured, I was met with the option to test my website’s SSL encryption set up with Qualys’ SSL Report tool at ssllabs.com, which was the exact time where I was met with a C rating. Wait…what? I can have poor encryption? I thought it was just encrypted or not encrypted. Turns out there’s a whole slew of things that could be wrong with your SSL encryption configuration.
I was met with a total of three errors. The first of which was telling me to disable SSLv3 due to the POODLE vulnerability that existed in that version. Finding out how to do that was simple enough and so I simply set
SSLProtocol ALL -SSLv2 -SSLv3 which worked to mitigate this first issue and in turn the issue with Forward Secrecy as seen in the screenshot above, but then there was another one. This one told me that RC4 cipher was available “but only on older protocols”. This struck me as odd so I set out to disable the RC4 cipher (in the end, this effort would prove to be irrelevant to the issue I had).
The first solution I found was to straight up disable RC4 which was done by adding
!RC4 to the
SSLCipherSuite section of my
httpd.conf. I tried this and at first, it seemed to work and gave me an A rating, yay! So I left it for a while, but then I came back and did the test and I was back down to B. What’s going on? I tried some more stuff and added
-TLSv1 -TLSv1.1 so the
SSLProtocol entry and still, no dice. After posting on some forums and emailing a few of my SysAdmin buddies, I stumbled upon this file in the
conf.d directory for httpd called
ssl.conf. Lo-and-behold in this file, there are different settings specified. I tried mirroring the settings I had in
httpd.conf in this one, retested and I get an A+ rating, fantastic!
In the end, I get top notch security while supporting most of the browsers that have been released in the last 7 or so years.
Here’s what I’ve learned from this experience:
- Don’t trust default set ups
- Learn the configuration options for any given piece of software, inside out
- Security and compatibility do not go hand-in-hand
Sound off in the comments below if you’ve had a similar experience.