ARTICLE: TLS, SSL and the POODLE vulnerability – implications for Healthcare and other web sites

Get in touch with us
29 October 2014

POODLEOCTOBER 29, 2014 – A vulnerability in SSL 3.0 was announced recently (October 2014), called by the name POODLE (Padding Oracle On Downgraded Legacy Encryption) (see the Security Advisory here). Vulnerabilities are announced and patched regularly, but there are important security implications, particularly for healthcare websites that should be considered.

First, understand that SSL 3.0 is now old (as the first page of the afore mentioned white paper says, it is an “obsolete and insecure protocol”). For whatever reason, the newer version of this security layer was renamed from SSL (Secure Sockets Layer) to TLS (Transport Layer Security). TLS 1.0 took its foundation from SSL 3.0 but it not compatible with SSL. TLS is now up to version 1.2, which plugs some significant security holes in SSL3.0, TLS 1.0 and TLS 1.1. A good summary article on the differences between SSL and TLS can be found here.

The so-called “POODLE” vulnerability exists in SSL 3.0. There are patches for it for all web engines that can be found easily via search.

This is all technical and uninteresting for some except for a couple of points:

  1. There are some links I’ve found that say the US Government is requiring sites to turn off SSL and only support TLS for Government sensitive and HIPAA Compliant transactions. I’ve found a long laborious NIST document ( which the HIPAA sites point to. The NIST document recommends using the highest version of TLS possible. I still cannot find a CMS or<> document that explicitly says this, but they all do point to this NIST document.
  2. SSL 3.0 un-patched and previous versions of SSL have big security holes in them that people have learned to exploit. Whether HIPAA requires/recommends this or not, it is more than worthwhile for a healthcare company or any other company that handles sensitive information for its partners, customers or employees to explore other solutions.


  • Turn off server side SSL support. This is the course of action recommended in the NIST article and elsewhere. For some systems, this is as simple as a couple of lines of configuration parameter changes. There are many places for instructions on how to make these changes on all manner of systems.
  • Before turning off SSL in production, test your applications. Modern browsers are set up to handle TLS vs. SSL, but applications, especially mobile applications, need to be tested to see if they rely on SSL or not.
  • Put in browser detection scripts for those poor souls still on older browsers. There are still several IE6/IE7 on Win XP users out there, and these browsers to not support TLS; however, the security ramifications of continuing to support them outweigh the option of displaying a message telling them that they should upgrade to a more secure browser.
  • TEST! The site we use to test is SSLLABS.COM. It provides a grading system for this and other vulnerabilities. And be sure to test alternate sites (for instance, if your primary domain is but you have for customers and for partners, submit all of the domains separately. Please not that there is a checkbox underneath the field where you submit the domain to test that says “do not list results publicly”; we suggest you check this.

An image of the results from our demo site is below. Note that its “letter grade” will be an A+ soon, as we are testing the impacts of additional changes on our applications before implementing.

SSL Labs

Leave a Reply

Your email address will not be published. Required fields are marked *