Exploiting insecure certificate validation in TLS clients

The talk opens with a primer on TLS and certificates, explaining how a certificate lets a client confirm it is talking to the right server. It covers the three checks a client should make: who issued the certificate, who it was issued to, and whether the signature is valid. The speaker argues that many non-browser clients, including IoT devices and internal applications, skip some or all of these checks, and that this is a long-known problem.

The middle section shows the problem in practice. Using openssl, the speaker creates a self-signed certificate and then clones a publicly issued certificate with a swapped public key, so the signature no longer matches. A code sample from a Microsoft Intune component was shown where the validation function always returned true, which the speaker linked to a 2021 remote code execution issue. Live demos then used rogue DHCP and DNS to redirect an iPhone's App Store traffic to a TLS-terminating listener, and redirected a Windows 11 machine to a spoofed configuration server. The speaker reported that the iOS issue was fixed by Apple and that further related issues are still undisclosed.

The takeaway is that developers should validate issuer, subject and signature in every client, and should not rely on TLS alone for sensitive downloads or configuration, adding an application-layer encryption or signature check. The speaker also points to badssl.com as a way to test invalid certificate cases in unit tests.