Mutual TLS (mTLS) for IoT was one of the most requested features from our IoT customers, so we are happy to announce that it is now globally available in our IoT remote management and networking solution. It is the same Ziti platform capability used for our API solution, app-embedded secure networking and IT remote access solutions, so it has hundreds of millions of sessions under its belt. It is available for both OpenZiti (open source zero trust networking platform) and CloudZiti (NetFoundry’s managed Ziti NaaS with hosted Ziti network fabric).
In this post, we take a step back to describe mTLS and the differences between TLS and mTLS. We then outline criteria by which you can determine if the mTLS option matches your IoT use case needs. We discuss how mTLS itself works in general, and specifically how it works as part of a Ziti-powered IoT overlay network.
Do you care about mTLS for IoT?
Most of us are familiar with TLS from the web. TLS tells our client/browser that the website we are visiting has proven (via a cryptographically authenticated X.509 certificate) that the web server is who it says it is. Think of this as the validation of the identity of one party.
Mutual TLS also validates the identity of the IoT client (in addition to validating the IoT server). So mTLS helps your IoT server validate that the IoT clients are who they say they are. It looks like this:
In a solution like NetFoundry’s, which combines IoT mTLS with an IoT overlay network fabric which only accepts authenticated endpoints, the net result is your IoT server no longer needs to be open to the Internet – you deny all inbound traffic (your IoT servers and clients both open outbound sessions to its private IoT overlay network fabric).
So, if you *don’t* care about IoT server security or management, then this post is probably not for you. If you *do* manage IoT servers, then this post is for you.
Is mTLS for IoT a better solution than TLS, VPN (or private mobile APN) or firewall ACLs?
Engineering answer: it depends. With that out of the way, let’s look at general guidelines for the use (or not) of mTLS in IoT.
IoT mTLS versus TLS
TLS will generally be simpler and easier. And simpler can mean more secure and scalable. If you are in a situation in which you can explicitly trust any device which has the ability to connect to your IoT server, and the data you are dealing with is not very valuable or sensitive, then TLS may be for you.
If you are concerned with attacks on your IoT server, for example because you are dealing with sensitive or valuable data, then mutual TLS is a great solution. In fact, most IoT operators would default to mTLS in that situation, except managing certificates and PKI is often difficult and complex (which is why NetFoundry customers asked us to build it into its IoT solution). Note: we are using PKI as shorthand for the set of tools, policies, and procedures needed to mint, enroll, manage, distribute, update and revoke digital client certificates (like X.509s).
IoT mTLS versus VPN or private mobile APN
This comparison mainly hinges on the number of sites, the amount of change and latency requirements. At one extreme, if you have a few sites, and they are relatively static, then you can probably afford the operational overhead of VPN. Likewise, if you are ok with site #1 tunneling all of its data to site #2, then VPN backhaul may be ok for you (split tunnel can be done but is made difficult by VPN architectures).
Mutual TLS scales far better, e.g. across 10s to 1000s of sites. And, if mTLS is paired with dynamic routing (it is in the NetFoundry IoT remote management and networking solution), then one IoT endpoint or gateway can simultaneously send (or receive) data from (n) number of other endpoints (eliminate backhaul). This is important for IoT deployments which need latency reduction (avoid VPN or private APN backhaul), or cost reduction (avoid backhauling all data to one cloud and then paying extra cloud egress costs to get the data to where it actually needs to go). Note: private mobile APNs and VPNs are essentially the same in the context of this conversation – both result in a default single tunnel backhaul VPN to one site.
IoT mTLS versus firewall ACLs
IP-address based ACLs has become somewhat of a default solution for folks who do want to protect their API servers, but don’t want to implement mTLS (prior to the availability of solutions like the NetFoundry solution which provide the IoT mTLS PKI). ACLs can work well for a limited number of endpoints with static public IPs and a low rate of change.
Dependencies on IP addresses and ACLs becomes difficult for large deployments (lots of IPs), overlapping RFC 1918 space, the need to get static public IPs (or do port forwarding) and dealing with IP address changes. Meanwhile, IP addresses are weak identifiers from a security perspective (as compared to mTLS X.509s…more on that below).
So, similar to VPNs, IoT mTLS is often the better choice for deployments which have many endpoints, strict security and compliance requirements or high rates of change.
IoT mTLS security model
Let’s not claim mutual TLS is more secure than TLS, VPN or firewall ACLs without describing the solution so you can judge for yourself.
Most security models should start with identity. Mutual TLS is no different. Specifically, X.509 certificates replace the use of IP addresses for identity (the certs can be other types but X.509 is dominant). These certs authenticate IoT client and device connections. In the NetFoundry solution, without this authentication, the devices can’t connect to the Ziti overlay network fabric, which means they can’t connect to your IoT servers (your IoT servers are no longer open to the Internet – you close the inbound firewall ports – and instead your servers will now only talk to mTLS authenticated clients, with all communication initiated outbound.
Why are X.509 certificates a good basis for identity and authentication? First of all, X.509 certificates enable asymmetric keys, taking advantage of the power of public-private key cryptography. You can store private keys in places like TSMs so that the cryptographic material never leaves your device. Because the private key never leaves the device, it is far stronger than credentials which can be hijacked, phished or brute forced such as passwords or codes passed by text message. Furthermore, they don’t require human interaction with the IoT device.
In the case of the NetFoundry solution, the Ziti controllers will validate the cert against its Certificate Authority (CA). You can optionally add your own CA to the chain of trust. The Ziti controller challenges the client for proof of ownership of the private key that corresponds to the public key contained in the certificate. Part of the magic of the solution is making the PKI (enrollment, validation and management process) simple. Check out this blog post series if you want more detail on it.
IoT option summary – is mutual TLS a silver bullet for IoT security?
No. The first question is if you need to secure your IoT servers. Even if you do, then mTLS is just one important layer. Whether IoT mTLS is for you depends largely on the factors listed above. If you do need IoT mTLS, and you want to combine it with an IoT network overlay in order to remove your IoT servers from any network exposure, then NetFoundry’s IoT management and networking solution looks like this:
