¿Es una buena práctica eliminar la contraseña de un certificado SSL?


10

He leído en varios blogs ahora que uno debe eliminar las contraseñas de los certificados SSL para evitar las solicitudes de contraseña durante los reinicios de Apache.

¿Es esto cierto y plantea algún riesgo de seguridad?


Si realmente le preocupa, hay hardware disponible, donde su clave privada puede almacenarse en un dispositivo USB y nunca podrá recuperarse. Sin embargo, esto realmente no funcionará en un entorno alojado.
Zoredache

Observo de pasada, solo para evitar confusiones, que el certificado nunca está encriptado, ni tendría ningún sentido hacerlo; para que se complete el protocolo de enlace SSL, el certificado debe ofrecerse en texto sin formato a cualquiera que lo solicite. Un certificado es solo una clave pública firmada por un tercero. Es la clave privada , la contraparte asimétrica de la clave pública (que es capaz de descifrar el tráfico cifrado en la clave pública), que puede almacenarse cifrada y sobre la que está preguntando.
MadHatter

Respuestas:


22

Sí, detendrá los mensajes que se envían al terminal al iniciar un servidor web.

Y sí, representa un riesgo de seguridad porque antes de que se encriptara el certificado ahora está en texto plano. Esto significa que podría ser posible robar un certificado completamente funcional de la máquina.

Si esto representa un riesgo de seguridad significativo para usted depende de cuáles serían las repercusiones si le ocurriera a usted y qué gana de hacerlo de esta manera.

Si es más importante para usted que los servicios se reinicien correctamente, incluso si están desatendidos que la seguridad del sistema SSL en general, entonces es una respuesta directa.

Personalmente, considero que mantener copias descifradas de certificados SSL en general tiene más ventajas que desventajas para mi carga de trabajo típica, he aquí por qué;

  1. Un atacante aún tendría una copia del certificado, incluso si estaba encriptado, por lo que sería su deber revocarlo de todos modos.
  2. En estos días es mucho más fácil para un atacante obtener un certificado válido para su sitio a través de ingeniería social que robar una copia de trabajo de uno.
  3. Los certificados caducan naturalmente haciendo que su superficie de ataque sea limitada.
  4. Los sistemas de seguridad basados ​​en host, como los permisos tradicionales y SELinux, ofrecen un medio sólido para proteger los certificados en la plataforma.
  5. Un certificado no es un todo y un sistema seguro. Hay muchos otros aspectos a considerar, como los datos que almacena, los medios en los que los almacena y el valor y / o la naturaleza personal de los datos.

Cosas que podrían hacerme cifrar:

  1. Si utilizó el certificado para realizar la autenticación mutua.
  2. Es un certificado comodín o un certificado que aloja múltiples dominios (las pérdidas se duplican o triplican o cualquier otro host que se pueda utilizar para ello)
  3. El certificado es multipropósito de alguna otra manera.
  4. El propósito de los certificados es garantizar la integridad de los datos de alto valor (registros médicos, transacciones financieras y similares).
  5. El otro extremo espera un alto grado de confianza y / o depende de la integridad de su sistema para tomar decisiones operativas.

En última instancia, no confíe en que otros tomen decisiones de seguridad por usted. Debe sopesar los riesgos y determinar qué es lo mejor para usted y su institución utilizando la mayor cantidad de información posible.


8

Proporciona más seguridad, pero la realidad es que si alguien ha llegado lo suficientemente lejos en su sistema para obtener acceso a su clave SSL privada, probablemente tenga problemas más grandes.

Desde una perspectiva práctica, ¿realmente desea estar allí cada vez que apache necesita reiniciarse para ingresar una contraseña?

Una cosa que podría hacer es mantener la clave sin contraseña protegida en su servidor (y protegerla mediante la seguridad normal del sistema) y mantener una copia de seguridad de la clave que almacena en otro lugar con una contraseña. Por lo tanto, si alguien puede desechar la clave de otro lugar que no sea su servidor (mucho más probable, piense que alguien portátil se lo roban en su escritorio), todavía está protegido.


0

Las claves de cliente utilizadas para iniciar sesión deben estar protegidas con contraseña.

Si desea que los servicios basados ​​en SSL se reinicien sin intervención manual, tiene dos opciones:

  1. No tenga una contraseña en la clave y protéjala para que solo los servicios que la necesiten puedan acceder a ella.
  2. Almacene la contraseña en texto sin formato o un texto sin formato equivalente en el servidor para que los servicios que la necesiten puedan proporcionar la contraseña. (Puede terminar con varias copias de la contraseña en archivos de configuración mal protegidos).

Las copias de seguridad de la clave deben estar protegidas con contraseña y aseguradas como si no estuvieran protegidas con contraseña.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.