POODLE and HTTPS

By now you will have no-doubt heard of the “POODLE” vulnerability, or “Padding Oracle On Downgraded Legacy Encryption”.  Major security standards have, in response to POODLE, advised the discontinuation of SSLv3 and additionally suggested a move to TLS 1.1 and 1.2 in order to prevent other potential avenues of attack.

What is SSLv3 and why is it used?

Whenever you view a “secure” website, such as your online banking application or credit card vendor, you may notice that the address begins with “HTTPS”.  HTTPS in this instance refers to “secured” HTTP – meaning that the identity, confidentiality, and integrity of the HTTP connection is protected by mathematical algorithms.

This protection is established via one of six protocols: SSLv1, v2, v3, TLSv1.0, v1.1, or v1.2.  SSLv1-3 were developed by Netscape, with version 2 released in 1995 and version 3 in 1996.  TLSv1.0 was released in 1999, 1.1 in 2006, and 1.2 in 2008.

Each successive protocol was designed to mitigate potential security concerns in the previous iteration, such that for many years now SSLv2 and earlier were considered insecure and disabled by default; SSLv3, while problematic, was thought to be “good enough” and was left enabled for the purpose of interoperability with old servers and clients.

However, due to a succession of severe vulnerabilities in the implementation of SSL and TLS, browser and server vendors have moved to more quickly support newer protocols such as TLSv1.1 and TLS1.2, making the need to support SSLv3 less important.

The final nail in the coffin for SSLv3 was POODLE, an attack released by Google security researchers in October 2014.

What is POODLE?

POODLE is an attack against SSLv3 which allows some amount of information to be leaked, violating the “confidentiality” of the secure connection, by repeatedly interrupting the connection from client to server in a specific way many hundreds of times.  It requires the attacker to have “man in the middle” access, in other words to be able to exist in between a client and a server.  This is possible for some advanced attackers on the internet, and also significantly less advanced attackers in places like coffee shops, hotels, conferences, and other such networks.

How does POODLE work?

POODLE actually is a two-step vulnerability: first it downgrades the connections from any version of TLS to SSLv3, and second it attacks SSLv3.  The downgrade occurs because browser vendors have attempted to maintain connectivity to even old, buggy servers, by attempting older protocols if newer ones result in a disconnect.  Because a man-in-the-middle attacker can cause a disconnect, they can cause a client and server to negotiate on SSLv3 even if TLSv1.0+ are supported.

The attack against SSLv3 works by exploiting the way in which “block ciphers” in SSLv3 encrypt the information being sent between the client and server.  Block ciphers are cryptographic algorithms that are designed to protect information, and the math behind them is generally solid – with the caveat that they can only protect information that has a length exactly equal to their “block size”.

On the web, this means that data on secure websites being encrypted with block ciphers is broken into “block size” chunks, however the data rarely fills all of the blocks neatly and there is some remainder.  This remainder is filled by “padding”, and in SSLv3, there is an unencrypted piece of information at the end of the transmission which specifies the amount of padding used.  POODLE uses this fact as part of an attack that lets a malicious party decrypt data bit-by-bit.  For a more thorough explanation of how this operation works, I recommend the article “CBC Padding Oracle Attacks Simplified – Key Concepts and Pitfalls“.

How can POODLE be mitigated?

Because it relies on SSLv3 being supported, the ability to downgrade from newer protocols to SSLv3, and on block ciphers being supported for SSLv3, there are essentially three possible solutions:

  1. Remove the ability for an attacker to forcibly downgrade the connection
    1. Option 1 is viable for servers which support something called TLS_FALLBACK_SCSV – this is a “phony” cipher suite which may be triggered by a downgrade attempt, and on triggering, if the server notices that it appears as if the connection is being downgraded, an exception is thrown to thwart the downgrade attempt.
  2. Remove support for SSLv3
    1. Option 2 is the preferred solution, as it gets to the problem at its root.  Disabling SSLv3, however, requires that all necessary clients support at least TLSv1.0 in order to continue communicating with the server.
  3. Remove support for block ciphers in SSLv3
    1. Because the only non-block-cipher available for SSLv3 is RC4 (which is a “stream cipher” that encrypts data on-the-fly and avoids needing padding), and RC4 is also very insecure, option 3 is out.

What has ESP done?

When it came to ESP’s attention in October 2014, we immediately moved to disable SSLv3 on our online banking platform and other core platforms.  Since then we’ve also worked to remove it from less sensitive services, and in addition we have enabled TLS_FALLBACK_SCSV where available.

Because our core platform does not use SSL/TLS to protect information transit, it was not affected.

What can you do?

You can scan websites or ranges of IP addresses for SSLv3 support by using these two tools:

  1. Scan a website for POODLE: https://www.poodlescan.com/
  2. Scan a website for detailed security analyses: https://www.ssllabs.com/ssltest/
  3. Scan an IP range: https://pentest-tools.com/network-vulnerability-scanning/ssl-poodle-scanner