Some POODLE notes

Heartbleed and Shellshock allowed hacks against servers (meaning websites and such). POODLE allows hacking clients (your webbrowser and such). If Hearbleed/Shellshock merited a 10, then this attack is only around a 5.

It requires MitM (man-in-the-middle) to exploit. In other words, the hacker needs to be able to to tap into the wires between you and the website you are browsing, which is difficult to do. This means you are probably safe from hackers at home, because hackers can't tap backbone links. But, since the NSA can tap into such links, it's probably easy for them. However, when using the local Starbucks or other unencrypted WiFi, you are in grave danger from this hack from hackers sitting the table next to you.

It requires, in almost all cases, JavaScript running in the browser. That's because the attacker needs to MitM thousands of nearly identical connections that can fail. There are possibly rare cases where such connections may happen (like automated control systems), but JavaScript is nearly a requirement. That means your Twitter app in your iPhone is likely safe, as the attacker can't run JavaScript in the app. Although, a lot of apps use web GUIs underneath, if only to serve ads, so not all "apps" are safe.

It doesn't hack computers, but crack encryption. It reveals previously encrypted data.

What the hacker will likely try to do is hack your session cookies. That means they won't get your password for your account, but they will be able to log in as you into your account. Thus, while you are at Starbucks, some hacker next to you will be able to post tweets in your Twitter account and read all your Gmail messages. These are two examples -- they really have near complete control over your accounts. They won't be able to steal your password, however.

In theory, the attacker can do much more, but that attacking cookies it the overwhelming most likely vector.

It's the standard protocol that is vulnerable, not anybody's code.  Essentially, they got the math wrong.


Only older versions of SSL are impacted -- but everybody is backwards compatible with older versions. Thus, part of the attack is to "downgrade" both sides, forcing both the client and server to use the older version.

This attack is against SSLv3, which is 15 years old and known to be obsolete. After this version of SSL, engineers renamed it to TLS and reset the version number to 1.0, because they are jerks and want to confuse people. (Actually, the story is that Netscape created SSL, and Microsoft insisted on a name change because they hated Netscape). Thus, the next version after SSLv3 is TLSv1.0.

The solution is to disable SSLv3 (and all prior versions), and leave only TLS version 1.0 (and later versions) enabled. If either the server (the website) or the client (the browser) doesn't support SSLv3, then the hack won't work.

Disabling SSLv3 in servers is difficult, because a lot of users still use IE6, Microsoft's browser from a decade ago. When servers remove SSLv3, then users with IE6 will no longer be able to access the server. However, CloudFlare, which hosts a lot of websites, has disabled SSLv3 across their systems. Apparently they are comfortable with breaking IE6 -- which is good guidance for other people considering the same.

Disabling SSLv3 in browsers is easy. On Chrome, use the command-line flag  --ssl-version-min=tls1, and on Firefox set security.tls.version.min to 1. Generally, there virtually no servers out there who don't support TLSv1, so this shouldn't break anything.

The simplest explanation is, as usual for such things, on Adam Langeley's blog here.