Why is TLS that encrypts but does not verify the server's certificate (curl -k, or an ESP32 built with server verification skipped) almost no protection on an open Wi-Fi network?
Without verification the client completes a handshake with whoever answers, including an attacker in the middle. The attacker terminates TLS with the client using their own certificate, opens a second TLS connection to the real server, and reads and changes everything in between. Encryption alone only stops passive listeners.
* Two encrypted connections, and the attacker holds the keys of both. *
Getting in the middle is easy on an open network, which has no way to authenticate the access point either. The attacker can:
- spoof ARP so the laptop's IP address resolves to the attacker's MAC address, or
- run a rogue access point with the same network name and a stronger signal.
Then the attack runs:
- The ESP32 opens a TLS connection to what it thinks is the server. The attacker answers with their own self-signed certificate.
- A client that verifies sees that it is not the pinned certificate and aborts. A client that does not verify carries on.
- The attacker now shares session keys with the ESP32 and, over a second connection, with the real server. Every request is decrypted, can be read or changed, and is re-encrypted.
This is why ESP-TLS refuses by default to connect when no verification option is configured, and why its "skip server certificate verification" option is labelled for testing only. curl -k is the same trade on the laptop: convenient while debugging, wrong for anything that matters.
Go deeper:
Wikipedia — Man-in-the-middle attack — how interception works and why authentication of the endpoints is the defence.- ESP-IDF — ESP-TLS — the verification options and the warning on the insecure skip option.