Heartbleed is a high profile flaw and attack on the OpenTLS implementation. This analyzes how well IHE ATNA rules mitigated the flaw, what should change, and contemplates future sensitivities. The flaw permitted exposure of in memory contents of client and server to a malicious counterparty on an established connection. The exposure could then potentially expose current, past, and perhaps future encrypted traffic.
The following analysis applies only to systems that use or used the vulnerable versions of software. Systems that used different software, or non-vulnerable versions, will not be directly affected by this bug.
The assets that ATNA needs to protect are:
- The encrypted traffic
- This could be past, present and future traffic. Most especially, this is the documents being exchanged.
- Private Authentication data
- This could be private certificates, passwords, etc.
ATNA requires the use of bi-directional authentication. So ATNA connections are exposed to this attack when one or both sides of a connection are malicious. The organization need not be malicious, but the secure node must have been penetrated and made malicious.
Other, non-ATNA, connections to the same server also expose ATNA connections to this attack. ATNA requires "appropriate" security measures for secure nodes and for secure applications. This is open to interpretation by those deploying systems. If the same secure node was used for both ATNA connections and non-ATNA connections, then those other connections may have exposed private data.
Most public servers use only server-authentication. They do not authenticate the client. They will accept connections from any client. It is near certainty that a public server will be penetrated by heartbleed given the number of potential malicious clients.
A server that requires bi-directional authentication for all connections has a lower probability of penetration. It drops to the probability that one of the known systems is penetrated and malicious. ATNA assumes that validation of acceptability for authentication is based on a review of security practices, so these systems are better protected than the typical system.
This makes the odds of penetration by heartbleed lower. For a system with only a few well protected partners, it is quite low. For a system supporting a large number of parters, it is higher, but probably still much lower than a public server.
Significant risk factors external to ATNA are:
- Was the system used exclusively for bi-directionally authenticated transactions? Even one open public https port could expose the system to attack. ATNA services on a shared server were probably exposed. (Details of memory access are very implementation dependent, so exposure is hard to predict.)
- Are other connections protected by other means from general public access? VPNs and VLANs are common alternative protections.
- Was traffic recordable for later attack? This is highly dependent upon implementation details. It changes the scope of the assets at risk in the event that the system was penetrated.
Some responses are obvious:
- Update to remove the bug. (Don’t waste time reading this. Do that now.) Get patches distributed and installed.
- Consider replacing passwords, revoking and replacing certificates. The urgency of this is very much dependent upon the number and type of potential communication partners. A system with public access was almost certainly penetrated and information that was available in memory is very much at risk. A system with just a few known well protected partners is at much lower risk.
- Consider negotiating Forward Security. This was always permitted by ATNA as part of TLS negotiation, but support is not required. Some systems were doing this already, because most of the libraries that support ATNA also support Forward Security. If offered and supported, it would be used. Forward Security did not protect against this bug. It just reduces the amount of past and future network traffic that was exposed.
- Consider partitioning systems so that public facing systems are fully separated (at the hardware level) from internal facing systems. In this context, public facing means systems that accept connections from any client. Many organizations use VPNs, TLS, SSH, etc. with configurations that require bi-directional authentication at all times. That is not public facing. Those systems deny network connections to unknown clients. (This authentication must be at the connection level, not as a later password or token interaction.)
Internal facing does not ensure safety. Depending upon the nature of your internal systems the risk of internal malicious systems ranges from low to high. There are many ways that malicious software gets into internal systems. The difference between internal and public facing is probability. It is certain that public facing systems are subject to constant attack from thousands of systems using a wide variety of methods. Internal facing systems are subject to attack from a much smaller number of systems using a smaller variety of methods.
Some thoughts on IHE response:
- Perhaps IHE should explicitly call out the permissibility of Forward Security. I suspect that many readers don’t realize that it is available as an option, since it is not listed. ATNA only lists the minimum necessary, not all the possible options.
- Perhaps make some stronger statement, such as identifying Forward Security as an IHE option. This doesn’t protect against penetration, but it does reduce the exposure from a penetration.
Some thoughts on public security perceptions:
- Five years ago it was hard to get the public interested in TLS protection, and tools like "HTTPS Everywhere" were limited to the techno-geeks. Now, a widespread flaw in TLS is major news. That’s quite a change for five years.
I expect some changes to authentication technologies:
- New approaches that incorporate bi-drectional authentication in ordinary consumer transactions will spread. Right now they are very rare and often poorly implemented. Banks are starting to use them. But corporate VPNs are pushing the technology and education into the general public. The affect of Heartbleed would have been somewhat smaller if these were in use. Instead of having a certainty of penetration for all public facing servers, it would be the likelihood that one of the server’s customer/client systems had been penetrated. It would still be a major penetration, but that is a smaller risk.
- One time password and related ID systems will spread. I rather like the Yubikey system. There are various others like it with different hardware and software requirements. They vary quite a bit at the moment, ranging from expensive smartcard ID systems like that used in some US government systems, to very simple systems like the Yubikey.
- I expect bio-metric IDs to flower and die for public authentication. The problem is that bio-metric IDs can be stolen. (I’ve done device drivers for fingerprint scanners. I know how to steal and copy a fingerprint. It’s harder than stealing and copying a certificate, but it can be done. Unlike a certificate, you can’t revoke a fingerprint.)