SSL 3.0 Vulnerability dropping tomorrow
theregister.co.uk
theregister.co.uk
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.
All modern browsers support pure TLS, even IE8 on XP
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.
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.
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.
* 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...