What Level of SSL or TLS is Required for HIPAA Compliance?
SSL and TLS are not monolithic encryption entities that you use or do not use to securely connect to email servers, websites, and other systems. SSL and TLS are evolving protocols with many nuances to how they may be configured. The “version” of the protocol 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 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; 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) and which “ciphers” are permitted significantly impact security. A “cipher” specifies the encryption algorithm, 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 weakened over time and should never be used in secure environments. Other ciphers protect 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).
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. Simply “turning on TLS” without configuring it appropriately is likely to leave your transmission encryption non-compliant.
What HIPAA Says about TLS and SSL
The Department of Health and Human Services has published guidance for TLS to secure 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 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 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, transmitted ePHI is unsecured and violates HIPAA.
So, What does NIST 800-52 rev 2 Say?
NIST 800-52 (revision two from August 2019) is a long and detailed document covering 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 most significant things to get out of this document are:
- SSL v2 and v3 must never be used,
- TLS v1.0+ is OK to be used when interoperability with non-government systems is required, and
- Only ciphers in a specific, recommended list are OK to use.
- TLS 1.3 should be supported by your services by 2024.
TLS v1.0? Really?
The NIST guidelines do indicate that TLS v1.0 is valid for use when necessary for communication with non-governmental systems. This is surprising as PCI has required the 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 support TLS v1.2 as well. So, making TLS 1.2 the “minimum protocol level” is a 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 recommend not including the “CBC” based ciphers in the list as CBC ciphers have had many weaknesses recently. 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. Plenty of good TLS v1.2+ ciphers 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 interesting 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).
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 websites, POP, IMAP, and SMTP connections.
LuxSci currently enables you to use TLS in a HIPAA-compliant way by:*
- Only allowing TLS v1.2+
- Only allowing connections using the above-recommended cipher list for HIPAA compliance (800-52 r2 no CBC).
- One exception: We permit TLS v1.0 to be used for inbound email connections from email servers worldwide and for outbound email connections to email servers that do not support TLS 1.2 yet. Email servers are generally poorly configured and often lag 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 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. Our HIPAA customers are not permitted 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 using 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.
* See LuxSci’s TLS 1.2+ upgrade maintenance window.
