Disabling SSLv3 and RC4 | Hacker News Reader

Disabling SSLv3 and RC4

googleonlinesecurity.blogspot.com

146 pointshelper40 comments

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.

Once you've checked your server, then you can head over to https://mozilla.github.io/server-side-tls/ssl-config-generat... and get an idea of how to change your server's SSL configuration.

Anything like this for IIS that shows client compatibility?

The only configuration tool I know of is https://www.nartac.com/Products/IISCrypto/.

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).

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.

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

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.

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

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.

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...

This is a good move.

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.

[0] https://tools.ietf.org/html/rfc7568

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.

People who are still using Windows XP are irresponsible. https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp...

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.

We still need the other side of this: Chrome, Firefox, MSIE, and Safari need to start refusing to negotiate SSLv3 and RC4.

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, [...]"

Chrome has already disabled SSLv3 (as have other browsers). We have also announced the planned removal of RC4 early next year: https://groups.google.com/a/chromium.org/forum/#!msg/securit.... (As have Mozilla and Microsoft.)

Thanks.

The closed Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1106470

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.

What do you suggest they use instead? No encryption?

Well, for all of its problems, SSL3 is less trivial to MITM.

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.

Given gmail's volume that would pretty much make it a requirement for all other mail services. A mandatory STARSTTLS would make me happy!

How mandatory STARTTLS (on Google servers' side) would help you against MitM downgrade attack?

The only way to avoid it is for your MUA to require STARTTLS.

Or for the server to terminate the connection if STARTTLS is not requested

Yes, but how that'd prevent the attack?

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.

They also support SMTP over TLS, which isn't vulnerable. Not sure what you mean about switching, perhaps you're confusing terms? TLS != STARTTLS.

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.

SMTPS (SMTP-over-SSL/TLS) still exists in some places (465/TCP) although it was technically deprecated a long time ago.

If you want to get rid of POODLE vulnerability due to SSLv3,

Here's how you can solve it in Google Chrome, Firefox & IE - http://bit.ly/disable-SSLv3

Reply on news.ycombinator.com