¿Debo probar mi certificado SSL para “RSA Shared Primes” antes de usarlo?

6

Hay varios documentos de 2012 que dicen que es Es posible factorizar varios módulos al factorizar primos compartidos. El enlace anterior incluye el código fuente de Python para verificar y probar este hecho.

Dado este conocimiento, ¿qué debo hacer como profesional de seguridad de TI con respecto a todos los certificados SSL de mi servidor y otros artefactos de cifrado que pueden o no ser vulnerables?

Pregunta

  • Si SSL es vulnerable, ¿es una buena idea para mí probar y volver a emitir los certificados afectados? ¿O simplemente debería cambiar los cifrados que utiliza mi servidor web?

  • ¿Los datos cifrados anteriores de las sesiones basadas en RSA o DHE son vulnerables?

pregunta random65537 30.06.2013 - 20:08
fuente

2 respuestas

2

Si es lo suficientemente simple como para realizar una prueba, entonces deberías hacerlo. No conozco ningún servicio u otro mecanismo que haga esta prueba por usted, pero si lo hace, entonces hágalo. La probabilidad de un ataque es probablemente muy escasa, pero la gravedad es bastante extrema. Sin duda vale la pena arreglarlo si lo detectas.

Sí, cualquier sesión anterior, si se captura, se puede descifrar si se puede derivar su clave privada. A menos que use Diffie-Hellman para generar su clave de sesión efímera (actualmente extremadamente poco común); simplemente busque "Perfect Forward Secrecy" para obtener información sobre cómo proteger las sesiones de hoy contra los ataques de mañana.

Tenga en cuenta que sus números primos se determinan cuando genera su clave , no su certificado . Generar una clave no cuesta nada (excepto su tiempo) y se puede hacer tantas veces como desee. Por lo tanto, si va a realizar una prueba, también puede generar la prueba de la clave antes de tiempo (o quizás varias de una sola vez), y luego generar una CSR basada solo en una tecla "fuerte". Una computadora con un buen TRNG (como Linux y BSD recientes) es útil aquí, ya que un mal PRNG suele ser su fuente de claves incorrectas.

Además, varias CA le permitirán "volver a escribir" un certificado, lo que básicamente significa emitir uno nuevo con la fecha de caducidad original. Entonces, si en algún punto su clave es sospechosa, esa puede ser una opción.

    
respondido por el tylerl 01.07.2013 - 05:25
fuente
2

Si acaba de crear una nueva clave, no se moleste en probarla. En su lugar, es mejor asegurarse de que cuando cree una nueva clave, utilice una buena aleatoriedad. Esta es una situación en la que la prevención es mucho más fácil que la detección.

Los investigadores descubrieron que el problema al que te estás refiriendo se debe principalmente a las claves privadas que se generaron en dispositivos integrados (por ejemplo, puntos de acceso inalámbrico de los consumidores, enrutadores DSL, etc.). Esos dispositivos tienden a tener PRNG pobres y (a menudo) código de generación de claves descuidadas. Por el contrario, si generó su clave en un servidor con un software confiable (por ejemplo, OpenSSL), probablemente esté bien.

(Excepción: el fallo de Debian afectó a algunas personas, pero eso fue hace bastante tiempo y no debería afectar a las claves que se generaron en el último año o dos).

    
respondido por el D.W. 01.07.2013 - 09:27
fuente

Lea otras preguntas en las etiquetas