Scotiabank internet whizzkids screw up their HTTPS security certs The team behind Scotiabank's Digital Banking Unit isn't impressing some customers, after forgetting to renew the security certificates for their own website. The DBU was set up last year to sell "world class digital solutions" to electronic banking customers around the world. But Jason Coulls, CTO of food safety testing …
Is it me or do we see a rather unhealthy trend developing as of late? I get the impression that more and more companies are much too busy doing "important" stuff right up to a point where they lose track of some of the essential parts which seriously matter.
... that is; they matter for their customers. And who cares about those, right?
This post has been deleted by its author
The certificate is not even assigned to scotiabank it is for the web hosting company ...
X509v3 Subject Alternative Name: DNS:*.webflow.io, DNS:webflow.io
so even before it had expired it would have been wrong.
I'm not even convinced it is an HTTPS enabled website .. look at the content of the website and it just looks like a project/brand microsite ... I can't immediately see where HTTPS would be required (e.g. for logging in or entering details in to a form etc) ... so I would say this looks more like a web hosting reverse proxy configuration error, i.e. HTTPS should not be enabled for this domain, just HTTP.
Scotiabank still does not allow customers to use upper case or special characters in passwords, arguing that it would confuse some customers.
Rather than putting resources into security, Scotiabank has been prioritising the disposal of long time employees and the centralisation of all decisions at head office in Toronto.
The days when you knew your branch manager, and they would bend the rules in an emergency, are long, long gone.
But hey! Scotiabank is still the industry leader in exorbitant service charges!
If, as surmised above, the site is designed to be served over HTTP, then why would you bother monitoring it over HTTPS, or bothering about an expired SSL cert on the server?
A case can be made that the site shouldn't respond at all on 443, but if the server has other sites on HTTPS then it's easy to overlook.
Sometimes this can slip through the cracks.
We're totally NOT depending on our website for business, but its FreeSSL cert had developed a fault and the site had thus reverted back to the SSL cert of the provider (which, of course, gets you immediately rendered unreachable accompanied by much screeching in Firefox, Chrome et al). It was pure luck that I detected this before it became something press worthy (note to self: see if availability monitor can pick this up).
If your site IS your business (or at least a large chunk of it) the site cert takes, of course, more prominence so renewal processes must be set up, but it can happen. All of this stuff is still done by humans, and we're not perfect (as my wife keeps reminding me :) )..
"All of this stuff is still done by humans..."
Why? Mine certainly aren't. Certificate renewal is part of the same automated workflow that handles backups, DNS verification, loopback TLS checks etc. In the event that screws up (e.g. the cert authority API changes without warning) then Supervisor would email me 20 days before the old cert expires. This is basic stuff. Even my throwaway Linode and EC2 dev servers do this. That a bank can't get this right on production equipment is frankly ridiculous incompetence offshore outsourcing.
I think this is a non story. The expired cert is not even for the given website ... I believe this is a 3rd party webhosting error. A default config on the frontend load balancer / SSL reverse proxy probably.
The website just appears to be a marketing site rather than a banking service site and as such should not HTTPS to be configured.
I'd love to say this is the bank's fault and is a result of outsourcing but I can't see any direct evidence of that.
The website just appears to be a marketing site rather than a banking service site
Isn't that worse? The bank regularly sends you emails and links and popups to dozens of non-secure bank affiliated advertising websites that you are supposed to know not to use for anything secure.
Then you get an email from scotiabank.google.com with a link to a secure site which does ask for your password.
It's like air traffic control playing "simon says" with their landing instructions
Why do people keep implying that just because you’re not logging in or doing banking on a website then it implies it doesn’t need https to begin with?
How can you be so wrong I don’t get it...
There are many reasons for using tls aside from just encrypting credentials.
As Troy Hunt has demonstrated on many occasions: there is absolutely no reason why every website should serve all content over https in 2017. It’s free after all (and said AMCE service keeps track of certificate expiary/renewals for you).
Every site from a banks random marketing page through to the blog my sister set up for her kittens should have basic tls. There is no technical reason not to.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
