1

Are non-browser applications which do not contain an embedded browser, and merely make REST API calls over HTTPS, vulnerable to POODLE?

And if not, is it unnecessary to disable SSL in such applications?

4

Poodle is, as presented, a chosen-plaintext attack, although not by a large amount.

At its core, the vulnerability that Poodle builds upon allows an active attacker to try to guess a single byte of cleartext data. The conditions are the following:

  • The stream uses SSL 3.0 with encryption done with a block cipher in CBC mode.
  • The byte value that the attacker is interested in is part of the stream, and occurs at the end of a block (blocks have length 8 bytes with 3DES or RC2, 16 bytes with AES).
  • A subsequent record in the stream (in the same direction) has a length that implies a full-block padding.
  • The guess has probability 1/256 to work. On failure, the SSL stream is broken, and both client and server know it.

So, in practice, the situation must be such that the attacker can trigger SSL connections silently, and arrange things so that an "interesting secret" is sent through the connection at a predictable place, and the attacker must also be able to alter the sent data size so that each "interesting byte" occurs at the end of a block, and a record with full-block padding also occurs. It is worth noting that the attacker must choose the length of some message elements, but needs not control the contents (this is why it is a CPA only honoris causa). Moreover, each broken connection must not trigger too visible alerts.

A Web browser running hostile Javascript and connected to the Internet through an attacker-controlled WiFi access points fulfils all these conditions. Chances are that your non-browser application does not.

Nevertheless, you should really use TLS 1.0 (or, better yet, TLS 1.1 or 1.2). Now the bright side is that the SSL/TLS handshake is protected against protocol downgrade attacks: if client and server follow the standards, then attackers cannot force a client and server that both know TLS 1.0 to fallback to SSL 3.0. Web browsers have unfortunately got into the unsavoury habit of working around the standards precisely to use SSL 3.0 in case of failure with TLS 1.0. In that respect, browsers are weak to Poodle because they insist on being weak; they favour continuous support of a handful of antique servers that have not been updated since last century, over simply preventing the user from getting hacked up beyond all recognition.

The real problem, though, is that client and server still accept to use SSL 3.0 even though they both know that it is weak. More on that subject here. Disabling SSL 3.0 support and concentrating on TLS 1.0 (that you already use in practice) is not something that you should do because of Poodle; it is something that you should do because it is high time to transition from stone tools to metal. Embrace Bronze Age before it is too late !

1

POODLE is the last nail in SSLv3's coffin. This issue is a design flaw and not an implementation bug, like Heartbleed was. As it's a design flaw ánd it's basically a dead protocol, it will never be "fixed". Moving to TLS is your only option to not be vulnerable to POODLE.

So yes, your non-browser application is also vulnerable to POODLE. However, an attacker must be in the same network as your application or client to perform the required MiTM attack and must be able to trigger many requests from the client to the server to be able to actually exploit the POODLE vulnerability. Depending on the exact situation that may or may not make exploitation very unlikely.

With that said, it's time to move on from SSLv3: plan for disabling it and moving to TLSv1.2.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.