Definition
TLS (Transport Layer Security) is an IETF-standardized transport layer security protocol that provides encryption, integrity verification (MAC), and authentication (certificate verification) for TCP connections. TLS evolved from SSL. HTTPS, MQTT over TLS, CoAP over DTLS, API calls, etc., are all based on TLS/DTLS, making it a crucial part of end-to-end IoT security and security architecture. TLS 1.3 is integrated into QUIC as the encryption layer for HTTP/3.
Versions and Features
- TLS 1.2: Widely deployed, supports multiple cipher suites (such as AES-GCM, ChaCha20-Poly1305), requires 2-RTT handshake
- TLS 1.3: RFC 8446, simplified handshake (1-RTT), removes weak algorithms, enforces forward secrecy (ECDHE), supports 0-RTT resumption
- DTLS: UDP version of TLS, used for CoAP, WebRTC, QUIC, etc., supports packet loss and out-of-order scenarios
Handshake and key exchange
TLS handshake includes: Client Hello (supported versions, cipher suites) → Server Hello (selected parameters, certificate) → Key Exchange (ECDHE/RSA) → Finished (verifies handshake integrity). After the handshake, an encrypted channel is established, and application data is transmitted using symmetric encryption (AES-GCM, etc.). Certificate chain verification ensures server identity and prevents man-in-the-middle attacks; mutual TLS (mTLS) can authenticate the client as well, commonly used for IoT device and platform authentication.
Typical Use Cases
TLS is widely used in HTTPS, API gateways, MQTT brokers, IoT platforms, VPN (such as traditional VPNs other than WireGuard), RADIUS over TLS (RadSec), etc. When IoT devices communicate with the cloud, it is strongly recommended to use TLS/DTLS encryption to ensure data confidentiality and integrity.
When SimtoLink's IoT devices communicate with the cloud platform, data is transmitted via protocols such as HTTP/HTTPS and MQTT over TLS, with TLS being the core for securing transmission. When configuring IoT platform integration, certificate management, and device authentication for customers, SimtoLink assists customers in enabling TLS 1.2 and above, setting up certificate validation and mutual authentication (mTLS), ensuring secure data transmission in public and private network scenarios.
The Handshake Proves Identity, the Record Layer Protects the Data
TLS first uses a handshake to agree the version, the cipher suite, and the keys, then uses the record layer to apply symmetric encryption and integrity protection to application data. Identity rests on the certificate chain. The server presents a certificate, and the device checks that the chain leads to a root it trusts and that the name in the certificate matches the host name it is visiting. Current key exchange uses an ephemeral elliptic-curve key, so a transcript recorded earlier cannot be decrypted later. TLS 1.3 shortens the handshake to one round trip and removes a set of obsolete suites. TLS 1.2 is still common, but the suite list has to be restricted. Null encryption or static RSA cannot be left on the list for the sake of compatibility. DTLS puts the same handshake on UDP and has to handle loss and reordering. A protocol such as CoAP uses DTLS, not TLS over TCP.
Successful encryption only means the bytes on the channel are protected. It does not mean the other party is the server that was expected. Skip name checking, or accept any certificate, and an interceptor can present its own certificate and take over the session. Mutual authentication also requires the client to present a certificate or a pre-shared key, so the platform can confirm which device it is.
Chain, Name, and Time: All Three Are Required
TLS is usable when the device has the correct trust anchor, can read the current time, and the domain being visited is written in the certificate’s subject or subject alternative name. Connect by IP while the certificate is issued only for a domain name, and validation fails. A device with no battery-backed clock, whose time at power-on sits at the year it left the factory, will judge a certificate that has not expired as not yet valid or already expired. If the chain is missing an intermediate certificate, a device that stores only the root cannot join the chain. An embedded device also has to afford the memory and the round trips of the handshake. On a cellular link with large delay, a handshake timeout that is too short is abandoned by the application before it can succeed.
0-RTT resumption can save a round trip, but early data can be replayed. It does not suit an unlock or a payment, an instruction that must not run twice. If session tickets are not rotated for a long time, a leaked ticket key widens the damage. The relation to integrity protection is this: the TLS record layer already carries integrity, and air-interface integrity is another layer. Do not substitute one layer for the other, and do not switch validation off inside TLS “to save computation.”
Skipping Validation, or Leaving an Expired Suite on the List
The most common field case is certificate validation switched off while debugging, then forgotten in the production firmware. The link is still encrypted, and an attacker can still impersonate the platform. Another case is checking only the root and not the host name. Any certificate issued by the same public CA then passes. A clock set backward, an intermediate certificate that was never delivered, or old firmware that does not recognize a new root after a certificate rotation all show up as intermittent connection failures and are easy to call a SIM fault. If TLS 1.0 or 1.1, RC4, or a suite with forward secrecy switched off remains on the server’s preference list, an old device negotiates down to a weak algorithm. The security scan and the protection actually in use do not match.
Also avoid burning the root private key or the device private key into the same firmware image that can be read out. Once a private key leaves with a maintenance package, every device can be impersonated until the certificate is revoked. When a handshake fails, read whether the alert is an unknown CA, a name mismatch, expiry, or a protocol version that does not match. The four fixes are completely different. Seeing only “SSL error” in the application log and then swapping the SIM does not locate the key material.
On a handshake failure, look at the alert type first. An unknown certificate authority, a host name that does not match, a time outside the validity period, and a protocol version or suite that does not match need four different responses. A device with no reliable clock will judge a certificate that is still inside its validity period as not yet valid. Check only as far as the root, and not the host name, and another certificate from the same authority can take the session over. If a debug switch in the production image still has validation off, encryption is still there and identity is already untrustworthy. Keep the alert name in the failure log. Do not keep only a generic handshake error.