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 https://onlinebanking.haIifax.co.uk?)
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 SecurityHeaders.io tool to see what security related headers were being returned by the sites, especially HTTP Strict Transport Security and HTTP Public Key Pinning.