Click on the Login link and look at the browsers security bar.
If it says "The Royal Bank of Scotland Group Plc [GB]" and that then entity with which you do business, great.
It seems as if Troy would be just fine with HTTPS rather than HTTP, but DV validated certs aren't what you want anyway with a financial institution.
It seems far more likely that you care about the entity you are working with (Royal Bank of Scotland), than the domain of the referring page (personal.natwest.com).
For ~$170 apparently you can get an EV cert for "Stripe, Inc" (by forming a company with that name).
Even aside from that fact, users are very bad at knowing what a secure site looks like. I would wager that if most users clicked "login" and didn't see an EV cert, but instead saw "<padlock> Secure" (i.e. a non-EV HTTPS connection), they would not notice the difference.
Troy is right to kick up a fuss about this; this is a significant attack vector (anyone on a wifi network can MITM your banking login URL), and it's more egregious because of how easy it is to set up HTTPS.
For one tenth that cost, you can register stripeinc.net and get an SSL cert. Yay!
Domain registration is available instantly for anyone, anytime, and it can be phished at least as easily as anything else. https://www.xn--80ak6aa92e.com/ looks pretty legit in Firefox.
Sure, but that's just more reason to use HTTPS across their entire domain and would help prevent users from being phished as easily. If I enter "apple.com" I expect all links on that page to point me to the correct location. A MITM attack from a non-HTTP page could easily alter the page and link me to https://www.xn--80ak6aa92e.com/login instead.
The issue is that users tend not to notice the absence of EV security indicators. If they see a padlock (which a phisher could get for a phishing domain), they assume it's secure and enter their credentials.
Also, it may not be apparent to users whether "The Royal Bank of Scotland Group Plc [GB]" would be affiliated with NatWest. Companies often have different names they do business under.
Or put another way, don't notice the absence of "The Royal Bank of Scotland Group Plc [GB]". Or don't notice if it's been changed to "RBSG [GB]" or "Royal Bank [GB]". Then there's this:
Dude, you could walk into a coffee shop in the UK today, set up a honeypot wifi, and over the course of a day collect a handful of credentials with direct access to bank accounts. Unlike the US, once you're into an account you can send money directly and more or less instantaneously to any other UK account. Assuming every single person is verifying the cert/domain after they click the login link is batshit insane, I guarantee you no more than 10% of people would even have a chance of noticing.
And if you aren't familiar with the details of how web browsers work (eg most people who use them), you would have no idea something was wrong. Not to mention potential problems such as http://stripe.ian.sh
Just one day prior, I wrote that people's mental model of the benefits that EV certs confer is broken [1]: "an EV cert asserts that the domain name is controlled by a legal entity in some jurisdiction. This is a very distinct notion from the site that you've arrived at being the site that you were intending to visit, but people use it as a terrible, flawed proxy for such."
This was on the topic of an EV cert being issued to a different 'Stripe, Inc'.
But also, I observed that for top sites, "people trust their website by fiat, simply by mental associations about their domain names (...)". This is why HTTPS on a landing page is so important: to safeguard the trust chain that most users use to arrive at the login page -- first, the name of their bank, then the bank's URL from memory, then the bank's login page from the homepage's URL.
Wasn't there a post on HN just yesterday about EV certs not being a secure method of authenticating the website you're on? Something about Stripe being spoofed.
The case is not overstated in any way, serving a major trust-building page like a bank homepage over HTTP is crazy. Redirecting to a spoofed webpage is obviously the simple hijack but there's no reason some attacker couldn't drop some custom-built HTML and JS to drop a faux-login form right on the page that's filled with copy about how trustworthy the bank is.
Sidenote: several years ago my bank started POSTing their login form to a completely separate domain to login to my account. So I fill in the username field on the homepage and it sends me to "totallysecurebankloginsite.com" to enter my password. After a few calls to the bank they insist that this is the design they intended and that it's just fine.
Uhh, yeah you could do that. Do most people do that after they click the login page on their bank's website? No.
The issue is that most non-technical users would not even think about checking. They went to their "secure" bank website and clicked login, why should they have to worry?
You want to know if the login page is NatWest?
Click on the Login link and look at the browsers security bar.
If it says "The Royal Bank of Scotland Group Plc [GB]" and that then entity with which you do business, great.
It seems as if Troy would be just fine with HTTPS rather than HTTP, but DV validated certs aren't what you want anyway with a financial institution.
It seems far more likely that you care about the entity you are working with (Royal Bank of Scotland), than the domain of the referring page (personal.natwest.com).