
SSL 3.0 Vulnerability dropping tomorrow - amingilani
http://www.theregister.co.uk/2014/10/14/nasty_ssl_30_vulnerability_to_drop_tomorrow/
======
cesarb
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.

------
ck2
Very easy to take SSLv3 out of the allowed protocols on nginx

All modern browsers support pure TLS, even IE8 on XP

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

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

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

------
jerf
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
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
"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
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)

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

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

~~~
yourad_io
_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-448...](http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4488)

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

[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-689...](http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6891)

[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-690...](http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6904)

[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-693...](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-694...](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-704...](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)

------
gogolb
[http://securityreactions.tumblr.com/post/99994455427](http://securityreactions.tumblr.com/post/99994455427)

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

