If you run an SSL server it is well worth running it through https://www.ssllabs.com/ssltest/index.html to spot any config errors. It was this that spotted I had SSLv3 enabled. I would have been completely clueless otherwise.
Maybe once major browsers all disable RC4, my bank will finally stop using it. Or maybe they'll just sit on their hands and tell people to use IE6. I don't know. Anything is possible when they're using such a ridiculous TLS config in 2015 (only TLS 1.0, only 3DES and RC4).
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.
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.
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.
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.
As an aside, I thought this was a funny appeal to authority:
> SSLv3 has been obsolete for over 16 years and is so full of known problems that the IETF has decided that it must no longer be used. <link to RFC 7568[0]>
This blog post was written by Adam Langley, who is also one of the authors of RFC 7568.
The only mainstream browser that doesn't support TLSv1 by default is IE6, and it's been dead for quite some time.
(At one of my API endpoints, I'm seeing IE6 market share in the range of 0.013%. And this is in South Korea where IE market share is abnormally high to begin with, so I'm sure the numbers are even lower in most other parts of the world.)
So this change has more to do with API clients than browsers. Unfortunately, a lot of API clients are still written for, and run on, grossly outdated platforms. For example, Java 1.4 is as old as IE6, but one still sees it in the wild from time to time.
Requiring Server Name Indication (SNI) extension is quite significant as if I understand correctly then this blocks Windows XP to access any of the Google services with any version of Internet Explorer.
I'm not sure it's all that significant - it's been inevitable for years, and Chrome and Firefox will still work.
Running a 14-year-old browser on a 14-year-old OS and complaining about support being dropped is like running a computer with 256MB of RAM and complaining you can't play the latest games :)
They are not dropping support immediately. They are providing advice so that future TLS clients (particularly embedded) will not have problems when support for things like TLS 1.0 is dropped likely years in the future.
From the post: "we expect to disable both SSLv3 and RC4 support at Google’s frontend servers and, over time, across our products in general, including Chrome, Android, [...]"
What I don't understand is how google can be comfortable to use TLS on their SMTP service given that it is vulnerable to a STARTTLS downgrade MITM attack. It's like switching from old encryption to optional encryption.
Downgradeable encryption is arguably better than none at all. It raises an attacker's prerequisites from just passive snooping to active tampering.
Yeah, it's an illusion of security to an extent, it's imperfect, but between waiting a decade or two for SMTPS delivery to be widespread, and using STARTTLS today, I'll take STARTTLS.
T̶h̶e̶y̶ ̶w̶o̶u̶l̶d̶n̶'̶t̶ ̶t̶a̶k̶e̶ ̶a̶ ̶d̶e̶l̶i̶v̶e̶r̶y̶ ̶o̶n̶ ̶p̶o̶r̶t̶ ̶2̶5̶ ̶w̶i̶t̶h̶o̶u̶t̶ ̶S̶T̶A̶R̶T̶T̶L̶S̶.̶.̶.̶ ̶i̶n̶t̶e̶r̶e̶s̶t̶i̶n̶g̶.̶ ̶ ̶D̶o̶e̶s̶ ̶a̶n̶y̶o̶n̶e̶ ̶k̶n̶o̶w̶ ̶i̶f̶ ̶t̶h̶i̶s̶ ̶i̶s̶ ̶u̶n̶i̶v̶e̶r̶s̶a̶l̶?̶ (Edit: may have spoken too soon. smtp.gmail.com responds "530 5.7.0 Must issue a STARTTLS command first." to MAIL FROM, which is I think to force a Gmail user to auth over STARTTLS before sending mail for relaying. The gmail.com MX servers don't appear to force STARTTLS.) Gmail could basically strongarm everyone into using STARTTLS and valid certs, for both sending and receiving, at which point we can release a new RFC requiring immediate STARTTLS or the connection will be closed, and everyone will already be capable of obeying it to be able to interop with Gmail.
The active attacker may tell your MUA to use the plain text, but this doesn't mean the whole connection must be unencrypted end-to-end. I don't see why the connection past the attacker can't still use STARTTLS (or even "classic" port-based TLS). Google servers won't even know the connection is not secured end-to-end.
That said, requiring TLS/STARTTLS on the server side is a good idea. But it doesn't protect from downgrade attacks.
I was under the impression that STARTTLS was the only implementation of SMTP over TLS.
If major providers do not respect the STARTTLS protocol and effectively make encryption mandatory that makes me happy. But as far as I know the standard says STARTTLS is optional.
