5 ms·

SSL 3.0 Vulnerability dropping tomorrow

58 points by amingilani 12y ago

spydum 12y ago
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).
ck2 12y ago
Very easy to take SSLv3 out of the allowed protocols on nginx All modern browsers support pure TLS, even IE8 on XP
- daenney 12y ago
  Modern browsers aren't the only things we have to deal with. A lot of older (embedded) devices do not speak TLS.
jerf 12y ago
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.
- daenney 12y ago
  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.
  - jerf 12y ago
    "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.
    - armb 12y ago
      Since the heads up _as given_ turned out to be detailed enough to give away the problem, that's clearly false. https://bugzilla.mozilla.org/show_bug.cgi?id=1076983#c51 https://bugzilla.mozilla.org/show_bug.cgi?id=1076983#c51
gogolb 12y ago
http://securityreactions.tumblr.com/post/99994455427 http://securityreactions.tumblr.com/post/99994455427
cesarb 12y ago
Here we go again... 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 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.
yourad_io 12y ago
* No source whatsoever. * 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.
- laumars 12y ago
  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)
- yourad_io 12y ago
  Speculation time 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-4488 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-6887 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-688... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6891 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-689... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6904 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-690... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6934 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6935 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6936 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6937 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6938 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6939 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6940 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-694... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6941 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-694... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7046 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-704... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7047 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-704...
kbar13 12y ago
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.
reedloden 12y ago
It's always a good idea to regularly check https://wiki.mozilla.org/Security/Server_Side_TLS 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.
yourabi 12y ago
This is why I built https://snitch.io https://snitch.io - security and SSL secured sites in particular are moving targets and not "fire and forget". 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.

58 points by amingilani 12y ago

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

ck2 12y ago

Very easy to take SSLv3 out of the allowed protocols on nginx All modern browsers support pure TLS, even IE8 on XP

daenney 12y ago
Modern browsers aren't the only things we have to deal with. A lot of older (embedded) devices do not speak TLS.

jerf 12y ago

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.

daenney 12y ago
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.
- jerf 12y ago
  "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.
  - armb 12y ago
    Since the heads up _as given_ turned out to be detailed enough to give away the problem, that's clearly false. https://bugzilla.mozilla.org/show_bug.cgi?id=1076983#c51 https://bugzilla.mozilla.org/show_bug.cgi?id=1076983#c51

gogolb 12y ago

http://securityreactions.tumblr.com/post/99994455427 http://securityreactions.tumblr.com/post/99994455427

cesarb 12y ago

Here we go again... 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 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.

yourad_io 12y ago

* No source whatsoever. * 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.

laumars 12y ago
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)
yourad_io 12y ago
Speculation time 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-4488 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-6887 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-688... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6891 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-689... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6904 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-690... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6934 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6935 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6936 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6937 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6938 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6939 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6940 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-694... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6941 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-694... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7046 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-704... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7047 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-704...

kbar13 12y ago

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.

reedloden 12y ago

It's always a good idea to regularly check https://wiki.mozilla.org/Security/Server_Side_TLS 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.

yourabi 12y ago

This is why I built https://snitch.io https://snitch.io - security and SSL secured sites in particular are moving targets and not "fire and forget". 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.