Hoping that whatever ends up coming out is able to be mitigated easily. So much older gear still only supports SSL3.0/TLSv1.0 (I am looking at YOU CISCO ACE).
Some hint of what the mitigation will end up being would be nice. In particular, does this so thoroughly destroy SSL 3.0 that we need to be prepping to turn it off entirely, in which case frankly all hell is going to break loose? Is it tied to ciphers such that we might just be able to cut off RC4 or something? Will it turn out to be "don't allow people to make over a trillion failed connections to an SSL 3.0 service"? This is so vague as to be useless, even as a heads up.
I doubt it has anything to do with the ciphers itself. That would impact far more than just SSLv3 and would also be easy to mitigate, 'disable these ciphers', so much less need for the whole cloak-and-dagger thing that's going on.
A heads up is always useful. Knowing that a vulnerability is being disclosed tonight means I'll make sure to track that and react the second it becomes clear what's going on. That in turn means we'll either disable SSLv3 directly or roll out the patch if that's directly available, instead of only being aware of this after you wake up in the morning and have to hope to god no one used the vulnerability on you in the mean time.
"I doubt it has anything to do with the ciphers itself."
Me too, I just wanted to give a rich range of examples.
I fear it will end up being the "turn off SSL 3.0 everywhere, it's now been rendered useless".
"A heads up is always useful."
Yes, but one slightly more useful would be even more useful, without having to be anywhere near detailed enough to give away the problem.
If anything argues against this being serious it is that it is apparently not such a big deal that the actual responsible people feel a need to issue any sort of warning. While I fear the worst, here's hoping the Register is just fearmongering, as is their wont.
If the vulnerability is limited to SSL 3.0, an easy workaround would be to disable it on both servers and clients.
Most servers should already support at least TLS 1.0. I have been using security.tls.version.min set to 1 on Firefox for a while (which disables SSL 3.0 and below, and also disables the "no extensions" fallback), and other than a period of time when archive.org was SSLv3 only, I have seen no issues.
For clients, a quick look at https://www.ssllabs.com/ssltest/clients.html shows that even older clients (Android 2.3, Java 6, the oldest supported version of IE, etc) support TLS 1.0, so there should be no issues disabling SSLv3 on servers too.
To be frank, this is typical reporting for the Register. The quality of it's reporting has been in a downwards spiral in recent months and I swear it's now little better than the Daily Mail (more technical, granted. But it's just as sensationalist)
I went on a brief hunt for more information about this, and there seems to be a cluster of CVEs created 4 days ago around improper validation of X.509 certificates in android (and libgadu), allowing MitM. If this is it, it is nowhere near the severity of heartbleed.
the register is not exactly the most reliable news source as they're sometimes troll-ish. I would wait until a more reliable source before even worrying about it.
It's always a good idea to regularly check https://wiki.mozilla.org/Security/Server_Side_TLS and ensure your web servers / load balancers are using the best possible (for your particular users) settings. If you don't have to worry about very old and unpatched WinXP users, going with the "intermediate" compatibility level should be the bare minimum.
Also, don't forget about your clients as well. Things like Ruby and Python each have their own set of SSL/TLS configuration that people always seem to forget about.
15 comments
[ 3.2 ms ] story [ 52.3 ms ] threadAll modern browsers support pure TLS, even IE8 on XP
A heads up is always useful. Knowing that a vulnerability is being disclosed tonight means I'll make sure to track that and react the second it becomes clear what's going on. That in turn means we'll either disable SSLv3 directly or roll out the patch if that's directly available, instead of only being aware of this after you wake up in the morning and have to hope to god no one used the vulnerability on you in the mean time.
Me too, I just wanted to give a rich range of examples.
I fear it will end up being the "turn off SSL 3.0 everywhere, it's now been rendered useless".
"A heads up is always useful."
Yes, but one slightly more useful would be even more useful, without having to be anywhere near detailed enough to give away the problem.
If anything argues against this being serious it is that it is apparently not such a big deal that the actual responsible people feel a need to issue any sort of warning. While I fear the worst, here's hoping the Register is just fearmongering, as is their wont.
If the vulnerability is limited to SSL 3.0, an easy workaround would be to disable it on both servers and clients.
Most servers should already support at least TLS 1.0. I have been using security.tls.version.min set to 1 on Firefox for a while (which disables SSL 3.0 and below, and also disables the "no extensions" fallback), and other than a period of time when archive.org was SSLv3 only, I have seen no issues.
For clients, a quick look at https://www.ssllabs.com/ssltest/clients.html shows that even older clients (Android 2.3, Java 6, the oldest supported version of IE, etc) support TLS 1.0, so there should be no issues disabling SSLv3 on servers too.
* No information beyond what is in the (linkbaity) title.
What's the purported scope? Is it implementation specific? What's the exposure? Session decryption? Memory leak? RCE?
> El Reg cannot confirm whether or not it is indeed a serious bug as we have not received details of the vuln.
Then what the hell are you reporting exactly?
[✓] Fear
[✓] Uncertainty
[✓] Doubt
Keep it classy, Register.
I went on a brief hunt for more information about this, and there seems to be a cluster of CVEs created 4 days ago around improper validation of X.509 certificates in android (and libgadu), allowing MitM. If this is it, it is nowhere near the severity of heartbleed.
libgadu: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-448...
many android apps: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-688...
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-689...
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-690...
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693...
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693...
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693...
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693...
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693...
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693...
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-694...
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-694...
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-704...
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-704...
Also, don't forget about your clients as well. Things like Ruby and Python each have their own set of SSL/TLS configuration that people always seem to forget about.
Snitch already generates an alert if a site doesn't use TLS v1.2 - I'll be watching this announcement closely and adding alerts as needed.