
This POODLE bites: exploiting the SSL 3.0 fallback - ch0wn
http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
======
tptacek
I'm not entirely sure, because I'm in a car waiting to pick up my daughter
from play practice while I consider it, but I think this is worse than BEAST.
It's slower, but it's easier.

POODLE seems to be a padding oracle based on SSL 3.0's inability to fully
validate padding. The oracle only gives you the last byte of a block; a full
extended padding oracle gives you successive bytes, but this vulnerability
doesn't. The authors sidestep that problem by using application-layer control
of the boundaries of blocks to repeatedly line up the byte they want to learn
with the last byte of padding the vulnerability reveals. _C l e v e r_ !

The difference, I think, between POODLE and BEAST is that BEAST needed not
just blockwise "chosen-boundary" control over plaintext, but also a continuous
channel that would provide the client with fine-grained control over the first
N bytes of each request. It didn't work (IIRC) with vanilla Javascript.

This attack, however, seems to.

~~~
gsnedders
> The difference, I think, between POODLE and BEAST is that BEAST needed not
> just blockwise "chosen-boundary" control over plaintext, but also a
> continuous channel that would provide the client with fine-grained control
> over the first N bytes of each request. It didn't work (IIRC) with vanilla
> Javascript.

Sure you have control over the first N bytes. Look at the request-line: "GET
/hello/world/this/is/my/url HTTP/1.1". Sure, you don't control the spaces, but
you can assume any practical implementation uses a single space character.
Combine that with control over the method (with XHR or statically through
<form> or <img>) and the path, you're in business.

AIUI, the JS PoC took a fair bit of trial-and-error to find the right value of
N, but all these attacks require a fair number of requests anyway, so it's not
really significant.

~~~
cryptbe
> Sure you have control over the first N bytes. Look at the request-line: "GET
> /hello/world/this/is/my/url HTTP/1.1". Sure, you don't control the spaces,
> but you can assume any practical implementation uses a single space
> character. Combine that with control over the method (with XHR or statically
> through <form> or <img>) and the path, you're in business.

tptacek is right. To make BEAST work we had to control _all_ the bytes of the
very first block. We tried very hard to make it work with Javascript, but we
couldn't. Java applet (and maybe Flash) was the only tool that gave us that
kind of control.

------
brians
Apparently independently discovered by Thomas Pornin with a few hours of work:
[http://chat.stackexchange.com/transcript/message/18151930#18...](http://chat.stackexchange.com/transcript/message/18151930#18151930)

We saw this with Heartbleed too: given sure confidence that there _is_ a
vulnerability in a particular diff, skilled security researchers can find it
very quickly. It makes me want to find such and firmly tell them that there
are vulnerabilities in TLS 1.2.

~~~
jared314
> We saw this with Heartbleed too: given sure confidence that there is a
> vulnerability in a particular diff, skilled security researchers can find it
> very quickly.

That reminds me of the old QA technique / tactic of only telling the
developers where a bug was found. Sometimes you don't even have to find an
issue, you can just pick a complicated module.

~~~
wglb
There was a study done decades ago where code was seeded with a number of
bugs. Developers were told that there were a number of bugs. They found that
many, but the overlap was not total. That is to say, they found bugs that the
study authors did not seed.

~~~
chetanahuja
Phew, I sure am glad that we instituted a company-wide policy of not putting
any bugs in the code in the first place. Just makes life easier all around.

~~~
wglb
Well, I remember at the time reading this that if one picked an arbitrary
number, and told the developers that there were that many, they would find
that many even if none were inserted.

------
xt
Here's relevant nginx configuration to disable SSLv3:

    
    
      ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
      ssl_ciphers EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:EECDH+RC4:RSA+RC4:!MD5;
      ssl_prefer_server_ciphers on;
    

This ciphersuite is recommended by CloudFlare.

~~~
praseodym
This works, but from TFA:

"Disabling SSL 3.0 support … presents significant compatibility problems"

"Therefore our recommended response is to support TLS_FALLBACK_SCSV."

~~~
modoc
CloudFlare sees 0.65% of HTTPS traffic using SSL v3 so it's a pretty small
impact.

~~~
zobzu
Except if you force downgrade browsers. So they nee to actually support the
extension to prevent that.

~~~
Buge
The point was that if you disable SSLv3, you will cut off some users from your
site, but only 0.65%, so it's not that bad of an effect.

------
cesarb
Mozilla is going to disable SSL 3.0 by default in Firefox 34:
[https://blog.mozilla.org/security/2014/10/14/the-poodle-
atta...](https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-
the-end-of-ssl-3-0/)

~~~
xenophonf
You don't have to wait for Firefox 34. Go to about:config and set
security.tls.version.min to 1. That will force the browser to use only TLSv1
or newer.

~~~
cesarb
I've done that since before security.tls.version.min existed (the pref had
another name before, and allowed nonsensical combinations like allowing TLS
1.0 and SSL 2.0 but not SSL 3.0).

But Firefox 34 disabling SSL 3.0 by default will disable it even for
nontechnical users. That should force the remaining non-TLS-compatible servers
and middleboxes to be fixed.

On the server side, hopefully the knee-jerk reaction of disabling SSL 3.0 will
have the same effect, forcing the remaining non-TLS-compatible clients and
middleboxes to be fixed.

That could allow for the SSL 3.0 code to be finally removed from both clients
and servers, like happened with the older SSL 2.0. And with it, the fallback
code for extension intolerant servers, so clients can count on being able to
use extensions.

------
turingbook
Adam Langley from Google explained this in more details：
[https://www.imperialviolet.org/2014/10/14/poodle.html](https://www.imperialviolet.org/2014/10/14/poodle.html)

------
jerf
Check me on this: The TLS_FALLBACK_SCSV will prevent downgrade attacks, yes.
However, any "real" SSLv3 connections will still be SSLv3 and still fully
vulnerable to the described attack. Downgrading is not a necessary component
of the attack, it just increases the number of vulnerable client/server
combinations to include those that would normally not be vulnerable due to
negotiating TLS1.0+. Therefore, if you are in a position where you truly care
about security and the fact the SSLv3 has such an enormous hole in it is
unacceptable, you should still be looking at simply turning off SSLv3 as the
only acceptable mitigation, even if that does cut some clients off.

Yes?

(Except please note for the purposes of this question I'm assuming as a given
that cutting off SSLv3 is considered preferable by the entity in question to a
very weak SSL negotiation. Whether or not any given entity should have that
opinion is a different question; I politely ask that you get into that
question elsewhere.)

~~~
gsnedders
The end of
[https://www.imperialviolet.org/2014/10/14/poodle.html](https://www.imperialviolet.org/2014/10/14/poodle.html)
talks about this better than the several paragraphs I just wrote in a draft
comment. So go read that.

tl;dr: practically, yes, we want to move away from SSLv3 ASAP, though it isn't
_totally_ broken yet.

~~~
jerf
Thanks. I wanted to check because there's a common pattern in these sorts of
security incidents where some suggestion for possible mitigation gets made
(note how I weakened that phrase) and by the time the game of security
telephone is played out over a few panicky hours it turns into "just do X and
the problem is solved!". For instance, "just switch to RC4!" was not exactly
the most solid of advice for BEAST, if one actually thought about it, but it
was frequently presented as The Solution (TM). (Not necessarily by
knowledgeable people, of course, but by enough people.)

TLS_FALLBACK_SCSV has the danger of becoming that, but in the short term it
doesn't seem like it actually does much in a world where, AFAIK, not very many
SSL connections support it.

------
AbeEstrada
Disable SSLv2 and SSLv3

For Apache:

SSLProtocol all -SSLv2 -SSLv3

For Nginx:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Source: [http://blog.rlove.org/2013/12/strong-ssl-
crypto.html](http://blog.rlove.org/2013/12/strong-ssl-crypto.html)

~~~
ecaron
For any unfortunate souls using IIS, Digicert has a walkthrough of disabling
SSLv3 at [https://www.digicert.com/ssl-support/iis-disabling-
ssl-v3.ht...](https://www.digicert.com/ssl-support/iis-disabling-ssl-v3.htm)

------
pjl
If you're using AWS' ELB, Amazon has already added a new Predefined Security
Policy with SSLv3 disabled: ELBSecurityPolicy-2014-10

~~~
aastaneh
Yes. If you have a lot of ELBs, use the following instructions instead of
changing the policies by hand:
[https://gist.github.com/aastaneh/46ceb03150e5284b8a3a](https://gist.github.com/aastaneh/46ceb03150e5284b8a3a)

------
rcthompson
I'm starting to wonder how many other important vulnerabilities I'm missing
because their discoverer didn't come up with a catchy name like Heartbleed,
Shellshock, or POODLE.

------
Cybershambles
I'm starting to collect articles of merit related to the new attack.

I'll continue to grow the list the more I see/read.

[https://cybershambles.com/question/97-the-sslappening-
poodle...](https://cybershambles.com/question/97-the-sslappening-poodle-major-
vulnerability-in-ssl-30-cve-2014-3566)

------
michaelbuckbee
I made a "non-technical" Poodle scan reporter at:
[https://www.expeditedssl.com/poodle](https://www.expeditedssl.com/poodle) if
anybody needs to convince someone in their organization that a problem needs
addressing and to take action.

~~~
borski
This seems to be reporting "not vulnerable" no matter what I put in. Known
vulnerable sites still are getting the checkmark.

We wrote one also at
[https://www.tinfoilsecurity.com/poodle](https://www.tinfoilsecurity.com/poodle)

~~~
romanminkin
Here is another one vulnerable hosts checker
[http://poodlemap.com/](http://poodlemap.com/)

------
omh
It seems that this is an attack on the CBC-mode ciphers but doesn't change
anything about the RC4 ciphers.

RC4 is mentioned in passing as having weaknesses, but is it actually broken?
If we can't disable SSL3 completely would using only RC4 ciphers be an option?

~~~
mzs
RC4 in TLS is pretty bad too:

[http://www.isg.rhul.ac.uk/tls/](http://www.isg.rhul.ac.uk/tls/)

"Our second attack applies to TLS and can be carried out in a single
connection or session (but tolerates multiple connections/sessions). It
exploits certain double-byte biases in RC4 keystreams (the Fluhrer-McGrew
biases). It targets plaintext bytes located at any position in the TLS
plaintext stream. The number of encryptions needed to reliably recover a set
of 16 consecutive targeted plaintext bytes is around 10 times 2^30, but
already with only 6 times 2^30 sessions, these target bytes can be recovered
with 50% reliability. Since this double-byte bias attack does not require the
TLS Handshake Protocol to be rerun, it can in practice be more efficient than
our single-byte bias attack."

[http://www.isg.rhul.ac.uk/tls/RC4biases.pdf](http://www.isg.rhul.ac.uk/tls/RC4biases.pdf)

edit: I could not get star to show-up, so I just spelled it out as 'times.'

~~~
omh
That's the "worst" RC4 attack I'm aware of. But I'm not sure that it's quite
at the level of a practical attack - certainly not as bad as POODLE.

------
userbinator
_Usually, the server will reject this record, and the attacker will simply try
again with a new request. Occasionally (on average, once in 256 requests), the
server will accept the modified record_

This suggests to me that a possible workaround could be to detect this attack
because it will generate the characteristic pattern of a successful record
amongst many invalid ones, and then expire the relevant cookies; by the time
the attacker has figured out a byte or two, the cookie has already become
useless. It could potentially turn into a denial-of-service, but that's
something anyone with MITM capability can do trivially anyway.

------
justinweiss
FYI, if you're using Twilio:
[https://twitter.com/twilio/status/522446663130963969](https://twitter.com/twilio/status/522446663130963969)

"If you are encountering trouble with inbound Twilio requests while mitigating
the SSLv3 vuln, contact help@twilio.com for direct help."

(That is, they have to manually enable TLS on your account.)

Also, if you're using GET requests with ExactTarget, you'll run into the same
thing, but I haven't heard back from them if / when they'll have that fixed.

------
nutmeg
How to disable SSL 3.0 in IIS:
[http://support.microsoft.com/kb/187498](http://support.microsoft.com/kb/187498)

------
IgorPartola
Practically speaking, how broken is SSLv3.0 now? Are we hours, days, weeks,
months, or years from someone actually getting out there and exploiting this?

~~~
rythie
Sounds fairly straight forward...

You need 256 requests to get one byte of clear text. A 160bit session key is
likely to be 40 bytes, so that's 10,240 requests to get the session key - it
might actually be less if you can take shortcuts because you know the result
bytes can only be 0-9a-f. You also need to be a man in the middle.

------
jvehent
To business owners and large sites operators out there: before disabling
SSLv3, make sure that none of your clients/customers/users are stuck on IE6.
We still see significant IE6 traffic coming from China. Some legacy clients
are also stuck on SSLv3.

As a general rule, review your logs before disabling things. And ask your
users to use modern browsers as soon as possible.

~~~
yuhong
If you absolutely have to use IE6, go to Internet Options's Advanced tab and
check TLS 1.0 and while you are at it uncheck SSL 2.0. But of course the
preferred solution is to upgrade and while you are it please also update to XP
SP3 if you hasn't already. There is no WGA check in WinXP service pack in
general, despite such misconceptions.

~~~
jvehent
I'm assuming that a user stuck on IE6 doesn't have the necessary technical
expertise to upgrade or change security parameters.

~~~
cesarb
I'd assume a user stuck on IE6 without the necessary technical expertise can
follow a detailed guide full of pretty pictures written by someone else to
change security parameters.

There's also the old trick of giving the user a .reg (or if that's too crude,
a simple executable) to poke the relevant settings directly in the registry.

(Poking directly in the registry can break if Microsoft changes the way that
setting is stored, but they won't change anything on XP anymore, so it's as
safe as poking in the registry usually is.)

------
ck2
Firefox 34 will disable SSLv3 entirely:

[https://blog.mozilla.org/security/2014/10/14/the-poodle-
atta...](https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-
the-end-of-ssl-3-0/)

Already using the beta, it is very stable.

You can also set _security.tls.version.min_ to 1

In Chrome set the command line flag _\--ssl-version-min=tls1_

------
laumars
Sorry if I've have missed this if it's been posted elsewhere, but is there a
way of having Apache log which SSL protocol version is being used for SSL/TLS
connections?

I've seen people post figures like 0.85% of HTTPS connections have been SSL
3.0 and was wondering how those figures were compiled.

------
rb2e
Reading [https://www.openssl.org/~bodo/ssl-
poodle.pdf](https://www.openssl.org/~bodo/ssl-poodle.pdf) may also be helpful
if you want to fully understand this exploit.

------
mikelat
This has pretty large implications for countries (namely china) with still a
sizable IE6 userbase. IE6 doesn't support TLS by default, making https
effectively completely unsupported for that browser.

~~~
r00fus
Isn't it an option? I remember IE5 having TLS1.0 as an option. Just because
it's default not enabled doesn't mean it's "effectively completely
unsupported". Browser protocol support matrix here:

[http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_br...](http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers)

------
ctz
[http://jbp.io/2013/07/07/tls-downgrade/](http://jbp.io/2013/07/07/tls-
downgrade/)

An old writeup of mine on TLS downgrade, if anyone's interested.

------
olov
Disable SSL3.0 in golang ListenAndServeTLS:
[https://gist.github.com/olov/eb60ab878eb73a7c5e22](https://gist.github.com/olov/eb60ab878eb73a7c5e22)

------
borski
You can check to see if you're vulnerable using our free tool:
[https://www.tinfoilsecurity.com/poodle](https://www.tinfoilsecurity.com/poodle)

------
cmdr_keen
[https://zmap.io/sslv3/](https://zmap.io/sslv3/) \- "POODLE Attack and SSLv3
Support Measurement"

------
davidgerard
We are in the horrible position of supporting some straggling IE6 users.
Thankfully disabling SSLv3 means they can no longer log in.

------
aburan28
This vulnerability is being downplayed and details are being kept secret until
they can patch this bug because of how severe this is

------
justcommenting
this may help clarify why Firefox dragged its feet for so long to enable TLS
1.2 support by default...from the timeline, we could probably make some
guesses as to when certain agencies took notice of this attack.

the real question is why it took major site ops this long to realize. given a
trove of handshakes (which Google has been saving for years), user-agent
headers, and expected ciphersuites, it perhaps should not have been too
difficult to detect downgrade attacks in the wild. that doesn't in itself give
you POODLE, but it probably offers some clues...especially given other
information available to them.

~~~
justcommenting
despite the positive changes in today's Firefox release, it's worth
remembering that time Firefox decided the GUI options for disabling sslv3
should be removed
[http://forums.mozillazine.org/viewtopic.php?f=23&t=2722163](http://forums.mozillazine.org/viewtopic.php?f=23&t=2722163)

~~~
yuhong
To be honest, I remember the Slashdot article that incorrectly suggested that
SSL 2.0 and TLS 1.0 was affected by BEAST.

~~~
justcommenting
i was not implying that POODLE affected TLS 1.0/1.1 in my (downvoted) parent
comment, but was pointing out that the scope of ciphersuites in Firefox has
been effectively constrained for a large number of users by defaults and GUI
toggles vs. enabled about:config prefs for quite some time now.

~~~
yuhong
And what I am talking about is why.

~~~
justcommenting
there are many layers of indirection.

i wouldn't dispute that disabling sslv3 gui prefs in Firefox may have had
significant positive impacts on many users or that many users are clueless
about crypto in general as it seems you're implying, but it's worth
considering that those decisions also have implications that may be convenient
for other parties, like dramatically increasing the activation energy to
configuring a browser for security.

another example is how long it currently takes to configure via GUI
distrusting or at least warning users when Firefox relies on CAs that users
from a given country may almost never encounter. should your average Firefox
user in the United States always silently trust Turkmenistan's CA out of the
box?

