New Release: HTTPS Site Migration

Moving Over to a Secure Website

Our sysadmin has been very busy lately and has now completed the migration from http over to https which is more secure for our visitors with a secure connection being the default. The migration was quite simple because our code base does not use magic numbers or strings so all URL are references to a variable which is replace with the URL contained in the configuration.

Secure Website

Enabling a secure connection by default is the way forward so we decided to make the move over now. We use Apache SSL and SPDY as a module to help speed up connections from clients who support the protocol.

Testing has been accomplished by using a clone of the live server running inside a VM instance, we like to use Virtualbox for VMs although it is now owned by Oracle not Sun it is still open source and a great bit of software that I find very useful.

Setting Up Apache

We already have a setup for the secure site because it is used to process our payments securely although all other traffic is redirected to the non secure site.

We edited /etc/apache2/mods-enabled/ssl.conf to configure the protocols we support and to disable ones which have vulnerabilities like POODLE. Here is a snipit of the configuration file.

SSLProtocol all -SSLv3 -SSLv2

SSLHonorCipherOrder on

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"

Next we needed to install a copy of mod-spdy for any user agents who support it

wget https://dl-ssl.google.com/dl/linux/direct/mod-spdy-beta_current_amd64.deb
dpkg -i mod-spdy-beta_current_amd64.deb

Our rewrite file on the non secure site looks like this now it just 301 redirects all requests to their secure equivalent.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

SPDY for Apache

Installing this has really improved our website response time and it just seems snappier than the non secure site we installed a mod-spdy package but SPDY only works with modern browser but we do not support old browsers any more so this is not a problem.

The source code for it and the packages are available and it has now been donated to the Apache foundation from Google. You can download the 64bit deb package here this is the one we used since we have 64bit Debian.

Site Config

This was simple and we only have two string representing the sites full URL one in the main PHP config file and another in the SiteConfig JavaScript class file. This approach also simplified when we moved over the domain name from www.ucarewecare.com to www.carehomes.net.

Conclusion

Porting our website code over to HTTPS has been quite a simple process in the end this was helped by us not using string literals as our URL and instead using a token which uses a value in the sites configuration so all we did was change one string and they all changed.

Remember to never use magic strings or numbers in your code and abstract away a bit because it does come in handy sometimes.

Server Updates and Fixes

Fixing Bugs and Vulnerabilities

We have been doing some administration on the server and we have decided to enable Perfect Forward Secrecy on our SSL site to improve our security rating which can be viewed using this website we also modified some of the ciphers used.

Our server has also been patched and configured to cover heartbleed, shellshock and POODLE vulnerabilities which have all been made public and fixed already.

Bugs

Perfect Forward Secrecy

Enabling PFS makes our site more secure due to a new key being generated for each session rather than the same key being used. Again configuring this is quite simple.

Poodle

SSLv3 was disabled to cover the POODLE vulnerability which makes man in the middle attacks possible this process is simple and there is a good document about it here all you need to do is disable -SSLv3.

Shellshock

Bash has been patched to the most recent version although I would think we are not affected by this attack vector but it is better to be safe.

Heartbleed

This one was patched up a long time ago and we have no reason to believe that any of our private keys were leaked because it would be quite an obvious intrusion which we have not noticed.

Future Improvements

One improvement we will be implementing is using SHA256 when creating the certificate rather than SHA1 which is a weaker implementation this will be done when we update our SSL certificate.

We plan on moving the main website over to HTTPS with SPDY soon because we feel this is the way the web is moving and it offers more speed and security so it makes sense.