Insecure Internet of Things (IoT) devices are regularly exploited to cause a great deal of harm, for example, distributed denial-of-service attacks and privacy invasion of users. A key way to improve the security and privacy of IoT devices is to protect their network communication, which may contain sensitive user data, or expose the inner workings of a device.
On the web, network communications are almost exclusively protected via HTTPS/TLS. The protocol is designed to provide guarantees of data confidentiality, authenticity, and integrity, and its use is typically indicated through a lock icon in the browser.
Unfortunately, little is known about the degree of effectiveness with which IoT devices use TLS. What’s more worrisome is that TLS usage in other non-browser software has been found to be particularly problematic, with some experts calling it “the most dangerous code in the world”.
To fill this knowledge gap, we at Northeastern University and IMDEA Networks studied ~17M TLS IoT device connections. The following post offers a brief snapshot of what we discovered and presented at IMC 2021.
- Most consumer IoT devices rely on TLS 1.2; few have upgraded to TLS 1.3.
- Some devices downgrade their TLS connections with old versions when encountering connection failure.
- Many devices trust CAs that have been explicitly distrusted by other major platforms due to misbehaviour.
- The set of CAs trusted by an IoT device should be public knowledge, similar to how it is with other platforms, to improve transparency and security.
TLS usage is hard to get right
Transport Layer Security (TLS) is what ensures your credit card information remains safe in transit to Amazon, or that an ISP doesn’t know what video you just watched on YouTube despite the network traffic being carried by it. IoT devices also mainly rely on TLS to secure their network traffic.
But effective TLS usage is hard to get right! That’s because TLS is an old protocol, and has been continually improved over the past 25 years in response to the various flaws discovered by the security community. It now offers a plethora of versions, features, and configurations that are implemented by a number of open and closed-source libraries. Using an insecure combination of these can make TLS communication susceptible to different attacks. Moreover, the TLS protocol continues to evolve, and its proper usage thereby requires active maintenance.
Two years, ~17M TLS connections
To study TLS behaviour in IoT devices, we configured 40 TLS-supporting consumer IoT devices (Figure 2) in the Mon(IoT)r lab at Northeastern University (Figure 1). Through an IRB-approved user study, we recruited more than 30 participants to use the devices in our lab. While our study participants used these devices freely as they pleased, we recorded all network traffic through the access point in our control. From January 2018 to March 2020, we collected ~17M TLS connections.
In addition to these uncontrolled experiments, we often needed to actively intercept TLS connections these devices made, to study their various properties. To do so, we used smart TP-link power plugs to programmatically power these devices on and off. Our key insight was that the majority of these devices generate TLS traffic within a few minutes of being rebooted. Using these passive and active approaches, we were able to shed light on various aspects of TLS usage.
Supporting older versions of TLS, lack of maintenance weaken the security of devices
During TLS connection establishment, the protocol version and cipher suites (that is, cryptographic algorithms) used for the connection are negotiated by the client (for example, an IoT device) and server. TLS connections using protocol versions less than 1.2 or (DES, 3DES, RC4, EXPORT) cipher suites are considered insecure.
The good news is that we found 32/40 devices to rely on TLS 1.2, and only two devices to ever establish connections using insecure cipher suites. However, we also found that devices rarely upgraded to the latest protocol version TLS 1.3, or state-of-the-art cipher suites that offer forward secrecy, such as (DH/ECHDE).
Passively monitoring network traffic only conveys information about the TLS features negotiated between the client and server by default. But to further investigate all the versions that a client may support, we used our active experimentation methodology where we intercepted TLS connections from devices and pretended to be servers negotiating weaker TLS versions. Interestingly, such experiments revealed 19 devices that still supported TLS 1.1 or 1.0.
We also found seven devices that would downgrade their TLS connections with old versions or cipher suites upon encountering connection failure. The most likely explanation is that these devices were trying to maximize compatibility with older servers, but this behaviour can be exploited by attackers.
Overall, our results regarding connection security show that although most device manufacturers rightly configure their devices to use TLS 1.2, the support for older protocol features and lack of maintenance can still weaken their device security.
IoT devices do not properly maintain their set of trusted CAs over time
TLS clients typically authenticate servers through trusted third-party Certificate Authorities (CAs), such as Let’s Encrypt or Digicert. These CAs vouch for the authenticity of servers by issuing certificates that bind cryptographic material to server identities.
A malicious or compromised CA can wreak havoc on the TLS security properties, as was observed in 2011 when a rogue certificate from the CA DigiNotar was used to intercept Gmail traffic of an estimated 300,000 Iranian users. For this reason, web browsers and operating systems maintain strict policies regarding their trust decisions and regularly update the set of CAs they trust. In fact, in the DigiNotar incident, all major vendors revoked trust in the CA by issuing software updates, rendering the company bankrupt soon afterwards.
Prior research has explored the CAs trusted in open platforms, but unfortunately, the validity of CAs trusted by the IoT ecosystem has been long ignored. Part of the reason why is that IoT devices are black boxes, and firmware analysis for inspection of trusted CAs is neither easy nor scalable to a large number of devices from different manufacturers.
In our work, we used a novel black-box methodology to infer CA root stores of some devices from our lab (Figure 3). The technique exploits a side-channel based on TLS alert messages.
Our key insight is that we can intercept TLS connections to present arbitrary certificates that will always fail — but may trigger different behaviours in TLS clients depending on the set of CAs they trust. We further showed that the difference in behaviour can be reliably used to infer whether a given CA is trusted by an IoT device or not. We refer readers to our paper for complete details.
Although our technique worked only for 8/24 devices we could test, to our surprise, all eight devices trusted at least one CA that has been explicitly distrusted by other major platforms due to misbehaviour. In addition, we also found devices to be trusting CAs that have long been removed from the sets of trusted CAs in other platforms. The most likely explanation of our findings is that IoT devices do not properly maintain their set of trusted CAs over time. In our opinion, CAs trusted by IoT devices form the weakest link in TLS security in the IoT ecosystem.
CAs trusted by an IoT device should be public knowledge
We did not find that TLS usage in IoT devices is completely broken. Rather, we observed a mix of good and bad usage practices, some of which have occurred in the past in other platforms such as mobile browsers and operating systems.
We hope work like ours can help the community further its understanding of how TLS gets deployed in the real world, and IoT manufacturers improve device security.
In addition, we propose that the set of CAs trusted by an IoT device should be public knowledge, similar to how it is with other platforms. We believe such transparency can help dissuade attackers from supply-chain attacks involving CAs and can help researchers audit such incidents if they do happen.
Talha Paracha is a Computer Science PhD student at Northeastern University.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.