My move of trivia to a new VM last December prompted me to look again at my server configuration. In particular I wanted to ensure that I was properly redirecting all HTTP requests to HTTPS and that the ciphers and protocols I support are as up to date and strong as possible. Mozilla offers a very good security reference site which should be your first port of call if you care about server side security. The “cheat sheet” on that site gives pointers to existing good practice guidelines for most of the configuration options you should care about on a modern website. I have implemented as many of these as is possible on trivia – but I am hampered slightly by the fact that I still use WordPress as my blogging platform. WordPress (and its myriad plugins) still does lots of things I don’t actually like (such as setting cookies I can’t control, loading google fonts etc.) but I’m stuck with that unless I change platform (which I might).
I have tried to ensure that all session cookies sent are as secure as possible by setting the “HttpOnly” and “secure” attributes in my wp-config file (as below)
@ini_set(‘session.cookie_httponly’, true);
@ini_set(‘session.cookie_secure’, true);
@ini_set(‘session.use_only_cookies’, true);
but that seems to be bypassed by some plugins – which I have thus disabled (behave or begone!). Apart from that change. and some minor tweaks to my TLS configuration to ensure that I only use recommended protocols and ciphers, nothing much seemed to need changing.
My first port of call for remote checking of my security was then the Mozilla Observatory site. I thought the results were disappointing – I only scored a “B”.
However, a careful reading of the full results showed that trivia had actually passed 10 of the 11 tests and achieved a score of 75/100. The 25 missing points all came from the failure of the “Content-Security-Policy” (I don’t implement one – because it is largely impossible on WordPress sites and particularly on a blog like trivia which points to multiple external resources).
Mozilla themselves say that:
Content Security Policy (CSP) is an HTTP header that allows site operators fine-grained control over where resources on their site can be loaded from. The use of this header is the best method to prevent cross-site scripting (XSS) vulnerabilities. Due to the difficulty in retrofitting CSP into existing websites, CSP is mandatory for all new websites and is strongly recommended for all existing high-risk sites.
I conclude that on general security recommendations I am doing reasonably well apart from the CSP issue.
Next, and most importantly, is the TLS check.
Mozilla’s own check gives me an “I”, meaning “Intermediate”. This is not surprising since I have implemented their “intermediate” level recommendations. I considered using the “modern” set only, but that excludes TLSv1.2, would exclude users of many browsers and, oddly, result in a lower score at SSL labs. Besides, I really don’t see why my blog should set the bar higher than seems to be used much more widely elsewhere.
Lastly, the observatory links to third party test sites, including ssllabs, immuniweb, securityheaders and hstspreload. I’ve used some of these (notably ssllabs) independently in the past and found them to be robust, reliable and helpful in getting my site properly configured. None of the results there surprised me or bothered me over much. I still get a nice satisfying big green A+ at ssllabs.
However, the immuniweb result intrigued me.
Apparently, my blog is PCI-DSS compliant. I do hope not. It runs on a debian VM in a datacentre in Prague owned by a small European ISP – and it cost next to nothing. If that is all it takes to gain PCI-DSS compliance then I’m a little worried. (In reality, I expect all it means is that my /TLS/ configuration is PCI-DSS compliant).
So, having checked my own configuration, and found that I still get a nice green A+ at ssllabs, I thought I might check some other sites – particularly those which ought to take extra care about the strength of their TLS implementations. Given my apparent PCI-DSS compliance, what better sites to check than those of the banks? I picked fourteen bank sites, including four of which I am a customer (either as a saver or a borrower). Here, in no particular order, is what I found.
Nationwide
Certicate expires in 1 year 8 months.
TSB
Certificate expires in 5 months.
Co-op Bank
Certificate expires in 9 months.
Halifax Bank
Certificate expires in 7 months.
HSBC
Certificate expires in 7 months.
Lloyds Bank
Certificate expires in 7 months.
Natwest Bank
Certificate expires in 1 year and 1 month.
RBS
Certificate expires in 1 month.
Sainsburys Bank
Certificate expires in 3 months.
Santander
Certificate expires in 10 months.
Smile Bank
Certificate expires in 9 months.
Tesco Bank
Certificate expires in 1 year 5 months.
Virgin Money
Certificate expires in 9 months.
So: of the fourteen banks I checked, only 3 get an A+, 5 get an A, 3 get a B, 2 get a C and poor old Santander gets an F. In Santander’s case this is because their server apparently remains unpatched for the Zombie Poodle vulnerabilities. Qualys published information about this vulnerabity in April 2019 and warned then that they would start giving an “F” grade to any server affected by these vulnerabilities from end of May 2019.
For the remainder, the majority of problems seem to stem from the failure to remove TLSv1 and TLSv1.1 protocols. It is generally accepted that only TLSv1.2 and above are to be considered “secure” these days. None of the sites I checked support TLSv1.3, and even those sites supporting TLSv1.2 offer weak ciphers or also offer TLS versions lower than 1.2. Certainly PCI-DSS compliance implies a minimum of TLSv1.2 (See the rationale for the “Intermediate” configuration at Mozilla”s site.)
I notice also that practically all the Banks use certificates which last for one or two years. This strikes me as rather a long time, but of course there is always the difficulty in a live IT environment of balancing the need for frequent certificate changes against the need for some stability. Nevertheless, certificate changes can be automated and it seems to me that a much shorter certificate lifetime (say 3 to 6 months) would be more appropriate.
Does this mean those Bank’s sites are insecure? Well, no, and the Banks themselves would almost certainly argue strongly, and correctly, that their TLS implementations meet industry best practice whilst catering for the (very wide) range of browsers in use by their clients. They may also argue that the sites I checked are not the actual portals to their on-line banking systems, merely the shop front door (so for example nationwide.co.uk uses the subdomain onlinebanking.nationwide.co.uk).
But I know what I think. They should do better. Much better.
And of course I’m not alone in my view. About 18 months ago Wired reported that “Top UK banks [weren’t] using the latest tech to secure transactions”. In that article, Wired pointed to research by Swansea University computer science student Edward Wall and also quoted Pen Test Partner’s Researcher David Lodge as noting “There are some significant issues in need of improvement. Encryption is possibly the most important, in particular the section marked TLS. There have been a selection of cryptographical flaws found in the implementation and algorithms with older forms of SSL/TLS, meaning that only TLS 1.2 and 1.3 are recommended nowadays”.
That article goes on to note that the PCI DSS requires that the latest encryption standards are used. Sadly little seems to have changed in the past 18 months.