Occasionally, I feel like I'm just handing an organisation more shovels - "here, keep digging, I'm sure this'll work out just fine..." The latest such event was with NatWest (a bank in the UK), and it culminated with this tweet from them:

I'm sorry you feel this way. I can certainly pass on your concerns and feed this back to the tech team for you Troy? DC — NatWest (@NatWest_Help) December 12, 2017

This was after a concerned customer and then myself trying to explain to them that serving their home page over a non-secure connection wasn't such a good idea. The "I'm sorry you feel this way" tweet was in response to me laying things out in what I thought was a pretty crystal-clear fashion:

You’re missing the point: when people want to logon they go to your homepage. The homepage is insecure so you can’t trust anything on it. The link to the login page is on it. You can’t trust the link to the login page. Make sense? — Troy Hunt (@troyhunt) December 12, 2017

Their original argument - and certainly they're not alone in this misconception - is that because the landing page of the website doesn't have anything sensitive on it then it doesn't require HTTPS:

Hi there Troy, the website contains general information, rest assured when you are logging in that the website is secure. Please feel free to DM me if you have anymore queries around this. Thank you, DC — NatWest (@NatWest_Help) December 12, 2017

So, let's just look at the home page for a moment and break down all the problems in the highlighted areas:

It's served over HTTP so it's not an encrypted connection and can therefore be intercepted, the traffic read, modified or requests redirect to other locations. We're seeing "Not secure" next to the address bar because I've typed something into the search box. This change began rolling out in Chrome in October and I would opine that "Not secure" is not what you want to see on your bank (although as I've said before, "bank grade" security is not necessarily a virtue either).

And then we have the link to the login page which is the source of much of this controversy. That link takes you off to https://www.nwolb.com/default.aspx which is indeed encrypted. The padlock next to that link is of zero functional value and importantly in the context of this post, is the only padlock on the page because the browser won't give you one due to the non-secure connection!

Here's the problem in the simplest terms I can put it:

NatWest acknowledges that HTTPS is important because they have it on their login page and (presumably), all their banking pages. Agree?

They're using HTTPS because of the aforementioned threats involving someone getting in the middle of the connection and messing with traffic. Still with me?

If someone is messing with traffic then they can modify non-secure requests. Yeah?

The NatWest landing page in non-secure and it serves up this bit of HTML for the login link:

But because of all the things we just agreed on, that link could just as easily be changed to this:

Get it? It's just a "w" versus "uu" change (and yes, you could go and register nuuolb.com right now), then you can go and stand your own site up on that domain and phish the credentials.

Edit: Shortly after publishing this post, NatWest went and registered that domain in what I assume is an attempt to stop a man in the middle intercepting their traffic and making a visually trivial change to a URL. Alarmingly though, nw0lb.com is still available as is nuu0lb.com and it-doesnt-matter-because-that-isnt-the-point.com.

Alternatively, you could do as Scott Helme just demonstrated and use sslstrip to grab everything:

And just as a brief reminder of how prevalent intercepting and modifying someone's traffic is, imagine your ISP injecting hundreds of lines of their own JavaScript into your bank's site:

Your users [*] could "enjoy" this bonus collection of JavaScript, when visiting your HTTP website.

[*] limited offer at participating locations; HTTPS sites need not apply.https://t.co/B6zpuD8nQ0 pic.twitter.com/4hvhsB7PTA — John ☆.o(≧▽≦)o.☆ (@JohnMu) December 8, 2017

Now fortunately Comcast is getting the press they so rightly deserve for this, but you can see the point.

We're on a march towards HTTPS everywhere. Almost 70% of web traffic today is encrypted and organisations not getting with the program are being increasingly penalised for lagging behind. A bank - of all sites - should be getting this right or at the very least, taking the discussion offline and deferring to their tech folks. Oh - and Twitter's CSIO has some good advice for these circumstances too ?

Companies - A general public announcement



If you receive security feedback from @troyhunt go ahead and have your security folks review the situation before attempting to claim troy is in the wrong. It's probably going to be a good use of time ? https://t.co/jYA36a8UN9 — Michael Coates (@_mwc) December 12, 2017

These days, the minimum accepted criteria is HTTPS across everything with HSTS preload. If you're not sure where to start, give my 6-Step "Happy Path" to HTTPS a go!

BTW NatWest - while you're fixing stuff, make sure you also reply to people reporting security vulnerabilities:

I've reported to them a XSS 4 months ago (Still not fixed!). They ignore my e-mails, don't accept my phone calls.. Terrible! pic.twitter.com/v1pzpiiYzV — ~ (@huykha10) December 13, 2017

Edit: A day later and NatWest was on the front of the BBC's tech page:

@troyhunt so you've made it onto the BBC main technology page https://t.co/Dwp0taYopF pic.twitter.com/4UTzBbMKBa — Dan Clarke (@OverByDan) December 14, 2017

To their credit, they also very quickly started redirecting the landing page to HTTPS albeit with a couple of glitches:

lol, now it's over ssl when I load it, but mixed content AND bad certs. pic.twitter.com/N2KtjHpEW0 — Zach Silveira (@zachcodes) December 14, 2017

So to the NatWest folks - kudos for responding quickly! But do read that 6-Step "Happy Path" post and get upgrade-insecure-requests in there pronto.