Understanding and Fixing the POODLE SSL Vulnerability (CVE­2014­3566)

Nov 3, 2014 3:56:15 AM | by Tom Thomas

Introduction

By far one of the most common protocols on the internet after HTTP is SSL. The Secure Sockets Layer (SSL) is the protocol that is used to encrypt connections between the web browser and the web server. What we refer to as SSL is essentially a suite of protocols collectively known as SSL/TLS.

SSL was developed at Netscape in the mid 90s when the internet was still in its infancy. Several glaring flaws were quickly identified in it and a replacement protocol was developed called Transport Layer Security (TLS). TLS was built as an upgrade to the version 3 of SSL. But despite this, TLS was not interoperable with SSL.

The Vulnerability

SSLv3 despite having flaws was considered to be secure enough when used with proper configuration; until now. Researchers at Google have demonstrated a way to exploit SSLv3 and reveal sensitive information with relative ease. This exploit is called POODLE, i.e. Padding Oracle On Downgraded Legacy Encryption.

POODLE essentially builds on a known weakness in SSL; it authenticates the message before encrypting it. The predominant algorithm for encryption in SSL is the AES cipher used in the CBC mode. This mode requires that the content being encrypted be a multiple of a certain size called block (usually, 128 or 256 bits). The encrypted content of one block is used as one of the input of the subsequent block. If an input block is smaller than the required size, it is padded with random values to fix the requirements, and the last value indicates the length of the padding.

The Exploit

An attacker, who obtains an encrypted message, can decipher the contents of the message using the following technique. A suitable message is chosen such that the padding would be full (usually 15), and this will be un-encrypted value of last byte of the padding. Next, the block containing the sensitive date (i.e. a cookie) is duplicated instead of the padding block. Now, since the attacker knows the value of the last byte (15), he makes a maximum of 256 requests to the server with all combinations. For all but one request, the authentication will fail and the connection will be terminated. By identifying the request that is accepted and the value that was sent, the unencrypted value of the information can be identified. An attacker usually needs to make 256 x n requests to decrypt n bytes of information.

Who are affected

This issue does not affect TLS, in which, rather than random values, the contents of the padding is pre-defined. This combined with the fact that more than 99% of the computers support and use TLS v1.1+ by default should make this issue seem trivial.

But unfortunately, all computers include support for SSLv3, despite not being used, and all versions of TLS support downgrading a connection to lower version in response to connection errors. This allows an attacker to force a connection to use SSLv3, even if both the client and the server support TLS.

Fixing the Vulnerability

Unlike most other exploits plaguing the SSL vulnerability like Heartbleed, POODLE exploits a weakness in the underlying protocol itself. It is not possible to fix this issue through a software update. Therefore, the only feasible solution would be to disable SSLv3, both on the client and the server side.

The only browser that does not support TLS is Internet Explorer v6. Further, with Windows XP reaching End-of-Life, it is not possible to update it. Hence, for servers still wishing to support users with IE6, the TLS_SCSV upgrade should be enabled on the server and enforced vigorously. This specification is actively supported on all current releases of SSL libraries including OpenSSL and Windows CAPI.

Instructions on how to disable SSL can be found for various browsers (https://zmap.io/sslv3/browsers.html) and servers (https://zmap.io/sslv3/servers.html).

A more technical whitepaper on this vulnerability can be found on OpenSSL’s site: https://www.openssl.org/~bodo/ssl-poodle.pdf