While studying for my Master's, I took on a project to actually build and run the POODLE attack myself, rather than just reading about how it worked. POODLE (Padding Oracle On Downgraded Legacy Encryption) is a well-known flaw in SSLv3, an old encryption protocol that some systems still fall back to even today. I wanted to see, hands-on, how an attacker could decrypt supposedly secure data without ever touching the encryption key.
I set up two virtual machines: an Ubuntu server running a deliberately outdated Apache and OpenSSL build with SSLv3 enabled, and a Kali Linux machine acting as the attacker. Modern software refuses to support SSLv3 by default, so getting the server into a vulnerable state on purpose meant compiling older versions from source rather than just installing them.
The idea behind POODLE is that a server can be tricked into revealing, one byte at a time, whether an encrypted block's padding is valid — and that alone is enough to work out the original message without decrypting anything directly. I wrote a script that took the captured ciphertext, modified its last byte, sent it back to the server, and worked through each possible value while watching how the server responded. A response with no error meant the padding was valid for that guess.
Running it against my own server, the script found a valid padding value and confirmed the attack works exactly the way the theory describes: no private key needed, just patience and a server willing to answer padding questions it shouldn't.
The fix for this is straightforward: turn SSLv3 off completely and only allow TLS 1.2 or newer. Enabling TLS_FALLBACK_SCSV also stops an attacker from forcing a secure connection to downgrade to SSLv3 in the first place, which is the trick that makes the attack possible against a real target. All of this was run entirely offline, on a virtual machine I controlled — nothing live or production was ever touched.