Differences
This shows you the differences between two versions of the page.
|
iothings:laboratoare:2025:lab8 [2025/11/15 13:24] dan.tudose [Modify the Firmware to Add the Certificate] |
iothings:laboratoare:2025:lab8 [2025/11/15 13:31] (current) dan.tudose [Lab 8. Security in IoT] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Lab 8. Security in IoT ====== | + | ====== Lab 8. IoT Security and Attacks ====== |
| ===== Breaking an insecure IoT sensor over HTTP ===== | ===== Breaking an insecure IoT sensor over HTTP ===== | ||
| Line 432: | Line 432: | ||
| Notice we are using a domain name instead of an IP address for the server and we are not relying anymore on ''setInsecure()'', rather we're using HTTPS with CA cert verification. | Notice we are using a domain name instead of an IP address for the server and we are not relying anymore on ''setInsecure()'', rather we're using HTTPS with CA cert verification. | ||
| + | |||
| + | ==== Replay the MITM Attack ==== | ||
| + | |||
| + | Try to repeat your ARP poisoning + mitmproxy trick with this setup. ARP poisoning still works: packets still flow ESP32 → attacker → server, but when mitmproxy shows its own cert to the ESP32, WiFiClientSecure aborts the handshake. That is because the cert is not signed by your lab CA. Your HTTP POST never happens; your code will see a connection / TLS error. | ||
| + | |||
| + | In brief: | ||
| + | * With ''setInsecure()'', MITM can see JSON + MAC and divert, alter or even drop packets entirely. | ||
| + | * With ''setCACert()'' + correct hostname, MITM can still route traffic (DoS is possible), but they cannot terminate TLS in the middle; they get reduced to a dumb packet forwarder or DoS attacker. | ||
