CVE-2014-3566 POODLE:

What is SSL, TLS, and HTTPS?

SSL stands for Secure Sockets Layer and, in short, it’s the standard technology for keeping an internet connection secure and safeguarding any sensitive data that is being sent between two systems, preventing criminals from reading and modifying any information transferred, including potential personal details. The two systems can be a server and a client (for example, a shopping website and browser) or server to server (for example, an application with personally identifiable information or with payroll information).

It does this by making sure that any data transferred between users and sites, or between two systems remain impossible to read. It uses encryption algorithms to scramble data in transit, preventing hackers from reading it as it is sent over the connection. This information could be anything sensitive or personal which can include credit card numbers and other financial information, names and addresses.

TLS (Transport Layer Security) is just an updated, more secure, version of SSL. We still refer to our security certificates as SSL because it is a more commonly used term, but when you are buying SSL from Symantec you are actually buying the most up to date TLS certificates with the option of ECC, RSA or DSA encryption.

HTTPS (Hyper Text Transfer Protocol Secure) appears in the URL when a website is secured by an SSL certificate. The details of the certificate, including the issuing authority and the corporate name of the website owner, can be viewed by clicking on the lock symbol on the browser bar.

How Does SSL/TLS Work?

For SSL/TLS negotiation to take place, the system administrator must prepare the minimum of 2 files: Private Key and Certificate. When requesting from a Certificate Authority such as Symantec Trust Services, an additional file must be created. This file is called Certificate Signing Request, generated from the Private Key. The process for generating the files are dependent on the software that will be using the files for encryption. For a list of the server software Symantec has, look at Symantec CSR Generation.

Note that although certificates requested from Certificate Authorities such as Symantec are inherently trusted by most clients, additional certificates called Intermediate Certificate Authority Certificates and Certificate Authority Root Certificates may need to be installed on the server. This is again server software dependent. There is usually no need to install the Intermediate and Root CA files on the client applications or browsers.

Once the files are ready and correctly installed, just start the SSL/TLS negotiation by using the secured protocol. On browser applications, it is usually Remember to use your secured website address. Above is just a sample address.


  • Father of SSL Dr. Taher ElGamel
  • First public release as SSL v2 in 1995
  • Many initial flaws.
  • SSL v3 released in 1996 with significant improvement
  • TLS 1.0 released in 1999 with minor improvement.
  • TLS 1.1 released in 2006.

BEAST Attack

  • Browser Exploit Against SSL/TLS/
  • A vulnerability in the way cipher block chaining implemented in pre-TLS 1.1 versions.
  • Thai Duong and Juliano Rizzo discovered in 2011
  • The initialization vector (IV) used is the cipher-text of the previous block.
  • An attacker could use a chosen plaintext attack since IV is predictable.
  • The attacker will keep trying different plaintexts until he is able to decrypt.
  • BEAST has three conditions that must be met for this attack to take place: o JavaScript or applet injection into the same origin as the web site o Network sniffing of the connection must be possible o A vulnerable version of SSL must be used which is using a block cipher

The BEAST attack utilizes a flaw in TLS/1.0 that mostly seen by the security community as one that needs to be remediated within the browser rather than the server. Although there are avenues, you can take to offer a secure connection to those of your users who are more technically and security practical understanding; the take-up numbers will be low.

Heart Bleed Attack

  • Heartbleed bug is a vulnerability in open source software first discovered in 2012.
  • It is an implementation bug in the OpenSSL cryptographic library.
  • The bug got its start from improper input validation in the OpenSSL implementation of the TLS Heartbeat extension.
  • Due to the missing bounds check on the length and payload fields in Heartbeat requests, coupled with trusting the data received from other machines, the responding machine mistakenly sends back its own memory data.
  • Attackers can send Heartbeat requests with the value of the length field greater than the actual length of the payload.
  • OpenSSL processes in the machine that are responding to Heartbeat requests do not verify if the payload size is the same as what is specified in length field.
  • Thus, the machine copies extra data residing in memory after the payload into the response.

Impact of Heart Bleed Attack

  • This vulnerability allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software.
  • To make matters worse, this attack leaves no apparent evidence in the log files.
  • Thus, it is extremely difficult to determine whether the machine has been compromised.

Prevent Heart Bleed Attack

  • The problem could have been avoided by validating the message length and ignoring Heartbeat request messages asking for more data than their payload needs.
  • A security review of OpenSSL software could have also caught the Heartbleed bug.


A block cipher is a deterministic encryption algorithm. It uses a symmetric key to encrypt a block of text at a time. It is different from stream cipher, where the plain text is encrypted one bit at a time. The most famous example for block cipher is AES cipher which encrypts 128 bit blocks with a key of predetermined length: 128, 192, or 256 bits. Block ciphers are pseudorandom permutation (PRP) families that operate on the fixed size block of bits. PRPs are functions that cannot be differentiated from completely random permutations and thus, are considered reliable, until proven unreliable.


As mentioned earlier, Block ciphers work on fixed size of blocks. Padding is a way to take data that may or may not be a multiple of the block size for a cipher and extend it out so that it is. This is required for many block cipher modes as they require the data to be encrypted to be an exact multiple of the block size. PKCS7 padding is a generalization of PKCS5 padding (also known as standard padding). PKCS7 padding works by appending N bytes with the value of chr(N), where N is the number of bytes required to make the final block of data the same size as the block size. A simple example of padding is:

>>> from cryptography.hazmat.primitives import padding
>>> padder = padding.PKCS7(128).padder()
>>> padded_data = padder.update(b"11111111111111112222222222")
>>> padded_data
>>> padded_data += padder.finalize()
>>> padded_data
>>> unpadder = padding.PKCS7(128).unpadder()
>>> data = unpadder.update(padded_data)
>>> data
>>> data + unpadder.finalize()


  • Slight change in plain text should produce a significant variation in the Ciphertext
  • Most important property for block ciphers
  • This effect helps in making the cryptanalysis hard
  • The necessity for avalanche effect gave rise to procedural rules for a generic block cipher
  • A.K.A Block Cipher modes of operation
  • Examples: Electronic code book mode, Cipher block chaining mode, Cipher Feedback mode, Galois counter mode etc…
  • SSL V3.0 uses cipher block chaining mode


Cipher block chaining (CBC) is a mode of operation for a block cipher (one in which a sequence of bits are encrypted as a single unit or block with a cipher key applied to the entire block). Cipher block chaining uses what is known as an initialization vector (IV) of a certain length. One of its key characteristics is that it uses a chaining mechanism that causes the decryption of a block of ciphertext to depend on all the preceding ciphertext blocks. As a result, the entire validity of all preceding blocks is contained in the immediately previous ciphertext block. A single bit error in a ciphertext block affects the decryption of all subsequent blocks. Rearrangement of the order of the ciphertext blocks causes decryption to become corrupted. Basically, in cipher block chaining, each plaintext block is XORed (XOR) with the immediately previous ciphertext block, and then encrypted. Decryption works in the exact opposite way. It is made clearer from the picture below:

CBC Encryption CBC Decryption


An Oracle is a system that reveals information. Normally, a system that uses encryption either works or doesn’t. However, if the system reveals extra information – like if padding was valid, then this is called a Padding Oracle. While the technical term is Padding Oracle, think of it as a blabbermouth.Normally modifying the message does not provide a way to guess the contents, because it’s encrypted and I don’t know what the decrypted message is. However, if we can sent the message to the Padding Oracle, and it returns “Good Padding” or “Bad Padding” – then we can defeat the system. The value hex(01) is valid padding when we have to add a single byte pad, so if we try all 256 combinations of the last byte, and one of these returns “Valid Padding”, then we know now what the cleartext of that byte is, thanks to the blabbermouth oracle. An example of the padding oracle attack can be found at this site, it gives the complete details. In short, the padding oracle attack algorithm works as follows: We have original plain text messages m1, m2, m3 and m1’, m2’, m3’ etc are assumed messages obtained from padding oracle attack.

Step 1: Collecting data

We eavesdrop on the network and collect Initialization vector IV and Cipher texts c1, c2 and c3.

Step 2: Choose random IV‘ with to generate incorrect padding.

With help of the oracle, we can start decrypting c1 like this: Instead of the original IV we choose a random IV‘ and prepend it to the ciphertext block c1. This message is then sent to the oracle. As c1 is now the last message, the oracle has to assume that it has a padding. Remember, a message has to end with a padding. The padding has to follow a specific format (01 if the last byte is padded, 02 if the last two bytes are padded, …). There is a high chance, that the padding format of m1′ is incorrect and the server returns an error message. If the server does not return an error message, we choose a new random IV‘ and run Step 2 again.

Step 3: Modify IV‘ until padding is valid

Now that we retrieved an error message from the oracle, we start modifying the last byte of IV‘ until the oracle does no longer send an error message. As we are modifying just one byte, we only have to do this 255 times maximum.

Step 4: Learn the original plain text

It might not be obvious yet, but getting the original plain text is very simple now. It just needs that we repeat the steps until we fully retrieve the message with the help of padding oracle.

A padding oracle attack can be performed without any knowledge about the secret key. Furthermore the secret key and the encryption/decryption operation is not involved in any of the mathematical/logical operations during the attack. This means, it is completely irrelevant which block cipher (DES, 3DES, AES, …) is being used. It is also irrelevant if the key length is 128 bit, 512 bit or 4096 bit. If CBC and RFC 2040 padding is in place, the example attack works for all of them. This blog has a really cool explanation with illustrations on padding oracle attack. Please read for more information.


The poodle module contains a POODLE class which implements the logic for exploiting the POODLE vulnerability.


  • POODLE stands for Padding Oracle On Downgraded Legacy Encryption, [Padding- A block cipher works on units of a fixed size (known as a block size), but messages come in a variety of lengths.
  • So some modes (namely ECB and CBC) require that the final block is padded before encryption] this vulnerability allows a man-in-the-middle attacker to decrypt cipher-text using a padding oracle side-channel attack.
  • Many Transport Layer Socket (TLS) clients down-grade their cryptography protocol to SSL 3.0 when they work with legacy servers.
  • An attacker that controls the network between the computer and server could interfere with the ‘handshake’ process, which is used to verify which cryptography protocol the server can accept using a “protocol downgrade dance”.
  • This will force computers to use the older SSL 3.0 protocol to protect data that is being sent. Attackers can then exploit the bug by carrying out a man-in-the-middle (MITM) attack to decrypt secure HTTP cookies, which could let them steal information or take control of the victim’s online accounts.
  • All systems and applications utilizing the Secure Socket Layer (SSL) 3.0 with cipher-block chaining (CBC) mode ciphers may have a degree of vulnerability.
  • However, the POODLE attack demonstrates that this vulnerability, using web browsers and web servers, is one of the most affected. Resource


  • The POODLE attack can be used against any system or application that supports SSL 3.0 with CBC mode ciphers.
  • This not just affects most current browsers and websites, but also includes any software that either reference a vulnerable SSL/TLS library or implements the SSL/TLS protocol suite by itself.
  • By exploiting this vulnerability in a likely web-based scenario, an attacker can gain access to sensitive data passed within the encrypted web session, such as passwords, cookies and other authentication tokens that can then be used to gain more complete access to a website.
  • The POODLE attack is man-in-the-middle exploitation which takes advantage of internet and security software clients which fall back to SSL 3.0.
  • If attackers successfully exploit this vulnerability, on average, they only need to make 256 SSL 3.0 requests to reveal one byte of encrypted messages.
  • This vulnerability has the CVE ID CVE-2014-3566. POODLE affects older standards of encryption, specifically Secure Socket Layer (SSL) version 3.
  • It does not affect the newer encryption mechanism known as Transport Layer Security (TLS).
  • Although SSL 3.0 is almost 15 years old, many servers and web browsers are still use it today.
  • When web browsers fail at connecting on a newer SSL version (i.e. TLS 1.0, 1.1, or 1.2), they fall back to an SSL 3.0 connection, which is where the trouble begins.
  • Because a network attacker can cause connection failures, including the failure of TLS 1.0/1.1/1.2 connections, they can force the use of SSL 3.0 and then exploit the poodle bug in order to decrypt secure content transmitted between a server and a browser. Resource ——————————————————————————————————————————-


CVE Number [] Google Paper [] Google Blog [] HeartBleed [] BEAST Attack [] Poodle Notes [] Poodle end SSL implementation [] Transaction Risk [] Poodle working concept [] POODLE SSL Verifier [] POODLE Scan website [] Vulnerability questions [] Block Cipher [] CBC and Padding Oracle attacks [] Padding Oracle attack []