January 2nd, 2020

What Level of SSL or TLS is Required for HIPAA Compliance?

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 ciphers used directly impact the level of 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 saw that SSL v3 was very weak and should not be used going forward by anyone (see the POODLE attacks, for example); TLS v1.0 or higher must be used.

Among the many configuration nuances of TLS, the protocol versions supported (e.g., 1.0, 1.1, 1.2, and 1.3) anfd which “ciphers” are permitted have the greatest impact on security.  A “cipher” specifies encryption algorithm to be used,  the secure hashing (message fingerprinting / authentication) algorithm to be used, and other related things such as how encryption keys are negotiated.   Some ciphers that have long been used, such as RC4, have become weak over time and should never be used in secure environments.  Other ciphers provide protection against people who record a secure conversation from being able to decrypt it in the future if somehow the server’s private keys are compromised (perfect forward secrecy).

What level of TLS is required by HIPAA?

Given the many choices of ciphers and TLS protocol versions, people are often at a loss as to what is specifically needed for HIPAA compliance for an appropriate and compliant level TLS security.  Simply “turning on TLS” without also configuring it appropriately is likely to leave your transmission encryption non-complaint.

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.

The FIPS specifications refer back to NIST 800-52 to define what cipher suites and settings are “FIPS approved.”  In other words, TLS usage must comply with the details set out in NIST 800-52 rev 2.   This implies that other encryption processes, especially those weaker than recommended by this publication, are not valid and are thus non-compliant.

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 rev 2 Say?

NIST 800-52 (revision 2 from August, 2019) is a long and detailed document that covers what is needed for strong TLS for government use.  It also succeeds all previous recommendations should be considered the current best practice recommendations.   In addition to many small nuances, the biggest things to get out of this document are:

  1. SSL v2 and v3 must never be used,
  2. TLS v1.0+ is OK to be used when interoperability with non-government systems is required, and
  3. Only ciphers in a specific, recommended list are OK to use.
  4. TLS 1.3 should be supported by your services by 2024.

TLS v1.0?  Really?

The NIST guidelines really do indicate that TLS v1.0 is valid for use when necessary for communication with non-governmental systems.  This is a bit of a surprise as PCI has required use of TLS 1.1+ (no TLS 1.0 or below) since June 30th, 2018.  Most modern web browsers are dropping support for TLS v1.0 and all modern operating systems support TLS 1.2.  Reading a little further into NIST 800-52, we see

TLS version 1.1 is required, at a minimum, in order to mitigate various attacks on version 1.0 of the TLS protocol. Support for TLS version 1.2 is strongly recommended.

So, it seems that HIPAA does technically permit TLS v1.0; however, the recommendations and best practices of the industry indicate that TLS v1.1+ should be used.  And in truth, 99% of systems supporting TLS v1.1 actually support TLS v1.2 as well.  So, making TLS 1.2 your “minimum protocol level” is the solid choice and an industry best practice.  Allow TLS v1.0 only when you MUST.

What Ciphers Should We Use?

The NIST document lists out all ciphers that are recommended.  When using TLS v1.2+, we would recommend not including the “CBC” based ciphers in the list as CBC ciphers have had many weaknesses recently and it would not be surprising if (a) your SSL stack or configuration might still be susceptible to one of them, or (b) a new CBC weakness could come out at any time.  There are plenty of good TLS v1.2+ ciphers  ciphers that do not use CBC at all.  Use those if possible.

For folks using RSA-based TLS certificates (most people) the NIST 80052r2 cipher list (One version with CBC ciphers excluded; list converted into a colon-delimited list of cipher names used by openssl, apache, and many other programs) includes:

Recommended Ciphers for HIPAA and TLS v1.2+

TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:TLS13-AES-128-CCM-8-SHA256:TLS13-AES-128-CCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-CCM:DHE-RSA-AES128-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-AES128-CCM8:DH-RSA-AES256-GCM-SHA384:DH-RSA-AES128-GCM-SHA256:ECDH-RSA-AES256-GCM-SHA384:ECDH-RSA-AES128-GCM-SHA256

Recommended Ciphers for HIPAA and TLS v1.2+ with CBC

TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:TLS13-AES-128-CCM-8-SHA256:TLS13-AES-128-CCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-CCM:DHE-RSA-AES128-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-AES128-CCM8:DH-RSA-AES256-GCM-SHA384:DH-RSA-AES128-GCM-SHA256:ECDH-RSA-AES256-GCM-SHA384:ECDH-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DH-RSA-AES256-SHA256:DH-RSA-AES128-SHA256

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 for 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).

If you have cases where you do need to support TLS 1.0+, you can add in those RSA-based ciphers from the NIST guidelines (these added ciphers use cipher block chaining (CBC) and SHA1, as that is what is available in TLS 1.0):

Recommended Ciphers for HIPAA and TLS v1.0+

TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:TLS13-AES-128-CCM-8-SHA256:TLS13-AES-128-CCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-CCM:DHE-RSA-AES128-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-AES128-CCM8:DH-RSA-AES256-GCM-SHA384:DH-RSA-AES128-GCM-SHA256:ECDH-RSA-AES256-GCM-SHA384:ECDH-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DH-RSA-AES256-SHA256:DH-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:DH-RSA-AES256-SHA:DH-RSA-AES128-SHA:ECDH-RSA-AES256-SHA:ECDH-RSA-AES128-SHA

 

What Does LuxSci Do?

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

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

  1. Only allowing TLS v1.2+
  2. Only allowing connections using the above recommended cipher list for HIPAA compliance (800-52 r2 no CBC).
  3. One exception: We permit TLS v1.0 to be used for inbound email connections from email servers around the world and for outbound email connections to email servers that do not support TLS 1.2 yet.  Email servers are generally poorly configured and are often lagging in proper support for modern standards.  The idea here is that some encryption (still under the NIST guidelines) is better than none.  Of course, when sending email in compliance contexts, we ensure that TLS 1.0 is not used.

LuxSci also allows HIPAA-compliant customers to choose to have secure email messages delivered to recipients using “TLS Only” secured connections to recipient servers that support TLS for SMTP.  For many customers, the ease-of-use of TLS for secure email delivery is a great solution, when available.  LuxSci’s systems dynamically check all of the recipient’s inbound email servers to ensure that all of them support a sufficient level of TLS (in this case, TLS 1.2+ with any NIST-recommended ciphers).  Only then will LuxSci permit TLS-Only email delivery.

We do observe some email servers on the internet do not support TLS at all and some support only SSL v3 or TLS v1.0 or very weak/old 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 upgrade their software configurations. Until then, LuxSci automatically upgrades secure messages to them to the use of SecureLine Escrow (portal pickup) or PGP or S/MIME to ensure compliant communications.

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

 

* See LuxSci’s TLS 1.2+ upgrade maintenance window.

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.

LUXSCI