Manejo de certificados SSL en productos

  

Estamos instalando el mismo certificado autofirmado en cada unidad de desarrollo y prototipo.

Instalar el mismo certificado en cada unidad es una de las peores prácticas de seguridad que uno podría imaginar al tratar con certificados. Ahora sabemos que no debemos lanzar productos con las credenciales administrativas codificadas por defecto. Evitamos las credenciales predeterminadas porque dichas credenciales podrían extraerse una vez y usarse para comprometer todos los dispositivos que las implementan. Esta es una situación muy similar: el certificado predeterminado significa que la clave privada podría extraerse una vez y usarse para comprometer todos los dispositivos que dependen de este certificado.

Criptográficamente, tanto los certificados de terceros autofirmados como los de confianza funcionan de la misma manera. Cada certificado está asociado a un par de claves que consiste en una clave privada secreta y una clave pública no secreta. Si conoce la clave privada, puede realizar todas las acciones asociadas con la clave pública y el certificado.

El compromiso de los certificados predeterminados tiene más implicaciones que solo comprometer la autenticación. Para TLS, dependiendo del cifrado utilizado, el certificado podría terminar siendo utilizado para establecer un secreto compartido. En tales casos, un intruso pasivo podría descifrar el tráfico TLS después de ver el saludo inicial.

Claro, los administradores competentes solucionarán este problema cargando sus propios certificados exclusivos, pero ¿cuántos de ellos se detendrían en la etapa de 'solo funciona' al confiar en el certificado predeterminado? Lo que debe hacer en su lugar es generar un nuevo par de claves en el arranque inicial o el restablecimiento de fábrica. Así es como funcionan los dispositivos de red seguros. Al generar un nuevo certificado, también debe asegurarse de tener suficiente entropía disponible en el sistema y no generar claves factorables.

Podrías hacer algo como ofrecer un certificado único para

product-serial-number.product-name.company-name.com

y haga que se emita por algo que tenga algo de confianza en la ruta de certificación. El certificado aún no sería confiable para ese propósito, pero alguien podría verificar el certificado con una etiqueta en la casilla (e instalarlo opcionalmente en su almacén de certificados). Desafortunadamente, Chrome y Edge ya no facilitan la visualización de los detalles de los certificados en las páginas HTTPS, por lo que será difícil.

He estado exactamente en la misma situación, ya que he sido responsable de desarrollar un servidor HTTPS (y el contenido asociado, la API REST, etc.) que está integrado en un dispositivo de consumo.

Como ya se indicó en la pregunta, la instalación de un certificado firmado por una CA (Autoridad de certificación) no es una opción desafortunadamente, porque el certificado debe estar vinculado a un dominio.

En mi experiencia, lo mejor que puedes hacer es generar un par de claves único y un certificado en cada dispositivo. En mi dispositivo, esto ocurre durante el primer arranque después de cargar el firmware en el dispositivo y también si se realiza un restablecimiento de fábrica. El microcontrolador en uso tiene un RNG de hardware utilizado para este propósito.

Utilizar el mismo par de claves y el mismo certificado en todos los dispositivos sería especialmente peligroso si considera que un atacante podría simplemente obtener uno de sus dispositivos y extraer de él la clave privada, momento en el cual todos los dispositivos se verían comprometidos.

Por lo tanto, en mi experiencia, lo mejor que puede hacer (ya que no parece existir una solución ideal) es informar a sus clientes por qué tienen que reconocer la advertencia de seguridad de su navegador sobre el certificado autofirmado en los manuales del producto. y, al menos, asegúrese de que cada dispositivo cree su propia clave privada y certificado únicos.

  

Los clientes podrán proporcionar sus propios certificados, firmados de la manera que deseen (en público o en privado). Esto les dará la cadena de confianza y les permitirá estar seguros de que realmente se están conectando a ese sistema.

Esto sugiere que o bien A ) una instalación típica tendrá un nombre de dominio "real", visible en la Internet pública (a diferencia de un nombre de dominio de la intranet o una dirección IP privada) o B ) un cliente típico tendrá los conocimientos técnicos necesarios para operar su propia autoridad de certificación interna.

Si (A) es verdadero, entonces su producto podría marcar Let's Encrypt y obtener un certificado firmado de esa manera. Esto requiere que el servicio tenga un nombre de dominio "real" y que sea completamente visible para el público en Internet (es decir, no tenga un servidor de seguridad en los puertos 80 y / o 443). Los certificados de Let's Encrypt se pueden adquirir de forma totalmente automatizada y no requieren ningún paso manual, siempre y cuando ambos sepan y controlen (pueden servir el tráfico web desde) el FQDN. Naturalmente, debe interactuar con el servicio de manera razonablemente "educada", especialmente considerando que es gratuito (es decir, no le envíe un gran número de solicitudes a la vez, implemente un retroceso exponencial de reintentos, etc.).

Si (B) es verdadero, entonces debería ir con la opción que describe (es decir, dejar que el cliente proporcione un certificado), porque sus clientes están mejor posicionados para resolver este problema que usted. Sin embargo, en la mayoría de las industrias, (B) no es cierto. Sin embargo, un cliente suficientemente aventurero podría querer la opción de hacer esto, por lo que debería proporcionarlo de todos modos.

Si ni (A) ni (B) son verdaderas, debes seguir una de las otras respuestas. En este caso, un cliente típico no tiene la capacidad de proporcionar un buen certificado, por lo que no debe responsabilizarse por ello. Es posible que aún desees proporcionar una opción para usar un certificado personalizado, pero no debes hacerlo como el predeterminado.