¿Cuál es el propósito del argumento -nodes en openssl?

102

¿Cuál es el propósito del -nodesargumento en openssl?

openssl

— usuario624409
fuente

Stack Overflow es un sitio para preguntas de programación y desarrollo. Esta pregunta parece estar fuera de tema porque no se trata de programación o desarrollo. Consulte ¿Qué temas puedo preguntar aquí en el Centro de ayuda? Quizás Super User o Unix & Linux Stack Exchange sería un mejor lugar para preguntar.

— jww

@jww No estoy de acuerdo, openssl es un conjunto de herramientas de bajo nivel y los desarrolladores tienen que lidiar con él todo el tiempo. La línea es bastante borrosa, y sería una gran pérdida no permitir preguntas openssl aquí simplemente porque resulta ser una CLI en lugar de C lib.

— gtd

@gtd: esa es una queja frecuente cuando las señalo. Consulte también ¿Dónde publico preguntas sobre Dev Ops? . (Pero creo que cometí un error en este caso; la pregunta es de 2011, y creo que estaba en el tema en ese entonces. No me gusta penalizar por el cambio de política).

— jww

@gtd - re: "openssl es un conjunto de herramientas de bajo nivel y los desarrolladores tienen que lidiar con él todo el tiempo". - para eso están Super User o Unix & Linux Stack Exchange . "... sería una gran pérdida no permitir preguntas de openssl ..." - Las preguntas de programación de openssl C siempre son bienvenidas aquí. La pérdida de las preguntas que no son de programación no se perderá porque Stack Overflow es un sitio de programación y desarrollo. Hay otros sitios a los que puede ir cuando no sabe cómo usar un comando.

— jww

Gracias por el enlace, publicaré mi respuesta allí, ya que creo que este es un tema muy importante.

— gtd

Respuestas:

123

La opción -nodesno es la palabra inglesa "nodes", sino que es "no DES". Cuando se proporciona como argumento, significa que OpenSSL no cifrará la clave privada en un archivo PKCS # 12 .

Para cifrar la clave privada, puede omitir -nodesy su clave se cifrará con 3DES-CBC. Para cifrar la clave, OpenSSL le solicita una contraseña y utiliza esa contraseña para generar una clave de cifrado utilizando la función de derivación de claves EVP_BytesToKey .

Según su versión de OpenSSL y las opciones compiladas, es posible que pueda proporcionar estas opciones en lugar de -nodes:

-des          encrypt private keys with DES
-des3         encrypt private keys with triple DES (default)
-idea         encrypt private keys with idea
-seed         encrypt private keys with seed
-aes128, -aes192, -aes256
              encrypt PEM output with cbc aes
-camellia128, -camellia192, -camellia256
              encrypt PEM output with cbc camellia

En última instancia, a nivel de biblioteca, OpenSSL llama a la función PEM_write_bio_PrivateKey con el algoritmo de cifrado (o la falta del mismo) que elija.

— indiv
fuente

Por cifrar, ¿te refieres con una contraseña?

— Flimm

@Flimm: Protegido con contraseña, sí. La contraseña genera una clave de cifrado mediante un algoritmo de derivación de claves, y el cifrado se realiza con la clave, no con la contraseña. La única forma de utilizar la clave cifrada es descifrarla primero, para lo cual necesita saber la contraseña con la que se cifró para generar la misma clave.

— indiv

¿Por qué debería cifrar mi archivo de clave privada? esos no se publican para nadie, de ahí el nombre. ¿O me equivoco?

— phil294

@Blauhirn: cifraría su archivo de clave privada por la misma razón por la que cifraría cualquier archivo: no quiere que alguien que obtenga una copia pueda leerlo o usarlo. El que deba cifrar la clave privada depende de la importancia de la clave y de su modelo de amenaza.

— indiv

editar: nginx v1.7.3 ha agregado una directiva ssl_password_file que lee las frases de contraseña de un archivo especificado probando cada frase de contraseña en la clave privada cifrada del contexto.

indiv es correcto que el -nodesargumento significa que OpenSSL creará una clave privada no cifrada ; de lo contrario, aparecerá un mensaje de contraseña para crear una clave privada cifrada . ver req , pkcs12 , CA.pl

sin embargo, creo que el propósito (para los programadores) es porque:

Los servidores HTTP (por ejemplo , Apache , Nginx ) no pueden leer la clave privada cifrada sin contraseña →
- Opción A: cada vez que se inicia el servidor HTTP, debe proporcionar una frase de contraseña para la clave privada cifrada.
- Opción B: especificar ssl_password_file file.keys;en http { }o server { }contexto. [ ref ]
- Opción C: utilícela -nodespara crear una clave privada sin cifrado

útil: bloquear private.key

{agregar servidor HTTP al grupo ssl-cert }
sudo chown root:ssl-cert private.key- ch ange propia er de private.key a raíz del usuario, ssl-cert grupo
sudo chmod 640 private.key- cambiar los permisos de acceso de private.key al propietario R / W, grupo R
ahora, el servidor HTTP debería poder iniciar y leer la clave privada no cifrada

Opción A

seguridad más sólida, pero cuando el servidor se reinicia, debe escribir manualmente la frase de contraseña para la clave privada cifrada.

Opción B

seguridad media, y probablemente buen equilibrio entre A / C

Opcion C

seguridad más débil, pero NO se le solicita una frase de contraseña de clave privada no cifrada

— Jake Berger
fuente

excelente explicación

— rizidoro

Nginx puede leer claves privadas cifradas desde la versión 1.7.3, consulte: nginx.org/en/docs/http/…

— 5lava

¿Cuál es el propósito de traer nginx y sus versiones a la discusión? Además, (B) y (C) ofrecen una seguridad equivalente (es decir, ACL del sistema de archivos). El problema que está describiendo es el problema del almacenamiento de claves desatendido , y es un problema sin solución. Consulte el libro de seguridad de ingeniería de Gutmann .

— jww

@jww la pregunta pregunta "cuál es el propósito ...". Consideré el contexto de la pregunta (QnA para programadores), que intenté indicar a través de "sin embargo, creo que el propósito (para programadores) es porque:". específicamente con respecto a la seguridad ... puede ser una discusión para security.stackexchange.com

— Jake Berger