**UPDATE** – InstaPage has been updated since the time of writing the below, however personally I kept the setup below.

Okay hands up, as a software developer I hate the idea of these codeless website builders. They produce un-optimised, SEO unfriendly, SLOW and buggy experiences often with a dire standard of code and a ridiculous on-going monthly cost.

Coding a website is not monetarily costly, for me, I have the relevant skills to code, design, optimise and secure a website myself. While getting a website up and running may not hit my physical wallet, to do anything properly takes an extraordinary amount of of time; something I have been trying to optimise in my life lately to find more time for projects. When you assign a cost to your time it really helps optimise the unnecessary parts (Twitter, Facebook and the like).

I left my inner techy shivering asking ‘what the hell are you thinking about’ and signed up for a website builder

The abbreviated background story

When someone I consider rather successful suggested to me that if I too wanted to build product and get traction I had to be able to verify ideas were going to be successful before committing time and money to them. Aka fail fast. So I left my inner techy shivering asking ‘what the hell are you thinking about’ and signed up for a website builder, or more particularly a landing page builder. After some very light research, I choose InstaPage. I will perhaps go into some detail in another blog about the product I built (https://www.motremind.co.uk), but basically the landing page just had to collect a email address and a couple of other little parts of data.

I signed up for the ~$33 dollars month to month plan, had the site built in 1 night and chucked some adds on AdWords to see the reaction. Surprisingly I did get some signups, so I spent the next couple of months building out the backend of the system, leaving the front end there collecting emails. When the backend and reminder system was finally built I set up a Twitter and Facebook account and prepared to announce to the world.

Before I did, I popped a support call into InstaPage as per their help centre article to enable SSL on my landing page. For those not in the know, $33 per month for hosting a trivial website is rather expensive, hence I had assumed after reading the help centre that of course SSL would be included in my plan and the support team would sort it out while I slept. In my haste to get officially going I announced to my friends my new product and invited them to like/follow the page of Twitter and Facebook. Big lesson learned I should have waited a day for the big reveal.

What no SSL, I am paying for this right?

I woke up the next morning with a reply to my support ticket telling me that SSL was a “Premium” feature (BTW no mention of this on the pricing page or I would have run for the hills months before). I jumped over to check out how many extra dollars they were trying to squeeze me for; my jaw hit the floor and rage built inside!. A minimum of $149 month to month ($127 if you want to give them the money upfront for a year) So $116 for SSL and a bunch of other features I would never use. Are they having a laugh? With projects like Let’s Encrypt offering free SSL Certs these days my inner techy is utterly appalled. These types of website builders are aimed at non-tech people not in the know, furthermore landing pages by their very nature are usually collecting some form of personal details, in my case this was only a email address…but still. I was taking some rather deserved flack from tech friends on Facebook by now for the lack of SSL.

What would I do if I developed the site from scratch?

Setting up SSL on InstaPage for Free while on a Basic plan

Well one thing is for sure, I was not stumping up that $116 extra dollars each month, my inner geek was livid by this point. I decided it was time to let the inner geek come back out and find a solution. What would geek me do if I was developing the site from scratch myself? Well with my security and performance hat on no professional external facing website I build is without Cloudflare unless there is a very good and specific reason. Usually I advise clients to stump up the cash and pay, but I was being cheap here – validating an idea. I jumped across to Cloudflare and checked out the features available on their free plan – more than adequate I thought. So here is how to do it:

Step 1: – Sign up for a Cloudflare account

Step 2: – Go to https://www.cloudflare.com/a/add-site and enter the URL of your InstaPage account.

Step 3: – Let Cloudflare work its magic to figure out the required settings to keep your site online (DNS for us geeks).

Step 4: – Find and Log into the portal your domain registrar (the people you purchased the domain name from) and update the “Name servers” to point them at CloudFlare.

Step 5: – Get a cup of tea and wait 10 min (24 hours max) and your domain should now be getting served by Cloudflare.


Step 6: – SEO optimise the SSL end point.

Technically the http and https version of your site is seen as two separate websites by Google and this can adversely effect your page rank as well as meaning people can still access the non secure version as well. Hence we want to redirect the http traffic to https. Our “Basic” InstaPage account does not let us get access to the code so doing traditional redirects is not going to work here. Cloudflare to the rescue again! Head back over to your CloudFlare account and select “Page Rules”. Set a rule to “Always use SSL” for “Http://Yourdomainname.com/*” (note the * at the end).


Step 7: – While we are at it, we might as well try and optimise some of the other downfalls of website builders, Page Speed. Google offers a free PageSpeed checker over here. You will likely find like I did that the page speed of your landing page is terrible, which is again bad for SEO. Hence add another Page Rule in Cloudflare to “Cache Everything” for “*.Yourdomain.com/*” (again note the *).

Step 8: – Re run the PageSpeed test and you will likely see a small improvement, unfortunately we will never make large gains without access to the code but a gain is a gain.

Any Question?

Any questions please do get in touch in the comments.

Do dheagh shlàinte


In May this year Troy Hunt, a respected application security expert, asked the question "Do you really want bank grade security in your SSL?" accompanying this with an analysis of the Australian banks. This was soon followed several weeks later by Mark (second name unknown) who compiled the British Equivalent that continues to be updated every few days. Unfortunately not much progress has been made in the months since these articles were first written, so I wanted to try a slightly different angle.

While I don’t want to repeat what Mark has already done at a UK level, I do want to localise this to Scotland and twist this a little to cover other financial services institutions and explain why the financial IT industry in Scotland has far reaching effects right across the world. Hopefully by blogging on this I will reach these security professional in Scotland to make them aware, and hopefully prompt action. Lastly, I would like to share some experiences I have had in trying to inform these organisations of issues, and the success and frustration I have faced.

Before I progress though, it is important to note:

Security is a continual compromise between usability, practicality and maintaining backward compatibility. It is never black and white.

Why does SSL matter?

For the less technical among you, SSL is the technology equivalent of the lock on your front door. It is the first, and main, line of defence in protecting all your sensitive financial data as it passes across the internet (think https and the green bar in your browser). How this is implemented and configured matters greatly:

Would you put the dinky bolt you use on your shed on your front door?

While OWASP only list security misconfiguration at number 5 in the top 10 list of security threats, it is one of the easiest items on the list to fix TODAY! I don’t take pleasure from writing this particular post. I, like many of you use these very institutions myself, and I don’t want to shame anyone. However, we as an IT community in Scotland, need to do all we can in persuading some (not all) of these organisations to start taking security issues as seriously, and as urgently, as their PR and marketing departments claim they do. These organisations are not short of budget to deal with these issues, see £300m IT systems in a subsidiary of RBS alone, but some are short on agility to respond quickly. The banking industry in the UK is well known for being as agile as a hippo without legs.

Financial Services in Scotland – From an IT perspective.

Despite the frankly embarrassing commercial issues at some organisations in the past few years, Scotland is one of Europe’s leading financial centres and the second biggest financial hub in the UK outside of London, with a history of some ‘Scottish’ banks going back 300 years. Banks are only one part of this, added to ‘Banks’ is many other retail financial services providers, such as Standard Life, Aegon, Royal London, Scottish Widows and others that we perhaps trust with our most important life savings in the form of pension funds, savings and ISAs. I wanted to establish if other FS (Financial Services) institutions were taking the ‘bank grade security’ any more seriously than banks of the traditional form.

It is important to note here I am making a distinction on ‘Retail’ providers, I would be here for weeks doing this exercise if I was to extend this into the wholesale or services market. From initial research I came up with a list of 80 medium to large FS organisations employing IT staff here (think large fund managers, asset Managers, fund platforms etc).

Added to the 1000’s of IT jobs from ‘Scottish’ FS providers, and what most people don’t realise, is that banks and FS institutions from across the world have large IT footprints here in Scotland, with many shipping financial systems and websites worldwide (Ireland, Australia, Canada, America, Switzerland, South Africa, Germany and France are some of the countries I know from personal experience). HSBC, Barclays, Prudential, Morgan Stanley and others employee 1000’s of IT workers in Scotland, with JP Morgan alone expanding their European technology hub beyond 800 people recently.

The institutions I list below may not all be ‘Scottish’, but they do all employ large numbers of IT professionals here, and it is these professionals I hope to reach to encourage the correction of any part of the ship they are responsible for. This is not to say all these organisation will have their SSL managed here, but responsibility starts with those in the know - hopefully the correct people/teams can be found internally if they don’t reside locally.

The Results

It is important to note that having less than an “A” grade doesn't mean these organisations are lacking attention from their security teams, a “B” grade could be considered perfectly acceptable if known exploits are not viable at the present time, though the term viable in reference to RC4 is now on the borderline of practical and is worth keeping an eye on. However, those scoring grade “F” (those where exploits are extremely practical i.e POODLE) really should be working urgently to get these issues patched yesterday, and or mitigated by other means! The below results were analysed using Qualys SSL Labs tools.

** Update 31/8/15 - Aegon now showing an "A-" 2 working days after publish. Kudos to the cheetahs at Aegon for their quick action :-)

** Update 17/9/15 - HSBC now showing a strong "B" grade **

CompanyOverall GradeMore DetailsNotes
Royal Bank of Scotland (RBS)A.HereRBS moved from C to A since Marks initial May report.
Virgin MoneyA.Here
Morgan StanleyA.Here
Scottish WidowsA-Here
Standard LifeB.HereWeak DH key
NationwideB.HereRC4 cipher
Clysdale BankC.HereRC4 still supported
No TLS 1.2 support
Royal London (Scottish Life)C.HereRC4 still supported
No TLS 1.2 support
JP MorganC.HereSSL3 & RC4 still supported
HSBCC.HereSSL3 & RC4 still supported
No TLS 1.2 support
Bank of Scotland (HBOS)C.HereSSL3 & RC4 still supported
No TLS 1.2 support
Sainsbury's BankC.HereSSL3 & RC4 still supported
No TLS 1.2 support
HalifaxC.HereVulnerable to SSL 3 Poodle
SSL3 & RC4 still supported
No TLS 1.2 support
Lloyds BankC.HereVulnerable to SSL 3 Poodle
SSL3 & RC4 still supported
No TLS 1.2 support
TSBF.HereVulnerable to Poodle
SSL3 & RC4 still supported
No TLS 1.2 support
Tesco BankF.HereVulnerable to Poodle
No TLS 1.2 support
AegonF.HereVulnerable to Poodle
Vulnerable to SSL 3 Poodle
SSL2, SSL3 & RC4 still supported

Tip: Terminating your SSL on a windows server? Use this tool to configure your SSL to PCI compliance and SSL Labs A grade!


As can be seen above some institutions are doing OK, special recognition to RBS for their improvement in the last few months. On the other hand others (Halifax, Lloyds, TSB, Tesco Bank and Aegon) appear to have room to pull their trousers up in regards to patching of vulnerabilities , mitigation of them and general configuration. There also appears to be no difference between retail banks and other FS institutions, some coming near the top (Scottish Widows) while others look like they may be terminating SSL on something last configured in 1990 (Aegon, SSL2 support do you really need that?).

I contacted, or certainly tried to (none of them make it easy to report security concerns to the correct people who know what gobbledygook I speak of here) some of the organisations at the bottom of this list. After many frustrating weeks trying to establish who to contact, I managed to get a friend to put me in touch with the security team at one of these institutions who called me. I was told that they were aware of Troy's original article, Marks follow-up, and separately their poodle vulnerabilities were highlighted by their own PCI/DSS auditors. They claimed they had a “Program of Works underway” to remove the deficient kit they are terminating SSL on, but they could not disclose externally when they expected this to be completed.

While the organisations that still support SSL3 and RC4 may have valid legacy compatibility reasons for doing so - that’s a big ‘may’ that is worth questioning - those that have known exploitable vulnerabilities left unpatched or mitigated should be doing something yesterday to protect their customers security. Quite frankly the response I talked about above is simply not fast enough (early May to late Aug). In the case of old hardware that can’t be removed today, why not terminate the traffic at cloudflare. Yes, less than ideal with it being a world wide CDN etc etc and likely not to be PCI/DSS compliant, but still much better than leaving a Poodle sized hole in your SSL implementation (see my note at the start of this blog post about the trade off).

Can Financial Services organisations possibly move like a cheetah on security though?

On doing the study of non retail institutions I so happened to run a medium to large organisation that came out with a grade “C”. Fortunately I had direct access to the correct people inside this organisation, and in less than 24 hours that organisation moved from a “C” to an “A”. So yes, with enough effort, determination and empowerment of the correctly skilled staff it is possible for organisations in financial services to move like a cheetah on security concerns.

Would love to known your thoughts in the comments. Special thanks to several individuals for helping directly or indirectly with this post, you know who you are.