By now you have likely heard a lot about a vulnerability in the SSL protocol called POODLE, whether it be from another vendor, news outlet, blog, or other medium. While you're hearing about all of the issues that it could cause, no one is explaining how it could affect you and what steps you and your business should take.
What is it?
POODLE, or Padding Oracle on Downgraded Legacy Encryption (great name, right?), is a discovered vulnerability in version 3.0 of the SSL protocol launched in 1996.
Server/client connections that negotiate security using the SSLv3 protocol are susceptible to the attack after several hundred HTTPS requests are made. If successful, information between the client and server could be decrypted and used maliciously.
Is it really a big deal?
Truthfully? Not really. Here's why:
As mentioned earlier, SSLv3 was launched in 1996 and has since been replaced by two versions of an enhanced version of SSL called TLS (IT people get bored with acronyms, so we like to change names from time to time).
When a secure connection is initiated, the highest compatible SSL version between the clients is selected automatically. Unless you are using an old browser (Internet Explorer 6, for instance, is the last version of IE that does not support TLS) or the server you are connecting to is very old and does not support either TLS protocol, you will likely not be affected.
What do you mean by likely?
As we mentioned earlier, SSL security is based on the negotiated highest capability of the server and the client. The largest fear is that malicious software at either end (server or client) could prevent, hide or disable the TLS protocols or their visibility, forcing negotiation to begin "falling back" to SSLv3, a process that occurs by design for compatibility.
If this occurs, TLS could be skipped and SSLv3 used for the connection instead, thus creating further opportunity for the vulnerability to be exploited.
What should I do?
The exposure/risk is extraordinarily low as indicated by Microsoft and several other security firms. While there is legitimate worry to any vulnerability, especially as it pertains to encryption, we believe that you do not necessarily have to actively do anything with regards to this exploit. What you will likely see occur is larger organizations and providers disable SSLv3 from their ends, which prevents it as a negotiable option to the client, thus circumventing the vulnerability (remember, a security protocol has to be agreed upon by both sides). We also expect patches for the major browsers that will disable SSLv3 or at least monitor for potential abuse of the exploit to begin surfacing over the coming weeks.
If your organization provides a web-based application or service to end users, you may want to follow suit by disabling SSLv3 on your servers.
If you are still concerned about your client security, there are actions that can be taken to disable SSLv3 at the client side. Please contact us as soon as possible so that we can schedule implementation and advisement on how to proceed.