Mejores prácticas para implementar HTTPS en dispositivos integrados

7

Los dispositivos integrados, como enrutadores, cámaras IP, generalmente proporcionan acceso HTTPS a la interfaz de administración. Estas implementaciones de HTTPS generalmente tienen muchos problemas (certificados no únicos, certificados autofirmados, etc.) que hacen que las conexiones sean inseguras. Por lo tanto, estoy buscando las mejores prácticas, cómo un dispositivo integrado puede implementar HTTPS de una manera segura, que cumpla con los siguientes requisitos:

  • El navegador que accede al dispositivo a través de HTTPS (tanto de forma remota como desde LAN) no muestra ninguna advertencia al usuario. Por lo tanto, el navegador puede validar correctamente el certificado enviado por el dispositivo.
  • Si la clave privada del dispositivo estaba comprometida, un atacante no debería poder usar esta clave para realizar un ataque MitM contra otro dispositivo u otra página web.
  • Si fuera posible, los usuarios no deberían tener que instalar ningún certificado o aceptar ninguna excepción en sus navegadores.
pregunta ebux 26.04.2016 - 10:26
fuente

2 respuestas

1

Es posible que un dispositivo no se venda o se use por un par de años después de su fecha de fabricación y la mayoría (si no todas) las CA probablemente no estén dispuestas a emitir certificados de dispositivos que tengan fechas de caducidad largas, por lo que la solución hacia adelante es quizás poco práctica.

Sin embargo, propongo la siguiente alternativa:

  1. Utilice un método alternativo para establecer la confianza inicial entre el dispositivo y el cliente. Por ejemplo, esto puede ser una VPN IPSec / L2TP con un PSK por dispositivo. La transferencia fuera de banda del PSK impide que MitM (a menos que el atacante sepa el PSK).

  2. Use HTTP (a través de VPN) para descargar una CSR desde el dispositivo. El dominio puede ser un subdominio aleatorio de un dominio controlado por el fabricante / suministrado por el usuario.

  3. El usuario / cliente envía el CSR a una CA en nombre del dispositivo y retransmite el certificado firmado al dispositivo a través de HTTP. La CA debe imponer reglas para no volver a emitir certificados para un subdominio.

  4. El dispositivo aplica el certificado y los conmutadores de comunicación a HTTPS.

  5. Cuando el certificado está a punto de caducar, el dispositivo envía una solicitud de renovación firmada a la CA (a través del cliente / usuario, si es necesario).

Obviamente, la "danza" anterior está mejor automatizada por un programa.

Análisis de seguridad

  • La identidad del dispositivo se establece mediante el conocimiento del PSK.
  • MitM y las escuchas son prevenidas por el protocolo VPN (con PSK)
  • La clave privada del dispositivo nunca se revela (y se puede generar a pedido en lugar de programada en fábrica) debido a la forma en que funciona la CSR
  • Se puede usar un certificado válido por dispositivo que cumpla con todos los requisitos
  • El subdominio aleatorio no específico del dispositivo impide que un impostor registre preventivamente un certificado
respondido por el billc.cn 26.04.2016 - 12:45
fuente
0

Los puntos 1 y 2 se tratan comprando un certificado de una CA de confianza.

En cuanto a tu segundo punto -

  

Si la clave privada del dispositivo estaba comprometida, un atacante no debería poder usar esta clave para realizar un ataque MitM contra otro dispositivo

Si puedes encontrar una manera de hacer esto, serás muy rico.

  

u otra página web.

Eh? No entiendo.

Si bien los dispositivos de este tipo que he usado en el pasado se han enviado sin un certificado, proporcionan un medio para implementar el certificado (y la clave privada) en el dispositivo. Ciertamente, no puede confiar en un certificado suministrado con el hardware a menos que haya enviado la solicitud de canto del certificado al proveedor (y haya conservado la clave privada).

    
respondido por el symcbean 26.04.2016 - 12:18
fuente

Lea otras preguntas en las etiquetas