¿Por qué las interfaces web en los enrutadores de los consumidores no activan advertencias de certificados que no son de confianza?

Lamentablemente, la mayoría de ellos no utilizan https en absoluto.

Si no se usa https, no es necesario realizar una verificación de certificado. En realidad, esto es más inseguro que tener TLS con certificados verificados manualmente, pero supongo que los proveedores intentan evitar asustar a las personas y obtener una reacción violenta de soporte.

En el futuro, cuando el navegador alertará a los envíos de formularios, esto podría cambiar.

Por cierto, el problema real no es el cambio de dirección IP, ya que la mayoría de los enrutadores se dan a conocer con un nombre de constante local. El problema real es que a los fabricantes les cuesta mucho distribuir un certificado para ese nombre de manera que los propietarios malintencionados no puedan recuperar la clave secreta. (Requeriría una protección HSM / TPM)

La otra respuesta no es completamente correcta, por lo tanto, intentaré arreglar eso.

Hay dos tipos diferentes de interfaces web para enrutadores: La interfaz web interna y la externa.

Mientras que el externo debe estar deshabilitado por muchas razones, el interno no necesita https para ser implementado: al acceder al enrutador desde su LAN (supongamos que CRACK puede ser reparado algún día y se considera WiFi) seguro otra vez), un MITM solo puede operar localmente, lo cual no es una gran amenaza en la mayoría de los casos de consumidores.

Sin embargo, en general, sería conveniente tener https en los enrutadores COTS. Esto plantea problemas significativos. Si bien la IP en sí no sería un gran problema, ya que la IP real solo se verifica cuando se accede directamente a través de IP (ya que se considera que la IP es el dominio), existe otro problema: la mayoría de los enrutadores SOHO no tienen zona DNS para los dispositivos o se pueden configurar.

Incluso si todos los enrutadores de un modelo se configuraran con un nombre de dominio local no modificable como "routerxy.local", .local es un dominio para el que ninguna CA nunca crearía un certificado. Este es el punto que faltan las otras respuestas. No es el almacenamiento del certificado y la clave lo que es el factor decisivo (también es uno de ellos, pero podría mitigarse con un HSM), es el dominio local y cómo funcionan las CA.

También habría una manera de mitigar este problema:

Maker x puede crear routery.x.tld y obtener un certificado para eso, y distribuirlo en el HSM de cada caja que envíe. Si esto se filtra (por una vulnerabilidad en el HSM, por ejemplo, ahora están en manos del posible atacante), estás nuevamente en un gran problema.

Además, la mayoría de las CA pueden revocar el certificado cuando ven un abuso como ese (ya que la entidad para la que está el certificado no es la que lo usa)

En general: hay dificultades técnicas que dificultan la facilidad de uso (no queremos advertencias de certificados en nuestro enrutador COTS) y hay pocos beneficios de usar TLS en una conexión que simplemente está dentro de la LAN.

Para el certificado HTTPS, la dirección IP no importa, lo que importa es el nombre de dominio DNS al que está asignado el dispositivo. Siempre que el dispositivo esté provisto de un certificado y una clave privada que coincidan con el nombre DNS que se asignó al enrutador, entonces puede proporcionar HTTPS para ese nombre de dominio.

Ya que los enrutadores generalmente también actúan como el DNS para la red que está sirviendo, es capaz de agregar cualquier nombre de DNS a la red. Así que todo lo que queda es obtener un certificado de confianza pública para ese nombre de dominio.

Las CA de confianza pública no pueden emitir certificados públicos para nombres DNS que no están registrados en el sistema DNS público. Según mi búsqueda, un number of sites afirma que tiene algunos enrutadores ASUS que tienen una página de administración de HTTPS automática en un nombre de dominio que se parece a enlace , que es una publicación pública Dirección DNS registrada que pertenece a los fabricantes del enrutador. Los fabricantes de enrutadores, ASUS en este caso, pueden obtener un certificado válido y de confianza pública para ese nombre de dominio, ya que son propietarios del nombre de dominio asus.com.

Todo lo que se necesita ahora es que el fabricante del enrutador incluya la clave privada para el certificado de confianza pública en los dispositivos que venden. Esto sugiere que, cuando se usa el certificado predeterminado, un atacante lo suficientemente avanzado puede extraer la clave privada del dispositivo para falsificar la página de administración del enrutador. Esperemos que esto no sea sencillo, ya que el enrutador no debería haber permitido que otros usuarios roben su nombre de dominio de administración.