What Level of SSL or TLS is Required by HIPAA?

Published: January 13th, 2015

SSL and TLS are not actually monolithic encryption entities that you either use or do not use to connect securely to email servers, web sites, and other systems.  SSL and TLS are evolving protocols which have many nuances to how they may be configured.  The “version” of the protocol you are using and the nuances of the configuration directly affect the security achievable through your connections.

Some people use the terms SSL and TLS interchangeably, but TLS (version 1.0 and beyond) is actually the successor of SSL (version 3.0). … see SSL versus TLS – what is the difference?  In 2014 we have seen that SSL v3 is very weak and should not be used going forward by anyone (see the POODLE attacks, for example), TLS v1.0 or higher should be used.

Among the many configuration nuances of SSL and TLS, which “ciphers” are permitted have the greatest impact on security.  A “cipher” defines the specific encryption algorithm to be used,  the secure hashing (message fingerprinting / authentication) algorithm to be used, and other related things.   Some ciphers that have long been used, such as RC4, have become weak over time and should not be used in secure environments.

Given these nuances, people are often at a loss as to what is specifically needed for HIPAA compliance or any kind of effective level TLS security.

What HIPAA Says about TLS and SSL:

Health and Human Services has published guidance for the use of TLS for securing health information in transit.  In particular, they say:

Electronic PHI has been encrypted as specified in the HIPAA Security Rule by “the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key” (45 CFR 164.304 definition of encryption) and such confidential process or key that might enable decryption has not been breached.  To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt.  The encryption processes identified below have been tested by the National Institute of Standards and Technology (NIST) and judged to meet this standard. 

They go on to specifically state what valid encryption processes for HIPAA compliance are:

Valid encryption processes for data in motion are those which comply, as appropriate, with NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; 800-77, Guide to IPsec VPNs; or 800-113, Guide to SSL VPNs, or others which are Federal Information Processing Standards (FIPS) 140-2 validated.

In other words, SSL and TLS usage must comply with the details set out in NIST 800-52.  This implies that other encryption processes, especially those weaker than recommended by this publication, are not valid.

If you are using a level of encryption weaker than recommended, it is not valid, and thus for all intents and purposes your transmitted ePHI is unsecured and in violation (breach) of HIPAA.

So, What does NIST 800-52 Say?

NIST 800-52 is a long and detailed document that covers what is needed for strong TLS for government use.  In addition to many small nuances, the biggest things to get out of this document are:

  1. SSL v3 must not be used
  2. TLS v1.0+ is OK to be used
  3. Only ciphers in a specific, recommended list are OK to use

The list of technically allowed ciphers (converted into the names used by openssl) are:

However, there are serious considerations around the use of “CBC” ciphers as documented in NIST 800-52, in this article, especially if they are used with the TLS v1.0 protocol.  As a result, it is best to remove CBC ciphers from the supported list (this has little negative impact, aside from not supporting the native Windows XP encryption stack which, of the list above, only supports DES-CBC3-SHA. That said, Windows XP is long deprecated).  So, your “good cipher” list is now:


So, in order to achieve HIPAA compliance, you must start by
  1. Turning OFF SSL v2 and SSL v3
  2. Enabling TLS 1.0 and higher
  3. Restrict the ciphers you will be using to ONLY those in the CBC-free above list.

One thing that is interesting to note is that there are many ciphers included in this list that are not 256-bit.  E.g. 128bit AES is allowed for HIPAA and high-security government use.  We often hear people stating that 256-bit encryption is a requirement of HIPAA … it is not (that answer is “too simple” — it comes down to which specific algorithms are used, for example).

What Does LuxSci Do?

LuxSci’s services use TLS for secure web site, MySQL, POP, IMAP, and SMTP connections.

LuxSci enables you to use TLS in a HIPAA compliant way by:

  1. Only allowing TLS v1.0+ (no SSL v3)
  2. Only allowing connections using a subset of ciphers in the above recommended list

Furthermore, LuxSci allows HIPAA-compliant customers to have email delivered to recipients using “TLS Only” secured connections to recipients servers that support TLS for SMTP.  For many customers, the easy-of-use of TLS for secure email delivery is a great solution when available.  LuxSci’s systems auto-check all of the recipient’s inbound email servers to ensure that all of them support TLS v1.0+ and at least of the recommended ciphers …. only in this case do we permit use of “TLS Only”.  E.g. only in this case can we deliver messages to them in a compliant manner.

We do observe some (a small subset) email servers on the Internet that only support SSL v3 or which only support old, weak ciphers.  We do not allow our HIPAA customers to communicate with them using only TLS (SSL), as that would place them out of compliance.   We recommend that these servers either upgrade their software configurations or that something like SecureLine Escrow is used to ensure compliant communications with them.

Use our TLS Checker Tool to see if a domain supports SMTP TLS and if its support is “good enough” for HIPAA-compliant email delivery.

Check a domain’s SMTP TLS capability.

Leave a Comment

You must be connected or logged in to post a comment. This is to reduce spam comments.

If you have not previously commented, you can connect using existing social media account, or register with a new username and password.