TLS Certificate Validation on Embedded Clients
A device that connects to the cloud over HTTPS is only as safe as its certificate validation. Many embedded clients encrypt the connection but never check who is on the other end, which defeats the whole point. A man in the middle simply terminates the TLS and reads everything. Here is how to test it.
Encryption Is Not Authentication
TLS does two jobs: it encrypts the channel and it authenticates the server through its certificate. Embedded clients often get the first and skip the second, accepting any certificate presented. That turns a secure channel into one a man in the middle can read at will, because the device cannot tell the attacker’s server from the real one.
Step 1: Put a Proxy in the Middle
Route the device’s traffic through an intercepting proxy that presents its own certificate. A client that validates correctly will refuse to connect:
mitmproxy --mode transparent --showhost
192.168.1.50 -> api.vendor-cloud.example:443 GET /v1/telemetry Authorization: Bearer 9f2c1a... 200 OK (client accepted the proxy certificate)
The device kept talking after the proxy swapped in its own certificate, and the bearer token is now visible in plaintext. That is a complete failure of certificate validation.
Step 2: Test the Subtler Cases
Even clients that check the certificate sometimes skip the hostname, accepting a valid certificate issued for a different domain. Present one and see whether the connection proceeds. A client that does not bind the certificate to the expected hostname is still interceptable.
Three TLS Validation Failures
The three ways embedded TLS goes wrong:
Validating Correctly
Verify the full certificate chain against a pinned CA or a pinned certificate, check the hostname, and reject expired or revoked certificates. Pin to your own CA rather than the entire public trust store so a single compromised public CA cannot sign a certificate your device will accept.
Where This Fits
Proving whether a device validates the server certificate, by intercepting its own traffic, is a standard part of a connected-product penetration test. That testing is the kind of work we do at Berkner Tech.