cómo implementar TLS entre el servidor web y los dispositivos integrados

Los requisitos de diseño de su sistema no están completamente claros para mí. Pero en el siguiente apartado asumo que usted tiene control total sobre la configuración y que esta configuración solo tiene los siguientes requisitos:

• conexión segura entre dispositivos y servidor de administración central
• la administración central debe poder enviar comandos a los dispositivos en cualquier momento
• La dirección IP para los dispositivos es dinámica y el servidor de administración no la conoce por adelantado, es decir, el dispositivo debe anunciarse al servidor inicialmente.

Hay varias opciones para implementar esto, como

• Cree una VPN entre los dispositivos y el sistema de administración. Esto se puede hacer, por ejemplo, con IPSec o OpenVPN y también con algunas variaciones con SSH. Dentro de esta VPN, los dispositivos pueden tener una dirección IP privada fija, por lo que abordar un dispositivo desde el servidor no es un problema. Y TLS no es necesario ya que la VPN ya protege las conexiones contra los atacantes fuera de la VPN.
• Cree una conexión TLS desde el dispositivo al sistema de administración que solo requiere un certificado en el lado del sistema de administración. Esta conexión TLS se puede usar con un protocolo personalizado para comunicarse entre el servidor y el cliente. Dependiendo de la configuración y las restricciones debido a los firewalls, puede ser útil no crear una conexión TLS simple directamente sobre TCP, sino usar WebSockets seguros para la conexión bidireccional. Sin embargo, solo se necesita un certificado en el lado del servidor que sea de confianza para el cliente.

Estas configuraciones son similares en que la conexión segura (es decir, el túnel VPN o TLS) se inicia desde el cliente, ya que la dirección IP del cliente es dinámica y el sistema de administración tiene una IP estática o al menos un nombre de host estático. Podría ser útil agregar alguna autenticación del cliente a esto porque no quiere que algún atacante se conecte a su sistema de administración.

Una forma sería crear su propia PKI con su propia CA y emitir un certificado único para cada dispositivo. El tema de este certificado puede ser algún ID de dispositivo que puede utilizar para identificar el dispositivo. Estos certificados del lado del cliente podrían utilizarse para la autenticación en la VPN o como certificados de cliente en la conexión TLS. Y, si un certificado fue comprometido (es decir, alguien hackeó el dispositivo), simplemente puede bloquear el acceso de forma centralizada con este certificado en su sistema de administración.

  

Hay cientos de dispositivos que no tienen nombre de host y su IP no es estática. ¿Entonces los certificados SSL pueden no ser posibles aquí?

Recuerde: antes de intentar descubrir alguna solución de seguridad, comience por determinar su perfil de amenaza. ¿Qué ataques intentas prevenir?

Supongo que uno de los principales es evitar que un atacante se haga pasar por el servidor de control y envíe comandos a los controladores con éxito. Para esto, entonces, desea que los dispositivos puedan autenticar el servidor, y eso requiere un certificado en el lado del servidor , no en los dispositivos, ya sea un HTTPS tradicional (o similar a HTTPS, si está utilizando un protocolo diferente) configuración si los clientes inician una conexión al servidor, o un certificado del lado del cliente si el servidor está iniciando una conexión a los dispositivos.

  

Hay cientos de dispositivos que no tienen nombre de host y su IP   No es estático. Entonces los certificados SSL pueden no ser posibles aquí ???.

Los certificados de autenticación de cliente SSL se pueden emitir sin un nombre resoluble de DNS o direcciones IP fijas. El servidor no tiene que estar configurado para usar DNS para verificarlos.

Tal como lo sugirió Stephan, parece ser el enfoque correcto hacer frente a su propia PKI para este sistema. A menos que su organización ya tenga su propia PKI, esto puede ser tan simple * como usar OpenSSL para generar su propio certificado autofirmado, y luego usar ese certificado de CA para firmar todos sus certificados de servidor y cliente. Tendrá que instalar el certificado de CA personalizado como un certificado de raíz de confianza en cada uno de los servidores y clientes. (Si estos son parte de un ecosistema cerrado, considere eliminar cualquier certificado raíz de confianza que los clientes no necesiten).

Es probable que tenga un inventario de los dispositivos como parte de la ejecución de su organización. Cualquiera que sea la ID que se les asigne, probablemente sería apropiado establecerlos en el DN de los certificados. Pero ciertamente tampoco tiene que hacer eso, especialmente si no quiere poner su nombre interno en sus certificados. En su lugar, puede generar previamente una gran cantidad de certificados y entregarlos a nuevos clientes cuando se registren con usted. A continuación, realice un seguimiento del ID de certificado y del ID de cliente para el que fue emitido y use esa relación para otorgar permisos de cliente. Esto mantiene a su CA emisora fuera del sistema que registra a sus clientes.

Si su organización ya tiene una PKI, consulte con ellos. Deben asignar una unidad organizativa reservada estrictamente a sus dispositivos. Luego, puede hacer que su servidor verifique que los certificados de cliente tengan la OU válida solo para sus dispositivos. De esa manera, otros grupos en su organización no podrán emitir certificados a dispositivos no autorizados / desconocidos.

Recuerde, una vez que los dispositivos están en el campo, pueden ser robados, manipulados y / o desarmados. No confíe más en los certificados de cliente de lo que necesita. No permita que estos mismos certificados de dispositivo otorguen permisos administrativos en el servidor. Y si un dispositivo desaparece, invalida su certificado rápidamente.

* Me disculpo por usar la palabra "simple" junto con PKI.