¿Por qué algunas API de lenguaje de programación no admiten contraseñas de clave privada?

Question

¿Por qué algunas API de lenguaje de programación no admiten contraseñas de clave privada?

#1 de Steve Sether (3 votos)
#2 de dave_thompson_085 (0 votos)

1

Dos preguntas:

Recientemente, comencé a crear un servidor web básico de Go y noté que la API para iniciar un servidor web TLS no admite una clave RSA privada cifrada simétricamente. La API se incluye a continuación y se vincula aquí :

func (srv *Server) ListenAndServeTLS(certFile, keyFile string) error

1) Dado que Go es un nuevo lenguaje de programación, y escrito con el beneficio de la experiencia, me pregunto por qué este es el caso. ¿No querrían los creadores fomentar el uso de archivos de clave encriptados y algunos patrones de pseudo-código como este?

var decryptKey = secureNetworkSource.getDecryptionKey();
ListenAndServeTLS(certFile, keyFile, decryptKey);

¿No entendí los beneficios de seguridad de usar un archivo de clave privada cifrada, es decir, es posible que el patrón anterior no sea más seguro que tener el archivo de clave sin cifrar en el disco?

2) También me pregunto por qué muchas de estas bibliotecas de servidores en diferentes idiomas (siendo Java el otro ejemplo que viene a la mente) confían en que el certificado se almacene localmente en el servidor; por ejemplo, la API de Go requiere una ruta a un archivo. ¿Por qué no es compatible con Bytestream, para que pueda adquirir una clave privada de otra fuente y reducir el radio de ráfaga de perder el disco duro en un servidor?

tls

pregunta uforic 30.06.2015 - 20:49

fuente

2 respuestas

Lea otras preguntas en las etiquetas tls

La autoridad de certificación ha cambiado para el sitio web personal, ¿pero no he cambiado nada? Importancia de la declaración de las bóvedas de usuarios de Lastpass y la autenticación de dos factores

score 3 · Answer 1

Los archivos de clave cifrados tienen algún valor, pero generalmente el valor es limitado porque la practicidad de una operación 24/7 determina que la clave debe almacenarse en el sistema de archivos en algún lugar sin cifrar. La alternativa de que un administrador ingrese la contraseña cada vez que se reinicia un servidor es terriblemente poco práctica y crea un riesgo de que el servidor se caiga si no se puede recordar la contraseña o si el administrador no la conoce.

Being that Go es un nuevo idioma, naturalmente, tendrá características limitadas. No admitir archivos de clave cifrados parece una omisión natural en un nuevo servidor web.

score 0 · Answer 2

No me queda claro si Java es parte de tu pregunta o no.

La API de Java Crypto puede cargar un almacén de claves desde cualquier flujo de entrada (y almacenar uno nuevo / modificado en cualquier flujo de salida), pero muchas aplicaciones y bibliotecas (y La utilidad keytool ) solo admite archivos. Ver por ejemplo enlace . Si su código utiliza la fábrica predeterminada de SSL configurada con las propiedades del sistema, también se limita principalmente a un archivo. Sin embargo, muchos sistemas operativos (¿la mayoría?) Admiten archivos que son realmente remotos e incluso pueden ser algo que solo imita un archivo, como Windows SMB, Unix NFS o Linux FUSE.

Las secuencias del almacén de claves Java están siempre encriptadas con contraseña , aunque como se señaló, esto generalmente significa que la contraseña solo se coloca en el servidor o en la configuración de JRE, lo que realmente no agrega seguridad.

También algunos "proveedores" tienen sus propios datos ; JCA puede usar un módulo de "hardware" PKCS # 11 , que puede ser desde un módulo de hardware real o una tarjeta inteligente hasta una biblioteca de software con sus propios archivos o base de datos o lo que sea. De manera similar, en Windows JCA puede usar el almacén de "certificados" (y claves) de Windows, que se almacena en algún lugar donde Microsoft intenta mantenerlo bien oculto y protegido. Depende de cada módulo PKCS # 11 si o cuando requiere contraseña (s); La tienda de Windows usa implícitamente el inicio de sesión de Windows.

Java SSL (JSSE) en sí mismo no requiere una tienda preexistente; está feliz de permitirte crear una nueva clave en la memoria y usarla. Por supuesto, los clientes SSL / TLS correctamente configurados no se conectarán a usted usando esa clave hasta que envíe un CSR a una CA y obtenga un certificado para ello, lo cual generalmente es inconveniente.