Client support vs PCI 3.1 Compliance

Back in December 2015 the Payment Card Industry Security Standards Council (PCI SSC) agreed it was time to start disabling support for old and insecure SSL protocols.

TLS 1.0 needs to be switched off before the 30 June 2018.

While many of the old SSL protocols have been disabled now due to vulnerabilities such as POODLE and Heartbleed this will be the first time a protocol has been disabled that is still being used by some old browsers without a known vulnerability.

A large number of older clients will break when you disable TLS 1.0, including:

  • Android 4.3 and older
  • Internet explorer 10 and older
  • Java 7 and older
  • Safari 5.1.9 / OS X 10.6.8
  • Safari 6.0.4 / OS X 10.8.4

We recommend you look at your analytics and see how many customers will be affected before making this change.

If you are in a position where you cannot disable TLS 1.0 yet, there are alternatives, your PCI provider will accept a plan to defer this work up to the 30 June 2018. Another solution could be separating your checkout pages from your website, this way older browsers can still browse most of you site.

Check out the PCISSC blog post for further reading.

Are you are concerned about disabling TLS 1.0? Running into PCI compliance issues? Unhappy with your site security? Drop us a message and see how we can help you.

Feature image made by costculculator licensed CC BY 2.0.

Quick/Easy Wins For Your Server

There are three main stages in a servers lifetime; building/configuring, usage, and being decommissioned, with the usage section usually being by far the largest section in terms of time. For this reason, it’s obviously important to make sure that the server is optimally configured, secure and able to be reproduced/replaced easily in the event of a disaster.

Depending on the company owning/running them, servers can range from clean and efficient pieces of machinery, to rusty old lawnmowers that need a bit of coaxing to start. There are some quick wins that offer a chance to move yourself from the second extreme into the first. By carrying out a fairly quick audit covering some main areas, you can get yourself some great returns for not much work.

Security

If you are running an insecure server on today’s internet, it’s not a question of if you have a system security compromise, it’s a matter of when. One of the first things we check upon carrying out a server audit is if the system is being actively patched, what levels of patch are being applied (all updates vs just security vs none at all), and how often the system is being patched. Furthermore, we also check the if non-system software, such as CMSs like WordPress/magento, or other utilities like phpMyAdmin, are being kept up to date. Actively keeping all system software up to date is one of the easiest things you can do in keeping systems secure, but it makes the job of a potential attacker much, much harder.

Another easy-win for security is the use of a firewall. Firewalls provide a set of rules determining who may connect to your server and on what ports/protocols. This allows you to greatly reduce your attack surface, by only exposing services that absolutely need to be exposed. For example, on a web server, you’d really want to expose ports 80 and 443, for HTTP and HTTPS respectively. However you may also want to expose port 22 (SSH) for remote management. This can be locked down to only allow certain IP addresses for this management. Depending on how security conscious you are, outbound firewalling can also be implemented, allowing you to control what other systems on the internet your server may talk to.

Backups

Everybody knows what backups are, but sadly not everyone understands their importance. Backups are critically important, as they allow you to retrieve your data should the worst happen with your server and it becomes inaccessible. Mistakes also happen, and having easy to access backups can save your so much time by allowing you to just roll back your changes, instead of taking a long time trying to unpick your errors and rectify them, often whilst under the pressure of having a broken server/websites/application etc.

The granularity of backups is also an important aspect to consider. Many server providers offer a backup service, but what people often fail to realise is that if you want to restore these backups, you have to restore everything, you don’t get to decide what’s rolled back and what’s kept. This can be a real pain if you have to lose a weeks worth of work just because you updated the wrong row in a table. This is why we also recommend that separate backups are kept for each “area” of data. For simple web server builds, we would typically configure backups of a sites web directory, and separate backups of the site’s MySQL databases(s).

It’s also important to keep these off-site; backups aren’t much use if they’re stored on the same server they’re backing up.

Configuration/optimisation

There are a huge number of configuration tweaks and changes that can be made in order to get more performance from your server, some being one-line changes, some involving a complete rebuild of your infrastructure. There are some however that can be done in a matter of minutes that can have huge benefits going forward. The main one we’re going to mention is resource limits.

Popular web-servers, such as Apache and nginx, allow you to set how much of the total system resources they are allowed to consume. In some cases it may seem obvious that you want them to be able to consume as much as they want for the best performance right? Wrong. If a server gets really busy, say your cat video has gone viral, there is a good chance people are going to be asking your server to work harder than it’s able. If you do not set appropriate resource limits, your server is going to use up every last drop of available memory/CPU, which results in it becoming unusably slow, and processes often get killed in order to free up memory.

We’ve quite often seen the MySQL database server process get killed, as it can use up a lot of memory. If your database goes offline, you’re gonna have a bad day.

If any of the above sounds like something you want to do, but you’re not sure where to start, then contact us and we can certainly help you with the points mentioned, along with many other aspects that we check in our server audits.

Feature image by Crystian Cruz under the CC BY-ND 2.0 license.

Switching a site from HTTP to HTTPS

We love HTTPS and with its Security, Speed, SEO and Accessibility you should upgrade now!

Having helped customers through this process many times we have learnt a thing or two about how to make the process go smoothly. So here is our …

4 step HTTPS upgrade guide

 

1) Get a certificate

You can get an SSL certificate from 100’s of different resellers, we have a hefty spreadsheet to keeps track of the best.

There are many types of SSL certificate from various Certificate Authorities. For basic domain validated certificates we are a big fan of Lets Encrypt.

If you don’t know what certificate you need you can read our other articles (link above) or contact us and we’ll be glad to help.

2) Set up your web server to listen to HTTPS

This is an important step I wanted to split out, this doesn’t mean stop using HTTP. Just because you are ready for HTTPS doesn’t mean your site is and jumping over immediately can often cause unforeseen issues.

All good web-servers can listen to multiple ports at once so you can continue running your site over HTTP while you are working on HTTPS.  If this process takes more than a day then you will probbaly want to firewall your new site off from the rest of the internet until it’s up and working as you wish.

At this step you can set up all sorts of new cool technologies. If you ever thought HTTPS was slower than HTTP wait until you try HTTP/2.0.

3) Configure the site to use HTTPS

This is when you fix those unforeseen issues I mentioned earlier, people often forget that HTTPS is very strict when it comes to downgrading the connection and will block anything loaded over HTTP. This often ends up with the page missing CSS or Javascript.

Another catch that is often missed is getting your site to generate links as HTTPS. If the site continues to generate HTTP links each visitors click and item load happens twice once to redirect to HTTPS and again to load it over HTTPS, it doubles the traffic and load time of your site.

One common concern with HTTPS is that you lose all referral information when a user clicks from an HTTPS to a HTTP site. There are ways around this, we include the <meta name=”referrer” content=”always”> tag in all of the HTML on our site so we don’t lose this, but you can only do this on sites that you control.

4) Configure your web server to redirect to HTTPS

The last step, set up a permanent redirect to upgrade all of your traffic to browse your site via HTTPS. Permanent redirects differ from other redirects as the redirection is cached as well as having some SEO benefits.

 

If you are interested in more information or would like help with your migration then please feel free to drop us a message and see how we can help you upgrade.

SEO (Search Engine Optimization) Beginners Guide

What is SEO?

Search Engine Optimisation is a process to improve the visibility or ranking of a website in search engines. By appearing earlier or higher ranked on the search results page a site will appear more frequently in the search results list resulting in more visitors to that website and ultimately these visitors could be converted into customers.

Most people can at least do the basic Search Engine Optimisation on their own website, without having to pay an experts, using the many useful guides online. Even small tweaks can make a big difference.

With this in mind we are not going to rewrite the book on SEO please find two beginner guides to SEO we find make a good starting point: