Banks, browsers and security

My interest was piqued by Ars Technica’s story that Gogo’s in-flight wifi services block some VPNs, and the thrust of the story is that you shouldn’t do sensitive work on a plane using their service.

Previously, Google engineers had noticed Gogo impersonating their secure sites by issuing lookie likie security certificates.

So Gogo are compromising your security – and sometimes crippling your ability to mitigate against those risks by using a VPN. Of course, Gogo have been called out for doing this publically, but any wifi provider in a coffee shop, train station or airport lounge could do exactly the same thing.

To help mitigate such risks, browser builders have employed technologies such as HTTP Public Key Pinning. When you visit a site, they can send you a copy of the public part of the cryptographic key and tell your browser to only trust the site when it sees that specific key. If you have that site’s public key “pinned”, should a naughty wifi network try to impersonate a site and send the wrong public key, then your browser will recognise this and refuse to connect. And the naughty wifi network people don’t get to access your private data.

You would think that of all the sites who need to use such technologies to protect their users, the banks would be pretty high up the list. Today I performed a quick test of 10 of the largest UK retail banks so see what their approach to browser security is. (Full disclosure: I’m an interested amateur rather than a proper certified security expert in these matters).

Shockingly, the protection offered by Public Key Pinning is NOT USED by any of these banks, so you’re not protected against impersonations when using a public wifi network.

8 out of 10 don’t use the website directive to only connect over HTTPS, HTTP Strict Transport Security.

NONE of the 10 banks’ main sites enforce SSL connections, meaning that the connection between you and their inscure main page can be intercepted and altered. This means that a malicious network operator can change the destination of that “secure” Login button. (Would you notice if the button pointed to

Unbelievably, two of the worst offenders actively block HTTPS connections to their main retail site.

A long time ago, running your website over HTTPS was expensive and technically tricky, so you could be forgiven for thinking that you only needed to use a secure site for the most sensitive parts of your business. Now, website security is cheap and ubiquitous, so I do not understand how UK retail banks can fail to use the tools at their disposal.


I typed in the bank’s domain name into a web browser URL bar to see if the site redirected to an SSL version of the site, ensuring that all connections to the site were secure – not just some of them.

I used Qualys SSL Labs to get a security grade for each bank’s main website and then the web domain used by the retail online baning application, where different.

I also used Scott Helme’s excellent tool to see what security related headers were being returned by the sites, especially HTTP Strict Transport Security and HTTP Public Key Pinning.

Posted in tech | Tagged , , , | Comments Off on Banks, browsers and security

Update: BBC Radio 4 FM stream

One of the most visited posts on this site is my list of the direct stream URLs for BBC Radio services. Since it was posted, the BBC have revamped their streaming infrastructure, and most internet radio services can only access the Long Wave version of Radio 4. This is hugely annoying, as it includes guff like The Daily Service.

Thanks to the BBC HTML 5 Beta, we seem to have a working .m3u8 for Radio 4 FM. For your delectation (terms & conditions apply, the value of your internet radio device may go down as well as up: BBC Radio 4 FM .m3u8

Posted in tech | Tagged , , , , | Comments Off on Update: BBC Radio 4 FM stream

Camille’s new website is launched

One of my favourite people has just launched a website for her psychodynamic psychotherapy practice in West London:

Posted in friends | Comments Off on Camille’s new website is launched

Pinterest and using the X-Frame-Options header for security

Nancy was having some trouble getting her application to create Pinterest Rich Pins working. The validator tool (and tech support) were not very helpful. The error just said:

We were unable to retrieve any data from your URL.

Pinterest Validator tool failure

I tried verifying that there was no intra-AWS connectivity issues (Pinterest’s tool lives in AWS, but so does Nancy’s site),  but I could see in the Apache logs that Pinterest was getting an HTTP-200 OK response.

It then dawned on me that I had – in a fit of security consciousness – turned on click-jacking protection on all my self-hosted domains.

The only problem being, Pinterest uses an IFRAME to validate that your Rich Pins are correctly marked up with tags. By using X-FRAME-OPTIONS: SAMEORIGIN, I was blocking the tool from framing the page, and thus validating the content.

Sure enough, turning the click-jacking protection off fixes it.

So, if you are seeing the error “We were unable to retrieve any data from your URL” with the Pinterest Rich Pins Validator, you may want to check your site to see if you’re using  X-FRAME-OPTIONS using’s handy tool.

Posted in tech | Tagged , , , | 1 Comment