Certificado SSL: ¿es necesaria una frase de contraseña y cómo lo sabe Apache?

13

Quiero generar una Solicitud de firma de certificado para mi servidor y para hacerlo, primero necesito una clave privada segura. Cuando creo una clave privada usando openssl genrsa -des3 -out server.key 2048 , me piden que proporcione una frase de contraseña. Después de investigar un poco, descubrí que no tener una contraseña es un alto riesgo para la seguridad porque una vez que mi clave privada se vea comprometida, el pirata informático podrá descifrar todo lo que estaba cifrado con mi clave.

Mi pregunta es: ¿cómo se supone que mi servidor funcione con una clave privada que necesita una frase de contraseña? Dado que no tiene cabeza, no hay forma de que pueda ingresar la clave cuando mi servidor arranca. ¿Cómo va a manejar Apache eso?

No pregunto cómo eliminar la frase de contraseña (sé cómo), estoy bastante interesado en cómo mi servidor podrá manejarlo y ¿es realmente un gran riesgo para la seguridad no usar una frase de contraseña? Quiero decir, una vez que el servidor web se vea comprometido, ¿no sería más fácil instalar un troyano?

    
pregunta Matt3o12 12.10.2014 - 19:01
fuente

3 respuestas

11

Si protege su clave privada con una frase de contraseña, Apache no podrá usarla a menos que le suministre la frase de contraseña cada vez que se reinicie o reinicie. Y dado que mantener esa frase de contraseña almacenada en el sistema de archivos anularía el punto de la frase de contraseña, eso significa tener algún tipo de método para pasar la frase de contraseña a Apache desde el exterior, cada vez que se reinicia o reinicia.

Algunas personas hacen esto, pero su impracticabilidad significa que la mayoría de las personas usan una clave privada no cifrada.

Si su clave privada no está encriptada, entonces su protección proviene del hecho de que solo su superusuario puede leerla y, por lo tanto, depende en gran medida de la integridad del sistema y de cuán susceptible es a la escalada de privilegios o similar.

Si su clave privada está comprometida, puede dirigirse a la autoridad de certificados de firma y pedirles que revoquen el certificado. La revocación no es una solución mágica; sin embargo, algunos sistemas no comprueban la revocación y una demora típica entre la revocación de un certificado y la información sobre la revocación que se está verificando.

  

una vez que mi clave privada se vea comprometida, el pirata informático podrá descifrar todo lo que estaba cifrado usando mi clave.

Este escenario es el tipo de cosas que secretismo hacia adelante está diseñado para prevenir. En TLS, las dos partes que se comunican pueden, si ambas cuentan con el soporte necesario, negociar configuraciones que permitan el secreto hacia adelante, de modo que, en caso de que la clave privada se vea comprometida, aún será imposible descifrar las comunicaciones anteriores.

La Prueba del servidor SSL puede verificar si la función de secreto de envío, entre otras cosas, funciona en su servidor.

    
respondido por el thomasrutter 13.10.2014 - 04:36
fuente
1
  

Quiero decir, una vez que el servidor web se vea comprometido, ¿no sería más fácil instalar un troyano hourse?

Esencialmente correcto. Una vez que un atacante tiene el control suficiente sobre su servidor, por lo general, solo pueden intercambiar su certificado cifrado por un certificado SSL barato o gratuito del tipo que solo confirma que tiene acceso al servidor (lo que hace el pirata informático). Los navegadores como regla no discriminan entre los certificados firmados por una CA válida.

O simplemente pueden destruir su configuración de Apache para que actúe como un proxy inverso para reenviar el tráfico a cualquier dirección que elijan.

El principal beneficio de un servidor con un certificado SSL encriptado cargado en tiempo de ejecución es que el certificado no puede ser robado para realizar un hombre en el ataque central. Esto es principalmente relevante para los sistemas donde el atacante solo tenía control limitado sobre el servidor; suficiente para robar datos pero no anular activos y reiniciar servicios.

    
respondido por el LateralFractal 13.10.2014 - 08:13
fuente
0
  

No estoy preguntando cómo eliminar la frase de contraseña (sé cómo), estoy más bien   interesado en cómo mi servidor será capaz de manejarlo y es realmente   un gran riesgo de seguridad para no usar una frase de contraseña? Quiero decir una vez que la web   El servidor se ve comprometido, ¿no sería más fácil instalar un troyano?   caballo?

Para dar una perspectiva ligeramente diferente sobre esto. Preguntar si algo es un gran riesgo de seguridad es un poco complicado. En primer lugar, hagamos esta pregunta, ¿es confidencial la información almacenada en el sitio web? ¿Existe más riesgo de seguridad si el sitio está fuera de línea? Si tiene información confidencial en el sitio web o viaja a través del sitio web, sería un alto riesgo no cifrar su clave privada. Sin embargo, si no tiene información confidencial y es más importante que el sitio esté activo todo el tiempo, puede ser un riesgo mayor para la seguridad la firma de la clave privada, ya que el póster anterior mencionó que esto significará que debe ingresar la contraseña en la carga de Apache.

Hay 3 áreas de seguridad, en general, Confidencialidad, Integridad y Acceso, usted firmaría el certificado si C & I es una preocupación y no si A es una preocupación.

Por supuesto, siempre puede tener su pastel y comérselo teniendo una granja de servidores web, o incluso solo instancias vm, luego balancee la carga con un control de estado en 443, de esta manera el tráfico se redirige a los servidores Apache que se ejecutan mientras alguien asiste. Para ingresar la contraseña para la clave privada, esto solo requiere dinero, cuanto más tenga, más podrá hacer.

    
respondido por el Brett Littrell 13.10.2014 - 16:43
fuente

Lea otras preguntas en las etiquetas