Por qué el mTLS no es para todo el mundo
En el sector IoT/OT se habla mucho de la seguridad Zero Trust y de cómo todo debe ir cifrado de extremo a extremo. Sobre el papel, suena impecable. Así que en mi último pipeline de telemetría decidí hacer las cosas “de manual”: asegurar la conexión entre mis nodos ESP32 y el broker MQTT utilizando mTLS (autenticación mutua).
El resultado: reinicios constantes, pérdida de paquetes y errores de asignación de memoria. Un desastre operativo.
Esto no es un post de éxito. Es un post sobre lo que pasa cuando intentas forzar el hierro más allá de sus límites físicos.
El choque de realidad bajando al cable
El ESP32 es un microcontrolador fantástico, pero el mTLS es un monstruo devorador de memoria estática (SRAM).
Para establecer un túnel mTLS, el cliente no solo cifra el tráfico. Tiene que procesar, cargar en memoria y validar certificados criptográficos asimétricos pesados, tanto del servidor como el suyo propio. Cuando le pides esto al microcontrolador usando librerías como mbedtls, el heap colapsa.
Si a la criptografía asimétrica le sumas el consumo de la pila TCP/IP, la gestión del Wi-Fi y tu propio código de sensores, el microcontrolador se queda sin aire. Empiezan a saltar errores como BIGNUM allocation failed, los handshakes dan timeout o, simplemente, el nodo se reinicia por desbordamiento.
Intentar solucionar por software un cuello de botella de hardware es una batalla perdida.
Mi mesa de trabajo. Donde realmente pasan las cosas..
Las 3 alternativas reales en entornos industriales
Mi gozo en un pozo, en fin… tuve que documentarme para ver que es lo que pasaba y como ponerle remedio a que este tipo de microcontroladores no fueran interceptados por un ataque MitM (Man-in-the-Middle) y que la telemetría llegara al broker encubierta, ¿pero cómo? Aqui estan las respuestas que encontré.
1. El patrón Edge Gateway (MQTT Bridge)
Si el sensor no puede con el certificado, no se lo pidas. Despliego los ESP32 publicando en local dentro de una red aislada y segura hacia un gateway en el borde (como una Raspberry Pi o un equipo de red dedicado). Es ese equipo, que va sobrado de cómputo, el que ejerce de Bridge y levanta el túnel mTLS contra el broker corporativo. Centralizas la seguridad y liberas al sensor.
2. Delegación Criptográfica al Hierro
Si el ESP32 tiene que salir directamente y necesitas mTLS real, saca las matemáticas de la CPU. Se integra un chip de elemento seguro por hardware (como un ATECC608A) conectado por I2C. El chip guarda las claves privadas y hace el trabajo pesado del handshake. El ESP32 vuelve a ser solo un mensajero.
3. Microsegmentación de Red (VLANs y Reglas Estrictas)
Si no hay hardware extra, la seguridad recae en la red. Renuncias al mTLS pesado en el nodo, usas TLS básico o incluso tráfico en plano, pero confinas los equipos. Todos los sensores van a una VLAN OT sin salida a internet, detrás de un firewall perimetral estricto que solo permite tráfico TCP por el puerto 1883, exclusivamente hacia la IP del broker.
La lección que me llevo es clara: la seguridad industrial no consiste en aplicar el mismo protocolo de servidor a un microcontrolador de 3 euros. Consiste en entender la topología, conocer los límites de tu hardware y adaptar la arquitectura de red en consecuencia.
Bueno, no siempre gusta poner las cosas bonitas, los fallos tambien cuentan y mucho.
ACTUALIZACIÓN (14 de Junio de 2026): El problema está en el “Hierro” (ESP-IDF)
Investigando a fondo por qué mi placa no aguantaba el túnel, di con la raíz del problema en la propia documentación del fabricante. Cuando programas en MicroPython (o en Arduino), en realidad estás usando una capa de abstracción. Por debajo, tu código se traduce a ESP-IDF (el framework oficial en C de Espressif).
Concretamente, toda la carga criptográfica recae sobre la API nativa esp_tls (que a su vez utiliza el motor matemático mbedTLS).
Para levantar un túnel mTLS completo, le estaba exigiendo a esp_tls que metiera en la minúscula memoria SRAM del ESP32 (apenas ~520 KB en total):
- La clave pública del servidor (
xxxxx.local). - El pesado certificado de cliente del propio ESP32.
- La clave privada RSA/ECC.
- Bloques de memoria masivos (buffers) para hacer las operaciones matemáticas de descifrado asimétrico en tiempo real.
Al final, el heap (la memoria dinámica) colapsaba bajo el peso de la criptografía de doble vía. El chip se quedaba sin oxígeno para gestionar el Wi-Fi, la pila TCP/IP, el sensor DHT11 y la pantalla OLED, entrando en pánico y reiniciándose por protección.
(Fuente técnica oficial sobre los límites de este protocolo: Espressif ESP-IDF API Reference: esp_tls)
La Solución Híbrida: Delegar la seguridad a la Red
No me gustaba la idea de dejar la telemetría del proyecto Sandevistan en texto plano, expuesta a cualquier ataque MitM (Man-in-the-Middle). Si el ESP32 no podía con el peso del mTLS completo, tenía que dividir la carga de seguridad entre el microcontrolador y la infraestructura de red.
Aquí está exactamente cómo lo hemos blindado:
- Aligerar la criptografía (TLS Unilateral): En lugar de asfixiar al ESP32 obligándole a presentar su propio certificado, le hemos dado un rol más ligero. Ahora solo carga el certificado de nuestra CA (
ca.crt) para validar el Common Name del servidor. Si el servidor es legítimo, levanta el túnel y se autentica mediante usuario y contraseña. Seguridad alta, consumo de RAM mínimo. - Microsegmentación y el Muro de Capas 2/3: El ESP32 vive confinado en una VLAN OT (VLAN 40), aislado del servidor MQTT (VLAN 30). En el router MikroTik, fijé un lease DHCP estático amarrado permanentemente a la dirección MAC del sensor.
- Reglas Quirúrgicas de Firewall: Implementé una regla en el MikroTik que exige una doble validación: el firewall comprueba la MAC (Capa 2) y la IP (Capa 3). Solo si coinciden, y el destino es el broker por el puerto cifrado
8883, el paquete pasa. Si el ESP32 se desconecta y otro dispositivo suplanta su IP, el router destruye el tráfico.
Conclusión
La lección que me llevo tras esta paliza técnica es clara: la seguridad industrial no consiste en aplicar a lo bruto el mismo protocolo de servidor a un microcontrolador de 3 euros. Consiste en conocer los límites físicos de tu hardware, entender cómo funcionan las APIs nativas que operan en la sombra, y delegar el blindaje duro a la arquitectura de red.
No siempre gusta poner las cosas bonitas en los blogs; los fallos cuentan, y mucho. Pero cuando la consola por fin te devuelve un ✅ Conectado al Broker Seguro (Port 8883), todo el esfuerzo cobra sentido.
Captura de tráfico TLS 1.2 en puerto 8883. La inspección del flujo Application Data confirma la encriptación efectiva de la carga útil (payload), verificando la integridad y confidencialidad del canal MQTT entre el nodo ESP32 y el broker Mosquitto.
