¿Puede alguien explicar qué se logra exactamente mediante la generación de parámetros DH?

34

Estoy configurando un servidor node.js:

https.createServer({
    ...
    ciphers: 'ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH',
    honorCipherOrder: true
}, app).listen(443);

Esto es capaz de lograr una calificación de SSLLabs A, lo cual es bueno. Ahora, parece que todas las negociaciones en la simulación de handshake se realizan usando TLS_RSA_WITH_RC4_128_SHA .

RC4 es resistente a BESTIA. Si somos vulnerables a BESTIA no podemos obtener una calificación de A.

Me gustaría admitir PFS (secreto de reenvío) si el cliente lo admite.

Según mi lectura, "debo generar cierta aleatoriedad" al generar los parámetros de Diffie-Hellman y obtener eso en mis certificados de alguna manera, antes de que el servidor implemente correctamente ECDHE para el secreto hacia adelante. Leí en algún lugar que ECDHE requiere menos CPU que DHE, por lo que es una ventaja.

Bueno, tengo muchas preguntas. Pero voy a preguntar el primero:

¿Por qué debo generar "algunos aleatoriedad " para adjuntar a los certificados, ¿para qué sirve y qué hace realmente el comando? La página OpenSSL en dhparam no me dice mucho acerca de lo que realmente hace.

He visto esta respuesta y estoy buscando una explicación más clara (o al menos referencias a lecturas relevantes) !).

Según Cifres OpenSSL parece que ECDHE es un cifrado TLS 1.2. En página PFS de Qualys dice que ECDHE es compatible con todos los principales navegadores modernos, y sin embargo, solo veo iOS6 en los resultados de mi prueba de SSLLabs que se conecta a través de TLS1.2. Supongo que puedo tomar la sección de "simulación de apretón de manos" con un grano de sal.

Otra pregunta es por qué SSLLabs califica con una A si dejo la entrada HIGH en la lista de cifrado: esto haría que el servidor admitiera una conexión, por ejemplo. TLS_RSA_WITH_AES_128_CBC_SHA (el informe lo indica), que es vulnerable a BEAST! Tal vez porque nunca se probó con un "cliente" que no informa de compatibilidad con RC4.

Una pregunta más: en la página Cifres de OpenSSL, la lista debajo de las suites de cifrado TLS 1.2 incluye:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256     ECDHE-RSA-AES128-SHA256

¿Esto indica que si me conecto con ECDHE que ahora también es vulnerable a BEAST debido al uso de CBC? P.ej. Debería cambiar esto para hacer lo que hace Google: ECDHE con RC4. Pero la página de Ciphers no incluye nada que se parezca a ECDHE-RSA-RC4-SHA. Sin embargo, hay un ECDHE-ECDSA-RC4-SHA. ¿Cómo es esto diferente? Edit: esta respuesta SO menciona que ECDSA es algo separado de RSA. Me gustaría replicar lo que está haciendo Google con ECDHE_RSA + RC4 + SHA, ya que parece ser la combinación perfecta de rendimiento y seguridad.

Más notas (por favor, dígame si he entendido mal las cosas, especialmente las declaraciones disfrazadas de preguntas):

La resistencia de BESTIA se controla mediante la selección del cifrado simétrico (RC4 vs AES, etc.). ¿Los modos de AES que no utilizan CBC no son compatibles con muchos clientes? Entonces, ¿deberíamos evitar AES por completo ...? El PFS se puede obtener mediante el uso del intercambio de claves Diffie-Hellman, y solo los modos que incluyen DHE o ECDHE satisfacen esto. Sólo OpenSSL admite el secreto hacia delante perfecto. RC4 es más rápido que AES. RC4 es mejor que AES (debido a BESTIA)?

Otra edición: Veamos ... aquí es una indicación de que BEAST no es algo para ser < Em> también se preocupa de manera realista, aunque afecta negativamente la calificación de SSLLabs. Esa gran "A" se ve tan bien ... Veamos ... Probablemente debería poner los cifrados RC4_128 en el comienzo de la cadena de cifrado si, por ninguna otra razón, no se ha demostrado que estén "rotas", y están Más rápido que AES en general. De todos modos me he alejado mucho del tema original que es ECDHE. ¿Y cómo hacer que los parámetros DH funcionen correctamente con Node / Express?

    
pregunta Steven Lu 30.06.2013 - 06:47
fuente

4 respuestas

35

El intercambio tradicional basado en RSA en SSL es bueno porque se genera una clave de sesión aleatoria y se transmite mediante cifrado asimétrico, por lo que solo el propietario de la clave privada puede leerlo. Esto significa que nadie puede descifrar la conversación a menos que tengan la clave privada del certificado. Pero si un tercero guarda el tráfico cifrado y eventualmente adquiere la clave privada, puede usarla para descifrar la clave de sesión del intercambio de SSL, y luego usarla para descifrar toda la sesión. Así que eso no es un perfecto secreto hacia adelante.

La clave aquí para el secreto perfecto hacia adelante es el intercambio de claves Diffie-Hellman . DH es un algoritmo muy bueno para generar una clave compartida entre dos partes, de modo que un observador que ve todo , todo el intercambio entre las dos partes en claro, no puede obtener la clave solo de lo que está enviado por el cable. La clave secreta derivada se usa una vez, nunca se almacena, nunca se transmite y nadie puede volver a utilizarla. En otras palabras, secreto perfecto hacia adelante.

DH solo no puede protegerte porque es trivial jugar al hombre en el medio ya que no hay identidad ni autenticación. Por lo tanto, puede continuar usando RSA para la autenticación y solo usar Diffie-Hellman para generar la clave de sesión. Eso es DHE-RSA-* , así que, por ejemplo: DHE-RSA-AES128-SHA1 es una especificación de cifrado que usa Diffie-Hellman para generar la clave, RSA para la autenticación, AES-128 para el cifrado y SHA1 para los resúmenes.

Para empezar, Diffie-Hellman requiere algunos parámetros de configuración. Estos no son secretos y pueden ser reutilizados; más tardan varios segundos en generarse. Pero deben estar "limpios", generados por usted para que sepa que no los proporciona un atacante. El paso dhparam genera los parámetros DH (en su mayoría solo un solo número primo grande) por adelantado, que luego almacena para que el servidor los use.

Algunas investigaciones recientes demostraron que si bien es difícil "romper" un intercambio de DH (es decir, derivar la clave del tráfico), se puede hacer una buena cantidad de ese trabajo difícil de antemano, simplemente en base a los números primos. Esto significa que si los mismos números primos de DH se utilizan en todas partes, se convierten en un objetivo "principal" para que las agencias bien financiadas ejecuten sus cálculos. Esto sugiere que se puede tener un poco más de seguridad al generar sus propios números primos (en lugar de depender de los que vienen con su software), y quizás al volver a generar esos números primos periódicamente. p>

Un poco interesante es que curva elíptica Diffie-Hellman es un intercambio de Diffie-Hellman modificado que utiliza la criptografía de curva elíptica en lugar de los primos grandes de estilo RSA tradicional. Entonces, aunque no estoy seguro de qué parámetros puede necesitar (si los hay), no creo que necesite el tipo que está generando.

Ver también:

Con respecto a BEAST
El ataque BEAST se basa en algunos artefactos del método de encadenamiento de bloques utilizado con AES en versiones anteriores de SSL. Las nuevas versiones de SSL hacen las cosas bien, así que no te preocupes. RC4 no es un cifrado de bloque, por lo que no hay encadenamiento de bloque. El ataque de BESTIA es tan absurdamente difícil de lograr que sus implicaciones en el mundo real son decididamente inexistentes. De hecho, RC4 tiene algunas debilidades propias, especialmente cuando se abusa de la forma en que el ataque BESTIA tendría que hacer. Por lo tanto, es posible que no esté obteniendo una mejor seguridad.

Ciertamente, obligar a TLS 1.2 resolvería todos sus problemas de seguridad teóricos, mientras que al mismo tiempo evita que muchos visitantes se conecten. No totalmente diferente a usar ECDHE.

    
respondido por el tylerl 30.06.2013 - 07:47
fuente
10

En una suite de cifrado "DHE", el servidor genera sobre la marcha un nuevo Diffie-Hellman par de claves, firma la clave pública con su clave privada RSA o DSA o ECDSA, y la envía al cliente. La clave DH es "efímera", lo que significa que el servidor nunca la almacena en su disco; lo mantiene en la memoria RAM durante la duración del protocolo SSL, luego lo olvida por completo. Nunca se almacena, no se puede robar después, y de eso viene PFS . Tenga en cuenta que esta empresa DH nunca ingresa el certificado: el certificado del servidor contiene la clave pública permanente del servidor, de tipo RSA o DSA o ECDSA, y se usa solo para firmas.

Diffie-Hellman, genéricamente, es un algoritmo computado en un grupo finito donde los cálculos son fáciles, pero logaritmo discreto es difícil. En el DH "normal", el grupo consiste en algunos enteros modulo a big prime p , con la multiplicación como la ley de grupo. Los parámetros DH son la definición de ese grupo, a saber, el gran primo p y el generador convencional g . Por motivos de seguridad, no hay problema en reutilizar los mismos parámetros para varios pares de claves, incluido el uso de los mismos parámetros DH que otra persona. Lo que se necesita es que los parámetros sean "justos", es decir, que el primer p se generó de manera aleatoria, y no fue creado especialmente para hacer que el logaritmo discreto sea un módulo fácil que el primo.

La generación de sus propios parámetros DH es una forma de "asegurarse" de que utiliza correctamente los parámetros DH aleatorios. Sin embargo, es más ritualista que científico: la biblioteca del servidor SSL debe tener los parámetros DH predeterminados que están bien, y usted, por definición, ya confía en esa biblioteca SSL para no jugarle malas pasadas.

ECDHE sigue las mismas líneas, excepto que aplica DH en otro grupo, a saber, un curva elíptica . Las curvas elípticas tienen algunos beneficios computacionales, pero son menos compatibles (todavía). El análogo de generar sus propios parámetros DH sería elegir su propia curva aleatoria. Nadie realmente hace eso, porque:

  • Generar una curva aleatoria con características apropiadas es un esfuerzo complejo y costoso.
  • Los beneficios computacionales de las curvas elípticas provienen parcialmente de ambas partes (cliente y servidor) que están optimizadas para una curva específica. Generar tu propia curva aleatoria derrotaría eso.

En cuanto a BESTIA, no te preocupes demasiado por eso. Es un ataque al cliente , no al servidor, y los clientes modernos incluyen soluciones alternativas (la "división 1 / n-1", en particular). Es un buen ataque, pero ya no funciona. Lo único que el servidor podía hacer al respecto era forzar a un cliente antiguo inconsciente a usar RC4 (que no es vulnerable por construcción).

Tenga en cuenta que BEAST solo se aplica a SSL 3.0 y TLS 1.0. Con TLS 1.1 y 1.2, BEAST no funciona en absoluto, incluso si el cifrado simétrico es un cifrado de bloque en modo CBC.

    
respondido por el Thomas Pornin 01.07.2013 - 15:17
fuente
0

Los ataques de la NSA en RSA modificaron el PRNG (número aleatorio). Es una apuesta justa que no es el único PRNG con el que se han metido. Aquí hay un generador aleatorio basado en hardware que no es de los EE. UU. Y que merece la pena analizar: enlace

    
respondido por el anon 25.12.2013 - 01:06
fuente
0
  

RC4 es resistente a BESTIA.

Es cierto que el uso de cifrados de flujo evita BEAST y POODLE, sin embargo, RC4 tiene sus propios problemas. El flujo de clave tiene sesgos conocidos que pueden filtrar información.

RC4 se recomendó brevemente durante un tiempo después de que se descubriera la bestia, pero antes de que se diera cuenta de cuán graves eran los problemas de sesgo en la secuencia clave en RC4.

  

Si somos vulnerables a BESTIA no podemos obtener una calificación A.

Esto puede haber sido cierto en un momento dado, ya no lo es.

Los hombres de Qualys juzgan que la bestia es un mal menor que RC4.

  

¿Por qué debo generar "algo de aleatoriedad" para adjuntar a los certificados, para qué sirve y qué hace realmente el comando? La página de OpenSSL en dhparam no me dice mucho sobre lo que realmente hace.

dhparam genera parámetros usados para diffie-hellman convencional (no ECDH). Estos parámetros no son secretos, pero para que DH sea seguro, deben cumplir algunas condiciones. Hay algunas razones por las que puede querer generar sus propios parámetros.

  1. Los parámetros incluidos con su software pueden ser demasiado cortos. Si bien 1024 bit dh no se ha roto públicamente, se sospecha que algunos atacantes bien financiados pueden haberlo hecho.
  2. Gran parte del trabajo de cracking dh es por conjunto de parámetros, no por sesión. Así que usar los mismos parámetros que todos los demás permite que un atacante reutilice su trabajo para romper muchas sesiones de diferentes servidores.
  3. Es posible crear parámetros de puerta trasera que pueden ser fácilmente resquebrajados por la entidad que los generó, pero se ven bien para todos los demás. Los más paranoicos pueden preocuparse de que los parámetros enviados con su software estén en la puerta trasera.

Afaict no hay conjuntos de cifrados DHE que usen RC4. Por lo tanto, en su configuración, esto solo importaría si el cliente no admite ninguno de los conjuntos de cifrado que ha identificado explícitamente y, en su lugar, termina utilizando uno de los conjuntos de cifrado "DHE" tradicionales de la lista "ALTO".

  

Me gustaría admitir PFS (secreto de reenvío) si el cliente lo admite.

Para mantener el secreto hacia adelante, necesita usar un conjunto de cifrado DHE o ECDHE, por lo que si su prioridad es el secreto hacia adelante, debe poner esto por delante de cualquier otro conjunto de cifrado. Para obtener la mejor compatibilidad y rendimiento, debe colocar los conjuntos de cifrado ECHDE por delante del correspondiente conjunto de cifrado DHE.

Finalmente, piense con mucho cuidado antes de codificar las listas de conjuntos de cifrado en su software. Las opciones que se consideran mejores pueden y cambian con el tiempo.

    
respondido por el Peter Green 28.02.2017 - 13:49
fuente

Lea otras preguntas en las etiquetas