¿Puede SSL unidireccional asegurar un dispositivo IoT?

Estoy considerando un dispositivo IoT conectado a mi red local (configuración predeterminada, sin VPN, sin NAT, sin DMZ) con o sin acceso a Internet. Mi dispositivo se ejecutará como un servidor HTTP que ofrece un mecanismo RPC con autenticación y autorización. Se anuncia con mDNS y hablo con mi aplicación móvil o mi RaspberryPi.

Parece que la norma en el desarrollo de IoT es tener SSL mutuo (bidireccional). ¿Eso significa que SSL unidireccional no puede asegurar mi tráfico? ¿Por qué?

Notas:

• Entiendo las diferencias técnicas entre SSL de una y dos vías, no entiendo por qué One-way (casi) nunca se considera en la producción de IoT.
• Entiendo que tener SSL mutuo para un dispositivo local es difícil: debe compartir la clave pública del servidor y el certificado con el cliente y viceversa. Unidireccional, por otro lado, parece más fácil (no requiere la acción del usuario).
• Algunos dispositivos de producción masiva como Philips Hue prefieren tener un punto final http local abierto y no seguro que un cifrado SSL unidireccional. ¿Por qué uno tomaría esta decisión?
• Espero que esta pregunta no esté basada en opiniones. Disculpas si este es el caso.

SSL / TLS funciona bien cuando el "servidor" se encuentra en una ubicación conocida (un nombre de host fijo) que puede coincidir con el CN ​​del certificado que presenta.

Esto no funciona bien para dispositivos en redes domésticas (por ejemplo, la mayoría de los dispositivos IoT) porque tienden a obtener direcciones IP emitidas desde bloques RFC1918 y no tienen entradas DNS. Esto significa que no pueden emitirse con certificados (bueno, sí, pero la mayoría de los navegadores los rechazarán). Esta es la razón por la cual dispositivos como Philips Hue utilizan puntos finales HTTP no seguros del dispositivo, básicamente dependen del acceso a la red que se protege para proteger el dispositivo.

Cuando se usa TLS mutuo, es para cuando el dispositivo se conecta a algún servicio central, el cliente tiene su propia clave cert / privada para autenticar que puede actuar en nombre del propietario con ese servidor central.

Como punto de aclaración a su pregunta, no necesita distribuir el certificado / clave de los servidores a todos los clientes, solo se necesita el certificado de la CA que emitió el certificado para demostrar que el certificado es confiable.

EDITAR:

Un buen ejemplo de una conexión de dispositivo local segura es la iluminación Tradfri de IKEA que utiliza COAP sobre DTLS con una clave precompartida (en un código QR) en el dispositivo que se utiliza para generar una clave por cliente. Esto garantiza el acceso físico para configurar un nuevo cliente y protege los datos en vuelo en la red local.

En general, TLS es bueno por mucho más que x.509, pero muchas implementaciones lo limitan a solo x.509.

x.509 es una técnica para una confianza indirecta segura. "A" confía en "B", si "B" tiene un certificado, que está firmado por "C" y "A" confía en "C". Eso funciona también en la vida real; confía en alguien que no conoce, si se presenta una carta firmada por una persona de su confianza. Tal vez veas la trampa: si la carta dice, por favor dale una taza de café que no le darás a tu auto. Por lo tanto, la información adicional en el certificado también es relevante para el alcance de la confianza. Es por eso que un servidor generalmente tiene su nombre DNS o dirección IP en su certificado. En general, puede incluir información diferente (por ejemplo, "lámpara de la sala de estar"), pero muchas implementaciones también están al menos preconfiguradas para usar / verificar el material DNS / IP. Y todo eso solo funciona si a alguien le importa la confianza "

Si puede pasar tiempo en él, verifique su implementación, si también ofrece conjuntos de cifrado PSK. De lo contrario, tal vez pueda ajustar la "verificación de validación" del certificado de los servidores. Pero requiere mucha lectura para encontrar una buena solución. Y a veces la implementación de TLS utilizada simplemente no ofrece eso.