Google found the POODLE in SSL 3

[LigH]

Sounds funny, but isn't: "Legacy" secure connections in web browsers via SSL are no more secure. The last version before the new TLS protocol, SSL v3.0, is now officially broken by all means.

You should try to set up your browser not to fall back to SSL3 anymore, but insist in at least TLS 1.0 for https connections. Details here (https://zmap.io/sslv3/).

First reports in "The Register": announcement (http://www.theregister.co.uk/2014/10/14/nasty_ssl_30_vulnerability_to_drop_tomorrow/) and release (http://www.theregister.co.uk/2014/10/14/google_drops_ssl_30_poodle_vulnerability/)

Google Online Security Blog (http://googleonlinesecurity.blogspot.co.uk/2014/10/this-poodle-bites-exploiting-ssl-30.html)

PDF with technical details (https://www.openssl.org/~bodo/ssl-poodle.pdf) on OpenSSL.org

[LoRd_MuldeR]

It should be noted that a workaround for the attack exists. The root cause of the attack is that the Attacker can force the Client to use the insecure SSL 3.0, even when then Client and the Server both support TSL 1.0 (or newer). That's because the Client will fall back to an older/insecure protocol version, if a connection attempt with the up-to-date protocol version has failed. And so the Attacker can interrupt the TSL connection attempts until the Client falls back to SSL 3.0 eventually. If, however, the Client includes the TLS_FALLBACK_SCSV flag in any fallback connection attempt, the Server can recognize SSL 3.0 connection attempts as an unexpected "fallback" and thus refuse them, which prevents the attack. At the same time, a Client that really only supports SSL 3.0 will not include TLS_FALLBACK_SCSV, so the server would still accept in this case. And a server that really only supports SSL 3.0 will ignore this flag, so Client can still fall back to SSL 3.0 in this case.

Yes, this doesn't help at all against the attack, if either the Client or the Server are limited to SSL 3.0. But that is a lost case anyway ;)