16 ms·

This POODLE bites: exploiting the SSL 3.0 fallback

391 points by ch0wn 12y ago

brians 12y ago
Apparently independently discovered by Thomas Pornin with a few hours of work: http://chat.stackexchange.com/transcript/message/18151930#18151930 http://chat.stackexchange.com/transcript/message/18151930#18... 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.
- tptacek 12y ago
  Pornin did this --- to Thai Duong, no less! --- with CRIME, too. That guy is a freak of nature. I also ruefully remember how Halvar Flake did this to Dan Kaminsky's embargoed DNS vulnerability.
  - cryptbe 12y ago
    When Pornin disclosed CRIME I was telling myself: "Wait a minute, I saw this name somewhere." Then I remembered that it was Pornin's article [1] that helped me understand how zlib flush modes work. I thought that was pretty funny. [1] http://www.bolet.org/~pornin/deflate-flush-en.html http://www.bolet.org/~pornin/deflate-flush-en.html
    - tptacek 12y ago
      You guys are both my heroes.
- jared314 12y ago
  > 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 12y ago
    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.
    - xenophonf 12y ago
      If you can dig up the citation, I'd love to read this. That's fascinating.
      - wglb 12y ago
        I was not successful, but a sibling comment to yours https://news.ycombinator.com/item?id=8458030 https://news.ycombinator.com/item?id=8458030 provides a very useful description of the phenomenon.
    - chetanahuja 12y ago
      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 12y ago
        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.
      - calinet6 12y ago
        You laugh, but this is closer to most companies "quality policy" than otherwise. True quality comes from good process and systems, nothing more, nothing less.
    - anonymfus 12y ago
      You can use overlap to estimate total number of bugs: http://en.wikipedia.org/wiki/Lincoln_index http://en.wikipedia.org/wiki/Lincoln_index http://allendowney.blogspot.com/2014/07/last-year-my-occasional-correspondent.html http://allendowney.blogspot.com/2014/07/last-year-my-occasio...
- haberman 12y ago
  I don't follow -- how is it an independent discovery if it was posted after complete details had already been released by Google?
  - tptacek 12y ago
    Pornin's comments on SE predate the publication.
    - haberman 12y ago
      Oh my bad. What is the explanation of this part? "given sure confidence that there is a vulnerability in a particular diff, skilled security researchers can find it very quickly." Was there previously an announcement that a vulnerability existed, without details of what the vulnerability was?
      - cesarb 12y ago
        Yes, there was: https://news.ycombinator.com/item?id=8452931 https://news.ycombinator.com/item?id=8452931 That announcement implied that the vulnerability was SSL 3.0 only. Knowing that, the obvious place to look at would be the differences between SSL 3.0 and its successor TLS 1.0.
      - brians 12y ago
        There was a lot of Twitter traffic about SSL3 being bad. But TLS1 has very few differences from SSL3. In Heartbleed, we knew that it was introduced with a particular OpenSSL version. That had 12 changes; 8 were DTLS. Two were clearly not relevant. One was heartbeat. Dan Franke took about fifteen minutes to go from that set of inputs to a sketch of heartbleed. I now advocate QA by what I call "virtual tests": you don't have to write the tests, just the failure messages. Developers will do the rest of the work on their own.
tptacek 12y ago
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 12y ago
  > 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 12y ago
    > 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.
jvehent 12y ago
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 12y ago
  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 12y ago
    I'm assuming that a user stuck on IE6 doesn't have the necessary technical expertise to upgrade or change security parameters.
    - cesarb 12y ago
      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.)
    - zobzu 12y ago
      to be honest a user on IE6 can be compromised in a zillion other ways :/
- pixl97 12y ago
  As a web app developer focusing on applications in both oil and healthcare related apps for smaller businesses we disabled SSL3 early this year after XP was depreciated. The vast majority of our clients had upgraded to a newer version of Windows already, but a few stuck on XP were able to use Chrome or Firefox to access the programs. As for legacy clients, time to firewall them from the internet. They make the Internet a more dangerous place for everybody. If your device/program cannot be updated then it needs put on a vlan'd network segment. Breach after breach have shown that attackers will use any exploitable resource go gain a foothold inside your network.
pjl 12y ago
If you're using AWS' ELB, Amazon has already added a new Predefined Security Policy with SSLv3 disabled: ELBSecurityPolicy-2014-10
- aastaneh 12y ago
  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
mikelat 12y ago
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 12y ago
  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_browsers http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_br...
justcommenting 12y ago
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 12y ago
  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 12y ago
    To be honest, I remember the Slashdot article that incorrectly suggested that SSL 2.0 and TLS 1.0 was affected by BEAST.
    - justcommenting 12y ago
      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 12y ago
        And what I am talking about is why.
        12y ago
xt 12y ago
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.
- thibaut_barrere 12y ago
  For those who want to verify their change after updating the configuration (since I looked for such information): either use "nmap --script ssl-enum-ciphers -p 443 <host>" or ssllabs (eg: https://www.ssllabs.com/ssltest/analyze.html?d=wisecashhq.com&hideResults=on https://www.ssllabs.com/ssltest/analyze.html?d=wisecashhq.co...) and you will see the enabled protocols.
- pixl97 12y ago
  For those running IIS, use IIS Crypto by Nartac Software for a decent GUI on configuring your protocol and cipher options.
- praseodym 12y ago
  This works, but from TFA: "Disabling SSL 3.0 support … presents significant compatibility problems" "Therefore our recommended response is to support TLS_FALLBACK_SCSV."
  - sslalready 12y ago
    Disabling SSLv3 will indeed affect a significant amount of clients in the real world. I've seen a few commenters here on HN that point out that pretty much everything since Windows XP (ignoring IE6) supports at least 1.0 of the TLS protocols. While that may be correct in theory, in practice it's not. At a 1MM+ visitors/week site we still see a few percent of our users that regularly connect using SSLv3 across different versions of Windows, including more modern ones such as Windows Vista, 7 and 8(!) Though I'm not sure why this is the case, antivirus software suites such as McAfee[1] have in the past been known to disable TLS 1.0 system wide in Windows. [1] http://answers.microsoft.com/en-us/ie/forum/ie8-windows_other/tls-10-on-internet-explorer-8-will-not-stay/3be14cfa-314c-46f6-a154-3a4eddaa5024 http://answers.microsoft.com/en-us/ie/forum/ie8-windows_othe...
rb2e 12y ago
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.
turingbook 12y ago
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
rcthompson 12y ago
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.
AbeEstrada 12y ago
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 12y ago
  For any unfortunate souls using IIS, Digicert has a walkthrough of disabling SSLv3 at https://www.digicert.com/ssl-support/iis-disabling-ssl-v3.htm https://www.digicert.com/ssl-support/iis-disabling-ssl-v3.ht...
- budgi3 12y ago
  For IIS: Nartac IIS Crypto gives a nice GUI to manage all Protocols, Ciphers, Hashes and Key Exchanges https://www.nartac.com/Products/IISCrypto/ https://www.nartac.com/Products/IISCrypto/
cesarb 12y ago
Mozilla is going to disable SSL 3.0 by default in Firefox 34: https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/ https://blog.mozilla.org/security/2014/10/14/the-poodle-atta...
- xenophonf 12y ago
  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 12y ago
    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.
  - perlgeek 12y ago
    And if you use thunderbird for emails, remember to do there too. (Same config key).
jerf 12y ago
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 12y ago
  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 12y ago
    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.
- paulannesley 12y ago
cmdr_keen 12y ago
https://zmap.io/sslv3/ https://zmap.io/sslv3/ - "POODLE Attack and SSLv3 Support Measurement"
ck2 12y ago
Firefox 34 will disable SSLv3 entirely: https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/ https://blog.mozilla.org/security/2014/10/14/the-poodle-atta... 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
IgorPartola 12y ago
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?
- jvdh 12y ago
  This is exploitable now. Padding oracles have been found before, and are even homework assignments of the Coursera cryptography course. The specifics of this bug make it a little bit harder but the paper explains how to work around this. Expect this bug to be exploited in the wild since minutes after (or perhaps already before) the release.
- rythie 12y ago
  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.
  - deleted 12y ago
    [deleted]
userbinator 12y ago
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.
borski 12y ago
You can check to see if you're vulnerable using our free tool: https://www.tinfoilsecurity.com/poodle https://www.tinfoilsecurity.com/poodle
ctz 12y ago
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.
Cybershambles 12y ago
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-major-vulnerability-in-ssl-30-cve-2014-3566 https://cybershambles.com/question/97-the-sslappening-poodle...
michaelbuckbee 12y ago
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 12y ago
  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
  - michaelbuckbee 12y ago
    Hey, we're checking for SSLv3 and then CBC ciphers, so if you're not on 3 or not using ciphers you'll show as ok.
  - romanminkin 12y ago
    Here is another one vulnerable hosts checker http://poodlemap.com/ http://poodlemap.com/
laumars 12y ago
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.
olov 12y ago
Disable SSL3.0 in golang ListenAndServeTLS: https://gist.github.com/olov/eb60ab878eb73a7c5e22 https://gist.github.com/olov/eb60ab878eb73a7c5e22
omh 12y ago
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 12y ago
  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 12y ago
    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.
nutmeg 12y ago
How to disable SSL 3.0 in IIS: http://support.microsoft.com/kb/187498 http://support.microsoft.com/kb/187498
deleted 12y ago
[deleted]
justinweiss 12y ago
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.
aburan28 12y ago
This vulnerability is being downplayed and details are being kept secret until they can patch this bug because of how severe this is
davidgerard 12y ago
We are in the horrible position of supporting some straggling IE6 users. Thankfully disabling SSLv3 means they can no longer log in.

391 points by ch0wn 12y ago

Apparently independently discovered by Thomas Pornin with a few hours of work: http://chat.stackexchange.com/transcript/message/18151930#18151930 http://chat.stackexchange.com/transcript/message/18151930#18... 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.

tptacek 12y ago
Pornin did this --- to Thai Duong, no less! --- with CRIME, too. That guy is a freak of nature. I also ruefully remember how Halvar Flake did this to Dan Kaminsky's embargoed DNS vulnerability.
- cryptbe 12y ago
  When Pornin disclosed CRIME I was telling myself: "Wait a minute, I saw this name somewhere." Then I remembered that it was Pornin's article [1] that helped me understand how zlib flush modes work. I thought that was pretty funny. [1] http://www.bolet.org/~pornin/deflate-flush-en.html http://www.bolet.org/~pornin/deflate-flush-en.html
  - tptacek 12y ago
    You guys are both my heroes.
jared314 12y ago
> 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 12y ago
  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.
  - xenophonf 12y ago
    If you can dig up the citation, I'd love to read this. That's fascinating.
    - wglb 12y ago
      I was not successful, but a sibling comment to yours https://news.ycombinator.com/item?id=8458030 https://news.ycombinator.com/item?id=8458030 provides a very useful description of the phenomenon.
  - chetanahuja 12y ago
    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 12y ago
      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.
    - calinet6 12y ago
      You laugh, but this is closer to most companies "quality policy" than otherwise. True quality comes from good process and systems, nothing more, nothing less.
  - anonymfus 12y ago
    You can use overlap to estimate total number of bugs: http://en.wikipedia.org/wiki/Lincoln_index http://en.wikipedia.org/wiki/Lincoln_index http://allendowney.blogspot.com/2014/07/last-year-my-occasional-correspondent.html http://allendowney.blogspot.com/2014/07/last-year-my-occasio...
haberman 12y ago
I don't follow -- how is it an independent discovery if it was posted after complete details had already been released by Google?
- tptacek 12y ago
  Pornin's comments on SE predate the publication.
  - haberman 12y ago
    Oh my bad. What is the explanation of this part? "given sure confidence that there is a vulnerability in a particular diff, skilled security researchers can find it very quickly." Was there previously an announcement that a vulnerability existed, without details of what the vulnerability was?
    - cesarb 12y ago
      Yes, there was: https://news.ycombinator.com/item?id=8452931 https://news.ycombinator.com/item?id=8452931 That announcement implied that the vulnerability was SSL 3.0 only. Knowing that, the obvious place to look at would be the differences between SSL 3.0 and its successor TLS 1.0.
    - brians 12y ago
      There was a lot of Twitter traffic about SSL3 being bad. But TLS1 has very few differences from SSL3. In Heartbleed, we knew that it was introduced with a particular OpenSSL version. That had 12 changes; 8 were DTLS. Two were clearly not relevant. One was heartbeat. Dan Franke took about fifteen minutes to go from that set of inputs to a sketch of heartbleed. I now advocate QA by what I call "virtual tests": you don't have to write the tests, just the failure messages. Developers will do the rest of the work on their own.

tptacek 12y ago

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 12y ago
> 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 12y ago
  > 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.

jvehent 12y ago

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 12y ago
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 12y ago
  I'm assuming that a user stuck on IE6 doesn't have the necessary technical expertise to upgrade or change security parameters.
  - cesarb 12y ago
    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.)
  - zobzu 12y ago
    to be honest a user on IE6 can be compromised in a zillion other ways :/
pixl97 12y ago
As a web app developer focusing on applications in both oil and healthcare related apps for smaller businesses we disabled SSL3 early this year after XP was depreciated. The vast majority of our clients had upgraded to a newer version of Windows already, but a few stuck on XP were able to use Chrome or Firefox to access the programs. As for legacy clients, time to firewall them from the internet. They make the Internet a more dangerous place for everybody. If your device/program cannot be updated then it needs put on a vlan'd network segment. Breach after breach have shown that attackers will use any exploitable resource go gain a foothold inside your network.

pjl 12y ago

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

aastaneh 12y ago
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

mikelat 12y ago

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 12y ago
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_browsers http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_br...

justcommenting 12y ago

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 12y ago
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 12y ago
  To be honest, I remember the Slashdot article that incorrectly suggested that SSL 2.0 and TLS 1.0 was affected by BEAST.
  - justcommenting 12y ago
    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 12y ago
      And what I am talking about is why.
      - 12y ago

xt 12y ago

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.

thibaut_barrere 12y ago
For those who want to verify their change after updating the configuration (since I looked for such information): either use "nmap --script ssl-enum-ciphers -p 443 <host>" or ssllabs (eg: https://www.ssllabs.com/ssltest/analyze.html?d=wisecashhq.com&hideResults=on https://www.ssllabs.com/ssltest/analyze.html?d=wisecashhq.co...) and you will see the enabled protocols.
pixl97 12y ago
For those running IIS, use IIS Crypto by Nartac Software for a decent GUI on configuring your protocol and cipher options.
praseodym 12y ago
This works, but from TFA: "Disabling SSL 3.0 support … presents significant compatibility problems" "Therefore our recommended response is to support TLS_FALLBACK_SCSV."
- sslalready 12y ago
  Disabling SSLv3 will indeed affect a significant amount of clients in the real world. I've seen a few commenters here on HN that point out that pretty much everything since Windows XP (ignoring IE6) supports at least 1.0 of the TLS protocols. While that may be correct in theory, in practice it's not. At a 1MM+ visitors/week site we still see a few percent of our users that regularly connect using SSLv3 across different versions of Windows, including more modern ones such as Windows Vista, 7 and 8(!) Though I'm not sure why this is the case, antivirus software suites such as McAfee[1] have in the past been known to disable TLS 1.0 system wide in Windows. [1] http://answers.microsoft.com/en-us/ie/forum/ie8-windows_other/tls-10-on-internet-explorer-8-will-not-stay/3be14cfa-314c-46f6-a154-3a4eddaa5024 http://answers.microsoft.com/en-us/ie/forum/ie8-windows_othe...

rb2e 12y ago

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.

turingbook 12y ago

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

rcthompson 12y ago

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.

AbeEstrada 12y ago

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 12y ago
For any unfortunate souls using IIS, Digicert has a walkthrough of disabling SSLv3 at https://www.digicert.com/ssl-support/iis-disabling-ssl-v3.htm https://www.digicert.com/ssl-support/iis-disabling-ssl-v3.ht...
budgi3 12y ago
For IIS: Nartac IIS Crypto gives a nice GUI to manage all Protocols, Ciphers, Hashes and Key Exchanges https://www.nartac.com/Products/IISCrypto/ https://www.nartac.com/Products/IISCrypto/

cesarb 12y ago

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

xenophonf 12y ago
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 12y ago
  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.
- perlgeek 12y ago
  And if you use thunderbird for emails, remember to do there too. (Same config key).

jerf 12y ago

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 12y ago
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 12y ago
  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.
paulannesley 12y ago

cmdr_keen 12y ago

https://zmap.io/sslv3/ https://zmap.io/sslv3/ - "POODLE Attack and SSLv3 Support Measurement"

ck2 12y ago

Firefox 34 will disable SSLv3 entirely: https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/ https://blog.mozilla.org/security/2014/10/14/the-poodle-atta... 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

IgorPartola 12y ago

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?

jvdh 12y ago
This is exploitable now. Padding oracles have been found before, and are even homework assignments of the Coursera cryptography course. The specifics of this bug make it a little bit harder but the paper explains how to work around this. Expect this bug to be exploited in the wild since minutes after (or perhaps already before) the release.
rythie 12y ago
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.
- deleted 12y ago
  [deleted]

userbinator 12y ago

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.

borski 12y ago

You can check to see if you're vulnerable using our free tool: https://www.tinfoilsecurity.com/poodle https://www.tinfoilsecurity.com/poodle

ctz 12y ago

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.

Cybershambles 12y ago

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-major-vulnerability-in-ssl-30-cve-2014-3566 https://cybershambles.com/question/97-the-sslappening-poodle...

michaelbuckbee 12y ago

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 12y ago
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
- michaelbuckbee 12y ago
  Hey, we're checking for SSLv3 and then CBC ciphers, so if you're not on 3 or not using ciphers you'll show as ok.
- romanminkin 12y ago
  Here is another one vulnerable hosts checker http://poodlemap.com/ http://poodlemap.com/

laumars 12y ago

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.

olov 12y ago

Disable SSL3.0 in golang ListenAndServeTLS: https://gist.github.com/olov/eb60ab878eb73a7c5e22 https://gist.github.com/olov/eb60ab878eb73a7c5e22

omh 12y ago

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 12y ago
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 12y ago
  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.

nutmeg 12y ago

How to disable SSL 3.0 in IIS: http://support.microsoft.com/kb/187498 http://support.microsoft.com/kb/187498

deleted 12y ago

[deleted]

justinweiss 12y ago

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.

aburan28 12y ago

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

davidgerard 12y ago

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