HTTPS on Your Landing Page Is Important
troyhunt.com
troyhunt.com
Microsoft is another major offender. When logging in, I get redirected 20 times between various domains, none of which in microsoft.com
One day S&M will catch up and have a fit at the fragmented "front face" - quite right too. To be honest the board should also give a shit about their org's outward appearance.
Bit of a fail all 'round, really.
Or is that an unrelated thing?
By having CDN assets on a separate domain, you not only easily avoid accidentally sending any cookies along to the other domains (so if your CDN gets owned at least they aren't getting user credentials or session cookies), but it's also a small performance optimization as there are less things sent in the headers.
The important distinction is that the user should never ENTER any information onto those domains directly. They should be for displaying static resources only, so there is no need to "build trust" for them.
It wouldn’t load because Facebook.com was blocked and apparently they were doing a full redirect via fb. Crazy.
This is also exploited by malicious actors to occasionally buy out fake ads for amazon.com or bestbuy.com (or even, hilariously, youtube.com) which actually direct you to support scam websites claiming your computer is infected.
Google seems to have no desire to correct this by making their advertisements show you the actual URL are you going to be directed to.
Verify that any link you click on is not an ad. Always look for the first native result. The policies permitted around ads make them simply a security risk to click on.
I've had a real shitter of a time trying to login before, with redirect loops, or getting automatically signed out as soon as I sign in. Or accounts being a "games for Windows" account, but not an MS account, or an Xbox live account, so some other account. Often I've just found it easier to give up and make a new account.
I was pulling my hair out the other day trying to find my Microsoft credentials in LastPass. I was searching for "microsoft", "office", "outlook" etc. until I finally found them under "live.com".
Well, a login system is a very central part, and other websites suck too, like Amazon still uses the old account login page since 1996 too. But Microsoft redirects way too often, it is worse.
Very frustrating - fortunately I don't use Skype regularly but it's always an exercise when somebody asks for my username.
* One account required me to log in with a username, and was associated with my main email address. * The other account required me to log in with my main email address.
In a way, they were both related to the same email, but different accounts. This shouldn't even have been possible, but it seems that one was an old MS account, and the other was an old Skype account. My roster ended up being split half and half between the two.
The steps I found to unlink within the XBox UI didn't work, futher research now leads me to the following discussion which I am about to try: https://answers.microsoft.com/en-us/outlook_com/forum/oemail...
Edit: it looks like this was possible in the past (basically deleting the Skype account?), but not anymore.
[1] https://support.microsoft.com/en-us/help/12412/microsoft-acc...
I confirmed over the phone with their support that was indeed the correct site before typing anything into it.
I said think about what you're asking for a second. Should I answer your questions? Couldn't get them to understand. Wound up hanging up and calling again and waiting on hold.
Obviously I terminated the conversation.
"Hello, am I talking to Nick Lamb?" "Yes, this is me" "OK, I'm calling from Example Bank and our confirmatory password is Melons" [not the actual bank or password] "Thanks, that checks out, what can I do for you?"
This happened because I had one of those conversations you're talking about, and they were like "Aha! We have something we can do for those situations, call us and set a password we can use" so I hung up and sure enough they've used that password ever since. I like it.
It's not a _good_ password, but hey, how many times does anyone try the wrong one? Literally never. So it's good enough.
The site itself is branded just like Templeton's own site. From what I could gather, it is actually their site but even the whois is something non descript. Quite ridiculous. And of course they don't have any way whatsoever that I could find to report things like vulnerabilities or phishing attempts.
Having a bank as a current client, I am often joking about what would happen if Jeff Bezos takes control for a month. And when I am angry, I ask what would happen if Amazon or Google start selling credits or insurances, tomorrow.
The future is here folks. And it sucks.
What's worse, because it can be entered on the phone, aAbBcC are all == 1. So it's really just 6 digits.
(Obligatory xkcd comic: https://xkcd.com/1926/ )
That is, of course, complete bullshit.
Sure, it is plausible that a bank has an old mainframe handling their accounts. It is also plausible that user account passwords on that old mainframe are only 6 or 8 characters and from a limited alphabet.
What does that have to do with customer online banking accounts? Nothing!
When you open a bank account they don't make a user account for you on their mainframe. What they make for you is an entry in an application database that their banking applications use. The only mainframe user accounts involved are the account that the database runs under and the account that the banking application runs under, both of which are the same for all banking customers.
Even if, for some strange reason, they do actually have to make a mainframe login account for each banking customer there is no reason for the banking customer to ever directly access that. Online banking is accessed through the web, so only the web server needs to access your banking account on the mainframe. They could make the website have its own password system, without the mainframe login restrictions. The restricted mainframe login information would only be known by the mainframe and the website back end. The banking customer should never deal with that.
https://i.imgur.com/O2eOwLw.jpg
Edit:
"You may be liable for all losses from unauthorized use of your Account if you:
contributed to its unauthorized use; used a PIN combination selected from your name, telephone number, date of birth, address, or Social Insurance Number; did not use reasonable care to safeguard your Secret ID Code; did not keep your Secret ID Code separate from your Card; did not comply with your reporting obligations in Section 11 of this Agreement unless there were exceptional circumstances for your failure to do so; or shared a mobile device that you registered with us for Electronic Banking Services. In those cases, your liability may exceed the funds in an Account, your credit limit or any daily transaction limits. In other words, your liability will not be limited by your Account balance, your credit limit or any daily transaction limits. You must cooperate and assist in any investigation that we initiate into the unauthorized use you reported, which is a precondition to being reimbursed for any losses. This cooperation may include filing a report with law enforcement authorities."
Overall seems fair enough protection.
It's entirely possible to claim your card was skimmed and have your bank refund the money. However, if they then find out that the ATM used to withdraw your entire balance is the same ATM you've used for years, and your face is on the ATMs security camera at the time of withdraw, then you're in for a world of hurt.
So the passwords 'abc' 'ABC' and '222' are treated as equivalent. Try it out for fun!
Ex : I call my bank and I have to go through a menu leading me to the right agent. Eventually, it asks for my password over the phone that I need to type using the 10 numbers on a phone dial.
Good luck using your fingerprint there :)
Look at Mr. PrivateBanking over there, my one is 5. Amount in words : Five.
And that is after they updated all their software and moved to a new datacenter and everything recently.
Granted I have a hardware dongle to authenticate any transactions, but to gain access to all my information, five characters is all the protection they wish to offer...
Offenders: Wells Fargo, Chase, American Express, Fidelity, ....
My corp (guild for non-Eve players) had a better and more secure login & SSO system than either my bank or my employer. My employer has replaced their SSO system by now, but my bank is still in the 90s.
I complained and a member of the dev team phoned me up and after a long discussion about why this was madness he told me that it was better to use older browsers for important things such as online banking (like IE6 which was in their whitelist) because they're tried and tested.
The app is pretty great.
It’s not pretty but it’s quick. :)
I open it in another tab and just go do something else.
I'm sure that has been said by some manager somewhere.
When they started using computers, they were taught to NEVER write your password down and to do things like replace letters like I with numbers like 1 for security.
Not only are those not true any more, but the opposite is recommended. Making a unique LONG password is much more important, and writing it down on a sticky note next to your monitor is arguably more secure from some threats than even something like LastPass.
But maximum lengths (that aren't measured in kb) are a monumentally stupid thing, as are most other password "rules" (No, disallowing words in your password is not a good idea...)
Provide a minimum length, and check passwords against common password lists, and use a damn good hashing algorithm with a process in place to easily allow upgrading that hash.
https://www.bankofamerica.com/information/supported-browsers...
It seems that every time Troy interacts with a company on Twitter, they never seem to click on to who he is, until it's probably too late and they look like fools.
It's just so amusing to see companies trying to condescend to Troy, when he's one of the most visible authorities on web security on the planet (not necessarily the most authoritative, but the most well known).
I occasionally get this when people try talking to me about computer science topics, when they don't realise that it's what I do for a living. I've probably done the same myself when talking to Doctors and other domain experts, I'm sure.
There's a number of places in that chain of events that something could go nastily wrong, despite them owning every part of that chain.
Several months ago I recall a website owner posted a bug to Firefox saying he didn’t need HTTPs and that Firefox shouldn’t tell users it’s insecure. Within hours his database was pwned.
I remember a few years ago when there was no way you could do it for side projects because certs were 100/yr., now they're free.
For anyone interested :
I'm only a customer for small niche sites, not associated in any other way, works fine enough for my needs.
Only annoyance (at least with webfaction) is that they don't currently support letsencrypt auto-renewal, so you have to remember to update your cert manually every 12 weeks.
The problem is not pissing off Troy Hunt; but more that they are advertising that their website is vulnerable and that they don't care.
everyone = Hacker News
Mostly likely not their customers; whom they have a vested interest in keeping money with.
My care factor is probably very different to most non techies, by assumption. Then again, there's probably a bunch of things I do that would annoy(?) {them} greatly - that I'm not even aware of.
> We have our own security system, and it has never been breached in more than 15 years.
Which leads me to believe that their system was built by scratch, in PHP, 15 years ago, and hasn't been updated since.
Besides, if the DB was pwned, it is unlikely that http -> https would have any real bearing anyway. There was probably a XSS exploit or whatever.
If you don't think HTTPS is important you're probably not worried about SQL injection either.
Sorry that's what I meant. Both moves are smart. Doing both is smartest.
My sides.
When I got a new nano-SIM (in 2012, one hopes they've changed this since), they didn't check any ID and only needed a postcode and date of birth to move my account to a new SIM.
The man on the other end of the phone was totally unable to solve my problem and in the end just gave me £10 of free credit on the account I'd meant to top up. He didn't ask for any ID or verification at any point, except for the serial number on the SIM card. It was a pretty bizarre customer service experience.
But Nationwide is pretty good for banking.
Until I'm sure the other person doesn't know what they're talking about, I try and assume they're right.
Oh bollocks, that's me undone. Err without Googling and being British and given where I am and a few other things, I'm going to go for ... ... firearm?
Simplistic analysis by me: Well it can't likely be a Champagne (French). Dunning (English), Kruger (German with options).
OK Goo ... https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect - hmmm 8)
It's an important legal mindset, too, because it's an important mindset for any honest debater: You prepare an argument by attacking it, and trying your damndest to be the best argument for the opposition you can possibly be.
That's important in moral issues, where there arguably is no "right answer" to certain questions, but it's vital when things come down to factual questions where one position is right, any other position is wrong, and being able to recognize when you're holding a position which is wrong is vital to being honest, not only with others but with yourself.
Alternative take, particularly pertinent to this situation:
The person handling twitter is not a technical person, but a customer support person who handles hundreds of dumb questions, day in, day out, from customers who have no clue what they're doing but will often throw technical terms around.
Expecting solid technical answers from a general twitter account for a business is beyond absurd.
Not anymore!
https://www.whois.com/whois/nuuolb.com
It seems NatWest has quickly gone to secure this major attack point in their otherwise chink-free armour. Does someone want to inform them about nwalb.com as well?
So I would advise you not to do it.
I can also get "complex web design" for $100 per hour from them. Judging by the quality of that site, I might pass.
The "2016" likely means they do minor/trivial updates now and again. Maybe it'll get a "2018" in the next 6 months or so too... :)
https://developers.google.com/web/fundamentals/security/encr...
[Edit] Thank you to those people who had some honest replies, not sure why this got down voted, it was an honest question. When you go to the "Learn More" page on Chrome it doesn't even say "Secure" it says "Information you send or get through the site is private."
However, message integrity is a real benefit of SSL that doesn't need CAs. Consider the original article. In this case encryption doesn't matter and integrity does.
Without message integrity, considering the login link has a known location and value, using bit-flips one might be able to change the login link (depending on the kind of encryption used).
This message integrity is getting to be a much more important part of https. There are a lot of things that you don't want other parties able to change. Maybe even more things than you don't want them to be able to read.
The only thing that HTTPS guarantees is that you are communicating securely with the person that owns the domain. That's it.
Google specifically says (without naming a date) that their long term intent is to put a UI like a red triangle plus the phrase "Not Secure" in the URL bar for all HTTP sites on their desktop browser. This is the same treatment you get today for a site with a bogus SSL certificate and similar to the treatment HTTP sites get now in Incognito mode.
"secure" means "secure connection" to me, and it sounds perfectly appropriate. Maybe you can't find a better term for "secure" because it's perfectly fine, already..?
Could be! Someone else suggested "Encrypted", seems like a good word. I really don't know.
I'm thinking specially in its inactive "not encrypted" version, where people aren't going to appreciate the gravity of a page being "not encrypted".
I bet the folks at Google already thought about this through.
It's nice that their goals align with something actually helpful. But don't mistake the motive. This extends their dominance in global snooping.
This is fine, except one of these A records was a 192.168.x.x address so their site didn't work intermittently.
I called them to report it and they refused to listen. Claimed the site was worked as intended from their office and they wouldn't escalate.
Bare in mind, on their complaints page you can download a complaints Word document, fully capable of having embedded VB script [2].
Also, it took them _months_ to sort out an issue where they would only check for 3 numbers (pin) and 3 letters (password), always asking for the first, second and third characters.
Also-also, I remember a while back not being able to access my card (for about a day) because a single engineer accidentally corrupted their main database.
[1] http://financial-ombudsman.org.uk
[2] http://financial-ombudsman.org.uk/consumer/complaints.htm
Only then we can have 100% of the web encrypted.
[0] https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
[2] https://security.googleblog.com/2017/09/broadening-hsts-to-s...
Actually you can! You just need to use one reserved for that purpose:
> In 1999, the Internet Engineering Task Force reserved the DNS labels example, invalid, localhost, and test so that they may not be installed into the root zone of the Domain Name System.
Couldn't something like a TXT record also address this, but on a cross-client, scalable fashion? Like how SMTP with SPF or DKIM works right now.
(And yes, I know DNS also has trust problems!)
At the very worst, a central, programmatic source of truth, like DNSBL and company... just like how Google offers their "malware sites" hash table for all to use.
DNSSEC has no practical impact on this due to a lack of adoption both on the domain and end-user resolver side. (Not to mention that it's a terrible protocol.)
Note that the HSTS preload list is not only used by Chrome, but practically all major browsers. For all intents and purposes it currently is the central source of truth. I imagine if the size ever becomes a problem, browsers will switch to a mechanism like Safe Browsing to distribute the list.
1. HSTS Preload: I am not 100% sure but, AFAIK your browser gets the list once during installation and then sticks with it until he receives another software update. I think the list should be dynamic (e.g. like adblock lists). That way even older browsers would have an up-to-date HSTS Preload list.
2. Like everything else HSTS records have a lifetime, but when you use your dev-tools to delete your browser cache it doesn't delete the HSTS information. So every time you want to delete them you have to go to some net-internals... browser configuration to explicitly delete a HSTS record for a specific domain. It's even easier to delete serviceworkers...
For a long time I also didn't like that you could not easily remove your own domain from a preload list, but that fortunately changed and now there is a website where you can easily request to be deleted from the preload lists. The only hitch here is that as it takes a few month until every browser on this planet got a software update the new list will also have to wait for a while: https://hstspreload.org/removal/
I mean, take this case; lets say NatWest DID put their landing page behind SSL... well, lots of people are going to try to go to http://<url> instead of https://<url>. Most site will redirect the user to the https version, but if an attacker hijacks the initial request, they could easily serve up a fake version of the landing page that has a 'login' link to the malicious site.
Now, at least if NatWest was redirecting http to https, a savvy user could notice that their session wasn't being redirected to https and could be aware something was wrong, but if you didn't know to check, you could be fooled.
There is nothing the site owner can do to prevent that sort of hijacking.
CT, as currently implemented, is good at two things: Detecting misbehaving CAs, and detecting certificates issued by attackers after a server is compromised or domain is hijacked, assuming the domain owner is monitoring logs for such certificates. The Web PKI does not provide many tools that actually mitigate damage for the second scenario (unless you've deployed HPKP, which is on its way out).
[1]: https://www.imperialviolet.org/2014/04/29/revocationagain.ht...
[2]: Practically no mainstream browser uses hard-failing OCSP. Firefox supports the X.509 Must-Staple extension, which enables hard-failing OCSP, but Must-Staple has a glaring hole: If the attacker gains the ability to issue a certificate for the targeted domain, they can simply request a certificate without the Must-Staple extension. Must-Staple's usefulness is mostly limited to key-compromise scenarios.
10 years ago it was best practice for ecommerce shops to serve non sensitive pages (pages without forms or user data) without HTTPS to reduce the server load (HTTPS connections are a little more expensive than HTTP).
Nowadays, even the economical driven ecommerce shops got it that is better to just serve everything via HTTPS. It is very sad to see a bank (which should really know better) arguing that way.
and many more.
I'm just not one of these people who think there are armies of people at the NSA/GCHQ spying on me. I'm also against forcing every website in the world onto https. Doing so will significantly raise the bar of accessibility for tinkerers and makers. If I had a webcam that showed the world whether my coffee put needed refilling[1], are we all saying (on this thread, and troy hunt) that it needs serving over https because the privacy and security of coffee watchers is such a closely guarded secret that they need to be secure in their coffee pot watching habit?
By all means, https up important pages and sites, but lets not make it mandatory to the extent that http is no longer supported by browsers.
As an aside... a Barclays bank advert running in the UK at the moment is showing users that 'a padlock in your browser bar ensures that you are safe and that the site you are visiting is who you think it is' - which is utter bullshit, all a padlock tells you is that site owner has spent 5 minutes setting up LetsEncrypt - it in NO way confirms that they are who they say they are, and it's this lie that Joe Public are being sold right now.
---
[1] Apparently this was a thing once ;)
How do you arrive at the checkout and account management pages? By clicking on a link. If the whole site isn't encrypted, the link can be modified to point to false checkout and account management pages. HTTPS is not only for privacy, it's also for integrity.
ALL https says is 'hey i'm encrypted' it doesn't PROVE to the end user that it's really who it says it is. Extended Validation was supposed to fix this, but that ended up as an evil money grabbing exercise by the CAs so that didn't get the adoption it needed.
Until there's a secure validation banner at the top of the browsers that contains an unfakeable and unbreakable 'this is who I am' statement, then https is just a sticking plaster/bandaid over the whole problem.
And for those who say 'https prevents man in the middle attacks' - no it does not. There are several network level devices that by design decrypt/review/encrypt/spoof-cert traffic to clients (WAN Accelerators and Corporate Proxies being good examples) something that can only be overcome by Security Pinning the Certs to IP addresses... but again hardly anyone does that either.
These network devices (middleboxes) can do that only if the client lets it. As you just said, once the client is compromised, all bets are off. HTTPS by design protects against a compromised network, not against a compromised client.
Please understand that you are wrong here.
You need to go and read the article, and then perhaps some more writing around why it's important for the whole site to be served over TLS.
Once you can read and understand the linked article and why what was described is a real issue you will no-longer sound like you don't know what you're talking about on the Internet.
> I'm just not one of these people who think there are armies of people at the NSA/GCHQ spying on me.
This isn't about NSA/GCHQ, it's about "bad actors". Which bad actors are relevant depends on your circumstances. It's quite likely that the bad actors in the case of maliciously tampering with the login links of a bank, or the link a checkout process on an e-commerce site will not be a government entity, but a criminal operation.
> I'm also against forcing every website in the world onto https.
It's really not that hard to implement TLS on the average website, and the benefits are great.
However the main focus of this article was about TLS on sites that link to sensitive information, such as banks.
> Doing so will significantly raise the bar of accessibility for tinkerers and makers.
There's two things wrong here.
1. It's really not raising the bar very high. Lets encrypt is easy to use, and as a member of a hackspace myself I know that most people there could use it, or get help using it.
2. Just because some "tinkerers and makers" may struggle with some aspect of security doesn't mean that e-commerce sites or banks etc. need to downgrade their security, or that the rest of us need to suffer.
> If I had a webcam that showed the world whether my coffee put needed refilling[1], are we all saying (on this thread, and troy hunt) that it needs serving over https because the privacy and security of coffee watchers is such a closely guarded secret that they need to be secure in their coffee pot watching habit?
This is a straw man argument. We're not talking about, and likely don't care about, your coffee pot.
We do however care about not having our personal data intercepted, our identities stolen, our credit card data misused, or ourselves be profiled etc. All concerns with things like e-commerce, bank, news sites etc. etc.
> By all means, https up important pages and sites, but lets not make it mandatory to the extent that http is no longer supported by browsers.
Ultimately this may happen in the interests of everyone's online safety, and when it does there won't be some sort of "end of times" scenario where coffee pot sites are dissapeared from the Internet, people will just move to use TLS on them.
> As an aside... a Barclays bank advert running in the UK at the moment is showing users that 'a padlock in your browser bar ensures that you are safe and that the site you are visiting is who you think it is' - which is utter bullshit, all a padlock tells you is that site owner has spent 5 minutes setting up LetsEncrypt - it in NO way confirms that they are who they say they are, and it's this lie that Joe Public are being sold right now.
Yes, and it's typical of banks to get this aspect of security wrong, however it's still better than not having TLS, and at this point you're just going to have to go and work out why yourself because I have other stuff to do.
> [1] Apparently this was a thing once ;)
Yes, it famously was: https://en.wikipedia.org/wiki/Trojan_Room_coffee_pot
Of course it was. Hence me using it in my 'straw-man' argument. Maybe I was too subtle.
You still haven't convinced me why I should move everything to TLS. Also, I do doubt you have other stuff to do, seeing as you answered my post, point by point...
Yes there are 'bad actors' but lets not get too paranoid here. We can't wrap everything up in TLS cottonwool.... where does it stop? Are we all too afraid to leave our houses without 'security' ? Do we now talk in code in public just. in. case. someone is overhearing what we say?
I don't need to, you can head off into the world believing what you want. You are however very wrong on this. Wether you decide you are going to continue to be wrong is of course up to you. I don't know you, do what you want.
> Also, I do doubt you have other stuff to do, seeing as you answered my post, point by point...
And I took time out of my day to do so, and yes, I do have other stuff to do.
> Yes there are 'bad actors' but lets not get too paranoid here. We can't wrap everything up in TLS cottonwool....
Taking adequate and proportional steps to secure our data, our identities and our money is not "wrapping everything up in cotton wool".
Risk and security are a sliding scale, we don't need to only talk about the extremes.
> where does it stop? Are we all too afraid to leave our houses without 'security' ? Do we now talk in code in public just. in. case. someone is overhearing what we say?
Another straw man argument, but just for fun:
> Are we all too afraid to leave our houses without 'security' ?
No would be the general answer, but it's going to depend on what your risks are. Who you are, where you live etc.
> Do we now talk in code in public just. in. case. someone is overhearing what we say?
Again, generally no. However if we have something that we want kept private we do either talk in code, or we wait until a more opportune moment.
I can just imagine NatWest: "Oh, is that the problem? Ah, ok, well, let's just go get that domain then. Sorted!"
The thing about domains is that so many companies register companyname-someotherwords.com for legitimate use that if you are suspicious about the domain name you'll get little done. Azure is a case in point.
What if browsers record "tainted follows"? E.g. you visit http. Once you click a link, anything linked from there onwards is not trusted. No http post information is sent to the server without a hard to get around warning page.
Apparently 35% of all UK banks have insecure landing pages. [5][6]
[2] https://www.starlingbank.com
[3] https://www.atombank.co.uk
[5] http://blog.softwareverify.com/list-of-uk-banks-that-are-sec...
[6] https://twitter.com/softwareverify/status/940961044633149440
Well, HSBC's didn't: https://threatpost.com/banking-apps-found-vulnerable-to-mitm...
A bit of programming, but most importantly, general concepts required to understand this kind of issue should be common knowledge.
For me it falls in the same category as the people putting an IP camera to watch their son sleep and broadcasting it to the whole internet. This kind of issue should be understood by them.
In this case, if the "banking manager" was aware of how security works, the issue would not have presented itself in the first place.
a: 0CC175B9C0F1B6A831C399E269772661
b: 92EB5FFEE6AE2FEC3AD71C777531578F
c: 4A8A08F09D37B73795649038408B5F33
etc.
then this is basically the same as storing the plaintext characters because as long as you know the hashing algorithm you can generate a pretty small map of hash -> original character and convert back.
I think the attitude here is kind of douche.
Ridiculous password policy, http home page, virtual keyboard for password, loading javascript from http and what not..
Instead what they did as preventive measure is to buy the domain name that Troy mentioned as one of the possible vector to spoof their site.
Hate to say this, but whoever made that decision as a course of resolution should be axed.
http://www.scotiabank.com/ca/en/0,,2,00.html
Didn't find any contact to report it. Is Twitter really the right place?
And the user shouldn't need to check the certs - if the CAs are trusted (yes there are problems there) then the domain name is enough.
(Banks should also protect against easily phishable domain names but that's a also losing game, and in that case the technical solution is not as simple or complete).
It doesn't seem to matter to me if my ISP is MITM, because someone inside the ISP would need to cause that. If my ISP is forced to MITM by government etc, I am in trouble anyway.
I could see that it could be done by using a bad/spoofed wireless or a public network connection somewhere. That makes sense. I don't do that though; I only use my own secure home network in a wired fashion when accessing my bank account.
If people are able to spoof my network connection, they could interfere with non-https software updates on my machine, which would let them replace the root certs of my browser potentially, in which case https wouldn't matter. Is the assumption here that all software updates on my machine are happening via https and only the bank website is a danger?
My point here is that while I agree what the bank is doing is bad practice, I don't see how it would affect me in any way.
The assumption is that yes, all of your machine’s updates are served over HTTPS. If they weren’t, then of course you’re right - it’d be possible to hijack your machine by serving malicious binaries. That’d be one hell of a security hole.
I fail to see how the bank changing their website to HTTPS is going to save the average Joe.
There are so many websites and things that operate over HTTP that make our machines vulnerable, that I think it is foolishness to use a link that could be MITM to begin with.
That is, it seems to me, that if you simply avoid ever using wireless there is no danger of MITM. I could see that XSS could be done on some sites with ads, and that would be worsened by lack of HTTP.
Is it as simple as "Don't use wifi. Use adblock. HTTP/HTTPS then no longer matters." ?
The HTTP landing page serves a link to the login page. This link could be modified by a hostile network to another site. The fact that the login page is served over HTTPS is immaterial for this attack.
Under that attack, wouldn't be the same whether you are using https or not? If you are in a hostile network with a compromised DNS, Couldn't the domain be phished too? Meaning that a valid certificate trusted by a fake CA would be used by the browser?
I don't think that's possible. A fake CA can't issue out valid certificates because you wouldn't trust their certs to begin with -- it's all about trust and if you know they are a fake CA, then you would never trust them or anything they issue. It's like if a known counterfeiter claims to be selling legit products, you probably wouldn't trust them.
So you need an up-to-date list of trusted CAs (which most of us are relying on google for, in this case), which means trusting google at the very least (a company that compiles and sells your data, and is also based in a nation that issues secret warrants and orders to tech companies). It would be pretty surprising if this wasn't already a vector of attack being actively used (the fact that a trusted list needs to be maintained suggests that it is).
For a NatWest customer accessing their internetbank, the expected, quite frequently observed risk comes from organized phishing teams pulling off mass semi-automated scams. For an attacker that, getting a certificate signed by a fake CA is unrealistic, and the concerns that you list aren't going to change anything since they're not going to do that anyway. On the other hand, getting a misleading certificate signed by a real CA and passing it off as the real thing is entirely feasible by this type of attacker, so fixing that is important.
Nation-state hacking, censorship and advanced persistent threats aren't what's causing the most damage/problems to most people on the internet right now, the multitude of random criminals is the largest issue. If you have to worry about a CA "compromised by nation-states through legal coercion", then this by itself means that you have a very different risk profile than pretty much everyone else; and the risk-reducing activities that make sense for you shouldn't be expected to be relevant for others and vice versa.
> fake CA
Pick one. If your cert isn't signed by a CA that the browser trusts, it won't load the page.
Modifying the link would not be possible if the landing page were served over an encrypted connection.
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).
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.
If the name is unrecognizable for users, _that_ is the user security concern that you should be posting about.
That handles the widest array of security vulnerabilities on http://personal.natwest.com/, whether MITM, compromised site, misspelled domain, etc.
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?
https://arstechnica.com/information-technology/2017/12/nope-...
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.
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.
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.
You want them to continuously keep verifying it’s the correct domain/cert just because this company is too lazy/cheap to buy a cert?