Well, Halifax (one of the bigger banks in the UK) has a similar config: https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2...

I would have expected banks to have audits for things like these fairly regularly. Does anyone know why they are running such a broken configuration when a lot of these vulnerabilities have been around for months/years? Not to mention that even ignoring any vulnerabilities, their ciphersuite is dire.

I'd be surprised / disappointed if banks weren't subject to PCI DSS audits and I know from my own personal experience with PCI compliance that the SSL 3 and TLS 1.0 would fail many 3rd party vulnerability scans.

So I was very surprised to read your post and after checking the URL (www.halifax-online.co.uk) myself, sadly it seems you're right.

Sadly this isn't the first time I've questioned Halifax over their security policy for online banking. When I first signed up with them approximately 5 years ago, their login process consisted predominantly of researchable questions (eg "what was your pet's name", "what primary school did you attend", etc). Thankfully now they have a standard 2 password process now with 2FA used for any additional payment processing.

Banks aren't subject to company wide PCI DSS audits. Which makes sense as you don't usually input your credit card number anywhere...

I'm not going to disagree with your generalisation there. However with Halifax, specifically, you input your debit card details as authentication when resetting your password / sending user name reminders. And since user names are non-memorable (the one assigned to me was a 9 digit integer!), you can find yourself using the user name reminder feature on Halifax more regularly than you'd normally expect.

Lloyds appears to have an identical config:

https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2...

Banks are sadly frequently too slow moving and bureaucratic to keep up with the rest of the world, and often don't have any good infosec people.

Case in point - I recently found myself (very reluctantly and under severe protest) patching an AES library to talk to a major bank's SFTP-based file transfer service, as they're still using a mode that's been broken since 2008. No-one at said bank was able to comprehend why this was a problem.

Heh, my bank just disabled RC4 (and enabled TLS1.2 by default) due to Chrome refusing to open the website. So I guess something good came out of it.

They might instruct all their customers to use IE6 for "security".

Isn't 3DES still "considered secure"? I know DES has been broken, but major Cloud hosts still recommend 3DES in their VPNs.

It's only secure when used with TLS 1.1+ where it has an effective security of 112 bits. Otherwise it is susceptible to the BEAST attack, like any other CBC cipher suite, unless the client has been updated to mitigate the attack.

Actually just had this conversation with someone about setting up a new https setup for hosting a tool and the amount of online "guides" that still reference 3DES (when other options may be more suitable) is impressively high. Yes 3DES is still "secure" in situations but other alternatives are preferred when we can take them.

It is secure, but it is much slower than AES and requires frequent rekeying because of small block size.

I would expect banks to allow more than a case-insensitive password of no longer than 8 letters and numbers (only) too.

It's kind of a sad state...