¿Es posible automatizar el uso de claves privadas cifradas con contraseña?

Question

¿Es posible automatizar el uso de claves privadas cifradas con contraseña?

#1 de LSerni (3 votos)
#2 de u2702 (3 votos)

5

Supongamos que tengo un par de claves público / privado, que me gustaría usar para servir HTTPS desde un servidor web. La parte que me preocupa es la siguiente: la clave privada está cifrada con una frase de paso, de modo que si un atacante obtiene acceso a mi servidor web no obtiene la clave privada. Pero quiero un sistema automatizado para iniciar el servidor web: por ejemplo, monit para reiniciar el servidor si se bloquea, o puppet para implementarlo en muchas máquinas diferentes. es posible? Me parece que tengo tres opciones:

Descifre la clave privada y guárdela en texto sin formato en algún lugar de la máquina, en un área que espero que un atacante no pueda comprometer.
Almacene y use la clave cifrada, pero también almacene la frase de contraseña para que la usen los sistemas automatizados. Esto no parece ser más seguro que (1).
Almacene solo la clave encriptada y requiera intervención manual cada vez que se inicie un servidor.

¿Hay alguna opción que me esté perdiendo? No puedo imaginar que los sitios web a gran escala como Wikipedia o Google requieran intervención manual para iniciar un servidor, por lo que supongo que deben estar almacenando las claves de texto simple; pero parece que debe ser una mala práctica de seguridad.

encryption tls

pregunta amalloy 12.07.2013 - 23:03

fuente

2 respuestas

3

Estás evaluando que 2 no es más seguro que 1 es correcto. Es un paso más para que un atacante se desenrede, pero no es tan desafiante.

La opción 3 es mejor que la 1 y la 2, pero un atacante inteligente con privilegios de nivel de raíz probablemente pueda sacar su certificado de la memoria.

Línea inferior: su servidor necesita tener su certificado sin cifrar para servir el tráfico HTTPS y alguien con acceso de nivel raíz podrá acceder a él. Es solo cuestión de tiempo y esfuerzo.

Su mejor opción es proteger su certificado en el host con permisos de archivo, ejecutar su servidor con privilegios de subraíz (dejándolo caer de root a nadie o http después de que esté vinculado al puerto 80 y 443 y cargue el certificado) y monitorear el host para detectar comportamientos inusuales.

Si ocurriera lo peor y su certificado se ve comprometido, para eso están las listas de revocación de certificados.

[Editar] Una cosa adicional ... las protecciones que coloque en su certificado deben depender del nivel de riesgo que esté dispuesto a aceptar.

respondido por el u2702 12.07.2013 - 23:52

fuente

Lea otras preguntas en las etiquetas encryption tls

¿Indicador de comando de Utilman.exe? ¿Prevención de hackeo? ¿Alternativas al envío de contraseñas en texto sin formato por correo electrónico?

score 3 · Accepted Answer

Un reinicio del servidor es un hecho grave, y nunca debería ocurrir por sí solo . Lo ideal es que un administrador inicie sesión para desencadenar el reinicio, o al menos reiniciar el servidor después de que él / ella haya diagnosticado por qué se apagó, en primer lugar, si no se programó.

Por lo tanto, el administrador puede proporcionar la frase de contraseña manualmente.

Como una alternativa más débil , la SSLPassPhraseDialog puede ser utilizado para suministrar la frase de contraseña.

Para reforzar el escenario, la secuencia de comandos debe estar protegida (de lo contrario, no es mejor que una frase de contraseña de texto simple o no una frase de contraseña), por lo que tendría que preguntar la frase de contraseña a un segundo servidor. eso tiene algunos medios para determinar si la solicitud es legítima o no.

Por ejemplo, si hay un diagnóstico inactivo en el servidor, solo entonces se otorga un inicio de sesión SSH para el usuario servermaint de esa IP y se otorga la dirección correcta. contraseña repetida:

ssh -i identity_file servermaint@passphraseserver "getpassphrase"

Y el identity_file solo identifica ese servidor con una dirección IP conocida.

Un atacante que obtenga acceso al servidor web no encontrará una frase de contraseña y no podrá iniciar sesión en passphraseserver (en realidad, lo haría , pero tal intento provocaría una alertar y desconectarlo instantáneamente en lugar de proporcionar la frase de contraseña (y también marcaría el servidor como comprometido).

Un atacante no solo tendría que irrumpir en el servidor, sino también provocar un apagado del servidor web, y permanecerán en control del servidor web mientras se llevan a cabo los diagnósticos de apagado y análisis forense: un evento improbable en el mejor de los casos: con ese tipo de control, podría ser capaz de explotar el proceso de Apache y obtener una copia de la frase de contraseña cuando el verdadero administrador del sistema lo escriba.

Por supuesto, en un escenario más simple y mucho más común ("Sólo quiero que mi servidor vuelva a subir si se cae, lo más rápido posible; no importa por qué se haya caído, siempre sucederá de vez en cuando y luego "), sería más fácil omitir la frase de contraseña por completo.